Údržba a optimalizácia tabuliek naprieč záťažami v Microsoft Fabric

Delta tabuľky v Microsoft Fabric môžu slúžiť Spark, SQL analytics endpoint, Power BI Direct Lake, Warehouse a ďalšie Fabric zážitky z dát uložených v OneLake. Optimálny výkon naprieč pracovnou záťažou závisí od dvoch faktorov:

  • Pracovná záťaž, ktorá vytvára a udržiava tabuľku.
  • Motory, ktoré pohlcujú stôl.

Lakehouse tabuľky sa bežne spravujú pomocou Spark, Fabric pipeline Copy activity alebo Dataflow Gen2. Spark je najbežnejší zapisovateľ a poskytuje najširšie možnosti rozloženia a údržby. Zrkadlenie skladov a databáz spravuje svoje fyzické rozloženia automaticky. Zrkadlové katalógy si zachovávajú rozloženie spravované v zdrojovom systéme. Požiadavky spotrebiteľov sú vo všeobecnosti kompatibilné, ale Power BI Direct Lakedodatočné požiadavky na úložisko pre optimálny výkon.

Používajte jednu zdieľanú tabuľku vždy, keď sú jej požiadavky kompatibilné. Pre výnimky, ktoré ospravedlňujú inú tabuľku, pozri Kedy vytvoriť ďalšiu tabuľku.

Pochopte vlastníctvo rozloženia

Začnite tým, že identifikujete, ktorá záťaž vlastní fyzické rozloženie tabuliek. Ovládacie prvky v nasledujúcej tabuľke sú kľúčové pre rozloženie a údržbu tabuliek naprieč pracovnými záťažami, nie vyčerpávajúci zoznam schopností každého motora.

Ukladací priestor údajov Metóda písania alebo prijímania Vlastníctvo usporiadania a údržby Kľúčové ovládanie
Lakehouse Spark Spravované používateľom Veľkosť súboru: adaptívna cieľová veľkosť súboru a cieľová kompaktácia na úrovni súboru.
Zápis a údržba: delečné vektory, automatická kompakcia, optimalizácia zápisu, OPTIMIZE, a VACUUM.
Organizácia dát:kvapalinové zhlukovanie, rozdelenie, Z-Order a V-Order.
Lakehouse Fabric pipeline Copy activity alebo Dataflow Gen2 Služba zapisuje dáta; Majiteľ jazerného domu udržiava tabuľku Nastavenia zápisu špecifické pre cieľ. Kompatibilnú údržbu spúšťajte samostatne pomocou Sparku, údržby Lakehouse alebo údržby potrubia.
Sklad Fabric Data Warehouse, Fabric pipeline Copy activity, alebo Dataflow Gen2 Spravované skladom Dátové zhlukovanie a nastavenie V-Order na úrovni skladu.
Zrkadlový predmet Služba zrkadlenia Závisí to od typu zrkadlenia Zrkadlenie databáz používa systémovo riadené rozloženie V-Ordered Delta bez priamych ovládacích prvkov. Zrkadlové katalógy si zachovávajú rozloženie zdrojových súborov, ktoré môžete optimalizovať v zdrojovom systéme, keď je podporované.

Usmernenie naprieč pracovnou záťažou

Nasledujúca tabuľka zhrňuje odporúčaný prístup podľa výrobcu a spotrebiteľa.

