インジェスト バッチ処理ポリシー

  • [アーティクル]

概要

キューに登録されたインジェスト プロセス中に、インジェストの前に小さなイングレス データ チャンクをバッチ処理することで、スループットが最適化されます。 バッチ処理により、キューに登録されたインジェスト プロセスによって消費されるリソースが削減され、バッチ処理されていないインジェストによって生成される小さなデータ シャードを最適化するためにインジェスト後のリソースは必要ありません。

インジェスト前にバッチ処理を実行することの欠点は、強制的な遅延です。 したがって、データ インジェストを要求してからクエリに対するデータの準備が完了するまでの、エンド ツー エンドの時間が長くなります。

IngestionBatching ポリシーを定義するときは、スループットの最適化と遅延時間とのバランスを見つける必要があります。 このポリシーは、キューを使用するインジェストに適用されます。 小さい BLOB をまとめてバッチ処理するときに許容される最大の強制遅延を定義します。 バッチ処理ポリシー コマンドの使用およびスループットの最適化の詳細については、以下を参照してください。

バッチのシール

一括インジェストの場合は、約 1 GB の非圧縮データが最適なサイズです。 データ量が非常に少ない BLOB のインジェストは最適とは言えません。そのため、キューを使用するインジェストでは小さい BLOB がまとめてバッチ処理されます。

次の一覧は、バッチをシールするための基本的なバッチ処理ポリシーのトリガーを示しています。 最初の条件が満たされると、バッチがシールされ、取り込まれます。

  • Size: バッチ サイズの上限に達したか、超過しています
  • Count: バッチ ファイル数の上限に達しました
  • Time: バッチ処理時間の有効期限が切れています

IngestionBatching ポリシーは、データベースまたはテーブルに対して設定できます。 既定値は次のとおりです: 5 分の最大遅延時間、1000 項目、1GB の合計サイズ。

重要

このポリシーを非常に小さい値に設定することの影響は、クラスターの COGS (売上原価) が増加し、パフォーマンスが低下することにあります。 さらに、バッチ処理ポリシーの値を小さくすると、複数のインジェスト プロセスを並行して管理するオーバーヘッドがあるため、エンド ツー エンドのインジェスト遅延が実質的に増加する可能性があります。

次の一覧は、単一の BLOB インジェストに関連したバッチをシールするための条件を示しています。 条件が満たされると、バッチがシールされ、取り込まれます。

  • SingleBlob_FlushImmediately: 'FlushImmediately' が設定されているため、1 つの BLOB を取り込む
  • SingleBlob_IngestIfNotExists: 'IngestIfNotExists' が設定されているため、1 つの BLOB を取り込む
  • SingleBlob_IngestByTag: 'ingest-by' が設定されているため、1 つの BLOB を取り込む
  • SingleBlob_SizeUnknown: BLOB サイズが不明なため、1 つの BLOB を取り込む

SystemFlush 条件が設定されている場合は、システム フラッシュがトリガーされたときにバッチがシールされます。 SystemFlush パラメーターが設定されている場合、システムはクラスターのスケーリングやシステム コンポーネントの内部リセットなどのためにデータをフラッシュします。

既定値と制限

種類 プロパティ Default 低待機時間の設定 最小値 最大値
項目数 MaximumNumberOfItems 500 500 1 25,000
データサイズ(MB) MaximumRawDataSizeMB 1024 1024 100 4096
時間 (秒) MaximumBatchingTimeSpan 300 20 - 30 10 1800

インジェスト バッチ処理ポリシーを使用してエンドツーエンドの待機時間を制御する最も効果的な方法は、待機時間の要件の上限に従って、テーブルまたはデータベース レベルでその時間境界を変更することです。 データベース レベルのポリシーは、テーブル レベルのポリシーが定義されていないデータベース内のすべてのテーブルと、新しく作成されたテーブルに影響します。

重要

インジェスト バッチ 処理ポリシーの時間境界を低イングレス テーブルで低く設定しすぎると、新しく作成したデータ シャードの最適化がクラスターで試みられる際に、追加のコンピューティングとストレージの作業が発生する可能性があります。 データ シャードの詳細については、エクステントに関する記事を参照してください。

バッチ データ サイズ

バッチ処理ポリシーのデータ サイズは、非圧縮データに対して設定されます。 Parquet、AVRO、ORC ファイルの場合、ファイル サイズに基づいて推定の計算が行われます。 圧縮データの場合、非圧縮データ サイズが次のように精度の降順に評価されます。

  1. インジェスト ソース オプションに圧縮されていないサイズが指定されている場合は、その値が使用されます。
  2. SDK を使用してローカル ファイルを取り込む場合は、zip アーカイブと gzip ストリームが検査され、生のサイズが評価されます。
  3. 上記のオプションでデータ サイズが指定されていない場合は、圧縮されたデータ サイズに係数を適用して、非圧縮データ サイズが推定されます。

バッチ処理の待機時間

待機時間は、多くの原因によって発生する可能性があり、バッチ処理ポリシー設定を使用して対処できます。

原因 解決策
データの待機時間が time 設定に一致し、データが少なすぎて size または count の制限に達しない time 制限を減らす
非常に小さなファイルが多数あるために非効率的なバッチ処理 ソース ファイルのサイズを大きくします。 Kafka シンクを使用する場合は、100 KB チャンク以上でデータを送信するように構成します。 小さいファイルが多数ある場合は、データベースまたはテーブルのインジェスト ポリシーで count を増やします (最大 2000)。
大量の非圧縮データのバッチ処理 これは、Parquet ファイルを取り込む場合によくあります。 テーブルまたはデータベースのバッチ処理ポリシーの size を 250 MB に向かって徐々に減らし、改善されるかどうかを確認します。
クラスターがスケールされているためのバックログ Azure Advisor の提案を受け入れて、クラスターをスケールアサイドまたはスケールアップします。 または、クラスターを手動でスケーリングして、バックログが閉じられていることを確認します。 これらのオプションが機能しない場合は、サポートにお問い合わせください。