Share via

Delta Lake-Tabellenoptimierung und V-Reihenfolge

  • Artikel

Die Tabellenformate Lakehouse und Delta Lake sind für Microsoft Fabric von zentraler Bedeutung. Eine wichtige Anforderung besteht darin, die Optimierung der Tabellen für Analysen sicherzustellen. In diesem Leitfaden werden von Delta Lake-Tabellenoptimierungskonzepte, Konfigurationen und deren Anwendung auf die häufigsten Big Data-Nutzungsmuster beschrieben.

Was ist mit V-Reihenfolge gemeint?

Die V-Reihenfolge ist eine Schreibzeitoptimierung für das Parquet-Dateiformat, die blitzschnelle Lesevorgänge unter Microsoft Fabric-Computemodulen wie Power BI, SQL, Spark und anderen ermöglicht.

Power BI- und SQL-Engines verwenden Microsoft Verti-Scan-Technologie und in V-Reihenfolge angeordnete Parquet-Dateien, um nahezu In-Memory-Datenzugriffszeiten zu erreichen. Spark und andere Computemodule, die nicht von Verti-Scan stammen, profitieren mit durchschnittlich um 10 % schnelleren Lesevorgängen ebenfalls von den in V-Reihenfolge angeordneten Dateien, wobei in einigen Szenarien Lesevorgänge bis zu 50 % schneller sind.

Für die V-Reihenfolge werden eine spezielle Sortierung, Zeilengruppenverteilung, Wörterbuchcodierung und Komprimierung auf Parkettdateien angewendet, sodass weniger Netzwerk-, Festplatten- und CPU-Ressourcen zum Lesen der Dateien benötigt werden. Dadurch werden Kosteneffizienz und Leistung gesteigert. Die Sortierung in V-Reihenfolge verändert die durchschnittlichen Schreibzeiten um 15 %, bietet aber eine um bis zu 50 % höhere Komprimierung.

Das Format ist zu 100 % mit dem Open-Source-Parquet-Format kompatibel. Alle Parquet-Engines können es als reguläre Parquet-Dateien lesen. Delta-Tabellen sind effizienter denn je. Features wie die Z-Reihenfolge sind mit der V-Reihenfolge kompatibel. Tabelleneigenschaften und Optimierungsbefehle können für die Steuerung der V-Reihenfolge in den zugehörigen Partitionen verwendet werden.

Die V-Reihenfolge wird auf Parquet-Dateiebene angewendet. Delta-Tabellen und deren Funktionen, wie Z-Reihenfolge, Komprimierung, Vakuum, Zeitreise usw. sind orthogonal zur V-Reihenfolge. Daher sind sie kompatibel und können zusammen verwendet werden, um zusätzliche Vorteile zu erzielen.

Steuern von Schreibvorgängen in V-Reihenfolge

Die V-Reihenfolge ist in Microsoft Fabric standardmäßig aktiviert, und in Apache Spark wird sie durch die folgenden Konfigurationen gesteuert.

Konfiguration Standardwert Beschreibung
spark.sql.parquet.vorder.enabled true Steuert auf Sitzungsebene das Schreiben in V-Reihenfolge.
TBLPROPERTIES(“delta.parquet.vorder.enabled”) false Standardmäßiger V-Reihenfolgenmodus für Tabellen
Dataframe Writer-Option: parquet.vorder.enabled Nicht festgelegt Steuern von Schreibvorgängen in V-Reihenfolge mit Dataframe Writer

Verwenden Sie die folgenden Befehle, um die Verwendung von Schreibvorgängen in V-Reihenfolge zu steuern.

Überprüfen der Konfiguration der V-Reihenfolge in einer Apache Spark-Sitzung

%%sql 
SET spark.sql.parquet.vorder.enabled

Deaktivieren von Schreibvorgängen in V-Reihenfolge in Apache Spark-Sitzungen

%%sql 
SET spark.sql.parquet.vorder.enabled=FALSE

Aktivieren von Schreibvorgängen in V-Reihenfolge in Apache Spark-Sitzungen

Wichtig

Bei Aktivierung auf Sitzungsebene Alle Parquet-Schreibvorgänge werden mit aktivierter V-Reihenfolge durchgeführt. Dies umfasst Nicht-Delta-Parquet-Tabellen und Delta-Tabellen, deren parquet.vorder.enabled-Tabelleneigenschaft auf true oder falsefestgelegt ist.

%%sql 
SET spark.sql.parquet.vorder.enabled=TRUE

