Databricks SQLでマテリアライズドビューを使用する

この記事ではDatabricks SQLでマテリアライズドビューを作成および更新して、パフォーマンスを向上させ、データ処理と分析のワークロードのコストを削減する方法について説明します。

マテリアライズドビューとは何ですか？

Databricks SQLでは、マテリアライズドビューは、クエリの結果を物理的に保存するUnity Catalogマネージドテーブルです。オンデマンドで結果をコンピュートする標準ビューとは異なり、マテリアライズドビューは結果をキャッシュし、基になるソーステーブルの変更に応じてスケジュールに従ってまたは自動的に更新します。

マテリアライズドビューは、抽出、変換、ロード ( ETL ) 処理などのデータ処理ワークロードに適しています。マテリアライズドビューは、コンプライアンス、修正、集計、または一般的な変更データキャプチャ ( CDC ) のデータを処理するためのシンプルで宣言的な方法を提供します。マテリアライズドビューでは、ベーステーブルのクリーニング、強化、非正規化により、使いやすい変換も可能になります。マテリアライズドビューは、高価なクエリや頻繁に使用されるクエリを事前に計算することで、クエリのレイテンシとリソース消費を削減します。多くの場合、ソーステーブルから変更を段階的にコンピュートすることができ、効率とエンドユーザーエクスペリエンスがさらに向上します。

マテリアライズドビューの一般的な使用例は次のとおりです。

エンドユーザーのクエリ遅延を最小限に抑えながら、BI ダッシュボードを最新の状態に保ちます。
シンプルなSQLロジックで複雑なETLオーケストレーションを削減します。
複雑で階層化された変換を構築します。
最新の知見や常に安定したパフォーマンスが求められるユースケース。

Databricks SQLウェアハウスでマテリアライズドビューを作成すると、マテリアライズドビューの作成と更新を処理するためのサーバレスパイプラインが作成されます。カタログエクスプローラーで更新操作のステータスを監視できます。DESCRIBE EXTENDEDで詳細を表示を参照してください。

要件

Databricks SQLで作成されたマテリアライズドビューは、サーバレスパイプラインによってサポートされています。この機能を使用するには、ワークスペースがサーバレスパイプラインをサポートしている必要があります。

マテリアライズドビューを作成または更新するための要件:

Unity Catalog 対応の Pro またはサーバレスSQLウェアハウスを使用する必要があります。
マテリアライズドビューを更新するには、それを作成したワークスペースにいる必要があります。
Deltaテーブルからマテリアライズドビューを段階的に更新するには、ソーステーブルで行追跡が有効になっている必要があります。
所有者 (マテリアライズドビューを作成するユーザー) には次の権限が必要です。
- SELECT マテリアライズドビューによって参照される実表に対する権限。
- USE CATALOG マテリアライズドビューのソーステーブルを含むカタログとスキーマに対するUSE SCHEMA権限。
- USE CATALOG マテリアライズドビューのターゲットカタログとスキーマに対するUSE SCHEMA権限。
- CREATE TABLE マテリアライズドビューを含むスキーマに対するCREATE MATERIALIZED VIEW権限。
マテリアライズドビューを更新するには、マテリアライズドビューに対するREFRESH権限が必要です。
ワークスペースは、サーバレスSQLウェアハウスをサポートするリージョンにある必要があります。
サーバレスの利用規約に同意しておく必要があります。

マテリアライズドビューをクエリするための要件:

マテリアライズドビューの所有者であるか、マテリアライズドビューにSELECTとその親のUSE SCHEMAおよびUSE CATALOGを持っている必要があります。
次のコンピュートリソースのいずれかを使用する必要があります。
- SQLウェアハウス
- Lakeflow Spark宣言型パイプラインインターフェイス
- 標準アクセスモードコンピュート (以前の共有アクセスモード)
- Databricks Runtime 15.4 以降の専用アクセスモード (旧シングルユーザーアクセスモード) (ワークスペースがサーバレスコンピュートに対して有効になっている場合)。専用コンピュートでのきめ細かなアクセス制御を参照してください。
  
  マテリアライズドビューの所有者の場合は、14.3 以降のDatabricks Runtimeを実行している専用アクセスモードのコンピュートリソースを使用できます。

