Sdílet prostřednictvím


Údržba a optimalizace tabulek napříč úlohami v Microsoft Fabric

Tabulky Delta v Microsoft Fabric obsluhují více modulů spotřeby, z nichž každá má různé charakteristiky výkonu a požadavky na optimalizaci. Tato příručka poskytuje komplexní architekturu pro pochopení toho, jak tabulky napsané jedním modulem využívají ostatní a jak odpovídajícím způsobem optimalizovat strategie údržby tabulek.

Pochopení vztahu mezi vzory zápisu a výkonem čtení v různých motorech je nezbytné pro vytváření efektivních datových platforem. Cílem je zajistit, aby producenti dat vytvářeli rozložení tabulek, která optimalizují výkon čtení pro podřízené uživatele, ať už tito uživatelé používají Spark, koncový bod analýzy SQL, Power BI Direct Lake nebo Warehouse.

Matice scénářů zápisu a čtení

Následující tabulka shrnuje očekávané charakteristiky výkonu pro běžné kombinace zápisu a čtení spolu s doporučenými strategiemi optimalizace. Pomocí této matice identifikujte svůj scénář a seznamte se s příslušnými pokyny.

Metoda Write Modul pro čtení Očekávané mezery Doporučená strategie
Dávka Sparku Spark Žádné mezery Výchozí konfigurace zápisu Sparku stačí.
Dávka Sparku Koncový bod analýzy SQL Žádné mezery Povolení automatického komprimace a optimalizace zápisu
Streamování Sparku Spark Možné malé soubory Automatické komprimace a optimalizace zápisu s naplánovanou optimalizací
Streamování Sparku Koncový bod analýzy SQL Malé soubory a kontrolní body Automatické komprimace, optimalizace zápisu, rozdělení vrstev medailiónu
Sklad Spark Žádné mezery Rozložení zpracovává optimalizace spravovaná systémem
Sklad Koncový bod analýzy SQL Žádné mezery Rozložení zpracovává optimalizace spravovaná systémem

Optimální rozložení souborů podle motoru

Různé motory spotřeby mají různá optimální rozložení souborů. Pochopení těchto cílů vám pomůže správně nakonfigurovat operace zápisu a úlohy údržby.

Pokyny pro koncový bod SQL analytiky a Fabric Data Warehouse

Pokud chcete dosáhnout optimálního výkonu s koncovým bodem sql Analytics a službou Warehouse, použijte následující nastavení:

  • Cílová velikost souboru: Maximálně 4 GB na soubor
  • Velikost skupiny řádků: Přibližně 2 miliony řádků na skupinu řádků
  • Pořadí V: Zlepšuje výkon čtení o 10%

Sklad pomocí těchto kritérií zjišťuje kandidáty na komprimace:

  • Režijní náklady na soubor tabulky jsou větší než 10%
  • Řádky tabulky, které byly logicky smazány, přesahují 10%
  • Velikost tabulky je větší než 1 024 řádků

Během provádění komprimace proces vybere kandidáty na základě těchto kritérií:

  • Libovolný soubor je menší než 25% ideální velikosti (na základě počtu řádků).
  • Jakýkoli soubor má více než 20% odstraněných řádků.

Spark

Spark je robustní při čtení různých velikostí souborů. Optimální výkon:

  • Cílová velikost souboru: 128 MB až 1 GB v závislosti na velikosti tabulky
  • Velikost skupiny řádků: 1 milion až 2 miliony řádků na skupinu řádků
  • V-Order: Nevyžaduje se pro výkon při čtení v Sparku (může přidat režii ve výši 15–33 % zápisu).

Čtení Sparku přináší výhodu adaptivní cílové velikosti souboru, která se automaticky upravuje na základě velikosti tabulky:

  • Tabulky pod 10 GB: cíl 128 MB
  • Tabulky nad 10 TB: Cílová velikost až 1 GB

Power BI Direct Lake

Pro optimální výkon Direct Lake:

  • Velikost cílové skupiny řádků: 8 milionů nebo více řádků na skupinu řádků pro dosažení nejlepšího výkonu
  • V-Order: Zásadní pro 40-60% zlepšení dotazů v chladné cache
  • Počet souborů: Minimalizace počtu souborů za účelem snížení režie při překódování
  • Konzistentní velikosti souborů: Důležité pro předvídatelný výkon dotazů

