次の方法で共有

具体化されたビューの増分更新

この記事では、具体化されたビューでの増分更新のセマンティクスと要件の概要を説明し、増分更新をサポートする 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 製品では、最後のクエリの実行後にデータ ソースが変更されていない場合、セッション内またはセッション間で結果が自動的にキャッシュされます。 自動キャッシュ動作は、具体化されたビューとは異なります。

次の例では、このバッチ クエリを具体化されたビューに変換します。

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

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

具体化されたビューのデータ ソースに関する考慮事項

具体化されたビューは任意のデータ ソースに対して定義できますが、すべてのデータ ソースが具体化されたビューに適しているわけではありません。 次の注意事項と推奨事項を検討してください。

Important

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

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

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

具体化されたビューを最適化する

最適なパフォーマンスを得るために、Databricks では、すべての具体化されたビュー ソース テーブルで次の機能を有効にすることをお勧めします。

これらの機能は、作成時に設定することも、後で ALTER TABLE ステートメントを使用して設定することもできます。 例えば次が挙げられます。

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 のキーワードまたは句 増分更新のサポート
SELECT 式* はい、決定論的組み込み関数、不変ユーザー定義関数 (UDF) などの式がサポートされています。
GROUP BY Yes
WITH はい。共通テーブル式はサポートされています。
UNION ALL* Yes
FROM サポートされているベース テーブルには、Delta テーブル、具体化されたビュー、ストリーミング テーブルが含まれます。
WHERE、HAVING* WHERE や HAVING などのフィルター句はサポートされています。
INNER JOIN* Yes
LEFT OUTER JOIN* Yes
FULL OUTER JOIN* Yes
RIGHT OUTER JOIN* Yes
OVER Yes. ウィンドウ関数の増分には、PARTITION_BY 列を指定する必要があります。
QUALIFY Yes
EXPECTATIONS はい。期待を含む具体化されたビューは、増分更新できます。 ただし、次の場合、増分更新はサポートされていません。
  • 具体化されたビューが期待値を含むビューから読み取る場合。
  • 具体化されたビューに DROP 期待値があり、スキーマに NOT NULL 列が含まれている場合。
非決定論的関数 非決定的時間関数は、 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.

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

ポリシーの更新

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

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

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

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

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

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