Delen via

Inzicht in opslag voor semantische Direct Lake-modellen

  • Artikel

In dit artikel worden Direct Lake-opslagconcepten geïntroduceerd. Hierin worden Delta-tabellen en Parquet-bestanden beschreven. Ook wordt beschreven hoe u Delta-tabellen voor semantische Direct Lake-modellen kunt optimaliseren en hoe u deze kunt onderhouden om betrouwbare, snelle queryprestaties te leveren.

Delta-tabellen

Delta-tabellen bestaan in OneLake. Ze organiseren gegevens op basis van bestanden in rijen en kolommen en zijn beschikbaar voor Microsoft Fabric-rekenprogramma's zoals notebooks, Kusto-en de lakehouse- en warehouse-. U kunt query's uitvoeren op Delta-tabellen met behulp van DAX (Data Analysis Expressions), Multidimensional Expressions (MDX), T-SQL (Transact-SQL), Spark SQL en zelfs Python.

Notitie

Delta, of Delta Lake, is een opensource-opslagindeling. Dat betekent dat Fabric ook query's kan uitvoeren op Delta-tabellen die zijn gemaakt door andere hulpprogramma's en leveranciers.

Delta-tabellen slaan hun gegevens op in Parquet-bestanden, die doorgaans worden opgeslagen in een lakehouse dat door een semantisch Direct Lake-model wordt gebruikt om gegevens te laden. Parquet-bestanden kunnen echter ook extern worden opgeslagen. Er kan naar externe Parquet-bestanden worden verwezen met behulp van een OneLake-snelkoppeling, die verwijst naar een specifieke opslaglocatie, zoals Azure Data Lake Storage (ADLS) Gen2, Amazon S3-opslagaccounts of Dataverse-. In bijna alle gevallen hebben rekenprogramma's toegang tot de Parquet-bestanden door een query uit te voeren op Delta-tabellen. Semantische Direct Lake-modellen laden echter meestal kolomgegevens rechtstreeks vanuit geoptimaliseerde Parquet-bestanden in OneLake met behulp van een proces dat bekend staat als transcodering.

Gegevensversiebeheer

Delta-tabellen bestaan uit een of meer Parquet-bestanden. Deze bestanden worden vergezeld van een set op JSON gebaseerde koppelingsbestanden, die de volgorde en aard van elk Parquet-bestand bijhouden dat is gekoppeld aan een Delta-tabel.

Het is belangrijk om te begrijpen dat de onderliggende Parquet-bestanden incrementeel van aard zijn. Vandaar de naam Delta als verwijzing naar incrementele gegevenswijziging. Telkens wanneer een schrijfbewerking naar een Delta-tabel plaatsvindt, zoals wanneer gegevens worden ingevoegd, bijgewerkt of verwijderd, worden nieuwe Parquet-bestanden gemaakt die de gegevenswijzigingen weergeven als een versie. Parquet-bestanden zijn daarom onveranderbare, wat betekent dat ze nooit worden gewijzigd. Het is daarom mogelijk dat gegevens vaak worden gedupliceerd in een set Parquet-bestanden voor een Delta-tabel. Het Delta-framework is afhankelijk van koppelingsbestanden om te bepalen welke fysieke Parquet-bestanden nodig zijn om het juiste queryresultaat te produceren.

Bekijk een eenvoudig voorbeeld van een Delta-tabel die in dit artikel wordt gebruikt om verschillende bewerkingen voor gegevenswijziging uit te leggen. De tabel heeft twee kolommen en slaat drie rijen op.

Product-ID StockOnHand
Een 1
B 2
C 3

De Delta-tabelgegevens worden opgeslagen in één Parquet-bestand dat alle gegevens bevat en er is één koppelingsbestand met metagegevens over wanneer de gegevens zijn ingevoegd (toegevoegd).

  • Parquet-bestand 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Koppelingsbestand 1:
    • Bevat de tijdstempel waarop Parquet file 1 is gemaakt en noteert dat gegevens zijn toegevoegd.

