Werkbelasting-overschrijdend onderhoud en optimalisatie van tabellen in Microsoft Fabric

Delta-tabellen in Microsoft Fabric kunnen Spark, SQL analytics endpoint, Power BI Direct Lake, Warehouse en andere Fabric-ervaringen leveren vanuit data die in OneLake zijn opgeslagen. Optimale prestaties tussen werklasten hangen af van twee factoren:

• De werklast die de tabel creëert en onderhoudt.
• De engines die de tabel gebruiken.

Lakehouse-tabellen worden vaak beheerd door Spark, Fabric pipeline Copy-activiteit of Dataflow Gen2. Spark is de meest gebruikte schrijver en biedt de breedste lay-out en onderhoudscontroles. Magazijn- en databasespiegeling beheren hun fysieke indelingen automatisch. Gespiegelde catalogi behouden de lay-out die in het bronsysteem wordt beheerd. De behoeften van consumenten zijn over het algemeen compatibel, maar Power BI Direct Lake heeft extra opslagvereisten voor optimale prestaties.

Gebruik één gedeelde tabel wanneer de vereisten compatibel zijn. Voor de uitzonderingen die een andere tabel rechtvaardigen, zie Wanneer een andere tabel moet aanmaken.

Begrijp wie de eigenaar van de lay-out is

Begin met het vaststellen welke werklast de fysieke tabelindeling beheert. De instellingen in de volgende tabel zijn de belangrijkste instellingen die relevant zijn voor de tabelindeling en het onderhoud voor verschillende workloads, en vormen geen uitputtende lijst van de mogelijkheden van elke engine.

Workloadoverschrijdende richtlijnen

De volgende tabel vat de aanbevolen aanpak samen door producent en consument.

Optimaliseer Lakehouse-tabellen

Lakehouse Delta-tabellen vereisen een expliciete onderhoudsstrategie, ongeacht of Spark, Pipeline Copy-activiteit of Dataflow Gen2 ze schrijft. Spark is het belangrijkste voorbeeld in deze sectie omdat het de breedste lay-out en onderhoudscontroles in Fabric biedt.

Gebruik de Spark runtime-standaardinstellingen

Wanneer Spark de tabel schrijft, gebruik dan de standaardinstellingen van Fabric Spark runtime 2.0 of later:

• Houd de adaptieve doelbestandsgrootte ingeschakeld. Het selecteert automatisch een doel voor elke tabel van 128 MB tot 1 GB.
• Houd bestandsniveau compactiedoelen ingeschakeld om te voorkomen dat bestanden worden herschreven die een eerder adaptief doel bereikten.
• Houd verwijderingsvectoren ingeschakeld.
• Leg geen willekeurig maximaal aantal rijen per bestand op. De rijbreedte varieert, dus een rijlimiet kan voor smalle tabellen overmatige kleine bestanden creëren.

In Fabric Spark runtime 1.3 zijn adaptieve doelbestandsgrootte, bestandsniveau-comprimatiedoelen en verwijdervectoren beschikbaar als opt-in instellingen.

Wanneer Pipeline Copy-activiteit of Dataflow Gen2 de tabel schrijft, inspecteer dan de resulterende bestandsindeling en plan het onderhoud apart in. Ga er niet van uit dat deze schrijvers Spark-runtime-standaardinstellingen toepassen.

• Fabric pipelines kunnen na het schrijven een onderhoudsactiviteit van Lakehouse orkestreren.

Voorkom en comprimeer kleine bestanden

Voor door Spark geschreven tabellen geef je de voorkeur aan automatische compactie. Deze functie evalueert tabelfragmentatie na het schrijven en voert verdichting alleen uit wanneer dat nodig is. Hierdoor is een aparte controle van de status van de tabel niet meer nodig voordat onderhoud wordt uitgevoerd.

Gebruik de volgende richtlijnen voor uitzonderingen en aanvullende kenmerken:

OPTIMIZE compacteert bestanden en verwijdert automatisch de verwijderingsvectoren van een bestand wanneer meer dan 5% van de records worden aangeduid door verwijdervectoren. REORG TABLE ... APPLY (PURGE) Gebruik alleen wanneer je fysiek dossiers onder die drempel moet verwijderen of aan een specifieke nalevingseis moet voldoen.

Voer VACUUM uit op een apart schema om niet-gerefereerde bestanden na de bewaarperiode te verwijderen. VACUUM Het wint opslag terug, maar verbetert de actieve bestandsindeling niet.

Data organiseren voor het overslaan van bestanden

