Nejde o deep dive. Dnešní díl je rozcestník a jednotlivým nástrojům se budu věnovat v samostatných dílech seriálu.

Proč je to tak těžké?

Důvody jsou dva. Nástrojů je hodně a mění se rychle. Za poslední zhruba dva roky se AI skill přejmenoval na data agenta, Azure AI Studio na Azure AI Foundry a pak na Microsoft Foundry. Power BI Q&A v únoru 2027 skončí. Stav jedné a té samé funkce se občas liší podle toho, kterou stránku dokumentace zrovna čtete.

A pak je tu slovo Copilot. To dnes neznamená jeden produkt, ale celou rodinu.

Tři patra

V hlavě si AI kolem dat dělím na patra:

• Ptám se – konverzační AI, která odpovídá nad daty. Copilot v Power BI, Microsoft 365 Copilot, Fabric data agent.
• Stavím agenta – platformy, kde si takového agenta postavíte sami. Copilot Studio a Microsoft Foundry.
• Vyvíjím s agentem – agentický vývoj. GitHub Copilot, Claude Code, Codex. Ty dnes umí přes MCP sáhnout i do semantic modelu.

Dnešní mapa pokrývá hlavně první dvě patra. Třetímu patru dám vlastní díl.

Základ: semantic model a Prep data for AI

Než se pustím do nástrojů – všechno z prvního patra stojí na stejném základu. Na semantic modelu. Pokud je model nepopsaný a plný technických sloupců, žádný Copilot to nezachrání.

Proto vzniklo Prep data for AI. Vyberete podmnožinu polí, kterou má AI používat (AI data schema). Doplníte instrukce s byznysovými pojmy (AI instructions). A pro nejčastější otázky připravíte schválené odpovědi (verified answers). Všechno se ukládá do modelu, ne do reportu. Takže to platí všude, kde se model s Copilotem potká – včetně data agenta.

Je to stará známá práce datového modeláře, jen s novým publikem.

Copilot v Power BI

Copilot v Power BI není jedna věc, ale několik různých funkcí:

• Copilot pane v reportu (GA) – odpovídá nad reportem, který máte otevřený.
• Standalone Copilot (preview) – celoobrazovkový, sám najde vhodný report nebo model, ke kterému máte přístup. Když odpověď v reportu není, sáhne do measures nebo si napíše DAX.
• Copilot pro tvůrce – psaní DAX, popisy measures, úpravy modelu.

Často slýchám, že Copilot „vidí celý tenant“. Nevidí. Vidí to, k čemu máte přístup vy, a admin mu to může dál zúžit na schválené modely. RLS platí.

Požadavek na kapacitu: F2 a výš nebo P1 a výš, případně Fabric Copilot capacity. Samotná Pro licence nestačí.

Microsoft 365 Copilot a Fabric IQ

Tady se na FabConu v Barceloně posunulo nejvíc. Power BI data v Microsoft Copilot Chatu jsou GA. Copilot sám pozná, který report nebo model se k otázce hodí. A k číslům přidá kontext z mailů, schůzek a dokumentů.

Zajímavost: funguje to i nad Pro a PPU workspace (Embedded kapacity ne). Potřebujete licenci Microsoft 365 Copilot (Learn ji teď vede jako Copilot Premium) a běžný přístup k reportu. Fabric kapacita podmínkou není.

Druhý krok se týká Power BI samotného. Stejný Copilot přichází přímo do Power BI a Fabricu. Zatím jako preview, jen pro držitele Copilot Premium licence a vedle stávajícího Power BI Copilotu. Na ostatní uživatele se má rozšířit později. Směr je ale vidět – čísla z Power BI a kontext z Microsoft 365 se potkávají v jednom Copilotu.

Fabric data agent

Když nechcete obecného Copilota, ale specialistu, je tu Fabric data agent. Dáte mu až pět zdrojů v libovolné kombinaci – lakehouse, warehouse, KQL databázi, semantic model, ontologii. Napíšete mu instrukce, kdy sáhnout kam, a přidáte příklady dotazů. (U semantic modelu příklady dotazů nejdou – tam agent bere to, co připravíte přes Prep data for AI.)

Agent si sám napíše SQL, DAX nebo KQL. Jen pro čtení. A má své meze: oficiálně podporuje jen angličtinu (v mém malém testu ale česky fungoval podobně jako anglicky), odpověď má strop 25 řádků × 25 sloupců a zdroje musí být ve stejném regionu.

Hlavní výhoda? Dá se volat shora. Ze standalone Power BI Copilotu, z Microsoft 365 Copilotu, z Copilot Studia i z Foundry. Postavíte ho jednou a volat ho může víc nástrojů.

Copilot Studio vs. Foundry

Pomůže analogie, kterou datoví lidé znají. Copilot Studio je pro agenty totéž, co Power Automate pro workflow. Foundry je totéž, co Logic Apps.

Copilot Studio je low-code, žije v Power Platform, spravuje se v Power Platform admin center a platí se v Copilot Credits. Staví v něm makeři, typicky agenty pro oddělení. Foundry je pro vývojáře: Azure subscription, volba modelu, vlastní kód, evaluace, platba za tokeny.

Rozšířené dělení, že Copilot Studio je „pro M365“ a Foundry „pro všechno ostatní“, ale neplatí. Copilot Studio volá přes konektory i systémy třetích stran a publikuje na web. Agenta z Foundry zase publikujete do Teams a do Microsoft 365 Copilotu. Hranice tedy není v tom, kam agent dosáhne. Je v tom, kdo ho staví, kde žije a kdo ho platí.

A pozor na detail, který vypadá nevinně. V Copilot Studiu si u data agenta volíte autentizaci. Při volbě Maker vidí všichni uživatelé data přes oprávnění autora. To si dobře rozmyslete.

Pro vývojáře: MCP a Foundry IQ

Dvě položky, které v mapě nesmí chybět. Power BI MCP servery: Authoring MCP slouží k tvorbě a úpravám modelu z agenta, Fabric IQ k odpovědím nad Power BI daty pro vlastní agenty. A Foundry IQ nad Azure AI Search, které řeší dokumenty. Zjednodušeně: Fabric IQ jsou čísla a sémantika, Foundry IQ jsou PDFka a texty.

Celá mapa v tabulce

Pro pořádek všechno na jednom místě.

Závěr

Dnešní článek měl být mapou, ne průvodcem. Základ tvoří semantic model připravený pro AI. Nad ním se ptají Copilot v Power BI, Microsoft 365 Copilot a data agent. A agenty si stavíte buď v Copilot Studiu, nebo ve Foundry – podle toho, kdo staví a kde to má žít.

Každému z nástrojů dám samostatný díl. Začnu přípravou dat pro AI, protože bez ní je všechno ostatní loterie.

Tenhle článek je pro vývojáře z Power BI světa, kteří uvažují o Fabricu a slyšeli o dbt. Nebude to kompletní průvodce dbt. Vysvětlím, co to je, proč mě to zaujalo a jak se z popisů napsaných jednou dostanete až do sémantického modelu.

Co je dbt (a co není)

dbt (data build tool) je nástroj na transformace dat uvnitř databáze. Nenačítá data, neorchestruje celý svět a nemá vlastní úložiště. Dělá jednu věc: ze SQL dotazů (modelů) postaví tabulky a views ve správném pořadí a ohlídá, že výsledek sedí.

Pro člověka z Power BI se to dá přirovnat takto:

• model je jeden SELECT uložený v souboru. dbt z něj udělá view nebo tabulku. Něco jako dotaz v Power Query, jen v SQL a ve skladu.
• ref() je odkaz na jiný model. Podle něj dbt pozná závislosti a sestaví lineage (graf, co z čeho vzniká). V Power BI znáte podobné zobrazení závislostí.
• test je pravidlo nad daty (unique, not_null, vztah mezi tabulkami). Spustí se spolu s buildem.
• YAML soubor vedle modelu popisuje model a sloupce: tady se píší descriptions. A právě to je důvod, proč jsem u dbt skončil.

Všechno jsou to textové soubory v Gitu. Pro vývojáře z Power BI, který si zvykl na PBIP a TMDL, to není nic cizího.

