Sdílet prostřednictvím

Principy úložiště pro sémantické modely Direct Lake

  • Článek

Tento článek představuje koncepty úložiště Direct Lake . Popisuje tabulky Delta a soubory Parquet. Popisuje také, jak můžete optimalizovat tabulky Delta pro sémantické modely Direct Lake a jak je můžete udržovat, abyste mohli zajistit spolehlivý a rychlý výkon dotazů.

Tabulky Delta

Tabulky Delta existují ve OneLake. Uspořádávají data založená na souborech do řádků a sloupců a jsou k dispozici pro výpočetní moduly Microsoft Fabric, jako jsou poznámkové bloky, Kusto a jezero a sklad. Tabulky Delta můžete dotazovat pomocí jazyka DAX (Data Analysis Expressions), multidimenzionálních výrazů (MDX), T-SQL (Transact-SQL), Spark SQL a dokonce Pythonu.

Poznámka:

Delta –nebo Delta Lake – je opensourcový formát úložiště. To znamená, že Fabric může také dotazovat tabulky Delta vytvořené jinými nástroji a dodavateli.

Tabulky Delta ukládají data v souborech Parquet, které jsou obvykle uložené v jezeře, kterou sémantický model Direct Lake používá k načtení dat. Soubory Parquet se ale dají ukládat i externě. Na externí soubory Parquet se dá odkazovat pomocí zástupce OneLake, který odkazuje na konkrétní umístění úložiště, jako je Azure Data Lake Storage (ADLS) Gen2, účty úložiště Amazon S3 nebo Dataverse. Ve téměř všech případech výpočetní moduly přistupují k souborům Parquet dotazováním tabulek Delta. Sémantické modely Direct Lake ale načítají data sloupců přímo z optimalizovaných souborů Parquet v OneLake pomocí procesu známého jako překódování.

Správa verzí dat

Tabulky Delta tvoří jeden nebo více souborů Parquet. Tyto soubory jsou doprovázeny sadou souborů odkazů založených na FORMÁTU JSON, které sledují pořadí a povahu každého souboru Parquet přidruženého k tabulce Delta.

Je důležité si uvědomit, že podkladové soubory Parquet jsou přírůstkové. Proto název Delta jako odkaz na přírůstkovou úpravu dat. Pokaždé, když dojde k operaci zápisu do tabulky Delta , například při vložení, aktualizaci nebo odstranění dat, se vytvoří nové soubory Parquet, které představují úpravy dat jako verzi. Soubory Parquet jsou proto neměnné, což znamená, že se nikdy nemění. Proto je možné data duplikovat mnohokrát v sadě souborů Parquet pro tabulku Delta. Architektura Delta spoléhá na soubory propojení k určení, které fyzické soubory Parquet jsou potřeba k vytvoření správného výsledku dotazu.

Podívejte se na jednoduchý příklad tabulky Delta, kterou tento článek používá k vysvětlení různých operací úprav dat. Tabulka obsahuje dva sloupce a ukládá tři řádky.

ProductID StockOnHand
A 0
T 2
C 3

Data tabulky Delta jsou uložená v jednom souboru Parquet, který obsahuje všechna data, a existuje jediný odkazový soubor, který obsahuje metadata o tom, kdy byla data vložena (připojena).

  • Parquet soubor 1:
    • ID produktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy Parquet file 1 bylo vytvořeno, a záznamy, ke kterým byla připojena data.

Operace vložení

Zvažte, co se stane, když dojde k operaci vložení: Nový řádek produktu C s skladem na ruční hodnotě 4 je vložen. Výsledkem této operace je vytvoření nového souboru Parquet a souboru propojení, takže teď jsou dva soubory Parquet a dva soubory propojení.

  • Parquet soubor 1:
    • ID produktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet soubor 2:
    • ID produktu: D
    • StockOnHand: 4
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy Parquet file 1 bylo vytvořeno, a záznamy, ke kterým byla připojena data.
  • Soubor odkazu 2:
    • Obsahuje časové razítko, kdy Parquet file 2 bylo vytvořeno, a záznamy, ke kterým byla připojena data.