Bewerkingen invoegen

Bedenk wat er gebeurt wanneer een invoegbewerking plaatsvindt: er wordt een nieuwe rij voor product C met een voorraad op voorraad van 4 ingevoegd. Deze bewerkingen resulteert in het maken van een nieuw Parquet-bestand en koppelingsbestand, dus er zijn nu twee Parquet-bestanden en twee koppelingsbestanden.

  • Parquet-bestand 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-bestand 2:
    • product-id: D
    • StockOnHand: 4
  • Linkbestand 1:
    • Bevat de tijdstempel waarop Parquet file 1 is gemaakt, en registreert dat gegevens zijn toegevoegd.
  • Linkbestand 2:
    • Bevat de tijdstempel waarop Parquet file 2 is gemaakt en registreert dat er gegevens zijn toegevoegd.

Op dit moment retourneert een query van de Delta-tabel het volgende resultaat. Het maakt niet uit dat het resultaat afkomstig is van meerdere Parquet-bestanden.

ProductID StockOnHand
Een 1
B 2
C 3
D 4

Elke volgende invoegbewerking maakt nieuwe Parquet-bestanden en koppelbestanden. Dat betekent dat het aantal Parquet-bestanden en koppelingsbestanden groeit met elke invoegbewerking.

Updatebewerkingen

Bedenk nu wat er gebeurt wanneer een updatebewerking plaatsvindt: de voorraadwaarde van de rij voor product D wordt gewijzigd in 10. Deze bewerkingen resulteert in het maken van een nieuw Parquet-bestand en koppelingsbestand, dus er zijn nu drie Parquet-bestanden en drie koppelingsbestanden.

  • Parquet-bestand 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-bestand 2:
    • product-id: D
    • StockOnHand: 4
  • Parquet-bestand 3:
    • ProductID-: C
    • StockOnHand: 10
  • Linkbestand 1:
    • Bevat de tijdstempel waarop Parquet file 1 is gemaakt en registreert dat gegevens zijn toegevoegd.
  • Linkbestand 2:
    • Bevat de tijdstempel waarop Parquet file 2 is gemaakt en registreert dat gegevens zijn toegevoegd.
  • Koppelingsbestand 3:
    • Bevat de tijdstempel waarop Parquet file 3 is gemaakt en registreert dat de gegevens zijn bijgewerkt.

Op dit moment retourneert een query van de Delta-tabel het volgende resultaat.

ProductID StockOnHand
Een 1
B 2
C 10
D 4

Gegevens voor product C bestaan nu in meerdere Parquet-bestanden. Query's in de Delta-tabel combineren echter de koppelingsbestanden om te bepalen welke gegevens moeten worden gebruikt om het juiste resultaat te bieden.

Verwijderingsbewerkingen

Bedenk nu wat er gebeurt wanneer er een verwijderbewerking plaatsvindt: de rij voor product B wordt verwijderd. Deze bewerking resulteert in een nieuw Parquet-bestand en koppelingsbestand, dus er zijn nu vier Parquet-bestanden en vier koppelingsbestanden.

  • Parquet-bestand 1:
    • ProductID: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet-bestand 2:
    • product-id: D
    • StockOnHand: 4
  • Parquet-bestand 3:
    • ProductID: C
    • VoorraadBeschikbaar: 10
  • Parquet-bestand 4:
    • product-id: A, C, D
    • StockOnHand: 1, 10, 4
  • Linkbestand 1:
    • Bevat de tijdstempel waarop Parquet file 1 is gemaakt en registreert dat gegevens zijn toegevoegd.
  • Linkbestand 2:
    • Bevat de tijdstempel waarop Parquet file 2 is gemaakt, en registreert dat gegevens zijn toegevoegd.
  • Linkbestand 3:
    • Bevat de tijdstempel waarop Parquet file 3 is gemaakt en registreert dat de gegevens zijn bijgewerkt.
  • Koppelingsbestand 4:
    • Bevat de tijdstempel waarop Parquet file 4 is gemaakt en registreert dat gegevens zijn verwijderd.