dbt ve Fabricu

Fabric má vlastní položku dbt job (Data Factory). Spouští dbt Core ve spravovaném runtime, takže nic neinstalujete lokálně. Projekt vezmete z ukázky (Jaffle Shop) nebo z GitHub repozitáře, vyberete cíl (Warehouse, Lakehouse a další podporované adaptéry) a job můžete naplánovat. Po běhu uvidíte lineage, zkompilované SQL a výsledky. Podle oznámení z FabCon Europe (29. 9. 2026) je dbt job ve stavu GA. Oznámení: FabCon/SQLCon Barcelona 2026: What’s new in Fabric Data Factory. Zapíná se v tenant settings.

Založení dbt jobu: vzorový projekt Jaffle Shop

Připojení projektu k cíli: výběr profilu adaptéru

Adaptéry jsou dva důležité:

• dbt-fabric pro Fabric Data Warehouse (T-SQL),
• dbt-fabricspark pro Lakehouse (Spark SQL přes Livy API, zapisuje Delta tabulky do OneLake).

Rozdíl je podstatný: SQL analytics endpoint u Lakehouse je pro dbt jen pro čtení, takže transformace ve stylu T-SQL patří do Warehouse. Pokud je váš tým spíš Spark, sáhnete po Lakehouse.

Nový Warehouse jako cíl dbt jobu

Profil adaptéru: Warehouse, schéma jaffle_shop, nahrání seed dat

Dva praktické limity z dokumentace: dbt job nemá build cache (každý běh kompiluje projekt od nuly) a ne všechny partnerské adaptéry jsou ve Fabricu podporované.

Proč mě to zajímalo: kde žijí popisy

V sémantickém modelu Power BI je popis jednoduchý. Zapíšete ho do vlastností sloupce nebo do TMDL a uvidí ho každý, kdo model použije, včetně Copilota a dalších nástrojů, které se na model dotazují.

Pod tím je ale datový sklad. A tam popisy sloupců uložit nejde. Standardní cesta ze SQL Serveru (extended properties) ve Fabric Warehouse nefunguje: sp_addextendedproperty Warehouse odmítne s hláškou, že procedura není podporovaná. Praktický důsledek: popisy se nejčastěji řeší vedle databáze. Excelem, wiki nebo vlastní konfigurační databází, kam se píše, co který sloupec znamená. Funguje to, dokud to někdo udržuje. Obvykle to trvá do prvního release.

dbt tenhle problém řeší jinak. Popis sloupce leží ve stejném YAML souboru jako model, ve stejném commitu a prochází stejným code review. Změníte sloupec a popis vidíte hned vedle.

Ukázka z demo projektu Jaffle Shop (fiktivní e-shop, který dbt i Fabric nabízejí jako vzorový projekt):

version: 2

models:
  - name: customers
    description: This table has basic information about a customer, as well as some derived facts based on a customer's orders
    columns:
      - name: customer_id
        description: This is a unique identifier for a customer
        tests:
          - unique
          - not_null
      - name: first_order
        description: Date (UTC) of a customer's first order
      - name: number_of_orders
        description: Count of the number of orders a customer has placed
      - name: total_order_amount
        description: Total value (AUD) of a customer's orders

schema.yml s popisy v editoru dbt jobu ve Fabricu

Delší popis nemusíte cpát do YAML. Dá se napsat jako doc blok v Markdownu (docs.md) a z YAML na něj odkázat přes {{ doc("orders_status") }}. V demu takhle vypadá popis stavů objednávky:

Doc blok orders_status v souboru docs.md

Popisy a závislosti skončí v artefaktu manifest.json, který dbt job ve Fabricu ukládá při každém běhu do složky target v OneLake. Příkaz dbt docs generate k tomu přidá catalog.json se skutečnými sloupci a typy z databáze. Pozor: ve Fabricu se vygenerovaná dokumentace zatím nerenderuje jako web, máte jen soubory.

Příkazy dbt jobu, mezi nimi i docs generate

Popisy až do databáze

dbt umí popisy zapsat i do samotné databáze, jako komentáře k tabulkám a sloupcům. Slouží k tomu konfigurace persist_docs:

models:
  my_project:
    +persist_docs:
      relation: true
      columns: true

Na řadě platforem to funguje (Snowflake, Databricks, BigQuery a další). Pro Fabric je situace rozdělená a vyzkoušel jsem si obě varianty:

• Warehouse (dbt-fabric): dokumentace dbt persist_docs pro tento adaptér neuvádí a test to potvrdil. dbt run s persist_docs končí chybou „alter_relation_comment macro not implemented for adapter fabric“, u sloupců totéž s alter_column_comment. Model s persist_docs tedy spadne, pro Warehouse ho nechte vypnutý.
• Lakehouse (dbt-fabricspark): persist_docs funguje. Popis tabulky i sloupců skončí v metadatech Delta tabulky (ověřil jsem v Delta logu). SQL analytics endpoint je ale do T-SQL metadat nepromítne (sys.extended_properties zůstane prázdné), takže přes T-SQL je neuvidíte.

Proč to ale není slepá ulička: popisy nemusí být v databázi, aby je někdo přečetl. Jsou v dbt projektu a v artefaktech. Kdo potřebuje metadata, přečte je odtud. A tím se dostávám k tomu, co mě na tom baví nejvíc.

Agent staví sémantický model a popisy si přečte sám

Sémantický model Power BI dnes umíme stavět i s agentem. Microsoft k tomu má Power BI Authoring MCP server (lokální verze se instaluje jako powerbi-modeling-mcp), který umí s modelem pracovat (tabulky, sloupce, measures, vztahy, popisy). Agent pak může model sestavit nad vaším skladem.

Obvyklý problém: agent vidí názvy sloupců a typy, ale neví, co znamenají. Model pak vznikne bez popisů, nebo se popisy domýšlejí. A domýšlené popisy jsou horší než žádné.

Pokud ale agent dostane k dispozici dbt projekt (nebo manifest.json), může popisy převzít. Zadání je jednoduché: „Postav sémantický model nad schématem jaffle_shop, popisy a vztahy převezmi z dbt projektu.“ Agent přečte popis customer_id z YAML a zapíše ho jako description sloupce v modelu. Vztah orders → customers odvodí z testu relationships, který je v YAML u sloupce orders.customer_id. Co jednou popíšete v dbt projektu, agent přenese do sémantického modelu bez ručního přepisování. Copilot a Fabric data agent pak nad modelem mají k dispozici popisy, které byste jinak psali ručně.

Zadání agentovi a shrnutí jeho běhu (výstup přepsaný do přehledné podoby), včetně nahlášeného nesouladu

Výsledný model v TMDL view: popisy z dbt jako /// komentáře

Jedna pojistka: popis z dbt je vstup, ne pravda. Hezky se to ukázalo hned v demu. YAML popisuje u zákazníka sloupec total_order_amount (viz ukázka výše), jenže tabulka ve Warehouse ho nemá, místo něj obsahuje customer_lifetime_value bez popisu. Nesoulad je přímo ve vzorovém projektu. Agent to porovnal se skutečnou tabulkou, nesouhlasící popis nepoužil a nesoulad nahlásil. Kdyby popisy jen slepě kopíroval, měli byste v modelu popis ke sloupci, který neexistuje. Agentovi proto dejte za úkol model postavit a nesoulady hlásit, ale zkontrolovat ho musíte vy.

Demo

Demo stojí na vzorovém projektu Jaffle Shop (fiktivní e-shop: zákazníci, objednávky, platby) ve Fabric Warehouse. Postup:

1. dbt job ve Fabricu nad Warehouse, modely ve dvou vrstvách (staging a výsledné tabulky customers a orders).
2. Popisy sloupců výsledných tabulek v YAML, testy unique, not_null, relationships a accepted_values.
3. Spuštění jobu s příkazem build, kontrola lineage a výsledků testů.
4. Agent načte popisy z dbt projektu a postaví nad Warehouse sémantický model (Direct Lake).
5. Výsledek v Power BI: popisy tabulek a sloupců ve vlastnostech modelu.

