パイプラインはどのように更新されますか?

パイプラインの更新が実行されると、パイプラインで定義されている具体化されたビューとストリーミング テーブルが更新され、結果にソース データの現在の状態が反映されます。 データセットの更新方法は、その種類と更新の種類によって異なります。 更新プログラムをトリガーして管理する方法については、「 パイプラインの更新を実行する」を参照してください。

更新の種類

既定では、パイプライン内のすべての具体化されたビューとストリーミング テーブルは、更新ごとに更新されます。 次の表は、各更新の種類の動作をまとめたものです。

更新 (既定値)

既定の更新では、データセットが更新され、定義クエリの現在の結果が反映されます。

ストリーミング テーブルは本質的に増分型です。 ストリーミング テーブルの更新では、前回の更新以降に到着したレコードのみが評価され、テーブルの現在の定義を使用して追加されます。 古いレコードは再処理されないため、既に書き込まれたデータに影響を与える変更は適用されません。 言い換えると、ストリーミング テーブルの既定の更新では、データの正確性が低下し、リソース コストが削減されます。 古いデータを再処理するには、フル 更新を実行するか、フロー チェックポイントをリセットします。

具体化されたビューは増分更新を試みますが、必要に応じてすべてのレコードを再処理して、テーブルを完全に正確に保ちます。 具体化されたビューは、次の 2 つの方法のいずれかを使用して更新されます。

• 増分更新 では、前回の更新以降の変更が識別され、新規または変更されたデータのみがマージされます。
• 完全更新 では、クエリ全体が実行され、増分更新が不可能またはコスト効率が高くない場合に、既存のデータが置き換えられます。

既定では、Azure Databricksはコスト モデルを使用して、よりコスト効率の高い方法を選択します。 この選択は、更新ポリシーでオーバーライドできます。 増分更新のセマンティクス、要件、およびサポートされている SQL については、 具体化されたビューの増分更新に関するページを参照してください。

完全更新

完全更新では、データセットを定義するロジックを使用して、ソース データからのすべてのレコードが再処理されます。

• 具体化されたビューの場合、完全更新によって結果全体が再計算されます。 具体化されたビューは常にバッチ クエリと同じ結果を返すので、既定の更新と完全更新では同じデータが生成されます。
• ストリーミング テーブルの場合、完全更新によってテーブルが切り捨てられ、フローのストリーミング チェックポイントがクリアされ、ソースからすべてのレコードが再処理されます。

完全更新ではすべてのソース データが再処理されるため、時間とコストは、そのデータのサイズに応じてスケーリングされます。 Databricks では、定義やスキーマの変更が既存のデータと互換性がない場合など、必要な場合にのみ完全更新を実行することをお勧めします。 ストリーミング テーブルを完全に更新すると、ソースが元のデータを保持しなくなった場合 (たとえば、Kafka トピックが保持期間を過ぎた場合など)、レコードを削除できます。

ストリーミング テーブルの完全更新を実行するタイミングと方法については、「ストリーミング テーブルの 完全更新」を参照してください。

チェックポイントのリセット

チェックポイントのリセットは、ストリーミング テーブルにのみ適用されます。 ストリーミング テーブルに既に書き込まれているデータをクリアせずに、選択したフローのストリーミング チェックポイントをクリアし、それらのフローを介してソースからすべてのレコードを再処理します。 完全更新とは異なり、既存のテーブル データは保持されます。

テーブルを切り捨てずに、フローのロジックを変更した後など、選択したフローのストリーミング ソースを再処理する場合に使用します。

チェックポイントのリセットは、Lakeflow パイプライン REST API を使用してトリガーされます。 手順については、「 パイプラインの更新を開始して、選択的ストリーミング フローのチェックポイントをクリアする」を参照してください。

その他のリソース

• パイプラインの更新を実行する
• マテリアライズドビューの増分更新
• ストリーミング テーブルの完全更新