具体化されたビューの使用に関するその他の制限については、制限事項を参照してください。

マテリアライズドビューの作成

Databricks SQLマテリアライズドビューCREATEオペレーションは、 Databricks SQLウェアハウスを使用してマテリアライズドビューにデータを作成し、読み込みます。マテリアライズドビューの作成は同期操作です。つまり、マテリアライズドビューが作成され、初期データの読み込みが完了するまで、 CREATE MATERIALIZED VIEWコマンドはブロックされます。サーバレスパイプラインは、 Databricks SQLマテリアライズドビューごとに自動的に作成されます。マテリアライズドビューが更新されると、パイプラインが更新を処理します。

マテリアライズドビューを作成するには、 CREATE MATERIALIZED VIEWステートメントを使用します。作成ステートメントを送信するには、Databricks UI の SQL エディター、 Databricks SQL CLI 、またはDatabricks SQL APIを使用します。

マテリアライズドビューを作成したユーザーがマテリアライズドビューの所有者となります。

次の例では、ベーステーブルbase_table1からマテリアライズドビューmv1を作成します。

SQL
-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

CREATE OR REPLACE MATERIALIZED VIEWステートメントを使用してマテリアライズドビューを作成すると、初期データの更新と作成がすぐに開始されます。これはSQLウェアハウスコンピュートを消費しません。代わりに、サーバレスパイプラインが作成とその後の更新に使用されます。

ベーステーブルの列コメントは、作成時にのみ新しいマテリアライズドビューに自動的に伝播されます。スケジュール、テーブル制約、またはその他のプロパティを追加するには、マテリアライズドビュー定義 ( SQLクエリ) を変更します。

同じSQLステートメントは、次回またはスケジュールに従って呼び出された場合、マテリアライズドビューを更新します。この方法で実行された更新は、他の更新と同じように機能します。詳細については、「マテリアライズドビューの更新」を参照してください。

マテリアライズドビューの構成の詳細については、 Databricks SQLでのマテリアライズドビューの構成」を参照してください。マテリアライズドビューを作成するための完全な構文については、 CREATE MATERIALIZED VIEWを参照してください。さまざまな形式や場所からデータをロードする方法については、「パイプラインでデータをロードする」を参照してください。

外部システムからデータを読み込む

マテリアライズドビューは、サポートされているデータソースに対してレイクハウスフェデレーションを使用して外部データ上に作成できます。レイクハウスフェデレーションでサポートされていないソースからのデータの読み込みについては、「データ形式オプション」を参照してください。例を含むデータのロードに関する一般情報については、「パイプラインでのデータのロード」を参照してください。

機密データを非表示にする

マテリアライズドビューを使用すると、テーブルにアクセスするユーザーから機密データを非表示にすることができます。これを行う 1 つの方法は、最初からそのデータを含まないようにクエリを作成することです。ただし、クエリを実行するユーザーの権限に基づいて列をマスクしたり、行をフィルター処理したりすることもできます。たとえば、グループHumanResourcesDeptに属していないユーザーに対してtax_id列を非表示にすることができます。これを行うには、マテリアライズドビューの作成時にROW FILTERおよびMASK構文を使用します。詳細については、「行フィルターと列マスク」を参照してください。

マテリアライズドビューを更新する

マテリアライズドビューを更新すると、ビューが更新され、更新時のベーステーブルへの最新の変更が反映されます。

