この記事では、パイプラインのトリガーモードと連続モードの運用セマンティクスについて説明します。
パイプライン モードは、計算されるテーブルの種類に依存しません。 具体化されたビューとストリーミング テーブルの両方を、どちらのパイプライン モードでも更新できます。
トリガーと継続的の間で変更するには、パイプラインの作成または編集中にパイプライン設定の [パイプライン モード ] オプションを使用します。 「 パイプラインの構成」を参照してください。
注
Databricks SQL で定義されている具体化されたビューとストリーミング テーブルの更新操作は、常にトリガーされたパイプライン モードを使用して実行されます。
トリガーされるパイプライン モードとは
パイプラインでトリガー モード が使用されている 場合、システムは、すべてのテーブルまたは選択したテーブルを正常に更新した後に処理を停止し、更新の開始時に使用可能なデータに基づいて更新の各テーブルが更新されるようにします。
連続パイプライン モードとは
パイプラインで 継続的 な実行が使用されている場合、Lakeflow Spark 宣言パイプラインは、データ ソースに到着した新しいデータを処理して、パイプライン全体のテーブルを最新の状態に保ちます。
継続的実行モードでの不要な処理を回避するために、パイプラインは依存する Delta テーブルを自動的に監視し、それらの依存テーブルの内容が変更された場合にのみ更新を実行します。
データ パイプライン モードを選択する
次の表は、トリガーされるパイプライン モードと連続パイプライン モードの違いを示しています。
| 主な質問 | トリガー済み | 継続的 |
|---|---|---|
| 更新はいつ停止しますか? | 完了すると自動的に実行されます。 | 手動で停止するまで継続的に実行されます。 |
| 処理されるデータ | 更新の開始時に使用できるデータ。 | 構成済みのソースに到着するすべてのデータ。 |
| この最適なデータ更新要件は何ですか? | データ更新は、10 分ごと、1 時間ごと、または毎日実行されます。 | データの更新は、10 秒から数分おきに行う必要があります。 |
トリガーされたパイプラインでは、クラスターの実行時間がパイプラインを更新するのに十分な時間しかないため、リソースの消費量とコストを削減できます。 ただし、パイプラインがトリガーされるまで、新しいデータは処理されません。 継続的なパイプラインには、常に実行されるクラスターが必要です。これはコストが高くなりますが、処理の待機時間が短縮されます。
連続パイプラインのトリガー間隔を設定する
連続モード用にパイプラインを構成する場合は、トリガー間隔を設定して、パイプラインが各フローの更新を開始する頻度を制御できます。
pipelines.trigger.intervalを使用して、テーブルまたはパイプライン全体を更新するフローのトリガー間隔を制御できます。 トリガーされたパイプラインは各テーブルを 1 回処理するため、 pipelines.trigger.interval は連続パイプラインでのみ使用されます。
Databricks では、ストリーミング クエリとバッチ クエリの既定値が異なるため、個々のテーブルに pipelines.trigger.interval を設定することをお勧めします。 パイプライン グラフ全体の更新を制御する処理が必要な場合にのみ、パイプラインに値を設定します。
テーブルの pipelines.trigger.interval は、Python の spark_conf または SQL の SET を使用して設定します。
@dp.table(
spark_conf={"pipelines.trigger.interval" : "10 seconds"}
)
def <function-name>():
return (<query>)
SET pipelines.trigger.interval=10 seconds;
CREATE OR REFRESH MATERIALIZED VIEW TABLE_NAME
AS SELECT ...
パイプラインに pipelines.trigger.interval を設定するには、パイプライン設定の configuration オブジェクトに追加します。
{
"configuration": {
"pipelines.trigger.interval": "10 seconds"
}
}