U ziet dat Parquet file 4 geen gegevens meer bevat voor product B, maar wel gegevens bevat voor alle andere rijen in de tabel.

Op dit moment retourneert een query van de Delta-tabel het volgende resultaat.

Product-id StockOnHand
Een 1
C 10
D 4

Notitie

Dit voorbeeld is eenvoudig omdat het gaat om een kleine tabel, slechts een paar bewerkingen en slechts kleine wijzigingen. Grote tabellen met veel schrijfbewerkingen en die veel rijen met gegevens bevatten, genereren meer dan één Parquet-bestand per versie.

Belangrijk

Afhankelijk van hoe u uw Delta-tabellen en de frequentie van bewerkingen voor het wijzigen van gegevens definieert, kan dit leiden tot veel Parquet-bestanden. Houd er rekening mee dat elke Fabric-capaciteitslicentie beperkingenheeft. Als het aantal Parquet-bestanden voor een Delta-tabel de limiet voor uw SKU overschrijdt, vallen query's terug op DirectQuery-, wat kan leiden tot tragere queryprestaties.

Zie Delta-tabelonderhoud verderop in dit artikel om het aantal Parquet-bestanden te beheren.

Delta-tijdreizen

Bestanden koppelen maken het uitvoeren van query's op gegevens mogelijk vanaf een eerder tijdstip. Deze mogelijkheid staat bekend als Deltatijdreizen. Het eerdere tijdstip kan een tijdstempel of versie zijn.

Bekijk de volgende queryvoorbeelden.

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

Tip

U kunt ook een query uitvoeren op een tabel met behulp van de @ verkorte syntaxis om de tijdstempel of versie op te geven als onderdeel van de tabelnaam. De tijdstempel moet in het yyyyMMddHHmmssSSS-formaat zijn. U kunt een versie specificeren na @ door deze vooraf te laten gaan door een v.

Hier volgen de vorige queryvoorbeelden die zijn herschreven met een korte syntaxis.

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

Belangrijk

Tabelversies die toegankelijk zijn met tijdreizen, worden bepaald door een combinatie van de bewaardrempel voor transactielogboekbestanden en de frequentie en de opgegeven retentie voor VACUUM-bewerkingen (verderop in de sectie Delta-tabelonderhoud beschreven). Als u VACUUM dagelijks uitvoert met de standaardwaarden, zijn zeven dagen aan gegevens beschikbaar voor tijdreizen.

Kadering

Framing is een Direct Lake-bewerking waarmee de versie van een Delta-tabel wordt ingesteld die moet worden gebruikt voor het laden van gegevens in een kolom in een semantisch model. Even belangrijk, de versie bepaalt ook wat moet worden uitgesloten wanneer gegevens worden geladen.

Een framebewerking stempelt de tijdstempel/versie van elke Delta-tabel in de semantische modeltabellen. Wanneer het semantische model vanaf dit moment gegevens uit een Delta-tabel moet laden, wordt de tijdstempel/versie die is gekoppeld aan de meest recente framebewerking gebruikt om te bepalen welke gegevens moeten worden geladen. Eventuele volgende gegevenswijzigingen die plaatsvinden voor de Delta-tabel sinds de meest recente framebewerking worden genegeerd (tot de volgende framebewerking).

Belangrijk

Omdat een omlijnd semantisch model verwijst naar een bepaalde Delta-tabelversie, moet de bron ervoor zorgen dat deze Delta-tabelversie behouden blijft totdat het vaststellen van een nieuwe versie is voltooid. Anders zullen gebruikers fouten tegenkomen wanneer de Delta-tabelbestanden toegankelijk moeten zijn voor het model en zijn opgeschoond of op een andere manier verwijderd door de workload van de producent.

Voor meer informatie over kadering, zie Overzicht van Direct Lake.

