Databricks SQL の具体化されたビューを使用する

2025-05-01

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

具体化されたビューとは何ですか?

Databricks SQL では、具体化されたビューは、クエリの結果を物理的に格納する Unity カタログマネージドテーブルです。必要に応じて結果を計算する標準ビューとは異なり、具体化されたビューは結果をキャッシュし、基になるソーステーブルの変更に応じて、スケジュールに従うか自動的に更新します。

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

具体化されたビューの一般的なユースケースを次に示します。

エンドユーザーのクエリ待機時間を最小限に抑えて、BI ダッシュボードを最新の状態に保ちます。
単純な SQL ロジックによる複雑な ETL オーケストレーションの削減。
複雑で階層化された変換を構築する。
up-to-date 分析情報を用いて一貫したパフォーマンスが求められるユースケース。

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

要件

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

具体化されたビューを作成または更新するための要件:

Unity Catalog 対応のプロまたはサーバーレス SQL ウェアハウスを使用する必要があります。
具体化されたビューを更新するには、それを作成したワークスペース内にいる必要があります。
Deltaテーブルから具体化されたビューを増分更新するには、ソーステーブルで行追跡を有効化する必要があります。
所有者 (具体化されたビューを作成するユーザー) には、次のアクセス許可が必要です。
- 具体化されたビューによって参照されるベーステーブルに対する SELECT 権限。
- 具体化されたビューのソーステーブルを含むカタログとスキーマに対する USE CATALOG および USE SCHEMA 権限。
- 具体化されたビューのターゲットカタログとスキーマに対する USE CATALOG および USE SCHEMA 権限。
- 具体化されたビューを含むスキーマに対する CREATE TABLE および CREATE MATERIALIZED VIEW 権限。
具体化されたビューを更新するには、具体化されたビューに対する REFRESH 権限が必要です。

ワークスペースは、サーバーレス SQL ウェアハウスをサポートするリージョンに存在する必要があります。

マテリアライズドビューに対するクエリの要件:

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

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

具体化されたビューを作成する

Databricks SQL 具体化されたビューの CREATE 操作では、Databricks SQL ウェアハウスを使用して、具体化されたビューでデータを作成し読み込みます。具体化されたビューの作成は同期操作であるため、具体化されたビューが作成され最初のデータ読み込みが完了するまで CREATE MATERIALIZED VIEW コマンドはブロックされます。 Databricks SQL マテリアライズドビューごとに、サーバーレスパイプラインが自動的に作成されます。具体化されたビューが更新されると、Lakeflow 宣言パイプラインによって更新が処理されます。

具体化されたビューを作成するには、CREATE MATERIALIZED VIEW ステートメントを使用します。 CREATE ステートメントを送信するには、Azure Databricks UI の SQL エディター、Databricks SQL CLI、または Databricks SQL API を使用します。

具体化されたビューを作成するユーザーは、具体化されたビューの所有者です。

次の例では、基本テーブル mv1 から具体化されたビュー base_table1 を作成します。

-- 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 ウェアハウスコンピューティングは使用されません。代わりに、サーバーレスの Lakeflow 宣言型パイプラインが作成とその後の更新に使用されます。

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

同じ SQL ステートメントは、後続の時刻またはスケジュールに従って呼び出された場合に、具体化されたビューを更新します。この方法で行われる更新は、他の更新として機能します。詳細については、「具体化されたビューを更新する」を参照してください。

具体化されたビューの構成の詳細については、「 Databricks SQL で具体化されたビューを構成する」を参照してください。具体化されたビューを作成するための完全な構文については、 CREATE MATERIALIZED VIEWを参照してください。さまざまな形式でさまざまな場所からデータを読み込む方法については、「 Lakeflow 宣言型パイプラインを使用したデータの読み込み」を参照してください。

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

Databricks では、サポートされているデータソースについては Lakehouse フェデレーションを使用して外部データを読み込むことをおすすめします。 Lakehouse フェデレーションでサポートされていないソースからデータを読み込む方法については、データ形式のオプションに関するページを参照してください。例を含むデータの読み込みの一般的な情報については、「 Lakeflow 宣言型パイプラインを使用したデータの読み込み」を参照してください。

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

重要

この機能はパブリックプレビュー段階です。

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

具体化されたビューを更新する

具体化されたビューを更新すると、更新時にベーステーブルに対する最新の変更が反映されるようにビューが更新されます。

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

更新ステートメントを送信するには、Azure Databricks UI の SQL エディター、SQL 倉庫に接続されたノートブック、Databricks SQL CLI、または Databricks SQL API を使用します。

所有者と、テーブルに対する REFRESH 権限が付与されたすべてのユーザーは、具体化されたビューを更新できます。

次の例では、具体化されたビュー mv1 を更新します。

REFRESH MATERIALIZED VIEW mv1;

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

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Databricks SQL 具体化されたビューはどのように更新されますか?

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