V tomto okamžiku vrátí dotaz tabulky Delta následující výsledek. Nezáleží na tom, že výsledek pochází z více souborů Parquet.

ProductID StockOnHand
A 0
T 2
C 3
D 4

Každá další operace vložení vytvoří nové soubory Parquet a propojuje soubory. To znamená, že počet souborů Parquet a souborů propojení roste s každou operací vložení.

Operace aktualizace

Teď zvažte, co se stane, když dojde k operaci aktualizace: Řádek produktu D má sklad na ruční hodnotu změněnou na 10. Výsledkem této operace je vytvoření nového souboru Parquet a souboru propojení, takže teď jsou tři soubory Parquet a tři soubory propojení.

  • Parquet soubor 1:
    • ID produktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet soubor 2:
    • ID produktu: D
    • StockOnHand: 4
  • Parquet soubor 3:
    • ID produktu: C
    • StockOnHand: 10
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy Parquet file 1 bylo vytvořeno, a záznamy, ke kterým byla připojena data.
  • Soubor odkazu 2:
    • Obsahuje časové razítko, kdy Parquet file 2 bylo vytvořeno, a záznamy, ke kterým byla připojena data.
  • Soubor odkazu 3:
    • Obsahuje časové razítko, kdy Parquet file 3 bylo vytvořeno, a záznamy, které se aktualizovaly.

V tomto okamžiku vrátí dotaz tabulky Delta následující výsledek.

ProductID StockOnHand
A 0
T 2
K 10
D 4

Data pro produkt C teď existují ve více souborech Parquet. Dotazy na tabulku Delta ale kombinují soubory propojení a určují, jaká data by se měla použít k poskytnutí správného výsledku.

Operace odstranění

Teď zvažte, co se stane, když dojde k operaci odstranění: Řádek produktu B se odstraní. Výsledkem této operace je nový soubor Parquet a soubor odkazu, takže teď jsou čtyři soubory Parquet a čtyři soubory propojení.

  • Parquet soubor 1:
    • ID produktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet soubor 2:
    • ID produktu: D
    • StockOnHand: 4
  • Parquet soubor 3:
    • ID produktu: C
    • StockOnHand: 10
  • Parquet soubor 4:
    • ID produktu: A, C, D
    • StockOnHand: 1, 10, 4
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy Parquet file 1 bylo vytvořeno, a záznamy, ke kterým byla připojena data.
  • Soubor odkazu 2:
    • Obsahuje časové razítko, kdy Parquet file 2 bylo vytvořeno, a záznamy, ke kterým byla připojena data.
  • Soubor odkazu 3:
    • Obsahuje časové razítko, kdy Parquet file 3 bylo vytvořeno, a záznamy, které se aktualizovaly.
  • Soubor odkazu 4:
    • Obsahuje časové razítko, kdy Parquet file 4 bylo vytvořeno, a záznamy, které se odstranily.

Všimněte si, že Parquet file 4 už neobsahuje data pro produkt B, ale obsahuje data pro všechny ostatní řádky v tabulce.

V tomto okamžiku vrátí dotaz tabulky Delta následující výsledek.

ProductID StockOnHand
A 0
K 10
D 4

Poznámka:

Tento příklad je jednoduchý, protože zahrnuje malou tabulku, jen několik operací a pouze menší úpravy. Velké tabulky, které mají zkušenosti s mnoha operacemi zápisu a které obsahují mnoho řádků dat, vygenerují více než jeden soubor Parquet na verzi.

Důležité

V závislosti na tom, jak definujete tabulky Delta a četnost operací úprav dat, může to vést k mnoha souborům Parquet. Mějte na paměti, že každá licence kapacity Fabric má ochranné mantinely. Pokud počet souborů Parquet pro tabulku Delta překročí limit pro vaši skladovou položku, dotazy se vrátí zpět do DirectQuery, což může vést k nižšímu výkonu dotazů.