Lineage view v dbt jobu: seedy, staging a výsledné tabulky

Výsledek dbt build: modely i testy prošly

Sémantický model (Direct Lake) ve Fabricu: popis sloupce first_order převzatý z dbt

Chování persist_docs ve Warehouse a v Lakehouse jsem zkoušel zvlášť na malém testovacím modelu (výsledky viz výše).

Kdy to dává smysl a kdy ne

Dává to smysl, pokud:

• máte transformace ve skladu v SQL a chcete je verzovat, testovat a mít lineage,
• chcete jedno místo pro popisy, které se dostane i do sémantického modelu,
• už dbt znáte, nebo máte tým, který zvládne Git.

Nedává to smysl, pokud:

• máte pár tabulek a transformace řešíte jednou za čas,
• nikdo nechce psát popisy: dbt je nevymyslí, jen je udrží u kódu,
• potřebujete něco, co dbt Core nemá. dbt job ve Fabricu dnes spouští dbt Core, novější engine Fusion v něm zatím není.

Závěr

Dnešní článek měl ukázat, co je dbt a proč ho zvážit ve Fabricu, i když jste vývojář Power BI. Pro mě je hlavní důvod popisy: napsat je jednou u kódu a nechat je přečíst agenta, který staví sémantický model. Warehouse a Lakehouse se v tom chovají odlišně, proto si to vyzkoušejte na malém projektu dřív, než to nasadíte na něco důležitého.

Zdroje:

• dbt job ve Fabricu (Microsoft Learn)
• Dokumentace a doc bloky v dbt
• persist_docs (dokumentace dbt)
• dbt-fabricspark setup (dokumentace dbt)
• Power BI MCP servery (Microsoft Learn)

Tenhle článek je přehled toho podstatného, co Microsoft k letošnímu FabConu a SQLConu oznámil. Nejedná se o kompletní seznam – jen zářijový Fabric Feature Summary má víc položek, než kolik kdo z nás stihne za týden vyzkoušet.

Power BI jako kód: PBIP je GA

Pro mě zpráva dne. Power BI Projects (PBIP) jsou Generally Available. A PBIR je nově výchozím formátem reportu pro PBIX i PBIP – legacy reporty se při editaci automaticky převádějí. Pokud máte skripty, které parsují starý report.json, zkontrolujte je. Btw. tady se jedná o dobrou zprávu pro všechny, kteří jsou na on premises Power BI Report serveru. Protože tam se dostanou jen věci v GA... Další release?

K tomu Power BI Agentic Experiences jsou GA – Power BI Authoring MCP, Power BI Desktop Bridge CLI a skills-for-fabric. Remote Power BI Authoring MCP Server je v preview. Nic neinstalujete a funguje i na Macu. Lokální MCP zůstává GA.

Na Power BI Day 2026 jsem živě ukazoval Claude nad Power BI reportem. Tohle je pro mě jasný signál, že verzování a práce s agenty nejsou experiment, ale standardní cesta. O integraci s Gitem jsem psal tady.

Aplikace v Power BI – i pro Pro a PPU

Agentic app creation v Power BI Desktop – nad semantic modelem popíšete v přirozeném jazyce, co potřebujete, a vznikne aplikace. Umí i write-back a publikuje se do Fabricu přes Fabric Apps. Je to preview, termín ale Microsoft uvádí různě (jednou týdny, jednou měsíce). Nechám se překvapit.

Zásadní je licencování. Apps in Power BI budou v preview i pro Power BI Pro a PPU bez příplatku, včetně Fabric Apps a Fabric Database – až 1 GB na aplikaci. Fabric Apps se mají objevit i v Org apps (Coming Soon).

Fabric Apps se připojují na semantic model read-only a posílají do něj DAX dotazy, do SQL DB a warehouse jde i zapisovat. Delegovaná autentizace vynucuje oprávnění včetně RLS. Aplikace tak dostane stejné číslo jako report a stejný uživatel uvidí stejná data. Jak jsem data app nad DAX dotazy stavěl v červnu, popisuju v článku Fabric Apps – náhrada Power BI reportů?

Modelování a DAX

• Vytváření a editace DirectQuery modelů v Power BI service – další krok k paritě webu a Desktopu.
• APPROXIMATEDISTINCTCOUNT pro Import a Direct Lake (preview). Standardní chyba kolem 1,6 %. Na počty zákazníků v přehledovém reportu ano, na finanční čísla ani náhodou.
• String Indexing a Full-Text Search v semantic modelech (preview).
• Nový Power Query editor v Power BI Desktopu (preview).
• Semantic views – governed metriky a sémantika definované přímo nad daty ve OneLake. Zatím jen „early look".
• Apache Ossie (incubating) – vendor-neutral standard výměny sémantických metadat, za kterým stojí Microsoft spolu se Snowflake. Open source Microsoft converter převede Ossie dokument na Power BI semantic model i Snowflake Semantic View – sémantiku definujete jednou, bez přesunu dat. Výhledově má být DAX uznávaným dotazovacím jazykem Ossie.

Copilot a governance

Fabric IQ v Microsoft Copilot Chat a Cowork je GA. Copilot odpovídá nad vašimi Power BI modely a reporty, a to bez dodatečných nákladů na AI tokeny. Fabric IQ MCP Server je taky GA.

Microsoft 365 Copilot přímo v Power BI a Fabricu je v preview, se sdílenou historií konverzací. Fabric data agents v Microsoft Copilot Studio jsou GA.

A teď to, co bych jako admin řešil nejdřív. Na semantic modelu přibylo nastavení, které zakáže read-only uživatelům přístup k modelu přes Copilot a Microsoft MCP nástroje. Výchozí hodnota je povoleno. K tomu Restrict from Copilot – admin určí, které semantic modely smí do AI experience. Sensitivity labels a DLP se do Copilot experience propisují. Pokud máte modely, které do AI nepatří, projděte je teď, ne až po incidentu.

Drobnosti, které potěší

