Jak na DP-600 a DP-700: praktický průvodce certifikacemi pro Microsoft Fabric

Proč vůbec řešit certifikace DP-600 a DP-700

Když se v podcastu Cesta do Fabricu s Vojtou Šímou bavíme o certifikacích, rád si připomínám jednoduchou hříčku se slovem „zkouška“ – beru ji spíš jako „zkusit“. Neznamená to, že musíte všechno umět na sto procent. Znamená to, že to jdete zkusit – ať už kvůli papíru, nebo kvůli vlastní zvědavosti, co všechno ještě nevíte.

Certifikace DP-600 a DP-700 jsou oproti klasickému „papíru z kurzu“ o úroveň výš. Účast na školení dokazuje, že jste někde seděli. Certifikace dokazuje, že jste aspoň jednou zvládli standardizovaný test v konkrétním čase a pod konkrétním tlakem. To může hrát roli jak u zákazníků, tak u vašeho zaměstnavatele.

Oficiální přehled najdete přímo na stránkách certifikací Fabric Analytics Engineer Associate (DP-600) a Fabric Data Engineer Associate (DP-700).

Jako lektor mám za sebou desítky zkoušek – od Windows Vista přes SQL Server až po BI developer certifikace. Ten „learning transcript“ je dnes spíš úsměvná galerie historie Microsoftu, ale má jedno společné: pokaždé jsem si z toho odnesl lepší představu, co všechno daná role pokrývá. A u Fabricu to platí dvojnásob. Platforma se vyvíjí rychle a certifikace vám pomůže udělat si mapu: tady jsou pipelines, tady notebooks, tady KQL, tady streaming, tady governance.

Pro firmy je certifikace často součástí partnerských programů – potřebují určitý počet certifikovaných lidí na konkrétní roli, aby dosáhly na vyšší partnerství. Pro vás to může znamenat zajímavější projekty nebo lepší pozici při vyjednávání o roli a sazbě. A i neúspěšný pokus má hodnotu: místo pocitu „asi něco umím“ dostanete velmi konkrétní zpětnou vazbu „tohle a tohle neumím“.

Jak zkoušky DP-600 a DP-700 vypadají v praxi

Společná struktura obou zkoušek

DP-600 i DP-700 se strukturou hodně podobají. Čeká vás:

• úvodní self-assessment dotazník,
• case study – delší text o fiktivní firmě s několika navázanými otázkami,
• hlavní blok zhruba čtyřiceti a více otázek,
• závěrečná mini case study se stejným zadáním a několika otázkami typu ano/ne.

U některých sekcí (typicky case study) se nejde vracet. Jakmile sekci opustíte, je zavřená. To vás nutí číst zadání poctivě hned napoprvé a nenechávat si „dopočtení“ na konec.

V hlavním bloku je naopak možné otázky označit jako „mark for review“, vracet se k nim a dávat k nim feedback. Celkový čas je okolo 120 minut, ale rozdělený mezi sekce – co utratíte v jedné, nedostanete v jiné. Scoring je škálovaný na 1000 bodů, hranice úspěchu je 700 a neexistují mínusové body za špatnou odpověď.

Co je typické pro DP-600

DP-600 cílí víc na analytickou část ve Fabricu. Najdete v ní víc „hands-on“ otázek:

• doplnění nebo úprava SQL dotazu,
• úprava notebooku,
• práce s analytickými nástroji nad daty ve Fabricu.

Pokud máte zkušenosti s Power BI, SQL a klasickým BI stackem, pravděpodobně se v DP-600 budete cítit „doma“ – koncepty nejsou úplně exotické, jen se přesunuly do Fabric světa.

Co je typické pro DP-700

DP-700 působí teoretičtěji. Je víc o architektuře celé datové platformy, integraci služeb a rozhodování „kdy použít pipeline, kdy notebook, kdy dataflow“. Velký důraz je na streamingová data a KQL – včetně drobných detailů.

Zajímavý kontrast, který zmiňujeme i v podcastu: na MVP Summitu v Redmondu padla otázka, kdo v reálných projektech řeší streamingová data. Rukou se zvedlo výrazně méně, než byste čekali podle obsahu DP-700. Přesto je streaming v testu hodně zastoupený – je to signál, kam Microsoft platformu směřuje.

Jak se na DP-600/700 připravit

Exam guide a Microsoft Learn jako základ

