Underhåll och optimering av arbetsbelastningsöverskridande tabeller i Microsoft Fabric

Delta-tabeller i Microsoft Fabric kan hantera Spark, SQL Analytics endpoint, Power BI Direct Lake, Warehouse och andra Fabric-upplevelser från data lagrade i OneLake. Optimal prestanda mellan arbetsbelastningar beror på två faktorer:

  • Arbetsbördan som skapar och underhåller tabellen.
  • Motorerna som förbrukar bordet.

Lakehouse-tabeller hanteras vanligtvis av Spark, Fabric pipeline Copy activity eller Dataflow Gen2. Spark är den vanligaste skrivaren och erbjuder den bredaste layout- och underhållskontrollen. Datalager och databasspegling hanterar sina fysiska layouter automatiskt. Spegelvända kataloger behåller layouten som hanteras i källkodssystemet. Konsumenternas krav är generellt kompatibla, men Power BI Direct Lake har ytterligare lagringskrav för optimal prestanda.

Använd en delad tabell när dess krav är kompatibla. För undantag som motiverar en annan tabell, se När man skapar en annan tabell.

Förstå layoutägarskap

Börja med att identifiera vilken arbetsbelastning som äger den fysiska tabelllayouten. Kontrollerna i följande tabell är de viktigaste kontrollerna som är relevanta för layouten och underhållet av arbetsbelastningstabeller, inte en uttömmande lista över varje motors kapacitet.

Databutik Skrivmetod eller inmatningsmetod Layout och underhållsägande Nyckelkontroller
Lakehouse Spark Användarstyrd Filstorlek: adaptiv målfilstorlek och filnivåkomprimeringsmål.
Skrivning och underhåll: raderingsvektorer, automatisk kompaktering, optimerad skrivning, OPTIMIZE, och VACUUM.
Dataorganisering: flytande klustring,partitionering, Z-ordning och V-ordning.
Lakehouse Fabric-pipeline kopieringsaktivitet eller Dataflow Gen2 Tjänsten skriver data; ägaren av lakehouse underhåller tabellen Destinationsspecifika skrivinställningar. Utför kompatibelt underhåll separat genom att använda Spark, Lakehouse maintenance eller en pipeline-underhållsaktivitet.
Lager Fabric Data Warehouse, Fabric pipeline Copy activity eller Dataflow Gen2 Lagerhanterad Dataklustring och lagernivåns V-order-inställning.
Speglat objekt Spegeltjänst Det beror på spegeleringstypen Databasspegling använder en systemstyrd V-Ordered Delta-layout utan direkta layoutkontroller. Speglade kataloger behåller källfilslayouten, som du kan optimera i källsystemet när det stöds.

Arbetsbelastningsövergripande vägledning

Följande tabell sammanfattar den rekommenderade metoden från producent och konsument.

Producer Consumer Rekommenderat tillvägagångssätt
Lakehouse: Spark-författare Spark Använd Fabric Spark runtime 2.0 eller senare standardinställningar och aktivera automatisk komprimering. Överväg liquid clustering när uppmätta predikat gynnas av förbättrad filuteslutning.
Lakehouse: Spark-författare SQL-analysslutpunkt Använd samma layout som rekommenderas för Spark. Sätt inte en statisk målfilstorlek, godtycklig radgräns eller V-Order enbart för SQL-analysens endpoint-prestanda.
Lakehouse: Spark-författare Power BI Direct Lake Använd samma layout som rekommenderas för Spark och aktivera dessutom V-Order, eller använd resursprofilenreadHeavyForPBI.
Lakehouse: Fabric pipeline eller Dataflow Gen2-skrivare Spark, SQL analytics-endpoint eller Power BI Direct Lake Övervaka den resulterande filstrukturen och schemalägg underhåll för kompatibla lakehouse separat. Vissa destinationsläge, såsom Dataflow Gen2 inkrementell uppdatering, medför underhållsbegränsningar.
Lager Fabric Data Warehouse eller Spark Använd systemstyrd layout. Fabric Data Warehouse hanterar automatiskt kompaktering och annat underhåll. Använd dataklustring för att förbättra möjligheten att hoppa över filer för arbetslaster med återkommande selektiva predikat.
Lager Power BI Direct Lake Behåll Warehouse V-Order-standardinställningen. Använd dataklustring när det gynnar delade frågemönster.
Spegling Spark, SQL analytics-endpoint eller Power BI Direct Lake Vid databasspegling använder du den systemhanterade V-Ordered Delta-layouten. För speglade kataloger, optimera de underliggande filerna i källsystemet när det stöds. Se Vad är spegling i Fabric?.