Tabelpartitionering

Delta-tabellen kunnen worden gepartitioneerd, zodat een subset rijen samen worden opgeslagen in één set Parquet-bestanden. Partities kunnen query's en schrijfbewerkingen versnellen.

Overweeg een Delta-tabel met een miljard rijen verkoopgegevens voor een periode van twee jaar. Hoewel het mogelijk is om alle gegevens in één set Parquet-bestanden op te slaan, is het voor dit gegevensvolume niet optimaal voor lees- en schrijfbewerkingen. In plaats daarvan kunnen de prestaties worden verbeterd door de miljarden rijen gegevens over meerdere reeks Parquet-bestanden te spreiden.

Een partitiesleutel moet worden gedefinieerd bij het instellen van tabelpartitionering. De partitiesleutel bepaalt welke rijen moeten worden opgeslagen in welke reeks. Voor Delta-tabellen kan de partitiesleutel worden gedefinieerd op basis van de afzonderlijke waarden van een opgegeven kolom (of kolommen), zoals een maand-/jaarkolom van een datumtabel. In dit geval worden twee jaar aan gegevens verdeeld over 24 partities (2 jaar x 12 maanden).

Fabric-rekenprogramma's zijn niet op de hoogte van tabelpartities. Wanneer nieuwe partitiesleutelwaarden worden ingevoegd, worden nieuwe partities automatisch gemaakt. In OneLake vindt u één submap voor elke unieke partitiesleutelwaarde en elke submap slaat een eigen set Parquet-bestanden en koppelingsbestanden op. Ten minste één Parquet-bestand en één koppelingsbestand moeten bestaan, maar het werkelijke aantal bestanden in elke submap kan variëren. Wanneer bewerkingen voor het wijzigen van gegevens plaatsvinden, onderhoudt elke partitie een eigen set Parquet-bestanden en koppelbestanden om bij te houden wat er moet worden geretourneerd voor een bepaalde tijdstempel of versie.

Als een query van een gepartitioneerde Delta-tabel wordt gefilterd op alleen de meest recente drie maanden aan verkoopgegevens, kan de subset van Parquet-bestanden en koppelingsbestanden die moeten worden geopend snel worden geïdentificeerd. Hierdoor kunnen veel Parquet-bestanden helemaal worden overgeslagen, wat resulteert in betere leesprestaties.

Query's die niet op de partitiesleutel filteren, presteren echter mogelijk niet altijd beter. Dat kan het geval zijn wanneer een Delta-tabel alle gegevens in één grote set Parquet-bestanden opslaat en er fragmentatie van bestanden of rijengroepen is. Hoewel het mogelijk is om het ophalen van gegevens uit meerdere Parquet-bestanden over meerdere clusterknooppunten te parallelliseren, kunnen veel kleine Parquet-bestanden een negatieve invloed hebben op bestands-I/O en dus queryprestaties. Daarom is het raadzaam om in de meeste gevallen het partitioneren van Deltatabellen te vermijden, tenzij schrijfoperaties of extractie-, transformatie- en laadprocessen (ETL) er duidelijk baat bij hebben.

Partitioneringsvoordelen komen ook ten goede aan de bewerkingen voor invoegen, bijwerken en verwijderen, omdat de bestandsactiviteit alleen plaatsvindt in submappen die overeenkomen met de partitiesleutels van de gewijzigde of verwijderde rijen. Als er bijvoorbeeld een batch met gegevens wordt ingevoegd in een gepartitioneerde Delta-tabel, worden de gegevens geëvalueerd om te bepalen welke partitiesleutelwaarden er in de batch bestaan. Gegevens worden vervolgens alleen doorgestuurd naar de relevante mappen voor de partities.

