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

この記事では、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 Spark 宣言型パイプライン インターフェイス

  • 標準アクセス モード コンピューティング (以前の共有アクセス モード)

  • ワークスペースがサーバーレス コンピューティングに対して有効になっている限り、Databricks Runtime 15.4 以降の専用アクセス モード (以前のシングル ユーザー アクセス モード)。 専用コンピューティングでのきめ細かなアクセス制御を参照してください。

    具体化されたビューの所有者は、14.3 以上の間で Databricks Runtime を実行している専用アクセス モードのコンピューティング リソースを使用できます。

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

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

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

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

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

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

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

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

具体化されたビューは、 サポートされているデータ ソースに対して Lakehouse Federation を使用して外部データに作成できます。 Lakehouse フェデレーションでサポートされていないソースからデータを読み込む方法については、データ形式のオプションに関するページを参照してください。 例を含むデータの読み込みに関する一般的な情報については、「 パイプラインでのデータの読み込み」を参照してください。

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

具体化されたビューを使用して、テーブルにアクセスするユーザーから機密データを非表示にすることができます。 これを行う 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 具体化されたビューはどのように更新されますか?

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

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

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

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

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

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

非同期更新

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

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

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

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

手動更新

具体化されたビューを手動で更新するには、Databricks SQL から更新を呼び出すか、ワークスペース UI を使用します。

REFRESH ステートメント

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

1. SQL エディターで、次のステートメントを実行します。

   REFRESH MATERIALIZED VIEW <mv-name>;
   

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

ワークスペース UI

ワークスペース UI でパイプラインを更新するには:

1. Azure Databricks ワークスペースで、[ワークフロー] をクリックします。ジョブとパイプライン。
2. 一覧から更新するパイプラインを選択します。
3. [スタート] ボタンをクリックします。

パイプラインが更新されると、UI に更新が表示されます。

更新時にトリガーする

TRIGGER ON UPDATE句は、アップストリームのソース データが変更されると、マテリアライズド ビューを自動的に更新します。 これにより、パイプライン間でスケジュールを調整する必要がなくなります。 具体化ビューは、アップストリームジョブの完了時期や複雑なスケジューリングロジックをユーザーが意識することなく、常に最新の状態を保ちます。

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

制限事項

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

次の例は、具体化されたビューを定義するときに更新時にトリガーを設定する方法を示しています。

更新時にトリガーを使用して具体化されたビューを作成する

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

次の例では、ソース customers テーブルまたは orders テーブルが更新されるたびに顧客の注文を集計して更新する具体化されたビューを作成します。

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 分ごとに更新するように制限します。

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句の構文と使用方法の詳細については、SCHEDULE 句CREATE MATERIALIZED VIEW参照してください。

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

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

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

次の例は、スケジュールを使用して具体化されたビューを作成する方法を示しています。

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

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

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 分ごとに更新をスケジュールします。

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 ステートメントを示しています。

REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

この方法は、次の場合に適しています。

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

SQL タスクでは、ジョブにアタッチされた SQL ウェアハウスと、更新を実行するサーバーレス コンピューティングの両方が使用されます。 具体化されたビュー定義ベースのスケジュール設定を使用して要件を満たしている場合は、 TRIGGER ON UPDATE または SCHEDULE に切り替えると、ワークフローを簡略化できます。

既存の具体化されたビューにスケジュールを追加する

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

-- 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 時間ごとに更新するように既存のスケジュールを変更します。

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

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

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

ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

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

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

更新のタイムアウト

具体化されたビューの更新は、実行できる時間を制限するタイムアウトで実行されます。 2025 年 8 月 14 日以降に作成または更新された具体化されたビューの場合、 CREATE OR REFRESHを実行して更新するとタイムアウトがキャプチャされます。

• STATEMENT_TIMEOUTが設定されている場合は、その値が使用されます。 STATEMENT_TIMEOUTを参照してください。
• それ以外の場合は、コマンドの実行に使用された SQL ウェアハウスからのタイムアウトが使用されます。
• ウェアハウスにタイムアウトが構成されていない場合は、既定値の 2 日が適用されます。

タイムアウトは、最初の作成だけでなく、その後のスケジュールされた更新でも使用されます。

2025 年 8 月 14 日より前に最後に更新された具体化されたビューの場合、タイムアウトは 2 日に設定されます。

例: 具体化されたビューの更新のタイムアウトを設定 する具体化されたビューの更新を実行できる期間を明示的に制御するには、ビューの作成時または更新時にステートメント レベルのタイムアウトを設定します。

SET STATEMENT_TIMEOUT = '6h';

CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
  SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;

これにより、具体化されたビューが 12 時間ごとに更新されるように設定され、更新に 6 時間以上かかる場合はタイムアウトになり、次回のスケジュールされた更新が待機されます。

スケジュールされた更新でタイムアウトを処理する方法

タイムアウトは、 CREATE OR REFRESHを明示的に実行した場合にのみ同期されます。

• スケジュールされた更新では、最新の CREATE OR REFRESH中にキャプチャされたタイムアウトが引き続き使用されます。
• ウェアハウスタイムアウトのみを変更しても、既存のスケジュールされた更新には影響しません。

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

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

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

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

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

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

DROP MATERIALIZED VIEW mv1;

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

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

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

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

行の追跡を有効にする

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

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

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

詳細については、Databricks での行の追跡に関するページを参照してください。

制限事項

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

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

外部クライアントから具体化されたビューにアクセスする

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

関連資料

• Databricks SQL で具体化されたビューを構成する
• Databricks SQL で具体化されたビューを監視する
• Databricks SQL でストリーミング テーブルを使用する