Optimera Lakehouse-tabeller

Lakehouse Delta-tabeller kräver en explicit underhållsstrategi oavsett om Spark, Pipeline Copy activity eller Dataflow Gen2 skriver dem. Spark är det främsta exemplet i detta avsnitt eftersom det erbjuder den bredaste layout- och underhållskontrollen i Fabric.

Viktigt!

Tabellunderhåll är avgörande för optimal läs- och skrivprestanda i olika databasmotorer. Även arbetsbelastningar med enbart tillägg som initialt fungerar bra utan underhåll kan ackumulera alltför många små filer, vilket påverkar Spark, SQL-analysslutpunkt, Direct Lake och externa dataläsare. Se Compacting Delta-tabeller för automatiska och manuella kompakteringsmetoder.

Använd Spark runtime-standardinställningar

När Spark skriver tabellen, använd Fabric Spark runtime 2.0 eller senare standardinställningar:

  • Ha adaptiv målfilstorlek aktiverad. Den väljer automatiskt ett mål för varje tabell från 128 MB till 1 GB.
  • Behåll filnivå-kompaktionsmål aktiverade för att undvika att skriva om filer som uppfyllde ett tidigare adaptivt mål.
  • Behåll raderingsvektorerna aktiverade .
  • Sätt inte på ett godtyckligt maxantal rader per fil. Radbredden varierar, så en radgräns kan skapa alltför små filer för smala tabeller.

I Fabric Spark runtime 1.3 finns adaptiv målfilstorlek, filnivåkomprimeringsmål och raderingsvektorer tillgängliga som opt-in-inställningar.

När kopieringsaktiviteten i Pipeline eller Dataflow Gen2 skriver tabellen granskar du den resulterande filstrukturen och schemalägger underhållet separat. Anta inte att dessa författare tillämpar Spark-runtime-standardinställningar.

Viktigt!

Lakehouse-destinationer i Dataflow Gen2 som använder inkrementell uppdatering stöder varken OPTIMIZE eller REORG TABLE. Följ Dataflow Gen2:s inkrementella uppdateringsbegränsningar.

Förhindra och komprimera små filer

För Spark-skrivna tabeller, föredra automatisk kompaktering. Denna funktion utvärderar tabellfragmentering efter skrivningar och kör kompaktering endast vid behov. Det eliminerar behovet av en separat tabellhälsokontroll innan underhåll påbörjas.

Använd följande vägledning för undantag och kompletterande egenskaper:

Scenario Rekommenderat tillvägagångssätt
tabell skriven med Spark Aktivera automatisk komprimering som standardunderhållsstrategi.
Strömmande skrivningar eller skrivningar i mikrobatchar Aktivera automatisk komprimering och optimera skrivningen för att minska ackumulering av små filer.
Arbetsbelastningar med strikta krav på skrivlatens Schemalägg OPTIMIZE separat istället för att köra synkron automatisk komprimering.
Existerande tabell med ackumulerade små filer Kör en engångs-OPTIMIZE, och aktivera sedan automatisk kompaktering för löpande underhåll.
Tabeller med frekventa uppdateringar, borttagningar eller sammanslagningar Ha raderingsvektorer och automatisk kompaktering aktiverade.

