Vedligeholdelse og optimering af tværarbejdstabels i Microsoft Fabric

Delta-tabeller i Microsoft Fabric understøtter flere forbrugsmotorer, hver med forskellige ydelseskarakteristika og optimeringskrav. Denne guide giver en omfattende ramme for at forstå, hvordan tabeller skrevet af én motor forbruges af andre, og hvordan man optimerer strategier for tabelvedligeholdelse derefter.

At forstå forholdet mellem skrivemønstre og læseydelse på tværs af forskellige motorer er essentielt for at opbygge effektive dataplatforme. Målet er at sikre, at dataproducenter skaber tabellayouts, der optimerer læseydelsen for downstream-forbrugere, uanset om disse forbrugere bruger Spark, SQL-analyseendpoint, Power BI Direct Lake eller Warehouse.

Skriv og læs scenariematrix

Følgende tabel opsummerer de forventede præstationskarakteristika for almindelige skrive- og læsekombinationer sammen med anbefalede optimeringsstrategier. Brug denne matrix til at identificere dit scenarie og forstå den relevante vejledning.

Skrivemetode	Læsemotor	Forventede huller	Anbefalet strategi
Spark-batch	Spark	Ingen huller	Standard Spark-skrivekonfigurationer er tilstrækkelige
Spark-batch	SQL Analytics-slutpunkt	Ingen huller	Aktivér auto-komprimering og optimer-skrivning
Spark-streaming	Spark	Små filer mulige	Autokomprimering og optimering-skrivning med planlagt OPTIMIZE
Spark-streaming	SQL Analytics-slutpunkt	Små filer og kontrolpunkter	Auto-komprimering, optimer-skriv,split medallion-lag
Lagersted	Spark	Ingen huller	Systemstyret optimering håndterer layout
Lagersted	SQL Analytics-slutpunkt	Ingen huller	Systemstyret optimering håndterer layout

Optimale fillayouts efter motor

Forskellige forbrugsmotorer har forskellige optimale fillayouts. At forstå disse mål hjælper dig med at konfigurere drifts- og vedligeholdelsesjobs passende.

Vejledning for SQL-analyse-endpoint og Fabric Data Warehouse

For optimal ydeevne med SQL-analyseendpointet og Warehouse, brug følgende indstillinger:

• Målfilstørrelse: Omkring 400 MB pr. fil
• Rækkegruppestørrelse: Omkring 2 millioner rækker pr. rækkegruppe
• V-Order: Forbedrer læseydelsen med 10%

Et lager bruger disse kriterier til at finde kandidater til kompaktering:

• Overhead for tabelfilerne er mere end 10%
• Tabellens logisk slettede rækker er mere end 10%
• Bordstørrelsen er større end 1.024 rækker

Under komprimeringsudførelsen udvælger processen kandidater baseret på disse kriterier:

• Enhver fil er mindre end 25% af den ideelle størrelse (baseret på rækkeantal)
• Enhver fil har mere end 20% slettede rækker

Spark

Spark er robust, når man læser forskellige filstørrelser. For optimal ydeevne:

• Målfilstørrelse: 128 MB til 1 GB afhængigt af tabelstørrelsen
• Rækkegruppestørrelse: 1 million til 2 millioner rækker pr. rækkegruppe
• V-Order: Ikke påkrævet for Spark-læseydelse (kan tilføje 15-33% skriveoverhead)

Spark-læsninger drager fordel af adaptiv målfilstørrelse, som automatisk justeres baseret på tabelstørrelse:

• Tabeller under 10 GB: 128 MB mål
• Tabeller over 10 TB: Op til 1 GB mål

Power BI Direct Lake

For optimal Direct Lake-ydelse:

• Målrækkegruppestørrelse: 8 millioner eller flere rækker pr. rækkegruppe for bedste ydeevne
• V-Order: Kritisk for 40-60% forbedring i cold-cache-forespørgsler
• Filantal: Minimer filantal for at reducere transkodningsoverhead
• Konsistente filstørrelser: Vigtigt for forudsigelig forespørgselsydelse

Direct Lake-semantiske modeller præsterer bedst, når:

• Kolonnedata er V-ordnet for VertiPaq-kompatibel komprimering
• Rækkegrupper er store nok til effektiv ordbogssammenlægning
• Deletionsvektorer minimeres gennem almindelig komprimering

For mere information, se Forstå Direct Lake-forespørgselsydelse.

Mirroring

Spejling automatisk skalerer filer baseret på tabelvolumen:

Tadelstørrelse	Rækker pr. rækkegruppe	Rækker pr. fil
Lille (op til 10 GB)	2 millioner	10 millioner
Medium (10 GB til 2,56 TB)	4 millioner	60 millioner
Stort (over 2,56 TB)	8 millioner	80 millioner

Skrivemønstre og konfigurationer

Spark-skrivemønstre

Spark-skrivninger bruger følgende standardkonfigurationer:

Konfiguration	Standardværdi	Beskrivelse
spark.microsoft.delta.optimizeWrite.fileSize	128 MB	Målfilstørrelse for optimerede skrivninger
spark.databricks.delta.optimizeWrite.enabled	Det varierer efter profil	Muliggør automatisk filkoalescing
spark.databricks.delta.autoCompact.enabled	Deaktiveret	Muliggør post-write-komprimering
spark.sql.files.maxRecordsPerFile	Ubegrænset	Maksimale poster pr. fil

For at konfigurere Spark-skrivninger til downstream SQL-forbrug:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

For mere information om ressourceprofiler og deres standardindstillinger, se Konfigurér ressourceprofilkonfigurationer.

Lagerskrivningsmønstre

Warehouse optimerer automatisk datalayoutet under skrivninger:

• V-Order er aktiveret som standard for læseoptimering.
• Automatisk kompaktering kører som en baggrundsproces.
• Checkpoint-styring håndteres automatisk.

Lageret producerer filer optimeret til SQL-forbrug uden manuel indgriben. Tabeller skrevet af Warehouse er iboende optimeret til både SQL-analyseendpoint og Warehouse-læsninger.

Bordvedligeholdelsesoperationer

OPTIMEER-kommandoen

Kommandoen OPTIMIZE samler små filer til større filer:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Vigtigt!

Kommandoen OPTIMIZE er en Spark SQL-kommando. Du skal køre det i Spark-miljøer som notesbøger, Spark-jobdefinitioner eller Lakehouse Maintenance-grænsefladen. SQL analytics-endpointet og Warehouse SQL-forespørgselseditoren understøtter ikke denne kommando.

For mere information, se Tabel kompaktering.

Automatisk komprimering

Autokomprimering evaluerer automatisk partitionens sundhed efter hver skriveoperation og udløser synkron optimering, når filfragmentering opdages:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Brug automatisk komprimering til indtastningspipelines med hyppige små skrivninger (streaming eller microbatch) for at undgå manuel planlægning og holde filer komprimeret automatisk.

Autokomprimering og optimeret skrivning giver typisk de bedste resultater, når de bruges sammen. Optimert skrivning reducerer antallet af små filer, der skrives, og automatisk komprimering håndterer den resterende fragmentering.

For mere information, se Auto kompaktering.

Optimer skrivning

Optimer skrivning reducerer overhead for små filer ved at udføre pre-write komprimering, hvilket genererer færre og større filer:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optimere skrivning er gavnligt for:

• Partitionerede tabeller
• Borde med hyppige små indsatser
• Operationer, der berører mange filer (MERGE, UPDATE, ) DELETE

Pre-write kompaktion (optimer, skriv) er generelt billigere end post-write komprimering (optimering). For mere information, se Optimer skrivning.

VAKUUM-kommando

Kommandoen VACUUM fjerner gamle filer, som en Delta-tabellog ikke længere refererer til:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Standardopbevaringsperioden er syv dage. Kortere tilbageholdelsesperioder påvirker Deltas tidsrejsemuligheder og kan forårsage problemer med samtidige læsere eller forfattere.

For mere information, se vedligeholdelse af Lakehouse-tabelen.

V-ordensoptimering

V-Order er en skrivetidsoptimering, der anvender VertiPaq-kompatibel sortering, kodning og komprimering på Parquet-filer:

• Power BI Direct Lake: 40-60% forbedring i cold-cache-forespørgsler
• SQL analytics endpoint og Warehouse: Cirka 10% forbedring i læseydelsen
• Spark: Ingen iboende læsefordel; 15-33% langsommere skrivninger

Hvornår skal V-Order aktiveres

V-Order giver størst fordel for:

• Guldlagstabeller, der betjener Power BI Direct Lake
• Tabeller ofte forespurgt gennem SQL analytics-endpointet
• Læseintensive arbejdsbelastninger, hvor skriveydelsen er mindre kritisk

Hvornår skal man undgå V-Order

Overvej at deaktivere V-Order for:

• Bronzelagstabeller fokuserede på indtagelseshastighed
• Spark-til-Spark pipelines, hvor SQL og Power BI ikke forbruger dataene
• Skrivetunge arbejdsbelastninger, hvor datalatens er kritisk

Konfigurér V-Order

V-Order er deaktiveret som standard i nye Fabric-arbejdsområder. Aktivering:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

