トリガーされたパイプライン モードと連続パイプライン モード

この記事では、Delta Live Tables のトリガーされたパイプライン モードと継続的パイプライン モードの運用セマンティクスについて説明します。

パイプライン モードは、計算されるテーブルの種類に依存しません。 具体化されたビューとストリーミング テーブルの両方を、どちらのパイプライン モードでも更新できます。

トリガーと継続的の間で変更するには、パイプラインの作成または編集中にパイプライン設定で Pipeline モード オプションを使用します。 「 デルタ ライブ テーブル パイプラインを構成するを参照してください。

Note

Databricks SQL で定義されている具体化されたビューとストリーミング テーブルの更新操作は、常にトリガーされたパイプライン モードを使用して実行されます。

トリガーされるパイプライン モードとは

パイプラインが トリガー モードを使用している場合、システムは、すべてのテーブルまたは選択したテーブルを正常に更新した後に処理を停止し、更新の開始時に使用可能なデータに基づいて更新の各テーブルが更新されるようにします。

連続パイプライン モードとは

パイプラインで 継続的実行を使用する場合、新しいデータがデータ ソースに到着すると、データは Delta Live Tables によって処理され、パイプライン全体のテーブルが最新の状態に維持されます。

継続的実行モードで不要な処理を回避するために、パイプラインによって Delta 依存テーブルが自動的に監視され、それらの依存テーブルの内容が変更された場合にのみ更新が実行されます。

データ パイプライン モードを選択する

次の表は、トリガーされるパイプライン モードと連続パイプライン モードの違いを示しています。

主な質問	トリガー済み	継続的
更新が停止するタイミング	完了すると自動的に停止する。	手動で停止されるまで継続的に実行される。
処理対象のデータ	更新の開始時に使用できるデータ。	構成済みのソースに到着したすべてのデータ。
最適なデータ更新要件	10 分ごと、1 時間ごと、または毎日実行されるデータ更新。	データの更新は、10 秒から数分おきに行う必要があります。

トリガーされたパイプラインでは、クラスターの実行時間がパイプラインを更新するのに十分な時間しかないため、リソースの消費量とコストを削減できます。 ただし、新しいデータは、パイプラインがトリガーされるまで処理されません。 継続的パイプラインには、常に実行されているクラスターが必要であるため、コストは高くなりますが、処理の待機時間は短縮されます。

連続パイプラインのトリガー間隔を設定する

連続モード用にパイプラインを構成する場合は、トリガー間隔を設定して、パイプラインが各フローの更新を開始する頻度を制御できます。

pipelines.trigger.interval を使用してテーブルまたはパイプライン全体を更新するフローのトリガー間隔を制御できます。 トリガーされたパイプラインは各テーブルを 1 回処理するため、 pipelines.trigger.interval は連続パイプラインでのみ使用されます。

Databricks では、ストリーミング クエリとバッチ クエリの既定値が異なるため、個々のテーブルに pipelines.trigger.interval を設定することをお勧めします。 パイプライン グラフ全体の更新を制御する処理が必要な場合にのみ、パイプラインに値を設定します。

テーブルの pipelines.trigger.interval は、Python の spark_conf または SQL の SET を使用して設定します。

@dlt.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"
  }
}