マテリアライズドビューを定義する場合、 CREATE OR REPLACE MATERIALIZED VIEWステートメントはビューの作成と、スケジュールされた更新の両方に使用されます。 REFRESH MATERIALIZED VIEWステートメントを使用して、クエリを再度指定することなくマテリアライズドビューを更新することもできます。このコマンドのSQL構文とパラメーターの詳細については、REFRESH ( MATERIALIZED VIEWまたはSTREAMING TABLE )を参照してください。増分更新できるマテリアライズドビューのタイプの詳細については、マテリアライズドビューの増分更新を参照してください。

更新ステートメントを送信するには、Databricks UI のSQLエディター、SQL ウェアハウスにアタッチされたノートブック、Databricks SQL CLI、またはDatabricks SQL API を使用します。

所有者、およびテーブルに対するREFRESH権限を付与されているユーザーは、マテリアライズドビューを更新できます。

次の例では、 mv1マテリアライズドビューを更新します。

SQL
REFRESH MATERIALIZED VIEW mv1;

デフォルトでは操作は同期的であり、更新操作が完了するまでコマンドはブロックされます。非同期的に更新するには、 ASYNCキーワードを追加します。

SQL
REFRESH MATERIALIZED VIEW mv1 ASYNC;

Databricks SQLマテリアライズドビューはどのように更新されますか?

マテリアライズドビューは、更新操作を処理するためにサーバレスパイプラインを自動的に作成および使用します。更新はパイプラインによって管理され、更新はマテリアライズドビューの作成に使用されるDatabricks SQLウェアハウスによって監視されます。マテリアライズドビューは、スケジュールに従って実行するパイプラインを使用して更新できます。 Databricks SQLで作成されたマテリアライズドビューは、常にトリガーモードで実行されます。トリガーされたパイプラインモードと継続的なパイプラインモードを参照してください。

マテリアライズドビューは、2 つの方法のいずれかを使用して更新されます。

増分更新 - システムはビューのクエリを評価して、最後の更新後に発生した変更を識別し、新しいデータまたは変更されたデータのみをマージします。
完全更新 - 増分更新が実行できない場合、またはコスト効率が悪い場合、システムはクエリ全体を実行し、マテリアライズドビュー内の既存のデータを新しい結果に置き換えます。

クエリの構造とソースデータの種類によって、増分更新がサポートされるかどうかが決まります。増分更新をサポートするには、行追跡と変更データフィードを有効にして、ソースデータをDeltaテーブルに保存する必要があります。クエリが増分可能かどうかを確認するには、Databricks SQL EXPLAIN CREATE MATERIALIZED VIEWステートメントを使用します。マテリアライズドビューを作成した後、その更新動作を監視して、段階的に更新されるか完全な更新によって更新されるかを確認できます。

デフォルトでは、Databricks はコストモデルを使用して、完全更新と増分更新の間でよりコスト効率の高いオプションを選択します。マテリアライズドビューのSQL定義でREFRESH POLICYを設定することで、この動作をオーバーライドして増分更新または完全更新を優先できます。

更新タイプの詳細と増分更新の最適化方法については、「マテリアライズドビューの増分更新」を参照してください。

非同期更新

デフォルトでは、更新操作は同期的に実行されます。更新操作を非同期的に実行するように設定することもできます。これは、更新コマンドでASYNCキーワードを使用して設定できます。 REFRESH (MATERIALIZED VIEW または STREAMING TABLE)を参照してください。それぞれのアプローチに関連する動作は次のとおりです。

同期: 同期更新は、更新が完了するまで他の操作を続行できません。Lakeflow ジョブなどのオーケストレーションツールで更新操作を順序付ける場合など、次の手順で結果が必要な場合は、同期更新を使用します。ジョブを使用してマテリアライズドビューを調整するには、 SQL タスクの種類を使用します。Lakeflowジョブを参照してください。
非同期 : 非同期更新は、マテリアライズドビューの更新が開始されるときに、サーバーレスコンピュートでバックグラウンドジョブを開始し、データのロードが完了する前にコマンドが戻ることができるようにします。この更新タイプは、コマンドが開始されるウェアハウスでの操作が必ずしもコンピュート容量を保持する必要がないため、コストを節約できます。更新がアイドル状態になり、他のタスクが実行されていない場合、更新が他の利用可能なコンピュートを使用している間、ウェアハウスはシャットダウンできます。さらに、非同期更新では複数の操作を並行して開始することがサポートされます。

