Vedlikehold og optimalisering av tverrarbeidstabeller i Microsoft Fabric

Delta-tabeller i Microsoft Fabric kan betjene Spark, SQL-analyse-endpoint, Power BI Direct Lake, Warehouse og andre Fabric-opplevelser fra data lagret i OneLake. Optimal ytelse på tvers av arbeidsbelastninger avhenger av to faktorer:

• Arbeidsmengden som skaper og vedlikeholder bordet.
• Motorene som konsumerer bordet.

Lakehouse-tabeller administreres vanligvis av Spark, Fabric pipeline Copy activity, eller Dataflow Gen2. Spark er den mest vanlige forfatteren og tilbyr det bredeste oppsettet og vedlikeholdskontrollene. Lager- og databasespeiling håndterer sine fysiske oppsett automatisk. Speilede kataloger beholder layouten som administreres i kildesystemet. Forbrukerkravene er generelt kompatible, men Power BI Direct Lake har ekstra lagringskrav for optimal ytelse.

Bruk én delt tabell når kravene er kompatible. For unntakene som rettferdiggjør en annen tabell, se Når du skal opprette en annen tabell.

Forstå eierskap til anlegget

Start med å identifisere hvilken arbeidsbelastning som eier det fysiske bordoppsettet. Kontrollene i tabellen nedenfor er de viktigste kontrollene som er relevante for oppsett og vedlikehold av arbeidsmengdetabeller, ikke en uttømmende liste over hver motors kapasiteter.

Veiledning på tvers av arbeidsbelastninger

Tabellen nedenfor oppsummerer den anbefalte tilnærmingen fra produsent og forbruker.

Optimaliser Lakehouse-tabeller

Lakehouse Delta-tabeller krever en eksplisitt vedlikeholdsstrategi uavhengig av om Spark, Pipeline Copy activity eller Dataflow Gen2 skriver dem. Spark er hovedeksempelet i denne seksjonen fordi det gir de bredeste layout- og vedlikeholdskontrollene i Fabric.

Bruk Spark runtime-standardene

Når Spark skriver tabellen, bruk Fabric Spark runtime 2.0 eller nyere standardinnstillinger:

• Hold adaptiv målfilstørrelse aktivert. Den velger automatisk et mål for hver tabell fra 128 MB til 1 GB.
• Hold filnivå-komprimeringsmål aktivert for å unngå å omskrive filer som oppnådde et tidligere adaptivt mål.
• Hold slettingsvektorer aktivert .
• Ikke pålegg et vilkårlig maksimalt antall rader per fil. Radbredden varierer, så en radgrense kan skape for små filer for smale tabeller.

I Fabric Spark runtime 1.3 er adaptiv filstørrelse, filnivå-komprimeringsmål og slettingsvektorer tilgjengelig som opt-in-innstillinger.

Når Pipeline Copy activity eller Dataflow Gen2 skriver tabellen, inspiser det resulterende filoppsettet og planlegg vedlikehold separat. Ikke anta at disse forfatterne bruker Spark runtime-standardinnstillinger.

• Fabric-rørledninger kan orkestrere en vedlikeholdsaktivitet ved Lakehouse etter skriving.

Forebygg og komprimer små filer

For tabeller skrevet av Spark, foretrekk automatisk komprimering. Denne funksjonen evaluerer tabellfragmentering etter skriving og kjører komprimering kun når det er nødvendig. Det eliminerer behovet for en separat tabellhelsesjekk før vedlikeholdskjøringer.

Bruk følgende veiledning for unntak og komplementære funksjoner:

OPTIMIZE komprimerer filer og fjerner automatisk en fils slettevektorer når mer enn 5% av postene refereres til med slettingsvektorer. Bruk REORG TABLE ... APPLY (PURGE) kun når du fysisk må tømme journaler under denne terskelen eller oppfylle et spesifikt krav til etterlevelse.

Kjør VACUUM på en separat tidsplan for å fjerne urefererte filer etter oppbevaringsperioden. VACUUM Tar tilbake lagring, men forbedrer ikke det aktive filoppsettet.

