Delta Lake-Tabellenoptimierung und V-Reihenfolge
Das Tabellenformat "Lakehouse " und " Delta Lake " sind für Microsoft Fabric von zentraler Bedeutung, da sichergestellt ist, dass Tabellen für Analysen optimiert sind. In diesem Leitfaden werden Konzepte, Konfigurationen und deren Anwendung auf die häufigsten Big Data-Nutzungsmuster von Delta Lake-Tabellen beschrieben.
Wichtig
Microsoft Fabric befindet sich derzeit in der VORSCHAU. Diese Informationen beziehen sich auf eine Vorabversion des Produkts, an der vor der Veröffentlichung noch wesentliche Änderungen vorgenommen werden können. Microsoft übernimmt keine Garantie, weder ausdrücklich noch stillschweigend, für die hier bereitgestellten Informationen.
Was ist V-Order?
V-Order ist eine Optimierung der Schreibzeit für das Parquet-Dateiformat , die blitzschnelle Lesevorgänge unter den Microsoft Fabric-Compute-Engines wie Power BI, SQL, Spark und anderen ermöglicht.
Power BI- und SQL-Engines verwenden microsoft Verti-Scan-Technologie und V-geordnete Parquet-Dateien, um In-Memory-Zeiten wie Datenzugriffszeiten zu erreichen. Spark und andere Nicht-Verti-Scan-Compute-Engines profitieren ebenfalls von den V-geordneten Dateien mit durchschnittlich 10 % schnelleren Lesezeiten, bei einigen Szenarien bis zu 50 %.
V-Order wendet spezielle Sortierung, Zeilengruppenverteilung, Wörterbuchcodierung und Komprimierung auf Parquet-Dateien an, wodurch weniger Netzwerk-, Datenträger- und CPU-Ressourcen in Compute-Engines benötigt werden, um sie zu lesen, was Kosteneffizienz und Leistung bietet. Die Sortierung von V-Reihenfolge hat einen Einfluss von 15 % auf die durchschnittlichen Schreibzeiten, bietet aber bis zu 50 % mehr Komprimierung.
Das 100 %-Open-Source-Parquet-Format ist kompatibel; alle Parquet-Engines können sie als reguläre Parquet-Dateien lesen. Delta-Tabellen sind effizienter als je zuvor; Features wie Z-Order sind mit V-Order kompatibel. Tabelleneigenschaften und Optimierungsbefehle können für die Steuerung der V-Reihenfolge für die zugehörigen Partitionen verwendet werden.
Die V-Reihenfolge wird auf parquet-Dateiebene angewendet. Delta-Tabellen und seine Funktionen, wie Z-Order, Komprimierung, Vakuum, Zeitreise usw. sind orthogonal zu V-Order als solche kompatibel und können zusammen für zusätzliche Vorteile verwendet werden.
Steuern von V-Order-Schreibvorgängen
V-Order 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 das Schreiben auf Sitzungsebene in V-Reihenfolge. |
TBLPROPERTIES("delta.parquet.vorder.enabled") | false | Standardmäßiger V-Reihenfolgenmodus für Tabellen |
Dataframe Writer-Option: parquet.vorder.enabled | Unset | Steuern von V-Order-Schreibvorgängen mit dataframe writer |
Verwenden Sie die folgenden Befehle, um die Verwendung von V-Order-Schreibvorgängen zu steuern.
Überprüfen der V-Order-Konfiguration in einer Apache Spark-Sitzung
%%sql
GET spark.sql.parquet.vorder.enabled
Deaktivieren von V-Order-Schreibvorgängen in Apache Spark-Sitzungen
%%sql
SET spark.sql.parquet.vorder.enabled=FALSE
Aktivieren des Schreibens von V-Order in einer Apache Spark-Sitzung
Wichtig
Wenn dies auf Sitzungsebene aktiviert ist. Alle Parquet-Schreibvorgänge werden mit aktivierter V-Reihenfolge durchgeführt. Dies umfasst Nicht-Delta-Parquet-Tabellen und Delta-Tabellen, deren parquet.vorder.enabled
Table-Eigenschaft auf true
oder false
festgelegt ist.
%%sql
SET spark.sql.parquet.vorder.enabled=TRUE
Steuern der V-Reihenfolge mithilfe von 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");
Wichtig
Wenn die Table-Eigenschaft auf TRUE festgelegt ist; Die Befehle INSERT, UPDATE und MERGE verhalten sich wie erwartet und funktionieren. Wenn die V-Order-Sitzungskonfiguration auf true festgelegt ist oder spark.write sie aktiviert, werden die Schreibvorgänge auch dann V-Order 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");
Nachdem Sie V-Order mithilfe von Tabelleneigenschaften aktiviert oder deaktiviert haben, sind nur zukünftige Schreibvorgänge in die Tabelle betroffen. Parquet-Dateien behalten die Reihenfolge bei, die beim Erstellen verwendet wurde. Um die aktuelle physische Struktur so zu ändern, dass V-Reihenfolge angewendet oder entfernt wird, lesen Sie den Abschnitt "Steuern der V-Reihenfolge bei der Optimierung einer Tabelle".
Direktes Steuern der V-Reihenfolge bei Schreibvorgängen
Alle Apache Spark-Schreibbefehle erben die Sitzungseinstellung, wenn sie nicht explizit sind. Alle folgenden Befehle schreiben mithilfe von V-Order, indem 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
V-Order wendet nur Dateien an, 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 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 optimierter Schreibvorgang?
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. Aufnahme-Workloads in Data-Lake-Tabellen können die vererbte Eigenschaft haben, ständig viele kleine Dateien zu schreiben; Dieses Szenario ist allgemein als „kleines Dateiproblem“ bekannt.
Optimize Write ist ein Delta Lake-Feature in Microsoft Fabric und Azure Synapse Analytics in der Apache Spark-Engine, das die Anzahl der geschriebenen Dateien reduziert und die individuelle Dateigröße der geschriebenen Daten erhöhen soll. Die Größe der Zieldatei kann je nach Workloadanforderungen mithilfe von Konfigurationen geändert werden.
Das Feature ist in Microsoft Fabric Runtime für Apache Spark standardmäßig aktiviert . Weitere Informationen zu Verwendungsszenarien zum Optimieren von Schreibvorgängen finden Sie im Artikel Die Notwendigkeit der Optimierung von Schreibvorgängen in Apache Spark.
Mergeoptimierung
Ü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 Verteilung von Delta Lake ist jedoch nicht vollständig für die Verarbeitung unveränderter Zeilen optimiert. Das Microsoft Spark Delta-Team hat eine benutzerdefinierte Low Shuffle Merge-Optimierung implementiert. Unveränderte Zeilen werden von einem teuren Shufflingvorgang ausgeschlossen, der zum Aktualisieren übereinstimmener Zeilen erforderlich ist.
Die Implementierung wird durch die spark.microsoft.delta.merge.lowShuffle.enabled
Konfiguration gesteuert, die standardmäßig in der Runtime aktiviert ist. Es erfordert keine Codeänderungen und ist vollständig mit der Open-Source-Distribution von Delta Lake kompatibel. Weitere Informationen zu Verwendungsszenarien für Zusammenführungen mit geringem Shuffle finden Sie im Artikel Optimierung der Zusammenführung mit geringem Shuffle für Delta-Tabellen.
Wartung von Deltatabellen
Wenn sich Delta-Tabellen ändern, verschlechtert sich die Leistung und die Speicherkosteneffizienz aus den folgenden Gründen tendenziell:
- Neue Daten, die der Tabelle hinzugefügt wurden, 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 Leseaufwand. Parquet-Dateien sind entwurfsbedingt unveränderlich, sodass Delta-Tabellen neue Parquet-Dateien hinzufügen, die das Changeset enthält, wodurch die Probleme, die durch die ersten beiden Elemente verursacht werden, noch verstärkt werden.
- Im Speicher verfügbare Datendateien und Protokolldateien sind nicht mehr erforderlich.
Um die Tabellen im besten Zustand für die beste Leistung zu halten, führen Sie Bin-Komprimierungs- und Vakuumvorgänge in den Delta-Tabellen aus. Die Bin-Komprimierung wird durch den Befehl OPTIMIZE erreicht; Alle Änderungen werden in größeren, konsolidierten Parquet-Dateien zusammengeführt. Dereferenzierter Speicher sauber wird durch den VACUUM-Befehl erreicht.
Wichtig
Das ordnungsgemäße Entwerfen 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 sind bin-compact und schreiben alle betroffenen Dateien mithilfe von V-Order 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-Komprimierung, ZORDER und VORDER sequenziell aus.
Die folgenden Befehle sind bin-compact und schreiben alle betroffenen Dateien mit der Einstellung TBLPROPERTIES neu. Wenn TBLPROPERTIES auf V-Order festgelegt ist, werden alle betroffenen Dateien als V-Order geschrieben. Wenn TBLPROPERTIES nicht festgelegt oder auf false auf V-Order festgelegt ist, erbt es die Sitzungseinstellung. Legen Sie daher die Sitzungskonfiguration auf false fest, um V-Order aus der Tabelle zu entfernen.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];