Überspringen von Daten

Hinweis

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.

Datensprunginformationen werden automatisch gesammelt, wenn Sie Daten in eine Tabelle schreiben. Azure Databricks nutzt diese Informationen (Mindest- und Höchstwerte, NULL-Anzahl und Gesamtdatensätze pro Datei) zur Abfragezeit, um schnellere Abfragen bereitzustellen.

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 wird automatisch ausgeführt ANALYZE, ein 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:

Table-Eigenschaft	Unterstützte Databricks Runtime-Version	Beschreibung
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:

-- For Delta tables
ALTER TABLE table_name SET TBLPROPERTIES('delta.dataSkippingStatsColumns' = 'col1, col2, col3')

-- For Iceberg tables
ALTER TABLE table_name SET TBLPROPERTIES('iceberg.dataSkippingStatsColumns' = 'col1, col2, col3')

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. Statistiken werden nicht für Spalten genutzt, 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

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 die Verwendung von Flüssigclustering für alle neuen Tabellen. Sie können ZORDER nicht in Kombination mit Liquid Clusterung verwenden. Siehe Verwenden von Flüssigclustering für Tabellen.

Die Z-Reihenfolge ist eine Technik für die Colocation von zusammengehörigen Informationen im selben Satz von Dateien. 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. 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 ZORDER BYdaten und Ihre letzten Datensätze viel breiter sind (z. B. längere Arrays oder Zeichenfolgenwerte) als die in der Vergangenheit, wird erwartet, dass die OPTIMIZE Vorgangsdauer des Auftrags verzerrt wird, ebenso wie die resultierenden Dateigrößen. Dies ist jedoch nur ein Problem für den Befehl OPTIMIZE selbst, es sollten sich keine negativen Auswirkungen für nachfolgende Abfragen ergeben.