• Export do Excelu („Data with current layout") ze 150 000 na 500 000 řádků (GA).
• Visual calculations pro small multiples (GA). O visual calculations jsem psal zde.
• Design ribbon (GA).
• Pozor na deprecation: od října ztratí verze Power BI Desktopu z března 2026 a starší možnost ukládat do OneDrive/SharePoint. Aktualizujte.

Fabric: kapacity a billing

Fabric zero-provisioned (F0) – start bez provisionované kapacity, s on-demand billingem jako výchozím (preview). On-demand billing napříč Fabric workloady má brzy přijít v preview a on-demand billing pro OneLake compute – přístup k datům nezávislý na běžící kapacitě – má dorazit v preview v příštích týdnech. F0 chci otestovat hned, jak bude k dispozici.

Dál: Capacity overage je GA, SKU F4096 a F8192 jsou GA a workspace-level surge protection má být GA brzy.

CI/CD, Git a observability

• Deployment plans (preview) – nový workspace item, vizuální pořadí nasazení, YAML jako source of truth, kroky před a po nasazení.
• Bulk import/export item definition APIs (GA).
• Git: branch workspace, selective branching, compare and commit (GA); file-level commit a branch workspace admin profile (preview).
• Observability in Fabric (preview) – workspace monitoring sjednocený do jednoho eventhouse, přepracovaný Monitor Hub, pohled na kapacitu a Activator alerty na joby. Fabric Observability Insights (public preview) – operations agent vyšetří třeba selhání pipeline.
• Fabric Core MCP Server (GA).

Governance a OneLake

• Policies in Fabric (preview) – řízení přístupu na základě atributů.
• DLP policies – restrict access to sensitive data (GA), rozšířené OneLake catalog Govern (GA), Outbound access protection pro OneLake shortcuts (GA).
• OneLake catalog v Excelu (preview) a na úrovni tabulek a sloupců včetně náhledu dat.
• OneLake Table Read API (preview) – čtení Delta/Iceberg tabulek bez SQL přes Apache Arrow, s vynucením table/row/column security.
• Azure Databricks: čtení a zápis přes native storage v OneLake – nově podporované v produkci.
• IQ sharing (preview, brzy) – sdílení governed dat a kontextu mimo organizaci.
• Mirroring Google BigQuery (GA), obousměrná integrace se Salesforce Data Cloud 360 (preview), shortcuts na verzovaná data v lakeFS, federace Iceberg katalogů (AWS Glue, Google).

Data Factory

• Mirroring for SharePoint Lists (GA) a rozšířený mirroring včetně Change Data Feeds (GA).
• Snowflake Security Roles Replication (public preview) – role a oprávnění ze Snowflake se překládají do OneLake security.
• Mirroring Dynamics 365 Business Central – brzy.
• dbt Job in Fabric (GA), dbt Core v2 (Fusion) brzy.
• Dataflow Gen2: optimalizovaný zápis do lakehouse, V-Order compression controls, Shared Queries, nové destinace včetně Excelu a e-mailu, stažitelná diagnostika.
• Pipelines: Lakehouse Maintenance activity (vacuum/optimize), pipeline-level dependencies, exponential retry a Approval activity.
• Upgrade experience z Azure Data Factory – ADF pipelines vidíte ve Fabric workspace, s posouzením kompatibility a postupným upgradem.

Data Engineering a Data Warehouse

• Data engineering agent (preview) – technologie z akvizice Osmos, pro migrace, modernizaci lakehouse a ETL. Funguje i z GitHub Copilotu, VS Code, Codexu nebo Claude Code.
• Runtime 2.0: Spark 4.0 + Delta Lake 4.0.
• Materialized Lake Views (GA) a Custom Live Pools (GA).
• GPU-accelerated query execution ve warehouse (public preview) – zapíná se na úrovni workspace, bez změn dat a SQL.
• Custom SQL pools (GA), Teradata Migration Assistant (preview), nový node-based billing model pro warehouse.
• Migration assistant ze Synapse dedicated SQL pools umí nově incremental migration.

Fabric Apps a Planning

Fabric Apps dostaly PostgreSQL vedle SQL Serveru, TypeScript functions se Secret Store, vestavěné metriky používání a plugin Rayfin pro GitHub Copilot. Rayfin SDK a CLI jsou open source. Deployment pipelines pro Fabric Apps jsou zatím v plánu na zbytek roku.

U Planningu (GA od července) přibyl Native Planning Engine (preview, Rust + Apache Arrow, až 10× výkon), writeback plánu zpět do semantic modelu a event triggery po writebacku – spustíte pipeline, refresh modelu nebo notebook. O cestě od SSAS writebacku k Fabric Planningu jsem psal v tomto článku.

Fabric IQ a Real-Time Intelligence

• Agentic tvorba ontologií ze semantic modelů, OneLake dat a dokumentů – včetně Power BI DAX measures v ontologii.
• Operations agent: root-cause analysis a pre-approved actions (preview).
• Business Events (GA), Copilot tvorba Real-Time Dashboardu (preview).

SQLCon

• Database Hub in Fabric (preview).
• Database agents pro SQL a PostgreSQL – rolling out v preview.
• DiskANN vector indexes (GA) v Azure SQL DB Hyperscale, SQL MI a SQL database ve Fabricu.

Závěr

Dnešní článek měl shrnout, co Microsoft oznámil na FabConu Europe 2026 v Barceloně – nejdřív pro Power BI, potom pro Fabric. Pro Power BI vývojáře je to hlavně PBIP v GA a agentic vývoj, který opustil preview. Pro Fabric nový pohled na billing a spousta práce kolem governance a CI/CD.

Berte to jako snapshot stavu k 30. 9. 2026 – u řady položek Microsoft termín ani status zatím neuvádí. Svůj osobní výběr toho, co budu zkoušet jako první, pošlu v příštím Weekly BI Digestu.

Co jsou Fabric Apps

Fabric Apps jsou nový typ itemu ve workspace. V kostce – webová aplikace, která běží přímo na Fabricu. Žádný externí hosting, žádné lepení krabiček od různých vendorů. Autentizace přes Entra ID, governance přes workspace permissions, data přes OneLake.

Dají se rozdělit na dvě části. Jednak operační appky – plnohodnotné webové aplikace, kde data nejen čtete, ale i zapisujete. Pamatujete, jak jsme se v jednom z předchozích dílů Cesty do Fabricu bavili o tom, že write-back může řešit i planning? Tohle je přesně ta kategorie. A zajímavé je to i pro nás z Power BI světa, protože to řeší věci, které Power BI samo o sobě nikdy neřešilo. A pak data apps – vizualizační dashboardy nad sémantickým modelem, kde se dotazy posílají přes DAX. Na ty se zaměřím hlavně.

Kde je Rayfin

S Fabric Apps úzce souvisí Rayfin – open-source SDK a CLI. Rayfin je nástroj, Fabric Apps je výsledek. Napíšete npx rayfin up a Rayfin vám nasadí kompletní backend – SQL databázi, GraphQL API, autentizaci, static hosting – přímo do vašeho Fabric tenantu. Microsoft to na Buildu demonstroval ve spolupráci s Replitem a byznys problém pojmenoval přesně: vygenerovat frontend zvládne dnes agent za hodinu. Produkční backend, který je bezpečný, škálovatelný a s důrazem na governance – to je ta těžší část. Rayfin ji řeší tím, že to všechno dědí z Fabricu. Detaily najdete v oficiálním blog postu na Fabric Community.

Jak to vypadá pod kapotou? Úplně jinak než v Power BI. Tady není žádné uživatelské rozhraní. Všechno se píše jako kód – nebo se musíte spolehnout na coding agenta (GitHub Copilot, Claude Code nebo jiný). Pod každou vizualizací je soubor s koncovkou .dax, který posílá DAX dotaz do sémantického modelu. Samotné vizualizace kombinují TypeScript, CSS, Vega/VegaLite. Máte nad tím absolutní kontrolu – můžete ten DAX dotaz odladit, můžete každý pixel posunout. Ale musíte to umět, nebo donutit agenta, aby to uměl za vás.

Nechal jsem Claude Code, ať se podívá do prohlížeče na můj starý report, prokliká si ho a vygeneruje mi novou verzi jako data app. Zadání: podívej se, co tam je, zachovej ty informace, ale zkus to udělat líp – drž se best practices pro vizualizace. Tady se mi agent rozjel.

Před (originál Power BI)

Dvě stránky, které měly být identické (lišila se jen metrika – obrat vs. marže), mi vygeneroval každou jinak. Některé vizualizace chyběly, některé byly úplně jiné. Interakce mezi vizualizacemi – to, co má Power BI by design – tady musíte explicitně naprogramovat. Kliknu do sliceru a chci, aby se překreslily všechny grafy na stránce? Musím to říct. Export do Excelu? Řazení? Prokliky? Totéž.

Jeden praktický postřeh. Při nasazení mi Rayfin automaticky vygeneroval Fabric SQL database, kterou jsem pro čistou data app vůbec nepotřeboval – tahal jsem data ze stávajícího sémantického modelu, ale zapomněl jsem to agentovi říct. Krátkodobě to vytížilo mou F2 kapacitu na 886 %. Jakmile jsem databázi odstranil, samotné interakce s data app byly z pohledu CU v podstatě zadarmo.

Nahradí to Power BI?

Ne. A myslím si, že to ani nemá. Kurt Buhler z Tabular Editoru to rozebral v článku, kde to přirovnal k legu a 3D tiskárně. Power BI je lego – pokládáte kostičky, máte hotový výsledek rychle, self-service uživatel si postaví report sám. Fabric Data Apps jsou 3D tiskárna – máte absolutní volnost, ale potřebujete úplně jiný skill.

Připomíná mi to příchod Power BI vedle Reporting Services. Tehdy všichni spekulovali, jestli Power BI nahradí paginated reporty. Microsoft v té době možná hůř komunikoval vizi a teprve čas ukázal, že to není náhrada, ale doplněk – vykrytí slabých míst platformy. Tady čekám totéž. Power BI zůstane pro self-service analytiku, pro běžného business uživatele, který si otevře Power BI Desktop a při troše štěstí report nakliká. Fabric Apps jsou pro profi vývojáře, který potřebuje custom, pixel-perfect, propojitelné s aplikační vrstvou – zápisy do databáze, napojení na externí API, komentování.

Kde to ale vidím jako skutečný přínos, je potenciální náhrada Power Apps. Vojta zná firmy, kde Power Apps používají třeba jako katalog reportů – přesně tohle by šlo nativně přesunout do Fabric Apps. Pokud už máte Fabric jako platformu, proč byste do toho vnášeli další platformu s vlastním licenčním chaosem?

Na co si dát pozor

Fabric Apps jsou v preview a nejsou dostupné ve všech regionech. Já jsem narazil s kapacitou v North Europe – musel jsem si vytvořit novou kapacitu ve West Europe. S Vojtou jsme v podcastu řešili, jestli se k Fabric Apps dostane uživatel bez Power BI Pro licence. V tu chvíli jsme to nevěděli, tak jsem to pak dohledal – uživatel s oprávněním "Run and interact" může Fabric App používat bez Pro licence, ale pouze na kapacitě F64 a výš. Pod F64 je Pro stále potřeba. Pokud jste na menších kapacitách – já na svém testovacím tenantu jedu na F2 – tak to je dobré vědět. A jedno obecnější riziko, o kterém se na LinkedIn už diskutuje – díky agentům je dnes schopný vygenerovat webovou aplikaci skoro kdokoliv. Nechat si to kompletně nagenerovat a nerozumět tomu kódu vůbec – to není úplně bez rizika. Ale to není specifické pro Fabric Apps, to je problém celého vibe codingu. Je to čerstvě vytažené z trouby.

Závěr

Dnešní post se věnoval Fabric Apps – novému typu workspace itemu, který rozšiřuje Fabric o plnohodnotné webové aplikace. Fabric už není jen základna pro vaše data, ale je to kompletní platforma. Pro vizualizační scénáře jsou data apps alternativa s daleko větší volností než Power BI, ale za cenu výrazně vyšší komplexity. Pro operační scénáře je to potenciálně cesta, jak se zbavit Power Apps v kontextu Fabricu. Stále je to preview, stále je to v plenkách. Já osobně budu číhat na use case, který bude lepší fit pro Fabric Data App než pro Power BI report. Do té doby jedu dál Power BI. A budu se seznamovat i s operational apps – to je pro mě zatím neprobádané území.

V Cestě do Fabricu jsme s Vojtou rozebrali i další střípky z Buildu 2026 – storage tiers, GPU-akcelerovaný warehouse a další.

Nebudu procházet všech 100+ announcementů. Zaměřím se na to, co je relevantní pro nás – lidi, co pracují s Power BI a Microsoft Fabric. Pokud vás zajímá AI infrastruktura, Surface hardware nebo quantum computing, tohle není ten správný článek.

Microsoft IQ – sémantický mozek pro agenty

Hlavní story letošního Build se dá shrnout do jednoho slova: agenti. Microsoft představil Microsoft IQ jako sjednocenou inteligentní vrstvu – kombinaci Work IQ (data z M365), Foundry IQ (znalostní báze), Fabric IQ Ontology (business sémantika) a nového Web IQ (grounding z webu). Je to GA od včerejška.

A tady je klíčová věta pro Power BI svět: sémantické modely Power BI jsou explicitně základem, na kterém agenti staví. Microsoft mluví o 30+ milionech sémantických modelů v produkci. Ontologie v Fabric IQ tyto modely rozšiřují o operační kontext – entity, vztahy, pravidla, akce. GA by mělo být v nejbližších měsících.

Jinými slovy – dobře navržený sémantický model není jen základ pro reporty, ale i pro agentní AI. Pokud jste investovali čas do kvalitního modelování, právě se vám to začíná vracet.

GPU-akcelerovaný Fabric Data Warehouse

Tohle je technicky asi nejzajímavější Fabric novinka na Build. Fabric Data Warehouse dostane GPU akceleraci – v interních benchmarcích Microsoft naměřil až 7× rychlejší výkon oproti třem hlavním cloudovým warehoussům. Výzkum za tím dostal cenu ACM SIGMOD za Best Industry Paper 2026. Early access preview bude v červenci 2026.

Data Agents v M365 Copilot – GA

Fabric Data Agents jsou nově GA v Microsoft 365 Copilot. K tomu přibyla podpora Service Principals, sledování přes Microsoft Foundry a Creator Agent pro SQL a Eventhouse zdroje. To všechno je v červnovém Fabric Feature Summary, který vyšel – jak jinak – souběžně s keynotem.

Copilot Credits a nový consumption model

Agent work přechází na consumption model: pay-as-you-go za $0.01/credit, nebo předplacené balíčky. Per-user Copilot licence zůstává pro lidské používání Copilota. Jinými slovy – agenti si platí zvlášť. Tohle bude zajímavé sledovat z pohledu FinOps.

OneLake – storage tiers a item-level reporting

Dvě praktické novinky v preview. Za prvé – lifecycle management pro automatický přesun dat mezi storage tiers (podle created/modified/accessed). Za druhé – item-size reporting, které konečně ukazuje storage breakdown na úrovni jednotlivých itemů, včetně system a soft-deleted dat. To je přesně ta viditelnost, co v Capacity Metrics app chybí.

Rayfin – backend jako služba přímo ve Fabric

Tohle je pro mě osobně jedna z nejzajímavějších novinek. Rayfin je open-source SDK a CLI, které umožní definovat kompletní aplikační backend v kódu – datový model, business logiku, API, autentizaci, přístupová pravidla – a jedním příkazem to celé nasadit do Microsoft Fabric. Data zůstávají v OneLake, aplikace běží jako first-class Fabric artefakt a automaticky dědí governance a zabezpečení tenantu.

Prakticky řečeno – je to odpověď na problém, který zná každý, kdo viběkóduje: AI vám vygeneruje frontend za hodinu, ale backend pro produkci je na týdny. Rayfin tu mezeru chce zavřít. Launch partnerem je Replit – postavíte aplikaci v Replitu, napíšete "rayfin up" a backend se nasadí do vašeho Fabric tenantu. Pricing zatím nebyl zveřejněn a bez Fabric kapacity to nepoběží – není to standalone služba. Preview je dostupné od včerejška.

Fabric Apps – custom webové dashboardy nad sémantickým modelem

Nový typ Fabric itemu, který by mohl být pro Power BI komunitu tou nejzásadnější novinkou z celého Build. Fabric Apps umožňují vytvořit kompletní webovou aplikaci – včetně dashboardů s vizualizačními knihovnami jako Vega nebo D3.js – a dotazovat se sémantického modelu v DAXu. Autentizace, RLS, governance – to všechno se dědí z Fabric platformy.

Důležitý detail: žádné UI na tvorbu. Je to čistě code-first workflow – HTML, CSS, TypeScript, DAX. Očekávaný způsob tvorby je přes coding agenty jako GitHub Copilot nebo Claude Code. Nenahrazuje to Power BI reporty – pokud potřebujete standardní self-service reporting, Power BI nikam neodchází. Ale pokud chcete pixel-perfect dashboard s plnou kontrolou nad vizualizacemi, tohle je nová cesta.

Kurt Buhler to na LinkedInu shrnul výstižně – přirovnal to k rozdílu mezi stavebnicí Lego a 3D tiskárnou. Větší volnost, větší komplexita, jiné use cases. Ve svém testování uvádí, že tvorba bespoke dashboardu byla s Fabric Apps výrazně rychlejší než v Power BI. Pokud vás téma zajímá, doporučuji jeho podrobný článek na Tabular Editor blogu.

A co ještě stojí za zmínku

V kostce: CI/CD pro SQL analytics endpoint (preview). GitHub Enterprise Cloud s data residency pro Git Integration (GA). Materialized Lake Views fungují across lakehouses a workspaces. Real-Time Intelligence dostalo AI-powered vizuály a Kafka + Service Bus konektory jsou GA.

Z platformových věcí mimo Fabric: Microsoft Foundry má 11 000+ modelů v katalogu, včetně Claude a GPT-5.5. Nová kategorie "Autopilots" s Microsoft Scout. A pro developery – GitHub Copilot CLI umí nově pracovat s Fabric IQ skills přímo z terminálu.

Co nebylo řečeno

Build je tradičně o architektonické strategii a developer preview. Nepadlo nic o licencování Fabric SKU ani o cenových změnách – to bývá doména Ignite. Konkrétní GA milníky pro Fabric IQ Ontologies a Power BI novinky očekávám na FabCon Europe v Barceloně (28. 9.–1. 10. 2026). Tam se uvidíme.

Závěr

Letošní Build jasně ukazuje směr: sémantický model už není jen základ pro reporty, ale pro celou agentní vrstvu. GPU akcelerace Warehouse je technicky impozantní a OneLake storage management jsou přesně ty practical improvements, co v produkci chybí. Podrobněji tohle probereme s Vojtou v příštím díle podcastu Cesta do Fabricu.

Zdroje

• Microsoft Build 2026 Live Blog (náhrada za tradiční Book of News)
• Building Agentic Apps with Microsoft Fabric and Microsoft Databases (Arun Ulag, Azure Blog)
• Fabric June 2026 Feature Summary (Patrick LeBlanc)
• Introducing Rayfin (Fabric Blog)
• Fabric Apps explained: Visualization as code in a data app dashboard (Kurt Buhler, Tabular Editor Blog)

V posledním díle podcastu jsme s Vojtou prošli celou historii tady té funkcionality — od prehistorie přes mezistupně až po Fabric Planning. Tenhle post to shrnuje i s technickými detaily, které se do podcastu nevešly.

Historické okénko: writeback v době SSAS Multidimensional

Potřeba zapisovat data zpět do modelu není nová. V době SSAS Multidimensional — na jehož engine je Power BI postaveno — to existovalo pod názvem writeback. Pod measure group vznikly minimálně 2 partitions: jedna zobrazovala aktuální data z databáze, druhá držela změny a zapisovala je do databázové tabulky. Uživatel mohl zapisovat buď přes MDX příkazy (k tomu existovaly nástroje třetích stran), nebo od Excelu 2010 přímo z kontingenční tabulky připojené na multidimenzionální model.

Záludnost spočívala v alokaci. Pokud člověk plánoval na vyšší úrovni hierarchie — třeba na úrovni roku a produktové kategorie — musela se ta čísla zhmotnit na detailní úrovni. Rovnoměrná alokace mohla v horším případě vygenerovat statisíce až miliony řádků. Podle toho, kolik bylo možných kombinací. Kdo tohle zažil v produkci, ví, o čem mluvím.

V době Power BI a SSAS Tabular (2. generace) Microsoft na writeback dlouho nativní odpověď neměl. Takže kdo potřeboval zapisovat — třeba jen komentáře — sáhl po Power Apps. Formulářové aplikace, které uměly zapsat do libovolné destinace. Nicméně Power Apps má pro mě strmou křivku učení. A licenční model? SharePoint list byl zdarma. Přímý zápis do SQL databáze byl placený konektor.

Translytical Task Flows: writeback přímo z Power BI

Paralelně s tím přišly Translytical Task Flows — Power BI funkcionalita, která ve spolupráci s User Data Functions (UDF) ve Fabricu umožňuje writeback přímo z Power BI prostředí. Pojmenování je trochu chaos, protože ve stejnou dobu vyšly i User Defined Functions v DAXu — a obojímu se říká UDF. Interně si to rozlišujeme jako UDFA (Fabric item) vs. UDFX (DAX).

UDF je v podstatě libovolný Python kód — typicky právě zápis zpět do zdroje. Uživatel klikne na řádek v reportu, napíše komentář do textového pole, a během vteřiny je to v databázi. Není to jako klikat přímo do buňky v Excelu. Je to textové pole, které je furt na stejném místě bez ohledu na to, kde kliknete. Ale je to nejbližší věc, co Power BI momentálně nabídlo — a pro komentáře nebo jednoduché přírůstky to funguje.

Fabric Planning: tabulka, do které se konečně dá psát

Plan item je nový item ve Fabricu, který vypadá a chová se jako Excel. Máte tam pivotku, do které se kliká. Pojem buňka existuje. Připojíte se na existující sémantický model, data jsou živá, a více lidí se dívá na stejné místo. Žádné sdílené excely na SharePointu, žádné posílání příloh mailem.

Plan item nabízí tři typy sheetů:

• Planning sheet — klasický forecasting a budgeting. Připojíte se na sémantický model, vykonstruujete pivotku, a v režimu scénáře přepisujete čísla. Ta reálná data v pozadí se nemění — scénář je váš sandbox.
• Power Table sheet — správa master dat. Typický příklad: kurzovní lístek. Britská pobočka plánuje v GBP, konsolidace je v EUR — Power Table sheet to umí vzít v potaz.
• Intelligence sheet — vizuální vrstva přímo v Plan itemu. Waterfally, progress bary, grafy scénářů. Teoreticky nemusíte výsledky exportovat do Power BI reportu — je to integrovaný frontend.

Writeback: kam a kolik řádků to vygeneruje

Writeback v Plan itemu slouží k uložení naplánovaných dat pro další komponenty — sémantický model, pipeline, reporting. Aktuálně jde writeback pouze do SQL databáze ve Fabricu. Lakehouse ani warehouse zatím ne.

Jak se data zapíší závisí na zvoleném módu:

• Long (default) — 1 řádek za 1 buňku. Pokud máte rok, měsíce a 10 produktů, tak to vynásobte. Hodně řádků. Stejný princip jako historická alokace v multidimenzionálu.
• Wide — sloupcový formát, méně řádků. Atributy se stanou sloupci. Víc připomíná strukturu pivotky.
• Long with changes — přidává preview value a latest value k každé změně. Máte historii, ale i víc dat.

Co to vlastně stojí

Podle dokumentace Plan item sám o sobě nic nestojí — Microsoft za něj neúčtuje žádné extra CU ani licence. Realita na pozadí je ale trochu jiná.

Celá pravda: každý Plan item automaticky vyrobí Fabric SQL Database, která ukládá veškerá metadata a operace. SQL databáze zadarmo není. Vojta si měřil hodinu aktivního klikání a vrtění v Plan itemu — řádově 1 000 CU. Na F2 kapacitě máte denní budget 172 800 CU (86 400 sekund × 2). Hodina plánování denně je tedy zhruba 0,5 % denního budgetu.

K tomu přičtěte, že SQL databáze dotáčí CU ještě nějakou dobu po operaci — reálně to může být 15–20 000 CU i víc. Výsledek: nezruinuje vás to. Ale není to zadarmo. A pro planning, který probíhá typicky v špičkách — jednou za měsíc nebo za kvartál — dává smysl kapacitu při potřebě škálovat nahoru a po skončení planningového cyklu zase dolů.

Formula language a trochu byznysu okolo

Jazyk formul v Plan itemu je prakticky Excel. IF, SUM, COUNT — nic nového. Jedna drobnost, která ale plannery potěší: pokud chcete zvýšit hodnotu o 9 %, napíšete +9 %. Systém si to přepočítá sám. Nemusíte si pamatovat, že to je ×1,09. Ocení to i lidé, kteří trojčlenku ovládají, ale radši ji neřeší.

Kontext, jak Planning vůbec vznikl: Microsoft tuhle funkcionalitu nenaprogramoval od nuly. Integroval řešení firmy Lumel (přibližně 400 zaměstnanců), která historicky dodávala custom vizuály pro writeback a plánování v Power BI. Nešlo o akvizici — šlo o partnerství, kde Lumel integroval svůj produkt přímo do Fabricu. Výhoda pro obě strany: Microsoft nabídne nativní plánovací nástroj jako součást platformy, Lumel neřeší procurement a certifikační procesy u každého zákazníka zvlášť. Pokud jste někdy zažili debatu s nákupním oddělením o schválení nástroje třetí strany, tak víte, proč to byl pro obě strany no-brainer.

Preview a jak to zapnout

Plan item je aktuálně v preview. Defaultně vypnutý — musíte ho explicitně zapnout v admin portálu. Po zapnutí počítejte se zpožděním 15–20 minut, než se aktivuje. Dostupnost závisí na regionu. West Europe funguje — Vojta testoval. Pokud máte tenant jinde, ověřte si seznam podporovaných regionů v dokumentaci předtím, než zákazníkovi slíbíte demo.

Závěr

Dnešní post vám měl ukázat cestu od historického SSAS writeback přes Power Apps a Translytical Task Flows až po Fabric Planning. Je to první nativně integrovaná odpověď v Power BI ekosystému na otázku z controllingu, která mě provází od začátku kariéry.

Celou historii jsme s Vojtou Šímou probrali v podcastu Cesta do Fabricu — pokud dáváte přednost mluvenému slovu, poslechněte si ho tam.

Princip jednoduchý. 

1. Uložit stávající soubor (vytvořený 2016) jako pbip. Rozložení do složkové struktury a lepší čitelnost pro agenta. Ze semantického modelu vykostit cache.abf. Ta je zde stejně k ničemu a zbytečně nafukuje soubor. Nechci ani nikam dávat data. 
2. Soubor zazipovat, hodit screenshot s layoutem a popsanými úpravami do vašeho oblíbeného chatbota (v mém případě Claude Opus 4.6 extended thinking).
3. A zadat prompt s úpravami.

Microsoft M365 Copilot

Gemini 3 thinking a 3.1 PRO

ChatGPT 5.4 Thinking

Závěr

Nyní se zaměříme na to, jak data do Lakehouse dostat. Máme čtyři způsoby a tento článek nebude pokrývat všechny.

• Shortcuts (ala zástupce na ploše)
• Pipelines (ala Azure Data Factory)
• Dataflows Gen 2 (Power Query Low Code)
• Notebooky v Pythonu

Dnes se zaměřím na poslední zmíněné – notebooky v Pythonu. Pro uživatele přicházející z Power BI světa možná nejméně intuitivní, ale mohou být efektivní, co se týče CU (Capacity Units), pokud je používáte dobře.

Porovnáme si čtyři různé typy knihoven v Pythonu, které mi umožní načíst data do Lakehouse. Na paškál jsem si vzal demo dataset New York City Taxi data, který je rozumně velký – necelé dva roky dat (01/2024–09/2025), celkem 76 milionů záznamů.

PySpark

Defaultně vám Fabric nabídne PySpark, který startuje Spark cluster a má několik pracujících uzlů. Jinými slovy – na malé kapacitě jdete okamžitě do burstingu, krátkodobě přetížíte kapacitu a jedete na dluh, kdy si půjčujete Capacity Units z budoucnosti.

Kód by mohl vypadat následovně. Aby si s Timestamp daty poradil i SQL Analytics Endpoint, můžete si všimnout CASTů.

Doba trvání na F2: 1:23. Pro menší objemy dat čekáte zbytečně na start clusteru, abyste zapsali pár řádků, a přetížíte Fabric F2 kapacitu. Důležité je, že to funguje.

Pandas

Pokud ale válčíme na malé kapacitě s burstingem, mohli bychom zkusit čistý Python. Jedna z nejpoužívanějších knihoven pro práci s daty v Pythonu je Pandas. Sám, když jsem s Pythonem začínal, byla Pandas jedna z prvních knihoven v rámci kurzů.

Kód by mohl vypadat například následovně:

Nebudu vás napínat – Pandas se snaží načíst všechna data do paměti, než je začne zapisovat. Na malé kapacitě, jako je F2, jsem při těchto objemech dat opakovaně skončil na Out Of Memory Exception. Trvalo to cca 1:45 – pokud na tom záleží, když to nedoběhlo. Odpočívej v pokoji, Pando, alespoň pro use case větší objem dat na malé kapacitě.

DuckDB

Když jsem se před nějakou dobou bavil se Štěpánem Rešlem (kterého tímto zdravím, pokud tohle náhodou čte), doporučil mi knihovny DuckDB a Polars jako efektivnější při využití paměti s podporou stránkování. Tak jsem to zkusil.

Stránkování jsem nastavil na 100 000 záznamů. Kód notebooku vypadá následovně:

Musel jsem opět řešit timestamp sloupce, stejně jako u PySparku. Díky stránkování F2 nepřekročila svých dedikovaných 16 GB paměti a load doběhl za 2:20. O něco pomalejší než PySpark, ale single node a kachna nevylezla z paměti a udělala to, co bylo potřeba.

Polars

Díky doporučení od Štěpána a šťourání od Vojty Šímy (kterého taky zdravím 🙂) jsem si řekl, že zkusím totéž i v Polars. Tady to bylo na nejvíce iterací, ale nakonec jsem se dostal k funkčnímu kódu, který by mohl vypadat takhle:

Doba trvání: 1:22, doběhla a funguje.

Závěr

Stejné cvičení, různé nástroje. Tři ze čtyř soutěžících došli do cíle. Každý má své silné a slabé stránky – každý ať si udělá závěry sám, nebo provede vlastní měření. Nebudu předstírat, že jsem guru na všechny zmiňované knihovny, a pomáhal mi kamarád Claude.

Osobně si z toho odnáším následující postřehy. PySparku se snažím pokud možno vyhýbat na malé kapacitě – už se mi stalo, že jsem si ji při jiných akcích na 24 hodin odstavil. Pandas žere paměť jako by se jednalo o eukalyptus a může přečerpat limit. S Polarsem mám ve finále hezké rozuzlení a dobrý čas, trvalo mi ale za pomoci LLM nejdéle to rozchodit tak, aby doběhlo. DuckDB funguje, dobíhá a podařilo se mi ji rozchodit velmi rychle i s laděním chyb – i když za cenu o něco delšího běhu.

Nebudu tvrdit, že některá knihovna je špatná nebo lepší než ostatní. To si musí každý zhodnotit sám a záleží primárně na kontextu, čeho se snaží dosáhnout. Já ale budu při příštích podobných use cases pošilhávat po DuckDB a Polars.

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 .

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"

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

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

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].

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.

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?

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).

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.

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.

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:

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

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