Organiser data for filhopp

Bruk væskeklynging når gjentakende filter- eller prosesseringsmønstre drar nytte av forbedret filhopp. Flytende klyngede tabeller krever OPTIMIZEautomatisk komprimering for å organisere nyskrevne data.

Unngå partisjonering som standard. Bruk det når et spesifikt krav rettferdiggjør de operative avveiningene, som å isolere samtidige skrivere som oppdaterer, sletter eller slår sammen data på tvers av disjunkte partisjoner. For mer informasjon, se Når man skal bruke partisjonering.

For eksisterende partisjonerte tabeller, vurder Z-orden når selektive predikater vanligvis filtreres på de samme kolonnene innenfor en partisjon.

Optimaliser lagerstyrte tabeller

Fabric datalager håndterer den fysiske Delta-tabelloppsettet uavhengig av inntastingsmetode.

Bruk de strategiske kontrollene som Warehouse eksponerer for å justere dataoppsettet:

• Bruk dataklynging på store tabeller når spørringer gjentatte ganger bruker selektive predikater på de samme kolonnene.
• Hold V-Order aktivert for leseorienterte og blandede arbeidsbelastninger. V-Order er aktivert som standard.
• Vurder å deaktivere V-Order for skriveintensive lagerarbeidsbelastninger.

For fullstendig veiledning om lageret, se Ytelsesretningslinjer i Fabric datalager.

Optimaliser speilede data

Din evne til å forbedre det fysiske oppsettet avhenger av om Fabric replikerer dataene eller refererer til kildefiler:

• Databasespeiling: Fabric replikerer kildedata til Delta-tabeller i OneLake og administrerer V-Ordered filoppsett og vedlikehold. Du kan ikke direkte konfigurere målfilstørrelse, opprydding av slettingsvektorer, væskeklynging, partisjonering eller V-Order på den speilede destinasjonen.
• Speilede kataloger: Fabric synkroniserer metadata og bruker OneLake-snarveier for å referere til kildedata på stedet. Fabric skriver ikke om eller vedlikeholder disse filene. Forbedre det fysiske oppsettet og oppryddingen i kildesystemet når de støttede funksjonene tillater det. Disse endringene er synlige gjennom snarveiene uten å lage en ny kopi i Fabric.

For databasespeilede data:

• Bruk selektive predikater og unngå unødvendige kolonner i Spark og SQL-spørringer.
• Design Power BI semantiske modeller og DAX-målinger for effektivt Direct Lake-forbruk.

For speilvendte kataloger:

• Bruk kildeplattformens støttede funksjoner for bordvedlikehold og layout.
• Evaluer kildefilen og radgruppefordelingen for Fabric-brukerne som spør snarveiene.
• For Direct Lake, vurder å lage et ekstra dimensjonalt modellert, V-ordnet serveringslag når kildeoppsettet ikke kan oppfylle ytelseskravene.

For speiling av konsepter, typer og støttede kilder, se Hva er speiling i Fabric? og Hvordan metadataspeiling fungerer.

Bruk forbrukerspesifikk optimalisering

Spark og SQL analytics-endepunktet fungerer godt på samme adaptive lakehouse-oppsett. Bruk adaptiv målfilstørrelse, unngå for små filer, og bruk flytende klynging når målte predikater drar nytte av bedre filhopp. Ikke aktiver V-Order kun for Spark eller SQL analytics endpoint-ytelse. For motorspesifikke detaljer, se vurderinger for ytelse på endepunktene i SQL-analyse.

Power BI Direct Lake

Direct Lake bruker de samme underliggende Delta-tabellene, men legger til anbefalinger knyttet til transkoding og inkrementell innramming:

• Fil- og radgruppeoppsett: Unngå små radgrupper og ujevn rekkefordeling, dette skaper flere VertiPaq-kolonnesegmenter og øker transkodingsoverhead.
• V-Rekkefølge: Følg den produsentspesifikke anbefalingen i veiledningen for tverrarbeidsmengde. For Spark-skrevne tabeller som hovedsakelig brukes gjennom Direct Lake, aktiver V-Order eller bruk ressursprofilenreadHeavyForPBI.
• Oppdateringsmønstre: Foretrekk append-vennlige oppdateringsmønstre der det er mulig for å bevare eksisterende Parquet-filer og støtte inkrementell innramming.

