Forstå lagringsplass for semantiske modeller i Direct Lake
Denne artikkelen introduserer Direct Lake lagringskonsepter. Den beskriver Delta-tabeller og Parquet-filer. Den beskriver også hvordan du kan optimalisere Delta-tabeller for semantiske direct lake-modeller, og hvordan du kan vedlikeholde dem for å bidra til å levere pålitelig, rask spørringsytelse.
Delta-tabeller
Delta-tabeller finnes i OneLake. De organiserer filbaserte data i rader og kolonner og er tilgjengelige for Microsoft Fabric-databehandlingsmotorer som notatblokker, Kustoog lakehouse og lager. Du kan spørre deltatabeller ved hjelp av DAX (Data Analysis Expressions), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL og til og med Python.
Notat
Delta – eller Delta Lake– er et lagringsformat med åpen kildekode. Det betyr at Fabric også kan spørre Delta-tabeller som er opprettet av andre verktøy og leverandører.
Delta-tabeller lagrer dataene sine i Parquet-filer, som vanligvis lagres i et lakehouse som en Semantisk Direct Lake-modell bruker til å laste inn data. Parquet-filer kan imidlertid også lagres eksternt. Eksterne parquet-filer kan refereres ved hjelp av en OneLake-snarvei, som peker til en bestemt lagringsplassering, for eksempel Azure Data Lake Storage (ADLS) Gen2, Amazon S3-lagringskontoer eller Dataverse. I nesten alle tilfeller får databehandlingsmotorer tilgang til Parquet-filene ved å spørre Delta-tabeller. Men vanligvis laster semantiske modeller i Direct Lake kolonnedata direkte fra optimaliserte Parquet-filer i OneLake ved hjelp av en prosess som kalles transkoding.
Dataversjonskontroll
Delta-tabeller består av én eller flere Parquet-filer. Disse filene er ledsaget av et sett med JSON-baserte koblingsfiler, som sporer rekkefølgen og arten til hver parkettfil som er knyttet til en Delta-tabell.
Det er viktig å forstå at de underliggende Parquet-filene er trinnvise i naturen. Derfor navnet Delta som en referanse til trinnvis dataendring. Hver gang en skriveoperasjon i en Delta-tabell finner sted, for eksempel når data settes inn, oppdateres eller slettes, opprettes nye parquet-filer som representerer dataendringene som en versjon. Parkettfiler er derfor uforanderlige, noe som betyr at de aldri blir endret. Det er derfor mulig at data dupliseres mange ganger på tvers av et sett med Parquet-filer for en Delta-tabell. Delta-rammeverket er avhengig av koblingsfiler for å finne ut hvilke fysiske parquetfiler som kreves for å produsere det riktige spørringsresultatet.
Vurder et enkelt eksempel på en Delta-tabell som denne artikkelen bruker til å forklare ulike dataendringsoperasjoner. Tabellen har to kolonner og lagrer tre rader.
| Produksjon | StockOnHand |
|---|---|
| En | 1 |
| B | 2 |
| C | 3 |
Delta-tabelldataene lagres i én enkelt parquetfil som inneholder alle data, og det finnes én enkelt koblingsfil som inneholder metadata om når dataene ble satt inn (tilføyd).
- Parkettfil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Koblingsfil 1:
- Inneholder tidsstempelet da
Parquet file 1ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
Sett inn operasjoner
Vurder hva som skjer når en innsettingsoperasjon oppstår: En ny rad for produkt C med en lagerverdi på 4 settes inn. Denne operasjonen resulterer i oppretting av en ny Parquet-fil og koblingsfil, så det er nå to Parquet-filer og to koblingsfiler.
- Parkettfil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parkettfil 2:
- ProductID: D
- StockOnHand: 4
- Koblingsfil 1:
- Inneholder tidsstempelet da
Parquet file 1ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
- Koblingsfil 2:
- Inneholder tidsstempelet da
Parquet file 2ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
På dette tidspunktet returnerer en spørring i Delta-tabellen følgende resultat. Det spiller ingen rolle at resultatet er hentet fra flere parquet-filer.
| Produksjon | StockOnHand |
|---|---|
| En | 1 |
| B | 2 |
| C | 3 |
| D | 4 |
Hver etterfølgende innsettingsoperasjon oppretter nye Parquet-filer og koblingsfiler. Det betyr at antall parquet-filer og koblingsfiler vokser med hver innsettingsoperasjon.
Oppdater operasjoner
Vurder nå hva som skjer når en oppdateringsoperasjon oppstår: Raden for produkt D har lagerverdien endret til 10. Denne operasjonen resulterer i oppretting av en ny Parquet-fil og koblingsfil, så det er nå tre Parquet-filer og tre koblingsfiler.
- Parkettfil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parkettfil 2:
- ProductID: D
- StockOnHand: 4
- Parkettfil 3:
- ProductID: C
- StockOnHand: 10
- Koblingsfil 1:
- Inneholder tidsstempelet da
Parquet file 1ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
- Koblingsfil 2:
- Inneholder tidsstempelet da
Parquet file 2ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
- Koblingsfil 3:
- Inneholder tidsstempelet da
Parquet file 3ble opprettet, og registrerer dataene som ble oppdatert.
- Inneholder tidsstempelet da
På dette tidspunktet returnerer en spørring i Delta-tabellen følgende resultat.
| Produksjon | StockOnHand |
|---|---|
| En | 1 |
| B | 2 |
| C | 10 |
| D | 4 |
Data for produkt C finnes nå i flere parquet-filer. Spørringer til Delta-tabellen kombinerer imidlertid koblingsfilene for å finne ut hvilke data som skal brukes til å gi riktig resultat.
Slett operasjoner
Vurder nå hva som skjer når en sletteoperasjon oppstår: Raden for produkt B slettes. Denne operasjonen resulterer i en ny Parquet-fil og koblingsfil, så det er nå fire Parquet-filer og fire koblingsfiler.
- Parkettfil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parkettfil 2:
- ProductID: D
- StockOnHand: 4
- Parkettfil 3:
- ProductID: C
- StockOnHand: 10
- Parkettfil 4:
- ProductID: A, C, D
- StockOnHand: 1, 10, 4
- Koblingsfil 1:
- Inneholder tidsstempelet da
Parquet file 1ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
- Koblingsfil 2:
- Inneholder tidsstempelet da
Parquet file 2ble opprettet, og poster som dataene ble tilføyet.
- Inneholder tidsstempelet da
- Koblingsfil 3:
- Inneholder tidsstempelet da
Parquet file 3ble opprettet, og registrerer dataene som ble oppdatert.
- Inneholder tidsstempelet da
- Koblingsfil 4:
- Inneholder tidsstempelet da
Parquet file 4ble opprettet, og registrerer dataene som ble slettet.
- Inneholder tidsstempelet da
Legg merke til at Parquet file 4 ikke lenger inneholder data for produkt B, men den inneholder data for alle andre rader i tabellen.
På dette tidspunktet returnerer en spørring i Delta-tabellen følgende resultat.
| Produksjon | StockOnHand |
|---|---|
| En | 1 |
| C | 10 |
| D | 4 |
Notat
Dette eksemplet er enkelt fordi det involverer en liten tabell, bare noen få operasjoner og bare mindre endringer. Store tabeller som opplever mange skriveoperasjoner og som inneholder mange rader med data, genererer mer enn én parquetfil per versjon.
Viktig
Avhengig av hvordan du definerer Delta-tabellene og hyppigheten av dataendringsoperasjoner, kan det føre til mange parquet-filer. Vær oppmerksom på at hver fabric kapasitet lisens har rekkverk. Hvis antall parquetfiler for en Delta-tabell overskrider grensen for SKU-en, vil spørringer falle tilbake til DirectQuery, noe som kan føre til langsommere spørringsytelse.
Hvis du vil administrere antall parquet-filer, kan du se Delta-tabellvedlikehold senere i denne artikkelen.
Delta tidsreiser
Koblingsfiler aktiverer spørring av data fra et tidligere tidspunkt. Denne funksjonen kalles deltatidsreiser. Det tidligere tidspunktet kan være et tidsstempel eller en versjon.
Vurder følgende spørringseksempler.
SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;
Tips
Du kan også spørre en tabell ved hjelp av @ shorthand-syntaks for å angi tidsstempelet eller versjonen som en del av tabellnavnet. Tidsstempelet må være i yyyyMMddHHmmssSSS format. Du kan angi en versjon etter @ ved å forhåndsvente en v til versjonen.
Her er de forrige spørringseksempler omskrevet med korthåndssyntaks.
SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;
Viktig
Tabellversjoner som er tilgjengelige med tidsreiser, bestemmes av en kombinasjon av oppbevaringsterskelen for transaksjonsloggfiler og hyppigheten og den angitte oppbevaringen for VACUUM-operasjoner (beskrevet senere i Delta-tabellvedlikehold inndeling). Hvis du kjører VACUUM daglig med standardverdiene, vil sju dager med data være tilgjengelig for tidsreiser.
Innramming
Innramming av er en Direct Lake-operasjon som angir versjonen av en Delta-tabell som skal brukes til å laste inn data i en semantisk modellkolonne. Like viktig er det at versjonen også bestemmer hva som skal utelates når data lastes inn.
En innrammingsoperasjon stempler tidsstempelet/versjonen av hver Delta-tabell inn i semantiske modelltabeller. Fra dette punktet, når den semantiske modellen må laste inn data fra en Delta-tabell, brukes tidsstempelet/versjonen som er knyttet til den nyeste innrammingsoperasjonen, til å bestemme hvilke data som skal lastes inn. Eventuelle etterfølgende dataendringer som skjer for Delta-tabellen siden den siste innrammingsoperasjonen ignoreres (frem til neste innrammingsoperasjon).
Viktig
Fordi en innrammet semantisk modell refererer til en bestemt Delta-tabellversjon, må kilden sørge for at den beholder denne Delta-tabellversjonen til innrammingen av en ny versjon er fullført. Ellers vil brukere støte på feil når Delta-tabellfilene må åpnes av modellen og har blitt støvsugd eller på annen måte slettet av produsentens arbeidsbelastning.
Hvis du vil ha mer informasjon om innramming, kan du se Oversikt over Direct Lake.
Tabellpartisjonering
Delta-tabeller kan partisjoneres slik at et delsett med rader lagres sammen i ett sett med Parquet-filer. Partisjoner kan øke hastigheten på spørringer samt skriveoperasjoner.
Vurder en Delta-tabell som har en milliard rader med salgsdata for en toårsperiode. Selv om det er mulig å lagre alle dataene i ett sett med Parquet-filer, er det for dette datavolumet ikke optimalt for lese- og skriveoperasjoner. I stedet kan ytelsen forbedres ved å spre de milliarder radene med data på tvers av flere serier med Parquet-filer.
En partisjonsnøkkel må defineres når du konfigurerer tabellpartisjonering. Partisjonsnøkkelen bestemmer hvilke rader som skal lagres i hvilken serie. For Delta-tabeller kan partisjonsnøkkelen defineres basert på de distinkte verdiene i en angitt kolonne (eller kolonner), for eksempel en måned/år-kolonne i en datotabell. I dette tilfellet distribueres to år med data på tvers av 24 partisjoner (2 år x 12 måneder).
Stoffdatabehandlingsmotorer er ikke klar over tabellpartisjoner. Når de setter inn nye partisjonsnøkkelverdier, opprettes nye partisjoner automatisk. I OneLake finner du én undermappe for hver unike partisjonsnøkkelverdi, og hver undermappe lagrer sitt eget sett med Parquet-filer og koblingsfiler. Minst én parquetfil og én koblingsfil må finnes, men det faktiske antallet filer i hver undermappe kan variere. Etter hvert som dataendringsoperasjoner finner sted, opprettholder hver partisjon sitt eget sett med Parquet-filer og kobler filer for å holde oversikt over hva som skal returneres for et gitt tidsstempel eller en gitt versjon.
Hvis en spørring i en partisjonert Delta-tabell filtreres til bare de siste tre månedene med salgsdata, kan delsettet med Parquet-filer og koblingsfiler som må åpnes, raskt identifiseres. Da kan du hoppe over mange Parquet-filer helt, noe som resulterer i bedre leseytelse.
Spørringer som ikke filtrerer på partisjonsnøkkelen, kan imidlertid ikke alltid fungere bedre. Det kan være tilfelle når en Delta-tabell lagrer alle data i ett enkelt stort sett med Parquet-filer, og det er fil- eller radgruppefragmisering. Selv om det er mulig å parallellisere datahentingen fra flere parquetfiler på tvers av flere klyngenoder, kan mange små parquet-filer påvirke fil-I/U negativt og derfor spørre ytelse. Derfor er det best å unngå partisjonering av Delta-tabeller i de fleste tilfeller, med mindre skriveoperasjoner eller trekke ut, transformere og laste inn (ETL)-prosesser helt klart ville ha nytte av det.
Partisjoneringsfordeler setter inn, oppdaterer og sletter operasjoner også, fordi filaktivitet bare foregår i undermapper som samsvarer med partisjonsnøkkelen for de endrede eller slettede radene. Hvis for eksempel en gruppe med data settes inn i en partisjonert Delta-tabell, vurderes dataene for å bestemme hvilke partisjonsnøkkelverdier som finnes i gruppen. Dataene sendes deretter bare til de relevante mappene for partisjonene.
Hvis du forstår hvordan Delta-tabeller bruker partisjoner, kan det hjelpe deg med å utforme optimale ETL-scenarioer som reduserer skriveoperasjonene som må skje når du oppdaterer store Delta-tabeller. Skriveytelsen forbedres ved å redusere antallet og størrelsen på eventuelle nye Parquet-filer som må opprettes. For en stor Delta-tabell partisjonert etter måned/år, som beskrevet i forrige eksempel, legger nye data bare til nye Parquet-filer i den nyeste partisjonen. Undermapper i tidligere kalendermåneder forblir uberørte. Hvis noen data fra tidligere kalendermåneder må endres, får bare de relevante partisjonsmappene nye partisjons- og koblingsfiler.
Viktig
Hvis hovedformålet med en Delta-tabell er å fungere som en datakilde for semantiske modeller (og sekundært, andre spørringsarbeidsbelastninger), er det vanligvis bedre å unngå partisjonering i preferanse for å optimalisere belastning av kolonner i minnet.
For semantiske Modeller for Direct Lake eller SQL Analytics-endepunktet, er den beste måten å optimalisere Tabellpartisjoner i Delta på å la Fabric automatisk administrere Parkett-filene for hver versjon av en Delta-tabell. Hvis du forlater ledelsen til Fabric, bør det føre til høy spørringsytelse gjennom parallellisering, men det gir kanskje ikke nødvendigvis den beste skriveytelsen.
Hvis du må optimalisere for skriveoperasjoner, bør du vurdere å bruke partisjoner til å optimalisere skriveoperasjoner til Delta-tabeller basert på partisjonsnøkkelen. Vær imidlertid oppmerksom på at over partisjonering av en Delta-tabell kan påvirke leseytelsen negativt. Derfor anbefaler vi at du tester lese- og skriveytelsen nøye, kanskje ved å opprette flere kopier av samme Delta-tabell med ulike konfigurasjoner for å sammenligne tidsberegninger.
Advarsel
Hvis du partisjonerer på en kolonne med høy kardinalitet, kan det resultere i et stort antall parquet-filer. Vær oppmerksom på at hver Fabric kapasitet lisens har rekkverk. Hvis antall parquetfiler for en Delta-tabell overskrider grensen for SKU-en, vil spørringer falle tilbake til DirectQuery, noe som kan føre til langsommere spørringsytelse.
Parquet-filer
Den underliggende lagringsplassen for en Delta-tabell er én eller flere Parquet-filer. Parquet-filformat brukes vanligvis for skrive-én, lese-mange programmer. Nye parquet-filer opprettes hver gang data i en Delta-tabell endres, enten ved en innsettings-, oppdaterings- eller sletteoperasjon.
Notat
Du kan få tilgang til Parquet-filer som er knyttet til Delta-tabeller ved hjelp av et verktøy, for eksempel OneLake-filutforskeren. Filer kan lastes ned, kopieres eller flyttes til andre mål like enkelt som å flytte andre filer. Det er imidlertid kombinasjonen av Parquet-filer og JSON-baserte koblingsfiler som gjør det mulig for databehandlingsmotorer å utstede spørringer mot filene som en Delta-tabell.
Parquet-filformat
Det interne formatet til en parkettfil skiller seg fra andre vanlige datalagringsformater, for eksempel CSV, TSV, XMLA og JSON. Disse formatene organiserer data etter rader, mens Parkett organiserer data etter kolonner. Parquet-filformatet skiller seg også fra disse formatene fordi det organiserer rader med data i én eller flere radgrupper.
Den interne datastrukturen til en semantisk Power BI-modell er kolonnebasert, noe som betyr at Parquet-filer deler mye til felles med Power BI. Denne likheten betyr at en semantisk Direct Lake-modell effektivt kan laste inn data fra Parquet-filene direkte i minnet. Faktisk kan svært store mengder data lastes inn i løpet av sekunder. Sammenlign denne funksjonen med oppdateringen av en semantisk importmodell som må hente blokker eller kildedata, deretter behandle, kode, lagre og deretter laste den inn i minnet. En oppdateringsoperasjon for semantisk importmodell kan også bruke betydelige mengder databehandling (minne og CPU) og ta lang tid å fullføre. Men med Delta-tabeller finner det meste av arbeidet med å klargjøre dataene som passer for direkte innlasting i en semantisk modell, sted når Parkett-filen genereres.
Slik lagrer parkettfiler data
Vurder følgende eksempelsett med data.
| Daddel | Produksjon | StockOnHand |
|---|---|---|
| 2024-09-16 | En | 10 |
| 2024-09-16 | B | 11 |
| 2024-09-17 | En | 13 |
| … |
Når det er lagret i Parquet-filformat, kan dette settet med data se ut som følgende tekst.
Header:
RowGroup1:
Date: 2024-09-16, 2024-09-16, 2024-09-17…
ProductID: A, B, A…
StockOnHand: 10, 11, 13…
RowGroup2:
…
Footer:
Data komprimeres ved å erstatte ordlistenøkler for vanlige verdier, og ved å bruke run-length koding (RLE). RLE forsøker å komprimere en serie med samme verdier til en mindre representasjon. I eksemplet nedenfor opprettes en ordlistetilordning av numeriske nøkler til verdier i toppteksten, og de mindre nøkkelverdiene brukes i stedet for dataverdiene.
Header:
Dictionary: [
(1, 2024-09-16), (2, 2024-09-17),
(3, A), (4, B),
(5, 10), (6, 11), (7, 13)
…
]
RowGroup1:
Date: 1, 1, 2…
ProductID: 3, 4, 3…
StockOnHand: 5, 6, 7…
Footer:
Når semantisk direct lake-modell trenger data for å beregne summen av StockOnHand kolonnen gruppert etter ProductID, kreves bare ordlisten og dataene som er knyttet til de to kolonnene. I store filer som inneholder mange kolonner, kan store deler av Parquet-filen hoppes over for å gjøre leseprosessen raskere.
Notat
Innholdet i en parkettfil er ikke lesbart for mennesker, og er derfor ikke egnet til å åpnes i et tekstredigeringsprogram. Det finnes imidlertid mange verktøy med åpen kildekode som kan åpne og vise innholdet i en parkettfil. Disse verktøyene kan også gjøre det mulig å undersøke metadata, for eksempel antall rader og radgrupper i en fil.
V-ordre
Fabric støtter en ekstra optimalisering kalt V-Order. V-Order er en skrivetidsoptimalisering i Parquet-filformatet. Når V-order er brukt, resulterer det i en mindre og derfor raskere fil å lese. Denne optimaliseringen er spesielt relevant for en semantisk direct lake-modell fordi den klargjør dataene for rask innlasting i minnet, og derfor stiller den mindre krav til kapasitetsressurser. Det resulterer også i raskere spørringsytelse fordi mindre minne må skannes.
Deltatabeller som er opprettet og lastet inn av Fabric-elementer, for eksempel datasamlebånd, dataflyterog notatblokker bruker automatisk V-order. Parquet-filer som lastes opp til et Fabric Lakehouse, eller som det refereres til av en snarvei, har kanskje ikke denne optimaliseringen brukt. Selv om ikke-optimaliserte Parquet-filer fremdeles kan leses, vil leseytelsen sannsynligvis ikke være så rask som en tilsvarende parquet-fil som har brukt V-ordre.
Notat
Parquet-filer som har V-Order brukt, samsvarer fortsatt med parkettfilformatet med åpen kildekode. Derfor kan de leses av verktøy som ikke er stoff.
Hvis du vil ha mer informasjon, kan du se Tabelloptimalisering for Delta Lake og V-Order.
Delta-tabelloptimalisering
Denne delen beskriver ulike emner for optimalisering av Delta-tabeller for semantiske modeller.
Datavolum
Selv om Delta-tabeller kan vokse til å lagre svært store mengder data, Fabric-kapasitetsrekkverk sette grenser for semantiske modeller som spør etter dem. Når disse grensene overskrides, vil spørringer falle tilbake til DirectQuery, noe som kan føre til langsommere spørringsytelse.
Vurder derfor å begrense radantallet for en stor faktatabell ved å øke detaljnivået (lagre summerte data), redusere dimensjonalitet eller lagre mindre logg.
Sørg også for at V-Order brukes fordi det resulterer i en mindre og derfor raskere fil å lese.
Kolonnedatatype
Forsøk å redusere kardinaliteten (antall unike verdier) i hver kolonne i hver Delta-tabell. Dette er fordi alle kolonnene er komprimert og lagret ved hjelp av hash-koding. Hash-koding krever V-ordreoptimalisering for å tilordne en numerisk identifikator til hver unike verdi i kolonnen. Det er den numeriske identifikatoren som lagres, og krever et hash-oppslag under lagring og spørring.
Når du bruker omtrentlige numeriske datatyper (for eksempel flyte og reelle), bør du vurdere å avrunde verdier og bruke en lavere presisjon.
Unødvendige kolonner
Som med alle datatabeller bør Delta-tabeller bare lagre kolonner som kreves. I sammenheng med denne artikkelen betyr det at den semantiske modellen krever det, selv om det kan være andre analytiske arbeidsbelastninger som spør deltatabellene.
Delta-tabeller bør inneholde kolonner som kreves av den semantiske modellen for filtrering, gruppering, sortering og oppsummering, i tillegg til kolonner som støtter modellrelasjoner. Selv om unødvendige kolonner ikke påvirker semantisk modellspørringsytelse (fordi de ikke lastes inn i minnet), resulterer de i en større lagringsstørrelse og krever derfor flere databehandlingsressurser for å laste inn og vedlikeholde.
Fordi semantiske modeller i Direct Lake ikke støtter beregnede kolonner, bør du materialisere slike kolonner i Delta-tabellene. Vær oppmerksom på at denne utformingstilnærmingen er et antimønster for semantiske modeller for Import og DirectQuery. Hvis du for eksempel har FirstName og LastName kolonner, og du trenger en FullName kolonne, materialiserer du verdiene for denne kolonnen når du setter inn rader i Delta-tabellen.
Tenk på at noen semantiske modellsammendrag kan avhenge av mer enn én kolonne. Hvis du for eksempel vil beregne salg, summerer målet i modellen produktet av to kolonner: Quantity og Price. Hvis ingen av disse kolonnene brukes uavhengig, vil det være mer effektivt å materialisere salgsberegningen som én kolonne enn å lagre komponentverdiene i separate kolonner.
Radgruppestørrelse
Internt organiserer en parkettfil rader med data i flere radgrupper i hver fil. En parquetfil som inneholder 30 000 rader, kan for eksempel dele dem inn i tre radgrupper, som hver har 10 000 rader.
Antall rader i en radgruppe påvirker hvor raskt Direct Lake kan lese dataene. Et høyere antall radgrupper med færre rader vil sannsynligvis ha negativ innvirkning på innlasting av kolonnedata i en semantisk modell på grunn av overdreven I/U.
Vanligvis anbefaler vi ikke at du endrer standard radgruppestørrelse. Du kan imidlertid vurdere å endre radgruppestørrelsen for store Delta-tabeller. Pass på å teste lese- og skriveytelsen nøye, kanskje ved å opprette flere kopier av de samme Delta-tabellene med ulike konfigurasjoner for å sammenligne tidsberegninger.
Viktig
Vær oppmerksom på at hver Fabric kapasitet lisens har rekkverk. Hvis antall radgrupper for en Delta-tabell overskrider grensen for SKU-en, vil spørringer falle tilbake til DirectQuery, noe som kan føre til langsommere spørringsytelse.
Delta-tabellvedlikehold
Etter hvert som skriveoperasjoner finner sted, akkumuleres Delta-tabellversjoner. Etter hvert kan du nå et punkt der en negativ innvirkning på leseytelsen blir merkbar. Verre, hvis antall parquetfiler per tabell eller radgrupper per tabell, eller rader per tabell overskrider rekkverk for kapasiteten, vil spørringer falle tilbake til DirectQuery, noe som kan føre til langsommere spørringsytelse. Det er derfor viktig at du vedlikeholder Delta-tabeller regelmessig.
OPTIMALISERE
Du kan bruke OPTIMALISER til å optimalisere en Delta-tabell for å samle mindre filer til større filer. Du kan også angi WHERE-setningsdelen til bare et filtrert delsett av rader som samsvarer med et gitt partisjonspredikat. Bare filtre som involverer partisjonsnøkler støttes. Kommandoen OPTIMIZE kan også bruke V-order til å komprimere og skrive om parquet-filene.
Vi anbefaler at du kjører denne kommandoen på store, jevnlig oppdaterte Delta-tabeller regelmessig, kanskje hver dag når ETL-prosessen fullføres. Balansere avveiningen mellom bedre spørringsytelse og kostnadene ved ressursbruk som kreves for å optimalisere tabellen.
VAKUUM
Du kan bruke VACUUM til å fjerne filer som ikke lenger refereres til, og/eller som er eldre enn en angitt oppbevaringsterskel. Pass på å angi en passende oppbevaringsperiode, ellers kan du miste muligheten til å tidsreiser tilbake til en versjon som er eldre enn rammen stemplet inn i semantiske modelltabeller.
Viktig
Fordi en innrammet semantisk modell refererer til en bestemt Delta-tabellversjon, må kilden sørge for at den beholder denne Delta-tabellversjonen til innrammingen av en ny versjon er fullført. Ellers vil brukere støte på feil når Delta-tabellfilene må åpnes av modellen og har blitt støvsugd eller på annen måte slettet av produsentens arbeidsbelastning.
REORG-TABELL
Du kan bruke REORG TABLE til å omorganisere en Delta-tabell ved å skrive om filer for å fjerne data som slettes, for eksempel når du slipper en kolonne ved hjelp av ALTER TABLE DROP COLUMN.
Automatiser tabellvedlikehold
Hvis du vil automatisere vedlikeholdsoperasjoner for tabeller, kan du bruke Lakehouse-API-en. Hvis du vil ha mer informasjon, kan du se Administrere Lakehouse med REST-API-en for Microsoft Fabric.
Tips
Du kan også bruke lakehouse Table-vedlikeholdsfunksjonen i Fabric-portalen for å forenkle administrasjon av Delta-tabellene.