Fakturuji půl dne za optimalizaci.

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.

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á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ě.

Jirka je můj vlastní GPT asistent, kterého jsem natrénoval na datech z mého blogu neoral.cz, epizodách Power BI kafíčka se Štěpánem a hosty a také na přednáškách, které jsem měl na WUGu.

Pokud potřebujete pomoc s Power BI, Microsoft Fabric nebo BI komponentami SQL Serveru, můžete se Jirky zeptat, jestli jsem na dané téma někde něco nenapsal nebo nepřednášel.

Jirku najdete zde:
https://chatgpt.com/g/g-67bb6d5866e881919b7d61e302e5846b-jirka

Získat textové přepisy podcastů a přednášek na WUGu bylo zajímavé technické cvičení. Jirka zatím není dokonalý, ale budu ho dál ladit. Přidal jsem mu také některé informace o sobě mimo práci.

Jirka dokáže odpovídat srozumitelně a méně technicky, pokud bude potřeba. :)

Tak či tak se můžete zamyslet nad použitím deployment pipelines v Microsoft Fabric/Power BI.

V prvním kroku budeme potřebovat 2–3 pracovní prostory podle počtu prostředí. V mém případě tři – pro vývoj, test a produkci.

Vybereme počet prostředí, která chceme použít. V mém případě všechny tři.