Steuern der V-Reihenfolge mit Delta-Tabelleneigenschaften

Aktivieren Sie die Tabelleneigenschaft für die V-Reihenfolge während der Tabellenerstellung:

%%sql 
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

Wichtig

Wenn die Tabelleneigenschaft auf „true“ festgelegt ist, verhalten sich die Befehle INSERT, UPDATE und MERGE wie erwartet und führen die Schreibzeitoptimierung durch. Wenn die Sitzungskonfiguration für die V-Reihenfolge auf „true“ festgelegt ist oder „spark.write“ sie aktiviert, werden die Schreibvorgänge auch dann in V-Reihenfolge ausgeführt, wenn TBLPROPERTIES auf „false“ festgelegt ist.

Aktivieren oder deaktivieren Sie die V-Reihenfolge, indem Sie die Tabelleneigenschaft ändern:

%%sql 
ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "true");

ALTER TABLE person SET TBLPROPERTIES("delta.parquet.vorder.enabled" = "false");

ALTER TABLE person UNSET TBLPROPERTIES("delta.parquet.vorder.enabled");

Wenn Sie V-Reihenfolge mithilfe von Tabelleneigenschaften aktivieren oder deaktivieren, sind nur zukünftige Schreibvorgänge in die Tabelle von der Änderung betroffen. Parquet-Dateien behalten die Reihenfolge bei, die bei ihrer Erstellung verwendet wurde. Um die aktuelle physische Struktur so zu ändern, dass die V-Reihenfolge angewendet oder entfernt wird, lesen Sie den Abschnitt „Steuern der V-Reihenfolge beim Optimieren einer Tabelle“.

Direktes Steuern der V-Reihenfolge bei Schreibvorgängen

Alle Apache Spark-Schreibbefehle erben die Sitzungseinstellung, wenn nicht explizit etwas anderes angegeben wird. Alle folgenden Befehle schreiben unter Verwendung der V-Reihenfolge, da sie implizit die Sitzungskonfiguration erben.

df_source.write\
  .format("delta")\
  .mode("append")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .location("Files/people")\
  .execute()

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .saveAsTable("myschema.mytable")

Wichtig

Die V-Reihenfolge wird nur auf Dateien angewendet, die vom Prädikat betroffen sind.

In einer Sitzung, in der spark.sql.parquet.vorder.enabled nicht festgelegt oder auf „false“ festgelegt ist, würden die folgenden Befehle unter Verwendung der V-Reihenfolge schreiben:

df_source.write\
  .format("delta")\
  .mode("overwrite")\
  .option("replaceWhere","start_date >= '2017-01-01' AND end_date <= '2017-01-31'")\
  .option("parquet.vorder.enabled ","true")\
  .saveAsTable("myschema.mytable")

DeltaTable.createOrReplace(spark)\
  .addColumn("id","INT")\
  .addColumn("firstName","STRING")\
  .addColumn("middleName","STRING")\
  .addColumn("lastName","STRING",comment="surname")\
  .addColumn("birthDate","TIMESTAMP")\
  .option("parquet.vorder.enabled","true")\
  .location("Files/people")\
  .execute()

Was ist Optimize Write?

Analytische Workloads auf Big-Datenverarbeitungs-Engines wie Apache Spark werden am effizientesten ausgeführt, wenn standardisierte größere Dateigrößen verwendet werden. Das Verhältnis zwischen der Dateigröße, der Anzahl der Dateien, der Anzahl der Spark-Worker und ihrer Konfigurationen spielt eine entscheidende Rolle für die Leistung. Das Erfassen von Daten in Data Lake-Tabellen kann die vererbte Eigenschaft haben, ständig viele kleine Dateien zu schreiben. Dieses Szenario ist allgemein als „Kleine-Dateien-Problem“ bekannt.

„Optimize Write“ (Schreibvorgang optimieren) ist ein Feature von Delta Lake on Microsoft Fabric und Azure Synapse Analytics der Apache Spark-Engine, die die Anzahl der geschriebenen Dateien reduziert und darauf abzielt, die individuelle Dateigröße der geschriebenen Daten zu erhöhen. Die Zieldateigröße kann je nach Workloadanforderungen mithilfe von Konfigurationen geändert werden.

Das Feature ist in Microsoft Fabric Runtime für Apache Sparkstandardmäßig aktiviert. Weitere Informationen zu Verwendungsszenarien für „Optimize Write“ finden Sie im Artikel Die Notwendigkeit der Optimierung von Schreibvorgängen in Apache Spark.

Merge-Optimierung

