Tabelloptimalisering for Delta Lake og V-ordre
Tabellformatet Lakehouse og Delta Lake er sentralt i Microsoft Fabric, og sikrer at tabeller er optimalisert for analyse er et viktig krav. Denne veiledningen dekker tabelloptimaliseringskonsepter for Delta Lake, konfigurasjoner og hvordan du bruker det på de vanligste bruksmønstrene for store data.
Viktig
Microsoft Fabric er i forhåndsversjon.
Hva er V-Ordre?
V-Order er en skrivetidsoptimalisering til parquet-filformatet som gjør det mulig å lese lynrask under Microsoft Fabric-databehandlingsmotorer, for eksempel Power BI, SQL, Spark og andre.
Power BI- og SQL-motorer bruker Microsoft Verti-Scan-teknologi og V-bestilte parquetfiler for å oppnå minne som datatilgangstider. Spark og andre ikke-Verti-Scan-databehandlingsmotorer drar også nytte av V-bestilte filer med et gjennomsnitt på 10% raskere lesetider, med noen scenarier opptil 50%.
V-order fungerer ved å bruke spesiell sortering, radgruppedistribusjon, ordlistekoding og komprimering på parquet-filer, og krever dermed mindre nettverks-, disk- og CPU-ressurser i databehandlingsmotorer for å lese den, noe som gir kostnadseffektivitet og ytelse. Sortering av V-rekkefølge har 15 % innvirkning på gjennomsnittlige skrivetider, men gir opptil 50 % mer komprimering.
Dens 100% åpen kildekode parquet format kompatibel; alle parquet-motorer kan lese den som en vanlig parquet-filer. Deltatabeller er mer effektive enn noensinne. funksjoner som Z-order er kompatible med V-Order. Tabellegenskaper og optimaliseringskommandoer kan brukes på kontroll-V-rekkefølge på partisjonene.
V-order brukes på parquet-filnivå. Delta-tabeller og funksjonene, for eksempel Z-Order, komprimering, vakuum, tidsreiser osv. er ortogonal til V-order, som sådan, er kompatible og kan brukes sammen for ekstra fordeler.
Kontrollere V-order-skriving
V-order er aktivert som standard i Microsoft Fabric, og i Apache Spark styres den av følgende konfigurasjoner
| Konfigurasjon | Standardverdi | Beskrivelse |
|---|---|---|
| spark.sql.parquet.vorder.enabled | sann | Kontrollerer V-ordreskriving på øktnivå. |
| TBLPROPERTIES("delta.parquet.vorder.enabled") | usann | Standard V-ordremodus på tabeller |
| Alternativ for datarammeskriver: parquet.vorder.enabled | Fjern | Kontroller V-Order-skriving ved hjelp av Dataframe-skriver |
Bruk følgende kommandoer til å kontrollere bruken av V-Order-skriving.
Kontroller V-Order-konfigurasjonen i Apache Spark-økten
%%sql
GET spark.sql.parquet.vorder.enabled
Deaktiver V-Order-skriving i Apache Spark-økt
%%sql
SET spark.sql.parquet.vorder.enabled=FALSE
Aktiver V-Order-skriving i Apache Spark-økt
Viktig
Når aktivert på øktnivå. Alle parquet-skrivinger gjøres med V-Order aktivert. Dette inkluderer ikke-Delta-parquet-tabeller og Delta-tabeller med tabellegenskapen parquet.vorder.enabled satt til enten true eller false.
%%sql
SET spark.sql.parquet.vorder.enabled=TRUE
Kontroller V-rekkefølge ved hjelp av egenskaper for Delta-tabell
Aktiver V-Order-tabellegenskap under oppretting av tabell:
%%sql
CREATE TABLE person (id INT, name STRING, age INT) USING parquet TBLPROPERTIES("delta.parquet.vorder.enabled","true");
Viktig
Når tabellegenskapen er satt til sann, KOMMANDOENE INSERT, UPDATE og MERGE fungerer som forventet og utføres. Hvis V-Order-øktkonfigurasjonen er satt til sann eller spark.write aktiverer den, vil skrivingen være V-Order selv om TBLPROPERTIES er satt til usann.
Aktiver eller deaktiver V-ordre ved å endre 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 aktiverer eller deaktiverer V-rekkefølge ved hjelp av tabellegenskaper, påvirkes bare fremtidige skrivinger til tabellen. Parquet-filer beholder rekkefølgen som ble brukt da den ble opprettet. Hvis du vil endre gjeldende fysiske struktur for å bruke eller fjerne V-rekkefølge, kan du lese avsnittet «Kontroller V-rekkefølge når du optimaliserer en tabell».
Kontrollere V-ordre direkte på skriveoperasjoner
Alle Apache Spark-skrivekommandoer arver øktinnstillingen hvis de ikke er eksplisitte. Alle følgende kommandoer skriver ved hjelp av V-rekkefølge ved implisitt å arve øktkonfigurasjonen.
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")
Viktig
V-order bruker bare filer som påvirkes av predikatet.
I en økt der spark.sql.parquet.vorder.enabled det er usett eller satt til usann, skriver følgende kommandoer ved hjelp av V-rekkefø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()
Hva er optimalisert skriving?
Analytiske arbeidsbelastninger på Big Data-behandlingsmotorer som Apache Spark yter mest effektivt når du bruker standardiserte større filstørrelser. Relasjonen mellom filstørrelsen, antall filer, antall Spark-arbeidere og dens konfigurasjoner, spiller en viktig rolle i ytelsen. Inntaksarbeidsbelastninger i datasjøtabeller kan ha den arvede karakteristikken ved stadig å skrive mange små filer. dette scenarioet er kjent som «problemet med den lille filen».
Optimaliser skriving er en Delta Lake på Microsoft Fabric og Azure Synapse Analytics-funksjonen i Apache Spark-motoren som reduserer antall filer som er skrevet, og som har som mål å øke den individuelle filstørrelsen for de skrevne dataene. Størrelsen på målfilen kan endres i henhold til arbeidsbelastningskravene ved hjelp av konfigurasjoner.
Funksjonen er aktivert som standard i Microsoft Fabric Runtime for Apache Spark. Hvis du vil lære mer om optimaliser bruksscenarioer for skrivetilgang, kan du lese artikkelen Behovet for å optimalisere skriving på Apache Spark
Sammenslåingsoptimalisering
Kommandoen Delta Lake MERGE gjør det mulig for brukere å oppdatere en deltatabell med avanserte betingelser. Den kan oppdatere data fra en kildetabell, visning eller DataFrame til en måltabell ved hjelp av MERGE-kommandoen. Den gjeldende algoritmen i åpen kilde distribusjon av Delta Lake er imidlertid ikke fullstendig optimalisert for håndtering av umodifiserte rader. Microsoft Spark Delta-teamet implementerte en egendefinert optimalisering for low shuffle-sammenslåing, og uendrede rader utelates fra en dyr shuffling-operasjon som er nødvendig for å oppdatere samsvarende rader.
Implementeringen kontrolleres av konfigurasjonen spark.microsoft.delta.merge.lowShuffle.enabled , aktivert som standard i kjøretiden. Det krever ingen kodeendringer og er fullstendig kompatibel med åpen kilde-fordelingen av Delta Lake. Hvis du vil lære mer om bruksscenarioer for low shuffle-fletting, kan du lese artikkelen Low Shuffle Merge optimization on Delta tables
Vedlikehold av deltatabell
Etter hvert som Delta-tabeller endres, har ytelses- og lagringskostnadseffektiviteten en tendens til å reduseres av følgende årsaker:
- Nye data som legges til i tabellen, kan forskyve data
- Satsvis og strømming av datainntak kan føre til mange små filer
- Oppdatere og slette operasjoner etter hvert opprette leseoverstrede; parquet-filer er uforanderlige ved utforming, så Delta-tabeller legger til nye parquetfiler som endringene har, noe som ytterligere forsterker problemene som er pålagt av de to første elementene.
- Ikke lenger nødvendige datafiler og loggfiler som er tilgjengelige i lagringsplassen.
For å holde tabellene i beste tilstand for best ytelse kan du utføre bin-komprimering og støvsugingsoperasjoner i Delta-tabellene. Bin-komprimering oppnås ved hjelp av OPTIMALISER-kommandoen . den fletter alle endringer til større, konsoliderte parquet-filer. Opprydding av dereferenced-lagring oppnås av VACUUM-kommandoen .
Viktig
Riktig utforming av tabellens fysiske struktur basert på inntaksfrekvensen og forventede lesemønstre er sannsynligvis viktigere enn å kjøre optimaliseringskommandoene som er beskrevet i denne delen.
Kontroller V-rekkefølge når du optimaliserer en tabell
Følgende kommando strukturerer bin-compact og omskriving av alle berørte filer ved hjelp av V-Order, uavhengig av TBLPROPERTIES-innstillingen eller innstillingen for øktkonfigurasjon:
%%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 brukes sammen, utfører Apache Spark bin-komprimering, ZORDER, VORDER sekvensielt.
Følgende kommandoer bin-compact og omskrive alle berørte filer ved hjelp av TBLPROPERTIES-innstillingen. Hvis TBLPROPERTIES er satt til V-Order, skrives alle berørte filer som V-Order. Hvis TBLPROPERTIES er usett eller satt til usann til V-order, arver den øktinnstillingen. så hvis du vil fjerne V-ordre fra tabellen, angir du øktkonfigurasjonen til usann.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];