Del via

Forstå lagerplads til semantiske Direct Lake-modeller

  • Artikel

I denne artikel introduceres Lagerkoncepter for Direct Lake. Den beskriver Delta-tabeller og Parquet-filer. Den beskriver også, hvordan du kan optimere Delta-tabeller til Semantiske Direct Lake-modeller, og hvordan du kan vedligeholde dem for at hjælpe med at levere pålidelig og hurtig ydeevne af forespørgsler.

Delta-tabeller

Der findes deltatabeller i OneLake. De organiserer filbaserede data i rækker og kolonner og er tilgængelige for Microsoft Fabric-beregningsprogrammer, f.eks. notesbøger, Kustoog lakehouse- og warehouse-. Du kan forespørge Delta-tabeller ved hjælp af DAX (Data Analysis Expressions), Flerdimensionelle udtryk (MDX), T-SQL (Transact-SQL), Spark SQL og endda Python.

Seddel

Delta – eller Delta Lake– er et lagringsformat med åben kildekode. Det betyder, at Fabric også kan forespørge Delta-tabeller, der er oprettet af andre værktøjer og leverandører.

Delta-tabeller gemmer deres data i Parquet-filer, som typisk gemmes i et lakehouse, som en semantisk Direct Lake-model bruger til at indlæse data. Parquet-filer kan dog også gemmes eksternt. Der kan refereres til eksterne parquetfiler ved hjælp af en OneLake-genvej, som peger på en bestemt lagerplacering, f.eks. ADLS (Azure Data Lake Storage) Gen2, Amazon S3-lagerkonti eller Dataverse-. I næsten alle tilfælde får beregningsprogrammer adgang til Parquet-filerne ved at forespørge Delta-tabeller. Semantiske Direct Lake-modeller indlæser dog typisk kolonnedata direkte fra optimerede Parquet-filer i OneLake ved hjælp af en proces, der kaldes omkodning.

Dataversioner

Delta-tabeller indeholder en eller flere Parquet-filer. Disse filer ledsages af et sæt JSON-baserede linkfiler, der sporer rækkefølgen og arten af hver Parquet-fil, der er knyttet til en Delta-tabel.

Det er vigtigt at forstå, at de underliggende Parquet-filer er trinvise. Derfor Delta som en reference til trinvis ændring af data. Hver gang en skrivehandling til en Delta-tabel udføres – f.eks. når data indsættes, opdateres eller slettes – oprettes der nye Parquet-filer, der repræsenterer dataændringerne som en version. Parquetfiler er derfor uforanderlige, hvilket betyder, at de aldrig ændres. Det er derfor muligt at duplikere data mange gange på tværs af et sæt Parquet-filer for en Delta-tabel. Delta-strukturen er afhængig af linkfiler for at bestemme, hvilke fysiske parquetfiler der kræves for at producere det korrekte forespørgselsresultat.

Overvej et simpelt eksempel på en Delta-tabel, som denne artikel bruger til at forklare forskellige dataændringshandlinger. Tabellen indeholder to kolonner og gemmer tre rækker.

Instruktion StockOnHand
En 1
B 2
C 3

Delta-tabeldataene gemmes i en enkelt Parquet-fil, der indeholder alle data, og der er en enkelt linkfil, der indeholder metadata om, hvornår dataene blev indsat (tilføjet).

  • Parquetfil 1:
    • ProductID: A, B, C
    • StockOnHand-: 1, 2, 3
  • Linkfil 1:
    • Indeholder tidsstemplet, da Parquet file 1 blev oprettet, og poster, som dataene blev tilføjet.

Indsæt handlinger

Overvej, hvad der sker, når der udføres en indsættelseshandling: Der indsættes en ny række for produkt C med en lagerværdi på 4. Denne handling resulterer i oprettelse af en ny Parquet-fil og en kædefil, så der er nu to Parquet-filer og to linkfiler.

  • Parquetfil 1:
    • ProductID: A, B, C
    • StockOnHand-: 1, 2, 3
  • Parquetfil 2:
    • ProductID: D
    • StockOnHand-: 4
  • Linkfil 1:
    • Indeholder tidsstemplet, da Parquet file 1 blev oprettet, og poster, som dataene blev tilføjet.
  • Linkfil 2:
    • Indeholder tidsstemplet, da Parquet file 2 blev oprettet, og poster, som dataene blev tilføjet.