Über den Delta Lake-Befehl MERGE können Sie eine Delta-Tabelle mit erweiterten Bedingungen aktualisieren. Hierbei können Sie Daten aus einer Quelltabelle, einer Ansicht oder einem Datenframe mit einem MERGE-Befehl aktualisieren. Der aktuelle Algorithmus in der Open-Source-Distribution von Delta Lake ist jedoch nicht vollständig für die Verarbeitung unveränderter Zeilen optimiert. Das Microsoft Spark Delta Team implementierte eine Low Shuffle Merge-Optimierung, bei der unveränderte Zeilen von einem kostspieligen Shufflevorgang, der zum Aktualisieren übereinstimmender Zeilen erforderlich ist, ausgenommen werden.

Die Implementierung wird durch die spark.microsoft.delta.merge.lowShuffle.enabled-Konfiguration gesteuert, die in der Runtime standardmäßig aktiviert ist. Sie erfordert keine Codeänderungen und ist vollständig mit der Open-Source-Distribution von Delta Lake kompatibel. Weitere Informationen zu Verwendungsszenarien für Low Shuffle Merge finden Sie im Artikel Low Shuffle Merge-Optimierung für Delta-Tabellen.

Wartung von Delta-Tabellen

Wenn sich Delta-Tabellen ändern, verschlechtern sich Leistung und Speicherkosteneffizienz aus den folgenden Gründen:

  • Neu der Tabelle hinzugefügte Daten können Daten verzerren.
  • Batch- und Streamingdatenerfassungsraten können viele kleine Dateien mit sich bringen.
  • Aktualisierungs- und Löschvorgänge führen schließlich zu Lesemehraufwand. Parquet-Dateien sind von vornherein unveränderlich, sodass Delta-Tabellen neue Parquet-Dateien hinzufügen, die den Änderungssatz ergänzen. Dadurch werden die Probleme, die durch die ersten beiden Punkte verursacht werden, noch verstärkt.
  • Nicht mehr erforderliche Datendateien und Protokolldateien bleiben im Speicher verfügbar.

Um die Tabellen im besten Zustand für die beste Leistung zu halten, führen Sie in den Delta-Tabellen Bin-Verdichtungs- und Vakuumvorgänge aus. Die Bin-Verdichtung wird durch den Befehl OPTIMIZE erreicht, der alle Änderungen in größeren, konsolidierten Parquet-Dateien zusammengeführt. Zur Bereinigung von dereferenziertem Speicher wird der Befehl VACUUM verwendet.

Die Tabellenwartungsbefehle OPTIMIZE und VACUUM können in Notebooks und Spark-Auftragsdefinitionen verwendet und dann mithilfe von Plattformfunktionen koordiniert werden. Lakehouse in Fabric bietet eine Funktion für die Verwendung der Benutzeroberfläche zur Durchführung von Ad-hoc-Tabellenwartungen, wie im Artikel zur Delta Lake-Tabellenwartung erläutert.

Wichtig

Der richtige Entwurf der physischen Tabellenstruktur basierend auf der Erfassungshäufigkeit und den erwarteten Lesemustern ist wahrscheinlich wichtiger als die Ausführung der in diesem Abschnitt beschriebenen Optimierungsbefehle.

Steuern der V-Reihenfolge beim Optimieren einer Tabelle

Die folgenden Befehlsstrukturen verdichten und schreiben alle betroffenen Dateien unter Verwendung der V-Reihenfolge neu, unabhängig von der TBLPROPERTIES-Einstellung oder Sitzungskonfigurationseinstellung:

%%sql 
OPTIMIZE <table|fileOrFolderPath> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;

OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER  BY (col_name1, col_name2, ...)] VORDER;

Wenn ZORDER und VORDER zusammen verwendet werden, führt Apache Spark die Bin-Verdichtung, ZORDER und VORDER sequenziell aus.

Die folgenden Befehle sind verdichten und schreiben alle betroffenen Dateien mit der Einstellung TBLPROPERTIES neu. Wenn TBLPROPERTIES für die V-Reihenfolge auf „true“ festgelegt ist, werden alle betroffenen Dateien in V-Reihenfolge geschrieben. Wenn TBLPROPERTIES nicht festgelegt oder für die V-Reihenfolge auf „false“ festgelegt ist, wird die Sitzungseinstellung übernommen. Um die V-Reihenfolge aus der Tabelle zu entfernen, legen Sie daher die Sitzungskonfiguration auf „false“ fest.

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];

Zugehöriger Inhalt