Kolik stojí Direct Lake v Microsoft Fabric?

tl;dr Direct Lake vychází levněji než Import, hlavně proto, že mu chybí refresh Importu, respektive ve stejné podobě. Direct Lake má o něco dražší DAX dotazy a nese další overhead, který část ušetřeného výkonu vrátí zpátky. Dobře nastavený Import s inkrementálním refreshem pořád dokáže oba porazit a je to validní alternativa. Když měříš cenu Direct Lake, nezapomeň započítat i operace na Lakehouse nebo Warehouse, které jsou na Direct Lake navázané, a dávej pozor na warm-up burst na menších kapacitách. Víc v blogu.

Disclaimer: pokud není řečeno jinak, všechna měření běží na Trial F64 a Direct Lake nad OneLake. Všechny pojmy, které tu použiju, najdeš rozebrané spolu s celým Direct Lake tady.

Cena Direct Lake v Capacity Units (CU)

Direct Lake je cool, ale změřil sis, kolik vlastně stojí? A cenou v tomhle blogu myslím, kolik Capacity Units spotřebuje. Nějaká čísla jsem už dal v předchozím blogu, kde Direct Lake rozebírám do detailu, ale byl to jenom malý výřez jedné konkrétní operace. Abych dostal celkově spolehlivá čísla, musel jsem se dostat o kus hlouběji.

V tomhle blogu si tedy uděláš obrázek, kolik Direct Lake může stát a jak na tom je proti Importu. Přesná čísla bez kontextu použití moc neříkají, takže ke každému tvrzení uvádím i prostředí, ve kterém bylo naměřené. Co ale nejspíš obstojí samo o sobě, jsou procentuální rozdíly mezi jednotlivými nastaveními a možnostmi.

Capacity unit (CU), přesněji Capacity unit second (CU-s), je základní měřicí jednotka pro sledování spotřeby kapacity Microsoft Fabric. Matematika za tím je jednoduchá. Podle tvého Fabric SKU, řekněme F2, máš 2 CU za sekundu. Za měsíc tedy máš počet sekund v měsíci krát 2. Tvoje měsíční kapacita tak může vyjít třeba na 5 milionů CU-s. Jak je utratíš, je na tobě.

Kategorie nákladů Direct Lake

Než ti ukážu všechna čísla, zasypu tě ještě troškou textu. Pokud se ti číst nechce, klidně scrolluj. Jestli ale ještě čteš, chtěl bych probrat přesněji, co všechno se na ceně Direct Lake podílí, protože to není jedna položka.

Kategorie jsou:

• Refresh / Framing

• Warm up and Querying

• Storage Item Cost

První v chronologickém pořadí, protože se stane jako první, je Refresh, v terminologii Direct Lake framing. Takhle se dostanou data z Delta tabulky dovnitř. Ve výchozím stavu se to děje automaticky a stojí to zanedbatelně málo CU-s, zanedbatelně znamená od 10 do 17 CU-s z 5 milionů na nejnižší kapacitě, to je vskutku málo.

Teď druhá, a zároveň největší položka. Tyhle dvě věci jsou v pozadí v podstatě to samé. Warmup je proces, který natáhne sloupce do VertiPaq a umožní ti vůbec číst nebo zobrazovat vizuály. Tohle je nejdražší část Direct Lake, aspoň na dobrém modelu. Pro představu, jednoduchý sémantický model s 5 tabulkami, každá kolem 10 sloupců, a faktovou tabulkou o 12 milionech řádků, může stát 650 CU-s. Číslo může jít níž, ale klidně i výrazně výš, počítej s tím, že jde o víceméně dobře optimalizovaný model.

Nakonec to, co budeš dělat nejčastěji, je querování/dotazování. Jinými slovy, koukání na vizuály ve tvém reportu. Říkám querování, protože přesně to se děje, posíláš DAX dotazy, aby ti vrátily data pro vizuály. V mých testech jsem se nedíval na obrázky, ale pálil jsem dotazy jako uživatel reportu. Tady číslo může vyjít prakticky jakékoli, ale nejspíš to bude ta největší položka. Záleží i na tom, jak máš navržené DAX a model, kolik máš uživatelů a jak jsou aktivní. V mém setupu stálo kolem 400 dotazů 1400 CU-s. Neboj, tabulku dostaneš později.

