構造化ストリーミングの運用に関する考慮事項

この記事には、リアルタイム アプリケーションまたはバッチ アプリケーションの待機時間とコストの要件を満たすために、Databricks の構造化ストリーミングを使用して運用増分処理ワークロードを構成するための推奨事項が含まれています。 Databricks での構造化ストリーミングの主要な概念を理解することで、データの量と速度をスケールアップし、開発から運用に移行する際の一般的な落とし穴を回避できます。

Databricks では、構造化ストリーミング ワークロードの運用インフラストラクチャの管理の複雑さを軽減するための Delta Live Tables が導入されました。 Databricks では、新しい構造化ストリーミング パイプラインに Delta Live Tables を使用することをお勧めします。「 Delta Live Tablesとは」を参照してください。

注

コンピュートの自動スケーリングには、構造化ストリーミング ワークロードのクラスター サイズをスケールダウンする制限があります。 Databricks 、ストリーミング ワークロードに拡張オートスケールを備えたDelta Live Tablesを使用することをお勧めします。 「拡張オートスケールDelta Live Tables Pipeline のクラスター使用率を最適化する」を参照してください。

構造化ストリーミング ワークロードでのノートブックの使用

Databricks ノートブックを使用した対話型開発では、クエリーを手動で実行するために、ノートブックをクラスターにアタッチする必要があります。 ワークフローを使用して、自動デプロイとクエリー障害からの自動回復のために Databricks ノートブック をスケジュールできます。

構造化ストリーミングクエリーは、対話型の開発中にノートブックで視覚化したり、運用ワークロードを対話型に監視したりできます。 構造化ストリーミングクエリーを運用環境で視覚化するのは、人間がノートブックの出力を定期的に監視する場合のみにしてください。 trigger パラメーターと checkpointLocation パラメーターは省略可能ですが、ベスト プラクティスとして、Databricks では 運用環境で常に 指定することをお勧めします。

Databricks での構造化ストリーミングのバッチサイズと頻度の制御

Databricks での構造化ストリーミングでは、 Auto Loader と Delta Lake を使用したストリーミング中にコストと待機時間を制御するのに役立つオプションが強化されています。

ステートフルストリーミングとは何ですか?

ステート フル な構造化ストリーミング クエリーでは、中間状態情報の増分更新が必要ですが、 ステートレス な構造化ストリーミング クエリーは、ソースからシンクまで処理された行に関する情報のみを追跡します。

ステートフル操作には、ストリーミング集約、ストリーミング dropDuplicates、ストリームとストリームの結合、 mapGroupsWithState、および flatMapGroupsWithStateが含まれます。

ステートフルな構造化ストリーミング クエリーに必要な中間状態情報は、適切に構成されていないと、予期しない待機時間や運用上の問題を引き起こす可能性があります。

Databricks Runtime 13.3 LTS 以降では、RocksDB を使用して変更ログのチェックポイントを有効にし、構造化ストリーミング ワークロードのチェックポイントの期間とエンドツーエンドの待機時間を短縮できます。 Databricks では、すべての構造化ストリーミング ステートフル クエリに対して変更ログ チェックポイントを有効にすることをお勧めします。 「 変更ログのチェックポイントを有効にする」を参照してください。