Sémantické modely Direct Lake fungují nejlépe v případech, kdy:

  • Data sloupců jsou V-Ordered pro kompresi kompatibilní s VertiPaq
  • Skupiny řádků jsou dostatečně velké pro efektivní slučování slovníků
  • Vektory odstranění se minimalizují prostřednictvím běžného komprimace.

Další informace najdete v tématu Výkon dotazů Direct Lake.

Zrcadlení

Zrcadlení automaticky nastavuje velikost souborů na základě objemu tabulky:

Velikost tabulky Počet řádků na skupinu Řádky na soubor
Malý (až 10 GB) 2 miliony 10 milionů
Střední (10 GB až 2,56 TB) 4 miliony 60 milionů
Velké (více než 2,56 TB) 8 milion 80 milionů

Vytváření vzorů a konfigurací

Šablony zápisu Sparku

Zápisy Sparku používají následující výchozí konfigurace:

Konfigurace Výchozí hodnota Description
spark.microsoft.delta.optimizeWrite.fileSize 128 MB Cílová velikost souboru pro optimalizované zápisy
spark.databricks.delta.optimizeWrite.enabled Liší se podle profilu. Povolí automatické slučování souborů.
spark.databricks.delta.autoCompact.enabled Disabled Povoluje komprimaci po zapsání.
spark.sql.files.maxRecordsPerFile Unlimited Maximální počet záznamů na soubor

Konfigurace zápisů ve Sparku pro spotřebu SQL ve směru toku dolů:

# Enable optimize write for better file layout
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable auto-compaction for automatic maintenance
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

Další informace o profilech prostředků a jejich výchozích hodnotách najdete v Konfigurace nastavení profilů prostředků.

Vzory zápisu do skladového systému

Sklad automaticky optimalizuje rozložení dat během zápisu:

  • V-Order je ve výchozím nastavení povolená pro optimalizaci čtení.
  • Automatické komprimace běží jako proces na pozadí.
  • Správa kontrolních bodů se zpracovává automaticky.

Sklad vytváří soubory optimalizované pro spotřebu SQL bez ručního zásahu. Tabulky napsané službou Warehouse jsou ze své podstaty optimalizované pro čtení koncového bodu analýzy SQL i služby Warehouse.

Operace údržby tabulek

PŘÍKAZ OPTIMIZE

Příkaz OPTIMIZE sloučit malé soubory do větších souborů:

-- Basic optimization
OPTIMIZE schema_name.table_name

-- Optimization with V-Order for Power BI consumption
OPTIMIZE schema_name.table_name VORDER

-- Optimization with Z-Order for specific query patterns
OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Důležité

Příkaz OPTIMIZE je příkaz Spark SQL. Musíte ho spustit v prostředích Sparku, jako jsou poznámkové bloky, definice úloh Sparku nebo rozhraní údržby Lakehouse. Koncový bod SQL Analytics a SQL Warehouse query editor tento příkaz nepodporují.

Další informace naleznete v tématu Komprimace tabulky.

Automatické komprimace

Automatické komprimace automaticky vyhodnotí stav oddílu po každé operaci zápisu a aktivuje synchronní optimalizaci při zjištění fragmentace souborů:

# Enable at session level
spark.conf.set('spark.databricks.delta.autoCompact.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.autoCompact' = 'true')
""")

Používejte automatickou kompakci pro příjmové kanály s častými malými zápisy (streamováním nebo mikro dávkami), abyste se vyhnuli ručnímu plánování a soubory se automaticky zkomprimovaly.

Automatické komprimace a optimalizace zápisu obvykle vytvářejí nejlepší výsledky při společném použití. Optimalizace zápisu snižuje počet zapsaných malých souborů a automatické komprimace zpracovává zbývající fragmentaci.

Další informace naleznete v tématu Automatické komprimace.

Optimalizace zápisu

Optimalizace zápisu snižuje režii malých souborů provedením komprimace před zápisem, která generuje méně větších souborů:

# Enable at session level
spark.conf.set('spark.databricks.delta.optimizeWrite.enabled', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true')
""")

Optimalizace zápisu je přínosná pro:

  • Dělené tabulky
  • Tabulky s častými malými vloženími
  • Operace, které se dotknou mnoha souborů (MERGE, UPDATE, DELETE)

