データロードのベストプラクティスとパフォーマンスチューニング
データロードは Apache Doris の重要な機能の一つです。ロード効率は、リアルタイム分析でデータを利用できるまでの速さとシステムの安定性に直結します。この記事では、典型的な業務シナリオを起点に、すぐに適用できるベストプラクティスを紹介した後、ロードの内部動作とチューニング方法を説明します。次の判断に役立ちます。
- 業務の特性に合ったロード方法を選ぶ
- テーブル設計、バッチ処理、バケット分割、メモリ、同時実行数を適切に決める
- 高頻度の小規模ロード、書き込み増幅、MemTable の OOM などの一般的な問題を避ける
- 業務に適したレイテンシーとスループットのバランスを見つける
クイックナビゲーション
| 検討事項 | 推奨事項 | セクション |
|---|---|---|
| ロード方法の選択 | データソースとリアルタイム性の要件に基づいて選ぶ | 適切なロード方法を選ぶ |
| テーブルモデル | Duplicate Key モデルを優先する | テーブルモデルとインデックス |
| パーティション分割とバケット分割 | 単一の Tablet を 1～10 GB に保つ | パーティション分割とバケット分割の設定 |
| ランダムバケット分割 | load_to_single_tablet を有効にしてスループットを向上させる | ランダムバケット分割のロード最適化 |
| 高頻度の小規模ロード | クライアント側のバッチ処理と Group Commit を組み合わせる | バッチ処理の方針 |
| ロードごとに扱うパーティション数 | MemTable が増えすぎないよう少数に抑える | パーティションのロードとメモリ制御 |
| 大量データのロード | バッチに分割し、各バッチを 100 GB 以下にする | 大量データのバッチロード |
| Broker Load の同時実行 | 圧縮ファイルや列指向ファイルを分割して同時実行を可能にする | Broker Load の同時実行 |
| Stream Load の同時実行 | BE ごとの同時実行数を 128 未満に保つ | Stream Load の同時実行 |
適切なロード方法を選ぶ
Doris には、基本的なワークフローを共有しながら、それぞれ異なるシナリオに最適化された複数のロード方法があります。データソースと業務要件に応じて選択してください。
| ロード方法 | プロトコル | 実行モード | 代表的なデータソース | 適したシナリオ |
|---|---|---|---|---|
| Stream Load | HTTP | 同期 | ローカルファイル、データストリーム | アプリケーションからの送信など、リアルタイムの書き込み |
| Broker Load | SQL | 非同期 | HDFS、S3、その他の外部ストレージ | 大規模なバッチロード |
| Routine Load | SQL | 非同期ストリーミング | Kafka | メッセージキューデータのリアルタイム同期。Exactly-Once をサポート |
| Insert Into / Select | SQL | 同期／非同期 | Doris テーブル、Hive、MySQL、S3 TVF | ETL ジョブ、外部データの統合 |
| MySQL Load | MySQL LOAD DATA | 同期 | ローカルの CSV ファイル | MySQL ユーザーによる小規模なテストや移行（FE が Stream Load として転送） |
ロードのベストプラクティス
以下では、データロードでよく検討する事項と、すぐに適用できるベストプラクティスを説明します。
テーブルモデルとインデックス
テーブルモデルの選択
Duplicate Key モデルを優先してください。
- 集約や重複排除を行わず、生データのみを格納するため、ロード経路が最も短くなります。
- ロードとクエリの両方で、ほかのモデルより高いパフォーマンスを発揮します。
- Aggregate モデルでは Key 列による集約、Unique Key モデルでは重複排除が必要です。どちらも MemTable 段階で BE 側に追加の計算（ソートや重複排除）が発生し、CPU とメモリの使用量が増えます。
Key による集約や重複排除が実際に必要な場合にのみ、Aggregate モデルまたは Unique Key モデルを選択してください。詳しくはデータモデルを参照してください。
インデックスの制御
ビットマップインデックスや転置インデックスなどは、ロード中に同期して更新する必要があり、書き込み時の維持コストが増えます。次の点を推奨します。
- インデックスは、頻繁にクエリされるフィールドにのみ作成する。
- 不要なインデックスを避ける。これにより、書き込み時に BE で行うインデックスの構築と検証が減り、CPU とメモリの使用量を抑えてロードのスループットを高められます。
パーティション分割とバケット分割の設定
パーティション分割とバケット分割は、BE ノード間のデータ分散と並列処理の度合いを決め、ロードとクエリのパフォーマンスに直接影響します。
単一の Tablet のサイズ: 1～10 GB
単一の Tablet のサイズを 1～10 GB の範囲に保ってください。
| Tablet のサイズ | 影響 |
|---|---|
| 小さすぎる | 集約の効果が低くなり、メタデータ管理の負荷が増える |
| 大きすぎる | レプリカの移行と補充が難しくなる |
| 1～10 GB（推奨） | ロード、クエリ、レプリカ管理のバランスが取れる |
バケット数の計算式は bucket count = total data size / (1-10 GB) です。適切なバケットキー（ランダムな列など）と組み合わせてデータの偏りを避け、BE ノード間の負荷を均等にし、並列書き込みの効率を高めてください。
詳しくはデータ分散を参照してください。
パーティション設計: 分散とメモリ負荷を抑える
業務上のクエリパターン（時間や地域など）に基づいてパーティションを分割すると、ロード中にデータが対象のパーティションにのみ分散され、無関係なパーティションのメタデータやファイルを処理せずに済みます。さらに、次の点に注意してください。
- 複数のパーティションに同時に書き込むと、多数の Tablet がアクティブになります。各 Tablet が独自の MemTable を使用するため、BE のメモリ負荷が大きく増えます。
- メモリが不足すると、早期 Flush が実行されます。これにより小さな Segment ファイルが多数生成され、頻繁な Compaction と書き込み増幅が発生します。
アクティブなパーティション数を制限すると（日単位でロードするなど）、同時にアクティブになる Tablet の数とメモリ負荷を減らせます。また、より大きな Segment ファイルが生成され、Compaction の負荷が下がるため、並列書き込みの効率とその後のクエリ性能が向上します。
ランダムバケット分割のロード最適化
ランダムバケット分割を使用する場合は、load_to_single_tablet=true を設定して単一 Tablet へのロードモードを有効にできます。
- データを単一の Tablet に直接書き込みます。複数の Tablet への分散を省き、Tablet の分散計算による CPU 負荷と BE 間の RPC 転送負荷をなくします。
- 単一の Tablet に書き込みを集中させることで、小さな Segment ファイルの生成を減らし、頻繁な Compaction による書き込み増幅を避けます。
- 大規模なデータロードの同時実行性能とスループットを大幅に向上させます。
詳しくはランダムバケット分割を参照してください。
バッチ処理の方針
各ロードは独立したトランザクションであり、FE Edit Log への書き込み（メタデータ変更の記録）と BE MemTable のディスクへの Flush（Segment ファイルの生成）を伴います。高頻度の小規模バッチロード（KB 単位）では、次の問題が発生します。
- FE Edit Log への書き込みが頻繁になり、FE のディスク I/O が増える。
- BE MemTable の Flush が頻繁になり、小さな Segment ファイルが多数生成される。
- Compaction が頻繁になり、深刻な書き込み増幅が発生する。
クライアント側とサーバー側のバッチ処理を組み合わせることで、これらの問題を軽減できます。
| バッチ処理の方法 | 適したシナリオ | 推奨事項 |
|---|---|---|
| クライアント側のバッチ処理 | クライアントが制御できるバッチ書き込み | ロードを開始する前に、クライアント側でデータを数百 MB～数 GBまで蓄積します。多数の小さなトランザクションを単一の大きなトランザクションにまとめることで、FE Edit Log への書き込みと BE MemTable の Flush の頻度を下げ、ストレージの断片化やその後の Compaction によるリソース消費を抑えます。 |
| サーバー側のバッチ処理（Group Commit） | 同時実行数が多く、データ量の少ないロード | Group Commit を有効にすると、サーバーが短い時間枠内の複数の小さなバッチを単一のトランザクションにまとめます。統合された大きなトランザクションによって、より大きな Segment ファイルが生成され、バックグラウンドの Compaction 負荷が下がります。ログや IoT データなど、高頻度の小規模バッチに特に適しています。 |
パーティションのロードとメモリ制御
ロード中、BE はまずデータをメモリ上の MemTable（デフォルトで 200 MB）に書き込みます。MemTable がいっぱいになると、ディスクへ非同期に Flush して Segment ファイルを生成します。各 Tablet はメモリ上に単一のアクティブな MemTable を持つため、ロードごとに扱うパーティション数がメモリ使用量に直接影響します。
- パーティション数が多いと、アクティブな Tablet と MemTable が増え、メモリ使用量が増加します。
- メモリ使用量が高すぎる場合は、プロセスの OOM を避けるために早期 Flush が実行されます。
- 早期 Flush によって小さなファイルが多数生成され、ロード性能がさらに低下します。
安定したロードスループットを得るには、次の点を守ってください。
- パーティションを順番にロードする: たとえば日単位でロードし、単一のパーティションに書き込みを集中させます。これにより、MemTable の分散と Flush の回数が減り、メモリの断片化と I/O 負荷が抑えられます。
- 単一のロードで扱うパーティション数を厳しく制限する: MemTable が増えすぎて早期 Flush が発生するのを避けます。
大量データのバッチロード
ファイル数が多く、データ量も非常に大きい場合は、再試行のコストを減らし、BE のメモリとディスクに負荷が集中するのを避けるため、バッチに分けてロードしてください。
| データソース | 推奨ロード方法 | 推奨バッチサイズ |
|---|---|---|
| HDFS やオブジェクトストレージなどのリモートファイル | Broker Load | 各バッチを 100 GB 以下にする |
| 大きなローカルファイル | Doris の streamloader ツール（自動バッチ処理） | ツールが自動的に制御する |
Broker Load の同時実行
同時実行の方針はファイルの種類によって異なります。
- 圧縮ファイル／Parquet／ORC ファイル: 同時にロードできるよう、ロード前に複数の小さなファイルへ分割します。
- 非圧縮の CSV／JSON ファイル: Doris が内部でファイルを自動分割し、同時にロードします。
同時実行の方針については、Broker Load の設定パラメータを参照してください。
Stream Load の同時実行
Stream Load の同時実行数は、BE のスレッドプールパラメータによって制限されます。以下のしきい値に従ってください。
| パラメータ／しきい値 | 推奨値 | 説明 |
|---|---|---|
| BE ごとの同時実行数（推奨上限） | 128 以下 | BE の webserver_num_workers によって制御されます。超過すると Web サーバーのスレッドが枯渇し、ロード性能が低下する可能性があります。 |
| BE ごとの同時実行数（絶対上限） | 512 を超えないこと | doris_max_remote_scanner_thread_pool_thread_num によって制御されます。超過すると BE プロセスがハングする可能性があります。 |
低レイテンシーのシナリオでの同時実行数の調整
リアルタイム監視など、低レイテンシーが求められるシナリオでは、次を検討してください。
- リソース競合を避けるため、同時実行数を適切に減らす。
- Group Commit の非同期モード（
async_mode）と組み合わせて小さなトランザクションをまとめ、トランザクションのコミットにかかる時間を短縮する。
Doris のロードの内部動作
以下の内部動作を理解すると、複雑なシナリオでも適切にチューニングできます。
設計思想
Doris のデータロードは分散アーキテクチャ上に構築されており、主に Frontend（FE）ノードと Backend（BE）ノードが関わります。
- FE: メタデータ管理、クエリ解析、タスクのスケジューリング、トランザクションの調整を担当します。
- BE: 実際のデータ格納、計算、書き込みを担当します。
データロードの設計は、リアルタイム書き込み、ストリーミング同期、バッチロード、外部データソースの統合など、多様な業務要件に対応することを目指しています。基本原則は次のとおりです。
| 設計目標 | 実装 |
|---|---|
| 一貫性と原子性 | 各ロードタスクをトランザクションとして扱い、データの書き込みに原子性を持たせ、部分的な書き込みを防ぎます。Label の仕組みにより、データの欠落や重複を防ぎます。 |
| 柔軟性 | さまざまなデータソース（ローカルファイル、HDFS、S3、Kafka など）と形式（CSV、JSON、Parquet、ORC など）をサポートし、異なるシナリオに対応します。 |
| 効率性 | 分散アーキテクチャを利用してデータを並列処理し、複数の BE ノードによる同時処理でスループットを高めます。 |
| シンプルさ | 軽量な ETL 機能を提供します。ロード中にデータのクレンジングと変換ができ、外部ツールへの依存を減らせます。 |
| 柔軟なモデリング | Duplicate Key、Unique Key、Aggregate Key の各モデルをサポートし、ロード中のデータ集約や重複排除を可能にします。 |
共通のロードワークフロー
Stream Load、Broker Load、Routine Load など、ロード方法にかかわらず、基本的なワークフローはほぼ同じです。
-
ロードタスクの送信
- クライアント（HTTP、JDBC、MySQL クライアントなど）からロードリクエストを送信し、データソース（ローカルファイル、Kafka トピック、HDFS ファイルパスなど）、対象テーブル、ファイル形式、ロードパラメータ（区切り文字やエラー許容値など）を指定します。
- 各タスクには、タスクの識別と冪等性の確保（重複ロードの防止）に使う一意の Label を指定できます。たとえば Stream Load では、HTTP ヘッダーで Label を指定します。
- Doris Frontend（FE）はリクエストを受け取り、権限を検証し、対象テーブルの存在を確認して、ロードパラメータを解析します。
-
タスクの割り当てと調整
- FE はデータ分散（テーブルのパーティション分割とバケット分割の規則に基づく）を分析してロード計画を作成し、タスク全体を調整する Coordinator として Backend（BE）ノードを選びます。
- Stream Load のように BE に直接送信する場合、その BE が Coordinator になることもできますが、その場合もテーブルスキーマなどのメタデータを FE から取得する必要があります。
- ロード計画によりデータを複数の BE ノードに分散し、並列処理によって効率を高めます。
-
データの読み取りと分散
- Coordinator BE はデータソースからデータを読み取ります（Kafka からメッセージを取得する、S3 からファイルを読み取る、HTTP データストリームを直接受信するなど）。
- Doris はデータ形式を解析し（CSV の分割や JSON の解析など）、ユーザーが指定する次の軽量な ETL 処理をサポートします。
- 事前フィルタリング: 生データをフィルタリングして処理負荷を減らします。
- 列マッピング: ソースの列と対象テーブルの列の対応関係を調整します。
- データ変換: 式を使用してデータを処理します。
- 事後フィルタリング: 変換後のデータをフィルタリングします。
- 解析後、Coordinator BE はパーティション分割とバケット分割の規則に従って、下流の複数の Executor BE にデータを分散します。
-
データの書き込み
- データは複数の BE ノードに分散され、Key 列でソートされたメモリ上のテーブル（MemTable）に書き込まれます。Aggregate または Unique Key モデルでは、Doris が Key に基づいて集約または重複排除を行います（SUM、REPLACE などを使用）。
- MemTable がいっぱいになる（デフォルトで 200 MB）かタスクが終了すると、データが非同期にディスクへ書き込まれ、Rowset を構成する列指向の Segment ファイルになります。
- 各 BE は割り当てられたデータを独立して処理し、書き込み完了後に Coordinator へ状態を報告します。
-
トランザクションのコミットと公開
- Coordinator は FE にトランザクションのコミット（Commit）を開始します。FE は過半数のレプリカへの書き込みが成功したことを確認すると、BE にデータバージョンの公開（Publish Version）を通知します。BE の Publish が成功すると、FE はトランザクションを VISIBLE としてマークし、データをクエリできるようになります。
- 失敗した場合、FE はロールバックを実行して一時データを削除し、データの一貫性を確保します。
-
結果の返却
- 同期方式（Stream Load、Insert Into など）は、成功／失敗の状態やエラーの詳細（ErrorURL など）を含むロード結果を直接返します。
- 非同期方式（Broker Load など）はタスク ID と Label を返します。
SHOW LOADを使うと、進捗、エラー行数、詳細情報を確認できます。 - 操作は監査ログに記録され、後から追跡できます。
MemTable 転送
MemTable 転送は Apache Doris 2.1.0 で導入された最適化で、INSERT INTO...SELECT によるロードの性能を大幅に向上させます。
- 従来のフローのボトルネック: Sink ノードはデータを Block 形式にエンコードし、Ping-pong RPC を介して下流ノードに転送する必要があります。これには複数回のエンコードとデコードが伴い、負荷が増えます。
- 最適化: Sink ノードが MemTable を直接処理して Segment データを生成し、Streaming RPC で転送します。これにより、エンコード／デコードと転送待ちが減り、メモリのバックプレッシャーもより正確になります。
- 性能向上: 公式テストでは、ロード時間が単一レプリカ構成で従来の 36%、三つのレプリカを持つ構成で 54% に短縮され、全体的な性能が 100% 以上向上しています。
- 適用範囲: 現在、この機能はストレージとコンピュートを一体化したデプロイモードでのみサポートされています。
コンピュートとストレージを分離したアーキテクチャでのロード
コンピュートとストレージを分離したアーキテクチャでは、データストレージとトランザクション管理の分離がロード最適化の中心になります。
- データストレージ
- BE はデータを永続化しません。MemTable の Flush 後、生成された Segment ファイルを共有ストレージ（S3 や HDFS など）へ直接アップロードします。オブジェクトストレージの高可用性と低コストを活用し、弾力的なスケーリングを実現します。
- BE のローカル File Cache はホットデータを非同期にキャッシュし、TTL と Warmup の方針によってクエリのキャッシュヒット率を高めます。
- Tablet や Rowset などのメタデータは、BE 上のローカル RocksDB ではなく、Meta Service によって FoundationDB に保存されます。
- トランザクション処理
- トランザクション管理を FE から Meta Service に移し、FE Edit Log への書き込みによるボトルネックを解消します。
- Meta Service は標準インターフェース（
beginTransaction、commitTransaction）を通じてトランザクションを管理し、FoundationDB のグローバルトランザクション機能を利用して一貫性を確保します。 - BE Coordinator は Meta Service と直接やり取りしてトランザクション状態を記録し、アトミック操作で競合とタイムアウト時の回収を処理します。これにより同期ロジックが簡素化され、同時実行数の多い小規模バッチロードのスループットが向上します。
レイテンシーとスループットのトレードオフ
実際の業務シナリオでは、データロードのレイテンシーとスループットのバランスを取る必要があります。
- レイテンシーを下げる: 最新のデータをより早く参照できます。ただし、書き込みバッチが小さく頻度が高くなると、バックグラウンドの Compaction が頻繁に発生します。その結果、CPU、I/O、メモリの消費とメタデータ管理の負荷が増えます。
- スループットを高める: ロードごとのデータ量を増やし、ロード回数を減らすことで、メタデータ管理の負荷とバックグラウンドの Compaction 負荷が大幅に下がり、システム全体の性能が向上します。ただし、データの書き込みから参照可能になるまでの時間は長くなります。
したがって、業務のレイテンシー要件を満たしながら、ロードごとのデータ量をできる限り増やすことで、スループットを高め、システム負荷を軽減してください。
テストデータ
Flink のエンドツーエンドレイテンシー
このテストでは、Flink Connector をバッチ書き込みモードで使用し、エンドツーエンドのレイテンシーとロードのスループットを測定します。バッチ間隔は Flink Connector のパラメータ sink.buffer-flush.interval で制御します。Flink Connector の使用方法については、Flink-Doris-Connectorを参照してください。
マシン構成:
- 1 FE: 8 コア CPU、16 GB メモリ
- 3 BEs: 16 コア CPU、64 GB メモリ
データセット:
- TPCH lineitem データ
バッチ間隔と同時実行数によるロード性能の違い:
| バッチ間隔（秒） | ロードの同時実行数 | バケット数 | スループット（行/秒） | エンドツーエンドの平均レイテンシー（秒） | エンドツーエンドの P99 レイテンシー（秒） |
|---|---|---|---|---|---|
| 0.2 | 1 | 32 | 6073 | 0.211 | 0.517 |
| 1 | 1 | 32 | 31586 | 0.71 | 1.39 |
| 10 | 1 | 32 | 67437 | 5.65 | 10.90 |
| 20 | 1 | 32 | 93769 | 10.962 | 20.682 |
| 60 | 1 | 32 | 125000 | 32.46 | 62.17 |
| 0.2 | 10 | 32 | 9300 | 0.38 | 0.704 |
| 1 | 10 | 32 | 34633 | 0.75 | 1.47 |
| 10 | 10 | 32 | 82023 | 5.44 | 10.43 |
| 20 | 10 | 32 | 139731 | 11.12 | 22.68 |
| 60 | 10 | 32 | 171642 | 32.37 | 61.93 |
バケット数によるロード性能の違い:
| バッチ間隔（秒） | ロードの同時実行数 | バケット数 | スループット（行/秒） | エンドツーエンドの平均レイテンシー（秒） | エンドツーエンドの P99 レイテンシー（秒） |
|---|---|---|---|---|---|
| 1 | 10 | 4 | 34722 | 0.86 | 2.28 |
| 1 | 10 | 16 | 34526 | 0.8 | 1.52 |
| 1 | 10 | 32 | 34633 | 0.75 | 1.47 |
| 1 | 10 | 64 | 34829 | 0.81 | 1.51 |
| 1 | 10 | 128 | 34722 | 0.83 | 1.55 |
Group Commit のテスト
高頻度の小規模バッチロードでは、Group Commit を有効にすることを推奨します。ロード性能が大幅に向上します。Group Commit の性能テストデータについては、Group Commit の性能を参照してください。
よくある質問
Q1: 適切なロード方法はどのように選べばよいですか？
データソースとリアルタイム性の要件に基づいて選んでください。ローカルファイルのリアルタイム送信には Stream Load、HDFS/S3 の大規模バッチには Broker Load、Kafka のストリーミングデータには Routine Load、外部テーブルまたは Doris テーブル間の ETL には Insert Into / Select、MySQL 互換のシナリオには MySQL Load を使用します。
Q2: 高頻度の小規模バッチロードが性能に大きく影響するのはなぜですか？
高頻度の小規模ロードでは Doris が頻繁に Compaction を実行し、深刻な書き込み増幅が発生します。クライアント側でデータを数 MB～数 GB まで蓄積するか、Group Commit を有効にしてサーバー側でまとめてください。
Q3: ロードで小さなファイルが多数生成され、Compaction の負荷が高い場合はどうすればよいですか？
Group Commit を有効にして小さなトランザクションをまとめるか、クライアント側で数百 MB～数 GB のデータを蓄積してからロードしてください。同時に、アクティブな Tablet が多くなりすぎないよう、パーティション分割とバケット分割の設計を確認してください。
Q4: 単一のロードで多数のパーティションを扱わないほうがよいのはなぜですか？
各 Tablet はメモリ上に単一のアクティブな MemTable を持ちます。アクティブな MemTable が占めるメモリの合計が大きくなりすぎると、OOM を避けるために早期 Flush が実行されます。これにより小さなファイルが多数生成され、ロード性能が低下します。単一のロードで扱うパーティション数を制限すると、この問題を軽減できます。
Q5: ロードごとのデータ量は、大きいほど常によいのですか？
いいえ。各バッチを 100 GB 以下にしてください。バッチが大きすぎると、再試行のコストと BE のメモリやディスクへの影響が増えます。大きなローカルファイルには、自動的にバッチへ分割する streamloader ツールを使用できます。
Q6: Tablet のサイズに 1～10 GB が推奨されるのはなぜですか？
Tablet が小さすぎると集約の効果が弱まり、メタデータ管理の負荷が増えます。大きすぎると移行と補充のコストが高くなります。1～10 GB は、ロード、クエリ、レプリカ管理のバランスを取るための経験的な範囲です。
Q7: Stream Load の同時実行数はどう設定すればよいですか？
単一 BE 上の Stream Load の同時実行数は 128 を超えないようにし（webserver_num_workers による制限）、512 未満にする必要があります（doris_max_remote_scanner_thread_pool_thread_num による制限）。そうしないと BE プロセスがハングする可能性があります。
Q8: MemTable 転送はどのようなシナリオで有効ですか？
ストレージとコンピュートを一体化したデプロイモードでの INSERT INTO...SELECT にのみ有効です。ロード時間は、単一レプリカ構成で従来の 36%、三つのレプリカを持つ構成で 54% になります。コンピュートとストレージを分離したモードでは、現在この最適化はサポートされていません。
Q9: データの偏りを避けるにはどうすればよいですか？
適切なバケット数（圧縮後に単一の Tablet が 1～10 GB になる値）を設定し、適切なバケットキーを選んでください。ランダムバケット分割のシナリオでは、load_to_single_tablet=true を有効にすると分散処理の負荷を減らせます。
トラブルシューティング
| 症状 | 考えられる原因 | 調査と対処 |
|---|---|---|
| ロードのスループットが低く、Compaction が頻繁に発生する | 高頻度の小規模バッチロードによる書き込み増幅 | クライアント側でバッチ処理するか、Group Commit を有効にする |
| ロード中に小さなファイルが多数生成される | 単一のロードで扱うパーティションが多すぎ、MemTable の早期 Flush が発生している | ロードごとに扱うパーティション数を減らし、順番にロードする |
| ロードしたデータが参照可能になるまで時間がかかる | 書き込みが成功したレプリカが過半数に達していない、または Publish が遅い | SHOW LOAD でタスクの状態を確認し、BE の稼働状態を検証して、必要に応じて Publish のタイムアウトを延ばす |
| BE で OOM または頻繁な Flush が発生する | 同時にアクティブなパーティション／Tablet が多すぎ、MemTable が分散している | パーティションを順番にロードし、バケット数と同時実行数を減らす |
| FE Edit Log の負荷が高い | 高頻度の小規模バッチロードでトランザクションが多すぎる | Group Commit を有効にするか、クライアント側でバッチ処理し、同時実行数が高すぎないか確認する |
| Compaction が追いつかず、クエリが遅くなる | 小さなファイルが多すぎ、書き込み増幅が深刻になっている | ロードごとのデータ量を増やし、バケット分割を調整し、必要に応じて Compaction パラメータを調整する |
| コンピュートとストレージを分離した構成でロード性能がばらつく | オブジェクトストレージの QPS 制限 | 同時実行数を制御し、バッチごとのデータ量を増やし、オブジェクトストレージ側の QPS クォータを確認する |
| ロードでエラー行が報告される | データ形式の不一致、列マッピングのエラー | 返された ErrorURL からエラーのサンプルを確認し、列マッピング、区切り文字、エラー許容値を調整する |
| BE プロセスがハングする | 単一 BE 上の Stream Load の同時実行数が 512 を超えている | 同時実行数を減らし、doris_max_remote_scanner_thread_pool_thread_num を調整する |
| Web サーバーのスレッドが枯渇し、Stream Load が遅い | 単一 BE 上の同時実行数が 128 を超えている | 同時実行数を 128 未満に保つか、webserver_num_workers を調整する |
| Broker Load の同時実行数が低い | 単一の圧縮ファイル／Parquet／ORC ファイルが大きすぎ、分割されていない | ロード前に大きなファイルを複数の小さなファイルに分割する |
| 単一の Broker Load が失敗した際の再試行コストが高い | バッチサイズが大きすぎる | 各バッチを 100 GB 未満にし、分割して送信する |