Als u begrijpt hoe Delta-tabellen partities gebruiken, kunt u optimale ETL-scenario's ontwerpen die de schrijfbewerkingen verminderen die moeten worden uitgevoerd bij het bijwerken van grote Delta-tabellen. Schrijfprestaties worden verbeterd door het aantal en de grootte van nieuwe Parquet-bestanden te verminderen die moeten worden gemaakt. Voor een grote Delta-tabel die is gepartitioneerd op maand/jaar, zoals beschreven in het vorige voorbeeld, worden alleen nieuwe Parquet-bestanden toegevoegd aan de nieuwste partitie. Submappen van eerdere kalendermaanden blijven ongewijzigd. Als gegevens van eerdere kalendermaanden moeten worden gewijzigd, ontvangen alleen de relevante partitiemappen nieuwe partitie- en koppelingsbestanden.

Belangrijk

Als het belangrijkste doel van een Delta-tabel is om te fungeren als een gegevensbron voor semantische modellen (en secundaire, andere queryworkloads), is het meestal beter om partitionering in voorkeur te voorkomen voor het optimaliseren van de belasting van kolommen in het geheugen.

Voor semantische Direct Lake-modellen of het SQL Analytics-eindpuntis de beste manier om Delta-tabelpartities te optimaliseren door Fabric automatisch de Parquet-bestanden te laten beheren voor elke versie van een Delta-tabel. Het overlaten van het beheer aan Fabric moet leiden tot hoge queryprestaties via parallelisering, maar het biedt mogelijk niet noodzakelijkerwijs het beste schrijfvermogen.

Als u moet optimaliseren voor schrijfbewerkingen, kunt u overwegen partities te gebruiken om schrijfbewerkingen naar Delta-tabellen te optimaliseren op basis van de partitiesleutel. Houd er echter rekening mee dat het partitioneren van een Delta-tabel een negatieve invloed kan hebben op de leesprestaties. Daarom raden we u aan om de lees- en schrijfprestaties zorgvuldig te testen, mogelijk door meerdere kopieën van dezelfde Delta-tabel te maken met verschillende configuraties om tijdsinstellingen te vergelijken.

Waarschuwing

Als u partitioneert op een kolom met hoge kardinaliteit, kan dit leiden tot een buitensporig aantal Parquet-bestanden. Houd er rekening mee dat elke Fabric-capaciteitslicentie beperkingen heeft. Als het aantal Parquet-bestanden voor een Delta-tabel de limiet voor uw SKU overschrijdt, vallen query's terug op DirectQuery, wat kan leiden tot tragere queryprestaties.

Parquet-bestanden

De onderliggende opslag voor een Delta-tabel is een of meer Parquet-bestanden. Parquet-bestandsindeling wordt over het algemeen gebruikt voor eenmalig schrijven, meerdere keren lezen toepassingen. Nieuwe Parquet-bestanden worden telkens gemaakt wanneer gegevens in een Delta-tabel worden gewijzigd, ongeacht of ze worden ingevoegd, bijgewerkt of verwijderd.

Notitie

U hebt toegang tot Parquet-bestanden die zijn gekoppeld aan Delta-tabellen met behulp van een hulpprogramma, zoals OneLake-bestandenverkenner. Bestanden kunnen net zo eenvoudig naar andere bestemmingen worden gedownload, gekopieerd of verplaatst als andere bestanden. Het is echter de combinatie van Parquet-bestanden en de op JSON gebaseerde koppelingsbestanden waarmee rekenprogramma's query's kunnen uitvoeren op de bestanden als een Delta-tabel.

Parquet-bestandsindeling

De interne indeling van een Parquet-bestand verschilt van andere algemene indelingen voor gegevensopslag, zoals CSV, TSV, XMLA en JSON. Deze indelingen organiseren gegevens op rijen, terwijl Parquet gegevens ordent op kolommen. De Parquet-bestandsindeling verschilt ook van deze indelingen omdat hiermee rijen met gegevens worden ingedeeld in een of meer rijgroepen.