OPTIMIZE komprimerar filer och tar automatiskt bort en fils raderingsvektorer när mer än 5 % av dess poster omfattas av raderingsvektorer. Använd REORG TABLE ... APPLY (PURGE) endast när du måste fysiskt rensa register under den gränsen eller uppfylla ett specifikt efterlevnadskrav.

Note

Autokomprimering rensar bort raderingsvektorer endast när partitionen också uppfyller sin utlösare för små filer. Om en arbetsbelastning utför uppdateringar eller raderingar utan att generera små filer, kör OPTIMIZE periodvis för att rensa kvalificerande raderingsvektorer. Använd REORG TABLE ... APPLY (PURGE) när du måste tvinga fram en fysisk utrensning.

Kör VACUUM på ett separat schema för att ta bort orefererade filer efter lagringsperioden. VACUUM Återtar lagring men förbättrar inte den aktiva fillayouten.

Varning

Förkorta VACUUM inte lagringstiden utan att utvärdera tidsresekrav och samtidiga läsare eller författare. Att ta bort filer för tidigt kan göra nödvändiga tabellversioner otillgängliga.

Organisera data för att hoppa över filer

Använd liquid clustering när återkommande filter- eller bearbetningsmönster har nytta av förbättrad hoppning över filer. Flytande klustrade tabeller kräver OPTIMIZEautomatisk komprimering för att organisera nyskriven data.

Undvik att partitionera som standard. Använd det när ett specifikt krav motiverar de operativa avvägningarna, såsom att isolera samtidiga skrivare som uppdaterar, raderar eller slår samman data över disjunkta partitioner. För mer information, se När man ska använda partitionering.

För befintliga partitionerade tabeller, betrakta Z-ordning när selektiva predikat vanligtvis filtrerar på samma kolumner inom en partition.

Optimera lagerhanterade tabeller

Fabric Data Warehouse hanterar den fysiska Delta-tabelllayouten oavsett intagningsmetod.

Använd de strategiska kontroller som Warehouse exponerar för att justera datalayouten:

  • Tillämpa dataklustring på stora tabeller när frågor upprepade gånger använder selektiva predikat på samma kolumner.
  • Behåll V-Order aktiverat för läsorienterade och blandade arbetsbelastningar. V-Order är aktiverat som standard.
  • Överväg att inaktivera V-Order för skrivintensiva lagerarbetsbelastningar.

Varning

Att inaktivera V-order är en lagernivå, irreversibel operation. Testa hela läs- och skrivarbetsbelastningen innan du inaktiverar den.

Fullständig vägledning om Warehouse finns i Riktlinjer för prestanda i Fabric Data Warehouse.

Optimera speglad data

Din förmåga att förbättra den fysiska layouten beror på om Fabric replikerar datan eller refererar till källfiler:

  • Databasspegeling: Fabric replikerar källdata till Delta-tabeller i OneLake och hanterar V-Order-fillayouten och underhållet. Du kan inte direkt konfigurera målfilstorlek, raderingsvektorrensning, vätskeklustring, partitionering eller V-ordning på den speglade destinationen.
  • Speglade kataloger: Fabric synkroniserar metadata och använder OneLake-genvägar för att referera källdata på plats. Fabric skriver inte om eller underhåller dessa filer. Förbättra den fysiska layouten och rensningen i källsystemet när dess stödda funktioner tillåter det. Dessa förändringar syns genom genvägarna utan att skapa en ny kopia i Fabric.

För databasspeglade data:

  • Använd selektiva predikat och undvik onödiga kolumner i Spark och SQL-frågor.
  • Designa Power BI-semantiska modeller och DAX-mått för effektiv Direct Lake-förbrukning.

För speglade kataloger:

  • Använd källkodsplattformens stödda funktioner för tabellunderhåll och layout.
  • Utvärdera källfilen och radgruppsfördelningen för de Fabric-konsumenter som frågar genvägarna.
  • För Direct Lake, utvärdera att skapa ett ytterligare dimensionellt modellerat, V-ordnat servinglager när källlayouten inte kan uppfylla prestandakraven.

