Reporting na F2 bez Power BI licence: změřil jsem Fabric Apps

Firma s kapacitou menší než F64, třeba F8, a dvě stě lidí, kteří reporty jen čtou. Pod F64 potřebuje každý z nich Pro nebo PPU. Podle přehledu licencí se to týká všech Power BI položek: reportů, sémantických modelů, dashboardů, stránkovaných reportů a dalších. Dá se těm lidem ukázat data jinak? Napadlo mě zkusit Fabric Apps (zatím v preview), tedy vlastní webovou aplikaci hostovanou přímo ve Fabricu. Co Fabric Apps jsou, jsem popsal v článku Fabric Apps – náhrada Power BI reportů? a novinky k nim v přehledech z Buildu 2026 a FabConu v Barceloně. Tentokrát mě zajímala licence čtenářů. Fabric App mezi Power BI položkami není (položka Org apps v tom seznamu znamená organizační aplikace Power BI, ne Fabric Apps) a na položky mimo Power BI stačí na F kapacitě licence Free. Výslovně to ale Learn pro Fabric Apps nepíše, tak jsem si to postavil a změřil ve vlastním tenantu na nejmenší kapacitě F2.

Nejde o návod, jak obejít licencování. Je to záznam z jednoho testu: co fungovalo, kde jsem narazil a co to stálo. Test jsem zmínil i v dílu podcastu Cesta do Fabricu o FabConu v Barceloně, který jsme natočili s Vojtou a Ondrou.

Co jsem postavil

Kapacita F2 v North Europe a na ní jeden workspace. Do warehouse jsem nahrál leden 2019 z veřejných dat NYC Yellow Taxi, tedy 7,66 milionu jízd, a k tomu číselník zón. Nahrání přes CREATE TABLE AS SELECT z veřejného parquetu trvalo na F2 36 sekund.

Nad tím stojí tři předpočítané tabulky: jízdy po dnech a čtvrtích, po hodinách a po zónách. Proč předpočítané, k tomu se dostanu. Na tyhle tabulky jsem nasadil row-level security ve warehouse: každý uživatel vidí jen svou čtvrť.

Aplikaci jsem postavil přes Rayfin, což je SDK a CLI, na kterém Fabric Apps stojí. Je to React aplikace s jedním konektorem na warehouse, čtyřmi KPI, dvěma grafy a tabulkou nejvytíženějších zón. Nasazení příkazem rayfin up trvalo 18 sekund. Ve workspace přibyly dvě položky: samotná aplikace a API for GraphQL, přes které aplikace čte data z warehouse.

Test dělal uživatel jen s licencí Fabric Free a s rolí Viewer ve workspace. V tenantu jsem vypnul nastavení Users can try Microsoft Fabric paid features, aby mu Power BI nemohlo samo přidělit šedesátidenní trial. Se zapnutým nastavením by test nic nedokazoval.

Výsledek: aplikace se otevře

Uživatel se do aplikace na F2 přihlásil a viděl data. RLS ve warehouse fungovala: místo 7,66 milionu jízd viděl jen Manhattan, tedy 6,93 milionu.

Past první: delegated, ne application

Konektor se přidává jedním příkazem:

rayfin connector add --type fabric-warehouse --workspace-id <workspace-id> --item-id <warehouse-id> --name taxi --operations read

Podle Microsoft Learn vznikne konfigurace s delegated, tedy s dotazy pod přihlášeným uživatelem. Moje verze CLI (1.36.2) ale do rayfin.yml zapsala auth.type: application. RLS ve warehouse potřebuje delegated, tak to před nasazením zkontrolujte. Pozor i na opakované connector add, hodnotu přepíše zpátky.

Past druhá: RLS chrání jen to, na co ji nasadíte

Do aplikace jsem schválně pustil i syrovou tabulku jízd, na kterou jsem RLS nedal. Uživatel, který na dashboardu viděl jen Manhattan, si přes ni za necelou sekundu spočítal tržby za celé město. Každá tabulka, kterou konektor vystaví, musí mít vlastní RLS.

Souhlas při prvním přihlášení

Při prvním přihlášení chce Fabric po uživateli souhlas, že aplikace smí přistupovat k warehouse jeho jménem. Pokud máte souhlasy uživatelů v tenantu zakázané, musí ho udělit admin.

Kam se schová business logika

Největší omezení je jinde. Aplikace nepustí vlastní SQL a nad warehouse nemá nic jako measures. Konektor fabric-warehouse vytvoří ve workspace položku API for GraphQL nad warehouse. Aplikace se jí ptá přes typovaného TypeScript klienta z Rayfin SDK (balíček @microsoft/rayfin-data), třeba client.connectors.taxi.Trips.groupBy(['paymentType']).aggregate(…), a klient z toho sestaví GraphQL dotaz. Ručně psaný GraphQL ani fetch šablona nepovoluje. Umí výběr sloupců, filtr, řazení, stránkování a seskupení.

Seskupení je lepší, než jsem čekal. Součet a počet po typech platby nad celou tabulkou 7,66 milionu jízd vrátil server za 3,5 sekundy. Omezení je ale dost:

Jen sum, avg, min, max a count, a to jen nad číselnými sloupci. Klasické COUNT(*) neexistuje.
Žádné výrazy. Podíl spropitného na tržbách spočítáte až v aplikaci, ne v dotazu (nebo předem ve view).
Agregaci nejde seřadit ani omezit na top N. Nejvytíženější zóny řadí až TypeScript.
Jedno čtení vrátí nejvýš sto tisíc řádků. Podle limitů API for GraphQL je to zároveň strop pro stránkování celkem, na víc potřebujete několik dotazů s různými filtry.

Logika se proto přesune do warehouse. Předpočítané tabulky fungují, a fungují i views: podíl spropitného, který klient neumí, jsem spočítal ve view a API for GraphQL ho vrátí stejně jako tabulku. RLS se přitom neztratí, filtr se podle dokumentace uplatní při čtení ze zdrojové tabulky. Jen view za vás CLI samo nepřidá: connector inspect ho vypíše, ale connector add vygeneruje entity jen pro tabulky. Entitu pro view musíte dopsat ručně (nebo o to požádat AI agenta) a bez primárního klíče umí jen čtení.

Pro čtyři KPI a pár grafů to stačí. Model s desítkami measures, time intelligence a calculation groups ale takhle nepřepíšete.

Kolik to stálo

Fabric App běží na kapacitě workspace. Podle přehledu spotřeby se účtuje API for GraphQL, případná SQL databáze aplikace, User Data Functions a uložení a čtení statických souborů v OneLake. Samotná hostingová služba a přihlašování se zatím samostatně neúčtují. Vlastní databázi aplikace jsem vypnul, data čte jen konektor. Dotazy ale končí ve warehouse a ty jdou z kapacity, na které warehouse leží, typicky z téže jako vaše loady.

Aplikaci jsem desetkrát načetl. V historii dotazů warehouse (queryinsights.exec_requests_history) to bylo 45 dotazů, dohromady 4,2 sekundy běhu a 1,3 sekundy CPU. Capacity Metrics za den testu ukázala u API for GraphQL 6,3 CU sekundy a u položky aplikace 3,9 CU sekundy. Warehouse za celý den, včetně nahrání 7,66 milionu řádků, spotřeboval zhruba 4 630 CU sekund. F2 má na den k dispozici 172 800 CU sekund, takže čtení z aplikace je zanedbatelné.

Fabric App, nebo Power BI?

Obě cesty mají své místo, liší se hlavně v tom, kdo a jak report staví.

Fabric App

Čtenáři nepotřebují Power BI licenci, aplikace čte z warehouse.
Vzhled i chování máte plně pod kontrolou.
Konektor na warehouse umí i zápis, takže do aplikace jde dostat třeba schvalování nebo opravu dat. Úprava a mazání potřebují primární klíč. Ve warehouse si ho deklarujete jako NOT ENFORCED, u dimenze to není problém. U číselníku zón jsem to vyzkoušel: po deklaraci klíče ho konektor načetl a úprava záznamu přes API for GraphQL prošla. Unikátnost klíče ale warehouse nehlídá, to je na vás.
Celé je to kód, takže ho můžete verzovat v Gitu a psát s AI agentem. Šablona Rayfinu mu rovnou dodává vlastní skilly.
Na druhou stranu: bez kódu (nebo AI) se neobejdete. Kliknete na čtvrť v grafu a chcete, aby se podle ní přefiltrovala tabulka? V Power BI to máte vestavěné v platformě a nemusíte objevovat kolo. Tady to někdo musí naprogramovat.
Business logika se musí vejít do předpočítaných tabulek, views a pár řádků TypeScriptu.

Power BI

Report naklikáte bez řádku kódu a Power BI je léty prověřené v produkci.
Sémantický model vám dá measures, time intelligence, calculation groups a RLS přímo v modelu.
K Power BI patří i export do Excelu, odběry e-mailem, mobilní aplikace nebo Copilot.
Pod F64 ale každý čtenář potřebuje Pro nebo PPU.

Rozhodoval bych se podle čtyř otázek. Kolik je čtenářů a kolik by stály jejich licence? Kolik CU spotřebují jejich dotazy? Každé otevření aplikace posílá dotazy do warehouse a s dvěma sty čtenáři a bez předpočítaných tabulek se to na malé kapacitě může prodražit. Jak složitá je business logika: vejde se do pár předpočítaných tabulek, nebo potřebujete sémantický model? A máte v týmu někoho, kdo aplikaci napíše a bude ji udržovat?

Závěr

Dá se pod F64 ukázat data lidem bez Pro/PPU? S Fabric App ano. Uživatel jen s licencí Fabric Free, bez Pro a bez trialu, otevře na F2 Fabric App nad warehouse a RLS ve warehouse platí.

Fabric Apps jsou alternativa pro jednoduché přehledy. Na licencích pro čtenáře se tak ušetřit dá, ale zaplatíte to jinde: vývojem a údržbou vlastní aplikace a business logikou poskládanou z předpočítaných tabulek a views místo measures. Pro jednoduchý přehled pro velkou skupinu čtenářů bych o tom uvažoval. Jako náhradu bohatého sémantického modelu ne. Jen pozor: Fabric Apps jsou zatím v preview. Čtenáři bez licence Power BI je dnes otevřou a hosting se samostatně neúčtuje, jenže licenční model se do GA ještě může změnit.

Oficiální dokumentace pro další studium: