Vedlikehold og optimalisering av kryss-arbeidsbelastningstabeller i Microsoft Fabric

Delta-tabeller i Microsoft Fabric betjener flere forbruksmotorer, hver med ulike ytelsesegenskaper og optimaliseringskrav. Denne guiden gir et omfattende rammeverk for å forstå hvordan tabeller skrevet av én motor brukes av andre, og hvordan man kan optimalisere strategier for bordvedlikehold deretter.

Å forstå forholdet mellom skrivemønstre og leseytelse på tvers av ulike motorer er avgjørende for å bygge effektive dataplattformer. Målet er å sikre at dataprodusenter lager tabelloppsett som optimaliserer leseytelsen for nedstrøms forbrukere, enten disse brukerne bruker Spark, SQL-analyseendepunkt, Power BI Direct Lake eller Warehouse.

Skriv og les scenariomatrise

Tabellen nedenfor oppsummerer forventede ytelsesegenskaper for vanlige skrive- og lesekombinasjoner, sammen med anbefalte optimaliseringsstrategier. Bruk denne matrisen for å identifisere situasjonen din og forstå relevant veiledning.

Skrivemetode	Les-motor	Forventede gap	Anbefalt strategi
Gnistbatch	Spark	Ingen hull	Standard Spark-skrivekonfigurasjoner er tilstrekkelige
Gnistbatch	Endepunkt for SQL-analyse	Ingen hull	Aktiver automatisk komprimering og optimaliser-skriving
Spark-strømming	Spark	Små filer mulig	Autokomprimering og optimaliser-skriving med planlagt OPTIMIZE
Spark-strømming	Endepunkt for SQL-analyse	Små filer og sjekkpunkter	Autokomprimering, optimalisering-skriving, delt medaljonglag
Warehouse	Spark	Ingen hull	Systemstyrt optimalisering håndterer layout
Warehouse	Endepunkt for SQL-analyse	Ingen hull	Systemstyrt optimalisering håndterer layout

Optimale filoppsett etter motor

Ulike forbruksmotorer har ulike optimale filoppsett. Å forstå disse målene hjelper deg å konfigurere drifts- og vedlikeholdsjobber på riktig måte.

Veiledning for SQL-analyseendepunkt og Fabric Data Warehouse

For optimal ytelse med SQL-analyseendepunktet og Warehouse, bruk følgende innstillinger:

Målfilstørrelse: Omtrent 400 MB per fil
Radgruppestørrelse: Omtrent 2 millioner rader per radgruppe
V-Order: Forbedrer leseytelsen med 10%

Et lager bruker disse kriteriene for å finne kandidater til kompaktering:

Overhead for tabellfilene er mer enn 10%
Tabelllogisk slettede rader er mer enn 10%
Bordstørrelsen er større enn 1 024 rader

Under komprimeringsutførelsen velger prosessen kandidater basert på disse kriteriene:

Enhver fil er mindre enn 25% av ideell størrelse (basert på radantall)
Enhver fil har mer enn 20% slettede rader

Spark

Spark er robust når man leser ulike filstørrelser. For optimal ytelse:

Målfilstørrelse: 128 MB til 1 GB avhengig av tabellstørrelse
Radgruppestørrelse: 1 million til 2 millioner rader per radgruppe
V-Order: Ikke nødvendig for Spark-leseytelse (kan legge til 15-33% skriveoverhead)

Spark-lesinger drar nytte av adaptiv målfilstørrelse, som automatisk justeres basert på tabellstørrelse:

Tabeller under 10 GB: 128 MB mål
Tabeller over 10 TB: Opptil 1 GB mål

Power BI Direct Lake

For optimal ytelse i Direct Lake:

Målradgruppestørrelse: 8 millioner eller flere rader per radgruppe for best ytelse
V-Order: Kritisk for 40-60% forbedring i cold-cache-spørringer
Filantall: Minimer antall filer for å redusere transkodings-overhead
Konsistente filstørrelser: Viktig for forutsigbar spørringsytelse

Direct Lake-semantiske modeller presterer best når:

Kolonnedataene er V-ordnet for VertiPaq-kompatibel komprimering
Radgrupper er store nok for effektiv ordboksammenslåing
Delesjonsvektorer minimeres gjennom regelmessig komprimering

For mer informasjon, se Forstå Direct Lake-spørringsytelse.

Mirroring

Speiling gjør automatisk størrelsen på filer basert på tabellvolum:

