Vysvetlenie ukladania pre sémantické modely Direct Lake

Tento článok vám predstaví koncepty Direct Lake úložiska. Popisuje tabuľky Delta a súbory parquet. Opisuje tiež, ako môžete optimalizovať tabuľky Delta pre sémantické modely Direct Lake a ako ich môžete zachovať, aby pomohli poskytovať spoľahlivý a rýchly výkon dotazov.

Delta tabuliek

Tabuľky Delta existujú v službe OneLake. Usporadúvajú údaje založené na súboroch do riadkov a stĺpcov a sú k dispozícii pre výpočtové zariadenia služby Microsoft Fabric, ako sú napríklad poznámkové bloky, Kustoa lakehouse a warehouse. Tabuľky Delta môžete dotazovať pomocou jazyka Data Analysis Expressions (DAX), multidimenzionálnych výrazov (MDX), T-SQL (Transact-SQL), Spark SQL a dokonca aj jazyka Python.

Tabuľky Delta ukladajú svoje údaje v súboroch Parquet, ktoré sú zvyčajne uložené v úložisku lakehouse, ktoré sémantický model Direct Lake používa na načítanie údajov. Parquet súbory však môžu byť uložené aj externe. Na externé parquet súbory možno odkazovať pomocou skratky OneLake, ktorá odkazuje na konkrétne umiestnenie úložiska, ako je napríklad Azure Data Lake Storage (ADLS) Gen2, kontá úložiska Amazon S3 alebo Dataverse. Takmer vo všetkých prípadoch výpočtové zariadenia získavajú prístup k súborom vo formáte Parquet dotazovaním tabuliek Delta. Zvyčajne však sémantické modely Direct Lake načítavajú údaje stĺpca priamo z optimalizovaných súborov parquet vo OneLake pomocou procesu známeho ako prekódovania.

Tvorba verzií údajov

Tabuľky Delta obsahujú jeden alebo viacero súborov vo formáte Parquet. Tieto súbory sú sprevádzané množinou súborov s prepojeniami založenými na formáte JSON, ktoré sledujú poradie a charakter každého súboru Parquet, ktorý je priradený k tabuľke Delta.

Je dôležité pochopiť, že základné súbory parketu sú prírastkové v prírode. Názov Delta preto odkaz na úpravu prírastkových údajov. Vždy, keď sa uskutoční operácia zápisu do tabuľky Delta, napríklad pri vložení, aktualizovaní alebo odstránení údajov, sa vytvoria nové súbory parquet, ktoré predstavujú úpravy údajov ako verziu. Parquet súbory sú preto nemenné, čo znamená, že sa nikdy nezmenia. Preto je možné veľakrát duplikovať údaje v rámci množiny súborov vo formáte Parquet pre tabuľku Delta. Delta framework využíva súbory prepojení na určenie, ktoré fyzické parquet súbory sú potrebné na vytvorenie správneho výsledku dotazu.

Zoberme si jednoduchý príklad tabuľky Delta, ktorú tento článok používa na vysvetlenie rôznych operácií úpravy údajov. Tabuľka má dva stĺpce a obsahuje tri riadky.

Údaje tabuľky Delta sú uložené v jednom súbore Parquet, ktorý obsahuje všetky údaje, a k dispozícii je súbor s jedným prepojením, ktorý obsahuje metaúdaje o tom, kedy boli údaje vložené (pripojené).

• Súbor parquet 1:
  • IDProduktu: A, B, C
  • StockOnHand: 1, 2, 3
• Súbor prepojenia 1:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 1 a zaznamená, že údaje boli pripojené.

Operácie vkladania

Zvážte, čo sa stane, keď sa vyskytne operácia vloženia: Vloží sa nový riadok pre produkt C s hodnotou zásob na sklade 4. Výsledkom týchto operácií je vytvorenie nového súboru Vo formáte Parquet a vytvorenie súboru s prepojením, takže teraz existujú dva parquet súbory a dva súbory s prepojeniami.

• Súbor parquet 1:
  • IDProduktu: A, B, C
  • StockOnHand: 1, 2, 3
• Súbor Parquet 2:
  • IDProduktu : D
  • StockOnHand: 4
• Súbor prepojenia 1:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 1 a zaznamená, že údaje boli pripojené.
• Súbor prepojenia 2:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 2 a zaznamená, že údaje boli pripojené.