Jako první krok doporučuji otevřít si study guide pro DP-600 a study guide pro DP-700. Najdete tam:

• rozpad domén (design, implementace, operacionalizace),
• procentuální váhy jednotlivých oblastí,
• odkazy na příslušné Microsoft Learn moduly.

Tohle je oficiální „smlouva“ mezi vámi a Microsoftem – to, co je v exam guide, se v nějaké podobě promítne do zkoušky. Learn moduly se vyplatí projít cíleně: ne jen proklikat, ale pochopit koncepty a ideálně si něco zkusit ve vlastním Fabric workspace.

Practice assessments: trénink na styl otázek

Microsoft nabízí practice assessments pro vybrané certifikace, včetně DP-600 a DP-700. Hodí se hlavně na dvě věci:

• zmapovat šíři témat,
• naučit se „jak přemýšlí autor testu“.

Otázky se částečně opakují, ale ostrý test není 1:1 kopie. Cílem není se je naučit nazpaměť, ale pochopit typické distractory (odpovědi, které jsou technicky možné, ale nejsou „nejvíc Microsoft“). Dobrá hranice je cílit na stabilních ~85 % úspěšnosti – ve chvíli, kdy jí dosáhnete, máte slušnou šanci, že zkoušku zvládnete.

Videa, knihy a další materiály

Pro DP-600 dnes dává velký smysl oficiální kniha Exam Ref DP-600 Implementing Analytics Solutions Using Microsoft Fabric, na které se podíleli Štěpán Rešl, Daniil Maslyuk a Johnny Winter. Je to přípravka psaná přímo proti zkoušce – strukturovaná podle exam objektivů, se scénáři a otázkami, které dobře ladí s tím, co vás u DP-600 čeká. Pokud chcete mít jeden hlavní studijní materiál v textové podobě, za mě je tohle dobrý kandidát.

V podcastu Vojta zmiňuje i video kurzy, které prochází jednotlivé domény zkoušek a hodí se hlavně pro ty z vás, kdo raději koukáte na video než čtete knížku nebo dokumentaci. Osobně jsem tyhle konkrétní kurzy celé neprocházel, takže je nechci přehnaně vyzdvihovat, ale jako doplněk k oficiálním materiálům a hands-on práci ve Fabricu mohou dobře zapadnout do studijního mixu.

Hands-on ve Fabricu: pipelines, notebooks, KQL a spol.

Bez ohledu na to, kolik videí a článků projdete, Fabric je pořád platforma, kterou si musíte „osahat“. Ideálně si ve vlastním (nebo firemním) workspace zkuste:

• vytvořit jednoduchou data pipeline,
• zpracovat data v notebooku (Spark nebo SQL),
• vyrobit dataflow a propojit ho s modelem,
• nastavit event stream, napojit ho na Event Hubs a uložit data do Lakehouse,
• napsat pár KQL dotazů nad logy nebo eventy,
• projít základní role a oprávnění.

Nejde o to mít tři roky praxe na produkčních projektech – ale když jste danou technologii aspoň jednou viděli a něco v ní udělali, otázky se čtou úplně jinak.

Strategie u zkoušky: čas, Learn a práce s otázkami

Time management a práce se sekcemi

Základní pravidlo, které jsem si kdysi odnesl už z prvních Office testů a platí dodnes: nenechte se zadřít na jedné otázce. Pokud si nejste jistí, vyberte „nejméně špatnou“ odpověď, označte si otázku pro review a jděte dál.

U DP-600/700 je dobré:

• mít v hlavě hrubý časový plán na sekci,
• u case study nepanikařit – text je dlouhý, ale často se v něm odpovědi doslova schovávají,
• nechat si na závěr pár minut na rychlé projetí označených otázek.

Nejsou mínusové body. Prázdná odpověď je vždycky horší než rozumný tip.

Kdy (a jak) používat Microsoft Learn během testu

V online režimu máte k dispozici panel s nástroji – včetně Microsoft Learn, kalkulačky a poznámek. Zní to lákavě, ale Learn není džin z lampy, který odpoví na každou otázku za vás.

Za mě dává smysl Learn použít hlavně u faktických dotazů (typ „jaké jsou parametry F32 capacity“). U komplexních scénářů (architektura, governance, kombinace služeb) vám většinou jen zopakuje dokumentaci – tam je rychlejší opřít se o vlastní pochopení ekosystému.

