Teilen über


Best Practices: Delta Lake

In diesem Artikel werden best Practices für die Verwendung von Delta Lake beschrieben.

Übersicht über bewährte Methoden

Im Folgenden finden Sie allgemeine Empfehlungen, die für die meisten Delta Lake-Workloads gelten:

Legacy-Delta-Konfigurationen entfernen

Databricks empfiehlt, beim Upgrade auf eine neue Databricks-Runtime-Version die meisten expliziten Delta-Konfigurationen aus Spark-Konfigurationen und Tabelleneigenschaften zu entfernen. Legacykonfigurationen können verhindern, dass neue Optimierungen und Standardwerte von Databricks auf migrierte Workloads angewendet werden.

Komprimieren von Dateien

Die Predictive Optimization führt automatisch OPTIMIZE- und VACUUM-Befehle in verwalteten Tabellen im Unity-Katalog aus. Siehe Prädiktive Optimierung für verwaltete Unity Catalog-Tabellen.

Databricks empfiehlt, den Befehl OPTIMIZE häufig auszuführen, um kleine Dateien zu komprimieren.

Hinweis

Dieser Vorgang entfernt nicht die alten Dateien. Um sie zu entfernen, führen Sie den Befehl VACUUM aus.

Verwenden Sie keine Spark-Zwischenspeicherung mit Delta Lake

Databricks empfiehlt die Verwendung von Spark-Zwischenspeicherung aus folgenden Gründen nicht:

  • Sie verlieren alle Daten, die von zusätzlichen Filtern, die zusätzlich zu den zwischengespeicherten DataFrame hinzugefügt werden, übersprungen werden können.
  • Die Daten, die zwischengespeichert werden, werden möglicherweise nicht aktualisiert, wenn auf die Tabelle mit einem anderen Bezeichner zugegriffen wird.

Unterschiede zwischen Delta Lake und Parquet auf Apache Spark

Delta Lake verarbeitet die folgenden Vorgänge automatisch. Sie sollten diese Vorgänge niemals manuell ausführen:

  • REFRESH TABLE: Delta-Tabellen geben immer die neuesten Informationen zurück. Ein manueller Aufruf von REFRESH TABLE nach einer Änderung ist daher nicht erforderlich.
  • Hinzufügen und Entfernen von Partitionen: Delta Lake verfolgt die in einer Tabelle vorhandenen Partitionen automatisch und aktualisiert die Liste, sobald Daten hinzugefügt oder entfernt werden. Daher ist die Ausführung von ALTER TABLE [ADD|DROP] PARTITION oder MSCK nicht erforderlich.
  • Laden einer einzelnen Partition: Das direkte Lesen von Partitionen ist nicht erforderlich. Sie müssen z. B. nicht ausführen spark.read.format("parquet").load("/data/date=2017-01-01"). Verwenden Sie stattdessen eine WHERE-Klausel zum Überspringen von Daten, etwa spark.read.table("<table-name>").where("date = '2017-01-01'").
  • Ändern Sie keine Datendateien manuell: Delta Lake verwendet das Transaktionsprotokoll, um Änderungen an der Tabelle atomar zu übernehmen. Ändern Sie in einer Delta-Tabelle keine Parquet-Datendateien direkt, fügen Sie diese nicht direkt zu dieser Tabelle hinzu oder entfernen Sie sie aus dieser Tabelle, da dies zu Datenverlusten oder einer Beschädigung der Tabelle führen kann.

Verbessern der Leistung für Delta Lake-Zusammenführungen

Sie können die Zeit für die Zusammenführung mit den folgenden Ansätzen reduzieren:

  • Reduzieren des Suchbereichs für Übereinstimmungen: Standardmäßig durchsucht der merge-Vorgang die gesamte Delta-Tabelle nach Übereinstimmungen in der Quelltabelle. Eine Möglichkeit zur Beschleunigung von merge besteht darin, den Suchbereich zu reduzieren, indem bekannte Einschränkungen in der Übereinstimmungsbedingung hinzugefügt werden. Angenommen, Sie haben eine Tabelle, die nach country und date partitioniert ist, und Sie möchten mithilfe von merge Informationen für den letzten Tag und ein bestimmtes Land aktualisieren. Durch Hinzufügen der folgenden Bedingung wird die Abfrage beschleunigt, da sie nur in den relevanten Partitionen nach Übereinstimmungen sucht:

    events.date = current_date() AND events.country = 'USA'
    

    Darüber hinaus verringert diese Abfrage auch die Wahrscheinlichkeit von Konflikten mit anderen gleichzeitigen Vorgängen. Weitere Informationen finden Sie unter Isolationsstufen und Schreibkonflikte in Azure Databricks.

  • Komprimieren von Dateien: Wenn die Daten in vielen kleinen Dateien gespeichert sind, kann das Lesen der Daten für die Suche nach Übereinstimmungen langsam werden. Sie können kleine Dateien in größere Dateien komprimieren, um den Lesedurchsatz zu verbessern. Details finden Sie unter Optimieren des Datendateilayouts.

  • Steuern der Shufflepartitionen für Schreibvorgänge: Der merge-Vorgang mischt Daten mehrmals, um die aktualisierten Daten zu berechnen und zu schreiben. Die Anzahl der für Shuffle verwendeten Aufgaben wird durch die Spark-Sitzungskonfiguration spark.sql.shuffle.partitions gesteuert. Durch das Festlegen dieses Parameters wird nicht nur die Parallelität gesteuert, sondern auch die Anzahl der Ausgabedateien bestimmt. Durch das Erhöhen des Werts wird die Parallelität erhöht, aber auch eine größere Anzahl kleinerer Datendateien generiert.

  • Aktivieren von optimierten Schreibvorgängen: Bei partitionierten Tabellen kann merge eine viel größere Anzahl von kleinen Dateien erzeugen als die Anzahl von Shufflepartitionen. Dies liegt daran, dass jede Shuffle-Aufgabe mehrere Dateien in mehreren Partitionen schreiben kann und so zu einem Leistungsengpass führen kann. Sie können die Anzahl der Dateien verringern, indem Sie „Optimized Write“ (Optimierter Schreibvorgang) aktivieren. Weitere Informationen finden Sie unter Optimierte Schreibvorgänge für Delta Lake in Azure Databricks.

  • Optimieren der Dateigröße in Tabellen: Azure Databricks kann automatisch erkennen, ob eine Delta-Tabelle häufige merge-Vorgänge zum erneuten Schreiben von Dateien enthält. Möglicherweise reduziert Databricks die Größe neu geschriebener Dateien in Erwartung weiterer Dateischreibvorgänge in der Zukunft. Details finden Sie im Abschnitt zum Optimieren von Dateigrößen.

  • Low Shuffle Merge: Low Shuffle Merge bietet eine optimierte Implementierung von MERGE für eine bessere Leistung bei den meisten gängigen Workloads. Darüber hinaus behält es vorhandene Optimierungen des Datenlayouts wie z. B. Z-Sortierung für unveränderte Daten bei.