På dette tidspunkt returnerer en forespørgsel i Delta-tabellen følgende resultat. Det betyder ikke noget, at resultatet stammer fra flere Parquet-filer.

Instruktion StockOnHand
En 1
B 2
C 3
D 4

Hver efterfølgende indsættelseshandling opretter nye Parquet-filer og linkfiler. Det betyder, at antallet af Parquet-filer og linkfiler vokser med hver indsættelseshandling.

Opdateringshandlinger

Overvej nu, hvad der sker, når der sker en opdateringshandling: Rækken for produkt D har den aktuelle lagerværdi ændret til 10. Denne handling resulterer i oprettelse af en ny Parquet-fil og en kædefil, så der er nu tre Parquet-filer og tre linkfiler.

  • Parquetfil 1:
    • ProductID: A, B, C
    • StockOnHand-: 1, 2, 3
  • Parquetfil 2:
    • ProductID: D
    • StockOnHand-: 4
  • Parquetfil 3:
    • ProductID-: C
    • StockOnHand-: 10
  • Linkfil 1:
    • Indeholder tidsstemplet, da Parquet file 1 blev oprettet, og poster, som dataene blev tilføjet.
  • Linkfil 2:
    • Indeholder tidsstemplet, da Parquet file 2 blev oprettet, og poster, som dataene blev tilføjet.
  • Linkfil 3:
    • Indeholder tidsstemplet, da Parquet file 3 blev oprettet, og poster, som dataene blev opdateret.

På dette tidspunkt returnerer en forespørgsel i Delta-tabellen følgende resultat.

Instruktion StockOnHand
En 1
B 2
C 10
D 4

Data for produkt C findes nu i flere Parquet-filer. Forespørgsler til Delta-tabellen kombinerer dog linkfilerne for at bestemme, hvilke data der skal bruges til at levere det korrekte resultat.

Slet handlinger

Overvej nu, hvad der sker, når der sker en sletning: Rækken for produkt B slettes. Denne handling resulterer i en ny Parquet-fil og linkfil, så der er nu fire Parquet-filer og fire linkfiler.

  • Parquetfil 1:
    • ProductID: A, B, C
    • StockOnHand-: 1, 2, 3
  • Parquetfil 2:
    • ProductID: D
    • StockOnHand-: 4
  • Parquetfil 3:
    • ProductID-: C
    • StockOnHand-: 10
  • Parquetfil 4:
    • ProductID-: A, C, D
    • StockOnHand-: 1, 10, 4
  • Linkfil 1:
    • Indeholder tidsstemplet, da Parquet file 1 blev oprettet, og poster, som dataene blev tilføjet.
  • Linkfil 2:
    • Indeholder tidsstemplet, da Parquet file 2 blev oprettet, og poster, som dataene blev tilføjet.
  • Linkfil 3:
    • Indeholder tidsstemplet, da Parquet file 3 blev oprettet, og poster, som dataene blev opdateret.
  • Linkfil 4:
    • Indeholder tidsstemplet, da Parquet file 4 blev oprettet, og poster, som dataene blev slettet.

Bemærk, at Parquet file 4 ikke længere indeholder data for produkt B, men indeholder data for alle andre rækker i tabellen.

På dette tidspunkt returnerer en forespørgsel i Delta-tabellen følgende resultat.

Instruktion StockOnHand
En 1
C 10
D 4

Seddel

Dette eksempel er enkelt, fordi det omfatter en lille tabel, kun nogle få handlinger og kun mindre ændringer. Store tabeller, der oplever mange skrivehandlinger, og som indeholder mange rækker med data, genererer mere end én Parquet-fil pr. version.

Vigtig