De interne gegevensstructuur van een semantisch Power BI-model is gebaseerd op kolommen, wat betekent dat Parquet-bestanden veel gemeen hebben met Power BI. Deze overeenkomst betekent dat een Direct Lake semantisch model efficiënt gegevens uit de Parquet-bestanden rechtstreeks in het geheugen kan laden. In feite kunnen zeer grote hoeveelheden gegevens in seconden worden geladen. Vergelijk deze mogelijkheid met het vernieuwen van een semantisch importmodel dat blokken of brongegevens moet ophalen, vervolgens verwerken, coderen, opslaan en laden in het geheugen. Een bewerking voor het vernieuwen van een semantisch importmodel kan ook aanzienlijke hoeveelheden rekenkracht (geheugen en CPU) verbruiken en veel tijd in beslag nemen. Met Delta-tabellen wordt echter het grootste deel van de moeite gedaan om de gegevens voor te bereiden die geschikt zijn voor direct laden in een semantisch model wanneer het Parquet-bestand wordt gegenereerd.

Hoe Parquet-bestanden gegevens opslaan

Bekijk de volgende voorbeeldset met gegevens.

Datum ProductID StockOnHand
2024-09-16 Een 10
16-09-2024 B 11
17-09-2024 Een 13
…

Wanneer de gegevensset in de Parquet-bestandsindeling is opgeslagen, kan deze er conceptueel uitzien als de volgende tekst.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

Gegevens worden gecomprimeerd door woordenlijstsleutels te vervangen door algemene waarden en door RLE-(run-length encoding) toe te passen. RLE streeft ernaar om een reeks van dezelfde waarden te comprimeren in een kleinere weergave. In het volgende voorbeeld wordt een woordenlijsttoewijzing van numerieke sleutels voor waarden gemaakt in de koptekst en worden de kleinere sleutelwaarden gebruikt in plaats van de gegevenswaarden.

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:

Wanneer het semantische Direct Lake-model gegevens nodig heeft om de som van de kolom StockOnHand gegroepeerd op ProductIDte berekenen, zijn alleen de woordenlijst en gegevens die zijn gekoppeld aan de twee kolommen vereist. In grote bestanden die veel kolommen bevatten, kunnen aanzienlijke delen van het Parquet-bestand worden overgeslagen om het leesproces te versnellen.

Notitie

De inhoud van een Parquet-bestand kan niet worden gelezen en is dus niet geschikt voor het openen in een teksteditor. Er zijn echter veel opensource-hulpprogramma's beschikbaar waarmee de inhoud van een Parquet-bestand kan worden geopend en weergegeven. Met deze hulpprogramma's kunt u ook metagegevens inspecteren, zoals het aantal rijen en rijgroepen in een bestand.

V-Order

Fabric ondersteunt een extra optimalisatie genaamd V-Order. V-Order is een optimalisatie van schrijftijd naar de Parquet-bestandsindeling. Zodra V-Order is toegepast, resulteert dit in een kleiner en dus sneller bestand om te lezen. Deze optimalisatie is met name relevant voor een semantisch Direct Lake-model, omdat hiermee de gegevens worden voorbereid voor snel laden in het geheugen, waardoor er minder behoefte is aan capaciteitsbronnen. Het resulteert ook in snellere queryprestaties omdat er minder geheugen moet worden gescand.

Delta-tabellen die zijn gemaakt en geladen door Fabric-items zoals gegevenspijplijnen, gegevensstromenen notebooks, passen automatisch de V-Order toe. Parquet-bestanden die zijn geüpload naar een Fabric Lakehouse, of waarnaar wordt verwezen door een snelkoppeling, hebben deze optimalisatie mogelijk niet toegepast. Hoewel niet-geoptimaliseerde Parquet-bestanden nog steeds kunnen worden gelezen, zijn de leesprestaties waarschijnlijk niet zo snel als een equivalent Parquet-bestand waarop V-order is toegepast.

Notitie

Parquet-bestanden waarop V-Order is toegepast, voldoen nog steeds aan de opensource Parquet-bestandsindeling. Daarom kunnen ze worden gelezen door niet-Fabric-hulpprogramma's.

