Vedligeholdelse og optimering af tværarbejdstavler i Microsoft Fabric

Delta-tabeller i Microsoft Fabric kan levere Spark, SQL analytics endpoint, Power BI Direct Lake, Warehouse og andre Fabric-oplevelser fra data lagret i OneLake. Optimal ydeevne på tværs af arbejdsbelastninger afhænger af to faktorer:

• Den arbejdsbyrde, der skaber og vedligeholder bordet.
• Motorerne, der forbruger bordet.

Lakehouse-tabeller administreres ofte af Spark, Fabric pipeline Copy activity eller Dataflow Gen2. Spark er den mest almindelige forfatter og tilbyder det bredeste layout og vedligeholdelseskontroller. Lager- og database-spejling styrer deres fysiske layout automatisk. Spejlede kataloger bevarer layoutet, der administreres i kildesystemet. Forbrugerkravene er generelt kompatible, men Power BI Direct Lake har yderligere lagringskrav for optimal ydeevne.

Brug én delt tabel, når dens krav er kompatible. For undtagelser, der retfærdiggør en anden tabel, se Hvornår for at oprette en anden tabel.

Forstå ejerskab af layoutet

Start med at identificere, hvilken arbejdsbyrde der ejer det fysiske bordlayout. Kontrollerne i den følgende tabel er de vigtigste kontroller, der er relevante for tværarbejdstabellayout og vedligeholdelse, ikke en udtømmende liste over hver lokomotivs kapaciteter.

Tværarbejdsbelastningsvejledning

Følgende tabel opsummerer den anbefalede tilgang fra producent og forbruger.

Optimer Lakehouse-tabeller

Lakehouse Delta-tabeller kræver en eksplicit vedligeholdelsesstrategi, uanset om Spark, Pipeline Copy activity eller Dataflow Gen2 skriver dem. Spark er det primære eksempel i denne sektion, fordi det giver den bredeste layout- og vedligeholdelseskontrol i Fabric.

Brug Spark runtime-standarderne

Når Spark skriver tabellen, brug Fabric Spark runtime 2.0 eller nyere standardindstillinger:

• Hav adaptiv målfilstørrelse aktiveret. Den vælger automatisk et mål for hver tabel fra 128 MB til 1 GB.
• Hold filniveau-kompaktionsmål aktiveret for at undgå at omskrive filer, der opfyldte et tidligere adaptivt mål.
• Hold sletningsvektorer aktiveret .
• Pålæg ikke et vilkårligt maksimalt antal rækker pr. fil. Rækkebredden varierer, så en rækkebegrænsning kan skabe for små filer til smalle tabeller.

I Fabric Spark runtime 1.3 er adaptiv målfilstørrelse, filniveau-komprimeringsmål og sletningsvektorer tilgængelige som opt-in indstillinger.

Når Pipeline Copy activity eller Dataflow Gen2 skriver tabellen, skal det resulterende fillayout og planlægges vedligeholdelse separat. Antag ikke, at disse forfattere anvender Spark runtime-standarder.

• Fabric-pipelines kan orkestrere en vedligeholdelsesaktivitet ved Lakehouse efter skrivning.

Forebyg og komprimer små filer

For Spark-skrevne tabeller foretrækker du automatisk komprimering. Denne funktion evaluerer tabelfragmentering efter skrivning og kører kompaktering kun, når det er nødvendigt. Det eliminerer behovet for en separat tabel-sundhedskontrol før vedligeholdelseskørslen.

Brug følgende vejledning for undtagelser og supplerende funktioner:

OPTIMIZE komprimerer filer og renser automatisk en fils sletningsvektorer, når mere end 5% af dens poster refereres til med sletningsvektorer. REORG TABLE ... APPLY (PURGE) Brug kun, når du fysisk skal rense journaler under denne grænse eller opfylde et specifikt overholdelseskrav.

Kør VACUUM på en separat tidsplan for at fjerne urefererede filer efter opbevaringsperioden. VACUUM Genererer lagerplads, men forbedrer ikke den aktive fillayout.

Organiser data til filspring

