Delta Lake-tabelloptimering och V-order

  • Artikel

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 beskriver begrepp, konfigurationer och hur du tillämpar dem 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 100% parquet-format med öppen källkod; alla parquetmotorer kan läsa det som en vanlig 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-order på dess partitioner.

V-Order tillämpas på parquet-filnivån. 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.

Kontrollera V-orderskrivningar

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.enabled true Styr V-orderskrivning på sessionsnivå.
TBLPROPERTIES("delta.parquet.vorder.enabled") falskt Standardläge för V-order i tabeller
Dataframe-skrivaralternativ: parquet.vorder.enabled 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.enabled

Inaktivera V-Order-skrivning i Apache Spark-session

%%sql 
SET spark.sql.parquet.vorder.enabled=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.enabled inställd på antingen true eller false.

%%sql 
SET spark.sql.parquet.vorder.enabled=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.enabled" = "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.enabled" = "true");

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

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

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 den 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.enabled är oetat eller inställt på false skulle följande kommandon skriva med hjälp av 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.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()

Vad är Optimera skrivning?

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

Optimera skrivning är en Delta Lake på Microsoft Fabric och Azure Synapse Analytics-funktionen i Apache Spark-motorn som minskar antalet filer som skrivs och syftar till att öka den enskilda filstorleken för 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 öppen källkod fördelningen av Delta Lake är dock inte helt optimerad för hantering av oförändrade rader. Microsoft Spark Delta-teamet implementerade en anpassad optimering av låg blandningssammanslagning, oförändrade rader undantas från en dyr blandningsåtgärd 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äskostnader. parquet-filer är oföränderliga avsiktligt, så Delta-tabeller lägger till nya parquet-filer med ändringsuppsättningen, 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 det bästa tillståndet för bästa prestanda utför du bin-compaction och dammsugningsåtgärder i Delta-tabellerna. Bin-compaction uppnås med kommandot OPTIMIZE . Den sammanfogar alla ändringar till större, konsoliderade parquet-filer. Dereferenced storage clean-up 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 funktion för att använda användargränssnittet för att utföra ad hoc-tabellunderhåll enligt beskrivningen i delta laketabellunderhållsartikeln.

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-compaction, ZORDER, VORDER sekventiellt.

Följande kommandon bin-compact och skriva 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 är oetat eller inställt på false till V-Order ärver den sessionsinställningen. så om du vill ta bort V-Order från tabellen anger du sessionskonfigurationen till false.

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

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

Relaterat innehåll