För speglande koncept, typer och stödda källor, se Vad är spegling i Fabric? och Hur metadataspegling fungerar.

Tillämpa konsumentspecifik optimering

Spark och SQL-analysändpunkt fungerar väl på samma adaptiva lakehouse-layout. Använd adaptiv målfilstorlek, förhindra alltför många små filer och använd liquid clustering när uppmätta predikat gynnas av förbättrad filuteslutning. Aktivera inte V-Order enbart för prestanda för Spark eller SQL-analysens slutpunkt. För motorspecifika detaljer, se prestandaöverväganden för SQL Analytics Endpoints.

Power BI Direct Lake

Direct Lake använder samma underliggande Delta-tabeller men lägger till rekommendationer relaterade till transkodning och inkrementell inramning:

Note

Direct Lake presterar generellt bäst med radgrupper mellan 1 och 16 miljoner rader. Utvärdera radgruppsfördelning och Direct Lake-prestanda innan du ändrar en stödd producentinställning.

För Spark-skrivna tabeller spark.sql.parquet.native.writer.maxRowGroupRowCount sätter maximala rader per radgrupp när den inbyggda exekveringsmotorn skriver Parquet-filerna. Standardvärdet är 0, vilket inte ger något maximum. Om analysen visar att radgruppsstorleken påverkar Direct Lakes prestanda, sätt en testad gräns innan tabellen skrivs eller skrivs om. Ett exempel:

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

Sätt inte gränsen enbart för att nå ett specifikt radantal. Radbredd, komprimering, filfördelning och kapacitetsparallellism påverkar också prestandan. Använd Delta Analyzer för att utvärdera den resulterande layouten.

För detaljerad vägledning om inramning, transkodning, radgrupper, uppdateringsmönster och Delta Analyzer, se Förstå Direct Lake-frågeprestanda.

Tillämpa vägledningen på medaljonglager

Brons, silver och guld beskriver datans syfte och förfining. De avgör inte om layouten är användar- eller systemstyrd, och de kräver inte separata kopior för varje konsument.

Skikt Primärt mål Vägledning för flera arbetsbelastningar
Brons (landstigning) Bevara källtrohet och datainmatningskapacitet Prioritera skrivgenomströmning samtidigt som du behåller Spark-skrivna tabeller med automatisk komprimering. Undvik Power BI Direct Lake-semantiska modeller på råa Bronze-tabeller om inte modellen och dataformen är avsiktligt designade för det ändamålet.
Silver (utvalt) Tillhandahålla validerad, konformad data för återanvändning Återanvänd bordet hos kompatibla Fabric-konsumenter. För tabeller i lakehouse som skrivits med Spark ska V-Order endast aktiveras när Direct Lake är den främsta användaren.
Guld (servande) Leverera affärsklara dimensioner, fakta, aggregat och analysmodeller Föredrar detta lager för Direct Lake-semantiska modeller. Återanvänd tabellen över kompatibla konsumenter och tillämpa de producentspecifika kontroller som beskrivs i denna artikel.

Lös layout- och underhållsproblem

Använd åtgärdande med hänsyn till producenten. Applicera Spark-underhållskommandon på lakehouse-tabeller när destinationsläget stödjer dessa operationer. Behandla signalerna som indikatorer snarare än universella trösklar, och validera dem mot tabellens skrivmönster och konsumentprestanda.