Producent Spotrebiteľ Odporúčaný postup
Lakehouse: Scenárista Spark Spark Použite predvolené nastavenia Fabric Spark runtime 2.0 alebo novšieho a zapnite automatickú kompakciu. Zvážte tekuté zhlukovanie , keď merané predikáty profitujú z lepšieho preskakovania súborov.
Lakehouse: Scenárista Spark Koncový bod analýzy SQL Použite rovnaké rozloženie odporúčané pre Spark. Nenastavujte statickú cieľovú veľkosť súboru, ľubovoľný limit riadkov alebo V-Order len kvôli výkonu SQL analytického endpointu.
Lakehouse: Scenárista Spark Power BI Direct Lake Použite rovnaké rozloženie odporúčané pre Spark a navyše povolte V-Order, alebo použite readHeavyForPBI resource profile.
Lakehouse: Fabric pipeline alebo Dataflow Gen2 writer Spark, SQL analytics endpoint alebo Power BI Direct Lake Monitorujte výsledné rozloženie súborov a plánujte údržbu kompatibilného jazerného domu samostatne. Niektoré cieľové režimy, ako napríklad inkrementálne obnovovanie Dataflow Gen2, ukladajú obmedzenia údržby.
Sklad Fabric Data Warehouse alebo Iskra Použite rozloženie spravované systémom. Fabric Data Warehouse automaticky riadi zhutnenie a ďalšiu údržbu. Použite dátové klastrovanie na zlepšenie preskakovania súborov pri pracovných záťažiach s opakujúcimi sa selektívnymi predikátmi.
Sklad Power BI Direct Lake Zachovanie predvoleného nastavenia Warehouse V-Order. Používajte dátové zhlukovanie , keď to prospeje zdieľaným vzorom dotazov.
Mirroring Spark, SQL analytics endpoint alebo Power BI Direct Lake Pre zrkadlenie databáz použite systémovo spravované rozloženie V-Ordered Delta. Pre zrkadlové katalógy optimalizujte podkladové súbory v zdrojovom systéme, ak sú podporované. Pozri Čo je zrkadlenie v Fabric?.

Optimalizujte Lakehouse tabuľky

Tabuľky Lakehouse Delta vyžadujú explicitnú stratégiu údržby bez ohľadu na to, či ich zapisuje Spark, Pipeline Copy activity alebo Dataflow Gen2. Spark je hlavným príkladom v tejto sekcii, pretože poskytuje najširšie rozloženie a údržbové ovládanie v Fabric.

Dôležité

Údržba tabuliek je kľúčová pre optimálny výkon zápisu a čítania naprieč motormi. Aj workloady len s pripojením, ktoré spočiatku fungujú dobre bez údržby, môžu nahromadiť nadmerné množstvo malých súborov, čo ovplyvňuje Spark, SQL analytics endpoint, Direct Lake a externé dátové čítačky. Pozri tabuľky kompaktujúcich delta pre automatické a manuálne metódy kompaktácie.

Použi predvolené runtime v Spark

Keď Spark píše tabuľku, použite Fabric Spark runtime 2.0 alebo novšie predvolené nastavenia:

V runtime Fabric Spark 1.3 sú k dispozícii adaptívna cieľová veľkosť súboru, ciele na zhutnenie na úrovni súboru a vektory na vymazanie ako voliteľné nastavenia.

Keď Pipeline Copy activity alebo Dataflow Gen2 zapíše tabuľku, skontrolujte výsledné rozloženie súboru a naplánujte údržbu samostatne. Nepredpokladajte, že títo autori aplikujú predvolené nastavenia Spark runtime.

Dôležité

Dataflow Gen2 jazerné destinácie, ktoré používajú inkrementálne obnovovanie, nepodporujú OPTIMIZE alebo REORG TABLE. Dodržiavajte obmedzenia inkrementálneho obnovovania Dataflow Gen2.

Prevencia a zhutnenie malých súborov

Pre tabuľky písané Sparkom uprednostňujem automatickú kompakciu. Táto funkcia vyhodnocuje fragmentáciu tabuliek po zápise a kompakciu vykonáva len vtedy, keď je to potrebné. Eliminuje potrebu samostatnej kontroly zdravia stola pred údržbou.

Použite nasledujúce usmernenia pre výnimky a doplnkové vlastnosti:

Scenár Odporúčaný postup
Tabuľka písaná iskrou Zapnite automatickú kompakciu ako predvolenú stratégiu údržby.
Streamovanie alebo mikrodávkové zápisy Zapnite automatickú kompakciu a optimalizujte zápis na zníženie hromadenia malých súborov.
Pracovné záťaže s prísnymi požiadavkami na latenciu zápisu Plánujte OPTIMIZE samostatne namiesto automatického automatického zhutňovania.
Existujúca tabuľka s nahromadenými malými súbormi Spustite jednorazový test OPTIMIZEa potom zapnite automatickú kompakciu pre priebežnú údržbu.
Tabuľky s častými aktualizáciami, vymazaniami alebo zlúčeniami Majte zapnuté deletion vectory a automatickú kompakciu .

OPTIMIZE kompaktuje súbory a automaticky čistí vektory na vymazanie súboru, keď je viac ako 5% záznamov referencovaných vektormi na vymazanie. Používajte len REORG TABLE ... APPLY (PURGE) vtedy, keď musíte fyzicky vymazať záznamy pod touto hranicou alebo splniť konkrétnu požiadavku na dodržiavanie predpisov.

Poznámka

Automatická kompakcia vyčistí deletion vektory len vtedy, keď partícia dosiahne aj svoj spúšťač malých súborov. Ak pracovná záťaž vykonáva aktualizácie alebo maže bez generovania malých súborov, pravidelne spúšťajte OPTIMIZE na vyčistenie kvalifikovaných vektorov na vymazanie. Používajte REORG TABLE ... APPLY (PURGE) , keď musíte vynútiť fyzické vyčistenie.

Bežte VACUUM podľa samostatného harmonogramu na odstránenie nereferencovaných súborov po uplynutí doby uchovávania. VACUUM Obnovuje úložisko, ale nezlepšuje aktívne rozloženie súborov.

Upozornenie

Neskracujte VACUUM dobu uchovávania bez toho, aby ste zhodnotili požiadavky na cestovanie v čase a súčasných čitateľov alebo autorov. Príliš skoré odstránenie súborov môže spôsobiť, že požadované verzie tabuliek nie sú dostupné.

Organizácia dát pre preskakovanie súborov

Používajte tekuté zhlukovanie pri opakujúcich sa filtroch alebo spracovateľských vzoroch, ktoré profitujú z lepšieho preskakovania súborov. Kvapalné zhlukované tabuľky vyžadujú OPTIMIZEautomatickú kompakciu na usporiadanie novo zapísaných dát.

Vyhnite sa štandardnému rozdeleniu hier. Používajte ho, keď konkrétna požiadavka ospravedlňuje prevádzkové kompromisy, napríklad izoláciu súbežných zapisovateľov, ktorí aktualizujú, mažú alebo zlučujú dáta naprieč disjunktnými partíciami. Viac informácií nájdete v článku Kedy použiť partingovanie.

Pre existujúce rozdelené tabuľky zvážte Z-Order , keď selektívne predikáty bežne filtrujú na tých istých stĺpcoch v rámci partície.

Optimalizujte tabuľky spravované skladom

Fabric Data Warehouse riadi fyzické rozloženie Delta stola bez ohľadu na spôsob prijímania.

Využite strategické kontroly, ktoré Warehouse sprístupňuje, na doladenie rozloženia dát:

  • Aplikujte dátové zhlukovanie na veľké tabuľky, keď dotazy opakovane používajú selektívne predikáty na tých istých stĺpcoch.
  • Nechajte V-Order zapnutý pre čítanie orientované a zmiešané pracovné zaťaženia. V-Order je predvolene zapnutý.
  • Zvážte vypnutie V-Order pre skladové záťaže náročné na zápis.

Upozornenie

Deaktivácia V-Order je operácia na úrovni skladu, nevratná. Otestujte kompletnú záťaž čítania a zápisu predtým, než ho vypnete.

