Freigeben über

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 arbeitet, indem spezielle Sortierung, Zeilengruppenverteilung, Wörterbuchcodierung und Komprimierung auf Parquet-Dateien angewendet werden, wodurch weniger Netzwerk-, Festplatten- und CPU-Ressourcen in Compute-Engines zum Lesen 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 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:

Konfiguration Standardwert Beschreibung
spark.sql.parquet.vorder.default false Steuert das Schreiben der V-Order auf Sitzungsebene. Standardmäßig auf false in neuen Fabric-Arbeitsbereichen festgelegt.
TBLPROPERTIES("delta.parquet.vorder.default") false Steuert das Standardverhalten der V-Reihenfolge auf Tabellenebene.
DataFrame Writer-Option: parquet.vorder.default Nicht festgelegt Wird zum Steuern der V-Reihenfolge auf Schreibvorgangsebene verwendet.

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

⚠– Wichtig:
V-Order ist standardmäßig deaktiviert in neuen Fabric-Arbeitsbereichenspark.sql.parquet.vorder.default=false, um die Leistung für Datenaufnahme- und Transformationspipelines zu verbessern.

Wenn Ihre Workload leselastig ist – z. B. interaktive Abfragen oder Dashboard-Visualisierungen – können Sie die V-Order aktivieren, indem Sie:

  • Festlegen der Spark-Eigenschaft spark.sql.parquet.vorder.default=true
  • Beim Wechsel zu den Ressourcenprofilen readHeavyforSpark oder ReadHeavy wird V-Order automatisch aktiviert, um eine bessere Leseleistung zu erzielen.

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

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

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

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

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

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.default-Tabelleneigenschaft auf true oder false festgelegt ist.

%%sql 
SET 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.default" = "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.default" = "true");

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

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

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 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")

Wichtig

Die V-Reihenfolge gilt nur für Dateien, die durch das Prädikat bestimmt werden.

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.default ","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.default","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.

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ü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 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.

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.

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 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