Praktický postup: nejdřív projít celý test a všude něco odpovědět, teprve potom při review jít cíleně na 2–3 otázky, kde dává smysl dohledat detail v Learn.

Jak číst zadání a case study „očima autora testu“

U case study a delších scénářů je kritické číst text pomalu a s „virtuální tužkou“:

• jaké má firma omezení (bezpečnost, compliance, budget),
• jaké technologie už používá,
• jaké jsou nefunkční požadavky (latence, SLA, škálování).

Autor testu většinou neskryje správnou odpověď v esoterickém detailu služby, ale v tom, jaký kontext vám v zadání podstrčí. Když víte, že zákazník má velmi přísné požadavky na minimální oprávnění, odpověď „dej všem admin roli“ bude správná jen velmi výjimečně.

Co nás překvapilo a na co si dát pozor

Streaming a KQL v DP-700 vs. realita projektů

Jedno z největších překvapení u DP-700 je, jak velký kus testu zabírají streamingová data a KQL. V reálných projektech dnes na streamingu pracuje menšina týmů, ale v testu je to naprosto mainstream.

Najdete tam otázky na návrh streamingové architektury, rozhodování, kdy použít event stream, kdy Event Hubs, kdy co považovat za externí zdroj, a taky detaily KQL syntaxe. Není nutné být expert na každý operátor, ale je dobré mít KQL aspoň základně ošahané.

Bezpečnost, oprávnění a governance

Další téma, které se opakuje, je bezpečnost a governance. Princip minimálních oprávnění („dejte uživateli jen to, co nezbytně potřebuje“) je evergreen, který se vrací v mnoha scénářích. Typicky budete vybírat mezi různými rolemi, scopes a možnostmi sdílení a přístupu k datům.

Angličtina a typické „mikrozákeřnosti“ v otázkách

Angličtina je kapitola sama pro sebe. Case study a otázky nejsou vždy napsané „učebnicově“ a někdy máte pocit, že zadání se dá číst na dva způsoby. I proto se hodí otázku označit, sjet zbytek testu a pak se k ní vrátit s širším kontextem z dalších příkladů.

Pokud jste angličtinu neměli v ruce od maturity, doporučuji před samotnou zkouškou číst technické články a dokumentaci v angličtině, podívat se na pár videí k Fabricu a Power BI bez titulků a projít practice assessments, abyste si zvykli na styl otázek.

Pro koho dává DP-600/700 smysl (a kdy si raději počkat)

DP-600 a DP-700 dávají největší smysl pro lidi, kteří se Fabricu chtějí věnovat v praxi: konzultanty, BI vývojáře, data inženýry a architekty. Pokud už dnes pracujete s Power BI, SQL, možná Azure Synapse nebo ADF, spousta principů se vám přenese – Fabric přidá nové stavební kameny, ale logika datové platformy zůstává podobná.

Pro juniory bez projektů může být certifikace motorem, jak se naučit širší spektrum technologií, ale je dobré počítat s delší přípravou. Hodně pomůže, pokud zkoušku platí firma nebo využijete voucher z community programů. Naopak pokud s Fabricem zatím vůbec nepracujete a nemáte reálně čas se mu věnovat, může dávat větší smysl začít pár menšími projekty či proof-of-concepty a zkoušku si naplánovat až ve chvíli, kdy se ve světě Fabricu alespoň trochu rozkoukáte.

Komunita a odkazy na další zdroje

Pokud chcete být v obraze a zároveň mít kde probrat svoje otázky, zkuste československou Discord komunitu Data & Chill, kterou vede Vojta. Přístup k serveru najdete přes Vojtův web Daatlers v sekci věnované komunitě a vzdělávání.

Za pozornost stojí i další oficiální zdroje Microsoftu – třeba video série Exam Readiness nebo on-demand kurzy pro DP-600 a DP-700 na Microsoft Learn. Ty vám pomůžou sladit očekávání ohledně rozsahu zkoušky a typů scénářů, které se v ní objevují.

Závěrečné doporučení a další kroky

Na závěr jednu osobní poznámku: certifikace sama z vás experta neudělá. Ale může vám otevřít dveře – k zajímavým projektům, k partnerstvím, k důvěře zákazníků. A hlavně vám nastaví zrcadlo. Ukáže, kde máte „bílé fleky“.