V tomto momente dotaz tabuľky Delta vráti nasledujúci výsledok. Nezáleží na tom, že výsledok pochádza z viacerých súborov vo formáte Parquet.

Každá následná operácia vloženia vytvorí nové súbory parkety a prepojte súbory. To znamená, že počet súborov Parquet a súborov s prepojeniami rastie pri každej operácii vloženia.

Operácie aktualizácie

Teraz zvážte, čo sa stane, keď dôjde k operácii aktualizácie: Riadok D produktu má svoje zásoby na sklade zmenenú na 10. Táto operácia má za následok vytvorenie nového súboru Parquet a prepojenie súboru, takže tam sú teraz tri súbory Parquet a tri súbory s prepojeniami.

• Súbor parquet 1:
  • IDProduktu: A, B, C
  • StockOnHand: 1, 2, 3
• Súbor Parquet 2:
  • IDProduktu : D
  • StockOnHand: 4
• Súbor Parket 3:
  • IDProduktu : C
  • StockOnHand: 10
• Súbor prepojenia 1:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 1 a zaznamená, že údaje boli pripojené.
• Súbor prepojenia 2:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 2 a zaznamená, že údaje boli pripojené.
• Súbor prepojenia 3:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 3 a zaznamená, že údaje boli aktualizované.

V tomto momente dotaz tabuľky Delta vráti nasledujúci výsledok.

Údaje o C produktov teraz existujú vo viacerých súboroch vo formáte Parquet. Dotazy na tabuľku Delta však kombinujú súbory prepojení a určujú, ktoré údaje by sa mali použiť na poskytnutie správneho výsledku.

Odstránenie operácií

Teraz zvážte, čo sa stane, keď nastane operácia odstránenia: Riadok pre B produktu sa odstráni. Výsledkom tejto operácie je nový súbor Parquet a súbor s prepojením, takže teraz sú k dispozícii štyri súbory Parquet a štyri súbory s prepojeniami.

• Súbor parquet 1:
  • IDProduktu: A, B, C
  • StockOnHand: 1, 2, 3
• Súbor Parquet 2:
  • IDProduktu : D
  • StockOnHand: 4
• Súbor Parket 3:
  • IDProduktu : C
  • StockOnHand: 10
• Súbor Parquet 4:
  • ProductID: A, C, D
  • StockOnHand: 1, 10, 4
• Súbor prepojenia 1:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 1 a zaznamená, že údaje boli pripojené.
• Súbor prepojenia 2:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 2 a zaznamená, že údaje boli pripojené.
• Súbor prepojenia 3:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 3 a zaznamená, že údaje boli aktualizované.
• Súbor prepojenia 4:
  • Obsahuje časovú pečiatku pri vytvorení Parquet file 4 a zaznamená, že údaje boli odstránené.

Všimnite si, že Parquet file 4 už neobsahuje údaje o produkte B, ale obsahuje údaje pre všetky ostatné riadky v tabuľke.

V tomto momente dotaz tabuľky Delta vráti nasledujúci výsledok.

Delta času cestovania

Súbory prepojení umožňujú dotazovanie údajov už v predchádzajúcom čase. Táto funkcia je známa ako Delta time travel. Predchádzajúcim časom môže byť časová pečiatka alebo verzia.

Zvážte nasledujúce príklady dotazov.

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

Tu sú predchádzajúce príklady dotazov prepísané pomocou skratky .

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

Rámovanie

Framing je operácia Direct Lake, ktorá nastaví verziu tabuľky Delta, ktorá by sa mala použiť na načítanie údajov do stĺpca sémantického modelu. Rovnako dôležité je, že verzia tiež určuje, čo by malo byť vylúčené pri načítavaní údajov.

Operácia rámovania odtlačí pečiatku časovej pečiatky/verziu každej tabuľky Delta do tabuliek sémantických modelov. Od tohto bodu, keď sémantický model potrebuje načítať údaje z tabuľky Delta, použije sa časová pečiatka/verzia priradená k najnovšej operácii rámovania, aby sa určilo, ktoré údaje sa majú načítať. Akékoľvek následné úpravy údajov, ktoré sa vykonávajú v tabuľke Delta, pretože posledná operácia rámovania sa ignoruje (až do ďalšej operácie rámovania).

