構造化ストリーミングの運用に関する考慮事項
この記事には、Azure Databricks で構造化ストリーミングを使い、運用環境の増分処理ワークロードを構成して、リアルタイムまたはバッチ アプリケーションの待機時間とコストの要件を満たすための推奨事項が含まれています。 Azure Databricks での構造化ストリーミングの主要な概念を理解すると、データのボリュームと速度をスケールアップし、開発環境から運用環境に移行するときの、一般的な落とし穴を回避するのに役立ちます。
Azure Databricks では、構造化ストリーミング ワークロードに関する運用インフラストラクチャの管理の複雑さを軽減するために、Delta Live Tables が導入されています。 Databricks では、新しい構造化ストリーミング パイプラインに Delta Live Tables を使うことをお勧めします。「Delta Live Tables とは」をご覧ください。
注意
コンピューティングの自動スケールには、構造化ストリーミング ワークロードのクラスター サイズのスケールダウンに制限があります。 Databricks では、ストリーミング ワークロードに、拡張自動スケーリングを備えた Delta Live Tables を使用することをお勧めします。 「拡張自動スケーリングを使用して、Delta Live Tables パイプラインのクラスター使用率を最適化する」を参照してください。
構造化ストリーミング ワークロードにノートブックを使用する
Databricks ノートブックを使用した対話型開発では、クエリを手動で実行するために、ノートブックをクラスターにアタッチする必要があります。 ワークフローを使用して、自動デプロイとクエリ エラーからの自動復旧のために、Databricks ノートブックをスケジュールできます。
- ワークフローを使って構造化ストリーミングのクエリ エラーから復旧する
- Azure Databricks で構造化ストリーミング クエリを監視する
- 複数のストリーミング ワークロード用にスケジューラ プールを使用する
対話型の開発中に、または運用ワークロードの対話型監視のために、構造化ストリーミングのクエリをノートブックで視覚化できます。 運用環境では、人間がノートブックの出力を定期的に監視する場合にのみ、構造化ストリーミングのクエリを視覚化する必要があります。 trigger パラメーターと checkpointLocation パラメーターは省略可能ですが、ベスト プラクティスとして、Databricks ではそれらを常に実稼働環境で指定することをお勧めします。
Azure Databricks で構造化ストリーミングのバッチ サイズと頻度を制御する
Azure Databricks の構造化ストリーミングには、自動ローダーと Delta Lake を使用したストリーミング中のコストと待機時間の制御に役立つ強化されたオプションがあります。
ステートフル ストリーミングとは
"ステートフルな" 構造化ストリーミング クエリでは、中間状態情報の増分更新が必要です。一方、"ステートレスな" 構造化ストリーミング クエリでは、ソースからシンクに対して処理された行に関する情報のみが追跡されます。
ステートフル操作には、ストリーミングの集約、ストリーミングの dropDuplicates、ストリーム ストリーム結合、mapGroupsWithState、flatMapGroupsWithState が含まれます。
ステートフルな構造化ストリーミング クエリに必要な中間状態情報は、適切に構成されていない場合、予期しない待機時間と運用環境の問題につながる可能性があります。
Databricks Runtime 13.2 LTS 以降では、構造化ストリーミング ワークロードのチェックポイント期間とエンドツーエンドの待機時間を短縮するために、RockDB の変更ログのチェックポイント処理を有効にすることができます。 Databricks では、すべての構造化ストリーミング ステートフル クエリに対して変更ログのチェックポイント処理を有効にすることをお勧めします。 変更ログのチェックポイント処理を有効にするを参照してください。