For selektivt at anvende V-Order baseret på Direct Lake-forbrug, bør man overveje at automatisere V-Order aktivering for tabeller, der bruges i Direct Lake semantiske modeller. Tabeller, der ikke forbruges af Direct Lake, kan forblive uden V-Order for bedre skriveydelse.

Du kan få flere oplysninger under Tabeloptimering af Delta Lake og V-Order.

Væskeklyngedannelse og Z-orden

Flydende klynger

Liquid Clustering er den anbefalede tilgang til dataorganisering. I modsætning til traditionel partitionering er Liquid Clustering:

• Tilpasser sig ændrede forespørgselsmønstre
• Kræver OPTIMIZE anvendelse af clustering
• Giver bedre filspring for filtrerede forespørgsler

Aktiver Liquid Clustering ved tabeloprettelse:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-orden

Z-Order samler relaterede data i de samme filer, så du får bedre forespørgselsydelse på filterprædikater.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Brug Z-Order, når:

• Din tabel er partitioneret, fordi Liquid Clustering ikke virker med partitionerede tabeller.
• Dine forespørgsler filtreres ofte på to eller flere kolonner samtidig.
• Dine prædikater er selektive nok til at drage fordel af filspring.

Medaljonarkitekturanbefalinger

Medaljonarkitekturen (bronze-, sølv- og guldlag) giver en ramme til optimering af strategier for bordvedligeholdelse baseret på formålet med hvert lag.

Bronzelag (landingszone)

Bronze-tabeller fokuserer på skriveydelse og lav-latens indlæsning:

• Optimeringsprioritet: Indlæsningshastighed over læseydelse
• Partitionering: Acceptabelt, men frarådes for nye implementeringer
• Små filer: Acceptabelt, da fokus er på indtagelseshastighed
• V-Order: Ikke anbefalet (tilføjer skriveoverhead)
• Auto-komprimering: Aktiver for at reducere små filer, men kan ofres for at opnå indtastningshastighed
• Sletningsvektorer: Aktivér for tabeller med sammenfletningsmønstre

Bronze-tabeller bør ikke leveres direkte til SQL analytics-endpoint- eller Power BI Direct Lake-forbrugere.

Sølvlag (kurateret zone)

Sølvtabeller balancerer skrive- og læseydelse:

• Optimeringsprioritet: Balance mellem indlæsning og forespørgselsydelse
• Filstørrelser: Moderat (128-256 MB) for at understøtte både skrive- og læseoperationer
• V-Order: Valgfrit; muliggør hvis SQL analytics endpoint eller Power BI forbrug er betydeligt
• Liquid Clustering eller Z-orden: Anbefales for at forbedre forespørgselsydelsen
• Auto-komprimering og optimeringsskrivning: Aktiver baseret på nedstrøms krav
• Sletningsvektorer: Aktiver for tabeller med hyppige opdateringer
• Planlagt OPTIMIZE: Kør aggressivt for at opretholde fillayoutet

Guldlag (serveringszone)

Guldtabeller prioriterer læseydelse til slutbrugerens forbrug:

• Optimeringsprioritet: Læseydelse for analyser
• Filstørrelser: Stor (400 MB til 1 GB) for optimal SQL- og Power BI-ydelse
• V-Order: Påkrævet for Power BI Direct Lake; fordelagtig for SQL-analyse-endpoint
• Flydende klyngedannelse: Påkrævet for optimal filspringning
• Optimize-write: Påkrævet for ensartede filstørrelser
• Planlagt OPTIMERING: Kør aggressivt for at opretholde det optimale layout

Optimer guldtabeller forskelligt afhængigt af hovedforbrugsmotoren:

Forbrugsmotor	V-rækkefølge	Målfilstørrelse	Rækkegruppestørrelse
SQL Analytics-slutpunkt	Ja	400 MB	2 millioner rækker
Power BI Direct Lake	Ja	400 MB til 1 GB	8+ millioner rækker
Spark	Valgfrit	128 MB til 1 GB	1-2 millioner rækker

Flere tabelkopier

Det er acceptabelt at vedligeholde flere kopier af tabeller, der er optimeret til forskellige forbrugsmønstre:

• Et sølvbord optimeret til Spark-behandling
• En guldtabel optimeret til SQL-analyse-endpoint og Power BI Direct Lake
• Datapipelines, der transformerer og placerer den rette struktur på hvert lag

Lagring er billig i forhold til compute. Optimering af tabeller for deres forbrugsmønstre giver en bedre brugeroplevelse end at forsøge at betjene alle forbrugere fra et enkelt tabellayout.