Pre kompletné usmernenia o sklade pozri Výkonnostné usmernenia v Fabric Data Warehouse.

Optimalizácia zrkadlených dát

Vaša schopnosť zlepšiť fyzické rozloženie závisí od toho, či Fabric replikuje dáta alebo odkazuje na zdrojové súbory:

  • Zrkadlenie databázy: Fabric replikuje zdrojové dáta do Delta tabuliek v OneLake a spravuje rozloženie a údržbu súborov V-Order. Nemôžete priamo nastaviť veľkosť cieľového súboru, čistenie deletion-vector, liquid clustering, partitioning ani V-Order na zrkadlovom mieste.
  • Zrkadlové katalógy: Fabric synchronizuje metadáta a používa skratky OneLake na odkazovanie na zdrojové dáta priamo na mieste. Fabric tieto súbory neprepisuje ani neudržiava. Zlepšiť fyzické rozloženie a čistenie v zdrojovom systéme, keď to podporované funkcie umožňujú. Tieto zmeny sú viditeľné cez skratky bez vytvárania ďalšej kópie v Fabric.

Pre databázovo zrkadlené dáta:

  • Používajte selektívne predikáty a vyhýbajte sa zbytočným stĺpcom v Spark a SQL dotazoch.
  • Navrhnúť Power BI sémantické modely a DAX merania pre efektívnu spotrebu Direct Lake.

Pre zrkadlové katalógy:

  • Použite podporované funkcie údržby a rozloženia tabuliek na zdrojovej platforme.
  • Vyhodnoťte zdrojový súbor a distribúciu skupín riadkov pre používateľov Fabric, ktorí dotazujú na skratky.
  • Pre Direct Lake zvážte vytvorenie dodatočnej dimenzionálne modelovanej V-usporiadanej servírovacej vrstvy, keď zdrojové rozloženie nespĺňa požiadavky na výkon.

Pre koncepty zrkadlenia, typy a podporované zdroje pozri Čo je zrkadlenie v Fabric? a Ako funguje zrkadlenie metadát.

Aplikujte optimalizáciu špecifickú pre spotrebiteľa

Spark a SQL analytics endpointy fungujú dobre na rovnakom adaptívnom rozložení lakehouse. Používajte adaptívnu cieľovú veľkosť súboru, zabraňte nadmernému množstvu malých súborov a aplikujte tekuté zhlukovanie pri meraných predikátoch, ktoré profitujú z lepšieho preskakovania súborov. Nezapájajte V-Order len kvôli výkonnosti koncových bodov v Spark alebo SQL analytics. Pre podrobnosti špecifické pre engine pozri SQL analytics Endpoint Performance Considerations.

Power BI Direct Lake

Direct Lake používa rovnaké základné Delta tabuľky, ale pridáva odporúčania týkajúce sa transkódovania a inkrementálneho rámcovania:

  • Rozloženie súborov a skupín riadkov: Vyhnite sa malým skupinám riadkov a nerovnomernému rozdeleniu skupín riadkov, čo vytvára viac segmentov stĺpcov VertiPaq a zvyšuje režijné náklady na transkódovanie.
  • V-Order: Riaďte sa špecifickým odporúčaním producenta v usmerneniach pre krížové pracovné zaťaženie. Pre tabuľky písané Sparkom, ktoré sa primárne spotrebovávajú cez Direct Lake, povolte V-Order alebo použite readHeavyForPBI profil zdrojov.
  • Vzory aktualizácií: Uprednostňujte vhodné vzory aktualizácií , kde je to možné, aby ste zachovali existujúce súbory Parquet a podporili inkrementálne rámcovanie.

Poznámka

Direct Lake zvyčajne dosahuje najlepšie výsledky pri skupinách riadkov medzi 1 a 16 miliónmi riadkov. Vyhodnoťte rozdelenie v skupinách riadkov a výkon Direct Lake pred zmenou prostredia podporovaného producenta.