Tillstånd Signal Sjöhus-tabell Lagerbord
Överdrivet små filer Filantalet ökar snabbare än den aktiva tabellstorleken, och filerna ligger under det adaptiva målet. Med Spark, kör en engångssökning OPTIMIZE för den befintliga backloggen och aktivera sedan automatisk komprimering. För kopieringsaktivitet i Pipeline eller skrivningar i Dataflow Gen2 ska underhåll av lakehouse som stöds schemaläggas separat. Ingen åtgärd. Lagerkompaktering sker automatiskt.
Äldre överdimensionerade filer Antalet filer ligger fortfarande långt över det aktuella adaptiva målet, och för få filer begränsar parallelliseringen av skanningen. Skriv om tabellen genom att använda en överskrivning eller CREATE OR REPLACE TABLE AS SELECT med adaptiv målfilstorlek aktiverad. Ingen åtgärd. Lageret hanterar filstorleken automatiskt.
Raderingsvektorackumulering DESCRIBE HISTORY Mätvärden visar att raderingsvektorer läggs till eller uppdateras snabbare än kompaktering tar bort dem, vilket potentiellt ökar läsöverhuvudet. Ha automatisk kompaktering aktiverad. Om raderingsvektorer ackumuleras utan att utlösa kompaktering av små filer, schemalägg OPTIMIZE. Använd REORG TABLE ... APPLY (PURGE) endast för uttryckliga utrensningskrav. Ingen åtgärd. Rensning hanteras av systemet.
Dåligt att hoppa över filer Selektiva predikat genomsöker en stor del av tabellen, eller så visar en utvärdering av klustringskvaliteten att organiseringen är bristfällig. Med Spark, konfigurera vätskeklustring eller använd Z-Order för en befintlig partitionerad tabell. Konfigurera klustring av lagerdata.
omkostnad för Direct Lake-transkodning Delta Analyzer visar överdrivna filer, små radgrupper eller bred omkodning efter uppdateringar. Komprimera små filer, granska radgrupper och applicera V-Order på Spark-skrivna tabeller. Konfigurera valfritt liquid clustering för att förbättra komprimeringskvaliteten i Parquet-filer. Behåll V-Order aktiverat och utvärdera dataklustring.
Tillväxt av orefererad fillagring OneLake-lagring växer snabbare än den aktiva tabellstorleken efter dataändringsoperationer. Kör VACUUM enligt krav för lagringstid. Ingen åtgärd. Rensning hanteras av systemet.

För speglade data följer du de producentspecifika åtgärderna i Optimera speglade data. Databasspegling är systemstyrd; För speglade kataloger, tillämpa stödd underhåll i källkodsplattformen.

För lakehouse-tabeller inkluderar alternativen för granskning sådana som stöds av Spark:

  • Kör DESCRIBE DETAIL för att granska antal filer, total storlek och den utvärderade egenskapen delta.targetFileSize.adaptive.
  • Kör DESCRIBE HISTORY för att granska skrivmönster och underhållshistorik.
  • Använd Delta Analyzer när du behöver detaljerad Direct Lake-radgrupps- och uppdateringsmönsteranalys.

Inspektera genomsnittlig filstorlek

Använd DESCRIBE DETAIL för att beräkna den genomsnittliga filstorleken som en initial indikator på tabelllayouten:

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

Ett genomsnitt kan dölja snedfördelning mellan partitioner eller mellan nyligen respektive tidigare kompakterade filer. Om genomsnittet indikerar ett möjligt layoutfel, inspektera de enskilda Parquet-filerna eller använd Delta Analyzer för att utvärdera fördelningen innan underhållsinställningarna ändras.

När ska man skapa en ny tabell

Skapa inte en annan fysisk tabell enbart för att flera Fabric-motorer konsumerar datan.

Skapa en annan tabell när den har ett självständigt syfte, såsom:

  • En transformation eller aggregering som förändrar datans korn eller affärsbetydelse.
  • Olika krav på säkerhet, lagring eller datakvalitet.
  • Ett latens- eller uppdateringskrav som den delade tabellen inte kan uppfylla.
  • En konsumentanpassad layout vars uppmätta nytta överväger dess kostnader för lagring, bearbetning, ursprung och styrning.

Relaterat innehåll

  • Last updated on