Bemærk
Adgang til denne side kræver godkendelse. Du kan prøve at logge på eller ændre mapper.
Adgang til denne side kræver godkendelse. Du kan prøve at ændre mapper.
Lakehouse- og Delta Lake-tabelformatet er centrale for Microsoft Fabric. At holde Delta-tabeller optimeret er nøglen til ydeevne og omkostningseffektivitet for analysearbejdsbyrder.
Denne artikel hjælper dig med at beslutte, hvornår du skal bruge V-Order, og viser de vigtigste konfigurations- og vedligeholdelsesmønstre for Delta-tabeller.
Brug denne artikel til at:
- Forstå, hvad V-Order ændrer, og hvornår det hjælper.
- Forstå, hvordan Z-ordenen og V-ordenen supplerer hinanden.
- Vælg det rigtige kontrolniveau: session, tabelegenskab eller skriveoperation.
- Anvend vedligeholdelsesmønstre for Delta-tabellen i den rigtige Spark-runtime-kontekst.
For vejledning på tværs af arbejdsbelastninger om, hvornår V-Order skal anvendes baseret på forbrugsscenarier, se Cross-workload table maintenance and optimization.
Hvad er V-Order?
V-Order er en skrivetidsoptimering for Parquet-filer, som kan forbedre downstream forespørgselsydelsen på tværs af Fabric-motorer.
Et overblik:
- Hvor det hjælper mest: Læse-tunge mønstre som dashboarding, interaktiv analyse og gentagne scanninger.
- Hvordan det hjælper: Reorganiserer Parquet-layoutet (for eksempel rækkegruppefordeling, kodning og komprimering) for at forbedre læseeffektiviteten.
- Typisk afvejning: Skrivninger kan tage længere tid (ofte omkring 15% i gennemsnit), mens læsninger kan forbedres betydeligt afhængigt af arbejdsbyrden.
- Motorkompatibilitet: Filer forbliver open source Parquet-kompatible, og Delta-funktioner som Z-Order forbliver kompatible.
- Omfang: V-Order er filniveau. Delta-operationer som kompaktion, vakuum og tidsrejser kan bruges med den.
Control V-Order skriver
V-Order bruges til at optimere Parquet-fillayoutet for hurtigere forespørgselsydelse, især i læseintensive scenarier. I Microsoft Fabric er V-Order som standard deaktiveret for alle nyoprettede arbejdsområder for at optimere ydeevnen for skrivetunge datatekniske arbejdsbelastninger.
Funktionsmåden for V-Order i Apache Spark styres via følgende konfigurationer:
| Konfiguration | Standardværdi | Beskrivelse |
|---|---|---|
spark.sql.parquet.vorder.default |
false |
Styrer skrivning af V-ordre på sessionsniveau. Indstillet til false som standard i nye Fabric-arbejdsområder. |
TBLPROPERTIES("delta.parquet.vorder.enabled") |
Fjern indstillingen | Styrer standardfunktionsmåden for V-rækkefølge på tabelniveau. |
Indstillingen DataFrame-skriver: parquet.vorder.enabled |
Fjern indstillingen | Bruges til at styre V-Order på skrivehandlingsniveau. |
Brug følgende kommandoer til at aktivere eller tilsidesætte V-Order-skrivninger efter behov i dit scenarie.
V-Order er deaktiveret som standard i nye Fabric-arbejdsområder (spark.sql.parquet.vorder.default=false) for at forbedre skriveydelsen for indlæsnings- og transformationspipelines.
For læseintensive arbejdsbelastninger som interaktive forespørgsler eller dashboarding, aktiver V-Order ved at sætte spark.sql.parquet.vorder.default til true. Du kan også skifte til readHeavyforSpark ressourceprofiler ReadHeavy , som automatisk aktiverer V-Order for læsefokuseret ydeevne.
I Fabric runtime 1.3 og senere er indstillingen spark.sql.parquet.vorder.enable fjernet. Fordi V-Order kan anvendes automatisk under Delta-optimering med OPTIMIZE, behøver du ikke denne ældre indstilling. Hvis du migrerer fra tidligere runtime-versioner, skal du fjerne denne indstilling fra din kode.
Kontrollér konfigurationen af V-Order i Apache Spark-sessionen
Brug disse kommandoer til at bekræfte den aktuelle sessionsværdi, før du ændrer den.
%%sql
SET spark.sql.parquet.vorder.default
Deaktiver V-Order-skrivning i Apache Spark-sessionen
Brug disse kommandoer, når din arbejdsbyrde er skrivetynget, og du ønsker hurtigere indtastning eller transformationsskrivninger.
%%sql
SET spark.sql.parquet.vorder.default=FALSE
Aktivér V-Order-skrivning i Apache Spark-sessionen
Når du aktiverer V-Order på sessionsniveau, bruger alle Parquet-skrivninger i den session V-Order, inklusive ikke-Delta Parquet-tabeller og Delta-tabeller, selvom parquet.vorder.enabled det eksplicit er sat til false.
%%sql
SET spark.sql.parquet.vorder.default=TRUE
Kontrollér V-rækkefølge ved hjælp af egenskaber for Delta-tabel
Denne sektion bruger kun Spark SQL, fordi tabelegenskaber defineres gennem SQL DDL og ALTER TABLE statements.
Brug tabelegenskaber, når du vil have en tabelniveau-standard, der gælder på tværs af sessioner.
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");
Når tabelegenskaben sættes til true, INSERT, UPDATE, og MERGE anvend V-ordenen ved skrivetidspunktet. Sessions- og skriveniveau-indstillinger har stadig forrang, så skrivninger kan stadig bruge V-Order, selv når TBLPROPERTIES er sat til false.
Aktivér eller deaktiver V-order 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, er det kun fremtidige skrivninger til tabellen, der påvirkes. 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 se, hvordan du styrer V-Order, når du optimerer en tabel.
Styring af V-order direkte ved skrivehandlinger
Denne sektion bruger PySpark til at demonstrere DataFrame writer API'en. Det samme mønster findes i Scala DataFrame API'er med tilsvarende muligheder.
Brug skriveniveau-muligheder, når du har brug for kontrol pr. operation, i stedet for sessions- eller tabel-dækkende standardindstillinger.
Alle Apache Spark-skrivekommandoer arver sessionsindstillingen, når de ikke eksplicit overskrives. Følgende eksempler skriver ved hjælp af V-Order ved at arve 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 >= '2025-01-01' AND end_date <= '2025-01-31'")\
.saveAsTable("myschema.mytable")
V-Order gælder kun for filer, der er påvirket af prædikatet.
I en session hvor spark.sql.parquet.vorder.default er unset eller sat til false, skriver følgende kommandoer ved hjælp af V-Order:
df_source.write\
.format("delta")\
.mode("overwrite")\
.option("replaceWhere","start_date >= '2025-01-01' AND end_date <= '2025-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 Optimer skrivning?
Analytical Spark-arbejdsbelastninger præsterer som regel bedre, når filstørrelserne er mere konsistente, og antallet af filer er lavere. Indtagelsespipelines producerer ofte mange små filer, hvilket fører til det almindelige problem med små filer.
Optimer skrivning er en Delta Lake-funktion i Fabric og Synapse, der reducerer antallet af filer og øger den enkelte filstørrelse under skrivninger i Apache Spark. Målfilens størrelse kan ændres pr. arbejdsbelastningskrav ved hjælp af konfigurationer.
Funktionen er som standard aktiveret i Microsoft Fabric Runtime til Apache Spark. Du kan få mere at vide om Optimer skriveanvendelsesscenarier i artiklen Behovet for at optimere skrive på Apache Spark.
Fletteoptimering
Delta Lake MERGE opdaterer en måltabel fra en kildetabel, visning eller DataFrame. I open source Delta Lake kan man MERGE bruge unødvendigt shuffle-arbejde på uændrede rækker. Fabric runtime inkluderer Low Shuffle Merge-optimering for at reducere denne overhead.
Implementeringen styres af spark.microsoft.delta.merge.lowShuffle.enabled og er aktiveret som standard under runtime. Det kræver ingen kodeændringer og forbliver kompatibelt med open source Delta Lake. For at lære mere, se Low Shuffle Merge-optimering på Delta-tabeller.
Vedligeholdelse af deltatabel
Efterhånden som Delta-tabeller udvikler sig, kan ydeevne og lagringseffektivitet faldt af flere grunde:
- Nye data, der føjes til tabellen, kan forvrænge data.
- Dataindtagelseshastigheder for batch- og streamingdata kan medføre mange små filer.
- Opdaterings- og sletningsoperationer tilføjer læseoverhead, fordi Parquet-filer er uforanderlige, og Delta skriver nye filer til ændringer.
- Ældre data og logfiler kan akkumuleres i lageret.
For at holde bordene sunde, brug komprimerings- og oprydningsoperationer regelmæssigt:
- OPTIMIZE udfører bin-komprimering ved at samle ændringer i større Parquet-filer.
- VACUUM fjerner derefererede filer fra lagringen.
Tips
Brug Delta-tabelvedligeholdelse i Lakehouse til portal-baseret vedligeholdelsesworkflow, kørende overvågningsvejledning og retention-fokuseret operationel vejledning.
OPTIMIZE
VACUUM og er Spark SQL-kommandoer. Kør dem i:
- Stofnotesbøger med Spark-runtime.
- Definitioner af spark-job.
- Lakehouse-vedligeholdelse i Explorer. Se vedligeholdelse af Delta Lake-tabellen.
Disse kommandoer understøttes ikke i SQL Analytics Endpoint eller Warehouse SQL-forespørgselseditoren, som kun understøtter T-SQL. For SQL-endpoint-arbejdsgange kan du bruge Delta Lake tabelvedligeholdelse eller køre kommandoerne i en Fabric-notebook.
Design bordets fysiske struktur baseret på indtagelsesfrekvens og læs mønstre først. I mange arbejdsbelastninger har tabeldesign større indflydelse end optimeringskommandoer alene.
Styr V-rækkefølge, når du optimerer en tabel
Brug disse kommandoer, når du ønsker, at komprimering og V-Order omskrivning skal ske i én enkelt operation.
Z-Order og V-Order optimerer forskellige aspekter af læseydelsen:
-
Z-Order (SQL-nøgleord
ZORDER) samler relaterede værdier for at forbedre dataspringning for selektive filtre. -
V-Order (SQL-nøgleord )
VORDERoptimerer Parquet-fillayoutet for at forbedre læseeffektiviteten på tværs af Fabric-motorer.
Hvis dine forespørgsler ofte filtreres på specifikke kolonner, kan Z-Order hjælpe. Hvis din arbejdsbyrde generelt er læsetung, kan V-Order hjælpe. I mange tilfælde kan du kombinere begge dele.
Brug denne hurtige beslutningsguide:
- Brug
VORDERden, når du ønsker brede forbedringer i læseydelse på tværs af motorer. - Brug
ZORDER BY (...)detVORDER, når forespørgsler gentagne gange filtrerer på kendte kolonner, og du ønsker også fordelene ved V-Order layout.
Følgende kommando danner bin-kompakt og omskriver alle berørte filer ved hjælp af V-Order, uafhængigt af TBLPROPERTIES sessionsindstillinger:
%%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 i SQL, anvender Apache Spark bin-komprimering, derefter Z-Order og derefter V-Order.
Følgende kommandoer bin-kompakter og omskriver alle berørte filer ved hjælp af TBLPROPERTIES. Hvis TBLPROPERTIES er sat til at aktivere V-Order, skrives alle berørte filer med V-Order. Hvis TBLPROPERTIES er usat eller sat til false, arver adfærden sessionsindstillingen. For at fjerne V-Order fra tabelomskrivninger, sæt sessionskonfigurationen til .false
Når du kører disse kommandoer i Fabric-notesbøger, skal du inkludere et mellemrum mellem %%sql og OPTIMIZE.
Korrekt syntaks:
%%sql
OPTIMIZE table_name;
Forkert syntaks: %%sqlOPTIMIZE table_name;.
%%sql
OPTIMIZE <table|fileOrFolderPath>;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate;
OPTIMIZE <table|fileOrFolderPath> WHERE predicate [ZORDER BY (col_name1, col_name2, ...)];
Brug VACUUM til opbevaring og opbevaringsrengøring
Et almindeligt VACUUM scenarie er oprydning baseret på fastholdelse. Brug den, når ældre, ikke-refererede filer har hobet sig op, og du vil genvinde lagerplads efter opdateringer, sletninger eller gentagne indtastningscyklusser.
Kør VACUUM kun med et tilbageholdelsesvindue, der passer til dine forventninger til tidsrejser og genopretning. Standardmønsteret bevarer syv dages historie.
I Spark-notesbøger ser et kompakt VACUUM mønster sådan ud:
%%sql
VACUUM schema_name.table_name;
VACUUM schema_name.table_name RETAIN 168 HOURS;
For retentionsadfærd og sikkerhedsvejledning, se VAKUUM-kommandoen. For programmatiske vedligeholdelseskørsler, se Kør tabelvedligeholdelse på en Delta-tabel.