Afhængigt af hvordan du definerer dine Delta-tabeller og hyppigheden af dataændringshandlinger, kan det resultere i mange Parquet-filer. Vær opmærksom på, at hver Fabric-kapacitetslicens har gelændere. Hvis antallet af Parquet-filer for en Delta-tabel overskrider grænsen for din SKU, vil forespørgsler falde tilbage til DirectQuery, hvilket kan resultere i langsommere forespørgselsydeevne.

Hvis du vil administrere antallet af Parquet-filer, skal du se vedligeholdelse af Delta-tabel senere i denne artikel.

Delta-tidsrejse

Linkfiler gør det muligt at forespørge om data fra et tidligere tidspunkt. Denne funktion kaldes Delta-tidsrejser. Det tidligere tidspunkt kan være et tidsstempel eller en version.

Overvej følgende forespørgselseksempler.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

Drikkepenge

Du kan også forespørge en tabel ved hjælp af @ oversigtssyntaks til at angive tidsstempel eller version som en del af tabelnavnet. Tidsstemplet skal være i yyyyMMddHHmmssSSS format. Du kan angive en version efter @ ved at forudindstille en v til versionen.

Her er de forrige forespørgselseksempler, der er omskrevet med oversigtssyntaks.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Vigtig

Tabelversioner, der er tilgængelige med tidsrejser, bestemmes af en kombination af opbevaringstærsklen for transaktionslogfiler og hyppigheden og den angivne opbevaring for VACUUM-handlinger (beskrevet senere i afsnittet vedligeholdelse af Delta-tabel). Hvis du kører VACUUM dagligt med standardværdierne, vil der være syv dages data til rådighed for tidsrejser.

Indramning

Framing er en Direct Lake-handling, der angiver den version af en Delta-tabel, der skal bruges til at indlæse data i en semantisk modelkolonne. Lige så vigtigt er det, at versionen også bestemmer, hvad der skal udelades, når data indlæses.

En indramningshandling stempler tidsstempel/version af hver Delta-tabel i de semantiske modeltabeller. Når den semantiske model skal indlæse data fra en Delta-tabel, bruges det tidsstempel/den version, der er knyttet til den seneste indramningshandling, til at bestemme, hvilke data der skal indlæses. Eventuelle efterfølgende dataændringer, der sker for Delta-tabellen siden den seneste indramning, ignoreres (indtil den næste indramning).

Vigtig

Da en indrammet semantisk model refererer til en bestemt Delta-tabelversion, skal kilden sikre, at deltatabelversionen bevares, indtil udformningen af en ny version er fuldført. Ellers vil brugerne støde på fejl, når modellen skal have adgang til Delta-tabelfilerne, og de er blevet støvsuget eller på anden måde slettet af producentens arbejdsbelastning.

Du kan få flere oplysninger om indramning under oversigt over Direct Lake.

Tabelpartitionering

Delta-tabeller kan partitioneres, så et undersæt af rækker gemmes sammen i et enkelt sæt Parquet-filer. Partitioner kan fremskynde forespørgsler samt skrivehandlinger.

Overvej en Delta-tabel, der har en milliard rækker med salgsdata for en toårig periode. Selvom det er muligt at gemme alle dataene i et enkelt sæt Parquet-filer, er det for denne datamængde ikke optimalt til læse- og skrivehandlinger. Ydeevnen kan i stedet forbedres ved at sprede de milliarder rækker med data på tværs af flere serier af Parquet-filer.

Der skal defineres en partitionsnøgle, når du konfigurerer tabelpartitionering. Partitionsnøglen bestemmer, hvilke rækker der skal gemmes i hvilken serie. For Delta-tabeller kan partitionsnøglen defineres på baggrund af de entydige værdier for en angivet kolonne (eller kolonner), f.eks. en måned/år-kolonne i en datotabel. I dette tilfælde distribueres to års data på tværs af 24 partitioner (2 år x 12 måneder).