Ďalšie informácie o rámovaní nájdete v téme prehľad Direct Lake.

Rozdelenie tabuliek

Tabuľky Delta možno rozdeliť tak, aby bola podmnožina riadkov uložená spolu v jednej množine súborov parquet. Oblasti môžu urýchliť dotazy, ako aj operácie zapisovaia.

Zoberme si tabuľku Delta, ktorá má miliardu riadkov s údajmi o predaji za dvojročné obdobie. Aj keď je možné uložiť všetky údaje do jednej množiny súborov vo formáte Parquet, pre objem údajov nie je optimálny pre operácie čítania a zapisovania. Namiesto toho možno zvýšiť výkon rozmiestnením miliárd riadkov údajov v rámci viacerých radov súborov parquet.

Pri nastavovaní rozdelenia tabuliek je potrebné definovať kľúč oblasti. Kľúč oblasti určuje, v ktorých riadkoch sa má uložiť v ktorom rade. V prípade tabuliek Delta možno kľúč na rozdelenie definovať na základe odlišných hodnôt zadaného stĺpca (alebo stĺpcov), ako je napríklad stĺpec mesiaca/roka tabuľky dátumov. V tomto prípade by sa dva roky údajov distribuovali v rámci 24 oblastí (2 roky x 12 mesiacov).

Výpočtové zariadenia služby Fabric nevedia o oblastí tabuliek. Pri vkladaní nových hodnôt kľúča oblasti sa nové oblasti vytvoria automaticky. V službe OneLake nájdete jeden podpriečinok pre každú jedinečnú hodnotu kľúča oblasti a každý podpriečinok ukladá svoju vlastnú sadu súborov parquet a súborov s prepojeniami. Musí existovať aspoň jeden súbor Parquet a jeden súbor s prepojením, ale skutočný počet súborov v každom podpriečinku sa môže líšiť. Keďže prebiehajú operácie úpravy údajov, každá oblasť udržiava svoju vlastnú sadu súborov Parquet a súbory prepojení, aby udržala prehľad o tom, čo sa má vrátiť pre danú časovú pečiatku alebo verziu.

Ak je dotaz rozdelený na tabuľku Delta filtrovaný len na posledné tri mesiace údajov o predaji, podmnožinu súborov Parquet a súborov s prepojeniami, ku ktorým je potrebné získať prístup, je možné rýchlo identifikovať. To potom umožňuje celkom vynechanie mnohých súborov parquet, čo má za následok lepší výkon pri čítaní.

Dotazy, ktoré nefiltrujú podľa kľúča oblasti, však nemusia vždy fungovať lepšie. To môže byť prípad, keď tabuľka Delta ukladá všetky údaje v jednej veľkej množine súborov Parquet a k dispozícii je fragmentácia súboru alebo skupiny riadkov. Hoci je možné paralelne načítať údaje z viacerých parquet súborov v rámci viacerých uzlov klastra, mnoho malých súborov parquet môže nepriaznivo ovplyvniť súbor I/ O, a preto výkon dotazu. Z tohto dôvodu je najlepšie vo väčšine prípadov vyhnúť sa rozdeleniu tabuliek Delta, pokiaľ by procesy zapisovania alebo extrakcie, transformácie a načítania jasne nevyťažovali.

Výhody rozdelenia majú tiež operácie vkladania, aktualizovania a odstraňovania, pretože aktivita súboru sa vykonáva len v podpriečinkoch zodpovedajúcich kľúču oblasti v upravených alebo odstránených riadkoch. Ak je napríklad dávka údajov vložená do rozdelených tabuliek Delta, údaje sa vyhodnotia s cieľom určiť, aké hodnoty kľúča oblasti existujú v dávke. Údaje sa potom presmerujú iba do príslušných priečinkov pre oblasti.

Pochopenie toho, ako tabuľky Delta používajú oblasti, vám môže pomôcť navrhnúť optimálne scenáre ETL, ktoré znížia operácie zápisu, ktoré sa musia vykonať pri aktualizácii veľkých tabuliek Delta. Výkon pri písaní sa zlepšuje znížením počtu a veľkosti všetkých nových súborov vo formáte Parquet, ktoré je potrebné vytvoriť. Pre veľkú tabuľku Delta rozdelenú podľa mesiaca/roka, ako je popísané v predchádzajúcom príklade, nové údaje pridajú nové súbory len do najnovšej oblasti. Podpriečinky predchádzajúcich kalendárnych mesiacov zostanú nezmenené. Ak je potrebné upraviť údaje za predchádzajúce kalendárne mesiace, len príslušné priečinky oblastí dostanú novú oblasť a súbory prepojení.

Pre sémantické modely Direct Lake alebo koncového bodu analýzy SQLje najlepším spôsobom optimalizácie oblastí tabuliek Delta nechať fabric automaticky spravovať súbory parquet pre každú verziu tabuľky Delta. Ak by ste ponechali správu služby Fabric, jej výsledkom by mal byť vysoký výkon dotazu prostredníctvom paralelného tvaru, nemusí to však nevyhnutne poskytovať najlepší výkon pri písaní.

Ak musíte optimalizovať pre operácie zapisovania, zvážte použitie oblastí na optimalizáciu operácií zapisovania do tabuliek Delta na základe kľúča oblasti. Uvedomte si však, že rozdelenie tabuľky Delta môže mať negatívny vplyv na výkon čítania. Z tohto dôvodu odporúčame starostlivo otestovať výkon čítania a zapisovania, napríklad vytvorením viacerých kópií rovnakej tabuľky Delta s rôznymi konfiguráciami na porovnanie načasovania.

Parketové súbory

Základným úložiskom pre tabuľku Delta je jeden alebo viacero súborov vo formáte Parquet. Formát súboru vo formáte parquet sa vo všeobecnosti používa na aplikácie typu write-once, read-many. Nové súbory vo formáte Parquet sa vytvoria vždy, keď sa upravia údaje v tabuľke Delta, či už operáciou vloženia, aktualizácie alebo odstránenia.

Formát súboru Parket

Interný formát súboru Parquet sa líši od iných formátov úložiska údajov Common Data Storage, ako je napríklad CSV, TSV, XMLA a JSON. Tieto formáty usporadúvať údaje podľa riadkov, zatiaľ čo Parquet usporadúvať údaje podľa stĺpcov. Formát súboru Parquet sa od týchto formátov líši, pretože usporiada riadky údajov do jednej alebo viacerých skupín riadkov.

Vnútorná štruktúra údajov sémantického modelu služby Power BI je založená na stĺpci, čo znamená, že súbory vo formáte Parquet majú spolu so službou Power BI veľa spoločného. Táto podobnosť znamená, že sémantický model Direct Lake môže efektívne načítať údaje zo súborov vo formáte Parquet priamo do pamäte. V skutočnosti sa veľmi veľké objemy údajov môžu načítať v sekundách. Táto funkcia je kontrastná s obnovením sémantického modelu importu, ktorý musí načítať bloky alebo zdrojové údaje, potom spracovať, kódovať, uložiť a potom ich načítať do pamäte. Operácia obnovenia sémantického modelu importu môže tiež využívať značné množstvo výpočtov (pamäte a procesora) a trvať značný čas, kým sa dokončí. Pri tabuľkách Delta však väčšina úsilia pri príprave údajov vhodných na priame načítanie do sémantického modelu prebieha po vygenerovaní súboru Parquet.

Ako parketové súbory ukladať údaje

Zoberme si nasledujúci príklad množiny údajov.

Ak je táto množina údajov uložená vo formáte súboru Parquet, koncepčne môže vyzerať ako nasledujúci text.

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

Údaje sa komprimujú nahradením kľúčov slovníka pre spoločné hodnoty a použitím kódovania dĺžky spustenia (RLE). RLE sa snaží komprimovať rad rovnakých hodnôt na menšie vyjadrenie. V nasledujúcom príklade sa v hlavičke vytvorí slovník mapovanie číselných kľúčov k hodnotám a menšie hodnoty kľúča sa použijú namiesto údajových hodnôt.

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:

Keď sémantický model Direct Lake potrebuje údaje na výpočet súčtu stĺpca StockOnHand zoskupeného podľa ProductID, vyžaduje sa len slovník a údaje priradené k obom stĺpcom. Vo veľkých súboroch, ktoré obsahujú mnoho stĺpcov, možno vynechať značné časti súboru Parquet, aby pomohla urýchliť proces čítania.