Zie Delta Lake-tabeloptimalisatie en V-Ordervoor meer informatie.

Optimalisatie van Delta-tabellen

In deze sectie worden verschillende onderwerpen beschreven voor het optimaliseren van Delta-tabellen voor semantische modellen.

Gegevensvolume

Hoewel Delta-tabellen kunnen groeien om extreem grote hoeveelheden gegevens op te slaan, leggen capaciteitsbeperkingen van Fabric limieten op aan semantische modellen die hierop queries uitvoeren. Wanneer deze limieten worden overschreden, zullen query's terugvallen op DirectQuery, wat kan leiden tot tragere query-prestaties.

Overweeg daarom het aantal rijen van een grote feitentabel te beperken door de granulariteit (opgeslagen samengevatte gegevens) te verhogen, dimensionaliteit te verminderen of minder geschiedenis op te slaan.

Zorg er ook voor dat V-Order- wordt toegepast omdat dit resulteert in een kleiner en daarom sneller te lezen bestand.

Kolomgegevenstype

Probeer kardinaliteit (het aantal unieke waarden) in elke kolom van elke Delta-tabel te verminderen. Dat komt doordat alle kolommen worden gecomprimeerd en opgeslagen met behulp van hashcodering. Voor hashcodering is V-Orderoptimalisatie vereist om een numerieke id toe te wijzen aan elke unieke waarde in de kolom. Het is de numerieke identificator die vervolgens wordt opgeslagen, waarvoor tijdens het opslaan en uitvoeren van query's een hash-zoekopdracht vereist is.

Wanneer u numerieke gegevenstypen gebruikt (zoals zwevende en echte), kunt u overwegen waarden af te ronden en een lagere precisie te gebruiken.

Onnodige kolommen

Net als bij elke gegevenstabel mogen Delta-tabellen alleen kolommen opslaan die vereist zijn. In de context van dit artikel betekent dit dat dit vereist is voor het semantische model, hoewel er andere analyseworkloads kunnen zijn die query's uitvoeren op de Delta-tabellen.

Delta-tabellen moeten kolommen bevatten die vereist zijn voor het semantische model voor filteren, groeperen, sorteren en samenvatten, naast kolommen die modelrelaties ondersteunen. Hoewel onnodige kolommen geen invloed hebben op de prestaties van semantische modelquery's (omdat ze niet in het geheugen worden geladen), resulteren ze in een grotere opslaggrootte en moeten er dus meer rekenresources worden geladen en onderhouden.

Omdat semantische Direct Lake-modellen geen berekende kolommen ondersteunen, moet u dergelijke kolommen in de Delta-tabellen materialiseren. Houd er rekening mee dat deze ontwerpbenadering een antipatroon is voor import- en DirectQuery-semantische modellen. Als u bijvoorbeeld FirstName en LastName kolommen hebt en u een FullName kolom nodig hebt, materialiseert u de waarden voor deze kolom bij het invoegen van rijen in de Delta-tabel.

Houd er rekening mee dat sommige semantische modelsamenvattingen mogelijk afhankelijk zijn van meer dan één kolom. Als u bijvoorbeeld de verkoop wilt berekenen, telt de maatstaf in het model de producten van twee kolommen op: Quantity en Price. Als geen van deze kolommen onafhankelijk wordt gebruikt, is het efficiënter om de verkoopberekening als één kolom te materialiseren dan de onderdeelwaarden in afzonderlijke kolommen op te slaan.

Grootte van rijgroep

Intern organiseert een Parquet-bestand rijen met gegevens in meerdere rijgroepen binnen elk bestand. Een Parquet-bestand met 30.000 rijen kan deze bijvoorbeeld in drie rijgroepen verdelen, elk met 10.000 rijen.

Het aantal rijen in een rijgroep beïnvloedt hoe snel Direct Lake de gegevens kan lezen. Een hoger aantal rijgroepen met minder rijen heeft waarschijnlijk een negatieve invloed op het laden van kolomgegevens in een semantisch model vanwege overmatige I/O.