Poslední náklad, možná trochu skrytý, a vlastně skutečně je, protože ho neuvidíš, pokud sleduješ jenom sémantický model. Storage Item Cost. Storage item je zde myšleno jako Lakehouse nebo Warehouse. Model Direct Lake zavádí overhead na storage itemu. Prakticky záleží na tom, jestli máš zapnuté "Keep your Direct Lake data up to date" nebo ne. Pokud ne, žádný dodatečný náklad nevzniká, protože tahle operace je právě ten sync, co drží data čerstvá. Pokud tuhle funkci máš zapnutou, což je výchozí stav, naúčtují ti zhruba 0,624 CU-s za 30 sekund, po celou dobu, kdy je tvůj sémantický model aktivní. A právě to "aktivní" je zapeklité, rozeberu to v další sekci.

Udržování Direct Lake dat aktuální

Jak jsem zmínil, Direct Lake zavádí overhead na storage itemu (Lakehouse) ve chvíli, kdy k němu připojíš sémantický model typu Direct Lake. Tento overhead se účtuje přes Lakehouse nebo Warehouse a cena je za model. Pojďme na rychlou matematiku. Jeden model - aktivní 24 hodin, to je 0,624 CU-s za 30 sekund, tedy 1,248 CU-s za minutu, 74,88 CU-s za hodinu, 1797 CU-s za den. Pro deset modelů je to 17 971 CU-s. Z denní kapacity F2 je to zhruba 10 % jen na sync.

Jestli je to hodně nebo ne, záleží na tvém use case. Pokud tahá data jednou denně, jde o dost promarněných CU, a Direct Lake asi ani nepotřebuješ. Pokud potřebuješ data updatovat padesátkrát denně, je to potom už trošku lepší koupě.

Tenhle náklad ale nevzniká automaticky jenom proto, že je sémantický model navázaný na Lakehouse. Zmínil jsem "aktivní" sémantický model, tak si to vysvětlíme.

Při testování jsem si myslel, že "aktivní" sémantický model je model, který má rezidentní column segmenty. Zjistil jsem, že to není pravda, a je to primárně otázka framingu. Jak jsem řekl, pokud vypneš ""Keep your Direct Lake data up to date" (moc se mi to nechce překládat), sync bude nulový a žádný "aktivní" sémantický model nemáš. Pokud to máš zapnuté, platíš ve chvíli, kdy je model framovaný, bez ohledu na to, jestli je něco nahrané v paměti. Sync se sám od sebe časem zastaví a dá se to i vynutit refreshem Clear Values. Když provedeš Clear Values, ztratíš rezidenci i framing a sync se zastaví. Pokud bys hned potom model znovu zaframoval, aniž bys ho vůbec queroval, sync se zase rozjede.

Spotřeba CU: Direct Lake proti Importu

Okej. Konečně to, pro co jsi přišel. Nejdřív ti představím testovací prostředí, ať máš kontext a dokážeš si to přenést na vlastní scénář.

Metodika a prostředí

Tomuhle testu říkám "9 to 5". V podstatě sleduju zhruba 8hodinový pracovní den. Běžel simultánně na F64 a F2, celkem 9 sémantických modelů, 7 z nich na F64, dva na F2.

Každý test začíná plným refreshem pro Import, plným warmupem pro Direct Lake a partial refreshem pro inkrementální Import. Každý model je zhruba stejný, 5 tabulek, 1 faktová tabulka o 12 milionech řádků, optimalizované parquety a zdravý model postavený podle dobré praxe.

Za těch 8 hodin vystřílel kolem 380 dotazů předem definovaných tvarů s měnícími se filtry, které simulují procházení stránek reportu. Dotazy napodobují jednoduché kartové vizuály, tabulky nebo matice. Vždycky šlo jen o jednoho "uživatele". Byla tam i hodinová obědová pauza, kdy se všechny modely zastavily, částečně proto, abych viděl, jestli pauza nějak zhorší výkon Direct Lake, na což by Import měl být víceméně imunní.

