Überspringen von Daten für Delta Lake

  • Artikel

Hinweis

In Databricks Runtime 13.3 und höher empfiehlt Databricks die Verwendung von Liquid Clustering für das Delta-Tabellenlayout. Das Clustering ist nicht mit der Z-Reihenfolge kompatibel. Weitere Informationen finden Sie unter Verwenden von Liquid Clustering für Delta-Tabellen.

Informationen zum Überspringen von Daten werden automatisch gesammelt, wenn Sie Daten in eine Delta-Tabelle schreiben. Delta Lake in Azure Databricks nutzt diese Informationen (Mindest- und Höchstwerte, NULL-Anzahl und Gesamtanzahl der Datensätze pro Datei) zur Abfragezeit, um schnellere Abfragen zu ermöglichen.

Für Spalten, die in ZORDER-Anweisungen verwendet werden, müssen Statistiken gesammelt werden. Weitere Informationen finden Sie unter Worum handelt es sich bei der Z-Reihenfolge?.

Angeben von Delta-Statistikspalten

Delta Lake erfasst standardmäßig Statistikinformationen für die ersten 32 Spalten, die in Ihrem Tabellenschema definiert sind. Wenn die Vorhersageoptimierung aktiviert ist, werden Dateisprungstatistiken intelligent ausgewählt und sind nicht auf die ersten 32 Spalten beschränkt. Die Predictive Optimization wird automatisch ausgeführt ANALYZE, ein Befehl zum Sammeln von Statistiken in verwalteten Tabellen im Unity-Katalog. Databricks empfiehlt die Aktivierung der prädiktiven Optimierung für alle verwalteten Tabellen in Unity Catalog, um die Datenwartung zu vereinfachen und die Speicherkosten zu senken. Siehe Prädiktive Optimierung für verwaltete Unity Catalog-Tabellen.

Wichtig

Predictive optimization with ANALYZE is in Public Preview. Sie enthält eine intelligente Statistiksammlung während der Schreibvorgänge. Verwenden Sie dieses Formular , um sich für die öffentliche Vorschau anzumelden.

Wenn Sie keine prädiktive Optimierung verwenden, können Sie das Verhalten ändern, das Statistikensammlungen auf 32 Spalten beschränkt, indem Sie eine der folgenden Tabelleneigenschaften festlegen:

Table-Eigenschaft Unterstützte Databricks Runtime-Version Beschreibung
delta.dataSkippingNumIndexedCols Alle unterstützten Databricks Runtime-Versionen Erhöhen oder verringern Sie die Anzahl der Spalten, für die Delta Statistiken sammelt. Hängt von der Spaltenreihenfolge ab.
delta.dataSkippingStatsColumns Databricks Runtime 13.3 LTS und höher Geben Sie eine Liste von Spaltennamen an, für die Delta Lake Statistiken sammelt. Hat Vorrang vor dataSkippingNumIndexedCols.

Tabelleneigenschaften können bei der Tabellenerstellung oder mit ALTER TABLE-Anweisungen festgelegt werden. Weitere Informationen finden Sie unter Referenz zu Delta-Tabelleneigenschaften.

Durch das Aktualisieren dieser Eigenschaften werden statistiken für vorhandene Daten nicht automatisch neu kompensiert. Stattdessen wirkt sich dies auf das Verhalten einer zukünftigen Statistiksammlung aus, wenn Daten in der Tabelle hinzugefügt oder aktualisiert werden. Delta Lake nutzt keine Statistiken für Spalten, die nicht in der aktuellen Liste der Statistikspalten enthalten sind.

Wenn Sie in Databricks Runtime 14.3 LTS und höher die Tabelleneigenschaften geändert oder die angegebenen Spalten für Statistiken geändert haben, können Sie die Neukompilierung von Statistiken für eine Delta-Tabelle mithilfe des folgenden Befehls manuell auslösen:

ANALYZE TABLE table_name COMPUTE DELTA STATISTICS

Hinweis

Lange Zeichenfolgen werden während der Statistiksammlung abgeschnitten. Sie können lange Zeichenfolgenspalten aus der Statistiksammlung ausschließen, insbesondere, wenn die Spalten nicht häufig zum Filtern von Abfragen verwendet werden.

Worum handelt es sich bei der Z-Reihenfolge?

Hinweis

Databricks empfiehlt Liquid Clustering für alle neuen Delta-Tabellen. Sie können ZORDER nicht in Kombination mit Liquid Clusterung verwenden.

Die Z-Reihenfolge ist eine Technik für die Colocation von zusammengehörigen Informationen im selben Satz von Dateien. Diese Colocation wird von den Delta Lake in Azure Databricks-Algorithmen zum Überspringen von Daten automatisch genutzt. Dieses Verhalten reduziert erheblich die Menge an Daten, die Delta Lake in Azure Databricks lesen muss. Wenn Daten in der Z-Reihenfolge sortiert werden sollen, geben Sie die Spalten, nach denen sortiert werden soll, in der ZORDER BY-Klausel an:

OPTIMIZE events
WHERE date >= current_timestamp() - INTERVAL 1 day
ZORDER BY (eventType)

Wenn Sie erwarten, dass eine Spalte häufig in Abfrageprädikaten verwendet wird, und wenn diese Spalte eine hohe Kardinalität aufweist (d. h. eine große Anzahl von eindeutigen Werten), dann verwenden Sie ZORDER BY.

Für ZORDER BY können Sie mehrere Spalten in Form einer durch Kommas getrennten Liste angeben. Allerdings sinkt die Effizienz der Colocation mit jeder zusätzlichen Spalte. Eine Z-Reihenfolge für Spalten, für die keine Statistiken erfasst werden, wäre ineffizient und eine Vergeudung von Ressourcen. Dies liegt daran, dass für das Überspringen von Daten spaltenbezogene Statistiken wie Mindest- und Höchstwerte sowie Anzahl erforderlich sind. Sie können die Statistikerfassung für bestimmte Spalten konfigurieren, indem Sie die Spalten im Schema neu anordnen oder die Anzahl von Spalten erhöhen, für die Statistiken erfasst werden sollen.

Hinweis

  • Die Z-Reihenfolge ist nicht idempotent, sondern zielt darauf ab, ein inkrementeller Vorgang zu sein. Es ist nicht garantiert, dass sich die für die Z-Reihenfolge benötigte Zeit über mehrere Ausführungen hinweg verringert. Wenn jedoch keine neuen Daten zu einer Partition hinzugefügt wurden, auf die kurz zuvor eine Z-Reihenfolge angewendet wurde, hat eine weitere Anwendung der Z-Reihenfolge auf diese Partition keine Auswirkung.

  • Die Z-Reihenfolge zielt darauf ab, gleichmäßige Datendateien in Bezug auf die Anzahl von Tupeln zu erzeugen, aber nicht notwendigerweise in Bezug auf die Datengröße auf dem Datenträger. Die beiden Kennzahlen sind in den meisten Fällen korreliert. Es kann jedoch Situationen geben, in denen dies nicht der Fall ist, was zu Abweichungen bei den Zeiten für die Optimierungsaufgaben führt.

    Wenn Sie beispielsweise ZORDER BY date ausführen und die neuesten Datensätze wesentlich umfangreicher sind (z. B. längere Arrays oder Zeichenfolgen) als die vorherigen, ist zu erwarten, dass die Aufgabendauer des OPTIMIZE-Auftrags sowie die resultierenden Dateigrößen abweichen. Dies ist jedoch nur ein Problem für den Befehl OPTIMIZE selbst, es sollten sich keine negativen Auswirkungen für nachfolgende Abfragen ergeben.