Bordstørrelse	Rader per radgruppe	Rader per fil
Liten (opptil 10 GB)	2 millioner	10 millioner
Medium (10 GB til 2,56 TB)	4 millioner	60 millioner
Stor (over 2,56 TB)	8 millioner	80 millioner

Skrivemønstre og konfigurasjoner

Spark-skrivemønstre

Spark-skrivinger bruker følgende standardkonfigurasjoner:

Konfigurasjon	Standardverdi	Beskrivelse
`spark.microsoft.delta.optimizeWrite.fileSize`	128 MB	Målfilstørrelse for optimaliserte skrivinger
`spark.databricks.delta.optimizeWrite.enabled`	Varierer etter profil	Muliggjør automatisk filkoalescing
`spark.databricks.delta.autoCompact.enabled`	Deaktivert	Muliggjør komprimering etter skriving
`spark.sql.files.maxRecordsPerFile`	Ubegrenset	Maksimale poster per fil

For å konfigurere Spark-skriving for nedstrøms SQL-forbruk:

# 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 mer informasjon om ressursprofiler og deres standardinnstillinger, se Konfigurer ressursprofilkonfigurasjoner.

Lagerskrivemønstre

Warehouse optimaliserer automatisk dataoppsettet under skriving:

V-Order er aktivert som standard for leseoptimalisering.
Automatisk komprimering kjører som en bakgrunnsprosess.
Kontrollpunktstyring håndteres automatisk.

Lageret produserer filer optimalisert for SQL-forbruk uten manuell inngripen. Tabeller skrevet av Warehouse er iboende optimalisert for både SQL-analyseendepunkt og Warehouse-lesninger.

Bordvedlikeholdsoperasjoner

OPTIMIZE-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)

Viktig!

Kommandoen OPTIMIZE er en Spark SQL-kommando. Du må kjøre det i Spark-miljøer som notatbøker, Spark-jobbdefinisjoner eller Lakehouse Maintenance-grensesnittet. SQL analytics-endepunktet og Warehouse SQL-spørringseditoren støtter ikke denne kommandoen.

For mer informasjon, se tabellkomprimering.

Automatisk komprimering

Autokomprimering evaluerer automatisk partisjonshelsen etter hver skriveoperasjon og utløser synkron optimalisering når filfragmentering oppdages:

# 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')
""")

Bruk automatisk komprimering for inntakspipelines med hyppige små skrivinger (streaming eller mikrobatch) for å unngå manuell planlegging og holde filer komprimert automatisk.

Automatisk komprimering og optimalisering av skriving gir vanligvis best resultater når de brukes sammen. Optimalisering av skriving reduserer antall små filer som skrives, og automatisk komprimering håndterer den gjenværende fragmenteringen.

For mer informasjon, se Automatisk komprimering.

Optimaliser skriving

Optimalisering av skriving reduserer overhead for små filer ved å utføre forhåndskomprimering, som genererer færre, 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')
""")

Optimalisering av skriving er fordelaktig for:

Partisjonerte tabeller
Bord med hyppige små innsatser
Operasjoner som berører mange filer (MERGE, UPDATE, DELETE)

Forhåndsskriving av komprimering (optimalisering av skriving) er generelt rimeligere enn etterskriving (optimalisering). For mer informasjon, se Optimaliser skriv.

VAKUUM-kommando

Kommandoen VACUUM fjerner gamle filer som en Delta-tabelllogg ikke lenger 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

Standard oppbevaringsperiode er sju dager. Å sette kortere lagringstider påvirker Deltas tidsreisemuligheter og kan skape problemer med samtidige lesere eller forfattere.

For mer informasjon, se vedlikehold av Lakehouse-tabellen.

V-ordensoptimalisering

V-Order er en skrivetidsoptimalisering som anvender VertiPaq-kompatibel sortering, koding og komprimering på Parquet-filer:

Power BI Direct Lake: 40-60% forbedring i cold-cache-spørringer
SQL-analyseendepunkt og lager: Omtrent 10% forbedring i leseytelse
Spark: Ingen iboende lesefordel; 15-33% tregere skrivinger

Når man skal aktivere V-Order

V-Order gir størst fordel for:

Gulllagstabeller som betjener Power BI Direct Lake
Tabeller som ofte spørres gjennom SQL-analyse-endepunktet
Lesetunge arbeidsbelastninger hvor skriveytelsen er mindre kritisk

Når bør man unngå V-ordre

Vurder å deaktivere V-Order for:

Bronselagstabeller fokuserte på inntakshastighet
Spark-til-Spark-pipelines hvor SQL og Power BI ikke bruker dataene
Skriveintensive arbeidsbelastninger hvor dataforsinkelse er kritisk