Pokud se kolem Fabricu pohybujete pravidelně, žijete v Power BI bublině a třeba jste s námi v komunitě na Discordu Data & Chill, DP-600 a DP-700 jsou za mě logický další krok. Ne jako sbírka odznáčků, ale jako strukturovaný checkpoint, že se v platformě orientujete.

Tak na co čekáte? Vyhrňte rukávy a běžte to „zkusit“! A pokud chcete téma nejdřív nasát v audio podobě, celou epizodu si můžete poslechnout na Spotify zde .

Integrace s Gitem - návrat do historie

V minulém článku jsme se bavili o potřebě verzování obsahu v Power BI workspace. Dnes se zaměříme na postup, jak obnovit verzi z historie. Jakože jsme nedej bože udělali chybu a potřebujeme se vrátit do minulé středy se svým reportem, notebookem nebo pipeline.

Pro začátek, mám integrovaný workspace s Gitem, nasadil jsem změny, uvědomil si chybu, ale ještě jsem neprovedl commit. Tady je to jednoduché, stačí otevřít source control vybrat notebook/změnu a dát "Undo"

Pokud jsme ale commit přece jen provedli a zanechali zprávu, například jako na obrázku níže

Můžeme historii procházet v sekci source control - View repository

Tímto se dostaneme do Azure DevOps, kde vybereme commity, branch a uvidíme naši aktivitu

Vybereme verzi commitu, do které se chceme vrátit. Klikneme v pravém horním rohu na trojtečku vedle "Browse files" a dáme Revert. Barevně vidíme zvýrazněno, co je jinak.

Vpravo nahoře potvrdíme Complete a můžeme se vrátit do Power BI service

U ovlivněných objektů uvidíme Git status "Update required" a stačí v source control sekci dát update all a následně provést nový commit

Závěr

Gratuluji, pokud jsme udělali chybu ve vývoji a potřebujeme se vrátit do stabilní verze třeba z minulého čtvrtka, už víme, jak na to.

Integrace s Gitem - nastavení

V rámci podcastu "Cesta do Fabricu" jsme se v minulém díle s Vojtou bavili o verzování a deployment pipelines. O deployment pipelines jsem už psal. Tak ještě ta část o integraci s Gitem.

Každý kdo to vývojem myslí trochu vážně snad narazil na potřebu zaverzovat si kód pro svou vlastní potřebu. Nebo při práci v týmu potřebu sdílež a mergovat změny více vývojářů. K verzování kódu a projektů jsem byl poprvé veden už někdy v roce 2009, když jsem s MS BI začínal a verzovali jsme projekty pro MS SQL Server v Team Foundation Serveru.

Postupem času se mezi vývojáři stal standardem Git. Git je distribuovaný systém pro správu verzí, který umožňuje sledovat historii změn v kódu, bezpečně experimentovat a kdykoli se vrátit k předchozím verzím. Umožňuje také spolupráci více vývojářů, kteří mohou pracovat paralelně, dělat vlastní větve (branče), slučovat změny a řešit konflikty. Díky své rychlosti, spolehlivosti a flexibilitě se stal de facto standardem v moderním vývoji a tvoří základ pro nástroje jako GitHub, GitLab či Azure DevOps.

Git můžete používat i samostatně bez integrace s Power BI/MS Fabric workspace. Doporučuji k tomuto účelu ukládat ve formátu pbip  kde je rozdělená část pro strukturu modelu (TMDL) a reportová část. Hlavně se dá vyloučit cache.abf, která fyzicky obsahuje data a může být zbytečně velká. Jde nám o verzování definic, nikoliv dat.

Jak tedy nastavit integraci Power BI/Microsoft Fabric workspace s gitem?

Už tato otázka naznačuje, že nemůžeme verzování zapnout nad standardním Pro workspacem (můžete stále verzovat lokální pbip soubory).

Když svůj workspace připnete na dedikovanou kapacitu, ve wWorkspace settings najdete sekci Git integration

Jako provider můžete použít buď Azure DevOps, nebo GitHub. Na projektech používám první zmiňovaný, takže i postup v blogu bude směřovat touto cestou

V Azure DevOps vytvoříte novou organizaci a projekt, pokud je ještě nemáte a následně vytvoříte branch.

Ve Fabric workspace dáme connect and sync