Komprimace před zápisem (optimalizace zápisu) je obecně méně nákladná než komprimace po zápisu (optimalizace). Další informace najdete v tématu Optimalizace zápisu.

Příkaz VACUUM

Příkaz VACUUM odebere staré soubory, na které už protokol tabulky Delta neodkazuje:

-- Remove files older than the default retention period (7 days)
VACUUM schema_name.table_name

-- Remove files older than specified hours
VACUUM schema_name.table_name RETAIN 168 HOURS

Výchozí doba uchovávání je sedm dnů. Nastavení kratších období uchovávání ovlivňuje schopnosti Delta pro časové cestování a může způsobovat problémy se souběžnými čtenáři nebo zapisovateli.

Další informace naleznete v tématu Spuštění údržby tabulek z Lakehouse.

Optimalizace V-Order

V-Order je optimalizace doby zápisu, která používá řazení, kódování a kompresi kompatibilní s VertiPaq u souborů Parquet:

  • Power BI Direct Lake: 40–60% zlepšení dotazů v mezipaměti
  • Koncový bod analýzy SQL a datový sklad: Přibližně 10% zlepšení výkonu čtení.
  • Spark: Žádná vlastní výhoda čtení; 15–33% pomalejší zápisy

Kdy povolit V-Order

V-Order poskytuje největší výhodu pro:

  • Tabulka zlaté vrstvy podporující Power BI Direct Lake
  • Často dotazované tabulky skrze koncový bod SQL Analytics
  • Úlohy náročné na čtení, u kterých je výkon zápisu méně kritický

Kdy se vyhnout objednávce V

Uvažujte o zakázání V-Order pro:

  • Tabulky bronzové vrstvy zaměřené na rychlost příjmu dat
  • Pipelines Spark-to-Spark, ve kterých SQL a Power BI data nespotřebovávají
  • Úlohy náročné na zápis, u kterých je kritická latence dat

Konfigurace V-Order

V-Order je ve výchozím nastavení zakázané v nových pracovních prostorech Fabric. Povolíte ji takto:

# Enable at session level (default for all writes)
spark.conf.set('spark.sql.parquet.vorder.default', 'true')

# Enable at table level
spark.sql("""
    ALTER TABLE schema_name.table_name 
    SET TBLPROPERTIES ('delta.parquet.vorder.enabled' = 'true')
""")

Pokud chcete selektivně použít V-Order na základě spotřeby Direct Lake, zvažte automatizaci povolení V-Order pro tabulky používané v sémantických modelech Direct Lake. Tabulky, které Direct Lake nevyužívá, mohou zůstat bez V-Order pro lepší výkon zápisu.

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

Kapalinové shlukování a pořadí Z

Klasifikace kapalin

Liquid Clustering je doporučený přístup pro organizaci dat. Na rozdíl od tradičního dělení clusteringu Liquid:

  • Adaptuje se na změny vzorů dotazů.
  • Vyžaduje použití OPTIMIZE pro clustering.
  • Poskytuje lepší přeskočení souborů pro filtrované dotazy.

Povolení clusteringu Liquid při vytváření tabulky:

CREATE TABLE schema_name.table_name (
    id INT,
    category STRING,
    created_date DATE
) CLUSTER BY (category)

Z-Order

Z-Order spolu umisťuje související data ve stejných souborech, takže získáte lepší výkon dotazů u filtračních predikátů.

OPTIMIZE schema_name.table_name ZORDER BY (column1, column2)

Použití pořadí Z v případech:

  • Vaše tabulka je rozdělená na oddíly, protože clustering Liquid nefunguje s dělenými tabulkami.
  • Dotazy často filtrují podle dvou nebo více sloupců současně.
  • Predikáty jsou dostatečně selektivní, aby mohly využívat přeskakování souborů.

Doporučení k architektuře Medallion

Architektura medailiónu (bronzová, stříbrná, zlatá vrstva) poskytuje architekturu pro optimalizaci strategií údržby tabulek na základě účelu každé vrstvy.

Bronzová vrstva (cílová zóna)

Bronzové tabulky se zaměřují na výkon zápisu a příjem dat s nízkou latencí:

  • Priorita optimalizace: Rychlost příjmu dat nad výkonem čtení
  • Dělení: Přijatelné, ale nedoporučuje se pro nové implementace
  • Malé soubory: Přijatelné, protože zaměření je na rychlost příjmu dat
  • V-Order: Nedoporučuje se (přidává zápisové režijní náklady)
  • Automatická komprese: Umožní snížit počet malých souborů, ale může být obětována pro rychlost ingestování dat.
  • Vektory odstranění: Povoleno pro tabulky se vzory sloučení

