Tabelloptimalisering for Delta Lake og V-order

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 Big Data.

Hva er V-Order?

V-Order er en skrivetidsoptimalisering for parkettfilformatet som muliggjør lynraske lesinger under Databehandlingsmotorene for Microsoft Fabric, for eksempel Power BI, SQL, Spark og andre.

Power BI- og SQL-motorer benytter seg av Microsoft Verti-Scan-teknologi og V-bestilte parkettfiler 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 scenarioer på 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. V-rekkefølgesortering har en 15 % innvirkning på gjennomsnittlige skrivetider, men gir opptil 50 % mer komprimering.

Det er 100% åpen kildekode parquet format kompatibel; alle parkettmotorer kan lese det som en vanlig parkett filer. Delta-tabeller er mer effektive enn noensinne. funksjoner som Z-Order er kompatible med V-Order. Tabellegenskaper og optimaliseringskommandoer kan brukes på kontrollen V-Order på partisjonene.

V-order brukes på parquet-filnivå. Delta-tabeller og funksjoner, for eksempel Z-order, komprimering, vakuum, tidsreiser osv. er ortogonale 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 Bekrivelse
spark.sql.parquet.vorder.enabled sann Kontrollerer V-ordreskriving på øktnivå.
TBLPROPERTIES("delta.parquet.vorder.enabled") usann Standard V-Ordre-modus 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-skrivere.

Kontroller V-Order-konfigurasjonen i Apache Spark-økten

%%sql 
SET 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-skrivere gjøres med V-Order aktivert. Dette inkluderer ikke-Delta-parketttabeller 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 tabellegenskaper for Delta

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, vil KOMMANDOENE INSERT, UPDATE og MERGE fungere som forventet og utføre optimaliseringen av skrivetid. 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-ordre 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 Kontroll V-rekkefølge når du optimaliserer en tabell.

Kontrollere V-ordre direkte på skriveoperasjoner

Alle Apache Spark-skrivekommandoer arver øktinnstillingen hvis den ikke er eksplisitt. Alle følgende kommandoer skriver ved hjelp av V-order 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 gjelder bare for filer som påvirkes av predikatet.

I en økt der spark.sql.parquet.vorder.enabled den ikke er usann 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 Optimaliser skriving?

Analytiske arbeidsbelastninger på Big Data-behandlingsmotorer som Apache Spark fungerer mest effektivt når du bruker standardiserte større filstørrelser. Relasjonen mellom filstørrelsen, antall filer, antall Spark-arbeidere og konfigurasjonene, spiller en kritisk rolle i ytelsen. Inntak av data i datasjøtabeller kan ha den arvede karakteristikken ved stadig å skrive mange små filer. dette scenarioet kalles vanligvis «det lille filproblemet».

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 på de skriftlige dataene. Målfilstørrelsen kan endres per arbeidsbelastningskrav 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 skriveskriving, kan du lese artikkelen Behovet for optimalisering av 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 KOMMANDOEN SLÅ SAMMEN. Men den nåværende algoritmen i åpen kilde fordelingen av Delta Lake er ikke fullt optimalisert for håndtering av umodifiserte rader. Microsoft Spark Delta-teamet implementerte en egendefinert optimalisering for lav shufflefletting, umodifiserte rader er utelatt fra en dyr shuffling-operasjon som er nødvendig for å oppdatere samsvarende rader.

Implementeringen styres av konfigurasjonen spark.microsoft.delta.merge.lowShuffle.enabled , aktivert som standard i kjøretiden. Det krever ingen kodeendringer og er fullt kompatibel med åpen kildekodefordelingen av Delta Lake. Hvis du vil lære mer om bruksscenarioer for lav shufflefletting, kan du lese artikkelen Low Shuffle Merge optimization on Delta tables.

Delta-tabellvedlikehold

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.
  • Oppdater og slett operasjoner til slutt opprette lese overhead; parkettfiler er uforanderlige ved utforming, så Delta-tabeller legger til nye parkettfiler med endringene, 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 best mulig ytelse, utføre bin-komprimering og støvsugingsoperasjoner i Delta-tabellene. Bin-komprimering oppnås av OPTIMIZE-kommandoen. Den slår sammen alle endringer til større, konsoliderte parkettfiler. Opprydding av dereferenced-lagring oppnås av VACUUM-kommandoen .

Tabellvedlikeholdskommandoene OPTIMIZE og VACUUM kan brukes i notatblokker og Spark Job Definitions, og deretter orkestreres ved hjelp av plattformfunksjoner. Lakehouse in Fabric tilbyr en funksjonalitet for å bruke brukergrensesnittet til å utføre vedlikehold av ad hoc-tabeller som forklart i vedlikeholdsartikkelen for Delta Lake-tabellen.

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 omskriver alle berørte filer ved hjelp av V-Order, uavhengig av innstillingen TBLPROPERTIES 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 som usann.

%%sql 
OPTIMIZE <table|fileOrFolderPath>;

OPTIMIZE <table|fileOrFolderPath> WHERE predicate;

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