マテリアライズドビュー更新のスケジュール

Databricks SQLマテリアライズドビューは、定義されたスケジュールに基づいて自動的に更新されるように、またはアップストリームデータが変更されたときにトリガーされるように構成できます。次の表は、更新をスケジュールするためのさまざまなオプションを示しています。

手法	説明	使用例
手動	SQL `REFRESH`ステートメントまたはワークスペース UI を使用したオンデマンド更新。	開発、テスト、アドホック更新。
`TRIGGER ON UPDATE`	上流のデータが変更されたときに自動的に更新されるようにマテリアライズドビューを定義します。	データ鮮度 SLA または予測不可能な更新期間を伴う本番運用ワークロード。
`SCHEDULE`	定義された時間間隔で更新されるマテリアライズドビューを定義します。	予測可能な時間ベースの更新要件。
ジョブ内のSQLタスク	更新はLakeFlow Jobsを通じて調整されます。	システム間の依存関係を持つ複雑なパイプライン。

手動更新

マテリアライズドビューを手動で更新するには、 Databricks SQLから更新を呼び出すか、ワークスペース UI を使用します。

REFRESH statement
Workspace UI

Databricks SQL を使用してパイプラインを更新するには:

の中で SQL エディタで 、次のステートメントを実行します。
SQL
```
REFRESH MATERIALIZED VIEW <mv-name>;
```

詳細については、 REFRESH ( MATERIALIZED VIEWまたはSTREAMING TABLE )」を参照してください。

更新時にトリガー

TRIGGER ON UPDATE句は、上流のソースデータが変更されると、マテリアライズドビューを自動的に更新します。これにより、パイプライン間でスケジュールを調整する必要がなくなります。マテリアライズドビューは、ユーザーが上流のジョブがいつ終了するかを認識したり、複雑なスケジューリングロジックを維持したりする必要がなく、常に最新の状態を保ちます。

これは、特にアップストリームの依存関係が予測可能なスケジュールで実行されない場合に、本番運用ワークロードに推奨されるアプローチです。構成が完了すると、マテリアライズドビューはそのソーステーブルを監視し、上流のソースの変更が検出されると自動的に更新されます。

制限事項

アップストリーム依存関係の制限: マテリアライズドビューは、最大 10 個のアップストリームテーブルと 30 個のアップストリームビューを監視できます。さらに依存関係を追加するには、ロジックを複数のマテリアライズドビューに分割します。
ワークスペースの制限: TRIGGER ON UPDATEマテリアライズドビューは、ワークスペースごとに最大 1,000 個存在できます。 1,000 を超えるマテリアライズドビューが必要な場合は、 Databricksサポートにお問い合わせください。
最小間隔: 最小トリガー間隔は 1 分です。

次の例は、マテリアライズドビューを定義するときに更新時にトリガーを設定する方法を示しています。

更新時にトリガーするマテリアライズドビューを作成する

ソースデータが変更されたときに自動的に更新されるマテリアライズドビューを作成するには、 CREATE MATERIALIZED VIEWステートメントにTRIGGER ON UPDATE句を含めます。

次の例では、ソースcustomersテーブルまたはordersテーブルが更新されるたびに顧客注文と更新を集計するマテリアライズドビューを作成します。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

スロットル更新頻度

アップストリームデータが頻繁に更新される場合は、 AT MOST EVERYを使用してビューの更新頻度を制限し、コンピュートコストを制限します。これは、ソーステーブルが頻繁に更新されるが、ダウンストリームのコンシューマがリアルタイムデータを必要としない場合に便利です。時間値の前にINTERVALキーワードが必要です。