Gebruik liquid clustering wanneer terugkerende filter- of verwerkingspatronen profiteren van verbeterde bestandsoverslaan. Liquid-clustered tabellen hebben OPTIMIZEof automatische compactie nodig om nieuw geschreven gegevens te ordenen.

Vermijd standaard partitioneren. Gebruik het wanneer een specifieke vereiste de operationele afwegingen rechtvaardigt, zoals het isoleren van gelijktijdige schrijvers die data bijwerken, verwijderen of samenvoegen over disjuncte partities. Voor meer informatie, zie Wanneer partitionering te gebruiken.

Voor bestaande gepartitioneerde tabellen wordt Z-Order beschouwd wanneer selectieve predicaten vaak op dezelfde kolommen binnen een partitie filteren.

Optimaliseer magazijnbeheerde tabellen

Fabric Data Warehouse beheert de fysieke Delta-tabel indeling, ongeacht de innamemethode.

Gebruik de strategische opties die Warehouse biedt om de gegevensindeling af te stemmen:

• Pas dataclustering toe op grote tabellen wanneer queries herhaaldelijk selectieve predicates op dezelfde kolommen gebruiken.
• Houd V-Order ingeschakeld voor leesgerichte en gemengde workloads. V-Order is standaard ingeschakeld.
• Overweeg V-Order uit te schakelen voor schrijfintensieve magazijnwerklasten.

Voor volledige magazijnrichtlijnen, zie Prestatierichtlijnen in Fabric Data Warehouse.

Optimaliseer gespiegelde data

Je vermogen om de fysieke lay-out te verbeteren hangt af van of Fabric de data repliceert of bronbestanden verwijst:

• Databasespiegeling: Fabric repliceert brongegevens in Delta-tabellen in OneLake en beheert de V-Ordered bestandsindeling en het onderhoud. Je kunt op de gespiegelde bestemming niet rechtstreeks de grootte van het doelbestand, het opschonen van verwijderingsvectoren, liquid clustering, partitioneren of V-Order configureren.
• Gespiegelde catalogi: Fabric synchroniseert metadata en gebruikt OneLake-snelkoppelingen om brondata ter plaatse te refereren. Fabric herschrijft of onderhoudt deze bestanden niet. Verbeter de fysieke lay-out en schoonmaak in het bronsysteem wanneer de ondersteunde functies dat toelaten. Die veranderingen zijn zichtbaar via de sneltoetsen zonder dat er een nieuwe kopie in Fabric wordt gemaakt.

Voor database-gespiegelde gegevens:

• Gebruik selectieve predicaten en vermijd onnodige kolommen in Spark en SQL-queries.
• Ontwerp Power BI semantische modellen en DAX-metingen voor efficiënt Direct Lake-verbruik.

Voor gespiegelde catalogi:

• Gebruik de ondersteunde tabelonderhoud en lay-outfuncties van het bronplatform.
• Evalueer de bronbestand- en rijgroepverdeling voor de Fabric-consumenten die de snelkoppelingen opvragen.
• Voor Direct Lake kun je overwegen een extra dimensioneel gemodelleerde, V-geordende serverlaag te creëren wanneer de bronlayout niet aan de prestatie-eisen kan voldoen.

Voor spiegelingsconcepten, types en ondersteunde bronnen, zie Wat is Mirroring in Fabric? en Hoe metadata-spiegeling werkt.

Pas consumentgerichte optimalisatie toe

Spark en het SQL-analyse-endpoint presteren goed op dezelfde adaptieve lakehouse-indeling. Gebruik adaptieve doelbestandsgrootte, voorkom te kleine bestanden en pas liquid clustering toe wanneer gemeten predicaten profiteren van verbeterde bestandsoverslaan. Schakel V-Order niet alleen in voor de prestaties van Spark- of SQL-analyse-endpoints. Voor engine-specifieke details, zie SQL analytics endpoint performance considerations.

Power BI Direct Lake

Direct Lake gebruikt dezelfde onderliggende Delta-tabellen, maar voegt aanbevelingen toe met betrekking tot transcoding en incrementele framing:

• Bestands- en rijgroepindeling: Vermijd kleine rijgroepen en ongelijke rijgroepverdeling; dit creëert meer VertiPaq-kolomsegmenten en verhoogt de transcoderingsoverhead.
• V-Order: Volg de specifieke aanbeveling van de producent in de richtlijnen voor meerdere workloads. Voor door Spark geschreven tabellen die voornamelijk via Direct Lake worden gebruikt, schakel V-Order in of gebruik het readHeavyForPBI resourceprofiel.
• Updatepatronen: Geef waar mogelijk voorkeur aan appendvriendelijke updatepatronen om bestaande Parquet-bestanden te behouden en incrementele framing te ondersteunen.