Pre tabuľky písané Sparkom nastavuje spark.sql.parquet.native.writer.maxRowGroupRowCount maximálny počet riadkov na skupinu riadkov, keď natívny výkonný engine zapisuje súbory Parquet. Predvolená hodnota je 0, ktorá neukladá maximum. Ak analýza ukáže, že veľkosť skupín riadkov ovplyvňuje výkon Direct Lake, nastavte testovaný limit pred zápisom alebo prepísaním tabuľky. Napríklad:

spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)

Nenastavujte limit len na dosiahnutie konkrétneho počtu riadkov. Šírka riadku, kompresia, distribúcia súborov a paralelizmus kapacity tiež ovplyvňujú výkon. Použite Delta Analyzer na vyhodnotenie výsledného rozloženia.

Pre podrobné pokyny o rámovaní, transkódovaní, skupinách riadkov, vzoroch aktualizácie a Delta Analyzeri pozri Pochopenie výkonu dotazov Direct Lake.

Aplikujte vedenie na vrstvy medailónov

Bronzová, strieborná a zlatá označujú účel a zdokonalenie dát. Neurčujú, či je rozloženie spravované používateľom alebo systémom, a nevyžadujú samostatné kópie pre každého spotrebiteľa.

Vrstva Hlavný cieľ Usmernenie naprieč pracovnou záťažou
Bronz (pristátie) Zachovať vernosť zdroja a priepustnosť prijímania Uprednostniť priepustnosť zápisu pri zachovaní tabuliek písaných Sparkom s automatickou kompakciou. Vyhnite sa Power BI Direct Lake sémantickým modelom na surových Bronze tabuľkách, pokiaľ model a dátový tvar nie sú zámerne navrhnuté na tento účel.
Striebro (kurátorské) Poskytnúť overené, konformované údaje na opätovné použitie Znovu použite tabuľku naprieč kompatibilnými Fabric používateľmi. Pre Spark-písané lakehouse tabuľky zapnite V-Order len vtedy, keď je Direct Lake primárnym spotrebiteľom.
Zlato (podávanie) Slúžiť obchodne pripravené dimenzie, fakty, agregáty a analytické modely Preferujem túto vrstvu pre sémantické modely Direct Lake. Opätovne použite tabuľku medzi kompatibilnými spotrebiteľmi a aplikujte špecifické kontroly pre výrobcu popísané v tomto článku.

Vyriešiť problémy s rozložením a údržbou

Používajte sanáciu s vedomím producenta. Aplikujte príkazy na údržbu Spark na tabuľky lakehouse, keď cieľový režim podporuje tieto operácie. Zaobchádzajte so signálmi ako s indikátormi, nie ako univerzálnymi prahmi, a overujte ich podľa vzoru zápisu tabuľky a výkonnosti spotrebiteľov.