具体化されたビューは、2 つの方法のいずれかを使用して更新されます。

増分更新 - システムはビューのクエリを評価して、前回の更新後に発生した変更を特定し、新しいデータまたは変更されたデータのみをマージします。
完全更新 - 増分更新を実行できない場合、システムはクエリ全体を実行し、具体化されたビュー内の既存のデータを新しい結果に置き換えます。

クエリの構造とソースデータの種類によって、増分更新がサポートされているかどうかが決まります。増分更新をサポートするには、ソースデータをデルタテーブルに格納し、行追跡と変更データフィードを有効にする必要があります。具体化されたビューを作成したら、その更新動作を監視して、増分更新または完全更新のどちらで更新されるかを確認できます。

更新の種類の詳細と、増分更新を最適化する方法については、具体化されたビューの増分更新に関するページを参照してください。

非同期更新

既定では、更新操作は同期的に実行されます。更新操作を非同期的に実行するように設定することもできます。これは、 ASYNC キーワードを指定して refresh コマンドを使用して設定できます。 REFRESH (MATERIALIZED VIEW または STREAMING TABLE) 各アプローチに関連する動作を次に示します。

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

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

定義されたスケジュールに基づいて自動的に更新されるように Databricks SQL 具体化されたビューを構成できます。スケジュールをセットするには、次のいずれかの操作を行います。

マテリアライズドビューを作成する際は、SCHEDULE 句を使用してスケジュールを設定します。
ALTER MATERIALIZED VIEW ステートメントを使用してスケジュールを追加します。

注

または、 CREATE OR REPLACE MATERIALIZED VIEW または REFRESH ステートメントのいずれかを含むタスクをジョブに作成し、他のジョブと同様に調整することもできます。「Lakeflow ジョブ」を参照してください。

次の例では、基本テーブル mv1から具体化されたビューbase_table1を作成し、マテリアライズドビューを 1 時間に 1 回更新するスケジュールを作成します。

CREATE OR REPLACE MATERIALIZED VIEW mv1
  SCHEDULE EVERY 1 hour
  AS SELECT
    date,
    sum(sales) AS sum_of_sales
  FROM
    base_table1
  GROUP BY
    date;

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

ALTER MATERIALIZED VIEW sales ALTER SCHEDULE EVERY 1 day;

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

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

Azure Databricks UI で SQL エディターから DESCRIBE EXTENDED ステートメントを実行します。 DESCRIBE TABLEを参照してください。
カタログエクスプローラーを使用して具体化されたビューを表示します。スケジュールは [概要] タブの 更新状態 に表示されます。「カタログエクスプローラーとは」を参照してください。

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

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

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

削除ベクトルが有効になっている具体化されたビューからレコードを完全に削除する

重要

具体化ビューを用いた REORG ステートメントのサポートは、パブリックプレビューでサポートされています。

注

具体化されたビューで REORG ステートメントを使用するには、Databricks Runtime 15.4 以降が必要です。
REORG ステートメントは具体化されたビューで使用できますが、削除ベクトルが有効になっている具体化されたビューからレコードを削除する場合にのみ必要です。このコマンドは、削除ベクトルを有効にせずに具体化されたビューで使用した場合は効果がありません。

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

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

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

具体化されたビューを削除する

注

具体化されたビューを削除するコマンドを送信するには、その具体化されたビューの所有者であるか、具体化されたビューに対する MANAGE 権限を持っている必要があります。

具体化されたビューを削除するには、DROP VIEW ステートメントを使用します。 DROP ステートメントを送信するには、Azure Databricks UI の SQL エディター、Databricks SQL CLI、または Databricks SQL API を使用できます。次の例では、具体化されたビュー mv1 を削除します。

DROP MATERIALIZED VIEW mv1;

カタログエクスプローラーを使用して、具体化されたビューを削除することもできます。

[サイドバーのカタログ。
左側のカタログエクスプローラーツリーで、カタログを開き、具体化されたビューがあるスキーマを選択します。
選択したスキーマの テーブル 項目を開き、具体化されたビューをクリックします。
[Kebab] メニューの [ 、[削除] を選択 します。

具体化されたビューのコストを理解する

具体化されたビューは、ノートブックまたはジョブ用に設定したコンピューティング以外のサーバーレスコンピューティングで実行されるため、それに関連するコストを理解する方法を疑問に思うかもしれません。具体化されたビューの使用状況は、DBU の使用量によって追跡されます。詳細については、「具体化されたビューまたはストリーミングテーブルの DBU 消費量とは」を参照してください。

行の追跡を有効にする

増分更新をデルタテーブルからサポートするためには、ソーステーブルで行追跡を有効にする必要があります。ソーステーブルを再作成する場合は、行追跡を再度有効にする必要があります。

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

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

詳細については、「デルタテーブルの行追跡を使用する」を参照してください。

制限事項

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

具体化されたビューで Azure Private Link 接続を使う必要がある場合は、Databricks の担当者にお問い合わせください。