スタンドアロンのマテリアライズドビューを使用する
スタンドアロンのマテリアライズドビューは、クエリー結果を事前にコンピュートしてキャッシュすることで、パフォーマンスを向上させ、データ処理と分析のワークロードのコストを削減します。
Databricks SQL warehouseまたはサーバレス汎用コンピュートで実行されているノートブックから、スタンドアロンのマテリアライズドビューを作成および更新できます。2 つのコンピュート オプションの違いの詳細については、スタンドアロンパイプラインの要件を参照してください。
ノートブックからPythonを使用してスタンドアロンのマテリアライズドビューを作成および更新するには、 「スタンドアロン パイプラインでの Python の使用」を参照してください。
スタンドアロン マテリアライズドビューとは何か?
スタンドアロンのマテリアライズドビューは、Lakeflowパイプラインの外部で定義された、クエリー結果を物理的に格納するUnity Catalogマネージドテーブルです。要求に応じて結果をコンピュートする標準ビューとは異なり、マテリアライズドビューは結果をキャッシュし、基になるソーステーブルが変更されたときに、スケジュールまたは自動的に結果を更新します。
マテリアライズドビューは、事前計算された結果をダッシュボードやレポートに提供したり、ベーステーブルのクリーニング、エンリッチメント、非正規化を行う変換に適しています。コストが高く、頻繁に使用されるクエリーを事前計算することで、マテリアライズドビューはクエリーのレイテンシとリソースの消費を削減します。多くの場合、ソーステーブルからの変更を 増分コンピュート できるため、効率とエンドユーザーの操作性がさらに向上します。
修正、遅れて到着したデータ、コンプライアンスの削除など、期間またはパーティションを定期的に上書きするバッチ抽出、変換、ロード (ETL) ワークロードの場合は、代わりに REPLACE WHERE フロー を使用してください。REPLACE WHERE とマテリアライズドビューの使用時期を参照してください。
マテリアライズドビューの一般的なユースケースは次のとおりです。
- BIダッシュボードを最新の状態に維持し、エンドユーザーのクエリーの待ち時間を最小限に抑えます。
- 複雑で階層化された変換の構築。
- 最新の知見や常に安定したパフォーマンスが求められるユースケース。
Databricks SQL warehouseでマテリアライズドビューを作成すると、マテリアライズドビューの作成と更新を処理するためのServerless パイプラインが作成されます。更新操作のステータスは カタログエクスプローラ で監視できます。DESCRIBE EXTENDEDで詳細を表示を参照してください。
要件
スタンドアロン マテリアライズドビューの作成、更新、およびクエリに関するコンピュート オプション、権限、およびその他の要件については、 「スタンドアロン パイプラインの要件」を参照してください。
具体化されたビューの使用に関するその他の制限については、 制限事項を参照してください。
マテリアライズドビューの作成
スタンドアロンのマテリアライズドビュー CREATE 操作では、Databricks SQL warehouseを使用して、マテリアライズドビューにデータを作成して読み込みます。マテリアライズドビューの作成は同期操作であるため、 CREATE MATERIALIZED VIEW コマンドは、マテリアライズドビューが作成され、初期データの読み込みが完了するまでブロックされます。Serverless パイプラインは、 スタンドアロン マテリアライズドビューごとに自動的に作成されます。マテリアライズドビューが更新されると、パイプラインは更新を処理します。
マテリアライズドビューを作成するには、 CREATE MATERIALIZED VIEW ステートメントを使用します。作成ステートメントを送信するには、Databricks UI のSQLエディター、Databricks SQL CLI、またはDatabricks SQL API を使用します。
マテリアライズドビューを作成したユーザーが、マテリアライズドビューの所有者になります。
アドホックマテリアライズドビュー
次の例では、ベース テーブル base_table1 からマテリアライズドビュー mv1 を作成します。
-- 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;
オントリガー マテリアライズドビュー
次の例では、 TRIGGER ON UPDATEを使用してアップストリームソースデータが変更されるたびに自動的に更新されるマテリアライズドビューを作成します。本番運用ワークロード、特にアップストリームの依存関係が予測可能なスケジュールで実行されない場合は、このアプローチを使用してください。
-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
TRIGGER ON UPDATE
AS SELECT
date,
sum(sales) AS sum_of_sales
FROM
base_table1
GROUP BY
date;
マテリアライズドビューのスケジュール
次の例では、午前 3:30 (UTC) に毎日の CRON 更新スケジュールを持つマテリアライズドビューを作成します。SELECT句の式と集計にはエイリアスを使用する必要があります。GROUP BYの列参照にエイリアスは必要ありません。
-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
date_trunc('day', order_time) AS sales_date,
region,
sum(revenue) AS total_revenue,
count(*) AS order_count
FROM
orders
GROUP BY sales_date, region;
スケジュール設定のその他のオプション(SCHEDULE EVERY構文や追加のCRONの例など)については、更新のスケジュール設定を参照してください。
CREATE OR REPLACE MATERIALIZED VIEW ステートメントを使用してマテリアライズドビューを作成すると、最初のデータ更新と入力がすぐに開始されます。これは SQLウェアハウス コンピュートを消費しません。代わりに、Serverless パイプラインが作成とその後の更新に使用されます。スタンドアロン マテリアライズドビューはどのように更新されますか?を参照してください。
ベーステーブルの列コメントは、作成時に新しいマテリアライズドビューに自動的に伝搬されます。スケジュール、テーブル制約、またはその他のプロパティを追加するには、マテリアライズドビュー定義(SQL クエリー)を変更します。
同じ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 マテリアライズドビュー (Materialized View) を更新します。
REFRESH MATERIALIZED VIEW mv1;
defaultでは、操作は同期的であるため、更新操作が完了するまでコマンドはブロックされます。非同期で更新するには、 ASYNC キーワードを追加できます。
REFRESH MATERIALIZED VIEW mv1 ASYNC;
更新をスケジュールする方法については、更新をスケジュールするをご覧ください。
スタンドアロンのマテリアライズドビューはどのように更新されますか?
マテリアライズドビューは、Serverless パイプラインを自動的に作成して使用し、更新操作を処理します。更新はパイプラインによって管理され、更新はマテリアライズドビューの作成に使用された Databricks SQL warehouse によって監視されます。マテリアライズドビューは、スケジュールに従って実行されるパイプラインを使用して更新できます。スタンドアロンのマテリアライズドビューは、Triggerモードでランします。Trigger パイプライン モードと継続的パイプライン モードを参照してください。
スケジュールされた更新には更新通知を付けることができ、更新のパフォーマンスモードを設定することもできます。
増分更新
マテリアライズドビューは、2 つの方法のいずれかで更新されます。
- 増分更新 - システムはビューのクエリーを評価し、前回の更新以降に行われた変更を特定し、新しいデータまたは変更されたデータのみをMergeします。
- 完全更新 - 増分更新を実行できない場合、または費用対効果が高くない場合、システムはクエリー全体を実行し、マテリアライズドビュー内の既存のデータを新しい結果で置き換えます。
クエリーの構造とソースデータの種類によって、増分更新がサポートされているかどうかが決まります。増分更新をサポートするには、ソースデータを、行追跡が有効な Delta テーブルに格納する必要があります。増分更新のパフォーマンスを向上させるために、チェンジデータフィードを有効にすることをお勧めします。クエリーが増分可能かどうかを確認するには、Databricks SQL の EXPLAIN CREATE MATERIALIZED VIEW ステートメントを使用します。マテリアライズドビューを作成したら、その更新動作を監視して、増分更新されるのか、それとも完全更新されるのかを確認できます。
defaultでは、Databricks はコスト モデルを使用して、完全更新と増分更新のどちらかコスト効率の高いオプションを選択します。マテリアライズドビューのSQL定義で REFRESH POLICY を設定することで、増分更新と完全更新のどちらかを優先するようにこの動作をオーバーライドできます。
更新タイプの詳細、および増分更新のために最適化する方法については、 マテリアライズドビューの増分更新を参照してください。
非同期更新
defaultでは、更新操作は同期的です。更新操作を非同期的に発生するように設定することもできます。これは、 ASYNC キーワードを使用した更新コマンドを使用して設定できます。更新 ( マテリアライズドビューまたはストリーミングテーブル )を参照してください。各アプローチに関連する動作は次のとおりです。
- 同期: 同期更新は、更新が完了するまで他の操作を続行できません。Lakeflow ジョブ などのオーケストレーション ツールで更新操作を順序付ける場合など、次の手順で結果が必要な場合は、同期更新を使用します。ジョブを使用してマテリアライズドビューを調整するには、 SQL タスクの種類を使用します。Lakeflowジョブを参照してください。
- 非同期 : 非同期更新では、マテリアライズドビューの更新が開始されると、Serverlessコンピュートでバックグラウンドジョブが起動され、データの読み込みが完了する前にコマンドが戻ることができます。この更新タイプでは、コマンドが開始されるwarehouseのコンピュート容量が必ずしも操作に保持されるとは限らないため、コストを節約できます。更新がアイドル状態になり、他のタスクが実行されていない場合、warehouseはシャットダウンでき、更新は他の使用可能なコンピュートを使用します。さらに、非同期更新では、複数の操作を並行して開始できます。
削除ベクトルが有効になっているマテリアライズドビューからレコードを完全に削除する
プレビュー
マテリアライズドビューでの REORG ステートメントのサポートは、パブリック プレビュー段階です。
- マテリアライズドビューで
REORGステートメントを使用するには、Databricks Runtime 15.4以降が必要です。 - マテリアライズドビューで
REORGステートメントを使用できますが、これは 削除ベクトル が有効なマテリアライズドビューからレコードを削除する場合にのみ必要です。このコマンドは、削除ベクトルが有効になっていないマテリアライズドビューで使用しても効果がありません。
GDPR コンプライアンスなどのために削除ベクトルが有効になっているマテリアライズドビューの基になるストレージからレコードを物理的に削除するには、 VACUUM 操作がマテリアライズドビューのデータに対して実行されるように追加のステップを実行する必要があります。
レコードを物理的に削除するには、次の操作を行います。
- マテリアライズドビューに対して
REORGステートメントを実行し、APPLY (PURGE)パラメーターを指定します。 たとえばREORG TABLE <materialized-view-name> APPLY (PURGE);。REORG TABLEを参照してください。 - マテリアライズドビューのデータ保持期間が経過するのを待ちます。defaultのデータ保持期間は7日間ですが、
delta.deletedFileRetentionDurationテーブルプロパティで構成できます。タイムトラベルクエリのデータ保持を構成するを参照してください。 REFRESHマテリアライズドビュー。更新 a マテリアライズドビューを参照してください。REFRESH操作から 24 時間以内に、レコードが完全に削除されるようにするために必要なVACUUM操作を含む、パイプライン メンテナンス タスクが自動的に実行されます。
マテリアライズドビューの削除
マテリアライズドビューを削除するコマンドを送信するには、そのマテリアライズドビューの所有者であるか、マテリアライズドビューに対する MANAGE 権限を持っている必要があります。
マテリアライズドビューを削除するには、 DROP VIEW 文を使用します。DROP ステートメントを送信するには、Databricks UI の SQL エディター、 Databricks SQL CLI、または Databricks SQL API を使用できます。次の例では、 mv1 マテリアライズドビュー (Materialized View) を削除します。
DROP MATERIALIZED VIEW mv1;
カタログエクスプローラを使用してマテリアライズドビューを削除することもできます。
- サイドバーの
カタログ をクリックします。
- 左側の [カタログエクスプローラ] ツリーでカタログを開き、マテリアライズドビューが配置されているスキーマを選択します。
- 選択したスキーマの下にある テーブル アイテムを開き、[マテリアライズドビュー] をクリックします。
- ケバブメニュー
で、 削除 を選択します。
マテリアライズドビューのコストの理解
CREATE MATERIALIZED VIEWまたはREFRESH MATERIALIZED VIEWを実行すると、Databricksは操作を処理するためにServerlessパイプラインを自動的に作成および実行します。このパイプラインは、コマンドを送信した Databricks SQL warehouse またはコンピュートリソースとは独立しています。warehouseのクラスターサイズは、更新に使用されるコンピュートやコストを制限しません。
- 更新パイプラインはServerlessコンピュートで実行され、Serverless LakeFlow Pipelines DBUとして請求されます。
- Serverlessパイプラインはwarehouseから分離されています。warehouseのコンピュートは操作の調整にのみ使用され、データ処理の実行には使用されません。
- コストは、SQLウェアハウスのサイズではなく、処理されるデータの量に比例します。
- マテリアライズドビューの更新コストを監視するには、システムテーブルを使用します。マテリアライズドビューまたはストリーミングテーブルのDBU消費量は?をご覧ください。
- マテリアライズドビューを管理する基盤となるパイプラインを表示するには:
- Databricks ワークスペースの左側のサイドバーで ジョブ & パイプライン をクリックします。
- パイプラインタイプ をクリックします。次に、 MV/ST を選択して、スタンドアロンのマテリアライズドビューを表示します。
元のwarehouseが専用コンピュートを使用していても、Serverless コンピュートの料金が発生する場合があります。
行追跡の有効化
Deltaテーブルからの増分更新をサポートするには、それらのソーステーブルで行トラッキングを有効にする必要があります。ソーステーブルを再作成した場合は、行トラッキングを再度有効にする必要があります。
次の例は、テーブルで行追跡を有効にする方法を示しています:
ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);
詳細については、「 Databricks の行追跡」を参照してください
制限事項
-
コンピュートオプションとワークスペースの要件については、スタンドアロンパイプラインの要件をご覧ください。
-
増分更新の要件については、「 マテリアライズドビュー のインクリメンタル 更新のサポート」を参照してください。
-
マテリアライズドビューは、ID 列または代理キーをサポートしていません。
-
マテリアライズドビューが
NULL-able列で合計集計を使用し、その列にNULL値のみが残っている場合、マテリアライズドビューの結果の集計値はNULLではなくゼロになります。 -
マテリアライズドビューでチェンジデータフィードを有効にしない限り、マテリアライズドビューから チェンジデータフィード を読み取ることはできません。マテリアライズドビューからのチェンジデータフィードの読み取り(ベータ版)を参照してください。
-
タイムトラベルクエリは、マテリアライズドビューではサポートされていません。
-
マテリアライズドビューをサポートする基になるファイルには、マテリアライズドビューの定義に表示されないアップストリームテーブルのデータ (個人を特定できる可能性のある情報を含む) が含まれる場合があります。このデータは、マテリアライズドビューの増分更新をサポートするために、基になるストレージに自動的に追加されます。マテリアライズドビューの基になるファイルは、マテリアライズドビュー スキーマの一部ではないアップストリーム テーブルからのデータを公開するリスクがあるため、Databricks では、基になるストレージを信頼されていないダウンストリーム コンシューマーと共有しないことをお勧めします。たとえば、マテリアライズドビューの定義に
COUNT(DISTINCT field_a)句が含まれているとします。マテリアライズドビュー定義には aggregateCOUNT DISTINCT句のみが含まれていますが、基になるファイルにはfield_aの実際の値のリストが含まれます。 -
専用のコンピュートでこれらの機能を使用する場合でも、一部のServerless コンピュート料金が発生する場合があります。
-
マテリアライズドビューでAWS PrivateLink 接続を使用する必要がある場合は、 Databricks担当者にお問い合わせください。
外部クライアントからマテリアライズドビューにアクセスする
オープンAPIをサポートしていない外部Delta LakeまたはIcebergクライアントからマテリアライズドビューにアクセスするには、Compatibility Modeを使用できます。互換性モードは、マテリアライズドビューの読み取り専用バージョンを作成し、任意のDelta LakeまたはIcebergクライアントからアクセスできるようにします。