Podmienka Signál Stôl Lakehouse Skladová tabuľka
Nadmerné malé súbory Počet súborov rastie rýchlejšie ako aktívna veľkosť tabuľky a súbory zostávajú pod adaptívnym cieľom. So Sparkom spustite jednorazové zhutnenie OPTIMIZE existujúceho backlogu a potom zapnite automatickú kompakciu. Pre Pipeline Copy activity alebo Dataflow Gen2 zápisy sa podporovala údržba lakehouse samostatne. Žiadna akcia. Zhutnenie skladov je automatické.
Staršie nadrozmerné súbory Súbory zostávajú oveľa vyššie ako aktuálny adaptívny cieľ a príliš málo súborov obmedzuje paralelizmus skenovania. Prepíšte tabuľku pomocou prepísania alebo CREATE OR REPLACE TABLE AS SELECT s povolenou adaptívnou cieľovou veľkosťou súboru . Žiadna akcia. Warehouse automaticky spravuje veľkosť súboru.
Akumulácia delečných vektorov DESCRIBE HISTORY Metriky ukazujú, že vektory vymazania sa pridávajú alebo aktualizujú rýchlejšie, než ich kompaktácia odstráni, čo môže zvýšiť náklady na čítanie. Majte zapnutú automatickú kompakciu . Ak sa vektory vymazania hromadia bez vyvolania kompaktácie malých súborov, naplánujte OPTIMIZE. Použitie REORG TABLE ... APPLY (PURGE) len na explicitné požiadavky na vyčistenie. Žiadna akcia. Čistenie je riadené systémom.
Slabé preskakovanie súborov Selektívne predikáty prehľadávajú veľkú časť tabuľky alebo hodnotenie kvality zhlukovania ukazuje slabú organizáciu. So Sparkom môžete nakonfigurovať zhlukovanie tekutín alebo použiť Z-Order pre existujúcu rozdelenú tabuľku. Konfigurujte dátové klastrovanie v sklade.
Režijné náklady na transkódovanie Direct Lake Delta Analyzer ukazuje nadmerné množstvo súborov, malé skupiny riadkov alebo rozsiahle retranskódovanie po aktualizáciách. Kompaktne malé súbory, prezerajte skupiny riadkov a aplikujte V-Order na tabuľky písané Sparkom. Voliteľne nakonfigurujte tekuté zhlukovanie na zlepšenie kvality kompresie v súboroch Parquet. Majte zapnutý V-Order a vyhodnocujte dátové zhlukovanie.
Rast nereferencovaného úložiska súborov Úložisko OneLake rastie rýchlejšie ako aktívna veľkosť tabuľky po operáciách zmeny dát. Postupujte VACUUM podľa požiadaviek na udržanie zamestnancov. Žiadna akcia. Čistenie je riadené systémom.

Pre zrkadlové dáta postupujte podľa špecifickej remediácie producenta v Optimalizujte zrkadlené dáta. Zrkadlenie databáz je riadené systémom; Pre zrkadlové katalógy aplikujte podporovanú údržbu v zdrojovej platforme.

Pre stoly do jazerných domov zahŕňajú možnosti inšpekcie podporované Sparkom:

  • Spustite na DESCRIBE DETAIL kontrolu počtu súborov, celkovej veľkosti a vyhodnotenej delta.targetFileSize.adaptive vlastnosti.
  • Bežte DESCRIBE HISTORY skontrolovať vzory písania a históriu údržby.
  • Použite Delta Analyzer, keď potrebujete podrobnú analýzu skupín riadkov a update-pattern pre Direct Lake.

Skontrolujte priemernú veľkosť súboru

Použite DESCRIBE DETAIL na výpočet priemernej veľkosti súboru ako počiatočného ukazovateľa rozloženia tabuľky:

details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()

table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
    details["sizeInBytes"] / num_files / (1024**2)
    if num_files
    else 0
)

print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")

Priemer môže skryť skreslenie medzi partíciami alebo nedávnymi a predtým kompaktovanými súbormi. Ak priemer naznačuje možný problém s rozložením, skontrolujte jednotlivé súbory Parquet alebo použite Delta Analyzer na vyhodnotenie rozloženia pred zmenou nastavení údržby.

Kedy vytvoriť ďalšiu tabuľku

Nevytvárajte ďalšiu fyzickú tabuľku len preto, že dáta spotrebúva viacero Fabric enginov.

Vytvorte ďalšiu tabuľku, ak má nezávislý účel, napríklad:

  • Transformácia alebo agregácia, ktorá mení zrno dát alebo ich obchodný význam.
  • Rôzne požiadavky na bezpečnosť, uchovávanie alebo kvalitu dát.
  • Požiadavka na latenciu alebo obnovenie, ktorú zdieľaná tabuľka nedokáže splniť.
  • Spotrebiteľsky špecifické usporiadanie, ktorého meraný prínos prevyšuje náklady na ukladanie, spracovanie, pôvod a riadenie.