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

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

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

サーバーレスコンピューティング実行されます

更新操作は、Databricks SQL で定義されたか、Lakeflow Spark 宣言パイプラインを使用して定義されたかに関係なく、サーバーレスパイプラインで実行されます。

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

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

マテリアライズドビューの更新セマンティクスとは

マテリアライズドビューでは、バッチクエリと同等の結果が保証されます。たとえば、次の集計クエリを考えます。

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Azure Databricks 製品を使用してこのクエリを実行すると、結果はバッチセマンティクスを使用して計算され、ソース transactions_table 内のすべてのレコードが集計されます。つまり、すべてのソースデータが 1 回の操作でスキャンおよび集計されます。

Note

一部の Azure 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

Python

@dp.materialized_view()
def transaction_summary():
  return (spark.read.table("transactions_table")
    .groupBy("account_id")
    .agg(
      count("*").alias("txn_count"),
      sum("txn_amount").alias("account_revenue")
    )
  )

マテリアライズドビューを更新すると、計算結果はバッチクエリセマンティクスと同じです。このクエリは、段階的に更新できるマテリアライズドビューの例です。つまり、更新操作では、ソース transactions_table 内の新しいデータまたは変更されたデータのみを処理して結果を計算しようとするベストエフォート型の試行が行われます。

マテリアライズドビューのデータソースに関する考慮事項

マテリアライズドビューは任意のデータソースに対して定義できますが、すべてのデータソースがマテリアライズドビューに適しているわけではありません。次の注意事項と推奨事項を検討してください。

Important

マテリアライズドビューでは、サポートされている操作の結果を増分更新するためにベストエフォート型の試行が行われます。データソースの一部の変更には、完全な更新が必要です。完全更新を実行するのではなく、失敗する更新ポリシーを定義できます。

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

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

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

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

これらの機能は、作成時に設定することも、後で ALTER TABLE ステートメント (Databricks SQL から実行) で設定することもできます。例えば次が挙げられます。

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

マテリアライズドビューの更新の種類

マテリアライズドビューを更新する場合は、更新または完全更新を指定できます。

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

更新プログラムが使用する更新の種類を確認するには、更新プログラムの更新の種類の決定に関するページを参照してください。

既定のリフレッシュ

サーバーレスでのマテリアライズドビューの既定の更新では、増分更新を試みます。増分更新では、最後の更新より後に基のデータで行われた変更が処理されて、そのデータがテーブルに追加されます。ベーステーブルと含まれる操作によっては、特定の種類のマテリアライズドビューのみを増分更新できます。増分更新ができない場合、または接続されたコンピューティングがサーバーレスではなくクラシックである場合は、完全な再計算が実行されます。

Note

Azure Databricks では、完全更新または増分更新が適用されます。この決定は、コスト効率が高いオプションと、クエリが増分更新をサポートしているかどうかに基づいています。この動作を変更するには、「ポリシーの更新」を参照してください。

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

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

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

更新プログラムが使用する更新の種類を確認するには、更新プログラムの更新の種類の決定に関するページを参照してください。

完全更新

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

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

REFRESH MATERIALIZED VIEW mv_name FULL

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

Important

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

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

次の表は、SQL のキーワードまたは句による増分更新に関するサポートの一覧です。特定のクエリでインクリメンタル化可能性をテストするには、 EXPLAIN CREATE MATERIALIZED VIEWを使用できます。

Important

一部のキーワードと句では、クエリ対象のデータソースで行追跡を有効にする必要があります。 Databricks の行追跡を参照してください。

これらのキーワードと句は、次の表の星 (*) でマークされています。

SQL のキーワードまたは句	同等の PySpark データフレーム	増分更新のサポート
`SELECT` 式*	`df.select()` または `df.selectExpr()`	はい、決定論的組み込み関数、不変ユーザー定義関数 (UDF) などの式がサポートされています。
`GROUP BY`	`df.groupBy().agg()`	Yes
`WITH`	データフレーム変数の連結。	はい。共通テーブル式はサポートされています。
`UNION ALL`*	`df.union` または `df.unionAll`	Yes
`FROM`	`df = spark.read...`	サポートされているベーステーブルには、Delta テーブル、マテリアライズドビュー、ストリーミングテーブルが含まれます。
`WHERE`、`HAVING`*	`df.filter()`、 `df.where()`、 `df.groupBy().filter()`	`WHERE` や `HAVING` などのフィルター句はサポートされています。
`INNER JOIN`*	`df.join()`	Yes
`LEFT OUTER JOIN`*	`df.join(... how="left")`	Yes
`FULL OUTER JOIN`*	`df.join(... how="full")`	Yes
`RIGHT OUTER JOIN`*	`df.join(... how="right")`	Yes
`OVER`	`df.over(window.partitionBy)` 関数	Yes. ウィンドウ関数の増分には、`PARTITION_BY` 列を指定する必要があります。
`QUALIFY`	`df.over(w).filter(...)`	Yes
`EXPECTATIONS`	`@dp.expect`	はい。エクスペクテーションを含むマテリアライズドビューは、増分更新することができます。ただし、次の場合、増分更新はサポートされていません。マテリアライズドビューが期待値を含むビューから読み取る場合。マテリアライズドビューに `DROP` 期待値があり、スキーマに `NOT NULL` 列が含まれている場合。
UDFs	UDFs	Azure Databricks は、UDF がいつ動作を変更するかを検出し、完全な更新を実行しようとします。ただし、他の関数またはライブラリを呼び出す UDF は、Azure Databricks で認識されない方法で動作が変わる可能性があります。 UDF の動作が変更された場合、更新された UDF を完全なマテリアライズドビューに適用するには、完全な更新を実行する必要があります。
非決定論的関数	非決定論的関数	非決定的時間関数は、 `WHERE` 句でサポートされています。これには、 `current_date()`、 `current_timestamp()`、 `now()`などの関数が含まれます。その他の非決定論的関数はサポートされていません。
デルタ以外のソース	デルタ以外のソース	ボリューム、外部の場所、外部カタログなどのソースはサポートされていません。