次の例では、ソースデータがより頻繁に変更される場合でも、マテリアライズドビューの更新を最大 5 分ごとに制限します。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

スケジュールされた更新

更新スケジュールをマテリアライズドビュー定義で直接定義して、一定の時間間隔でビューを更新できます。このアプローチは、データの更新頻度がわかっており、予測可能な更新タイミングが必要な場合に役立ちます。

更新スケジュールがある場合でも、更新されたデータが必要な場合はいつでも手動で更新を実行できます。

Databricks は、単純な間隔のSCHEDULE EVERYと正確なスケジュールのSCHEDULE CRONという 2 つのスケジュール構文をサポートしています。SCHEDULEキーワードとSCHEDULE REFRESHキーワードは意味的に同等です。

SCHEDULE句の構文と使用法の詳細については、 CREATE MATERIALIZED VIEW SCHEDULE 句を参照してください。

スケジュールが作成されると、更新を処理するように新しい Databricks ジョブが自動的に構成されます。

スケジュールを表示するには、次のいずれかを実行します。

Databricks UI の SQL エディターからDESCRIBE EXTENDEDステートメントを実行します。「DESCRIBE TABLE」を参照してください。
Catalog Explorer を使用してマテリアライズドビューを表示します。スケジュールは、 [概要] タブの [更新ステータス] に表示されます。「カタログエクスプローラーとは何ですか?」を参照してください。

次の例は、スケジュールを使用してマテリアライズドビューを作成する方法を示しています。

時間間隔ごとにスケジュールを設定する

この例では、1 時間ごとに更新をスケジュールします。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
  SCHEDULE EVERY 1 HOUR
AS SELECT
    date_trunc('hour', event_time) AS hour,
    count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;

cronを使用したスケジュール

この例では、UTC タイムゾーンの 15 分ごとに更新をスケジュールします。

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
  SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
    date_trunc('minute', event_time) AS minute,
    count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;

ジョブ内のSQLタスク

マテリアライズドビューの更新は、 REFRESH MATERIALIZED VIEWコマンドを含むSQLタスクを作成することでDatabricksジョブを通じて調整できます。このアプローチは、マテリアライズドビュー更新を既存のジョブオーケストレーションワークフローに統合します。

マテリアライズドビューを更新するためのジョブを作成するには 2 つの方法があります。

SQL エディターから : REFRESH MATERIALIZED VIEWコマンドを記述し、 [スケジュール] ボタンをクリックして、クエリから直接ジョブを作成します。
ジョブ UI から : 新しいジョブを作成し、SQL タスクタイプを追加し、 REFRESH MATERIALIZED VIEWコマンドを使用して SQL クエリまたはノートブックをアタッチします。

次の例は、マテリアライズドビューを更新するSQLタスク内のSQLステートメントを示しています。

SQL
REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

このアプローチは次のような場合に適しています。

複雑なマルチステップパイプラインには、システム間で依存関係があります。
既存のジョブオーケストレーションとの統合が必要です。
ジョブレベルのアラートとモニタリングが必要です。

SQLタスクはジョブに付属するSQLウェアハウスと更新を実行するサーバレスコンピュートの両方を使用します。マテリアライズドビュー定義ベースのスケジューリングを使用することで要件が満たされる場合は、 TRIGGER ON UPDATEまたはSCHEDULEに切り替えることでワークフローを簡素化できます。

既存のマテリアライズドビューにスケジュールを追加する

作成後にスケジュールを設定するには、 ALTER MATERIALIZED VIEWステートメントを使用します。

SQL
-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

既存のスケジュールまたはトリガーを変更する

マテリアライズドビューにすでにスケジュールまたはトリガーが関連付けられている場合は、 ALTER SCHEDULEまたはALTER TRIGGER ON UPDATEを使用して更新構成を変更します。これは、あるスケジュールから別のスケジュールに変更する場合、あるトリガーから別のトリガーに変更する場合、またはスケジュールとトリガーを切り替える場合に適用されます。