Po přidání obsahu do workspace stačí otevřít sekci source control, kde na nás již svítí jedna změna [1], napsat zprávu ke commitu [2] a potvrdit změnu do verzovacího repozitáře [3].

Závěr
Gratuluji, workspace pro verzování máme nastavený. Příště se podíváme, jak se vrátit v čase a vytáhnout změny z historie. 

FabCon Europe Vienna 2025

Od pondělí 15.9. do čtvrtka 19.9 proběhla ve Vídni největší komunitní konference v Evropě zaměřená na Power BI a Microsoft Fabric. Díky společnosti DataSentics jsem měl možnost se na konferenci vydat a užít si hromadu technického obsahu, networking s produktovým týmem, komunitou, kolegy z MVP programu a v neposlední řadě lidmi z Česka a Slovenska.

Účast byla obrovská. Dorazilo přes 4000 lidí.

Další FabCon Europe se bude konat příští rok 28.9 až 1.10 v Barceloně a pokud to jen trochu půjde, motivován letošním ročníkem, pojedu znovu i s rodinou.

Jaká oznámení letošní ročník přinesl? Úvodní keynote obsahovala hlavní highlights z celé konference. Pokouším se to shrnout ze svých nesourodých poznámek, než budou dostupné slidy.

Power BI

• Web modelling generally available a měli bychom mít paritu mezi Power BI Desktopem a webovým rozhraním.

• Dostupnost Copilota i pro uživatele, se kterými je nasdílen obsah pouze přes Power BI Apps (což je majorita uživatelů).

• Zrychlení DataFlows Gen 2 díky Modern Query Evaluatoru a jejich zlevnění v rámci CU, pro Data Flows, které běhají pod 10 minut. Dostupnost také enable-only previews u Data Flows Gen 2. Třeba se dostaneme s Data Flows blíže k cenám zpracování dat pomocí notebooků. Při běhu pod oněch 10 minut Microsoft slibuje až 90% úsporu.

• Z top featur bych vypíchl Enhanced Time Intelligence. Možnost markovat jednotlivé úrovně podobně jako je možno v Multidimenzionálních Analysis Services (budiž jim země lehká). Tohle vyřeší například nestandardní kalendáře či práci s týdenními výpočty. Přibyla například i funkce TOTALWTD, která je v GA.

• TMDL Generally Available. Skvělá zpráva pro nás všechny a stejně tak pro uživatele On-Premises Power BI Report Serveru, že se brzy dočkají TMDL. Což totiž není v GA, se do On-Prem nedostane. O TMDL jsem měl velmi plodnou debatu s Rui Romano po jedné ze sessions, co mi chybí. Konkrétně se jedná o správu report-level measures u Live Connected modelů právě přes TMDL.

• DAX User Defined Functions – můžete zabalit kus DAX kódu jako uživatelsky definovanou funkci a než ji celou opakovat, voláte ji názvem. Tohle zjednoduší čitelnost, údržbu kódu a znovupoužitelnost podobně jako Calculation Groups a TMDL. Podařilo se mi též odchytit Jaye a vyjádřit pár přání k Visual Calculations.

• Copilot v DAX query view taky v GA.

• Zaujala mě příprava semantických modelů pro AI a Power BI Agenti. Mimo jiné půjde chatovat s vašimi daty přímo z M365.

• Stejně tak mě zaujal Best Practices Analyzer nad sémantickými modely, který doma hned otestuji.

Za mě nejlepší přednáškou celé konference byla od Ruie Romana, ohledně podpory v Power BI pro profesionální vývojáře. V každý čas kromě keynote slotů běželo paralelně až 10 přednášek zaráz. Čili byl někdy problém si vybrat. U Ruie jsem byl na DataPointu v květnu a měl cukání, zda jít znovu na stejnou přednášku. Díky bohu, že jsem šel. Bylo to kulervoucí, omluvte mi ten výraz. Kdyžtak si doplňte dechberoucí, kam se to všechno od května posunulo.

Díky interní práci na formátech PBIP a PBIR, TMDL se posouváme blíže k tomu, co dříve nešlo a bouráme limity. Již brzy se dočkáme možnosti stáhnout modely upravené přes XMLA endpoint, a to i pokud byl u modelu použit incremental refresh.

Znovupoužitelnost kódu možná díky TMDL – můžete kouknout do TMDL Galerie a případně se v ní sami angažovat: https://aka.ms/tmdl-gallery