更新プログラムの更新の種類を決定する

マテリアライズドビューの更新のパフォーマンスを最適化するために、Azure Databricks はコストモデルを使用して、更新に使用される手法を選択します。次の表では、これらの手法について説明します。

Technique	増分更新でしょうか?	Description
`FULL_RECOMPUTE`	No	マテリアライズドビューが完全に再計算されました
`NO_OP`	適用なし	ベーステーブルに対する変更が検出されなかったため、マテリアライズドビューは更新されませんでした。
次のいずれか: `ROW_BASED` `PARTITION_OVERWRITE` `WINDOW_FUNCTION` `APPEND_ONLY` `GROUP_AGGREGATE` `GENERIC_AGGREGATE`	Yes	マテリアライズドビューは、指定された手法を使用して増分更新されました。

「ポリシーの更新」も参照してください。

使用される手法を確認するには、 event_type が planning_informationされている Lakeflow Spark 宣言パイプラインイベントログに対してクエリを実行します。

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

<fully-qualified-table-name> を、カタログやスキーマなど、マテリアライズドビューの完全修飾名に置き換えます。

このコマンドの出力例:

timestamp	メッセージ
`2025-03-21T22:23:16.497+00:00`	`Flow 'sales' has been planned in :re[LDP] to be executed as ROW_BASED.`

パイプラインイベントログを参照してください。

ポリシーの更新

Important

この機能はベータ版です。ワークスペース管理者は、[ プレビュー] ページからこの機能へのアクセスを制御できます。 Azure Databricks プレビューの管理を参照してください。

既定では、Azure Databricks は、クエリ構造、データ変更ボリューム、システムコストモデリングに基づいて、最もコスト効率の高い更新戦略 (増分または完全) を自動的に選択します。この既定の動作では、手動構成を必要とせずに更新のパフォーマンスが最適化されます。

ただし、一部のワークロードでは、より予測可能または明示的に制御された更新動作が必要です。これらのシナリオをサポートするために、マテリアライズドビュー定義で REFRESH POLICY を指定できます。更新ポリシーは、Azure Databricks が増分更新を実行するかどうか、完全な更新にフォールバックする可能性がある場合、および完全な再計算を実行する代わりに更新を失敗させるかどうかを制御します。

REFRESH POLICYを使用して、システムを次のように構成できます。

AUTO (既定値) - コストベースの自動選択を使用します。 Databricks は、効率とクエリ機能に基づいて増分更新または完全更新を選択します。ほとんどのユーザーに推奨されます。
INCREMENTAL - 増分更新を優先します。 Databricks は可能な限り段階的更新を実行します。クエリプランで増分更新がサポートされなくなった場合は、完全更新にフォールバックします。
INCREMENTAL STRICT - 増分更新が厳密に必要です。通常の操作中は増分更新が必要です。増分化できない場合、更新または作成操作は失敗します。
FULL - 常に完全な更新を実行します。クエリが増分可能な場合でも、Databricks は増分更新を実行しません。

SQL

-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Python

from pyspark import pipelines as dp

@dp.materialized_view(
  refresh_policy = 'incremental_strict'
)
def my_mv():
  return spark.read("main.default.source_table")

最適な更新ポリシーは、ワークロードの特性によって異なります。

AUTO は、ほとんどのワークロードに適しています。コストとパフォーマンスのバランスを取り、クエリの動作が変化したときに自動的に適応します。
INCREMENTAL は、増分更新が利点を提供する場合に便利ですが、増分化が一時的に使用できなくなった場合 (ソーステーブルの行追跡がオフになっている場合など) に、Azure Databricks で完全な更新を実行できます。
INCREMENTAL STRICT は、コスト、パフォーマンス、または SLA の制約を満たすために増分更新が必要であり、予期しない完全更新が許容できない場合に使用する必要があります。このポリシーは、ユーザーが更新を失敗させる場合に推奨され、完全な更新を続行するのではなく、問題をデバッグできます。
FULL は、増分更新の利点がほとんどない場合、データセットが小さい場合、またはクエリ構造が増分化を妨げる方法で頻繁に変更される場合に適しています。

詳細と構文については、REFRESH POLICY 句 (パイプライン) を参照してください。データセットが Databricks SQL で定義されている場合は、POLICY 句REFRESH。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-02-26

次の方法で共有

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

サーバーレス コンピューティング実行されます

マテリアライズド ビューの更新セマンティクスとは

SQL

Python

マテリアライズド ビューのデータ ソースに関する考慮事項

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

マテリアライズド ビューの更新の種類

既定のリフレッシュ

完全更新

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

更新プログラムの更新の種類を決定する

ポリシーの更新

SQL

Python

フィードバック

その他のリソース

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

サーバーレスコンピューティング実行されます

マテリアライズドビューの更新セマンティクスとは

マテリアライズドビューのデータソースに関する考慮事項

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

マテリアライズドビューの更新の種類

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