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

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

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

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

実体化ビュー (Materialized View) の増分更新には、サーバレスパイプラインが必要です。

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

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

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

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

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 製品では、最後のクエリが実行された後にデータソースが変更されていない場合、セッション内またはセッション間で結果が自動的にキャッシュされます。自動キャッシュ動作は、実体化ビュー (Materialized View) とは異なります。

次の例では、このバッチクエリを具体化ビュー (Materialized View) に変換します。

CREATE OR REFRESH 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

マテリアライズド・ビューを更新すると、コンピュートの結果はバッチ・クエリ・セマンティクスと同一になります。このクエリは、増分更新が可能な具体化ビュー (Materialized View) の例です。つまり、更新操作では、ソースデータ内の新しいデータまたは変更されたデータのみを処理して結果をコンピュートするベストエフォート transactions_table 試みます。

実体化ビュー (Materialized View) のデータソースに関する考慮事項

マテリアライズドビューは任意のデータソースに対して定義できますが、すべてのデータソースがマテリアライズドビューに適しているわけではありません。次の注意事項と推奨事項を考慮してください。

重要

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

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

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

具体化されたビューの最適化

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

削除ベクトル
- 行追跡
- チェンジデータフィード

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

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

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

Full 更新

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

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

REFRESH MATERIALIZED VIEW mv_name FULL

Delta Live Tables パイプラインで定義されているマテリアライズドビューの場合、パイプライン内の選択したデータセットに対してフル更新を実行するか、すべてのデータセットに対してフル更新を実行するかを選択できます。「Delta Live Tables でテーブルとビューが更新される方法」を参照してください。

重要

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

注：

オプションで、テーブルプロパティの pipelines.reset.allowed を falseに設定することで、テーブルの完全更新を無効にすることができます。

増分更新

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

サーバレスパイプラインを使用して更新された実体化ビュー (Materialized View) のみが増分更新を使用できます。サーバレスパイプラインを使用しないマテリアライズドビューは、常に完全に更新されます。

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