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