Fabric-beregningsprogrammer er ikke klar over tabelpartitioner. Når de indsætter nye partitionsnøgleværdier, oprettes der automatisk nye partitioner. I OneLake finder du én undermappe for hver entydig partitionsnøgleværdi, og hver undermappe gemmer sit eget sæt Parquet-filer og linkfiler. Der skal være mindst én Parquet-fil og én linkfil, men det faktiske antal filer i hver undermappe kan variere. Når dataændringshandlinger finder sted, bevarer hver partition sit eget sæt Parquet-filer og sammenkæder filer for at holde styr på, hvad der skal returneres for et givent tidsstempel eller en given version.

Hvis en forespørgsel i en partitioneret Delta-tabel filtreres til de seneste tre måneders salgsdata, kan undersættet af Parquet-filer og linkfiler, der skal tilgås, hurtigt identificeres. Det giver derefter mulighed for at springe mange Parquet-filer over, hvilket resulterer i bedre læseydeevne.

Forespørgsler, der ikke filtrerer på partitionsnøglen, fungerer muligvis ikke altid bedre. Det kan være tilfældet, når en Delta-tabel gemmer alle data i et enkelt stort sæt Parquet-filer, og der er fragmentering af fil- eller rækkegrupper. Selvom det er muligt at parallelisere datahentning fra flere Parquet-filer på tværs af flere klyngenoder, kan mange små Parquet-filer påvirke fil-I/O negativt og derfor forespørgselsydeevnen. Derfor er det bedst at undgå at partitionere Delta-tabeller i de fleste tilfælde – medmindre skrivehandlinger eller udtrække, transformere og indlæse processer (ETL) klart vil drage fordel af dem.

Partitionering af fordele indsætter, opdaterer og sletter også handlinger, fordi filaktivitet kun finder sted i undermapper, der svarer til partitionsnøglen for de ændrede eller slettede rækker. Hvis der f.eks. indsættes en batch af data i en partitioneret Delta-tabel, vurderes dataene for at bestemme, hvilke partitionsnøgleværdier der findes i batchen. Data dirigeres derefter kun til de relevante mapper for partitionerne.

Hvis du forstår, hvordan Delta-tabeller bruger partitioner, kan det hjælpe dig med at designe optimale ETL-scenarier, der reducerer de skrivehandlinger, der skal udføres, når du opdaterer store Delta-tabeller. Skriveydeevnen forbedres ved at reducere antallet og størrelsen af nye Parquet-filer, der skal oprettes. For en stor Delta-tabel, der er partitioneret efter måned/år, som beskrevet i det forrige eksempel, føjer nye data kun nye Parquet-filer til den seneste partition. Undermapper i tidligere kalendermåneder forbliver urørte. Hvis data fra tidligere kalendermåneder skal ændres, er det kun de relevante partitionsmapper, der modtager nye partitions- og linkfiler.

Vigtig

Hvis hovedformålet med en Delta-tabel er at fungere som en datakilde for semantiske modeller (og sekundært andre forespørgselsarbejdsbelastninger), er det normalt bedre at undgå partitionering i stedet for at optimere belastning af kolonner i hukommelsen.

For semantiske Direct Lake-modeller eller SQL Analytics-slutpunkter den bedste måde at optimere Delta-tabelpartitioner på, at Fabric automatisk kan administrere parquetfilerne for hver version af en Delta-tabel. Hvis du overlader administrationen til Fabric, bør det resultere i høj forespørgselsydeevne via parallelisering, men det giver muligvis ikke nødvendigvis den bedste skriveydeevne.

Hvis du skal optimere til skrivehandlinger, kan du overveje at bruge partitioner til at optimere skrivehandlinger til Delta-tabeller baseret på partitionsnøglen. Vær dog opmærksom på, at over partitionering af en Delta-tabel kan påvirke læseydeevnen negativt. Derfor anbefaler vi, at du tester læse- og skriveydeevnen omhyggeligt, måske ved at oprette flere kopier af den samme Delta-tabel med forskellige konfigurationer for at sammenligne tidsindstillinger.

Advarsel