Informace o správě počtu souborů Parquet najdete v části Údržba tabulek Delta dále v tomto článku.

Rozdílová doba trvání

Soubory propojení umožňují dotazování dat k dřívějšímu bodu v čase. Tato funkce se označuje jako rozdílová doba trvání. Dřívějším bodem v čase může být časové razítko nebo verze.

Podívejte se na následující příklady dotazů.

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

Tip

K zadání časového razítka nebo verze v názvu tabulky můžete také použít @ zkrácenou syntaxi tabulky. Časové razítko musí být ve yyyyMMddHHmmssSSS formátu. Verzi @ můžete zadat tak, že ji předejdete v .

Tady jsou předchozí příklady dotazů, které se přepíšou pomocí zkrácené syntaxe.

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

Důležité

Verze tabulek přístupné s časovým cestováním jsou určeny kombinací prahové hodnoty uchovávání pro soubory transakčního protokolu a četností a určeným uchováváním pro operace vakua (popsané dále v části Údržba tabulky Delta). Pokud spustíte úklid denně s výchozími hodnotami, bude pro časovou cestu k dispozici sedm dnů dat.

Rámování

Framing je operace Direct Lake, která nastavuje verzi tabulky Delta, která by se měla použít k načtení dat do sloupce sémantického modelu. Stejně důležitá je také verze, která určuje, co by se mělo vyloučit při načtení dat.

Operace rámování vytyčí časové razítko/verzi každé tabulky Delta do tabulek sémantických modelů. Od tohoto okamžiku se v případě, že sémantický model potřebuje načíst data z tabulky Delta, použije se časové razítko nebo verze přidružené k poslední operaci rámování k určení dat, která se mají načíst. Všechny následné úpravy dat, ke kterým dochází u tabulky Delta, protože poslední operace rámování se ignorují (až do další operace rámování).

Důležité

Vzhledem k tomu, že sémantický model odkazuje na konkrétní verzi tabulky Delta, musí zdroj zajistit, aby se zachová verze tabulky Delta, dokud se nedokončí rámování nové verze. V opačném případě se uživatelům zobrazí chyby v případě, že soubory tabulek Delta musí být přístupné modelem a byly vysáty nebo jinak odstraněny úlohou producenta.

Další informace o rámování najdete v tématu Direct Lake – přehled.

Dělení tabulky

Tabulky Delta je možné rozdělit tak, aby podmnožina řádků byla uložena společně v jedné sadě souborů Parquet. Oddíly můžou urychlit dotazy i operace zápisu.

Představte si tabulku Delta, která obsahuje miliardy řádků prodejních dat za dvouleté období. I když je možné uložit všechna data do jedné sady souborů Parquet, není pro tento svazek dat optimální pro operace čtení a zápisu. Místo toho je možné zvýšit výkon rozložením miliard řádků dat do více řad souborů Parquet.

Klíč oddílu musí být definován při nastavování dělení tabulky. Klíč oddílu určuje, které řádky se mají uložit do které řady. V případě tabulek Delta je možné klíč oddílu definovat na základě jedinečných hodnot zadaného sloupce (nebo sloupců), například sloupce měsíce/roku v tabulce kalendářních dat. V tomto případě by se dva roky dat distribuovaly napříč 24 oddíly (2 roky x 12 měsíců).

Výpočetní moduly infrastruktury neví o oddílech tabulky. Při vkládání nových hodnot klíče oddílu se nové oddíly vytvoří automaticky. Ve OneLake najdete jednu podsložku pro každou jedinečnou hodnotu klíče oddílu a každá podsložka ukládá vlastní sadu souborů Parquet a propojování souborů. Musí existovat alespoň jeden soubor Parquet a jeden soubor odkazu, ale skutečný počet souborů v každé podsložce se může lišit. Vzhledem k tomu, že probíhají operace úprav dat, každý oddíl udržuje svou vlastní sadu souborů Parquet a propojí soubory, abyste měli přehled o tom, co se má vrátit pro dané časové razítko nebo verzi.

