Gründe für die Partitionierung von Tabellen in Azure Databricks

Hinweis

Databricks empfiehlt flüssiges Clustering für alle verwalteten Tabellen. Bei verwalteten Tabellen mit Apache Iceberg unterstützt Unity Catalog nur flüssiges Clustering und interpretiert PARTITION BY Spalten als Clusterschlüssel. Siehe Eine partitionierte Tabelle in Liquid Clustering konvertieren.

Die meisten Tabellen auf Azure Databricks mit weniger als 100 TB Daten benötigen keine Partitionierung. Azure Databricks verwendet Delta Lake standardmäßig für alle Tabellen und gruppiert automatisch Daten in nicht partitionierten Tabellen nach Erfassungszeit, sodass Sie partitionsähnliche Leistung ohne manuelle Optimierung erhalten. Berücksichtigen Sie eine benutzerdefinierte Partitionierungsstrategie nur, wenn sie diese Standardwerte übertrifft. Siehe Verwendung der Erfassungszeit-Klusterung.

Benutzerdefinierte Partitionierungsstrategien

Erweiterte Benutzer von Apache Spark und Delta Lake identifizieren möglicherweise eine Partitionierungsstrategie, die die standardmäßige Erfassungszeitclustering übertrifft.

Warnung

Eine ineffektive Partitionierungsstrategie wirkt sich möglicherweise negativ auf die Abfrageleistung aus und erfordert ein vollständiges Umschreiben von Daten zum Beheben. Eine vollständige Neuschreibung kann sehr teuer und langsam für große Tabellen sein.

Vor der Verwendung von benutzerdefinierten Partitionierungsstrategien empfiehlt Databricks das flüssige Clustering für alle Tabellen und die prädiktive Optimierung für verwaltete Tabellen im Unity-Katalog. Siehe Verwenden von Flüssigclustering für Tabellen und Predictive Optimization für verwaltete Tabellen im Unity-Katalog.

Verwenden Sie ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY, um eine vorhandene partitionierte Delta-Lake-Tabelle auf Liquid Clustering umzustellen. Liquid Clustering funktioniert sowohl für Spalten mit niedriger wie auch hoher Kardinalität und umgeht die festen Partitionsgrenzen sowie die bei statischer Partitionierung häufig auftretenden Probleme mit kleinen Dateien. Siehe Eine partitionierte Tabelle in Liquid Clustering konvertieren.

Unterstützte Datentypen für Partitionsspalten

Die Partitionierung unterstützt diese Datentypen für Partitionsspalten:

  • Datum
  • Zeitstempel
  • TimestampNTZ
  • Intervall
  • String
  • Binary
  • Boolean
  • Integer, Long, Short, Byte
  • Float, Double, Dezimal

Partitionsspalten müssen Spalten der obersten Ebene sein. Sie können nicht nach einer der folgenden Optionen partitionieren:

  • Komplexe Typen, wie StructType, MapType, ArrayType oder VariantType
  • Felder einer Struktur, wie struct_col.field. Delta Lake behandelt ein Strukturfeld PARTITIONED BY als Ausdruck und nicht als Spaltenverweis.

Um eine Tabelle nach einem Strukturfeld zu organisieren, verwenden Sie stattdessen liquid clustering, wodurch ein Strukturfeld als Clusterschlüssel erkannt wird. Liquid Clustering ist die einzige Möglichkeit, Daten in einem Strukturfeld zu überspringen, ohne dieses Feld zuvor in eine Spalte der obersten Ebene zu extrahieren. Siehe Verwenden von Flüssigclustering für Tabellen.

Empfohlene Mindestgröße

Die Partitionierung unter diesen Mindestgrößen wirkt sich wahrscheinlich negativ auf die Abfrageleistung aus, anstatt sie zu verbessern. Beachten Sie Folgendes, wenn Sie entscheiden, ob Sie eine Tabelle partitionieren sollten:

  • Für Tabellen:
    • Bei weniger als 1 TB Daten müssen Sie nicht partitionieren.
    • Verwenden Sie mit mehr als 1 TB bis 100 TB Daten flüssigen Clustering anstelle der Partitionierung. Die Partitionierung wirkt sich wahrscheinlich häufiger auf die Leistung aus, als dies hilft.
    • Bei 100 TB oder mehr Daten kann die Partitionierung die Leistung verbessern. Databricks empfiehlt jedoch, zuerst liquid clustering zu verwenden und Leistungsverbesserungen zu überprüfen.
  • Überprüfen Sie bei Partitionen, ob jede Partition mindestens 1 GB Daten enthält. Tabellen mit weniger, größeren Partitionen sind tendenziell leistungsfähiger als Tabellen mit vielen kleineren Partitionen.

Gruppierung nach Ingestionszeit verwenden

Bei Verwendung von Delta Lake nutzen nicht partitionierte Tabellen automatisch Clustering nach Erfassungszeit. Der Zeitpunkt der Datenerfassung verbessert die Abfrageleistung ähnlich wie Partitionierungsstrategien mit Datums-/Uhrzeitfeldern, ohne dass Ihre Daten manuell optimiert oder abgestimmt werden müssen.

Hinweis

Um die Aufnahmezeit beim Clustering beizubehalten, wenn eine große Anzahl von Änderungen mithilfe von UPDATE- oder MERGE-Anweisungen für eine Tabelle durchgeführt wird, empfiehlt Databricks die Verwendung von Liquid Clustering in einer Spalte, die der Aufnahmereihenfolge entspricht, z. B. einem Ereigniszeitstempel oder einem Erstellungsdatum. Siehe Verwenden von Flüssigclustering für Tabellen.