Hvis du partitioneres på en kolonne med høj kardinalitet, kan det resultere i et stort antal parquetfiler. Vær opmærksom på, at alle Fabric-kapacitetslicenser har gelændere. Hvis antallet af Parquet-filer for en Delta-tabel overskrider grænsen for din SKU, vil forespørgsler falde tilbage til DirectQuery, hvilket kan resultere i langsommere forespørgselsydeevne.

Parquetfiler

Det underliggende lager for en Delta-tabel er en eller flere Parquet-filer. Parquet-filformat bruges generelt til skrive-én gang, læse-mange programmer. Nye Parquet-filer oprettes, hver gang data i en Delta-tabel ændres, uanset om det er ved at indsætte, opdatere eller slette.

Seddel

Du kan få adgang til Parquet-filer, der er knyttet til Delta-tabeller, ved hjælp af et værktøj, f.eks. OneLake-stifinder. Filer kan downloades, kopieres eller flyttes til andre destinationer lige så let som at flytte andre filer. Det er dog kombinationen af Parquet-filer og JSON-baserede linkfiler, der gør det muligt for beregningsprogrammer at udstede forespørgsler mod filerne som en Delta-tabel.

Parquetfilformat

Det interne format for en Parquet-fil adskiller sig fra andre almindelige datalagerformater, f.eks. CSV, TSV, XMLA og JSON. Disse formater organiserer data efter rækker, mens Parquet organiserer data efter kolonner. Parquet-filformatet adskiller sig også fra disse formater, fordi det organiserer rækker med data i en eller flere rækkegrupper.

Den interne datastruktur i en semantisk Power BI-model er kolonnebaseret, hvilket betyder, at Parquet-filer deler meget til fælles med Power BI. Denne lighed betyder, at en semantisk Direct Lake-model effektivt kan indlæse data fra Parquet-filerne direkte i hukommelsen. Faktisk kan meget store datamængder indlæses på få sekunder. Sammenlign denne funktion med opdateringen af en semantisk importmodel, som skal hente blokke eller kildedata og derefter behandle, kode, gemme og derefter indlæse den i hukommelsen. En opdateringshandling for en semantisk importmodel kan også forbruge betydelige mængder beregning (hukommelse og CPU) og tage lang tid at fuldføre. Men med Delta-tabeller udføres det meste af indsatsen for at forberede de data, der er egnede til direkte indlæsning i en semantisk model, når Parquet-filen genereres.

Sådan gemmer parquetfiler data

Overvej følgende eksempelsæt af data.

Dato Instruktion StockOnHand
2024-09-16 En 10
2024-09-16 B 11
2024-09-17 En 13
…

Når dette datasæt gemmes i Parquet-filformat, kan det se ud 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 at erstatte ordbogsnøgler med almindelige værdier og ved at anvende RLE (run-length encoding). RLE bestræber sig på at komprimere en serie af samme værdier til en mindre repræsentation. I følgende eksempel oprettes der en ordbogstilknytning af numeriske nøgler til værdier i overskriften, og de mindre nøgleværdier bruges i stedet for dataværdierne.

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 den semantiske Direct Lake-model skal bruge data til at beregne summen af kolonnen StockOnHand grupperet efter ProductID, kræves kun den ordbog og de data, der er knyttet til de to kolonner. I store filer, der indeholder mange kolonner, kan store dele af Parquet-filen springes over for at fremskynde læsningsprocessen.

Seddel

Indholdet af en Parquet-fil kan ikke læses af mennesker, så det er ikke egnet til at åbne i en teksteditor. Der er dog mange tilgængelige værktøjer med åben kildekode, der kan åbne og vise indholdet af en Parquet-fil. Med disse værktøjer kan du også undersøge metadata, f.eks. antallet af rækker og rækkegrupper i en fil.

V-rækkefølge

Fabric understøtter en yderligere optimering, der kaldes V-Order. V-Order er en skrivetidsoptimering til Parquet-filformatet. Når V-Order er anvendt, resulterer det i en mindre og derfor hurtigere fil at læse. Denne optimering er især relevant for en Semantisk Direct Lake-model, fordi den forbereder dataene til hurtig indlæsning i hukommelsen, og derfor stiller den mindre krav til kapacitetsressourcer. Det resulterer også i hurtigere forespørgselsydeevne, fordi der skal scannes mindre hukommelse.