Poradie V

Fabric podporuje dodatočnú optimalizáciu s názvom poradie. V-Order je write-time optimalizácia formátu súboru Parquet. Po použití poradia V sa vytvorí menšie, a teda rýchlejšie čítanie súboru. Táto optimalizácia je relevantná najmä pre sémantický model direct lake, pretože pripravuje údaje na rýchle načítanie do pamäte, a preto vytvára menšie požiadavky na kapacitné prostriedky. Výsledkom je tiež rýchlejší výkon dotazu, pretože je potrebné naskenovať menej pamäte.

Tabuľky Delta vytvorené a načítané položkami služby Fabric, ako sú napríklad kanály údajov , toky údajova poznámkové bloky automaticky použijú poradie V. Súbory nahrané do úložného priestoru Fabric lakehouse alebo súbory, na ktoré odkazuje odkaz, však túto optimalizáciu nemusia byť použité. Zatiaľ čo non-optimalizované parquet súbory možno ešte čítať, čítať výkon pravdepodobne nebude tak rýchlo ako ekvivalentný súbor Parquet, ktorý bol použitý V-Order.

Ďalšie informácie nájdete optimalizácii tabuľky Delta Lake aV-Order.

Optimalizácia tabuľky Delta

Táto časť popisuje rôzne témy na optimalizáciu tabuliek Delta pre sémantické modely.

Objem údajov

Zatiaľ čo tabuľky Delta sa môžu zväčšiť a ukladať veľmi veľké objemy údajov, ochrana kapacity služby Fabric ukladajú obmedzenia pre sémantické modely, ktoré ich dotazujú. Po prekročení týchto limitov sa dotazy vrátia späť doDirectQuery , čo môže mať za následok nižší výkon dotazov.

Zvážte preto obmedzenie počtu riadkov veľkej tabuľky faktov tak, že zvýšite jeho granularitu (ukladací priestor s súhrnnými údajmi), znížite dimenzionalitu alebo uložíte menej histórie.

Uistite sa tiež, že poradie V-Order sa použije, pretože výsledkom je menší a teda rýchlejší súbor na čítanie.

Typ údajov stĺpca

Snažte sa znížiť kardinalitu (počet jedinečných hodnôt) v každom stĺpci každej tabuľky Delta. Je to spôsobené tým, že všetky stĺpce sa komprimujú a ukladajú pomocou kódovania hash. Kódovanie hash vyžaduje optimalizáciu poradia V-Order na priradenie číselného identifikátora ku každej jedinečnej hodnote obsiahnutej v stĺpci. Ide o numerický identifikátor, ktorý sa potom uloží a počas ukladania a dotazovania vyžaduje vyhľadávanie hash.

Pri používaní približných číselných typov údajov (ako s pohyblivou desatinnou čiarkou a reálnych), zvážte zaokrúhlenie hodnôt a s použitím nižšej presnosti.

Nepotrebné stĺpce.

Rovnako ako v prípade každej tabuľky údajov, tabuľky Delta by mali ukladať iba stĺpce, ktoré sú povinné. V kontexte tohto článku to znamená, že to znamená, že sa vyžaduje v sémantickom modeli, hoci môžu existovať aj iné analytické vyťaženia, ktoré dotazujú tabuľky Delta.

Tabuľky Delta by mali okrem stĺpcov, ktoré podporujú vzťahy modelov, obsahovať stĺpce požadované sémantickým modelom na filtrovanie, zoskupovanie, zoraďovanie a sumarizáciu. Nepotrebné stĺpce síce nemajú vplyv na výkon dotazov v sémantickom modeli (pretože sa nenačítajú do pamäte), výsledkom je väčšia veľkosť úložiska, a preto si vyžadujú na načítanie a údržbu viac výpočtových prostriedkov.

Keďže sémantické modely Direct Lake nepodporujú vypočítané stĺpce, mali by ste tieto stĺpce realizovať v tabuľkách Delta. Všimnite si, že tento prístup k návrhu je antim vzorom pre sémantické modely importu a DirectQuery. Ak máte napríklad FirstName a LastName stĺpce a potrebujete FullName stĺpec, realizujte hodnoty pre tento stĺpec pri vkladaní riadkov do tabuľky Delta.