Pokud se dotaz na dělenou tabulku Delta vyfiltruje jenom na poslední tři měsíce prodejních dat, je možné rychle identifikovat podmnožinu souborů Parquet a souborů odkazů, ke kterým je potřeba přistupovat. To pak umožňuje úplně přeskočit mnoho souborů Parquet, což vede k lepšímu výkonu čtení.

Dotazy, které nefiltrují klíč oddílu, ale nemusí vždy fungovat lépe. To může být případ, kdy tabulka Delta ukládá všechna data do jedné velké sady souborů Parquet a dochází k fragmentaci souborů nebo skupin řádků. I když je možné paralelně paralelizovat načítání dat z několika souborů Parquet napříč několika uzly clusteru, může mnoho malých souborů Parquet nepříznivě ovlivnit vstupně-výstupní operace souboru, a proto výkon dotazů. Z tohoto důvodu je nejvhodnější vyhnout se dělení tabulek Delta ve většině případů – pokud by z nich byly jasně přínosné operace zápisu nebo operace extrakce, transformace a načítání (ETL).

Také operace vkládání, aktualizace a odstraňování oddílů, protože aktivita souborů probíhá pouze v podsložkách odpovídajících klíči oddílu upravených nebo odstraněných řádků. Pokud je například dávka dat vložená do dělené tabulky Delta, vyhodnotí se data a určí, jaké hodnoty klíče oddílu v dávce existují. Data se pak směrují pouze do příslušných složek pro oddíly.

Když pochopíte, jak tabulky Delta používají oddíly, můžete navrhnout optimální scénáře ETL, které snižují operace zápisu, které je potřeba provést při aktualizaci velkých tabulek Delta. Výkon zápisu se zvyšuje snížením počtu a velikosti všech nových souborů Parquet, které se musí vytvořit. U velké tabulky Delta rozdělené podle měsíce/roku, jak je popsáno v předchozím příkladu, nová data přidávají do nejnovějšího oddílu jenom nové soubory Parquet. Podsložky předchozích kalendářních měsíců zůstávají nedotčené. Pokud je nutné upravit nějaká data předchozích kalendářních měsíců, dostanou nové oddíly a soubory propojení jenom příslušné složky oddílů.

Důležité

Pokud je hlavním účelem tabulky Delta sloužit jako zdroj dat pro sémantické modely (a za druhé i jiné úlohy dotazů), je obvykle lepší vyhnout se dělení v předvolbách pro optimalizaci zatížení sloupců do paměti.

V případě sémantických modelů Direct Lake nebo koncového bodu sql Analytics je nejlepším způsobem optimalizace oddílů tabulek Delta umožnit službě Fabric automatickou správu souborů Parquet pro každou verzi tabulky Delta. Ponechání správy do prostředků infrastruktury by mělo vést k vysokému výkonu dotazů prostřednictvím paralelizace, nemusí ale nutně poskytovat nejlepší výkon zápisu.

Pokud je nutné optimalizovat operace zápisu, zvažte použití oddílů k optimalizaci operací zápisu do tabulek Delta na základě klíče oddílu. Mějte ale na paměti, že při dělení tabulky Delta může negativně ovlivnit výkon čtení. Z tohoto důvodu doporučujeme pečlivě otestovat výkon čtení a zápisu, například vytvořením více kopií stejné tabulky Delta s různými konfiguracemi pro porovnání časování.

Upozorňující

Pokud rozdělíte oddíl na sloupec s vysokou kardinalitou, může to vést k nadměrnému počtu souborů Parquet. Mějte na paměti, že každá licence kapacity Fabric má ochranné mantinely. Pokud počet souborů Parquet pro tabulku Delta překročí limit pro vaši skladovou položku, dotazy se vrátí zpět do DirectQuery, což může vést k nižšímu výkonu dotazů.