次の例では、既存のスケジュールを 4 時間ごとに更新するように変更します。

SQL
ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

スケジュールまたはトリガーを削除する

スケジュールを削除するには、 ALTER ... DROPを使用します。

SQL
ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

アクティブな更新を停止する

Databricks UI でアクティブな更新を停止するには、 パイプラインの詳細 ページで [停止] をクリックしてパイプラインの更新を停止します。 Databricks CLIまたはPOST /api/2.0/パイプライン/{pipeline_id}/stop を使用して更新を停止することもできます。パイプラインAPIでの操作。

更新のタイムアウト

長時間実行される更新はタイムアウトする可能性があります。2025 年 8 月 14 日以降に作成または更新されたマテリアライズドビューは、更新の実行に使用されたSQLウェアハウスに関連付けられたタイムアウトを使用します。ウェアハウスにタイムアウトが設定されていない場合は、デフォルトの 2 日が使用されます。

注記

マテリアライズドビューは、 CREATE OR REFRESHステートメントを手動で実行する場合にのみタイムアウトを同期します。スケジュールされた更新では、最新のCREATE OR REFRESHからのタイムアウトが保持されます。

更新の SQL でSTATEMENT_TIMEOUT構成を使用してタイムアウトを明示的に設定できます。STATEMENT_TIMEOUTを参照してください。

削除ベクトルが有効になっているマテリアライズドビューからレコードを完全に削除します

備考

プレビュー

マテリアライズドビューでの REORG ステートメントのサポートは、パブリックプレビュー段階です。

注記

マテリアライズドビューでREORGステートメントを使用するには、 Databricks Runtime 15.4 以降が必要です。
REORGステートメントは任意のマテリアライズドビューで使用できますが、削除が有効になっているマテリアライズドビューからレコードを削除する場合にのみ必要です。このコマンドは、下り通路を有効にせずにマテリアライズドビューで使用した場合には効果がありません。

GDPR コンプライアンスなど、削除が有効になっているマテリアライズドビューの基盤となるストレージからレコードを物理的に削除するには、 GDPRビューのデータに対してvacuum操作が確実に実行されるように追加の手順を実行する必要があります。

レコードを物理的に削除するには:

マテリアライズドビューに対してREORGステートメントを実行し、 APPLY (PURGE)パラメーターを指定します。たとえばREORG TABLE <materialized-view-name> APPLY (PURGE); 。REORG TABLEを参照してください。
マテリアライズドビューのデータ保存期間が経過するまで待ちます。デフォルトのデータ保持期間は 7 日間ですが、 delta.deletedFileRetentionDurationテーブルプロパティを使用して構成できます。「タイムトラベルクエリのデータ保持を構成する」を参照してください。
REFRESH マテリアライズドビュー。マテリアライズドビューの更新を参照してください。 REFRESH操作から 24 時間以内に、レコードが完全に削除されるようにするために必要なVACUUM操作を含むパイプラインメンテナンスタスクが自動的に実行されます。

マテリアライズドビューの削除

注記

マテリアライズドビューを削除するコマンドを送信するには、そのマテリアライズドビューの所有者であるか、マテリアライズドビューに対するMANAGE権限を持っている必要があります。

マテリアライズドビューを削除するには、 DROP VIEWステートメントを使用します。 DROPステートメントを送信するには、Databricks UI の SQL エディター、 Databricks SQL CLI 、またはDatabricks SQL API を使用できます。次の例では、 mv1マテリアライズドビューを削除します。

SQL
DROP MATERIALIZED VIEW mv1;

カタログエクスプローラーを使用してマテリアライズドビューをドロップすることもできます。

クリックサイドバーの カタログ 。
左側のカタログエクスプローラーツリーでカタログを開き、マテリアライズドビューが配置されているスキーマを選択します。
選択したスキーマの下にある テーブル アイテムを開き、[マテリアライズドビュー] をクリックします。
ケバブメニューで、 [削除] を選択します。