For Spark-skrevne tabeller, spark.sql.parquet.native.writer.maxRowGroupRowCount setter det maksimale antall rader per radgruppe når den native utførelsesmotoren skriver Parquet-filene. Standardverdien er 0, som ikke pålegger et maksimum. Hvis analysen viser at radgruppestørrelser påvirker Direct Lake-ytelsen, sett en testet grense før du skriver eller skriver om tabellen. Eksempel:

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

Ikke sett grensen kun for å nå et bestemt radantall. Radbredde, komprimering, fildistribusjon og kapasitetsparallellitet påvirker også ytelsen. Bruk Delta Analyzer for å evaluere det resulterende oppsettet.

For detaljert veiledning om innramming, transkoding, radgrupper, oppdateringsmønstre og Delta Analyzer, se Forstå Direct Lake-spørringsytelse.

Bruk veiledningen på medaljonglagene

Bronse, sølv og gull beskriver dataens formål og raffinering. De avgjør ikke om oppsettet er brukerstyrt eller systemstyrt, og de krever ikke separate kopier for hver forbruker.

Løse problemer med oppsett og vedlikehold

Bruk produsentbevisst utbedring. Bruk Spark-vedlikeholdskommandoer på lakehouse-tabeller når destinasjonsmodusen støtter disse operasjonene. Behandle signalene som indikatorer i stedet for universelle terskler, og valider dem mot tabellens skrivemønster og forbrukerytelse.

For speilede data, følg produsentens spesifikke utbedring i Optimaliser speilede data. Databasespeiling er systemstyrt; For speilede kataloger, bruk støttet vedlikehold i kildeplattformen.

For lakehouse-bord inkluderer Spark-støttede inspeksjonsalternativer:

• Kjør DESCRIBE DETAIL for å inspisere antall filer, total størrelse og den evaluerte delta.targetFileSize.adaptive egenskapen.
• Kjør DESCRIBE HISTORY for å gjennomgå skrivemønstre og vedlikeholdshistorikk.
• Bruk Delta Analyzer når du trenger detaljert Direct Lake radgruppe- og oppdateringsmønsteranalyse.

Inspekter gjennomsnittlig filstørrelse

Bruk DESCRIBE DETAIL for å beregne gjennomsnittlig filstørrelse som en initial indikator på tabelloppsettet:

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 gjennomsnitt kan skjule skjevhet mellom partisjoner eller nylige og tidligere komprimerte filer. Hvis gjennomsnittet indikerer et mulig layoutproblem, inspiser du de individuelle Parquet-filene eller bruk Delta Analyzer for å evaluere fordelingen før du endrer vedlikeholdsinnstillingene.

Når man skal lage en ny tabell

Ikke lag en ny fysisk tabell bare fordi flere Fabric-motorer bruker dataene.

Opprett en annen tabell når den har et selvstendig formål, for eksempel:

• En transformasjon eller aggregering som endrer dataens korn eller forretningsbetydning.
• Ulike krav til sikkerhet, oppbevaring eller datakvalitet.
• Et forsinkelses- eller oppdateringskrav som den delte tabellen ikke kan oppfylle.
• Et forbrukerspesifikt oppsett hvor den målte fordelen overstiger kostnadene for lagring, prosessering, opprinnelse og styring.

Relatert innhold

• Juster størrelsen på Delta-tabellens datafiler
• Komprimering av deltatabeller
• Slettingsvektorer for delta-tabeller
• Bruk væskeklynging på Delta-tabeller
• Partisjonering for delta-tabeller
• Optimaliser Delta Lake-tabeller med V-Order
• Ytelseshensyn for SQL Analytics-endepunkt
• Understand Direct Lake spørringsytelse
• Ytelsesretningslinjer i Fabric datalager
• Dataklynging i Fabric datalager
• Hva er speiling i stoff?