インジェスト バッチ処理ポリシー
概要
キューに登録されたインジェスト プロセス中に、インジェストの前に小さなイングレス データ チャンクをまとめてバッチ処理することで、サービスがスループットを最適化します。 バッチ処理により、キューに登録されたインジェスト プロセスによって消費されるリソースが減り、バッチ処理されていないインジェストによって生成される小さなデータ シャードを最適化するためにインジェスト後のリソースは必要ありません。
インジェスト前にバッチ処理を実行することの欠点は、強制的な遅延です。 したがって、データ インジェストを要求してからクエリに対するデータの準備が完了するまでの、エンド ツー エンドの時間が長くなります。
IngestionBatching ポリシーを定義するときは、スループットの最適化と遅延時間とのバランスを見つける必要があります。 このポリシーは、キューを使用するインジェストに適用されます。 小さい BLOB をまとめてバッチ処理するときに許容される最大の強制遅延を定義します。 バッチ処理ポリシー コマンドの使用およびスループットの最適化の詳細については、以下を参照してください。
バッチのシール
一括インジェストの場合は、約 1 GB の非圧縮データが最適なサイズです。 データ量が非常に少ない BLOB のインジェストは最適とは言えません。そのため、キューを使用するインジェストでは小さい BLOB がまとめてバッチ処理されます。
次の一覧は、バッチをシールするための基本的なバッチ処理ポリシーのトリガーを示しています。 最初の条件が満たされると、バッチがシールされ、取り込まれます。
Size: バッチ サイズの上限に達したか、超過していますCount: バッチ ファイル数の上限に達しましたTime: バッチ処理時間の有効期限が切れています
IngestionBatching ポリシーは、データベースまたはテーブルに設定できます。 既定値は次のとおりです。 5 分 最大遅延時間、 500 項目、 1 GB の合計サイズ。
重要
このポリシーを非常に小さな値に設定した場合の影響は、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 パラメーターを設定すると、データベースのスケーリングやシステム コンポーネントの内部リセットなどのために、システムによってデータがフラッシュされます。
既定値と制限
| Type | プロパティ | 既定値 | 低待機時間の設定 | 最小値 | 最大値 |
|---|---|---|---|---|---|
| 品目数 | MaximumNumberOfItems | 500 | 500 | 1 | 25,000 |
| データサイズ(MB) | MaximumRawDataSizeMB | 1024 | 1024 | 100 | 4096 |
| Time (TimeSpan) | MaximumBatchingTimeSpan | 00:05:00 | 00:00:20 - 00:00:30 | 00:00:10 | 00:30:00 |
インジェスト バッチ処理ポリシーを使用してエンドツーエンドの待機時間を制御する最も効果的な方法は、待機時間の要件の上限に従って、テーブルまたはデータベース レベルでその時間境界を変更することです。 データベース レベルのポリシーは、テーブル レベルのポリシーが定義されていないデータベース内のすべてのテーブルと、新しく作成されたテーブルに影響します。
重要
インジェスト バッチ処理ポリシーの時間境界を低イングレス テーブルで低く設定すると、データベースが新しく作成されたデータ シャードの最適化を試みる際に、追加のコンピューティングとストレージの作業が発生する可能性があります。 データ シャードの詳細については、エクステントに関する記事を参照してください。
バッチ データ サイズ
バッチ処理ポリシーのデータ サイズは、非圧縮データに対して設定されます。 Parquet、AVRO、ORC ファイルの場合、ファイル サイズに基づいて推定の計算が行われます。 圧縮データの場合、非圧縮データ サイズが次のように精度の降順に評価されます。
- インジェスト ソース オプションに圧縮されていないサイズが指定されている場合は、その値が使用されます。
- SDK を使用してローカル ファイルを取り込む場合は、zip アーカイブと gzip ストリームが検査され、生のサイズが評価されます。
- 上記のオプションでデータ サイズが指定されていない場合は、圧縮されたデータ サイズに係数を適用して、非圧縮データ サイズが推定されます。
バッチ処理の待機時間
待機時間は、多くの原因によって発生する可能性があり、バッチ処理ポリシー設定を使用して対処できます。
| 原因 | 解決策 |
|---|---|
データの待機時間が time 設定に一致し、データが少なすぎて size または count の制限に達しない |
time 制限を減らす |
| 非常に小さなファイルが多数あるために非効率的なバッチ処理 | ソース ファイルのサイズを大きくします。 Kafka シンクを使用する場合は、100 KB チャンク以上でデータを送信するように構成します。 小さいファイルが多数ある場合は、データベースまたはテーブルのインジェスト ポリシーで count を増やします (最大 2000)。 |
| 大量の非圧縮データのバッチ処理 | これは、Parquet ファイルを取り込む場合によくあります。 テーブルまたはデータベースのバッチ処理ポリシーの size を 250 MB に向かって徐々に減らし、改善されるかどうかを確認します。 |
| データベースのスケールが下がっているため、バックログ | データベースを拡大またはスケールアップするための Azure Advisor の提案を受け入れます。 または、データベースを手動でスケーリングして、バックログが閉じているかどうかを確認します。 これらのオプションが機能しない場合は、サポートにお問い合わせください。 |