マテリアライズドビューのコストを理解する

マテリアライズドビューは、ノートブックやジョブに設定したコンピュートの外にあるサーバレスコンピュートで実行されるため、それに関連するコストをどう理解すればよいのか疑問に思うかもしれません。マテリアライズドビューの使用状況は、 DBU消費量によって追跡されます。詳細については、「マテリアライズドビューまたはストリーミングテーブルのDBU消費量は何ですか?」を参照してください。

行追跡を有効にする

Deltaテーブルからの増分更新をサポートするには、それらのソーステーブルに対して行追跡を有効にする必要があります。ソーステーブルを再作成する場合は、行トラッキングを再度有効にする必要があります。

次の例は、テーブルで行追跡を有効にする方法を示しています。

SQL
ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

詳細については、 Databricks の行追跡を参照してください。

制限事項

コンピュートおよびワークスペースの要件については、「要件」を参照してください。
増分更新の要件については、「マテリアライズドビューの増分更新」を参照してください。
マテリアライズドビューは、ID 列または代理キーをサポートしていません。
マテリアライズドビューがNULL可能な列に対して合計集計を使用し、その列にNULL値のみが残っている場合、マテリアライズドビューの結果の集計値はNULLではなく 0 になります。
マテリアライズドビューからチェンジデータフィードを読み取ることはできません。
タイムトラベルクエリはマテリアライズドビューではサポートされていません。
マテリアライズドビューをサポートする基になるファイルには、マテリアライズドビューの定義に表示されないアップストリームテーブルのデータ (個人を特定できる可能性のある情報を含む) が含まれる場合があります。このデータは、マテリアライズドビューの増分更新をサポートするために、基になるストレージに自動的に追加されます。マテリアライズドビューの基になるファイルは、マテリアライズドビュースキーマの一部ではないアップストリームテーブルからのデータを公開するリスクがあるため、Databricks では、基になるストレージを信頼されていないダウンストリームコンシューマーと共有しないことをお勧めします。たとえば、マテリアライズドビューの定義に COUNT(DISTINCT field_a) 句が含まれているとします。マテリアライズドビュー定義には aggregate COUNT DISTINCT 句のみが含まれていますが、基になるファイルには field_aの実際の値のリストが含まれます。
専用コンピュートでこれらの機能を使用する場合でも、サーバーレスコンピュート料金が発生する場合があります。
マテリアライズドビューで AWS PrivateLink 接続を使用する必要がある場合は、Databricks の担当者にお問い合わせください。

外部クライアントからマテリアライズドビューにアクセスする

オープンAPIsをサポートしていない外部のDelta LakeまたはIcebergクライアントからマテリアライズドビューにアクセスするには、互換Modeを使用できます。互換Modeは、 Delta LakeまたはIcebergクライアントからアクセスできるマテリアライズドビューの読み取り専用バージョンが作成されます。

マテリアライズドビューとは何ですか？​

要件​

マテリアライズドビューを作成または更新するための要件:​

マテリアライズドビューをクエリするための要件:​

マテリアライズドビューの作成​

外部システムからデータを読み込む​

機密データを非表示にする​

マテリアライズドビューを更新する​

Databricks SQLマテリアライズドビューはどのように更新されますか?​

非同期更新​

マテリアライズドビュー 更新のスケジュール​

手動更新​

更新時にトリガー​

スケジュールされた更新​

ジョブ内のSQLタスク​

既存のマテリアライズドビューにスケジュールを追加する​

既存のスケジュールまたはトリガーを変更する​

スケジュールまたはトリガーを削除する​

アクティブな更新を停止する​

更新のタイムアウト​

削除ベクトルが有効になっているマテリアライズドビューからレコードを完全に削除します​

マテリアライズドビューの削除​

マテリアライズドビューのコストを理解する​

行追跡を有効にする​

制限事項​

外部クライアントからマテリアライズドビューにアクセスする​

関連記事​