Přiřadíme workspaces k prostředím. Zde pozor – lze vybrat pouze workspaces na dedikované kapacitě MS Fabric nebo Power BI Premium. Dobrá zpráva je, že u MS Fabric stačí SKU F2, tedy to nejlevnější.

Při výběru prostředí, do kterého chceme změny nasadit, se nám dole provede porovnání obsahu (1). Můžeme po kliknutí na ikonu s bleskem (2) nastavit pravidla pro nasazení (3), jako například změnu mappingu z vývojového serveru na test/produkci, změnu databáze a podobně.

Závěr

Deployment pipelines jsou skvělým nástrojem, jak od sebe oddělit jednotlivá prostředí vývojového cyklu reportů s možností posouvat změny. Zpravidla změny posouváme manuálně, protože než report nasadíme do produkce, musí projít testingem. Posledním krokem bývá aktualizace Power BI Apps, aby se změny promítly. Abyste mohli deployment pipelines používat, budete potřebovat workspaces přiřadit na dedikovanou kapacitu MS Fabric, případně Power BI Premium, pokud jej ještě jako stávající zákazník máte k dispozici.

V době psaní článku je tato funkce v preview a je potřeba ji nejprve povolit v menu File - Options and Settings - Options - Preview features - TMDL View.

Po následném přepnutí do zobrazení (1) a přetažení celého sémantického modelu (2) můžeme upravit definici v textovém editoru bez prodlev v grafickém rozhraní a nad rámec toho, co UI umožňuje.

