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

  • Artikel

Dieser Artikel bietet eine Übersicht darüber, wie Sie Tabellen in Azure Databricks partitionieren können, sowie spezifische Empfehlungen dazu, wann Sie die Partitionierung für Tabellen verwenden sollten, die von Delta Lake unterstützt werden. Aufgrund der integrierten Features und Optimierungen erfordern die meisten Tabellen mit weniger als 1 TB Daten keine Partitionen.

Azure Databricks verwendet Delta Lake standardmäßig für alle Tabellen. Bei den folgenden Empfehlungen wird davon ausgegangen, dass Sie mit für alle Tabellen Delta Lake arbeiten.

In Databricks Runtime 11.3 LTS und höher gruppiert Azure Databricks Daten automatisch nach Erfassungszeit in nicht partitionierten Tabellen. Weitere Informationen finden Sie unter Verwenden der Gruppierung nach Erfassungszeit.

Müssen kleine Tabellen partitioniert werden?

Databricks empfiehlt, keine Tabellen zu partitionieren, die weniger als 1 Terabyte an Daten enthalten.

Was ist die Mindestgröße für jede Partition in einer Tabelle?

Databricks empfiehlt, dass alle Partitionen mindestens 1 Gigabyte an Daten enthalten sollten. Tabellen mit weniger, größeren Partitionen sind tendenziell leistungsfähiger als Tabellen mit vielen kleineren Partitionen.

Verwenden der Gruppierung nach Erfassungszeit

Durch die Verwendung von Delta Lake und Databricks Runtime 11.3 LTS oder höher profitieren nicht partitionierte Tabellen, die Sie erstellen, automatisch von der Gruppierung nach Erfassungszeit. Die Erfassungszeit bietet ähnliche Abfragevorteile wie Partitionierungsstrategien, die auf Datum-Uhrzeit-Feldern (datetime) basieren, ohne dass Ihre Daten optimiert oder abgestimmt werden müssen.

Hinweis

Um die Gruppierung nach Erfassungszeit aufrechtzuerhalten, wenn Sie eine große Anzahl von Änderungen mithilfe von UPDATE oder MERGE vornehmen, empfiehlt Databricks die Ausführung von OPTIMIZE mit ZORDER BY unter Verwendung einer Spalte, die der Erfassungsreihenfolge entspricht. Dies kann beispielsweise eine Spalte sein, die einen Ereigniszeitstempel oder ein Erstellungsdatum enthält.

Teilen Delta Lake und Parquet Partitionierungsstrategien?

Delta Lake verwendet Parquet als primäres Format zum Speichern von Daten, und einige Delta-Tabellen mit angegebenen Partitionen weisen eine ähnliche Organisationen auf wie Parquet-Tabellen, die mit Apache Spark gespeichert werden. 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 nicht auf dieser Partitionierungsstrategie basieren, um mit Delta-Tabellen zu interagieren.

Viele Delta Lake-Features unterbrechen Annahmen über das Datenlayout, die möglicherweise von Parquet-, Hive- oder sogar früheren Delta Lake-Protokollversionen übertragen wurden. Sie sollten immer mit Daten interagieren, die in Delta Lake gespeichert sind, indem Sie offiziell unterstützte Clients und APIs verwenden.

Wie unterscheiden sich Delta Lake-Partitionen von Partitionen in anderen Data Lakes?

Azure Databricks und Delta Lake bauen zwar auf Open-Source-Technologien wie Apache Spark, Parquet, Hive und Hadoop auf, doch die Gründe und Strategien zum Partitionieren, die bei diesen Technologien nützlich sind, gelten nicht auch generell für Azure Databricks. Wenn Sie sich entschließen, Ihre Tabelle zu partitionieren, sollten Sie die folgenden Fakten berücksichtigen, bevor Sie eine Strategie auswählen:

  • Transaktionen werden nicht durch Partitionsgrenzen definiert. Delta Lake stellt ACID über Transaktionsprotokolle sicher, sodass Sie einen Datenbatch nicht durch eine Partition trennen müssen, um die atomische Ermittlung sicherzustellen.
  • 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.

Wie funktionieren Z-Sortierung und Partitionen zusammen?

Sie können Z-Sortierungs-Indizes zusammen mit Partitionen verwenden, um Abfragen an große Datasets zu beschleunigen.

Hinweis

Die meisten Tabellen können das Gruppieren nach Erfassungszeit nutzen, um sich nicht um Z-Sortierung und Partitionsoptimierung Gedanken machen zu müssen.

Die folgenden Regeln sollten Sie bei der Planung einer Abfrageoptimierungsstrategie beachten, die auf Partitionsgrenzen und Z-Sortierung basiert:

  • Die Z-Sortierung funktioniert zusammen mit dem Befehl OPTIMIZE. 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.

Warum verwenden einige Azure Databricks-Features Partitionen, wenn diese so schlecht sind?

Partitionen können insbesondere für sehr große Tabellen von Vorteil sein. Viele Leistungsverbesserungen rund um die Partitionierung konzentrieren sich auf sehr große Tabellen (Hunderte von Terabyte oder mehr).

Viele Kunden migrieren von Parquet-basierten Data Lakes zu Delta Lake. Mit der CONVERT TO DELTA-Anweisung können Sie eine vorhandene Parquet-basierte Tabelle in eine Delta-Tabelle konvertieren, ohne vorhandene Daten neu zu schreiben. Somit verfügen viele Kunden über große Tabellen, die frühere Partitionierungsstrategien erben. Einige von Databricks entwickelte Optimierungen versuchen, diese Partitionen nach Möglichkeit zu nutzen, um einige potenzielle Nachteile für Partitionierungsstrategien zu minimieren, die nicht für Delta Lake optimiert sind.

Delta Lake und Apache Spark sind Open-Source-Technologien. Während Databricks weiterhin Features einführt, die die Abhängigkeit von Partitionierung verringern, wird die Open-Source-Community möglicherweise weiterhin neue Features erstellen, die die Komplexität erhöhen.

Ist es möglich, die integrierten Azure Databricks-Optimierungen mit benutzerdefinierter Partitionierung zu übertreffen?

Einige erfahrene Benutzer von Apache Spark und Delta Lake sind möglicherweise in der Lage, ein Muster zu entwerfen und zu implementieren, das eine bessere Leistung als die Gruppierung nach Erfassungszeit bietet. Die Implementierung einer fehlerhaften Partitionierungsstrategie kann sehr negative Auswirkungen auf die Downstreamleistung haben und möglicherweise ein vollständiges Neuschreiben der Daten erfordern, um dies zu beheben. Databricks empfiehlt, dass die meisten Benutzer Standardeinstellungen verwenden, um keine kostspieligen Ineffizienzen einzuführen.