Bronzové tabulky by se neměly poskytovat přímo příjemcům koncového bodu analýzy SQL ani příjemcům Power BI Direct Lake.

Stříbrná vrstva (kurátorovaná zóna)

Výkon zápisu a čtení u stříbrných tabulek:

  • Priorita optimalizace: Vyvážení mezi příjmem dat a výkonem dotazů
  • Velikosti souborů: Střední (128–256 MB) pro podporu operací zápisu i čtení
  • V-Order: Volitelné; povolit, pokud je významný koncový bod pro analýzy SQL nebo spotřeba Power BI
  • Liquid Clustering nebo Z-Order: Doporučuje se pro zvýšení výkonu dotazů.
  • Automatická komprimace a optimalizace zápisu: Povolení dle požadavků na downstream
  • Vektory odstranění: Povolení pro tabulky s častými aktualizacemi
  • Plánovaná optimalizace: Spouštět agresivně za účelem zachování rozložení souborů

Zlatá vrstva (zóna obsluhy)

Zlaté tabulky upřednostňují výkon čtení pro spotřebu koncových uživatelů:

  • Priorita optimalizace: Výkon čtení pro analýzy
  • Velikosti souborů: Velké (400 MB až 1 GB) pro optimální výkon SQL a Power BI
  • V-Order: Požadováno pro Power BI Direct Lake; přínosný pro koncový bod analýzy SQL
  • Liquid Clustering: Vyžadováno pro optimální přeskočení souborů
  • Optimalizace zápisu: Vyžadováno pro konzistentní velikosti souborů
  • Plánovaná OPTIMALIZACE: Spouštět agresivně za účelem zachování optimálního rozložení

Optimalizace zlatých tabulek odlišně na základě primárního modulu spotřeby:

Spotřeba motoru Pořadí V Cílová velikost souboru Velikost skupiny řádků
Koncový bod analýzy SQL Ano 400 MB 2 miliony řádků
Power BI Direct Lake Ano 400 MB až 1 GB Více než 8 milionů řádků
Spark Volitelné 128 MB až 1 GB 1–2 miliony řádků

Více kopií tabulky

Zachování více kopií tabulek optimalizovaných pro různé vzory spotřeby je přijatelné:

  • Tabulka Silver optimalizovaná pro zpracování Sparkem
  • Zlatá tabulka optimalizovaná pro koncový bod analýzy SQL a Power BI Direct Lake
  • Datové kanály, které transformují a umisťují správnou strukturu na každou vrstvu

Storage je levné ve srovnání s výpočetním výkonem. Optimalizace tabulek pro jejich vzory spotřeby poskytuje lepší uživatelské prostředí, než když se snažíte obsluhovat všechny uživatele z jednoho rozložení tabulky.

Identifikace kondice tabulky

Před optimalizací tabulek vyhodnoťte aktuální stav tabulky, abyste porozuměli potřebám optimalizace.

Přímá kontrola souborů Parquet

Složku tabulky ve OneLake můžete procházet a zkontrolovat velikosti jednotlivých souborů Parquet. Tabulky, které jsou v pořádku, mají rovnoměrně distribuované velikosti souborů. Vyhledejte:

  • Konzistentní velikosti souborů: Soubory by měly mít přibližně stejnou velikost (do 2x od sebe).
  • Žádné extrémně malé soubory: Soubory pod 25 MB značí fragmentaci.
  • Žádné extrémně velké soubory: Soubory větší než 2 GB mohou snížit paralelismus.

Nerovnoměrná distribuce velikosti souboru často značí chybějící komprimaci nebo nekonzistentní vzory zápisu v různých úlohách.

OPTIMALIZACE SUCHÉHO SPUŠTĚNÍ ve Spark SQL

DRY RUN Pomocí možnosti zobrazit náhled souborů, které mají nárok na optimalizaci bez provedení komprimace:

-- Preview files eligible for optimization
OPTIMIZE schema_name.table_name DRY RUN