Soubory Parquet

Podkladové úložiště pro tabulku Delta je jeden nebo více souborů Parquet. Formát souboru Parquet se obecně používá pro aplikace typu zápis-jednou, čtení-N . Nové soubory Parquet se vytvářejí při každé změně dat v tabulce Delta, ať už operací vložení, aktualizace nebo odstranění.

Poznámka:

K souborům Parquet, které jsou přidružené k tabulkám Delta, můžete přistupovat pomocí nástroje, jako je Průzkumník souborů OneLake. Soubory je možné stáhnout, zkopírovat nebo přesunout do jiných cílů stejně snadno jako přesun všech ostatních souborů. Jedná se ale o kombinaci souborů Parquet a souborů odkazů založených na formátu JSON, které výpočetním modulům umožňují vydávat dotazy na soubory jako tabulku Delta.

Formát souboru Parquet

Interní formát souboru Parquet se liší od jiných běžných formátů úložiště dat, jako jsou CSV, TSV, XMLA a JSON. Tyto formáty uspořádají data podle řádků, zatímco Parquet uspořádá data podle sloupců. Formát souboru Parquet se také liší od těchto formátů, protože uspořádá řádky dat do jedné nebo více skupin řádků.

Interní datová struktura sémantického modelu Power BI je založená na sloupcích, což znamená, že soubory Parquet sdílejí hodně společného s Power BI. Tato podobnost znamená, že sémantický model Direct Lake dokáže efektivně načítat data ze souborů Parquet přímo do paměti. Ve skutečnosti lze velmi velké objemy dat načíst v sekundách. Porovnejte tuto funkci s aktualizací sémantického modelu importu, který musí načítat bloky nebo zdrojová data, pak zpracovávat, kódovat, ukládat a načítat do paměti. Operace aktualizace sémantického modelu importu může také spotřebovávat značné množství výpočetních prostředků (paměti a procesoru) a dokončení trvá poměrně dlouho. U tabulek Delta se ale většina úsilí připravit data vhodná pro přímé načítání do sémantického modelu probíhá při generování souboru Parquet.

Jak soubory Parquet ukládají data

Představte si následující ukázkové sady dat.

Datum ProductID StockOnHand
2024-09-16 A 10
2024-09-16 T 11
2024-09-17 A 13
…

Při ukládání ve formátu souboru Parquet může tato sada dat vypadat koncepčně jako následující text.

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

Data se komprimují nahrazením klíčů slovníku pro běžné hodnoty a použitím kódování RLE (run-length). RLE se snaží zkomprimovat řadu stejných hodnot do menší reprezentace. V následujícím příkladu se v hlavičce vytvoří slovník mapování číselných klíčů na hodnoty a místo hodnot dat se použijí menší hodnoty klíče.

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:

Pokud sémantický model Direct Lake potřebuje data k výpočtu součtu StockOnHand sloupce seskupeného podle ProductID, vyžaduje se pouze slovník a data přidružená ke dvěma sloupcům. Ve velkých souborech, které obsahují mnoho sloupců, je možné vynechat podstatné části souboru Parquet, aby se urychlil proces čtení.

Poznámka:

Obsah souboru Parquet není čitelný člověk a proto se nehodí k otevření v textovém editoru. Existuje však mnoho opensourcových nástrojů, které mohou otevřít a odhalit obsah souboru Parquet. Tyto nástroje také umožňují kontrolovat metadata, například počet řádků a skupin řádků obsažených v souboru.

Pořadí V

Prostředky infrastruktury podporují další optimalizaci s názvem V-Order. V-Order je optimalizace času zápisu do formátu souboru Parquet. Jakmile se použije pořadí V, bude výsledkem menší a rychlejší čtení souboru. Tato optimalizace je obzvláště relevantní pro sémantický model Direct Lake, protože připravuje data pro rychlé načítání do paměti, takže snižuje nároky na prostředky kapacity. Výsledkem je také rychlejší výkon dotazů, protože je potřeba zkontrolovat méně paměti.