Dočkáme se velmi brzy (už je to v private preview) oficiálních MCP serverů od Microsoftu. O přístup k němu jsem si již zažádal. Budou dva, jeden lokální, jeden vzdálený.

Rui ukazoval skvělé use cases při integraci PBIP v kombinaci s VS Code a Copilotem pro VS Code. To se nedá popsat pár větami, to se musí vidět. Došlo na agentic development, automatickou dokumentaci modelů nebo templatizaci na nové projekty. Translations generované AI by se také mohly někdy hodit.

Microsoft Fabric

Pokud nejste čistě Fabric uživatelé, čtěte dál.

• Fabric Command Line Interface (CLI) je GA

• Pokud máte workspaces integrované s Gitem, tak 100 % komponent je nyní kompatibilní pro CI/CD (aktuálně 38 typů items)

• V notebooku add connection za vás předgeneruje Python kód.

• Viděli jsme low-code/no-code práci s Graph daty.

• Microsoft papá své vlastní jídlo, co si navaří – veškeré Azure services jsou monitorované přes Azure Real Time Intelligence.

• Real-time anomaly detector je v public preview.

• Pro účely writebacku můžete zvážit Translytical Task Flows, což jsou uživatelsky definované funkce v Pythonu a můžou vpisovat do SQL DB.

• Pokud se chcete vyhnout kopírování dat do Fabricu a používáte shortcuts, můžete nově použít shortcuts proti Oracle DB a Google BigQuery. Zajímavě vypadají i shortcut transformations.

• Ve OneLake katalogu přibyla záložka secure. Můžete řešit security z jednoho místa.

• Komponenta Maps ve Fabricu nápadně připomíná PowerMap z Excelu, ale pokud řešíte mapy, tak proč ne. Aktuálně v Preview.

Data Flows

• 170+ konektorů

• o zlevnění jsem psal již u Power BI, tiered costing podle doby trvání, only previews a modern query evaluator

• Destinations v Data Flows se rozrostly o Snowflake DB, Fabric Lakehouse a brzy Excely v SharePoint dokumentové knihovně

Data Factory

• podpora Evaluate Expressions

• interval-based schedules

• cross-cloud mirroring

Mirroring podpora pro SAP DataSphere a ABAP v Private preview. Pokud by někdo potřeboval, vyhrabu linky.

S ohledem na Security zajímavá možnost blokovat outbound public access.

Pro nás aktuálně stěžejní zdroj Databricks podporuje metadata mirroring katalogu pro Direct Query připojení. Zatím ale bez tabulek, na kterých je RLS/CLS. Nicméně incoming.

Z pipelines jde volat DBX serverless Job.

Fabric SQL Database – zvýšení retention backupů ze 7 na 35 dní.

SQL Server 2025 je v preview.

Byly prezentovány novinky v Monitoring Fabric kapacit. Pokud nemáte aktualizovanou appku, doporučuji to udělat. Prezentoval Chris Webb, kterého jsem po letech též velmi rád viděl.

Data Agenti – co k tomu říct. Hodně přednášek AI heavy, ale agenty vyzkouším. Možnost mimo jiné chatovat i nad mirrorovanými daty.

Závěr

FabCon byl skvělý po všech stránkách. Networking, technický obsah. Komunikace s produktovými týmy. Ale na rozdíl například od MVP summitu můžu psát, co jsem se dozvěděl. Oznámení bylo hodně, stejně jako možností přihlásit se do různých private/public previews. Čili hromada práce přede mnou. Tak další článek na některé ze zmíněných témat a více rozebereme s Vojtou v podcastu Cesta do fabriky.

Z SSAS do Power BI: Přesuňte svůj workload do Microsoft Fabric

Analysis Services – mrtvá technologie? Ani náhodou!

Analysis Services je technologie, která mě přivedla do světa Business Intelligence. Je to platforma, kterou mám opravdu rád, a právě ona mě nasměrovala i k Power BI. Je dnes tahle technologie mrtvá? Za mě rozhodně ne – nadále žije v Power BI a Microsoft Fabric. Jsem přesvědčený, že i dnes existují scénáře, kdy dává smysl on-premises nasazení modelů hostovaných v SSAS. Na tyto modely se lze připojit z Power BI přes Live Connection. Ostatně, téma jsem podrobněji rozebíral na konferenci Data Points Prague během své přednášky.