Test jsem spustil v 9 replikacích, takže celkem šlo o zhruba 71 hodin testování na 9 modelech současně, 30 780 dotazů celkem.

Replikací a dlouhých běhů jsem udělal hodně, abych vyrovnal některé nesrovnalosti, které se stávají, třeba že se rychlé dotazy vůbec nenaúčtují nebo se v Capacity Metrics vůbec neobjeví, což se často dělo u Importu. Celková čísla ale byla docela konzistentní.

Jedna poznámka k setupu, všechny modely na Lakehouse sdílely ten samý Lakehouse. Dělal jsem i pár kontrolních solo testů, ale spíš na odhalení anomálií než jako hlavní měření. Lakehouse samotný byl dost přeplněný dalšími tabulkami a dalším obsahem, i když během testů na něm neběželo nic jiného, ale všechny modely četly stejnou sadu pěti tabulek. Celkově měl Lakehouse mnohem víc dat než jeho protějšek Warehouse. To je jenom kontext k výsledkům níž, protože Warehouse z nich vychází o něco lépe. Netvrdím, že je to kvůli rozdílné míře "znečištění" obou zdrojů, ale chtěl jsem zmínit, že setup nebyl úplně čistý, třeba příště.

Ale znovu, všechny tabulky byly rovnocenné, se stejnou předem definovanou sadou dotazů.

Výsledky

Výsledky jsou mediány z 9 replikací. Day range ukazuje rozptyl jednotlivých běhů. Všechny hodnoty jsou v CU-s.

F64

Model	Nastavení nebo refresh	Dotazy	Celkem za den	vs baseline	Rozsah dne
Import, full refresh	2 412,6	1 004,2	3 541,9	baseline	3 255 - 4 865
Import, incremental	1 030,8	475,6	1 522,6	-57,0%	1 183 - 2 250
Direct Lake on SQL endpoint	685,8	1 576,3	2 241,4	-36,7%	1 802 - 3 186
Direct Lake on OneLake	642,5	1 548,5	2 191,0	-38,1%	1 724 - 2 866
Direct Lake on SQL, fallback off	646,1	1 463,5	2 103,2	-40,6%	1 904 - 3 301
Direct Lake on OneLake, Warehouse source	318,0	1 416,2	1 748,0	-50,6%	1 321 - 1 950
Direct Lake on SQL, Warehouse source	183,5	1 299,5	1 527,3	-56,9%	1 025 - 2 064

F2

Model	Nastavení nebo refresh	Dotazy	Celkem za den	vs baseline	Rozsah dne
Import F2	2 670,5	971,6	3 574,3	baseline	3 050 - 3 925
Direct Lake on OneLake F2	362,3	1 172,6	1 521,0	-57,4%	1 265 - 2 018

Čísla jsou naměřená přímo na sémantických modelech. Můžeme k nim přičíst i přímý náklad storage itemů napojených na modely.

F64

Zdroj	Refresh	Sync	Celkem
Lakehouse	0	2 826,7	2 826,7
Lakehouse SQL endpoint	669,2	0,0	669,2
Warehouse	250	1 320,2	1 570,2
Zdroj strana celkem	919,2	4 146,9	5 066,1

Čísla jsou agregovaná za běh přes všechny výše uvedené modely. Refresh patří k modelům Import, Sync k Direct Lake.

Refreshe nejsou stejné

Bez kontextu to vypadá, že Direct Lake vychází v celkové spotřebě levněji než Import. A je to hlavně proto, že mu chybí refresh Importu.

Refresh sémantického modelu typu Import je asi nejdražší operace v celém Fabricu. Teď nemluvím o nějakých nových fancy featurách, co by mohly přijít. Když se ti povede stáhnout dobu trvání refreshe dolů, vyjde levněji. V mém scénáři byl refresh docela krátký, zhruba 2 minuty. Pokud refresh v průměru stojí zhruba 24 CU-s za každou sekundu běhu a moje refreshování by trvalo 15 minut, nebylo by to 2 880 CU-s celkem, ale 21 600 CU-s. Úspora Direct Lake by pak byla mnohem výraznější.

