具体化されたビューの増分更新

この記事では、具体化されたビューでの増分更新のセマンティクスと要件の概要を説明し、増分更新をサポートする SQL 操作、キーワード、句を特定します。増分更新と完全更新の違いについて説明し、具体化されたビューとストリーミングテーブルを選択するための推奨事項が含まれています。

サーバーレスパイプラインを使用して具体化されたビューで更新を実行する場合、多くのクエリを増分更新できます。増分更新では、具体化されたビューの定義に使用されるデータソースの変更を検出し、結果を増分計算することで、コンピューティングコストを節約できます。

サーバーレスコンピューティング実行されます

更新操作は、Databricks SQL で定義されたか、Lakeflow 宣言パイプラインを使用して定義されたかに関係なく、サーバーレスパイプラインで実行されます。

Databricks SQL を使用して定義された具体化されたビューの場合、サーバーレスの Lakeflow 宣言パイプラインに対してワークスペースを有効にする必要はありません。更新では、サーバーレスパイプラインが自動的に使用されます。

Lakeflow 宣言型パイプラインを使用して定義された具体化されたビューの場合は、サーバーレスを使用するようにパイプラインを構成する必要があります。サーバーレスパイプラインの構成を参照してください。

具体化されたビューの更新セマンティクスとは

具体化されたビューでは、バッチクエリと同等の結果が保証されます。たとえば、次の集計クエリを考えます。

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Azure Databricks 製品を使用してこのクエリを実行すると、結果はバッチセマンティクスを使用して計算され、ソース transactions_table 内のすべてのレコードが集計されます。つまり、すべてのソースデータが 1 回の操作でスキャンおよび集計されます。

Note

一部の Azure Databricks 製品では、最後のクエリの実行後にデータソースが変更されていない場合、セッション内またはセッション間で結果が自動的にキャッシュされます。自動キャッシュ動作は、具体化されたビューとは異なります。

次の例では、このバッチクエリを具体化されたビューに変換します。

CREATE OR REPLACE MATERIALIZED VIEW transaction_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

具体化されたビューを更新すると、計算結果はバッチクエリセマンティクスと同じです。このクエリは、段階的に更新できる具体化されたビューの例です。つまり、更新操作では、ソース transactions_table 内の新しいデータまたは変更されたデータのみを処理して結果を計算しようとするベストエフォート型の試行が行われます。

具体化されたビューのデータソースに関する考慮事項

具体化されたビューは任意のデータソースに対して定義できますが、すべてのデータソースが具体化されたビューに適しているわけではありません。次の注意事項と推奨事項を検討してください。

Important

具体化されたビューでは、サポートされている操作の結果を増分更新するためにベストエフォート型の試行が行われます。データソースの一部の変更には、完全な更新が必要です。

具体化されたビューを定義するクエリで増分更新がサポートされている場合でも、具体化されたビューのすべてのデータソースは、完全な更新セマンティクスに対して堅牢である必要があります。

完全更新がコストの高いクエリの場合は、ストリーミングテーブルを使用して 1 回だけ処理を保証します。たとえば、非常に大きなテーブルがあります。
レコードを 1 回だけ処理する必要がある場合は、データソースに対して具体化されたビューを定義しないでください。代わりに、ストリーミングテーブルを使用します。次のような例があります。
- Kafka など、データ履歴を保持しないデータソース。
- 自動ローダーを使用してクラウドオブジェクトストレージからデータを取り込むクエリなどの取り込み操作。
- 処理後にデータを削除またはアーカイブするが、ダウンストリームテーブルに情報を保持する必要があるデータソース。たとえば、特定のしきい値より古いレコードを削除する予定の日付パーティションテーブルなどです。
すべてのデータソースが増分更新をサポートしているわけではありません。次のデータソースでは、増分更新がサポートされています。
- Delta Lake によってサポートされる Unity Catalog マネージドテーブルと外部テーブルを含む Delta テーブル。
- 具体化されたビュー。
- AUTO CDC ... INTO 操作のターゲットを含むストリーミングテーブル。
一部の増分更新操作では、クエリ対象のデータソースで行追跡を有効にする必要があります。行追跡は Delta テーブルでのみサポートされる Delta Lake 機能であり、具体化されたビュー、ストリーミングテーブル、Unity Catalog マネージドテーブルが含まれます。「Delta テーブルの行追跡の使用」を参照してください。

具体化されたビューを最適化する

最適なパフォーマンスを得るために、Databricks では、すべての具体化されたビューソーステーブルで次の機能を有効にすることをお勧めします。

これらの機能は、作成時に設定することも、後で ALTER TABLE ステートメントを使用して設定することもできます。例えば次が挙げられます。

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

具体化されたビューの更新の種類

具体化されたビューを更新する場合は、更新または完全更新を指定できます。

更新では増分更新が試行されますが、必要に応じてデータの完全な再計算が実行されます。増分更新は、接続先のコンピューティングがサーバーレスの場合にのみ使用できます。
完全更新では、マテリアライズドビューへのすべての入力が常に再計算され、すべてのチェックポイントがリセットされます。

更新プログラムが使用する更新の種類を確認するには、更新プログラムの更新の種類の決定に関するページを参照してください。

既定のリフレッシュ

サーバーレスでの具体化されたビューの既定の更新では、増分更新を試みます。増分更新では、最後の更新より後に基のデータで行われた変更が処理されて、そのデータがテーブルに追加されます。ベーステーブルと含まれる操作によっては、特定の種類の具体化されたビューのみを増分更新できます。増分更新ができない場合、または接続されたコンピューティングがサーバーレスではなくクラシックである場合は、完全な再計算が実行されます。

増分更新と完全な再計算の出力は同じです。 Azure Databricks はコスト分析を実行して、増分更新と完全な再計算の間で安価なオプションを選択します。

増分更新を使用できるのは、サーバーレスパイプラインを使用して更新された具体化されたビューのみです。サーバーレスパイプラインを使用しない具体化されたビューは、常に完全に再計算されます。

SQL ウェアハウスまたはサーバーレスの Lakeflow 宣言パイプラインを使用して具体化されたビューを作成すると、クエリがサポートされている場合、Azure Databricks によって増分更新されます。クエリでサポートされていない式が使用されている場合、Azure Databricks では代わりに完全な再計算が実行されるため、コストが増加する可能性があります。

更新プログラムが使用する更新の種類を確認するには、更新プログラムの更新の種類の決定に関するページを参照してください。

完全更新

完全更新では、テーブルとチェックポイントをクリアし、ソースで使用可能なすべてのデータを再処理することで、具体化されたビューの結果が上書きされます。

Databricks SQL を使用して定義された具体化されたビューに対して完全な更新を実行するには、次の構文を使用します。

REFRESH MATERIALIZED VIEW mv_name FULL

Lakeflow 宣言型パイプラインで定義された具体化されたビューの場合、選択したデータセットまたはパイプライン内のすべてのデータセットに対して完全な更新を実行することを選択できます。「パイプライン更新セマンティクス」をご覧ください。

Important

データ保持のしきい値または手動による削除によってレコードが削除されたデータソースに対して完全な更新が実行された場合、削除されたレコードは計算結果に反映されません。ソースでデータが使用できなくなった場合、古いデータを回復できないことがあります。また、ソースデータに存在しなくなった列のスキーマも変更される可能性があります。