Příkaz vrátí seznam souborů, které by se při optimalizaci přepsaly. Použijte toto k:

  • Před spuštěním vyhodnoťte rozsah optimalizace.
  • Porozumíte fragmentaci souborů beze změny tabulky.
  • Odhadnout dobu optimalizace na základě počtu ovlivněných souborů.

Distribuce velikosti souboru

K analýze velikostí a distribuce souborů použijte následující přístup:

from delta.tables import DeltaTable

# Get table details
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").collect()[0]
print(f"Table size: {details['sizeInBytes'] / (1024**3):.2f} GB")
print(f"Number of files: {details['numFiles']}")

# Average file size
avg_file_size_mb = (details['sizeInBytes'] / details['numFiles']) / (1024**2)
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Distribuce může být zkreslená, protože soubory blízko začátku tabulky nebo z konkrétního oddílu nemusí být optimalizované.

Distribuci můžete posoudit spuštěním dotazu, který seskupí podle partitioningových nebo klastrovacích klíčů tabulky.

Určení potřeb optimalizace

Na základě modulu pro spotřebu porovnejte skutečné velikosti souborů s cílovými velikostmi:

Motor Cílová velikost souboru Pokud jsou soubory menší Pokud jsou soubory větší
Koncový bod analýzy SQL 400 MB Spusťte příkaz OPTIMIZE. Soubory jsou přijatelné
Power BI Direct Lake 400 MB až 1 GB Spusťte příkaz OPTIMIZE VORDER. Soubory jsou přijatelné
Spark 128 MB až 1 GB Povolení automatické komprimace Soubory jsou přijatelné

Historie tabulek a transakční protokol

Projděte si historii tabulek a seznamte se se vzory zápisu a frekvencí údržby:

-- View table history
DESCRIBE HISTORY schema_name.table_name

-- Check for auto-compaction runs
-- Auto-compaction shows as OPTIMIZE with auto=true in operationParameters

Osvědčené postupy konfigurace

Upřednostněte vlastnosti tabulky před konfiguracemi relací

Vlastnosti tabulky se uchovávají napříč sezeními a zajišťují konzistentní chování ve všech úlohách a zapisovačích.

# Recommended: Set at table level for consistency
spark.sql("""
    CREATE TABLE schema_name.optimized_table (
        id INT,
        data STRING
    )
    TBLPROPERTIES (
        'delta.autoOptimize.optimizeWrite' = 'true',
        'delta.autoOptimize.autoCompact' = 'true',
        'delta.parquet.vorder.enabled' = 'true'
    )
""")

Konfigurace na úrovni relace se vztahují pouze na aktuální relaci Sparku a můžou způsobit nekonzistentní zápisy, pokud různé relace používají různé konfigurace.

Povolení adaptivní cílové velikosti souboru

Adaptivní cílová velikost souboru automaticky upraví cíle velikosti souboru na základě velikosti tabulky:

spark.conf.set('spark.microsoft.delta.targetFileSize.adaptive.enabled', 'true')

Tato funkce:

  • Začíná menšími soubory (128 MB) pro malé tabulky.
  • Zvyšuje škálování až na 1 GB pro tabulky přes 10 TB.
  • Automatické opětovné vyhodnocení během OPTIMIZE operací

Povolení cílů komprimace na úrovni souborů

Zabránit přepsání dříve komprimovaných souborů při změně cílových velikostí:

spark.conf.set('spark.microsoft.delta.optimize.fileLevelTarget.enabled', 'true')

Souhrn doporučení

Vrstva Automatická komprimace Optimalizace zápisu Pořadí V Klasifikace kapalin Plánovaná optimalizace
Bronz Povolit (volitelné) Enable Ne Ne Volitelné
Stříbro Enable Enable Volitelné Ano Aggressive
Zlato Enable Enable Ano Ano Aggressive

Pro konkrétní scénáře použijte následující doporučení:

  • Spark-to-Spark: Zaměřte se na optimalizaci velikosti souborů; Volitelné pořadí V.
  • Spark-to-SQL: Povolení optimalizace zápisu a automatické komprimace; cíl 400 MB souborů s 2 miliony skupin řádků.
  • Příjem dat streamování: Povolení automatického komprimace; naplánujte další OPTIMIZE úlohy pro uživatele SQL.
  • Power BI Direct Lake: Povolit V-Order; cílit na 8+ milionů skupin řádků; spustit OPTIMIZE VORDER.