Voor door Spark geschreven tabellen stelt spark.sql.parquet.native.writer.maxRowGroupRowCount het maximumaantal rijen per rijgroep in wanneer de native uitvoeringsengine de Parquet-bestanden schrijft. De standaardwaarde is 0, wat geen maximum oplegt. Als analyse aantoont dat de grootte van rijgroepen de prestaties van Direct Lake beïnvloedt, stel dan een geteste limiet in voordat je de tabel schrijft of herschrijft. Voorbeeld:

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

Stel de limiet niet alleen in om een specifiek aantal rijen te bereiken. Rijbreedte, compressie, bestandsverdeling en capaciteitsparallelisme beïnvloeden ook de prestaties. Gebruik Delta Analyzer om de resulterende lay-out te evalueren.

Voor gedetailleerde richtlijnen over framing, transcodering, rijgroepen, updatepatronen en Delta Analyzer, zie Understand Direct Lake-queryprestaties.

Pas de richtlijnen toe op medaillonlagen

Brons, zilver en goud beschrijven het doel en de verfijning van de gegevens. Ze bepalen niet of de lay-out door de gebruiker of door het systeem beheerd is, en ze hebben geen aparte kopieën voor elke consument nodig.

Oplossing van indelings- en onderhoudsproblemen

Gebruik producentenbewuste sanering. Pas Spark-onderhoudscommando's toe op lakehouse-tabellen wanneer de bestemmingsmodus die bewerkingen ondersteunt. Beschouw de signalen als indicatoren in plaats van universele drempels, en toets ze aan het schrijfpatroon van de tabel en de prestaties van de afnemer.

Voor gespiegelde gegevens volgt u de producentspecifieke herstelprocedure in Gespiegelde gegevens optimaliseren. Databasespiegeling wordt door het systeem beheerd; voer voor gespiegelde catalogi ondersteunde onderhoudstaken uit in het bronplatform.

Voor lakehouse-tabellen omvatten door Spark ondersteunde inspectieopties:

• Voer DESCRIBE DETAIL uit om het aantal bestanden, de totale grootte en de geëvalueerde delta.targetFileSize.adaptive eigenschap te inspecteren.
• Voer DESCRIBE HISTORY uit om schrijfpatronen en onderhoudsgeschiedenis te bekijken.
• Gebruik Delta Analyzer wanneer je gedetailleerde Direct Lake rijgroep- en update-patroonanalyse nodig hebt.

Inspecteer de gemiddelde bestandsgrootte

Gebruik DESCRIBE DETAIL om de gemiddelde bestandsgrootte te berekenen als initiële indicator van de tabelindeling:

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

Een gemiddelde kan scheefheid tussen partities of recente en eerder gecompacteerde bestanden verbergen. Als het gemiddelde een mogelijk indelingsprobleem aangeeft, inspecteer dan de individuele Parquet-bestanden of gebruik Delta Analyzer om de verdeling te evalueren voordat onderhoudsinstellingen worden gewijzigd.

Wanneer een nieuwe tabel aanmaken

Maak geen nieuwe fysieke tabel alleen omdat meerdere Fabric-engines de data verbruiken.

Maak een andere tabel aan wanneer deze een onafhankelijk doel heeft, zoals:

• Een transformatie of aggregatie die de korrel of bedrijfsbetekenis van de data verandert.
• Verschillende eisen aan beveiliging, behoud of datakwaliteit.
• Een latentie- of verversingsvereiste waaraan de gedeelde tabel niet kan voldoen.
• Een consumentgerichte lay-out waarvan het gemeten voordeel zwaarder weegt dan de kosten voor opslag, verwerking, afstamming en governance.

Verwante inhoud

• Stel de grootte van Delta-tabel databestanden af
• Delta-tabellen comprimeren
• Verwijderingsvectoren voor Delta-tabellen
• Vloeibare clustering toepassen op Delta-tabellen
• Partitionering voor Delta-tabellen
• Optimaliseer Delta Lake-tabellen met V-Order
• Prestatieoverwegingen voor SQL Analytics-eindpunten
• Begrijp Direct Lake-queryprestaties
• Richtlijnen voor prestaties in Fabric Data Warehouse
• Gegevensclustering in Fabric Data Warehouse
• Wat is spiegelen in Stof?