Zoberme si, že niektoré súhrny sémantických modelov môžu závisieť od viac ako jedného stĺpca. Napríklad na výpočet predaja mierka v modeli sčíta súčin dvoch stĺpcov: Quantity a Price. Ak sa žiadny z týchto stĺpcov nepoužíva nezávisle, bolo by efektívnejšie realizovať výpočet predaja ako jeden stĺpec, ako uložiť hodnoty jeho súčastí v samostatných stĺpcoch.

Veľkosť skupiny riadkov

Súbor Parquet interne usporiada riadky údajov do viacerých skupín riadkov v rámci každého súboru. Súbor Parquet, ktorý obsahuje 30 000 riadkov, ich môže napríklad rozdeliť do troch skupín riadkov, pričom každý z nich má 10 000 riadkov.

Počet riadkov v skupine riadkov ovplyvňuje to, ako rýchlo môže Direct Lake čítať údaje. Väčší počet skupín riadkov s menším počtom riadkov pravdepodobne bude mať negatívny vplyv na načítanie údajov stĺpca do sémantického modelu v dôsledku nadmerného počtu riadkov.

Vo všeobecnosti neodporúčame zmeniť predvolenú veľkosť skupiny riadkov. Môžete však zvážiť zmenu veľkosti skupiny riadkov pre veľké tabuľky Delta. Výkon čítania a zapisovania testujte opatrne, napríklad vytvorením viacerých kópií rovnakých tabuliek Delta s rôznymi konfiguráciami, aby sa porovnali načasovania.

Údržba tabuľky Delta

Postupne sa ako operácie zápisu vykonávajú, verzie tabuľky Delta sa hromadia. Možno dosiahnete bod, v ktorom sa bude zrejmá negatívny vplyv na výkon čítania. Čo je horšie, ak počet súborov vo formáte Parquet na tabuľku alebo skupín riadkov na tabuľku alebo riadkov v tabuľke presahuje bezpečnostné zložky pre vašu kapacitu, dotazy sa vrátia späť doDirectQuery , čo môže mať za následok nižší výkon dotazu. Preto je dôležité, aby ste tabuľky Delta udržiavali pravidelne.

OPTIMALIZOVAŤ

Funkciu OPTIMALIZÁCIA môžete použiť na optimalizáciu tabuľky Delta tak, aby sa menšie súbory spojili do väčších. Môžete tiež nastaviť klauzulu WHERE tak, aby smerovala len na filtrovanú podmnožinu riadkov, ktoré zodpovedajú danej predikátu oblasti. Podporované sú iba filtre zahŕňajúce kľúče oblasti. Príkaz OPTIMIZE môže použiť aj príkaz V-Order na kompaktnie a prepísanie súborov parquet.

Odporúčame, aby ste spustili tento príkaz na veľkých, často aktualizovaných tabuľkách Delta pravidelne, možno každý deň po dokončení procesu ETL. Vyváženie kompromisu medzi lepším výkonom dotazu a nákladmi na využívanie zdrojov potrebných na optimalizáciu tabuľky.

VÁKUUM

Pomocou VACUUM môžete odstrániť súbory, na ktoré sa už odkazuje a/alebo ktoré sú staršie ako nastavená prahová hodnota uchovávania údajov. Dbajte na nastavenie príslušného obdobia uchovávania údajov, v opačnom prípade by ste mohli stratiť možnosť cestovanie časom späť do verzie staršej ako rám opečiatkovaný do tabuliek sémantických modelov.

REORG TABLE

Pomocou REORG TABLE môžete usporiadať tabuľku Delta prepísaním súborov, aby sa vymazali obnoviteľné odstránené údaje, napríklad pri poklese stĺpca pomocou stĺpca ALTER TABLE DROP.

Automatizácia údržby tabuliek

Na automatizáciu operácií údržby tabuliek môžete použiť rozhranie API Lakehouse. Ďalšie informácie nájdete Spravovanie služby Lakehouse pomocou rozhrania Microsoft Fabric REST API.

Súvisiaci obsah

• prehľad direct lake
• vývoj sémantických modelov Direct Lake
• spravovanie sémantických modelov Direct Lake
• optimalizáciu tabuľky Delta Lake a objednávok V-Order