Ne všechny importové refreshe jsou ale stejné. Když uděláš inkrementální refresh, dostaneš rychlejší refresh a technicky i rychlejší dotazy, pokud trefíš sweet spot v partitioningu. To je jedna optimalizace, kterou můžeš udělat hned teď, aniž bys musel investovat čas do Direct Lake.

Jedna poznámka, při refreshi Importu můžeš zasáhnout i SQL Analytics Endpoint tvého Lakehouse. Takže tenhle náklad musíš přičíst taky. Přirozeně to záleží na tvém zdroji, ale stojí za to o tom vědět, a v tomhle konkrétním případě se to dá technicky obejít jiným konektorem, pokud SQL dotaz nepotřebuješ.

Dotazy

Samotné DAX dotazy jsou taky trochu jiné. Import má jednoznačně levnější dotazy, i když by technicky měly fungovat stejně a jedou nad stejným enginem. Zdá se ale, že Capacity Metrics k tomu přidává trochu marže, nebo Direct Lake v sobě skrývá nějakou dodatečnou práci navíc. Takže co ztratíš na Importu na refreshi, pomalu doženeš zpátky na dotazech. Musel bys ale nejspíš querovat hodně dlouho, abys se dostal na nulu.

Capacity Units samy o sobě neznamenají Capacity Utilization

Cena v CU vyšla na obou kapacitách stejně, což je dobré znamení. Samotná čísla CU ti ale neřeknou celý příběh. Existuje něco jako Capacity Utilization %, což se obvykle měří k danému okamžiku a říká ti, jestli je tvoje kapacita v pořádku, nebo jestli začíná throttlovat. Kdybys jenom vydělil celkem spotřebovaná CU denní kapacitou, řekl by sis "v pohodě, ještě mi zbývá 40 %". Extrémně důležité ale je, jak rychle jsi spotřeboval těch 60 %.

Za tím je zase jednoduchá matematika. Nejkratší časový bod, který Capacity Metrics měří, je 30 sekund a limit v tomhle okně je 30× SKU. Pro F2 je to 60 CU-s. Trefíš dané číslo a jsi na 100 %, a věci se pak můžou rychle zvrtnout.

Existují různé typy operací, třeba Interactive a Background.

Background se rozprostírá do mnohem delšího okna než Interactive. Refresh, jedna z aktivit, ti nemusí kapacitu zabít jenom proto, že stojí hodně CU. Naproti tomu Interactive může, tam patří třeba čtení vizuálů nebo warmup Direct Lake.

Proč to zmiňuju?

Metrika	Import F2 refresh	Direct Lake F2 warm-up
CU-s	2 381	317
Typ	background	interactive
Nárůst peaku	1,4%	52,9%

Protože, jak vidíš v tabulce, i když warmup stál zlomek plného refreshe, vešel se do tak úzkého okna, že utilizaci vytáhl přes 50 %. Se dvěma takovými modely bych se nejspíš dostal do burstingu.

Takže až budeš experimentovat, počítej s tím, že u celkových CU je potřeba myslet i na to, jak se rozprostřou v čase, aby zatěžovaly kapacitu rovnoměrně.

Závěr

Jestli si z tohohle článku máš odnést jedno, tak že Direct Lake může stát za to a může vyjít levněji, ale musíš si sečíst všechna čísla, hlavně sync a warmup. "Keep your Direct Lake data up to date" jde pro každý model vypnout a udělat si programaticky drobné refreshe/framing "ručně". Záleží na tvém use case.

Přirozeně, při dobrém setupu je starý dobrý Import pořád beast a rozhodně by se neměl automaticky zavrhovat ve prospěch Direct Lake. A nakonec, pokud jsi na F2, obecně nedoporučuju na tu kapacitu dávat report vůbec, ale pokud máš něco malého, co využije silné stránky Direct Lake, proč ne.

Kolik stojí Direct Lake v Microsoft Fabric?