Tabulky Delta vytvořené a načtené položkami Infrastruktury, jako jsou datové kanály, toky dat a poznámkové bloky, automaticky používají pořadí V. Soubory Parquet nahrané do objektu Fabric Lakehouse nebo odkazované zástupcem však nemusí tuto optimalizaci použít. I když soubory Parquet, které nejsou optimalizované, je stále možné číst, výkon čtení pravděpodobně nebude tak rychlý jako ekvivalentní soubor Parquet, který měl použitou objednávku V.

Poznámka:

Soubory Parquet, které mají použité V-Order, stále odpovídají opensourcovém formátu souboru Parquet. Proto je můžou číst nástroje, které nejsou prostředky infrastruktury.

Další informace najdete v tématu Optimalizace tabulek Delta Lake a pořadí V-Order.

Optimalizace tabulek Delta

Tato část popisuje různá témata pro optimalizaci tabulek Delta pro sémantické modely.

Objem dat

Tabulky Delta sice můžou růst tak, aby ukládaly extrémně velké objemy dat, ale mantinely kapacity Fabric ukládají limity pro sémantické modely, které je dotazují. Po překročení těchto limitů se dotazy vrátí zpět do DirectQuery, což může vést k pomalejšímu výkonu dotazů.

Proto zvažte omezení počtu řádků velké tabulky faktů zvýšením členitosti (ukládání souhrnných dat), snížením počtu dimenzí nebo uložením méně historie.

Také se ujistěte, že se použije pořadí V, protože výsledkem je menší a rychlejší čtení souboru.

Datový typ sloupce

Snažte se omezit kardinalitu (počet jedinečných hodnot) v každém sloupci každé tabulky Delta. Je to proto, že všechny sloupce jsou komprimované a uložené pomocí kódování hash. Kódování hash vyžaduje optimalizaci V-Order k přiřazení číselného identifikátoru ke každé jedinečné hodnotě obsažené ve sloupci. Jedná se o číselný identifikátor, který se pak uloží a během ukládání a dotazování vyžaduje vyhledávání hash.

Pokud používáte přibližné číselné datové typy (například plovoucí a reálné), zvažte zaokrouhlování hodnot a použití nižší přesnosti.

Nepotřebné sloupce

Stejně jako u jakékoli tabulky dat by tabulky Delta měly ukládat jenom požadované sloupce. V kontextu tohoto článku to znamená, že to vyžaduje sémantický model, i když mohou existovat další analytické úlohy, které se dotazují na tabulky Delta.

Tabulky Delta by měly obsahovat sloupce vyžadované sémantickým modelem pro filtrování, seskupování, řazení a souhrny kromě sloupců, které podporují relace modelu. I když nepotřebné sloupce nemají vliv na výkon dotazů na sémantický model (protože se nenačtou do paměti), výsledkem je větší velikost úložiště, takže k načtení a údržbě vyžadují více výpočetních prostředků.

Vzhledem k tomu, že sémantické modely Direct Lake nepodporují počítané sloupce, měli byste tyto sloupce materializovat v tabulkách Delta. Všimněte si, že tento přístup návrhu je anti-pattern pro sémantické modely Import a DirectQuery. Pokud například máte FirstName a LastName sloupce a potřebujete FullName sloupec, materializujte hodnoty pro tento sloupec při vkládání řádků do tabulky Delta.

Vezměte v úvahu, že některé sémantické souhrny modelů můžou záviset na více než jednom sloupci. Například k výpočtu prodeje se míra v modelu sčítá součin dvou sloupců: Quantity a Price. Pokud by se žádný z těchto sloupců nepoužíval nezávisle, bylo by efektivnější materializovat výpočet prodeje jako jeden sloupec, než aby se hodnoty součástí ukládaly do samostatných sloupců.