Kompatibilität von Delta Lake und Parquet-Partitionierung

Delta Lake verwendet Parquet zum Speichern von Daten, und einige partitionierte Delta-Lake-Tabellen haben Datenlayouts, die denen von mit Apache Spark gespeicherten Parquet-Tabellen ähneln. Apache Spark verwendet die Partitionierung im Hive-Stil, wenn Daten im Parquet-Format gespeichert werden. Die Partitionierung im Hive-Stil ist nicht Teil des Delta-Lake-Protokolls, und Workloads sollten sich nicht auf diese Partitionierungsstrategie verlassen, um mit Delta-Lake-Tabellen zu interagieren.

Databricks empfiehlt, mit Daten zu interagieren, die in Delta Lake gespeichert sind, indem Sie offiziell unterstützte Clients und APIs verwenden. Viele Delta-Lake-Funktionen durchbrechen Annahmen über das Datenlayout, die möglicherweise Parquet, Hive oder sogar älteren Versionen des Delta-Lake-Protokolls zugrunde lagen.

Hinweis

Wenn Sie die Spaltenzuordnung für eine Delta Lake-Tabelle aktivieren, ersetzen zufällige Präfixe Spaltennamen in Partitionsverzeichnissen für die Partitionierung im Hive-Stil. Weitere Informationen finden Sie unter Rename and drop columns with Delta Lake column mapping (Umbenennen und Löschen von Spalten mit Delta Lake-Spaltenzuordnung).

Delta-Lake-Partitionierung im Vergleich zu anderen Data Lakes

Partitionierungstechniken, die in anderen Open-Source-Technologien (wie Apache Spark, Parquet, Hive und Hadoop) nützlich sind, gelten nicht immer auch für Azure Databricks. Wenn Sie die Tabelle partitionieren möchten, beachten Sie Folgendes:

  • Transaktionen werden nicht durch Partitionsgrenzen definiert. Da Delta Lake ACID durch Transaktionsprotokolle gewährleistet, müssen Sie einen Batch von Daten nicht nach einer Partition aufteilen, um die Atomität zu garantieren.
  • Azure Databricks-Computecluster weisen keine Datenort auf, der an physische Medien gebunden ist. Im Lakehouse erfasste Daten werden im Cloudobjektspeicher gespeichert. Während Daten während der Datenverarbeitung im lokalen Datenträgerspeicher zwischengespeichert werden, verwendet Azure Databricks dateibasierte Statistiken, um die Datenmindestmenge für das parallele Laden zu identifizieren.

Z-Reihenfolge und Partitionen

Hinweis

Databricks empfiehlt für alle neuen Tabellen die Verwendung von Liquid Clustering anstelle von Z-Sortierung. Siehe Verwenden von Flüssigclustering für Tabellen.

Sie können Z-Sortierungs-Indizes zusammen mit Partitionen verwenden, um Abfragen an große Datasets zu beschleunigen. Die meisten Tabellen verwenden Clustering nach Erfassungszeit, damit Z-order und Partitionen nicht abgestimmt werden müssen.

Beachten Sie die folgenden Regeln, wenn Sie eine Abfrageoptimierungsstrategie basierend auf Partitionsgrenzen und Z-Reihenfolge planen:

  • Für die Z-Reihenfolge ist der OPTIMIZE Befehl erforderlich. Sie können Dateien nicht über Partitionsgrenzen hinweg kombinieren, weshalb Z-Sortierungsgruppierung nur innerhalb einer Partition erfolgen kann. Bei nicht partitionierten Tabellen können Dateien in der gesamten Tabelle kombiniert werden.
  • Die Partitionierung funktioniert nur für Felder mit niedriger oder bekannter Kardinalität (z. B. Datumsfelder oder physische Speicherorte) gut, aber nicht für Felder mit hoher Kardinalität wie Zeitstempel. Die Z-Sortierung funktioniert für alle Felder, einschließlich Feldern mit hoher Kardinalität und Feldern, die unendlich wachsen können (z. B. Zeitstempel oder die Kunden-ID in einer Tabelle mit Transaktionen oder Aufträgen).
  • Sie können keine Z-Sortierung nach Feldern ausführen, die für die Partitionierung verwendet werden.

So optimieren Azure Databricks vorhandene Partitionen

Viele Kunden migrieren von Parquet-basierten Data Lakes zu Delta Lake, z. B. indem sie die Anweisung CONVERT TO DELTA verwenden, um eine vorhandene Parquet-basierte Tabelle in eine Delta-Lake-Tabelle zu konvertieren, ohne vorhandene Daten neu zu schreiben. Da die Konvertierung vorhandene Daten nicht neu schreibt, erben große Tabellen möglicherweise vorherige Partitionierungsstrategien.

Einige Databricks-Optimierungen verwenden diese Partitionen nach Möglichkeit und verringern negative Leistungseffekte für Partitionierungsstrategien, die nicht für Delta Lake optimiert sind.

Delta Lake und Apache Spark sind Open-Source-Technologien. Während Databricks Features aufweist, die die Abhängigkeit von Partitionierung reduzieren, kann die Open Source Community neue Features erstellen, die Komplexität hinzufügen.

  • Last updated on