Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Note
In Databricks Runtime 13.3 und höher empfiehlt Databricks die Verwendung flüssiger Clustering für das Tabellenlayout. Das Clustering ist nicht mit der Z-Reihenfolge kompatibel. Siehe Verwenden von Flüssigclustering für Tabellen.
Datensprungstatistiken werden automatisch gesammelt, wenn Sie Daten in einen Delta Lake oder eine verwaltete Apache Iceberg-Tabelle schreiben. Azure Databricks verwendet pro Datei Statistiken (Mindest- und Höchstwerte, Nullanzahl und Gesamtdatensätze) zur Abfragezeit, um irrelevante Dateien zu überspringen und Abfragen zu beschleunigen.
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?.
Statistikspalten angeben
Bei externen Tabellen im Unity-Katalog werden Statistiken für die ersten 32 Spalten gesammelt, die standardmäßig in Ihrem Tabellenschema definiert sind. Bei verwalteten Tabellen des Unity-Katalogs werden statistische Dateisprungdaten mithilfe prädiktiver Optimierung intelligent ausgewählt und unterliegen keinem Limit von 32 Spalten. Predictive Optimization führt ANALYZE automatisch aus, einen Befehl zum Sammeln von Statistiken. 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.
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:
| Tabelleneigenschaft | Databricks Runtime unterstützt | Description |
|---|---|---|
dataSkippingNumIndexedCols |
Alle unterstützten Databricks Runtime-Versionen | Erhöhen oder verkleinern Sie die Anzahl der Spalten, für die Statistiken gesammelt werden. Hängt von der Spaltenreihenfolge ab. |
dataSkippingStatsColumns |
Databricks Runtime 13.3 LTS und höher | Geben Sie eine Liste von Spaltennamen an, für die Statistiken gesammelt werden. Hat Vorrang vor dataSkippingNumIndexedCols. |
Tabelleneigenschaften können bei der Tabellenerstellung oder mit ALTER TABLE-Anweisungen festgelegt werden. Siehe Referenz zu Tabelleneigenschaften. Im folgenden Beispiel wird das Standardverhalten der Statistikensammlung überschrieben, um die Statistikauflistung für benannte Spalten festzulegen:
Delta Lake
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')
Eisbergtisch
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')
Das Aktualisieren dieser Eigenschaften führt nicht dazu, dass Statistiken für vorhandene Daten automatisch neu berechnet werden. Stattdessen wirkt sich dies auf das Verhalten einer zukünftigen Statistiksammlung aus, wenn Daten in der Tabelle hinzugefügt oder aktualisiert werden. Statistiken werden nicht für Spalten verwendet, 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 Tabelle mithilfe des folgenden Befehls manuell auslösen:
ANALYZE TABLE table_name COMPUTE DELTA STATISTICS
Note
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?
Note
Databricks empfiehlt die Verwendung von Flüssigclustering für alle neuen Tabellen. Sie können ZORDER nicht in Kombination mit Liquid Clustering verwenden. Siehe Verwenden von Flüssigclustering für Tabellen.
Z-Ordering ist eine Technik, um zusammengehörige Informationen in derselben Dateigruppe gemeinsam abzulegen. Azure Databricks-Datenübersprungs-Algorithmen nutzen diese Kolokalität automatisch aus. Dieses Verhalten reduziert die Datenmenge, die gelesen werden muss. Geben Sie für Z-Reihenfolge-Daten die Spalten an, die in der ZORDER BY Klausel sortiert werden sollen:
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. Die Effektivität fällt jedoch bei jeder zusätzlichen Spalte ab.
Databricks empfiehlt, dass Sie nicht für Spalten verwenden ZORDER BY , die keine Statistiken gesammelt haben, da sie ineffektiv ist und unnötige Computeressourcen verwendet. Das Überspringen von Daten erfordert spaltenbezogene Statistiken wie Minimum, Maximum und Anzahl. 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.
Note
Die Z-Reihenfolge ist nicht idempotent, sondern zielt darauf ab, ein inkrementeller Vorgang zu sein. Die für die Z-Sortierung benötigte Zeit nimmt bei mehreren Durchläufen nicht garantiert ab. Wenn jedoch keine neuen Daten zu einer Partition hinzugefügt wurden, die nur Z-geordnet war, hat eine andere Z-Sortierung dieser Partition keine Auswirkung.
Die Z-Sortierung zielt darauf ab, gleichmäßig ausgeglichene Datendateien in Bezug auf die Anzahl der Tupel, aber nicht unbedingt die Datengröße im Speicher zu erzeugen. Obwohl Dateigrößen und die Anzahl der Tupel miteinander korrelieren, kann es Situationen geben, in denen dies nicht der Fall ist, was die Laufzeiten von Optimierungsaufgaben verzerrt.
Wenn Sie beispielsweise
ZORDER BYdate verwenden und Ihre neuesten Datensätze alle deutlich umfangreicher sind (etwa durch längere Arrays oder Zeichenfolgenwerte) als die früheren,OPTIMIZEkönnten die Aufgabendauern des Jobs und die resultierenden Dateigrößen verzerrt sein. Dies ist jedoch nur ein Problem für denOPTIMIZEBefehl selbst. Es hat wahrscheinlich keine negativen Auswirkungen auf nachfolgende Abfragen.