Sdílet prostřednictvím

Pochopení ú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í v OneLake. Uspořádávají soubory dat do řádků a sloupců a jsou k dispozici pro výpočetní nástroje Microsoft Fabric, jako jsou poznámkové bloky, Kusto, a také lakehouse a warehouse. 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 datovém lakehousu, který sémantický model Direct Lake používá k načítání dat. Soubory Parquet se ale dají ukládat i externě. Externí soubory Parquet lze odkázat pomocí zástupce OneLake, který směřuje na konkrétní úložiště, jako například Azure Data Lake Storage (ADLS) Gen2, ú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 však obvykle načítají data sloupců přímo z optimalizovaných souborů Parquet v OneLake prostřednictvím procesu zvaného transkó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. Při každé 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 verze. Soubory Parquet jsou proto neměnné, tedy nikdy nedochází k jejich změ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 Zásoby na skladě
A 1
B 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:
    • idproduktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy bylo Parquet file 1 vytvořeno, a zaznamenává, že data byla připojena.

Operace vložení

Zvažte, co se stane, když dojde k operaci vložení: Vloží se nový záznam pro produkt C s hodnotou na skladu 4. 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:
    • idproduktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Parquet soubor 2:
    • IDproduktu: D
    • StockOnHand: 4
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy byl Parquet file 1 vytvořen, a zaznamenává připojení dat.
  • Soubor odkazu 2:
    • Obsahuje časové razítko při vytvoření Parquet file 2 a zaznamenává, že data byla připojena.

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.

ID produktu Zásoby na skladě
A 1
B 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 propojovacích souborů roste s každou operací vložení.

Aktualizační operace

Nyní zvažte, co se stane, když dojde k operaci aktualizace: Řádek produktu D má hodnotu dostupného skladu 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í.

  • Soubor Parquet 1:
    • idproduktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Soubor Parquet 2:
    • IDproduktu: D
    • StockOnHand: 4
  • Soubor Parquet 3:
    • idproduktu: C
    • Skladové zásoby: 10
  • Odkaz na soubor 1:
    • Obsahuje časové razítko, kdy bylo Parquet file 1 vytvořeno, a záznamy o připojení dat.
  • Soubor odkazu 2:
    • Obsahuje časové razítko při vytvoření Parquet file 2 a zaznamenává, že data byla připojena.
  • Soubor odkazu 3:
    • Obsahuje časové razítko, kdy bylo Parquet file 3 vytvořeno, a zaznamenává, že data byla aktualizována.

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

ProductID StockOnHand
A 1
B 2
C 10
D 4

Data pro produkt C nyní 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.

Mazání operací

Teď zvažte, co se stane, když dojde k operaci odstranění: Řádek pro produkt 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:
    • idproduktu: A, B, C
    • StockOnHand: 1, 2, 3
  • Soubor Parquet 2:
    • IDproduktu: D
    • StockOnHand: 4
  • Parquet soubor 3:
    • idproduktu: C
    • StockOnHand: 10
  • soubor Parquet 4:
    • idproduktu: A, C, D
    • StockOnHand: 1, 10, 4
  • Odkaz na soubor 1:
    • Obsahuje časové razítko vytvoření Parquet file 1 a zaznamenává, že data byla připojena.
  • Soubor odkazu 2:
    • Obsahuje časové razítko, kdy byl Parquet file 2 vytvořen, a zaznamenává, že data byla připojena.
  • Soubor odkazu 3:
    • Obsahuje časové razítko při vytvoření Parquet file 3 a zaznamenává, že data byla aktualizována.
  • Soubor odkazu 4:
    • Obsahuje časové razítko vytvoření Parquet file 4 a záznam o tom, že data byla odstraněna.

Všimněte si, že Parquet file 4 již 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 1
C 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á mantinely. Pokud počet souborů Parquet pro tabulku Delta překročí limit pro vaši skladovou položku, dotazy se vrátí zpět doDirectQuery, což může vést k nižšímu výkonu dotazů.

Pokud chcete spravovat počet souborů Parquet, přečtěte si údržbu tabulek Delta dále v tomto článku.

Delta cestování časem

Soubory propojení umožňují dotazování dat k dřívějšímu bodu v čase. Tato schopnost se označuje jako Delta cestování časem. Dřívějším časovým bodem 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;

Spropitné

K dotazování na tabulku můžete také použít zkrácenou syntaxi @ k zadání časového razítka nebo verze jako součást názvu tabulky. Časové razítko musí být ve formátu yyyyMMddHHmmssSSS. Verzi můžete zadat po @ tak, že před verzi přidáte v.

Zde jsou předchozí příklady dotazů přepsané 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 VACUUM (popsané dále v části údržba tabulek Delta). Pokud spustíte VACUUM denně s výchozími hodnotami, bude pro cestování v čase k dispozici sedm dnů dat.

Rámování

Framing je operace Direct Lake, která nastavuje verzi tabulky Delta, jež by měla být použita 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í otiskne časové razítko/verzi každé tabulky Delta do sémantických modelových tabulek. 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 dojde u tabulky Delta od 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, když musí mít model přístup k souborům tabulek Delta, které byly vyčištěny nebo jinak odstraněny úlohou producenta.