Konfigurer V-Order

V-Order er deaktivert som standard i nye Fabric-arbeidsområder. Slik aktiverer du:

# 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 anvende V-Order basert på Direct Lake-forbruk, bør du vurdere å automatisere V-Order-aktivering for tabeller brukt i Direct Lake-semantiske modeller. Tabeller som ikke brukes av Direct Lake kan forbli uten V-Order for bedre skriveytelse.

Hvis du vil ha mer informasjon, kan du se Tabelloptimalisering for Delta Lake og V-order.

Væskeklynging og Z-orden

Flytende klynger

Liquid Clustering er den anbefalte tilnærmingen for dataorganisering. I motsetning til tradisjonell partisjonering, er væskeklynging:

Tilpasser seg endrede spørringsmønstre
Krever OPTIMIZE å anvende klynging
Gir bedre filhopp for filtrerte spørringer

Aktiver væskeklynging ved bordopprettelse:

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

Z-orden

Z-Order samler relaterte data i de samme filene, så du får bedre spørringsytelse på filterpredikater.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Bruk Z-Order når:

Tabellen din er partisjonert, fordi Liquid Clustering ikke fungerer med partisjonerte tabeller.
Spørringene dine filtreres ofte på to eller flere kolonner samtidig.
Predikatene dine er selektive nok til å dra nytte av filhopping.

Anbefalinger for medaljongarkitektur

Medaljongarkitekturen (bronse-, sølv- og gulllag) gir et rammeverk for å optimalisere strategier for bordvedlikehold basert på formålet med hvert lag.

Bronselag (landingssone)

Bronsetabeller fokuserer på skriveytelse og lav-latens inntak:

Optimaliseringsprioritet: Inntakshastighet fremfor leseytelse
Partisjonering: Akseptabelt, men frarådes for nye implementasjoner
Små filer: Akseptabelt siden fokuset er på inntakshastighet
V-Order: Anbefales ikke (legger til skriveoverhead)
Autokomprimering: Aktiver for å redusere små filer, men kan ofres for inntastingshastighet
Slettingsvektorer: Aktiver tabeller med sammenslåingsmønstre

Bronsetabeller skal ikke leveres direkte til SQL-analyseendepunkter eller Power BI Direct Lake-brukere.

Sølvlag (kuratert sone)

Sølvtabeller balanserer skrive- og leseytelse:

Optimaliseringsprioritet: Balanse mellom inntasting og spørringsytelse
Filstørrelser: Moderat (128-256 MB) for å støtte både skrive- og leseoperasjoner
V-Order: Valgfritt; aktiver hvis SQL-analyse-endepunkt eller Power BI-forbruk er betydelig
Liquid Clustering eller Z-orden: Anbefales for å forbedre spørringsytelsen
Autokomprimering og optimaliseringsskriving: Aktiver basert på krav nedstrøms
Slettingsvektorer: Aktiver tabeller med hyppige oppdateringer
Planlagt OPTIMALISERING: Kjør aggressivt for å opprettholde filoppsettet

Gulllag (serveringssone)

Gulltabeller prioriterer leseytelse for sluttbrukerens forbruk:

Optimaliseringsprioritet: Leseytelse for analyse
Filstørrelser: Stor (400 MB til 1 GB) for optimal SQL- og Power BI-ytelse
V-Order: Påkrevd for Power BI Direct Lake; gunstig for SQL-analyse-endepunkt
Væskeklynging: Nødvendig for optimal filhopping
Optimaliser-skriving: Kreves for konsistente filstørrelser
Planlagt OPTIMALISERING: Kjør aggressivt for å opprettholde optimal layout

Optimaliser gulltabeller forskjellig basert på hovedforbruksmotoren:

Forbruksmotor	V-ordre	Målfilstørrelse	Radgruppestørrelse
Endepunkt for SQL-analyse	Ja	400 MB	2 millioner rader
Power BI Direct Lake	Ja	400 MB til 1 GB	8+ millioner rader
Spark	Valgfritt	128 MB til 1 GB	1–2 millioner rader

Flere tabellkopier

Det er akseptabelt å opprettholde flere kopier av tabeller optimalisert for ulike forbruksmønstre:

Et sølvbord optimalisert for Spark-prosessering
En gulltabell optimalisert for SQL-analyseendepunkt og Power BI Direct Lake
Datapipelines som transformerer og plasserer riktig struktur på hvert lag

Lagring er rimelig sammenlignet med beregning. Å optimalisere tabeller for deres forbruksmønstre gir en bedre brukeropplevelse enn å prøve å betjene alle forbrukere fra ett enkelt tabelloppsett.