Identificer tabelens sundhed

Før du optimerer tabeller, vurder den aktuelle tabels sundhed for at forstå optimeringsbehov.

Inspicer Parquet-filer direkte

Du kan gennemse tabelmappen i OneLake for at inspicere størrelserne på individuelle Parquet-filer. Sunde tabeller har jævnt fordelte filstørrelser. Se efter:

• Konsistente filstørrelser: Filerne bør have omtrent samme størrelse (inden for 2x af hinanden).
• Ingen ekstremt små filer: Filer under 25 MB indikerer fragmentering.
• Ingen ekstremt store filer: Filer over 2 GB kan reducere parallelisme.

Ujævn filstørrelsesfordeling indikerer ofte manglende komprimering eller inkonsistente skrivemønstre på tværs af forskellige jobs.

OPTIMER DRY Run i Spark SQL

Brug muligheden DRY RUN for at forhåndsvise, hvilke filer der er egnede til optimering uden at udføre komprimeringen:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Kommandoen returnerer en liste over filer, der ville blive omskrevet under optimeringen. Brug dette til at:

• Vurder optimeringens omfang, før du kører den.
• Forstå filfragmentering uden at ændre tabellen.
• Estimerer optimeringstiden baseret på antallet af berørte filer.

Filstørrelsesfordeling

Brug følgende tilgang til at analysere filstørrelser og fordeling:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Fordelingen kan være skæv, da filer tæt på tabellens hoved eller fra en bestemt partition måske ikke er optimeret.

Du kan vurdere fordelingen ved at køre en forespørgsel, der grupperer efter tabellens opdelings- eller klyngenøgler.

Bestem optimeringsbehov

Baseret på forbrugsmotoren sammenlignes de faktiske filstørrelser med målstørrelser:

Motor	Målfilstørrelse	Hvis filerne er mindre	Hvis filerne er større
SQL Analytics-slutpunkt	400 MB	Kør OPTIMIZE	Filer er acceptable
Power BI Direct Lake	400 MB til 1 GB	Kør OPTIMIZE VORDER	Filer er acceptable
Spark	128 MB til 1 GB	Aktivér automatisk komprimering	Filer er acceptable

Tabelhistorik og transaktionslog

Gennemgå tabellens historik for at forstå skrivemønstre og vedligeholdelsesfrekvens:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Konfigurationsbedste praksis

Brug tabelegenskaber over sessionskonfigurationer

Tabelegenskaber består på tværs af sessioner og sikrer ensartet adfærd på tværs af alle jobs og forfattere:

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Sessionsniveau-konfigurationer gælder kun for den aktuelle Spark-session og kan forårsage inkonsistente skrivninger, hvis forskellige sessioner bruger forskellige konfigurationer.

Aktivér adaptiv målfilstørrelse

Adaptiv målfilstørrelse justerer automatisk filstørrelsesmål baseret på tabelstørrelse:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Denne funktion:

• Starter med mindre filer (128 MB) til små tabeller
• Skalerer op til 1 GB for tabeller over 10 TB
• Re-evaluering automatisk under OPTIMIZE operationer

Aktivér fil-niveau kompaktionsmål

Undgå at omskrive tidligere komprimerede filer, når målstørrelserne ændres:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Resumé af anbefalinger

Lag	Auto-komprimering	Optimer-skriv	V-rækkefølge	Flydende klynger	Planlagt OPTIMIZE
Bronze	Aktiver (valgfrit)	Enable	Nej	Nej	Valgfrit
Sølv	Enable	Enable	Valgfrit	Ja	Aggressiv
Guld	Enable	Enable	Ja	Ja	Aggressiv

For specifikke scenarier kan du bruge følgende anbefalinger:

• Spark-to-Spark: Fokuser på optimering af filstørrelse; V-Order valgfrit.
• Spark-to-SQL: Aktiver optimeringsskrivning og autokomprimering; sigt mod 400 MB filer med 2 millioner rækkegrupper.
• Streaming-indlæsning: Aktiver automatisk komprimering; planlæg yderligere OPTIMIZE jobs til SQL-brugere.
• Power BI Direct Lake: Aktiver V-orden; mål 8+ millioner rækkegrupper; løb.OPTIMIZE VORDER

Relateret indhold

• Tabeloptimering af Delta Lake og V-Order
• Komprimering af tabel
• Juster filstørrelse
• Vedligeholdelse af Lakehouse bord
• Overvejelser i forbindelse med ydeevnen for SQL-analyseslutpunkter
• Retningslinjer for ydeevne i Fabric Data Warehouse
• Om ydeevnen af Direct Lake-forespørgsler