EXPLAIN CREATE MATERIALIZED VIEW

Gilt für: Ja angekreuzt Databricks SQL Ja angekreuzt Databricks Runtime 17.3 und höher

Berichtet, ob die Abfrage für eine materialisierte Ansicht schrittweise aktualisiert werden kann. Stellen EXPLAIN Sie eine CREATE MATERIALIZED VIEW Erklärung vor, um die Inkrementalisierungsberechtigung zu prüfen, bevor Sie die materialisierte Ansicht erstellen oder eine teure Aktualisierung durchführen.

Um mehr über die Inkrementierung der materialisierten Ansicht zu erfahren, siehe Inkrementelle Aktualisierung für materialisierte Ansichten.

Welche EXPLAIN Berichte

EXPLAIN CREATE MATERIALIZED VIEW prüft, ob die Abfrage strukturell für eine inkrementelle Aktualisierung geeignet ist. Der Incremental Update Eligibility Abschnitt der Ausgabe berichtet eines von zwei Ergebnissen:

• The Materialized View can be incrementally refreshed: Das Abfragemuster unterstützt eine inkrementelle Aktualisierung.
• The Materialized View cannot be incrementally refreshed: Die Abfrage ist strukturell nicht für eine inkrementelle Aktualisierung geeignet. Unter den AUTO und FULL Aktualisierungsrichtlinien verwendet die materialisierte Ansicht eine vollständige Neuberechnung. Unter INCREMENTAL oder INCREMENTAL STRICTfehlschlägt die CREATE Wiederholung, weil inkrementelle Aktualisierung nicht möglich ist. Der Abschnitt listet Detailed Incrementalization Info auf, was die Inkrementalisierung verhindert.

Die strukturelle Berechtigung garantiert nicht, dass eine inkrementelle Aktualisierung ausgeführt wird. Unter der Standard-Aktualisierungsrichtlinie AUTO trifft das Kostenmodell die endgültige Entscheidung zur Laufzeit und kann weiterhin eine vollständige Neuberechnung für eine geeignete materialisierte Ansicht wählen. Details finden Sie unter Berechtigung und Laufzeitverhalten.

Empfohlene Verwendung von EXPLAIN

Ausführen EXPLAIN CREATE MATERIALIZED VIEW:

• Bevor Sie eine neue materialisierte Ansicht bereitstellen, sollten Sie überprüfen, ob das Abfragemuster eine schrittweise Aktualisierung unterstützt.
• Wenn du langsame Aktualisierungen debuggst, um zu bestätigen, dass die materialisierte Ansicht zulässig ist. Wenn nicht, schreibe die Abfrage neu.
• Nachdem Sie eine Abfrage neu geschrieben haben, um zu überprüfen, ob die neue Version zulässig ist.
• Wenn Sie von DBT oder einem anderen Tool migrieren, um zu überprüfen, dass die transformierten Abfragen von inkrementeller Aktualisierung profitieren.

Syntax

EXPLAIN [CREATE MATERIALIZED VIEW query]

Die Parameter

• query

  Eine SQL-Abfrage, die eine materialisierte Ansicht erstellt. Folgen EXPLAIN Sie der Anfrage.

  Hinweis

  CREATE MATERIALIZED VIEW Abfragen von Lakeflow-Pipelines funktionieren möglicherweise nicht ohne EXPLAIN Aktualisierung. Beispiel:

  • Erwartungen (CONSTRAINT...EXPECT Klauseln) müssen aus der Abfrage entfernt werden.
  • Quelldatensätze müssen möglicherweise mit einem Katalog, schema oder einem anderen Pfad qualifiziert werden, der beim Ausführen im Kontext einer Pipeline nicht erforderlich ist.

Examples

Die folgenden Beispiele zeigen die Ausgabe für eine zulässige Abfrage und für zwei Abfragen, die nicht schrittweise aktualisiert werden können.

Für inkrementelle Aktualisierungen berechtigt

Eine Abfrage, die einen Filter, eine Projektion und eine Aggregation auf eine Delta Lake-Tabelle anwendet, ist zulässig:

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.

Nicht zulässig: Verwendung LIMIT

Eine Abfrage, die verwendet LIMIT , ist nicht inkrementalisierbar, da Grenzwertoperatoren nicht inkrementell gepflegt werden können:

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.

Nicht berechtigt: Quelle außerhalb des Delta Lake

Eine Abfrage, die aus einer Nicht-Delta Lake-Quelle liest, wie CSV-Dateien, ist nicht inkrementellierbar:

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.

Berechtigung und Laufzeitverhalten

EXPLAIN Berichtet, ob die Abfragestruktur eine inkrementelle Aktualisierung unterstützt. Er sagt nicht voraus, was der Optimierer zur Laufzeit tut. Unter dem Standard REFRESH POLICY AUTOtrifft das Kostenmodell die endgültige Entscheidung und kann auch für eine geeignete materialisierte Ansicht eine vollständige Neuberechnung wählen, zum Beispiel wenn es schätzt, dass Operatorverschachtelung oder das aktuelle Datenvolumen eine vollständige Neuberechnung effizienter macht. Für die vollständige Liste der Aktualisierungsrichtlinien siehe Aktualisierungsrichtlinie.

Wenn eine berechtigte materialisierte Ansicht konsequent vollständige Neuberechnung unter AUTOverwendet, können Sie:

• Wähle REFRESH POLICY INCREMENTAL eine inkrementelle Aktualisierung gegenüber der kostenbasierten Wahl. Für die Syntax siehe REFRESH Klausel POLICY.
• Überprüfen Sie das Pipeline-Ereignisprotokoll auf Ereignisse INCREMENTAL_PLAN_REJECTED_BY_COST_MODEL , um zu verstehen, warum das Kostenmodell den inkrementellen Plan abgelehnt hat. Für Details siehe Pipeline-Ereignisprotokoll und die CostModelRejectionSubType Werte im Pipeline-Ereignisprotokoll-Schema.

Häufige Gründe für eine Ablehnung von Kostenmodellen sind:

• EXCESSIVE_OPERATOR_NESTING: Die Abfragedefinition ist komplex und weist viele Ebenen von Operatorverschachtelung auf, die das Kostenmodell für inkrementelle Verarbeitung als riskant betrachtet.
• CHANGESET_SIZE_THRESHOLD_EXCEEDED und TABLE_SIZE_THRESHOLD_EXCEEDED: Das Kostenmodell schätzt, dass eine vollständige Neuberechnung für das aktuelle Datenvolumen günstiger ist.

Eine Ablehnung des Kostenmodells bedeutet nicht, dass die materialisierte Sichtweise nicht inkrementellisieren kann. Das bedeutet, dass der Optimierer sich dagegen entschieden hat. Setting REFRESH POLICY INCREMENTAL ist eine unterstützte Möglichkeit, diese Entscheidung zu überschreiben.