Delta-tabeller, der er oprettet og indlæst af Fabric-elementer, f.eks. datapipelines, dataflowsog notesbøger automatisk anvende V-Order. Parquet-filer, der er uploadet til et Fabric lakehouse, eller som der refereres til af en genvej, har muligvis ikke anvendt denne optimering. Selvom ikke-optimerede Parquet-filer stadig kan læses, vil læseydeevnen sandsynligvis ikke være så hurtig som en tilsvarende Parquet-fil, hvor V-Order er anvendt.

Seddel

Parquet-filer, hvor V-Order er anvendt, er stadig i overensstemmelse med parquetfilformatet med åben kildekode. Derfor kan de læses af ikke-Fabric-værktøjer.

Du kan få flere oplysninger under Tabeloptimering af Delta Lake og V-Order.

Optimering af deltatabel

I dette afsnit beskrives forskellige emner til optimering af Delta-tabeller til semantiske modeller.

Datamængde

Selvom Delta-tabeller kan vokse for at lagre ekstremt store datamængder, Fabric-kapacitetsre gelændere indføre begrænsninger for semantiske modeller, der forespørger dem. Når disse grænser overskrides, vil forespørgsler falde tilbage til DirectQuery-, hvilket kan resultere i langsommere forespørgselsydeevne.

Overvej derfor at begrænse antallet af rækker i en stor faktatabel ved at øge granulariteten (lagrede opsummerede data), reducere dimensionalitet eller gemme mindre historik.

Sørg også for, at V-Order- anvendes, fordi det resulterer i en mindre og derfor hurtigere fil at læse.

Kolonnedatatype

Stræb efter at reducere kardinaliteten (antallet af entydige værdier) i hver kolonne i hver Delta-tabel. Det skyldes, at alle kolonner komprimeres og gemmes ved hjælp af hashkodning. Hashkodning kræver V-Order-optimering for at tildele et numerisk id til hver entydig værdi i kolonnen. Det er derefter det numeriske id, der er gemt, og som kræver et hashopslag under lagring og forespørgsel.

Når du bruger omtrentlige numeriske datatyper (f.eks. flydende og reelle), kan du overveje at afrunde værdier og bruge en lavere præcision.

Unødvendige kolonner

Som med alle datatabeller bør Delta-tabeller kun gemme de kolonner, der kræves. I forbindelse med denne artikel betyder det, at den semantiske model kræver det, selvom der kan være andre analysearbejdsbelastninger, der forespørger Delta-tabellerne.

Delta-tabeller skal indeholde kolonner, der kræves af den semantiske model til filtrering, gruppering, sortering og opsummering, ud over kolonner, der understøtter modelrelationer. Selvom unødvendige kolonner ikke påvirker forespørgselsydeevnen for semantiske modeller (fordi de ikke indlæses i hukommelsen), resulterer de i en større lagerstørrelse og kræver derfor flere beregningsressourcer at indlæse og vedligeholde.

Da semantiske Direct Lake-modeller ikke understøtter beregnede kolonner, skal du materialisere sådanne kolonner i Delta-tabellerne. Bemærk, at denne designtilgang er et antimønster for semantiske import- og DirectQuery-modeller. Hvis du f.eks. har FirstName og LastName kolonner, og du har brug for en FullName kolonne, skal du materialisere værdierne for denne kolonne, når du indsætter rækker i Delta-tabellen.

Overvej, at nogle semantiske modelopsummeringer kan afhænge af mere end én kolonne. Hvis du f.eks. vil beregne salg, opsummerer målingen i modellen produktet af to kolonner: Quantity og Price. Hvis ingen af disse kolonner bruges uafhængigt af hinanden, vil det være mere effektivt at materialisere salgsberegningen som en enkelt kolonne end at gemme komponentværdierne i separate kolonner.

Rækkegruppestørrelse

