- Rychlost a cenu Direct Lake určuje i způsob, jakým se data ukládají do souborů, nejen samotný model.
- Stejná data uložená dvěma způsoby se mohou načítat několikanásobně dráž.
- Nejvíc pomáhá ukládat data do menšího počtu větších bloků. Fabric pro Power BI nabízí připravené nastavení, které data takto ukládá.
- Úprava obvykle nevyžaduje měnit reporty ani model.
Vojtěch Šíma porovnal na 64 modelech Direct Lake, jak způsob uložení dat mění rychlost a spotřebu kapacity. Výsledky, čísla i nastavení pro váš tým najdete v článku na jeho blogu.
Obsah 5 částí
- 01Kde se rychlost Direct Lake ztrácí?
- 02Co pomalé načítání stojí
- 03Jak Direct Lake zrychlit?
- 04Na co se zeptat svého týmu
- 05Časté otázky
Kde se rychlost Direct Lake ztrácí?
Představte si sklad. Když má model odpovědět na dotaz, musí si potřebná data nejdřív přinést ze souborů do paměti. Data v souborech leží v blocích, něco jako zboží v krabicích, a model je nosí jednu krabici po druhé. Pár velkých krabic přinese rychle, stovky malých krabic se stejným zbožím ho zdrží a stojí víc práce.
Kolik krabic vznikne, rozhoduje nástroj, který data do souborů zapisuje, a jeho nastavení. Datový inženýr na první pohled rozdíl nevidí, data jsou stejná a report ukazuje stejná čísla. Rozdíl se projeví až na rychlosti a na účtu za kapacitu.
Co pomalé načítání stojí
Každé načtení dat spotřebuje kus kapacity, kterou platíte, ať ji máte v podobě F2, nebo F64. Při jednom uživateli je rozdíl nepatrný, při desítkách lidí a několika aktualizacích denně se sčítá. V našem měření se stejná data podle způsobu uložení načítala až čtyřikrát dráž.
Jak Direct Lake zrychlit?
Ve většině případů stačí změnit nastavení zápisu dat a reporty zůstanou, jak jsou. Fabric pro Power BI nabízí připravený profil readHeavyForPBI, který ukládá data do větších bloků a zároveň zapne V-Order, funkci pro lepší kompresi. Data zapisovaná vlastními skripty v Pythonu mívají výchozí nastavení s mnoha malými bloky, takže stojí za kontrolu jako první.
Druhá věc jsou sloupce. Model načítá každý sloupec, který v něm je, i takový, se kterým nikdo nepracuje. Za mě je proto první otázka u pomalého modelu, které sloupce v něm opravdu musí být.
Na co se zeptat svého týmu
- Jakým nastavením se ukládají tabulky, ze kterých Direct Lake čte?
- Zapisuje je Spark, nebo vlastní skript v Pythonu?
- Které sloupce model obsahuje, ale nikdo je v reportech nepoužívá?
- Kdy jste naposledy měřili, kolik kapacity modely spotřebují?
Časté otázky
Musíme měnit reporty nebo model?
Většinou ne. Změna se týká způsobu, jakým se data ukládají do souborů, a reporty i model nad nimi zůstanou stejné.
Proč je první otevření reportu po aktualizaci dat pomalé?
Model si po aktualizaci načítá data ze souborů znovu do paměti. Další dotazy už čtou z paměti, takže jsou rychlejší.
Pomáhá vždycky V-Order?
Ne vždy. U většiny faktových tabulek model zlevní, u dat, která už jsou seřazená a mají málo různých hodnot, může naopak trochu přidat. Proto se vyplatí změřit, jak se chová na vašich datech.
Jak jste na tom vy?
Audit výkonu
70 000 Kčbez DPH
Načítají se vám vizuály vteřiny místo milisekund, nebo refresh trvá desítky minut? Změříme stav před a po a uvidíte konkrétní čísla.
