EXPLAIN CREATE MATERIALIZED VIEW

適用対象:チェックマーク付き：はい Databricks SQL チェックマーク付き：はい Databricks Runtime 17.3 以降

マテリア化されたビューのクエリがインクリメンタルで更新可能かどうかを報告します。 マテリアライズされたビューを作成したり、高価なリフレッシュを実行する前に、インクリメンタライゼーションの適格性を確認するためにEXPLAINCREATE MATERIALIZED VIEW文の前に付け加えてください。

具体化ビューの増分化に関する詳細は、「具体化ビューの増分更新」をご覧ください。

報告 EXPLAIN 内容

EXPLAIN CREATE MATERIALIZED VIEW クエリが 構造的に インクリメンタルリフレッシュの対象かどうかを確認します。 出力の Incremental Update Eligibility セクションでは、2つの結果のいずれかが報告されています。

  • The Materialized View can be incrementally refreshedクエリパターンはインクリメンタルリフレッシュに対応しています。
  • The Materialized View cannot be incrementally refreshed: クエリは構造的にインクリメンタルリフレッシュの対象外です。 AUTOおよびFULLリフレッシュポリシーの下で、マテリアライズドビューは完全な再計算を使用します。 INCREMENTALまたはINCREMENTAL STRICTでは、インクリメンタルリフレッシュが不可能であるためCREATEが失敗します。 Detailed Incrementalization Infoセクションには、インクリメンタリゼーションを防ぐ要因が記載されています。

構造的適格性は、インクリメンタルリフレッシュが必ず実行される保証ではありません。 デフォルトの AUTO リフレッシュポリシーでは、コストモデルが実行時に最終決定を行い、対象となるマテリアライズドビューに対して完全な再計算を選択することができます。 詳細は「 適格性および実行時の動作」を参照してください。

どのようなときに EXPLAIN を使用するか

EXPLAIN CREATE MATERIALIZED VIEWを実行します。

  • 新しいマテリアル化されたビューを展開する前に、クエリパターンがインクリメンタルリフレッシュに対応しているか確認してください。
  • デバッグ時に遅い更新を行い、物質化されたビューが対象かどうかを確認しましょう。 もし違うなら、クエリを書き直してください。
  • クエリを書き直した後、新しいバージョンが適格かどうかを確認しましょう。
  • dbtや他のツールから移行する際には、変換されたクエリがインクリメンタルリフレッシュの恩恵を受けているか検証します。

構文

EXPLAIN [CREATE MATERIALIZED VIEW query]

パラメーター

  • クエリ

    具体化されたビューを作成する SQL クエリ。 質問の前に付け EXPLAIN 。

    注

    CREATE MATERIALIZED VIEW Lakeflow パイプラインからのクエリは、更新なしで EXPLAIN で動作しない可能性があります。 例えば次が挙げられます。

    • 期待値 (CONSTRAINT...EXPECT 句) をクエリから削除する必要があります。
    • ソース データセットは、パイプラインのコンテキストで実行するときに不要なカタログ、スキーマ、またはその他のパスで修飾する必要がある場合があります。

例示

以下の例は、適格なクエリと、増分的にリフレッシュできない2つのクエリの出力を示しています。

インクリメンタルリフレッシュの対象

デルタ湖テーブルにフィルター、投影、集計を適用するクエリは以下の条件を満たします:

EXPLAIN CREATE MATERIALIZED VIEW sales_summary AS
SELECT region, SUM(revenue) AS total_revenue, COUNT(*) AS order_count
FROM catalog.schema.orders
WHERE order_date >= '2024-01-01'
GROUP BY region;

== Incremental Update Eligibility ==
The Materialized View can be incrementally refreshed.

== Detailed Incrementalization Info ==
No issues detected.

対象外:用途 LIMIT

LIMIT を使うクエリは増分化できません。なぜなら極限演算子は増分的に維持できないからです。

EXPLAIN CREATE MATERIALIZED VIEW top_customers AS
SELECT customer_id, total_spend
FROM catalog.schema.customer_summary
ORDER BY total_spend DESC
LIMIT 100;

== Incremental Update Eligibility ==
The Materialized View cannot be incrementally refreshed.

== Detailed Incrementalization Info ==
- OPERATOR_NOT_INCREMENTALIZABLE: Operators GlobalLimit, LocalLimit are not incrementalizable. Consider rewriting the query to avoid using them.

対象外:デルタ湖以外の供給源

CSVファイルなど、デルタレイク以外のソースから読み取るクエリは、インクリメンタル化できません。

EXPLAIN CREATE MATERIALIZED VIEW external_data AS
SELECT * FROM csv.`/path/to/files/`;

== Incremental Update Eligibility ==
The Materialized View cannot be incrementally refreshed.

== Detailed Incrementalization Info ==
- INPUT_NOT_IN_DELTA: Tables are not in Delta format. Consider converting them to Delta tables.

適格性と実行時の動作

EXPLAIN クエリ構造がインクリメンタルリフレッシュに対応しているかどうかを報告します。 実行時にオプティマイザーが何をするかを予測するわけではありません。 デフォルトの REFRESH POLICY AUTOでは、コストモデルが最終決定を行い、例えば演算子のネストや現在のデータ量が完全な再計算を効率化すると推定する場合など、対象となる物質化されたビューに対しても完全な再計算を選択できます。 リフレッシュポリシーの全リストについては「 リフレッシュポリシー」をご覧ください。

対象となるマチャライズドビューが AUTOの下で一貫して完全な再計算を用いる場合、以下が可能です:

  • REFRESH POLICY INCREMENTALコストベースの選択よりも増分リフレッシュを優先するように設定してください。 構文については、 REFRESH POLICY節を参照してください。
  • パイプラインイベントログで INCREMENTAL_PLAN_REJECTED_BY_COST_MODEL イベントを確認し、なぜコストモデルがインクリメンタルプランを却下したのか理解してください。 詳細については、パイプラインイベントログおよびパイプラインイベントログスキーマの CostModelRejectionSubType 値をご参照ください。

一般的なコストモデルの却下理由には以下があります:

  • EXCESSIVE_OPERATOR_NESTINGクエリの定義は複雑で、多くのオペレーターのネストレベルがあり、コストモデルは増分処理においてリスクが高いと考えています。
  • CHANGESET_SIZE_THRESHOLD_EXCEEDED TABLE_SIZE_THRESHOLD_EXCEEDED:コストモデルは現在のデータ量に対して完全な再計算の方が安価であると推定します。

コストモデルのリジェクションは、具現化された視点が増分化できないという意味ではありません。 それは最適化側がそうしなかったことを意味します。 設定 REFRESH POLICY INCREMENTAL はその選択を上書きするサポートされた方法です。

  • Last updated on