Internt organiserer en Parquet-fil rækker med data i flere rækkegrupper i hver fil. En Parquet-fil, der indeholder 30.000 rækker, kan f.eks. opdele dem i tre rækkegrupper, der hver har 10.000 rækker.

Antallet af rækker i en rækkegruppe påvirker, hvor hurtigt Direct Lake kan læse dataene. Et højere antal rækkegrupper med færre rækker vil sandsynligvis påvirke indlæsningen af kolonnedata i en semantisk model negativt på grund af overdreven I/O.

Generelt anbefaler vi ikke, at du ændrer standardstørrelsen for rækkegruppen. Du kan dog overveje at ændre rækkegruppens størrelse for store Delta-tabeller. Sørg for at teste læse- og skriveydeevnen omhyggeligt, måske ved at oprette flere kopier af de samme Delta-tabeller med forskellige konfigurationer for at sammenligne tidsindstillinger.

Vigtig

Vær opmærksom på, at alle Fabric-kapacitetslicenser har gelændere. Hvis antallet af rækkegrupper for en Delta-tabel overskrider grænsen for din SKU, vil forespørgsler falde tilbage til DirectQuery, hvilket kan resultere i langsommere forespørgselsydeevne.

Vedligeholdelse af deltatabel

Efterhånden som skrivehandlinger finder sted, akkumuleres Delta-tabelversioner. Til sidst kan du nå et punkt, hvor en negativ indvirkning på læseydeevnen bliver mærkbar. Værre er, at hvis antallet af Parquet-filer pr. tabel eller rækkegrupper pr. tabel eller rækker pr. tabel overskrider de gelændere for din kapacitet, vil forespørgsler falde tilbage til DirectQuery-, hvilket kan resultere i langsommere forespørgselsydeevne. Det er derfor vigtigt, at du vedligeholder Delta-tabeller regelmæssigt.

OPTIMERE

Du kan bruge OPTIMERE til at optimere en Delta-tabel for at samle mindre filer i større filer. Du kan også angive WHERE-delsætningen til kun at målrette et filtreret undersæt af rækker, der svarer til et givent partitions prædikat. Det er kun filtre, der omfatter partitionsnøgler, der understøttes. Kommandoen OPTIMIZE kan også anvende V-Order til at komprimere og omskrive Parquet-filerne.

Vi anbefaler, at du kører denne kommando på store, ofte opdaterede Delta-tabeller med jævne mellemrum, måske hver dag, når DITL-processen er fuldført. Afvej afvejninger mellem bedre forespørgselsydeevne og omkostningerne ved ressourceforbrug, der kræves for at optimere tabellen.

VAKUUM

Du kan bruge VACUUM- til at fjerne filer, der ikke længere refereres til, og/eller som er ældre end en angivet opbevaringsgrænse. Vær opmærksom på at angive en passende opbevaringsperiode, ellers kan du miste muligheden for at tidsrejse tilbage til en version, der er ældre end rammen, der er stemplet i semantiske modeltabeller.

Vigtig

Da en indrammet semantisk model refererer til en bestemt Delta-tabelversion, skal kilden sikre, at deltatabelversionen bevares, indtil udformningen af en ny version er fuldført. Ellers vil brugerne støde på fejl, når modellen skal have adgang til Delta-tabelfilerne, og de er blevet støvsuget eller på anden måde slettet af producentens arbejdsbelastning.

REORG-TABEL

Du kan bruge REORG TABLE- til at omorganisere en Delta-tabel ved at omskrive filer for at fjerne bløde slettede data, f.eks. når du slipper en kolonne ved hjælp af ALTER TABLE DROP COLUMN.

Automatiser tabelvedligeholdelse

Hvis du vil automatisere tabelvedligeholdelseshandlinger, kan du bruge Lakehouse-API'en. Du kan få flere oplysninger under Administrer Lakehouse med Microsoft Fabric REST API-.

Drikkepenge

Du kan også bruge lakehouse-funktionen Til vedligeholdelse af tabeller på Fabric-portalen til at forenkle administrationen af dine Delta-tabeller.

Relateret indhold