Over het algemeen raden we u niet aan om de standaardgrootte van de rijgroep te wijzigen. U kunt echter overwegen om de grootte van de rijgroep voor grote Delta-tabellen te wijzigen. Zorg ervoor dat u de lees- en schrijfprestaties zorgvuldig test, mogelijk door meerdere kopieën van dezelfde Delta-tabellen met verschillende configuraties te maken om tijdsinstellingen te vergelijken.

Belangrijk

Houd er rekening mee dat elke Fabric-capaciteitslicentie kaders heeft. Als het aantal rijgroepen voor een Delta-tabel de limiet voor uw SKU overschrijdt, kunnen query's terugvallen op DirectQuery, wat kan leiden tot tragere prestaties.

Onderhoud van Delta-tabellen

Naarmate er in de loop van de tijd schrijfbewerkingen plaatsvinden, hopen deltatabelversies zich op. Uiteindelijk bereikt u mogelijk een punt waarop een negatieve invloed op leesprestaties merkbaar wordt. Erger nog, als het aantal Parquet-bestanden per tabel, of rijgroepen per tabel, of rijen per tabel de capaciteitsgrenzen overschrijdt voor uw capaciteit, zullen query's terugvallen op DirectQuery, wat kan leiden tot tragere queryprestaties. Daarom is het belangrijk dat u Delta-tabellen regelmatig onderhoudt.

OPTIMALISEREN

U kunt OPTIMIZE gebruiken om een Delta-tabel te optimaliseren om kleinere bestanden te samenvoegen in grotere bestanden. U kunt ook de WHERE clausule instellen op alleen een gefilterde subset van rijen, die overeenkomen met een bepaald partitiepredicaat. Alleen filters met partitiesleutels worden ondersteund. Met de opdracht OPTIMIZE kunt u ook V-Order toepassen om de Parquet-bestanden te comprimeren en te herschrijven.

We raden u aan deze opdracht regelmatig uit te voeren op grote, regelmatig bijgewerkte Delta-tabellen, misschien elke dag wanneer uw ETL-proces is voltooid. Vind de balans tussen betere queryprestaties en de kosten van het resourcegebruik die nodig zijn om de tabel te optimaliseren.

VACUÜM

U kunt VACUUM- gebruiken om bestanden te verwijderen waarnaar niet meer wordt verwezen en/of die ouder zijn dan een ingestelde bewaardrempel. Zorg ervoor dat u een geschikte bewaarperiode instelt, anders verliest u mogelijk de mogelijkheid om tijdreizen te terug naar een versie die ouder is dan het frame dat in semantische modeltabellen is gestempeld.

Belangrijk

Omdat een geramd semantisch model verwijst naar een bepaalde Delta-tabelversie, moet de gegevensbron ervoor zorgen dat die Delta-tabelversie bewaard blijft totdat het inlijsten van een nieuwe versie is voltooid. Anders zullen gebruikers fouten tegenkomen wanneer de Delta-tabelbestanden toegankelijk moeten zijn voor het model en zijn opgeschoond of anderszins verwijderd door de producerende werklast.

REORG-TABEL

U kunt REORG TABLE gebruiken om een Delta-tabel te reorganiseren door bestanden opnieuw te schrijven om zacht verwijderde gegevens te wissen, bijvoorbeeld wanneer u een kolom verwijdert met behulp van ALTER TABLE DROP COLUMN.

Tabelonderhoud automatiseren

Als u onderhoudsbewerkingen voor tabellen wilt automatiseren, kunt u de Lakehouse-API gebruiken. Zie Manage the Lakehouse with Microsoft Fabric REST APIvoor meer informatie.

Fooi

U kunt ook de lakehouse tabelonderhoudsfunctie in de Fabric-portal gebruiken om het beheer van uw Delta-tabellen te vereenvoudigen.

Verwante inhoud