マテリアライズドビューの増分更新

この記事では、マテリアライズドビューでの増分更新のセマンティクスと要件の概要を説明し、増分更新をサポートする SQL 操作、キーワード、および句を特定します。増分更新と完全更新の違いの説明や、マテリアライズドビューとストリーミングテーブルのどちらを選択するかについての推奨事項が含まれています。

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

サーバレスパイプラインは増分更新に必要です

マテリアライズドビューの増分更新には、サーバレスパイプラインが必要です。

Databricks SQL で定義されているマテリアライズドビューの更新操作は、常にサーバレスパイプラインを使用して実行されます。

DLT パイプラインを使用して定義されたマテリアライズドビューの場合、サーバレスを使用するようにパイプラインを構成する必要があります。サーバレス DLT パイプラインの設定を参照してください。

マテリアライズドビューの更新セマンティクスは何ですか?

マテリアライズドビューは、バッチクエリと同等の結果を保証します。たとえば、次の集計クエリについて考えてみます。

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

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

注記

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

次の例では、このバッチクエリをマテリアライズドビューに変換します。

SQL
CREATE OR REPLACE MATERIALIZED VIEW transation_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

マテリアライズドビューは、サポートされている操作の結果を段階的に更新するためのベストエフォート型の試みを行います。データソースの一部の変更には、完全な更新が必要です。

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

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

マテリアライズドビューを最適化します

最高のパフォーマンスを得るために、Databricks では、すべてのマテリアライズドビューソーステーブルで次の機能を有効にすることをお勧めします。

削除ベクトル
- 行トラッキング
- チェンジデータフィード

マテリアライズドビューの更新タイプ

マテリアライズド・ビューへの更新は、フルまたはインクリメンタルのいずれかです。すべての操作で、増分更新と完全更新の結果は同じです。 Databricks 、コスト分析を実行して、データソースへの変更に完全な更新が必要かどうかを特定します。

更新プログラムで使用された更新の種類を確認するには、「更新プログラムの更新の種類を確認する」を参照してください。

フルリフレッシュ

フルリフレッシュでは、ソースで使用可能なすべてのデータが再処理され、マテリアライズドビューの結果が上書きされます。すべてのマテリアライズドビューは、データソースがどのように変更されたかに応じて、特定の更新時に完全に更新される場合があります。

必要に応じて、フルリフレッシュを強制できます。 Databricks SQL を使用して定義されたのマテリアライズドビューの場合は、次の構文を使用します。

SQL
REFRESH MATERIALIZED VIEW mv_name FULL

DLT パイプラインで定義されているマテリアライズドビューの場合、選択したデータセットに対して完全更新を実行するか、パイプライン内のすべてのデータセットに対して完全更新を実行するかを選択できます。パイプラインの更新セマンティクスを参照してください。

important

データ保持しきい値または手動削除によりレコードが削除されたデータソースに対してフルリフレッシュを実行した場合、削除されたレコードはコンピュートの結果に反映されません。ソースでデータが使用できなくなった場合、古いデータを回復できない場合があります。

注記

オプションで、テーブルプロパティの pipelines.reset.allowed を falseに設定することで、テーブルのフルリフレッシュを無効にすることができます。

増分更新

増分更新では、前回の更新後に基になるデータの変更が処理され、そのデータがテーブルに追加されます。ベース・テーブルと含まれる操作によっては、特定のタイプのマテリアライズド・ビューのみを増分的に更新できます。

サーバレスパイプラインを使用して更新されたマテリアライズドビューのみが増分更新を使用できます。サーバレスパイプラインを使用しないマテリアライズドビューは、常にフルリフレッシュされます。

マテリアライズドビューを SQLウェアハウスまたはサーバレス DLT パイプラインを使用して作成する場合、クエリがサポートされている場合は自動的に増分更新されます。増分更新でサポートされていない式がクエリに含まれている場合、フルリフレッシュが実行されるため、追加コストが発生する可能性があります。