Brug væskeklyngedannelse, når tilbagevendende filter- eller behandlingsmønstre drager fordel af forbedret filspring. Flydende klyngetabeller kræver OPTIMIZEautomatisk komprimering for at organisere nyskrevne data.

Undgå at partitionere som standard. Brug det, når et specifikt krav retfærdiggør de operationelle afvejninger, såsom at isolere samtidige skrivere, der opdaterer, sletter eller sammenlægger data på tværs af adskilte partitioner. For mere information, se Hvornår man skal bruge partitionering.

For eksisterende opdelte tabeller betragtes Z-orden , når selektive prædikater ofte filtreres på de samme kolonner inden for en partition.

Optimer lagerstyrede tabeller

Fabric data warehouse håndterer den fysiske Delta-tabelopsætning uanset indlæsningsmetoden.

Brug de strategiske kontroller, som Warehouse eksponerer, til at finjustere datalayoutet:

• Anvend dataklyngning på store tabeller, når forespørgsler gentagne gange bruger selektive prædikater på de samme kolonner.
• Hold V-Order aktiveret til læseorienterede og blandede arbejdsbyrder. V-Order er aktiveret som standard.
• Overvej at deaktivere V-Order for skriveintensive lagerarbejdsbyrder.

For fuldstændig vejledning om lageret, se Performance-retningslinjer i Fabric data warehouse.

Optimer spejlede data

Din evne til at forbedre det fysiske layout afhænger af, om Fabric replikerer dataene eller refererer til kildefiler:

• Databasespejling: Fabric replikerer kildedata i Delta-tabeller i OneLake og administrerer V-Ordered fillayout og vedligeholdelse. Du kan ikke direkte konfigurere målfilstørrelse, oprydning af deletion-vektorer, væskeklyngedannelse, partitionering eller V-Order på den spejlede destination.
• Spejlede kataloger: Fabric synkroniserer metadata og bruger OneLake-genveje til at referere kildedata på stedet. Fabric omskriver eller vedligeholder ikke disse filer. Forbedre det fysiske layout og oprydning i kildesystemet, når dets understøttede funktioner tillader det. Disse ændringer er synlige gennem genvejene uden at oprette en ny kopi i Fabric.

For database-spejlede data:

• Brug selektive prædikater og undgå unødvendige kolonner i Spark og SQL-forespørgsler.
• Design Power BI semantiske modeller og DAX-målinger for effektivt Direct Lake-forbrug.

For spejlede kataloger:

• Brug kildeplatformens understøttede tabelvedligeholdelses- og layoutfunktioner.
• Evaluer kildefil- og rækkegruppefordelingen for de Fabric-forbrugere, der forespørger genvejene.
• For Direct Lake bør du vurdere at skabe et ekstra dimensionelt modelleret, V-ordnet serveringslag, når kildelayoutet ikke kan opfylde ydelseskravene.

For spejling af koncepter, typer og understøttede kilder, se Hvad er spejling i Fabric? og Hvordan metadata-spejling fungerer.

Anvend forbrugerspecifik optimering

Spark og SQL analytics-endpointet fungerer godt på det samme adaptive lakehouse-layout. Brug adaptiv målfilstørrelse, undgå for små filer, og anvend flydende klyngedannelse, når målte prædikater drager fordel af forbedret filspring. Aktiver ikke V-Order udelukkende for Spark eller SQL analytics endpoints ydeevne. For engine-specifikke detaljer, se SQL analytics endpoint performance considerations.

Power BI Direct Lake

Direct Lake bruger de samme underliggende Delta-tabeller, men tilføjer anbefalinger vedrørende transkodning og inkrementel indramning:

• Fil- og rækkegruppelayout: Undgå små rækkegrupper og ujævn rækkegruppefordeling, det skaber flere VertiPaq-kolonnesegmenter og øger transkodningsoverhead.
• V-Order: Følg den producentspecifikke anbefaling i vejledningen for arbejdsbyrde. For Spark-skrevne tabeller, der primært forbruges gennem Direct Lake, aktiver V-Order eller brug readHeavyForPBI ressourceprofilen.
• Opdateringsmønstre: Foretræk opdateringsmønstre, der er append-venlige , hvor det er muligt, for at bevare eksisterende Parquet-filer og understøtte inkrementel indramning.

