Tabeloptimering af Delta Lake og V-Order
Tabelformatet Lakehouse og Delta Lake er centrale for Microsoft Fabric, og det er et vigtigt krav at sikre, at tabeller er optimeret til analyse. Denne vejledning dækker Delta Lake-tabeloptimeringsbegreber, konfigurationer, og hvordan du anvender den på de mest almindelige big data-forbrugsmønstre.
Vigtigt
Microsoft Fabric fås som prøveversion.
Hvad er V-Order?
V-Order er en optimering af skrivetid til parquetfilformatet , der muliggør lynhurtige læsninger under Microsoft Fabric-beregningsprogrammer, f.eks. Power BI, SQL, Spark og andre.
Power BI- og SQL-programmer bruger Microsoft Verti-Scan-teknologi og V-ordnede parquetfiler for at opnå hukommelse som f.eks. dataadgangstider. Spark og andre beregningsprogrammer, der ikke er Verti-Scan, drager også fordel af V-Ordnede filer med gennemsnitligt 10 % hurtigere læsningstider med nogle scenarier op til 50 %.
V-Order fungerer ved at anvende særlig sortering, distribution af rækkegrupper, kodning og komprimering af ordbog på parquetfiler, hvilket kræver færre netværks-, disk- og CPU-ressourcer i beregningsprogrammer for at læse den, hvilket giver omkostningseffektivitet og ydeevne. V-sortering har en 15 % indvirkning på den gennemsnitlige skrivetid, men giver op til 50 % mere komprimering.
Dens 100 % open source-parquet-format er kompatibelt. alle parketmotorer kan læse den som en almindelig parket filer. Deltatabeller er mere effektive end nogensinde før. funktioner som Z-Order er kompatible med V-Order. Tabelegenskaber og optimeringskommandoer kan bruges i kontrolelementet V-Order på partitionerne.
V-Order anvendes på parquetfilniveau. Deltatabeller og dens funktioner, såsom Z-Order, komprimering, vakuum, tidsrejser osv. er ortogonale til V-Order, som sådan, er kompatible og kan bruges sammen til ekstra ydelser.
Styring af V-ordreskrivninger
V-Order er som standard aktiveret i Microsoft Fabric og i Apache Spark styres den af følgende konfigurationer
| Konfiguration | Standardværdi | Beskrivelse |
|---|---|---|
| spark.sql.parquet.vorder.enabled | sand | Styrer skrivning af V-ordre på sessionsniveau. |
| TBLPROPERTIES("delta.parquet.vorder.enabled") | falsk | V-order-standardtilstand for tabeller |
| Indstilling for datarammeskriver: parquet.vorder.enabled | unset | Kontrollér V-order-skrivninger ved hjælp af Dataframe-skriver |
Brug følgende kommandoer til at styre brugen af V-Order-skrivninger.
Kontrollér V-Order-konfigurationen i Apache Spark-sessionen
%%sql
GET spark.sql.parquet.vorder.enabled
Deaktiver V-Order-skrivning i Apache Spark-sessionen
%%sql
SET spark.sql.parquet.vorder.enabled=FALSE
Aktivér V-Order-skrivning i Apache Spark-sessionen
Vigtigt
Når den er aktiveret på sessionsniveau. Alle parquetskrivninger foretages med V-Order aktiveret. Dette omfatter ikke-Delta-parquettabeller og Delta-tabeller, hvor tabelegenskaben parquet.vorder.enabled er angivet til enten true eller false.
%%sql
SET spark.sql.parquet.vorder.enabled=TRUE
Kontrollér V-rækkefølge ved hjælp af egenskaber for tabellen Delta
Aktivér egenskaben for tabellen V-Order under oprettelse af tabellen:
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled","true");
Vigtigt
Når tabelegenskaben er angivet til true. Kommandoerne INSERT, UPDATE og MERGE fungerer som forventet og udføres. Hvis konfigurationen af V-Order-sessionen er angivet til sand, eller hvis spark.write aktiverer den, vil skrivene være V-Order, selvom TBLPROPERTIES er angivet til falsk.
Aktivér eller deaktiver V-rækkefølge ved at ændre tabelegenskaben:
%%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 aktiveret eller deaktiveret V-order ved hjælp af tabelegenskaber, påvirkes det kun fremtidige skrivninger til tabellen. Parquetfiler bevarer den rækkefølge, der blev brugt, da den blev oprettet. Hvis du vil ændre den aktuelle fysiske struktur for at anvende eller fjerne V-order, skal du læse afsnittet "Kontrollér V-rækkefølge, når du optimerer en tabel".
Styring af V-order direkte ved skrivehandlinger
Alle Apache Spark-skrivekommandoer nedarver sessionsindstillingen, hvis den ikke er eksplicit. Alle følgende kommandoer skrives ved hjælp af V-Order ved implicit at nedarve sessionens konfiguration.
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")
Vigtigt
V-Order anvender kun filer, der påvirkes af prædikatet.
I en session, hvor spark.sql.parquet.vorder.enabled er ikke angivet eller angivet til falsk, skrives følgende kommandoer ved hjælp af V-rækkefølge:
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()
Hvad er optimeret skrivning?
Analytiske arbejdsbelastninger i Big Data-behandlingsprogrammer, f.eks. Apache Spark, fungerer mest effektivt, når du bruger standardiserede større filstørrelser. Relationen mellem filstørrelsen, antallet af filer, antallet af Spark-arbejdere og dens konfigurationer spiller en vigtig rolle for ydeevnen. Indtagelse af arbejdsbelastninger i data lake-tabeller kan have den arvelige egenskab, at der konstant skrives mange små filer. dette scenarie kaldes ofte "problemet med den lille fil".
Optimer skrivning er en Delta Lake på Microsoft Fabric- og Azure Synapse Analytics-funktionen i Apache Spark-programmet, der reducerer antallet af filer, der skrives, og som har til formål at øge de skrevne datas individuelle filstørrelse. Målfilens størrelse kan ændres i forhold til kravene til en arbejdsbelastning ved hjælp af konfigurationer.
Funktionen er som standard aktiveret i Microsoft Fabric Runtime til Apache Spark. Hvis du vil vide mere om Optimer skrivebrugsscenarier, skal du læse artiklen Behovet for at optimere skrivning på Apache Spark
Fletoptimering
Kommandoen Delta Lake MERGE giver brugerne mulighed for at opdatere en deltatabel med avancerede betingelser. Det kan opdatere data fra en kildetabel, en visning eller en DataFrame til en destinationstabel ved hjælp af kommandoen MERGE. Den aktuelle algoritme i åben kildekode distributionen af Delta Lake er dog ikke fuldt optimeret til håndtering af uændrede rækker. Microsoft Spark Delta-teamet implementerede en brugerdefineret Low Shuffle Merge-optimering. Uændrede rækker udelades fra en dyr blandingshandling, der er nødvendig for at opdatere tilsvarende rækker.
Implementeringen styres af spark.microsoft.delta.merge.lowShuffle.enabled konfigurationen, der som standard er aktiveret i kørslen. Den kræver ingen kodeændringer og er fuldt kompatibel med distributionen af Delta Lake med åben kildekode. Hvis du vil vide mere om brugsscenarier for lav shufflefletning, skal du læse artiklen Low Shuffle Merge-optimering på Delta-tabeller
Delta-tabelvedligeholdelse
I takt med at Delta-tabeller ændres, bliver ydeevnen og lageromkostningen ofte forringet af følgende årsager:
- Nye data, der føjes til tabellen, kan skæve data
- Dataindtagelseshastigheder for batch- og streamingdata kan medføre mange små filer
- Opdaterings- og sletningshandlinger medfører til sidst læseomkostninger. parquet-filer er uforanderlige af design, så Delta-tabeller tilføjer nye parquetfiler, som ændringssættet, yderligere forstærker de problemer, der pålægges af de første to elementer.
- Der er ikke længere brug for datafiler og logfiler, der er tilgængelige i lageret.
For at sikre, at tabellerne er i den bedste tilstand for at opnå den bedste ydeevne, skal du udføre bin-komprimering og støvsugning i Delta-tabellerne. Beholderkomprimering opnås ved hjælp af kommandoen OPTIMIZE . Den fletter alle ændringer i større, sammenflettede parquetfiler. Ryd op i lageret, der refereres til, opnås ved hjælp af kommandoen VACUUM .
Vigtigt
Det er sandsynligvis vigtigere at designe den fysiske tabelstruktur på baggrund af indtagelsesfrekvensen og forventede læsemønstre end at køre de optimeringskommandoer, der er beskrevet i dette afsnit.
Styr V-rækkefølge, når du optimerer en tabel
Følgende kommandostrukturer bin-compact og omskrive alle berørte filer ved hjælp af V-Order, uafhængigt af indstillingen TBLPROPERTIES eller sessionskonfigurationsindstillingen:
%%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 og VORDER bruges sammen, udfører Apache Spark bin-compaction, ZORDER, VORDER sekventielt.
Følgende kommandoer er bin-compact og omskriver alle berørte filer ved hjælp af indstillingen TBLPROPERTIES. Hvis TBLPROPERTIES er angivet til true til V-Order, skrives alle berørte filer som V-Order. Hvis TBLPROPERTIES ikke er angivet eller angivet til falsk til V-rækkefølge, arver den sessionsindstillingen. så hvis du vil fjerne V-Order fra tabellen, skal du angive sessionens konfiguration til falsk.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];