Jak načíst data do Fabric Lakehouse Pythonem, aniž zabijete F2 kapacitu

Vstupním bodem do Microsoft Fabricu, abyste mohli analyzovat data v Power BI, je Lakehouse. Něco mezi datovým skladem a Data Lake, který si bere to nejlepší z obou světů. Nejste svázáni přílišnou strukturovaností jako u Data Lake, ale zároveň máte k dispozici SQL Analytics Endpoint pro dotazování nad Delta Lake tabulkami. Tématu Lakehouse jsem se věnoval v jiných přednáškách a v podcastu Cesta do Fabricu s Vojtou Šímou.

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

import psutil, os

from pyspark.sql import functions as F

from pyspark.sql.types import TimestampType

def print_memory(label):

    mem = psutil.Process(os.getpid()).memory_info().rss / 1024**3

    print(f"[{label}] RAM used: {mem:.2f} GB")

print_memory("start")

spark.conf.set("spark.sql.parquet.outputTimestampType", "TIMESTAMP_MICROS")

df = spark.read.parquet("Files/NYC/")

print_memory("after read")

df = df.withColumn("tpep_pickup_datetime", F.col("tpep_pickup_datetime").cast(TimestampType())) \

       .withColumn("tpep_dropoff_datetime", F.col("tpep_dropoff_datetime").cast(TimestampType()))

df.write.format("delta") \

    .mode("overwrite") \

    .option("overwriteSchema", "true") \

    .saveAsTable("yellow_tripdata_spark")

print_memory("after write")

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ě:

import pandas as pd

import psutil

import os

from deltalake.writer import write_deltalake

def print_memory(label):

    mem = psutil.Process(os.getpid()).memory_info().rss / 1024**3

    print(f"[{label}] RAM used: {mem:.2f} GB")

print_memory("start")

# Pandas loads ALL files into RAM at once

df = pd.read_parquet('/lakehouse/default/Files/NYC/')

print_memory("after read")  # likely crashes here or reports 2-3 GB

write_deltalake(

    lakehouse.properties['abfsPath'] + "/Tables/yellow_tripdata_pandas",

    df,

    mode="overwrite",

    engine="pyarrow"

)

print_memory("after write")

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ě:

import duckdb

from deltalake.writer import write_deltalake

import notebookutils

lakehouse = notebookutils.lakehouse.get("NYC_taxi_data")

token = notebookutils.credentials.getToken("storage")

con = duckdb.connect()

# Cast timestamps explicitly to TIMESTAMP (no timezone, microsecond precision)

reader = con.execute("""

    SELECT

        * EXCLUDE (tpep_pickup_datetime, tpep_dropoff_datetime),

        tpep_pickup_datetime::TIMESTAMPTZ AS tpep_pickup_datetime,

        tpep_dropoff_datetime::TIMESTAMPTZ AS tpep_dropoff_datetime

    FROM read_parquet('/lakehouse/default/Files/NYC/*.parquet')

""").fetch_record_batch(rows_per_batch=100_000)

write_deltalake(

    lakehouse.properties['abfsPath'] + "/Tables/yellow_tripdata_duckDb",  # match exact casing

    reader,

    mode="overwrite",

    engine="rust",

    storage_options={"bearer_token": token, "use_fabric_endpoint": "true"}

)

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:

import pyarrow.dataset as ds

import pyarrow as pa

from deltalake.writer import write_deltalake

import notebookutils

import psutil, os, time

lakehouse = notebookutils.lakehouse.get("NYC_taxi_data")

token = notebookutils.credentials.getToken("storage")

def print_memory(label):

    mem = psutil.Process(os.getpid()).memory_info().rss / 1024**3

    print(f"[{label}] RAM used: {mem:.2f} GB")

start = time.time()

print_memory("start")

dataset = ds.dataset('/lakehouse/default/Files/NYC/', format='parquet')

# Check what type PyArrow sees

ts_field = dataset.schema.field("tpep_pickup_datetime")

print(f"Original type: {ts_field.type}")

# Force timestamps to us with UTC timezone — readable by SQL Analytics Endpoint

target_type = pa.timestamp("us", tz="UTC")

schema = dataset.schema

for col in ["tpep_pickup_datetime", "tpep_dropoff_datetime"]:

    idx = schema.get_field_index(col)

    schema = schema.set(idx, schema.field(col).with_type(target_type))

print_memory("after scan")

write_deltalake(

    lakehouse.properties['abfsPath'] + "/Tables/yellow_tripdata_polars",

    dataset.to_batches(),

    schema=schema,

    mode="overwrite",

    engine="rust",

    storage_options={"bearer_token": token, "use_fabric_endpoint": "true"}

)

print_memory("after write")

print(f"Execution time: {time.time() - start:.1f}s")

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.

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.