Delta Lake-Tabellenoptimierung und V-Reihenfolge

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 Nicht-Verti-Scan-Rechen-Engines profitieren ebenfalls von den V-geordneten Dateien mit durchschnittlich um 10 % schnelleren Lesegeschwindigkeiten, während sie in manchen Szenarien sogar um bis zu 50 % schneller sind.

V-Order optimiert Parquet-Dateien durch Sortierung, Zeilengruppenverteilung, Codierung und Komprimierung und damit die Reduzierung der Ressourcennutzung sowie die Verbesserung der Leistung und Kosteneffizienz. Während es ca. 15% zu Schreibzeiten hinzufügt, kann es die Komprimierung um bis zu 50%erhöhen. 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 verwendet werden, um die V-Reihenfolge ihrer Partitionen zu steuern.

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

V-Order wird verwendet, um das Layout von Parquet-Dateien für eine schnellere Abfrageleistung zu optimieren, insbesondere in leseintensiven Szenarien. In Microsoft Fabric ist V-Order standardmäßig für alle neu erstellten Arbeitsbereiche deaktiviert , um die Leistung für schreibintensive Datenverarbeitungsworkloads zu optimieren.

Das V-Order-Verhalten in Apache Spark wird über die folgenden Konfigurationen gesteuert:

Verwenden Sie die folgenden Befehle, um V-Order-Schreibvorgänge nach Bedarf für Ihr Szenario zu aktivieren oder außer Kraft zu setzen.

In Fabric Runtime 1.3 und höheren Versionen wird die spark.sql.parquet.vorder.enable Einstellung entfernt. Da V-Order während der Delta-Optimierung mithilfe von OPTIMIZE-Anweisungen automatisch angewendet wird, muss diese Einstellung in neueren Laufzeitversionen nicht manuell aktiviert werden. Wenn Sie Code aus einer früheren Laufzeitversion migrieren, können Sie diese Einstellung entfernen, da das Modul sie jetzt automatisch behandelt.

• Weitere Informationen zu Ressourcenprofilen

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

%%sql 
SET spark.sql.parquet.vorder.default 

%%pyspark
spark.conf.get('spark.sql.parquet.vorder.default')

%%spark  
spark.conf.get('spark.sql.parquet.vorder.default')

%%sparkr
library(SparkR)
sparkR.conf("spark.sql.parquet.vorder.default")

Deaktivierung des V-Order-Schreibvorgangs in einer Apache Spark-Sitzung

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

%%pyspark
spark.conf.set('spark.sql.parquet.vorder.default', 'false')   

%%spark  
spark.conf.set("spark.sql.parquet.vorder.default", "false") 

%%sparkr
library(SparkR)
sparkR.conf("spark.sql.parquet.vorder.default", "false")

Aktivieren Sie das Schreiben in V-Reihenfolge in der Apache Spark-Sitzung

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

%%pyspark
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

%%spark  
spark.conf.set("spark.sql.parquet.vorder.default", "true")

%%sparkr
library(SparkR)
sparkR.conf("spark.sql.parquet.vorder.default", "true")

Steuern der V-Reihenfolge mit Delta-Tabelleneigenschaften

Aktivieren Sie die V-Order-Tabelleneigenschaft während der Tabellenerstellung.

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

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. Informationen zum Ändern der aktuellen physischen Struktur zum Anwenden oder Entfernen der V-Reihenfolge finden Sie unter 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 in V-Reihenfolge, indem sie die Sitzungskonfiguration implizit 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") 

In einer Sitzung, in der spark.sql.parquet.vorder.default nicht festgelegt oder auf „false“ gesetzt ist, würden die folgenden Befehle mit V-Order 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 ist ein Delta Lake-Feature in Fabric und Synapse, das die Anzahl der Dateien reduziert und die einzelne Dateigröße bei Schreibvorgängen in Apache Spark erhöht. 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.

Zusammenführungsoptimierung

Über den Delta Lake-Befehl MERGE können Sie eine Delta-Tabelle mit erweiterten Bedingungen aktualisieren. Man kann Daten aus einer Quelltabelle, einer Ansicht oder einem DataFrame mithilfe des MERGE-Befehls in einer Zieltabelle 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ügen Leseaufwand hinzu. Parquet-Dateien sind ihrer Natur nach unveränderlich. Da Delta-Tabellen neue Parquet-Dateien mit den Änderungen hinzufügen, werden die durch die ersten beiden Punkte auferlegten Probleme weiter verstärkt.
• Nicht mehr erforderliche Datendateien und Protokolldateien sind 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-Komprimierungs- und Vakuumiervorgänge aus. Die Bin-Komprimierung wird durch den Befehl OPTIMIZE erreicht, der alle Änderungen in größeren, konsolidierten Parquet-Dateien zusammenfü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.

Steuerung der V-Reihenfolge beim Optimieren einer Tabelle

Mit den folgenden Befehlsstrukturen wird eine Bin-Komprimierung aller betroffenen Dateien durchgeführt und die Dateien werden unter Verwendung der V-Reihenfolge erneut generiert, 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 Prozesse Bin-Verdichtung, ZORDER und VORDER nacheinander aus.

Mit den folgenden Befehlen wird die Bin-Komprimierung und erneute Generierung aller betroffenen Dateien mit der TBLPROPERTIES-Einstellung durchgeführt. Wenn TBLPROPERTIES auf „true“ für V-Order festgelegt ist, werden alle betroffenen Dateien als V-Order geschrieben. Wenn TBLPROPERTIES nicht festgelegt oder auf "false" festgelegt ist, erbt sie die Sitzungseinstellung. Um die V-Reihenfolge aus der Tabelle zu entfernen, legen Sie die Sitzungskonfiguration auf "false" fest.

%%sql 
OPTIMIZE table_name;

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

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

Zugehöriger Inhalt

• Was ist Delta Lake?
• Lakehouse und Delta Lake
• Die Notwendigkeit, das Schreiben auf Apache Spark zu optimieren
• Low Shuffle Merge-Optimierung für Delta-Tabellen