V poslední době jsem řešil několik projektů, které se pohybují na pomezí Analysis Services a Microsoft Fabric / Power BI. K dedikované kapacitě ve workspace Microsoft Fabric se totiž můžete připojit stejně jako k Analysis Services serveru. Navíc sem můžete publikovat i stávající Analysis Services modely.

Proč jsem dříve volil SSAS/BIM definice?

Jedním z rozhodujících důvodů byla škálovatelnost a možnost rozdělení modelu na partitiony. Od června 2025 však tuto funkcionalitu nabízí také Power BI Desktop díky TMDL (Tabular Model Definition Language):
https://powerbi.microsoft.com/en-us/blog/open-and-edit-any-semantic-model-with-power-bi-tools/

TMDL ve spojení s integrací do Visual Studio Code a novým formátem popisu reportu (PBIR) představuje podle mě strategický krok správným směrem. O TMDL jsem již psal v jiném článku.

Jaké scénáře můžeme řešit konverzí mezi SSAS a Power BI?

• Scénář 1: Máme stávající SSAS model (například vytvořený v rámci Synapse nebo jako samostatný projekt), ale rádi bychom jej přenesli do Power BI a využili výhod nového formátu TMDL, který považujeme za modernější a flexibilnější.

• Scénář 2: Začali jsme s Power BI v režimu self-service, ale model narostl do takové velikosti nebo složitosti, že už Power BI import nestačí. Chceme jej tedy převést do SSAS.

V tomto článku se dále věnuji pouze prvnímu scénáři – tedy převodu existujícího SSAS modelu do Power BI prostředí.

Postup migrace BIM → PBIX/PBIP

Netvrdím, že jde o jediný nebo nejjednodušší způsob. Výhodou je, že je zdarma. Může však vyžadovat ruční úpravy.

1. Otevřete původní Visual Studio projekt, případně přímo .bim soubor v Tabular Editoru (postačí i neplacená verze).

Spusťte prázdný Power BI Desktop a v modelovém zobrazení identifikujte port lokální instance SSAS. Server zkopírujte do schránky (např. localhost:XXXXX). Na obrázku jako 3

V Tabular Editoru otevřete nabídku Model → Deploy, jako cíl zadejte lokální instanci SSAS (localhost:XXXXX).

Dokončete průvodce nasazením.

Může se objevit výzva k upgradu na enhanced metadata format nebo potřeba přepočítání dat. Výsledkem však bude úspěšné nasazení modelu včetně partitions.

Závěr

Dedikovaná kapacita v Microsoft Fabric může plně nahradit Analysis Services server nebo Azure SSAS. Pokud již máte vytvořené SSAS modely a chybí vám v Power BI některé funkcionality – například partitioning – nebo pokud chcete využívat moderní formát TMDL, nyní máte možnost. Svůj BIM model můžete převést do Power BI projektu ve formátu PBIP a naplno využít nové možnosti platformy.

Zlo dostalo jméno Auto date/time intelligence

Kdybych měl dostat pětikorunu za každý případ, kdy jsem na tento nešvar upozornil, pravděpodobně bych nezbohatl. Bylo by to ale minimálně na solidní párty. Proto jsem se rozhodl zvěčnit své myšlenky v dnešním blogovém příspěvku. Inspirovala mě k tomu také včerejší debata s Jirkou Vicherkem při nahrávání Data talk podcastu, když se mě ptal na Power BI dark patterns. Asi z toho udělám sérii.

Pokud bych měl vybrat první věc, kterou udělat po čisté instalaci Power BI Desktopu, bylo by to vypnutí funkce Auto date/time intelligence.

Kdybych měl vyjmenovat nejčastější příčinu, proč u data import modelů méně zkušených uživatelů model nabobtnal do nesmyslných rozměrů, je to Auto date/time intelligence.

Tak si to prosím vypněte. Globální nastavení najdete v menu File - Options zde:

Pokud to máte nějakým nedopatřením zapnuté u stávajícího souboru, vypnete to zde

Tak si to prosím vypněte, ať je klid. Děkuji.

Tady by se dalo skončit, ale asi dlužím vysvětlení proč...

Co to dělá?

Pro každý sloupec datového typu date potažmo datetime to vytvoří hierarchii se čtyřmi extra sloupci pro rok, kvartál, měsíc a pořadové číslo dne měsíci

Proč to vadí?

