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

備考

プレビュー

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

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

更新実行 on サーバレスコンピュート

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

Databricks SQLを使用して定義されたマテリアライズドビューの場合、ワークスペースでサーバレス Lakeflow 宣言型パイプラインを有効にする必要はありません。更新は、サーバレスパイプラインを使用して自動的に行われます。

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

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

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

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 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

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

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

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

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

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

これらの機能は、作成時または後で ALTER TABLE ステートメントを使用して設定できます。例えば：

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

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

マテリアライズドビューが更新されるときに、更新または完全更新を指定できます。

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

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

デフォルトの更新

サーバレス上のマテリアライズドビューのデフォルト更新は、 増分更新 を実行しようとします。増分更新では、前回の更新後に基になるデータの変更が処理され、そのデータがテーブルに追加されます。基本テーブルと含まれる操作によっては、特定のタイプのマテリアライズドビューのみを段階的に更新できます。増分更新が不可能な場合、または接続されているコンピュートがサーバレスではなくクラシックである場合は、完全な再計算が実行されます。

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

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

SQLウェアハウスまたはサーバレスLakeFlow宣言型パイプラインを使用してマテリアライズドビューを作成すると、クエリがサポートされている場合は、Databricks段階的に更新します。クエリでサポートされていない式が使用されている場合、Databricks は代わりに完全な再計算を実行するため、コストが増加する可能性があります。

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

フルリフレッシュ

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

Databricks SQLを使用して定義されたマテリアライズドビューで完全な更新を実行するには、次の構文を使用します。

SQL
REFRESH MATERIALIZED VIEW mv_name FULL

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

important

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