このページでは、アドミッション 制御を使用して、ストリーミング クエリの一貫したバッチ サイズを維持する方法について説明します。
アドミッション 制御では、構造化ストリーミング クエリの入力速度が制限されます。これにより、一貫性のあるバッチ サイズを維持し、大規模なバッチによってスピルやマイクロバッチ処理の遅延が連鎖するのを防ぐことができます。
Azure Databricks には、Delta Lake と自動ローダーの両方の構造化ストリーミング バッチ サイズを制御するための同じオプションが用意されています。
注
ストリーミング クエリのチェックポイントをリセットせずに、アドミッション制御の設定を変更できます。 「構造化ストリーミング クエリの変更後に復旧する」を参照してください。
バッチ サイズを増減するようにアドミッション制御設定を変更すると、パフォーマンスに影響があります。 ワークロードを最適化するには、コンピューティング構成の調整が必要になる場合があります。
Warnung
ストリームが停止したときにマイクロバッチが計画されている場合、計画されたマイクロバッチが完了するまで、アドミッション制御に対する変更は有効になりません。 たとえば、失敗したトランザクションの後にストリームが停止した場合は、チェックポイントを削除して、新しいアドミッション コントロールを使用してストリームでトランザクションの再処理を強制する必要がある場合があります。 この動作は、Structured Streaming が冪等性を持ち、繰り返し実行時にマイクロバッチは同じデータを含める必要があるために発生します。 構造化ストリーミング セマンティクスを参照してください。
maxFilesPerTrigger で入力速度を制限する
設定 maxFilesPerTrigger (自動ローダーの場合は cloudFiles.maxFilesPerTrigger) によって、マイクロバッチごとに処理されるファイル数の上限が指定されます。
maxBytesPerTrigger で入力速度を制限する
設定 maxBytesPerTrigger (または cloudFiles.maxBytesPerTrigger 自動ローダーの場合) によって、マイクロバッチごとに処理されるデータ量の "ソフト最大値" が設定されます。 これは、最小の入力単位がこの制限を超える場合にストリーミング クエリを進めるために、バッチでほぼこの量のデータが処理され、制限を超える処理が行われる可能性があることを意味します。 この設定の既定値はありません。
たとえば、各マイクロバッチを 10 GB のデータに制限するバイト文字列 (10g など) を指定するとき、ファイルにそれぞれ 3 GB が与えられている場合、Azure Databricks では、1 回のマイクロバッチで 12 GB が処理されます。
複数の入力速度をまとめて設定する
maxBytesPerTrigger との連動で maxFilesPerTrigger を使用する場合、maxFilesPerTrigger または maxBytesPerTrigger の下限に到達するまでマイクロバッチによってデータが処理されます。
他の構造化ストリーミング ソースの入力速度の制限
Apache Kafka などのストリーミング ソースには、maxOffsetsPerTrigger のようなカスタム入力制限があります。 詳細については、「 SQLとSpark APIで取り込む」をご覧ください。