Förstå lagring för Direct Lake-semantiska modeller
Den här artikeln beskriver begrepp för Direct Lake-lagring . Den beskriver Delta-tabeller och Parquet-filer. Den beskriver också hur du kan optimera Delta-tabeller för Direct Lake-semantiska modeller och hur du kan underhålla dem för att leverera tillförlitliga, snabba frågeprestanda.
Deltatabeller
Deltatabeller finns i OneLake. De organiserar filbaserade data i rader och kolumner och är tillgängliga för Microsoft Fabric-beräkningsmotorer som notebook-filer, Kusto och lakehouse och lager. Du kan köra frågor mot Delta-tabeller med dataanalysuttryck (DAX), flerdimensionella uttryck (MDX), T-SQL (Transact-SQL), Spark SQL och till och med Python.
Kommentar
Delta – eller Delta Lake – är ett lagringsformat med öppen källkod. Det innebär att Fabric också kan fråga Delta-tabeller som skapats av andra verktyg och leverantörer.
Deltatabeller lagrar sina data i Parquet-filer, som vanligtvis lagras i ett sjöhus som en Direct Lake-semantisk modell använder för att läsa in data. Parquet-filer kan dock också lagras externt. Externa Parquet-filer kan refereras med hjälp av en OneLake-genväg som pekar på en specifik lagringsplats, till exempel Azure Data Lake Storage (ADLS) Gen2, Amazon S3-lagringskonton eller Dataverse. I nästan alla fall har beräkningsmotorer åtkomst till Parquet-filerna genom att köra frågor mot Delta-tabeller. Men vanligtvis läser Direct Lake-semantiska modeller in kolumndata direkt från optimerade Parquet-filer i OneLake med hjälp av en process som kallas transkodning.
Versionshantering av data
Deltatabeller består av en eller flera Parquet-filer. Dessa filer åtföljs av en uppsättning JSON-baserade länkfiler som spårar ordningen och arten för varje Parquet-fil som är associerad med en Delta-tabell.
Det är viktigt att förstå att de underliggande Parquet-filerna är inkrementella till sin natur. Därav namnet Delta som en referens till inkrementell dataändring. Varje gång en skrivåtgärd till en Delta-tabell äger rum, till exempel när data infogas, uppdateras eller tas bort, skapas nya Parquet-filer som representerar dataändringarna som en version. Parquet-filer är därför oföränderliga, vilket innebär att de aldrig ändras. Det är därför möjligt att duplicera data många gånger i en uppsättning Parquet-filer för en Delta-tabell. Delta-ramverket förlitar sig på länkfiler för att avgöra vilka fysiska Parquet-filer som krävs för att skapa rätt frågeresultat.
Tänk dig ett enkelt exempel på en Delta-tabell som används i den här artikeln för att förklara olika åtgärder för dataändring. Tabellen har två kolumner och lagrar tre rader.
| ProductID | StockOnHand |
|---|---|
| A | 1 |
| F | 2 |
| C | 3 |
Delta-tabelldata lagras i en enskild Parquet-fil som innehåller alla data, och det finns en enda länkfil som innehåller metadata om när data infogades (läggs till).
- Parquet-fil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Länkfil 1:
- Innehåller tidsstämpeln när
Parquet file 1den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
Infoga åtgärder
Tänk på vad som händer när en infogningsåtgärd inträffar: En ny rad för produkten C med lagervärdet 4 infogas. De här åtgärderna resulterar i skapandet av en ny Parquet-fil och länkfil, så det finns nu två Parquet-filer och två länkfiler.
- Parquet-fil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parquet-fil 2:
- ProductID: D
- StockOnHand: 4
- Länkfil 1:
- Innehåller tidsstämpeln när
Parquet file 1den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
- Länkfil 2:
- Innehåller tidsstämpeln när
Parquet file 2den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
I det här läget returnerar en fråga i Delta-tabellen följande resultat. Det spelar ingen roll att resultatet kommer från flera Parquet-filer.
| ProductID | StockOnHand |
|---|---|
| A | 1 |
| F | 2 |
| C | 3 |
| D | 4 |
Varje efterföljande infogningsåtgärd skapar nya Parquet-filer och länkfiler. Det innebär att antalet Parquet-filer och länkfiler växer med varje infogningsåtgärd.
Uppdateringsåtgärder
Tänk nu på vad som händer när en uppdateringsåtgärd inträffar: Raden för produkten D har sitt lager på lagervärdet ändrat till 10. De här åtgärderna resulterar i skapandet av en ny Parquet-fil och länkfil, så det finns nu tre Parquet-filer och tre länkfiler.
- Parquet-fil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parquet-fil 2:
- ProductID: D
- StockOnHand: 4
- Parquet-fil 3:
- ProductID: C
- StockOnHand: 10
- Länkfil 1:
- Innehåller tidsstämpeln när
Parquet file 1den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
- Länkfil 2:
- Innehåller tidsstämpeln när
Parquet file 2den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
- Länkfil 3:
- Innehåller tidsstämpeln när
Parquet file 3den skapades och registrerar att data uppdaterades.
- Innehåller tidsstämpeln när
I det här läget returnerar en fråga i Delta-tabellen följande resultat.
| ProductID | StockOnHand |
|---|---|
| A | 1 |
| F | 2 |
| C | 10 |
| D | 4 |
Data för produkten C finns nu i flera Parquet-filer. Frågor till Delta-tabellen kombinerar dock länkfilerna för att avgöra vilka data som ska användas för att ge rätt resultat.
Borttagningsåtgärder
Tänk nu på vad som händer när en borttagningsåtgärd inträffar: Raden för produkten B tas bort. Den här åtgärden resulterar i en ny Parquet-fil och länkfil, så det finns nu fyra Parquet-filer och fyra länkfiler.
- Parquet-fil 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
- Parquet-fil 2:
- ProductID: D
- StockOnHand: 4
- Parquet-fil 3:
- ProductID: C
- StockOnHand: 10
- Parquet-fil 4:
- ProductID: A, C, D
- StockOnHand: 1, 10, 4
- Länkfil 1:
- Innehåller tidsstämpeln när
Parquet file 1den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
- Länkfil 2:
- Innehåller tidsstämpeln när
Parquet file 2den skapades och registrerar att data lades till.
- Innehåller tidsstämpeln när
- Länkfil 3:
- Innehåller tidsstämpeln när
Parquet file 3den skapades och registrerar att data uppdaterades.
- Innehåller tidsstämpeln när
- Länkfil 4:
- Innehåller tidsstämpeln när
Parquet file 4den skapades och registrerar att data har tagits bort.
- Innehåller tidsstämpeln när
Observera att Parquet file 4 inte längre innehåller data för produkten B, men den innehåller data för alla andra rader i tabellen.
I det här läget returnerar en fråga i Delta-tabellen följande resultat.
| ProductID | StockOnHand |
|---|---|
| A | 1 |
| C | 10 |
| D | 4 |
Kommentar
Det här exemplet är enkelt eftersom det omfattar en liten tabell, bara några få åtgärder och endast mindre ändringar. Stora tabeller som har många skrivåtgärder och som innehåller många rader med data genererar mer än en Parquet-fil per version.
Viktigt!
Beroende på hur du definierar deltatabellerna och frekvensen för dataändringsåtgärder kan det resultera i många Parquet-filer. Tänk på att varje infrastrukturkapacitetslicens har skyddsräcken. Om antalet Parquet-filer för en Delta-tabell överskrider gränsen för din SKU kommer frågorna att återgå till DirectQuery, vilket kan leda till långsammare frågeprestanda.
Information om hur du hanterar antalet Parquet-filer finns i Delta-tabellunderhåll senare i den här artikeln.
Deltatidsresor
Länkfiler aktiverar frågedata från och med en tidigare tidpunkt. Den här funktionen kallas deltatidsresor. Den tidigare tidpunkten kan vara en tidsstämpel eller version.
Tänk på följande frågeexempel.
SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;
Dricks
Du kan också köra frågor mot en tabell med hjälp @ av den korta syntaxen för att ange tidsstämpeln eller versionen som en del av tabellnamnet. Tidsstämpeln måste vara i yyyyMMddHHmmssSSS format. Du kan ange en version efter @ genom att lägga till en v till versionen.
Här är de tidigare frågeexemplen som skrivits om med kortsyntax.
SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;
Viktigt!
Tabellversioner som är tillgängliga med tidsresor bestäms av en kombination av kvarhållningströskelvärdet för transaktionsloggfiler och frekvensen och den angivna kvarhållningen för VACUUM-åtgärder (beskrivs senare i avsnittet deltatabellunderhåll ). Om du kör VACUUM dagligen med standardvärdena blir sju dagars data tillgängliga för tidsresor.
Inramning
Inramning är en Direct Lake-åtgärd som anger den version av en Delta-tabell som ska användas för att läsa in data i en semantisk modellkolumn. Lika viktigt är att versionen också avgör vad som ska undantas när data läses in.
En inramningsåtgärd stämplar tidsstämpeln/versionen av varje Delta-tabell i semantiska modelltabeller. När semantikmodellen behöver läsa in data från en Delta-tabell används tidsstämpeln/versionen som är associerad med den senaste inramningsåtgärden för att avgöra vilka data som ska läsas in. Eventuella efterföljande dataändringar som inträffar för Delta-tabellen sedan den senaste inramningsåtgärden ignoreras (fram till nästa inramningsåtgärd).
Viktigt!
Eftersom en inramad semantisk modell refererar till en viss Delta-tabellversion måste källan se till att den behåller deltatabellversionen tills inramningen av en ny version har slutförts. Annars får användarna fel när Delta-tabellfilerna måste nås av modellen och har dammsugits eller på annat sätt tagits bort av producentarbetsbelastningen.
Mer information om inramning finns i Översikt över Direct Lake.
Table partitioning (Tabellpartitionering)
Deltatabeller kan partitioneras så att en delmängd rader lagras tillsammans i en enda uppsättning Parquet-filer. Partitioner kan påskynda frågor och skrivåtgärder.
Överväg en Delta-tabell som har en miljard rader med försäljningsdata för en tvåårsperiod. Det är möjligt att lagra alla data i en enda uppsättning Parquet-filer, men för den här datavolymen är det inte optimalt för läs- och skrivåtgärder. I stället kan prestanda förbättras genom att sprida miljarder rader med data över flera serier parquet-filer.
En partitionsnyckel måste definieras när du konfigurerar tabellpartitionering. Partitionsnyckeln avgör vilka rader som ska lagras i vilken serie. För Delta-tabeller kan partitionsnyckeln definieras baserat på distinkta värden för en angiven kolumn (eller kolumner), till exempel en månad/år-kolumn i en datumtabell. I det här fallet skulle två års data distribueras över 24 partitioner (2 år x 12 månader).
Infrastrukturberäkningsmotorer känner inte till tabellpartitioner. När de infogar nya partitionsnyckelvärden skapas nya partitioner automatiskt. I OneLake hittar du en undermapp för varje unikt partitionsnyckelvärde, och varje undermapp lagrar sin egen uppsättning Parquet-filer och länkfiler. Minst en Parquet-fil och en länkfil måste finnas, men det faktiska antalet filer i varje undermapp kan variera. När datamodifieringsåtgärder utförs behåller varje partition sin egen uppsättning Parquet-filer och länkfiler för att hålla reda på vad som ska returneras för en viss tidsstämpel eller version.
Om en fråga i en partitionerad Delta-tabell filtreras till endast de senaste tre månadernas försäljningsdata kan delmängden av Parquet-filer och länkfiler som behöver nås snabbt identifieras. Då kan du hoppa över många Parquet-filer helt och hållet, vilket ger bättre läsprestanda.
Men frågor som inte filtrerar på partitionsnyckeln kanske inte alltid fungerar bättre. Det kan vara fallet när en Delta-tabell lagrar alla data i en enda stor uppsättning Parquet-filer och det finns fragmentering av fil- eller radgrupper. Även om det är möjligt att parallellisera datahämtningen från flera Parquet-filer över flera klusternoder, kan många små Parquet-filer påverka fil-I/O negativt och därmed frågeprestanda. Därför är det bäst att undvika partitionering av Delta-tabeller i de flesta fall, såvida inte ETL-processer (write operations or extract, transform, and load) (ETL) skulle dra nytta av det.
Partitioneringsfördelar infogar, uppdaterar och tar bort åtgärder också, eftersom filaktiviteten endast sker i undermappar som matchar partitionsnyckeln för de ändrade eller borttagna raderna. Om till exempel en batch med data infogas i en partitionerad Delta-tabell utvärderas data för att avgöra vilka partitionsnyckelvärden som finns i batchen. Data dirigeras sedan endast till relevanta mappar för partitionerna.
Att förstå hur Delta-tabeller använder partitioner kan hjälpa dig att utforma optimala ETL-scenarier som minskar de skrivåtgärder som måste utföras när du uppdaterar stora Delta-tabeller. Skrivprestanda förbättras genom att minska antalet och storleken på alla nya Parquet-filer som måste skapas. För en stor Delta-tabell partitionerad efter månad/år, enligt beskrivningen i föregående exempel, lägger nya data bara till nya Parquet-filer till den senaste partitionen. Undermappar för tidigare kalendermånader förblir orörda. Om data från tidigare kalendermånader måste ändras får endast relevanta partitionsmappar nya partitions- och länkfiler.
Viktigt!
Om huvudsyftet med en Delta-tabell är att fungera som datakälla för semantiska modeller (och i andra hand andra frågearbetsbelastningar) är det vanligtvis bättre att undvika partitionering i stället för att optimera belastningen på kolumner i minnet.
För Direct Lake-semantiska modeller eller SQL-analysslutpunkten är det bästa sättet att optimera Delta-tabellpartitioner att låta Fabric automatiskt hantera Parquet-filerna för varje version av en Delta-tabell. Att lämna hanteringen till Infrastrukturresurser bör resultera i höga frågeprestanda genom parallellisering, men det kanske inte nödvändigtvis ger bästa skrivprestanda.
Om du måste optimera för skrivåtgärder bör du överväga att använda partitioner för att optimera skrivåtgärder till Delta-tabeller baserat på partitionsnyckeln. Tänk dock på att över partitionering av en Delta-tabell kan påverka läsprestanda negativt. Därför rekommenderar vi att du testar läs- och skrivprestanda noggrant, kanske genom att skapa flera kopior av samma Delta-tabell med olika konfigurationer för att jämföra tidsinställningar.
Varning
Om du partitionera på en kolumn med hög kardinalitet kan det resultera i ett stort antal Parquet-filer. Tänk på att varje fabric-kapacitetslicens har skyddsräcken. Om antalet Parquet-filer för en Delta-tabell överskrider gränsen för din SKU kommer frågorna att återgå till DirectQuery, vilket kan leda till långsammare frågeprestanda.
Parquet-filer
Den underliggande lagringen för en Delta-tabell är en eller flera Parquet-filer. Parquet-filformat används vanligtvis för skriv-en gång, read-many-program . Nya Parquet-filer skapas varje gång data i en Delta-tabell ändras, antingen genom en infognings-, uppdaterings- eller borttagningsåtgärd.
Kommentar
Du kan komma åt Parquet-filer som är associerade med Delta-tabeller med hjälp av ett verktyg, till exempel OneLake-utforskaren. Filer kan laddas ned, kopieras eller flyttas till andra mål lika enkelt som att flytta andra filer. Det är dock kombinationen av Parquet-filer och JSON-baserade länkfiler som gör det möjligt för beräkningsmotorer att utfärda frågor mot filerna som en Delta-tabell.
Parquet-filformat
Det interna formatet för en Parquet-fil skiljer sig från andra vanliga datalagringsformat, till exempel CSV, TSV, XMLA och JSON. Dessa format organiserar data efter rader, medan Parquet organiserar data efter kolumner. Dessutom skiljer sig Parquet-filformatet från dessa format eftersom det organiserar rader med data i en eller flera radgrupper.
Den interna datastrukturen för en Power BI-semantisk modell är kolumnbaserad, vilket innebär att Parquet-filer delar mycket gemensamt med Power BI. Den här likheten innebär att en Semantisk Direct Lake-modell effektivt kan läsa in data från Parquet-filerna direkt till minnet. I själva verket kan mycket stora mängder data läsas in på några sekunder. Kontrastera den här funktionen med uppdateringen av en importsemantisk modell som måste hämta block eller källdata, sedan bearbeta, koda, lagra och sedan läsa in den i minnet. En import-semantisk modelluppdateringsåtgärd kan också förbruka stora mängder beräkning (minne och CPU) och ta lång tid att slutföra. Men med Delta-tabeller utförs det mesta av arbetet med att förbereda data som är lämpliga för direkt inläsning till en semantisk modell när Parquet-filen genereras.
Hur Parquet-filer lagrar data
Överväg följande exempeluppsättning med data.
| Datum | ProductID | StockOnHand |
|---|---|---|
| 2024-09-16 | A | 10 |
| 2024-09-16 | F | 11 |
| 2024-09-17 | A | 13 |
| … |
När de lagras i Parquet-filformat kan den här uppsättningen data se ut som följande text.
Header:
RowGroup1:
Date: 2024-09-16, 2024-09-16, 2024-09-17…
ProductID: A, B, A…
StockOnHand: 10, 11, 13…
RowGroup2:
…
Footer:
Data komprimeras genom att ordlistenycklar ersätts med vanliga värden och genom att run-length-kodning (RLE) tillämpas. RLE strävar efter att komprimera en serie med samma värden till en mindre representation. I följande exempel skapas en ordlistemappning av numeriska nycklar till värden i rubriken och de mindre nyckelvärdena används i stället för datavärdena.
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 Direct Lake-semantikmodellen behöver data för att beräkna summan av StockOnHand kolumnen grupperad efter ProductIDkrävs endast ordlistan och data som är associerade med de två kolumnerna. I stora filer som innehåller många kolumner kan stora delar av Parquet-filen hoppas över för att påskynda läsprocessen.
Kommentar
Innehållet i en Parquet-fil är inte läsbart för människor och passar därför inte för att öppna i en textredigerare. Det finns dock många tillgängliga verktyg med öppen källkod som kan öppna och avslöja innehållet i en Parquet-fil. Med de här verktygen kan du också granska metadata, till exempel antalet rader och radgrupper som finns i en fil.
V-order
Fabric stöder ytterligare en optimering som kallas V-Order. V-Order är en skrivtidsoptimering till Parquet-filformatet. När V-order har tillämpats resulterar det i en mindre och därför snabbare fil att läsa. Den här optimeringen är särskilt relevant för en Direct Lake-semantisk modell eftersom den förbereder data för snabb inläsning i minnet, och därför ställer mindre krav på kapacitetsresurser. Det resulterar också i snabbare frågeprestanda eftersom mindre minne behöver genomsökas.
Deltatabeller som skapats och lästs in av infrastrukturresurser som datapipelines, dataflöden och notebook-filer tillämpar automatiskt V-Order. Parquet-filer som laddats upp till en Infrastruktursjöhus, eller som refereras till av en genväg, kanske inte har den här optimeringen tillämpad. Även om icke-optimerade Parquet-filer fortfarande kan läsas, kommer läsprestanda sannolikt inte att vara lika snabba som en motsvarande Parquet-fil som har tillämpat V-Order.
Kommentar
Parquet-filer som har V-Order tillämpad överensstämmer fortfarande med Parquet-filformatet med öppen källkod. Därför kan de läsas av icke-Infrastrukturverktyg.
Mer information finns i Delta Lake-tabelloptimering och V-order.
Deltatabelloptimering
I det här avsnittet beskrivs olika ämnen för att optimera Delta-tabeller för semantiska modeller.
Datavolym
Delta-tabeller kan växa för att lagra extremt stora datavolymer, men skyddsräcken för infrastrukturkapacitet begränsar semantiska modeller som frågar dem. När dessa gränser överskrids återgår frågorna till DirectQuery, vilket kan leda till långsammare frågeprestanda.
Överväg därför att begränsa antalet rader i en stor faktatabell genom att öka dess kornighet (lagra sammanfattade data), minska dimensionaliteten eller lagra mindre historik.
Kontrollera också att V-Order tillämpas eftersom det resulterar i en mindre och därför snabbare fil att läsa.
Kolumndatatyper
Sträva efter att minska kardinaliteten (antalet unika värden) i varje kolumn i varje Delta-tabell. Det beror på att alla kolumner komprimeras och lagras med hash-kodning. Hash-kodning kräver V-Order-optimering för att tilldela en numerisk identifierare till varje unikt värde i kolumnen. Det är den numeriska identifieraren som sedan lagras, som kräver en hash-sökning under lagring och frågor.
När du använder ungefärliga numeriska datatyper (till exempel flyttal och verkliga) bör du överväga att avrunda värden och använda en lägre precision.
Onödiga kolumner
Precis som med alla datatabeller bör Delta-tabeller endast lagra kolumner som krävs. I den här artikeln innebär det att det krävs av den semantiska modellen, även om det kan finnas andra analytiska arbetsbelastningar som kör frågor mot Delta-tabellerna.
Deltatabeller bör innehålla kolumner som krävs av den semantiska modellen för filtrering, gruppering, sortering och sammanfattning, förutom kolumner som stöder modellrelationer. Även om onödiga kolumner inte påverkar semantisk modell frågeprestanda (eftersom de inte läses in i minnet), resulterar de i en större lagringsstorlek och kräver därför fler beräkningsresurser för att läsa in och underhålla.
Eftersom Direct Lake-semantiska modeller inte stöder beräknade kolumner bör du materialisera sådana kolumner i Delta-tabellerna. Observera att den här designmetoden är ett antimönster för import- och DirectQuery-semantiska modeller. Om du till exempel har FirstName och LastName kolumner, och du behöver en FullName kolumn, materialiserar du värdena för den här kolumnen när du infogar rader i Delta-tabellen.
Tänk på att vissa semantiska modellsammanfattningar kan bero på mer än en kolumn. Om du till exempel vill beräkna försäljningen summerar måttet i modellen produkten med två kolumner: Quantity och Price. Om ingen av dessa kolumner används oberoende av varandra skulle det vara mer effektivt att materialisera försäljningsberäkningen som en enda kolumn än att lagra dess komponentvärden i separata kolumner.
Radgruppsstorlek
Internt ordnar en Parquet-fil rader med data i flera radgrupper i varje fil. Till exempel kan en Parquet-fil som innehåller 30 000 rader dela upp dem i tre radgrupper, där var och en har 10 000 rader.
Antalet rader i en radgrupp påverkar hur snabbt Direct Lake kan läsa data. Ett högre antal radgrupper med färre rader kommer sannolikt att påverka inläsningen av kolumndata till en semantisk modell negativt på grund av överdriven I/O.
I allmänhet rekommenderar vi inte att du ändrar standardstorleken för radgrupper. Du kan dock överväga att ändra radgruppens storlek för stora Delta-tabeller. Se till att testa läs- och skrivprestanda noggrant, kanske genom att skapa flera kopior av samma Delta-tabeller med olika konfigurationer för att jämföra tidsinställningar.
Viktigt!
Tänk på att varje fabric-kapacitetslicens har skyddsräcken. Om antalet radgrupper för en Delta-tabell överskrider gränsen för din SKU, återgår frågorna till DirectQuery, vilket kan leda till långsammare frågeprestanda.
Underhåll av deltatabeller
När skrivåtgärder utförs ackumuleras Delta-tabellversioner med tiden. Så småningom kan du nå en punkt där en negativ inverkan på läsprestanda blir märkbar. Värre är att om antalet Parquet-filer per tabell eller radgrupper per tabell eller rader per tabell överskrider skyddsräckena för din kapacitet, återgår frågorna till DirectQuery, vilket kan leda till långsammare frågeprestanda. Därför är det viktigt att du underhåller Delta-tabeller regelbundet.
OPTIMIZE
Du kan använda OPTIMIZE för att optimera en Delta-tabell för att samla mindre filer i större. Du kan också ange WHERE att satsen endast ska rikta in sig på en filtrerad delmängd rader som matchar ett visst partitionspredikat. Endast filter som involverar partitionsnycklar stöds. Kommandot OPTIMIZE kan också använda V-Order för att komprimera och skriva om Parquet-filerna.
Vi rekommenderar att du kör det här kommandot på stora, ofta uppdaterade Delta-tabeller regelbundet, kanske varje dag när ETL-processen är klar. Balansera kompromissen mellan bättre frågeprestanda och kostnaden för resursanvändning som krävs för att optimera tabellen.
VACUUM
Du kan använda VACUUM för att ta bort filer som inte längre refereras till och/eller som är äldre än ett angivet tröskelvärde för kvarhållning. Var noga med att ange en lämplig kvarhållningsperiod, annars kan du förlora möjligheten att tidsfördriva tillbaka till en version som är äldre än ramen som stämplas i semantiska modelltabeller.
Viktigt!
Eftersom en inramad semantisk modell refererar till en viss Delta-tabellversion måste källan se till att den behåller deltatabellversionen tills inramningen av en ny version har slutförts. Annars får användarna fel när Delta-tabellfilerna måste nås av modellen och har dammsugits eller på annat sätt tagits bort av producentarbetsbelastningen.
REORG-TABELL
Du kan använda REORG TABLE för att ordna om en Delta-tabell genom att skriva om filer för att rensa mjukt borttagna data, till exempel när du släpper en kolumn med hjälp av ALTER TABLE DROP COLUMN.
Automatisera tabellunderhåll
Om du vill automatisera tabellunderhållsåtgärder kan du använda Lakehouse-API:et. Mer information finns i Hantera Lakehouse med Microsoft Fabric REST API.
Dricks
Du kan också använda underhållsfunktionen lakehouse Table i Infrastrukturportalen för att förenkla hanteringen av deltatabellerna.