For Spark-skrevne tabeller fastsættes det maksimale antal rækker pr. rækkegruppe, spark.sql.parquet.native.writer.maxRowGroupRowCount når den native eksekveringsmotor skriver Parquet-filerne. Standardværdien er 0, hvilket ikke pålægger et maksimum. Hvis analysen viser, at rækkegruppestørrelser påvirker Direct Lakes ydeevne, skal en testet grænse blive sat, før tabellen skrives eller omskrives. Eksempel:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Sæt ikke grænsen kun for at nå et bestemt antal rækker. Rækkebredde, komprimering, filfordeling og kapacitetsparallelisme påvirker også ydeevnen. Brug Delta Analyzer til at evaluere det resulterende layout.

For detaljeret vejledning om indramning, transkodning, rækkegrupper, opdateringsmønstre og Delta Analyzer, se Forstå Direct Lake-forespørgselsydelse.

Anvend vejledningen på medaljonlagene

Bronze, sølv og guld beskriver dataens formål og forfinelse. De afgør ikke, om layoutet er brugerstyret eller systemstyret, og de kræver ikke separate kopier for hver forbruger.

Løs layout- og vedligeholdelsesproblemer

Brug producentbevidst afhjælpning. Anvend Spark-vedligeholdelseskommandoer på lakehouse-tabeller, når destinationstilstanden understøtter disse operationer. Behandl signalerne som indikatorer frem for universelle tærskler, og valider dem mod tabellens skrivemønster og forbrugerpræstation.

For spejlede data, følg producent-specifik udrensning i Optimer spejlede data. Databasespejling er systemstyret; For spejlede kataloger anvendes understøttet vedligeholdelse i kildeplatformen.

For lakehouse-borde omfatter Spark-understøttede inspektionsmuligheder:

• Kør DESCRIBE DETAIL for at inspicere filantal, total størrelse og den vurderede delta.targetFileSize.adaptive egenskab.
• Kør DESCRIBE HISTORY for at gennemgå skrivemønstre og vedligeholdelseshistorik.
• Brug Delta Analyzer , når du har brug for detaljeret Direct Lake rækkegruppe- og opdateringsmønsteranalyse.

Inspicer gennemsnitlig filstørrelse

Brug DESCRIBE DETAIL til at beregne den gennemsnitlige filstørrelse som en indledende indikator for tabellayoutet:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Et gennemsnit kan skjule skævhed mellem partitioner eller nylige og tidligere komprimerede filer. Hvis gennemsnittet indikerer et muligt layoutproblem, inspiceres de enkelte Parquet-filer eller brug Delta Analyzer til at evaluere fordelingen, før vedligeholdelsesindstillingerne ændres.

Hvornår skal der oprettes en ny tabel

Opret ikke endnu en fysisk tabel udelukkende fordi flere Fabric-motorer forbruger dataene.

Opret en anden tabel, når den har et selvstændigt formål, såsom:

• En transformation eller aggregation, der ændrer datakornet eller forretningsbetydningen.
• Forskellige krav til sikkerhed, opbevaring eller datakvalitet.
• Et krav om latenstid eller opdatering, som den delte tabel ikke kan opfylde.
• Et forbrugerspecifikt layout, hvis målte fordel opvejer dets lager-, behandlings-, oprindelses- og styringsomkostninger.

Relateret indhold

• Juster størrelsen på Delta-tabellens datafiler
• Kompaktering af Delta-tabeller
• Sletningsvektorer for Delta-tabeller
• Anvend væskeklyngedannelse på Delta-tabeller
• Opdeling af delta-tabeller
• Optimer Delta Lake-tabeller med V-Order
• Overvejelser i forbindelse med ydeevnen for SQL-analyseslutpunkter
• Om ydeevnen af Direct Lake-forespørgsler
• Performance-retningslinjer i Fabric data warehouse
• Dataklyngedannelse i Fabric data warehouse
• Hvad er Spejling i Fabric?