Protože Power BI ve Vertipaq enginu drží data v column store úložišti, kde každý sloupec komprimuje do paměti. Pro každý sloupec na pozadí vzniká localdatetable a ta zabírá místo. 
O fungování Vertipaq engine jsem psal například v článku o velikosti modelu v Power BI a SSAS Tabular.

Tady máme jeden ukázkový reálný historický report stav před vypnutím auto date/time

Když se na tento report připojím z DAX studia, vidím hromadu tabulek LocalDateTable

Když vyexportuju statistiky do vpax souboru, analyzuji model ve Vertipaq analyzeru, zjistím že zabírají 92% celé velikosti modelu.

Vypínám auto date/time a ukládám soubor

Fakturuji půl dne za optimalizaci.

To je samozřejmě nadsázka, ale je to dobrý startovní bod.

Proč je to tedy proboha defaultně zaplé?

Power BI je zaměřeno na koncového uživatele a pro ty méně technicky znalé se Microsoft snaží věci zjednodušovat. Takovýto uživatel dost často nepracuje s dimenzionálním modelem, ale má jen jednu faktovou tabulku. Takže ano v takovém případě to může být užitečné, když uživatel neví, jak si vytvořit hierarchii vlastní.

Nicméně pokud mám alespoň dvě faktové tabulky obě s datumem, budu beztak potřebovat vytvořit společnou tabulku s kalendářem, abych je mohl filtrovat přes společný ovládací prvek. A ve vlastní kalendářové tabulce (jeden ze způsobů, jak ji vytvořit jsem sepsal zde). V takové společné dimenzionální tabulce si následně vytvořím hierarchii vlastní.

Můžu to tedy hned beztrestně vypnout?

Může to být tricky u stávajících souborů s vizualizacemi. Auto date/time totiž datumové sloupce referencuje v DAXu a může být potřeba opravit počítané sloupce a measures, které se odvolávají na dílčí části. Tyto návaznosti je potřeba opravit.

Stejně tak vizualizace, které tuto logiku používaly je potřeba opravit. To, co bylo seskupeno například podle roku, se rozpadne na jednotlivé datumy a musíte tyto vizualizace upravit. 

Závěr

Od té doby, co o tomto chování vím (a taky jsem na začátku nevěděl) je vypnutí auto date/time intelligence pro nové soubory první věcí, kterou vypínám po instalaci Power BI desktopu. Jestli tohle nastavení ve svých souborech potřebujete, nebo ne je na zvážení každého individuálně. Tento příspěvek vám snad dal informace abyste se mohli kvalifikovaně rozhodnout.

Podmíněný formát s visual calculations

V minulém článku jsem psal o Visual Calculations a probral některé scénáře, kdy mohou být užitečné. Pro opakovaně použitelné výpočty v rámci modelu budou většinou výhodnější measures. Psát však measure do modelu jen kvůli formátování barev v jednom vizuálu je jako střílet kanónem na vrabce. Může to také vést k velkému množství formátovacích measures v modelu a snížení celkové přehlednosti.

Podmíněné formátování je skvělým případem pro použití Visual Calculations, protože je svázané s konkrétní vizualizací.

Podívejme se na následující příklad nad databází Adventure Works. Vytvořil jsem Visual Calculation pro výpočet průměru podle toho, co je aktuálně na řádcích.

Výhodou je, že průměr se vždy počítá přes položky na řádcích (v tomto případě Reseller) a bude tedy fungovat obecně, i kdybych jej například použil pro podmíněné formátování barvou.

Výpočet trochu rozšířím tak, aby vracel barvu:

Average Sales =

var _avg = AVERAGEX(ROWS,[# Reseller])

var _sales = [# Reseller]

var _rslt = if(_sales>=_avg, "Green", "Red")

RETURN _rslt

Ještě je potřeba nastavit datový formát pro Visual Calculation, aby se chovala jako text.

Následně stačí v Cell elements vybrat formátování na základě hodnoty v poli.

Formát funguje pro model

i pro barvu, případně cokoliv jiného.

Závěr

Podmíněné formátování je skvělým kandidátem pro využití Visual Calculations, protože s jejich pomocí zabráníme exponenciálnímu růstu počtu metrik v datovém modelu.

Samozřejmě je možné vytvořit i pokročilejší scénáře, například podle kategorií produktů, více stavů a podobně.