Delta Lake-tabelloptimering och V-order
Tabellformatet Lakehouse och Delta Lake är centrala för Microsoft Fabric, och att se till att tabeller är optimerade för analys är ett viktigt krav. Den här guiden behandlar begrepp om Delta Lake-tabelloptimering, konfigurationer och hur du kan tillämpa det på de vanligaste användningsmönstren för stordata.
Vad är V-Order?
V-Order är en skrivtidsoptimering till parquet-filformatet som möjliggör blixtsnabba läsningar under Microsoft Fabric-beräkningsmotorerna, till exempel Power BI, SQL, Spark och andra.
Power BI- och SQL-motorer använder Microsoft Verti-Scan-teknik och V-Ordered parquet-filer för att uppnå minnesinterna dataåtkomsttider. Spark och andra beräkningsmotorer som inte är Verti-Scan drar också nytta av de V-sorterade filerna med i genomsnitt 10 % snabbare lästider, med vissa scenarier upp till 50 %.
V-Order fungerar genom att använda särskild sortering, radgruppsdistribution, ordlistekodning och komprimering på parquet-filer, vilket kräver mindre nätverks-, disk- och CPU-resurser i beräkningsmotorer för att läsa den, vilket ger kostnadseffektivitet och prestanda. V-ordersortering har 15 % inverkan på genomsnittliga skrivtider, men ger upp till 50 % mer komprimering.
Det är ett parquet-format som är 100% kompatibelt med öppen källkod; alla parquet-motorerna kan läsa det som vanliga parquet-filer. Deltatabeller är effektivare än någonsin. funktioner som Z-Order är kompatibla med V-Order. Tabellegenskaper och optimeringskommandon kan användas för att styra V-ordningen för dess partitioner.
V-Order tillämpas på filnivå för parquet. Delta-tabeller och dess funktioner, till exempel Z-Order, komprimering, vakuum, tidsresor osv. är ortoggonala till V-Order, som sådana, är kompatibla och kan användas tillsammans för extra fördelar.
Övervakning av V-order-skrivningar
V-Order är aktiverat som standard i Microsoft Fabric och i Apache Spark styrs det av följande konfigurationer.
| Konfiguration | Standardvärde | beskrivning |
|---|---|---|
| spark.sql.parquet.vorder.default | true | Kontrollerar skrivning av V-Order på sessionsnivå. |
| TBLPROPERTIES("delta.parquet.vorder.default") | falskt | Standardläge för V-order i tabeller |
| Dataframe-skrivaralternativ: parquet.vorder.default | Inaktivera | Kontrollera V-Order-skrivningar med dataramsskrivare |
Använd följande kommandon för att styra användningen av V-Order-skrivningar.
Kontrollera V-Order-konfigurationen i Apache Spark-sessionen
%%sql
SET spark.sql.parquet.vorder.default
Inaktivera V-Order-skrivning i Apache Spark-session
%%sql
SET spark.sql.parquet.vorder.default=FALSE
Aktivera V-Order-skrivning i Apache Spark-session
Viktigt!
När det är aktiverat på sessionsnivå. Alla parquet-skrivningar görs med V-Order aktiverat. Detta inkluderar icke-Delta-parquet-tabeller och Delta-tabeller med tabellegenskapen parquet.vorder.default inställd på antingen true eller false.
%%sql
SET spark.sql.parquet.vorder.default=TRUE
Kontrollera V-order med hjälp av deltatabellegenskaper
Aktivera tabellegenskapen V-Order när tabellen skapas:
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.default" = "true");
Viktigt!
När tabellegenskapen är inställd på true fungerar kommandona INSERT, UPDATE och MERGE som förväntat och utför skrivtidsoptimeringen. Om konfigurationen för V-Order-sessionen är inställd på true eller om spark.write aktiverar den, blir skrivningar V-Order även om TBLPROPERTIES är inställt på false.
Aktivera eller inaktivera V-order genom att ändra tabellegenskapen:
%%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");
När du har aktiverat eller inaktiverat V-Order med hjälp av tabellegenskaper påverkas endast framtida skrivningar till tabellen. Parquet-filer behåller den ordning som användes när de skapades. Om du vill ändra den aktuella fysiska strukturen för att tillämpa eller ta bort V-order läser du avsnittet "Kontrollera V-ordning när du optimerar en tabell" nedan.
Styra V-order direkt vid skrivåtgärder
Alla Apache Spark-skrivkommandon ärver sessionsinställningen om de inte är explicita. Alla följande kommandon skriver med hjälp av V-Order genom att implicit ärva sessionskonfigurationen.
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")
Viktigt!
V-Order gäller endast för filer som påverkas av predikatet.
I en session där spark.sql.parquet.vorder.default är oetat eller inställt på falskt skriver följande kommandon med V-Order:
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()
Vad är Optimize Write?
Analytiska arbetsbelastningar på stordatabearbetningsmotorer som Apache Spark fungerar mest effektivt när du använder standardiserade större filstorlekar. Relationen mellan filstorleken, antalet filer, antalet Spark-arbetare och dess konfigurationer spelar en viktig roll för prestanda. Att mata in data i datasjötabeller kan ha den ärvda egenskapen att ständigt skriva massor av små filer. Det här scenariot kallas ofta för "små filproblem".
Optimerad skrivprocess är en funktion i Delta Lake på Microsoft Fabric och Azure Synapse Analytics inom Apache Spark-motorn som minskar antalet filer som skrivs och syftar till att öka storleken på de enskilda filerna i de skrivna data. Målfilens storlek kan ändras enligt arbetsbelastningskraven med hjälp av konfigurationer.
Funktionen är aktiverad som standard i Microsoft Fabric Runtime för Apache Spark. Mer information om att optimera användningsscenarier för skrivning finns i artikeln Behovet av att optimera skrivning på Apache Spark.
Sammanslagningsoptimering
Med kommandot Delta Lake MERGE kan användare uppdatera en deltatabell med avancerade villkor. Den kan uppdatera data från en källtabell, vy eller DataFrame till en måltabell med hjälp av KOMMANDOT MERGE. Den aktuella algoritmen i den öppna källkodsversionen av Delta Lake är dock inte helt optimerad för hantering av de oförändrade raderna. Microsoft Spark Delta-teamet implementerade en anpassad "Low Shuffle Merge"-optimering, där oförändrade rader undantas från en dyr omfördelningsoperation som behövs för att uppdatera matchade rader.
Implementeringen styrs av konfigurationen spark.microsoft.delta.merge.lowShuffle.enabled , som är aktiverad som standard i körningen. Det kräver inga kodändringar och är helt kompatibelt med fördelningen med öppen källkod för Delta Lake. Mer information om användningsscenarier med låg blandningssammanslagning finns i artikeln Optimering av låg blandningssammanslagning i Delta-tabeller.
Underhåll av deltatabeller
När Delta-tabellerna ändras tenderar prestanda och lagringskostnadseffektivitet att försämras av följande skäl:
- Nya data som läggs till i tabellen kan förvränga data.
- Batch- och strömmande datainmatningshastigheter kan medföra många små filer.
- Uppdaterings- och borttagningsåtgärder skapar så småningom läsoveralast; parquet-filer är oföränderligt till sin utformning, så Delta-tabeller lägger till nya parquet-filer med ändringspaketet, vilket ytterligare förstärker de problem som de två första objekten medför.
- Datafiler och loggfiler som är tillgängliga i lagringen behövdes inte längre.
För att hålla tabellerna i bästa skick och prestanda utför du bin-komprimering och vakuumåtgärder i Delta-tabellerna. Bin-kompaktering uppnås med kommandot OPTIMIZE. Den sammanfogar alla ändringar till större, konsoliderade Parquet-filer. Rensning av oadresserat lagringsutrymme uppnås med kommandot VACUUM.
Tabellunderhållskommandona OPTIMIZE och VACUUM kan användas i notebook-filer och Spark-jobbdefinitioner och sedan orkestreras med hjälp av plattformsfunktioner. Lakehouse i Fabric erbjuder en funktionalitet för att utföra tillfälligt tabellunderhåll via användargränssnittet, enligt beskrivningen i artikeln om Delta Lake-tabellunderhåll.
Viktigt!
Korrekt utformning av tabellens fysiska struktur, baserat på inmatningsfrekvensen och förväntade läsmönster, är sannolikt viktigare än att köra optimeringskommandona som beskrivs i det här avsnittet.
Kontrollera V-order när du optimerar en tabell
Följande kommando strukturerar bin-compact och skriver om alla berörda filer med hjälp av V-Order, oberoende av inställningen TBLPROPERTIES eller sessionskonfigurationsinställningen:
%%sql
OPTIMIZE <table|fileOrFolderPath> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> VORDER;
OPTIMIZE <table|fileOrFolderPath> WHERE <predicate> [ZORDER BY (col_name1, col_name2, ...)] VORDER;
När ZORDER och VORDER används tillsammans utför Apache Spark bin-komprimering, ZORDER, VORDER sekventiellt.
Följande kommandon bin-komprimerar och skriver om alla berörda filer med hjälp av inställningen TBLPROPERTIES. Om TBLPROPERTIES är inställt på V-Order skrivs alla berörda filer som V-Order. Om TBLPROPERTIES inte är satt eller är inställt på false för V-Order, ärver den sessionsinställningen, så om du vill ta bort V-Order från tabellen, ställ in sessionskonfigurationen på false.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];