Další informace o zarámování naleznete v přehledu Direct Lake .

Dělení tabulek

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íč pro rozdělení určuje, do které řady se mají uložit jednotlivé řádky. 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 fabricu nevědí o rozděleních tabulek. 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 souborů odkazů. 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í.

Avšak dotazy, které nefiltrují podle klíče oddílu, 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ů, ledaže by z takového dělení měly jasný přínos operace zápisu nebo procesy extrakce, transformace a načítání (ETL).

Operace vkládání, aktualizace a odstraňování také těží z oddělení dat, protože aktivita souborů probíhá pouze v podsložkách odpovídajících klíči oddílu modifikovaných nebo odstraněných řádků. Například pokud se dávka dat vloží do dělené tabulky Delta, data se vyhodnotí, aby se určilo, 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é, jiné úlohy dotazů), je obvykle lepší vyhnout se dělení v předvolbách pro optimalizaci zatížení sloupců do paměti.

U sémantických modelů Direct Lake nebo koncového bodu SQL Analytics spočívá nejlepší způsob optimalizace oddílů tabulky Delta v tom, že služba Fabric automaticky spravuje soubory Parquet pro každou verzi tabulky Delta. Ponechání správy na Fabric by mělo vést k vysokému výkonu dotazů prostřednictvím paralelizace, avšak nemusí 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řílišné dělení tabulky Delta může negativně ovlivnit výkon při č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í.

Varování

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 na kapacitu Fabric má omezení. Pokud počet souborů Parquet pro tabulku Delta překročí limit pro vaši skladovou položku, dotazy se vrátí zpět doDirectQuery, 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 jednorázový zápis, četba mnohonásobná aplikace. 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 ale většina úsilí na přípravu dat vhodných 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
16.09.2024 A 10
16. září 2024 B 11
17.09.2024 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 je ve záhlaví vytvořen slovník mapující číselné klíče na hodnoty a menší hodnoty klíčů jsou použity jako hodnoty dat.

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 sloupce StockOnHand 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

Fabric podporuje další optimalizaci nazvanou 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 prohledat méně paměti.

Tabulky Delta vytvořené a načtené položkami Fabric, jako jsou datové kanály, toky data poznámkové bloky, automaticky používají V-Order. Soubory Parquet nahrané do objektu Fabric Lakehouse nebo na které odkazuje zástupce , nemusí tuto optimalizaci použít. I když je možné číst neoptimalizované soubory Parquet, jejich výkon čtení pravděpodobně nebude tak rychlý jako u ekvivalentního souboru Parquet, který má aplikovaný V-Order.

Poznámka

Soubory Parquet, u kterých byl použit V-Order, stále odpovídají formátu souboru Parquet, který je open-source. Proto je mohou číst nástroje, které nejsou součástí Fabric.

Další informace najdete v tématu Optimalizace tabulek Delta Lake aV-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, mantinely kapacity Fabric na sémantické modely, které je dotazují. Po překročení těchto limitů se dotazy automaticky přepnou naDirectQuery, což může mít za následek pomalejší výkon 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 aplikuje V-Order, protože výsledkem je menší a tím pádem rychleji načítatelný soubor.

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 komprimovány a uloženy pomocí hashového kódování. 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 uloží, přičemž při ukládání a dotazování je vyžadováno vyhledávání hash.

Pokud používáte přibližné číselné datové typy (například plovoucí a skutečné), 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. Je důležité si uvědomit, že tento návrhový přístup je považován za anti-pattern, tedy nevhodný vzor, pro sémantické modely využívající Import a DirectQuery. Pokud máte například 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 pro výpočet 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á omezující prvky. Pokud počet skupin řádků pro tabulku Delta překročí limit pro vaši skladovou položku, dotazy se vrátí zpět doDirectQuery, 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 skupin řádků na tabulku, nebo řádků na tabulku překročí mantinely pro kapacitu, dotazy se přejdou na DirectQuery, což může vést k pomalejší rychlosti dotazů. Proto je důležité pravidelně udržovat tabulky Delta.

OPTIMALIZOVAT

Pomocí OPTIMIZE můžete optimalizovat tabulku Delta tak, aby se menší soubory shodily do větších. Klauzuli WHERE můžete také nastavit tak, aby se zaměřila pouze na vyfiltrovanou podmnožinu řádků, které odpovídají danému předikátu oddílení. Podporují se jen filtry obsahující klíče oddílů. Příkaz OPTIMIZE může také použít příkaz 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.

VAKUUM

Pomocí VACUUM můžete odebrat soubory, které již nejsou referencovány a/nebo jsou starší než nastavená prahová hodnota uchovávání. Dbejte na to, abyste nastavili odpovídající dobu uchovávání, jinak byste mohli přijít o možnost cestovat časem zpět k verzi starší než rámec vyznačený v sémantických tabulkách 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 TABLE 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í 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.

Spropitné

Ke zjednodušení správy tabulek Delta můžete také použít funkci údržby tabulek lakehouse na portálu Fabric.

Související obsah