Dají se skriptovat a nahrazovat i dílčí objekty. Pro účely dnešního článku jsem vyskriptoval model jako celek.

K čemu může být TMDL zobrazení dobré? Pár příkladů z posledních týdnů.

Problém

Report u zákazníka. Padá mi automatická aktualizace. V chybové hlášce vidím, že účet nemá práva do databáze XYZ. Report obsahuje komplexní model s 50 dotazy – nechci hledat po jednom, kde se na databázi odkazuji.

Řešení

TMDL view, vyskriptovat definici sémantického modelu, CTRL+F - XYZ

Problém

Po nasazení zlobí RLS v modelu u zákazníka. V chybové hlášce je reference na pravděpodobně použitou funkci CROSSFILTER nebo USERELATIONSHIP. Kde to mám mezi těmi 200 measures hledat?

Řešení

TMDL view, CTRL+F CROSSFILTER/USERELATIONSHIP

Problém

Chceme globálně změnit formáty. Všechny procentuální metriky mají nově zobrazovat 1 desetinné místo místo 2.

Řešení

CTRL+F - % podívat se, jak je to napsané, a následně například CTRL+H pro nahrazení 0.00% za 0.0%

Myslím, že už máte určitou představu, kam tím mířím. Hledáním a nahrazováním ale použití TMDL nekončí. Další scénář může být přenos kódu mezi soubory.