Velikost skupiny řádků

Soubor Parquet interně uspořádá řádky dat do více skupin řádků v rámci každého souboru. Například soubor Parquet, který obsahuje 30 000 řádků, je může rozdělit do tří skupin řádků, přičemž každý má 10 000 řádků.

Počet řádků ve skupině řádků ovlivňuje, jak rychle může Direct Lake číst data. Vyšší počet skupin řádků s menším počtem řádků pravděpodobně negativně ovlivní načítání dat sloupců do sémantického modelu kvůli nadměrnému počtu vstupně-výstupních operací.

Obecně nedoporučujeme změnit výchozí velikost skupiny řádků. Můžete ale zvážit změnu velikosti skupiny řádků pro velké tabulky Delta. Nezapomeňte pečlivě otestovat výkon čtení a zápisu, například vytvořením více kopií stejných tabulek Delta s různými konfiguracemi pro porovnání časování.

Důležité

Mějte na paměti, že každá licence kapacity Fabric má ochranné mantinely. Pokud počet skupin řádků pro tabulku Delta překročí limit skladové položky, dotazy se vrátí zpět do DirectQuery, což může vést k nižšímu výkonu dotazů.

Údržba tabulek Delta

V průběhu času se při operacích zápisu hromadí verze tabulek Delta. Nakonec můžete dosáhnout bodu, kdy se zjeví negativní dopad na výkon čtení. Horší je, že pokud počet souborů Parquet na tabulku nebo skupiny řádků na tabulku nebo řádky na tabulku překročí ochranné mantinely pro vaši kapacitu, dotazy se vrátí do DirectQuery, což může vést k pomalejšímu výkonu dotazů. Proto je důležité pravidelně udržovat tabulky Delta.

OPTIMIZE

Pomocí funkce OPTIMIZE můžete optimalizovat tabulku Delta tak, aby se menší soubory shodily do větších. Klauzuli WHERE můžete také nastavit tak, aby cílila pouze na filtrovanou podmnožinu řádků, které odpovídají danému predikátu oddílu. Podporují se jenom filtry zahrnující klíče oddílů. Příkaz OPTIMIZE může také použít V-Order k komprimaci a přepsání souborů Parquet.

Doporučujeme tento příkaz spustit na velkých, často aktualizovaných tabulkách Delta pravidelně, třeba každý den, když se proces ETL dokončí. Vyvažte kompromis mezi lepším výkonem dotazů a náklady na využití prostředků vyžadovanými k optimalizaci tabulky.

VACUUM

Pomocí funkce VAKUA můžete odebrat soubory, na které se už neodkazují nebo které jsou starší než nastavená prahová hodnota uchovávání informací. Dbejte na to, abyste nastavili odpovídající dobu uchovávání, jinak byste mohli přijít o možnost časového přesunu zpět na verzi starší než rámec kolkovaný do sémantických tabulek modelu.

Důležité

Vzhledem k tomu, že sémantický model odkazuje na konkrétní verzi tabulky Delta, musí zdroj zajistit, aby se zachová verze tabulky Delta, dokud se nedokončí rámování nové verze. V opačném případě se uživatelům zobrazí chyby v případě, že soubory tabulek Delta musí být přístupné modelem a byly vysáty nebo jinak odstraněny úlohou producenta.

REORG TABLE

Tabulku REORG můžete použít k přeuspořádání tabulky Delta přepsáním souborů pro vymazání obnovitelně odstraněných dat, například při přetažení sloupce pomocí příkazu ALTER TABLE DROP COLUMN.

Automatizace údržby tabulek

K automatizaci operací údržby tabulek můžete použít rozhraní API Lakehouse. Další informace najdete v tématu Správa lakehouse pomocí rozhraní Microsoft Fabric REST API.

Tip

Správu tabulek Delta můžete také zjednodušit pomocí funkce údržby tabulek lakehouse na portálu Fabric.

Související obsah