Identifiser tabellhelse

Før du optimaliserer tabeller, vurder nåværende tabellhelse for å forstå optimaliseringsbehov.

Inspiser Parquet-filer direkte

Du kan bla gjennom tabellmappen i OneLake for å inspisere størrelsene på individuelle Parquet-filer. Sunne tabeller har jevnt fordelte filstørrelser. Se etter:

Konsistente filstørrelser: Filene bør være omtrent like store (innenfor 2x av hverandre).
Ingen ekstremt små filer: Filer under 25 MB indikerer fragmentering.
Ingen ekstremt store filer: Filer over 2 GB kan redusere parallellisme.

Ujevn filstørrelsesfordeling indikerer ofte manglende komprimering eller inkonsistente skrivemønstre på tvers av ulike jobber.

OPTIMIZE DRY RUN i Spark SQL

Bruk DRY RUN alternativet for å forhåndsvise hvilke filer som er kvalifisert for optimalisering uten å utføre komprimeringen:

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

Kommandoen returnerer en liste over filer som ville blitt omskrevet under optimaliseringen. Bruk dette til å:

Vurder omfanget av optimaliseringen før du kjører det.
Forstå filfragmentering uten å endre tabellen.
Anslå optimaliseringstid basert på antall berørte filer.

Filstørrelsesfordeling

Bruk følgende tilnærming for å analysere filstørrelser og distribusjon:

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")

Distribusjonen kan være skjev, ettersom filer nær toppen av tabellen eller fra en spesifikk partisjon kanskje ikke er optimalisert.

Du kan vurdere fordelingen ved å kjøre en spørring som grupperer etter partisjonerings- eller klyngenøklene i tabellen.

Bestem optimaliseringsbehov

Basert på forbruksmotoren, sammenlign faktiske filstørrelser med målstørrelser:

Motor	Målfilstørrelse	Hvis filene er mindre	Hvis filene er større
Endepunkt for SQL-analyse	400 MB	Kjøre `OPTIMIZE`	Filer er akseptable
Power BI Direct Lake	400 MB til 1 GB	Kjøre `OPTIMIZE VORDER`	Filer er akseptable
Spark	128 MB til 1 GB	Aktiver automatisk komprimering	Filer er akseptable

Tabellhistorikk og transaksjonslogg

Gå gjennom tabellhistorikk for å forstå skrivemønstre og vedlikeholdsfrekvens:

-- View table history
DESCRIBE HISTORY schema_name.table_name

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

Beste praksis for konfigurasjon

Bruk tabellegenskaper over sesjonskonfigurasjoner

Tabellegenskaper vedvarer på tvers av økter og sikrer konsistent oppførsel på tvers av alle jobber 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'
    )
""")

Sesjonsnivå-konfigurasjoner gjelder kun for den nåværende Spark-sesjonen og kan føre til inkonsistente skrivinger hvis ulike sesjoner bruker forskjellige konfigurasjoner.

Aktiver adaptiv målfilstørrelse

Adaptiv målfilstørrelse justerer automatisk filstørrelsesmål basert på tabellstørrelse:

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

Denne funksjonen:

Starter med mindre filer (128 MB) for små tabeller
Skalerer opptil 1 GB for bord over 10 TB
Revurderer automatisk under OPTIMIZE drift

Aktiver filnivå-komprimeringsmål

Unngå omskriving av tidligere komprimerte filer når målstørrelser endres:

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

Oppsummering av anbefalinger

Lag	Autokomprimering	Optimaliser-skriv	V-ordre	Flytende klynger	Planlagt OPTIMIZE
Bronse	Aktiver (valgfritt)	Aktiver	Nei	Nei	Valgfritt
Sølv	Aktiver	Aktiver	Valgfritt	Ja	Aggressiv
Gull	Aktiver	Aktiver	Ja	Ja	Aggressiv

For spesifikke scenarioer, bruk følgende anbefalinger:

Spark-to-Spark: Fokuser på optimalisering av filstørrelse; V-Order valgfritt.
Spark-to-SQL: Aktiver optimaliseringsskriving og automatisk komprimering; sikt mot 400 MB-filer med 2 millioner radgrupper.
Strømmeinntak: Aktiver automatisk komprimering; planlegg ekstra OPTIMIZE jobber for SQL-brukere.
Power BI Direct Lake: Aktiver V-orden; mål 8+ millioner radgrupper; løp.OPTIMIZE VORDER

Tilbakemeldinger

Var denne siden nyttig?

Last updated on 2026-02-13