Problém

Máte v jednom souboru tabulku s kalendářem vygenerovanou přes Power Query a potřebujete ji přenést do druhého souboru?

Řešení

Vyskriptovat ve zdrojovém souboru v TMDL, CTRL+C, CTRL+V v TMDL view cílového souboru a spustit.

A další

TMDL umožňuje spravovat i možnosti nedostupné v UI, například vlastnost isAvailableInMDX, která může pomoci s optimalizací úložiště. Pokud nevíte, co dělá, zatím ji prosím nezkoušejte. Pověnuji se jí někdy samostatně.

Závěr

Dnešní článek vám měl představit jazyk TMDL a vysvětlit, proč by vás měl zajímat. Výše zmíněné scénáře použití jsou jen začátek. Tak se do něj ponořte a podívejte se, s čím by mohl pomoci vám.

V době psaní tohoto článku jsou Visual Calculations dostupné v režimu Preview, a je tedy nutné je nejprve povolit. To provedete v File → Options and settings → Options → Preview features → Visual Calculations a následně restartujete Power BI Desktop.

Jaké Visual Level Calculations máme k dispozici? Nejjednodušeji s nimi můžete začít kliknutím na tři tečky v rohu vizualizace – viz obrázek.

Například bych chtěl porovnat aktuální prodeje s předchozím obdobím.

Versus previous =

if( --kontorola zda je co porovnávat

    ISBLANK([# Internet]) || ISBLANK(PREVIOUS([# Internet]))

    ,BLANK(), -- pokud ne, tak prázdná buňka

    -- jinak odečet

    [# Internet]-PREVIOUS([# Internet])

)

Tento přístup je výrazně jednodušší a přehlednější, přičemž stále poskytuje správné výsledky. Ve skutečnosti bychom si mohli vystačit i se základním výpočtem:

Versus previous = [# Internet]-PREVIOUS([# Internet])

Funkce PREVIOUS ve Visual Calculations vrací hodnotu z předchozího řádku vizualizace. To znamená, že její výsledek závisí na tom, jak jsou data ve vizualizaci seřazena. Pokud je tabulka setříděna sestupně podle data, funkce nebude vracet očekávané výsledky. Proto je důležité správně nastavit pořadí řazení.

Kdy použít Visual Calculation a kdy Measure?

Measures

• Nejsou závislé na konkrétní vizualizaci – lze je znovu použít v různých reportech.
• Pracují přímo s datovým modelem a umožňují komplexní výpočty.
• Vhodné pro scénáře, kde je potřeba konzistentní výpočet v celém reportu.

Visual Calculations

• Jsou vázané na konkrétní vizualizaci, takže jejich použití je omezenější.
• Mají jednodušší syntaxi, což ocení zejména ti, kdo s DAXem začínají.
• V některých případech mohou mít lepší výkon, protože pracují s agregovanými daty ve vizualizaci místo s detailními daty v datovém modelu.

Výběr mezi Measure a Visual Calculation tedy závisí na konkrétním scénáři – pokud potřebujete opakovaně použitelný výpočet, měřítko (measure) je lepší volba. Pokud ale hledáte rychlé řešení v rámci jedné vizualizace, Visual Calculation může být efektivnější.

Visual Calculations jsou další skvělou součástí DAX arzenálu. Klasické measures stále mají své pevné místo, ale v některých situacích umožňují Visual Calculations jednodušší a efektivnější řešení s ohledem na výkon. Navíc fungují i pro Live Connection k SSAS a sémantickým modelům v Microsoft Fabric.

Živé demo Visual Calculations jsem ukazoval na své přednášce pro WUG. Záznam najdete zde:
Záznam přednášky na WUG

📅Chystám se téma podrobněji rozebrat na samostatné přednášce 20. 3. 2025 v rámci 9. ročníku Power BI Day. Rád vás tam uvidím i osobně!
Power BI Day 2025

📅 Pokud se chcete naučit jazyk DAX od základů až po pokročilé scénáře, včetně Visual Calculations, přijďte na můj celodenní workshop na Data Point Prague 29.–30. 5. 2025.
Data Point Prague 2025

Ve zkratce šlo o problém, kdy chci zobrazovat uživatelům stejně rozvržený report, ale mít možnost volit metriku. Stejné grafy, tabulky a další vizuály s možností vybrat mezi obratem, marží nebo náklady.

Dnes se podíváme na dynamiku z druhé strany, a sice z pohledu dimenzionálního.

Představte si stejný typ grafu, stejnou metriku, ale s možností zobrazit rozpad podle různých dimenzionálních atributů – například podle produktové kategorie, prodejního kanálu nebo třeba barvy.

A právě k tomu slouží field parameters.

K demonstraci použiju starou dobrou databázi Adventure Works DW, stejně jako u většiny příkladů.

Tvorba field parametru probíhá na záložce Modeling na pásu karet.

Nejprve nadefinujeme název parametru – zde Split (1), protože budu ovládat rozpad v grafu, matici a dalších vizualizacích. Následně vybereme seznam polí, která vytvoří hodnoty parametru v příslušném pořadí (2), a ponecháme zaškrtnutou možnost vytvoření sliceru (3).

V modelu se vytvoří počítaná tabulka Split, která obsahuje název parametru (1), kód (2) volající popisky nahrazené hodnotou (NAMEOF funkce) a pořadí. Tyto hodnoty se zobrazí ve sliceru (3).

Detail vygenerovaného kódu

Při tvorbě grafu a matice se nejprve zobrazí drill-down v defaultním pořadí.

Pokud ale nejprve vyberu měnu (Currency) a následně kategorii (Category), vizuál se překreslí následovně:

Jaká mají field parameters omezení?

Podle posledního testu v době psaní tohoto článku nejsou field parameters k dispozici v Power BI Desktopu určeném pro on-premises Power BI Report Server.

Stejně tak není možnost tvorby field parameters dostupná u live connection, protože v tomto režimu nelze vytvářet ani počítané tabulky. Pokud chcete použít field parameters, museli byste přepnout do DirectQuery režimu proti SSAS/Semantickému modelu. V takovém případě však může přepnutí do DirectQuery negativně ovlivnit výkon a funkcionalitu reportu.

Závěr