Power BI, Fabric a Azure Databricks

Databricks a Fabric dnes nejsou konkurenti na život a na smrt — Microsoft obě platformy prodává a od roku 2025 do nich systematicky doplňuje interoperabilitu pod heslem „better together". Pro datového inženýra to znamená příjemný problém: k datům v Unity Catalogu vede do Power BI hned několik cest a každá má jiné vlastnosti. Kdo zná jen „konektor na warehouse", platí zbytečně za compute; kdo slepě nasadí mirroring, může narazit na limity toho, co se mirroruje.

Čtyři hlavní cesty, které v této kapitole probereme:

• Power BI konektor na Databricks SQL Warehouse — klasika: Import nebo DirectQuery, dotazy platí Databricks compute.
• Mirroring Unity Catalogu do Fabricu — katalogový (metadatový) mirroring, data zůstávají na místě, Fabric je čte přes shortcuts. Nad tím funguje Direct Lake.
• OneLake shortcuts / OneLake jako storage — Fabric ukazuje na Delta soubory v ADLS Gen2, nebo Databricks přímo čte a zapisuje do OneLake.
• Delta Sharing — otevřený protokol pro sdílení mezi organizacemi a platformami, včetně Power BI konektoru.

Nativní Azure Databricks konektor v Power BI Desktopu se připojuje na SQL Warehouse (pro BI zátěž doporučené, ideálně serverless — viz kapitola 2) přes ODBC/HTTP; novější verze umí přepnout na ADBC (Arrow) driver, který zrychluje přenos velkých výsledků — přesný stav a plán přechodu na ADBC jako výchozí ověřte v dokumentaci, protože se dotkne i vašich gateway verzí. Autentizace jde přes Microsoft Entra ID pro interaktivní práci a přes OAuth service principal (M2M) pro plánované refreshe ve službě. Připojení zvládne i Partner Connect přímo z Databricks UI.

Zásadní volba je storage mode datasetu:

• Import — Power BI si při refreshi zkopíruje data do své in-memory VertiPaq engine. Vizuály pak běží z paměti, typicky pod sekundu, a SQL Warehouse se dotkne jen refresh. Platíte však duplikací dat, limitem velikosti modelu a zpožděním (data jsou stará jako poslední refresh).
• DirectQuery — každá interakce s vizuálem vygeneruje DAX, který se přeloží do SQL a odletí na SQL Warehouse. Data jsou vždy čerstvá a model nemá limit velikosti, ale latence reportu závisí na warehouse a každý klik stojí compute. Pozor: Databricks.Query (native query) má v kombinaci s DirectQuery omezení — chování ověřte v dokumentaci konektoru.

Většina „Power BI nad Databricks je pomalé" příběhů má stejné kořeny: report sedí přímo na širokých bronze/silver tabulkách, warehouse je poddimenzovaný nebo chybí statistiky. Zásady, které fungují:

Na straně Databricks: reporty připojujte výhradně na gold vrstvu — hvězdicové schéma, ne široké ploché tabulky. Tabulky udržujte přes OPTIMIZE s liquid clusteringem podle filtračních sloupců a sbírejte statistiky, aby optimalizátor generoval rozumné plány. Nejdražší agregace předpočítejte jako materialized views (viz kapitola 3, případně sekce 10.6) — warehouse pak servíruje hotové výsledky:

-- statistiky pro optimalizator
ANALYZE TABLE main.gold.sales_fact COMPUTE STATISTICS FOR ALL COLUMNS;

-- predpocitana agregace pro nejcastejsi vizual
CREATE MATERIALIZED VIEW main.gold.sales_by_month_mv AS
SELECT date_trunc('month', order_date) AS month,
       region,
       sum(amount) AS revenue
FROM main.gold.sales_fact
GROUP BY ALL;

SQL Warehouse pro BI zátěž dimenzujte spíš na více clusterů (autoscaling) než na větší velikost — BI generuje hodně malých souběžných dotazů, ne jeden velký. Pomáhá Photon (u SQL Warehouse vždy zapnutý) a vrstvy cache: result cache vrací opakované dotazy okamžitě (typicky slicery a sdílené dashboardy), disk cache drží horká data lokálně.

Na straně Power BI:

• Composite model — fakta v DirectQuery, dimenze v Dual/Import módu. Slicery pak nechodí na warehouse vůbec.
• User-defined aggregations — malá Import tabulka s agregáty „chytá" většinu dotazů, na detail se sáhne DirectQuery jen při drill-down.
• Incremental refresh u Import módu — refreshuje se jen poslední partition, ne celá historie; s Databricks konektorem funguje díky query foldingu přes RangeStart/RangeEnd.
• Assume referential integrity na relacích — generuje INNER JOIN místo OUTER, což je pro warehouse levnější (jen pokud FK integrita opravdu platí!).
• Méně vizuálů na stránce — každý vizuál v DirectQuery je minimálně jeden SQL dotaz.

Mirrored Azure Databricks catalog je z pohledu Fabricu položka, která zrcadlí strukturu Unity Catalogu. Klíčové slovo je struktura: na rozdíl od mirroringu databází (SQL, Cosmos…) se zde nekopírují žádná data. Fabric si stáhne metadata katalogu (schémata, tabulky) a k samotným Delta souborům přistupuje přes interní shortcuts do ADLS Gen2. Dokumentace: „When you use Fabric to read data that is registered in Unity Catalog, there is no data movement or data replication." Funkce je GA (obecně dostupná od poloviny 2025).

Co po vytvoření mirrored katalogu dostanete:

• položku Mirrored Azure Databricks ve workspace s vybranými schématy/tabulkami,
• automaticky vygenerovaný SQL analytics endpoint — read-only T-SQL dotazování nad Databricks tabulkami z Fabricu,
• možnost postavit nad tím Direct Lake semantic model pro Power BI (viz sekce 15.7).

Metadata se synchronizují automaticky: přidání/odebrání schématu či tabulky v UC se propíše do Fabricu. Změny dat se projevují s malým zpožděním (sekundy až minuty — jde o stejný mechanismus discovery jako u SQL analytics endpointu nad lakehouse). Governance zůstává dvojkolejná: Unity Catalog řídí přístup na straně Databricks, ve Fabricu platí Fabric permissions nad mirrored položkou — počítejte s tím v security review.

Delta Sharing (viz kapitola 5, sekce 5.6) je otevřený protokol pro sdílení Delta tabulek komukoli — jiné organizaci, jinému tenantu, jiné platformě. V kontextu Power BI a Fabricu má dvě podoby:

• Power BI Delta Sharing konektor — příjemce dostane credential soubor (endpoint URL + bearer token, nověji i OIDC federace bez tokenů) a připojí se z Power BI Desktopu konektorem „Delta Sharing". Data se načítají v Import módu; v Advanced options je limit řádků (výchozí 1 milion, lze zvýšit). Poskytovatele to nestojí žádný compute — příjemce čte Parquet soubory přímo přes sharing server.
• Fabric jako příjemce — data z Delta Share lze dostat do OneLake (např. přes shortcuts či dataflow) a dál s nimi pracovat ve Fabricu; možnosti a stav této integrace se vyvíjejí, ověřte aktuální dokumentaci.

-- poskytovatel: share + prijemce (open sharing)
CREATE SHARE gold_reporting;
ALTER SHARE gold_reporting ADD TABLE main.gold.sales_by_month;
CREATE RECIPIENT partner_bi;  -- vygeneruje aktivacni odkaz s tokenem
GRANT SELECT ON SHARE gold_reporting TO RECIPIENT partner_bi;

Delta Sharing je správná volba, když příjemce není ve vašem tenantu nebo nemá Databricks: dodavatelský řetězec, klienti, dceřiné firmy. Uvnitř jedné organizace s Fabric kapacitou bývá mirroring (15.4) pohodlnější — Delta Sharing tam přidává správu tokenů a limity konektoru navíc.

OneLake je logické datové jezero Fabricu — technicky ADLS-kompatibilní endpoint (onelake.dfs.fabric.microsoft.com), takže s ním Databricks umí pracovat jako s běžným ABFS úložištěm. Vztah funguje v obou směrech:

Fabric ukazuje na Databricks data — OneLake shortcuts. Shortcut v lakehouse je virtuální odkaz na externí úložiště: vytvoříte ADLS Gen2 shortcut na složku s Delta tabulkami, které produkuje Databricks, a tabulky se v lakehouse tváří jako lokální — bez kopírování, bez pipeline. Funguje to dobře pro external tabulky, u kterých znáte cestu; pro managed tabulky UC je čistější mirroring z 15.4, který cesty řeší za vás.

Databricks čte a píše OneLake — ABFS cesta. Na standardním clusteru stačí OAuth konfigurace se service principalem (Contributor na Fabric workspace):

# OAuth pres service principal (secrets, ne natvrdo!)
spark.conf.set("fs.azure.account.auth.type", "OAuth")
spark.conf.set("fs.azure.account.oauth.provider.type",
    "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
spark.conf.set("fs.azure.account.oauth2.client.id", client_id)
spark.conf.set("fs.azure.account.oauth2.client.secret", client_secret)
spark.conf.set("fs.azure.account.oauth2.client.endpoint",
    f"https://login.microsoftonline.com/{tenant_id}/oauth2/token")

# cteni a zapis pres OneLake ABFS endpoint
path = "abfss://BIWorkspace@onelake.dfs.fabric.microsoft.com/Prodej.lakehouse/Tables/dim_zakaznik"
df = spark.read.format("delta").load(path)
df.write.format("delta").mode("overwrite").save(path)

Tím může Databricks pipeline zapisovat gold tabulky rovnou do Fabric lakehouse — a Power BI je má okamžitě k dispozici pro Direct Lake, bez jakéhokoli mirroringu. Daní je, že takto zapsané tabulky žijí mimo governance Unity Catalogu (jde o přímý zápis na storage).

Novější vývoj tuto mezeru zaceluje — stav k srpnu 2026, ověřte v dokumentaci:

• OneLake catalog federation — Unity Catalog umí přes CREATE CONNECTION … TYPE onelake a foreign catalog číst Fabric Lakehouse a Warehouse bez kopie napřímo z Databricks (zero-copy opačným směrem). Přístup je read-only, vyžaduje DBR 18.0+ ve standard access mode (SQL warehouse 2025.40+) a nepodporuje views, materialized views ani komplexní datové typy.
• UC managed tables v OneLake — external location Unity Catalogu namapovaná na OneLake cestu, takže i managed tabulky UC mohou fyzicky ležet v OneLake. K polovině 2026 v Beta.

Direct Lake je třetí storage mode Power BI, dostupný jen na Fabric kapacitě (F SKU). Trik: VertiPaq engine načítá sloupce přímo z Delta/Parquet souborů v OneLake do paměti (tzv. transcoding) — až ve chvíli, kdy je dotaz potřebuje. „Refresh" modelu je jen framing: aktualizace metadat na novou verzi Delta tabulky, operace na sekundy. Výsledek: dotazy rychlé jako Import, čerstvost dat blízká DirectQuery, bez kopírování celého datasetu.

Direct Lake existuje ve dvou variantách — a rozdíl je u Databricks scénářů důležitý:

U starší varianty „on SQL" je klíčové slovo fallback: když engine nemůže číst Delta soubory napřímo (zdroj je SQL view, na endpointu je definované RLS, tabulka přesahuje guardrails kapacity), dotaz se potichu přepne do DirectQuery — a report najednou běží 5× pomaleji, aniž by kdo cokoliv změnil. Fallback lze v nastavení modelu zakázat (Direct Lake behavior), pak místo zpomalení dostanete chybu — v produkci často lepší, protože problém uvidíte hned.

Guardrails závisí na SKU — orientačně: F64 zvládne na tabulku 1,5 mld. řádků, 5 000 Parquet souborů a 25 GB paměti modelu; menší SKU úměrně méně. Přesná čísla ověřte v dokumentaci. Prakticky to znamená: Delta tabulky pro Direct Lake udržujte kompaktní (OPTIMIZE, rozumný počet souborů a row groups) — V-Order optimalizace Parquetu čtení VertiPaqem dále zrychluje a Databricks ji při zápisu neprodukuje. Nespoléhejte se ale na to, že tabulky psané Fabricem ji mají — od jara 2025 je V-Order defaultně vypnutý i pro nově zakládané Fabric workspaces (dokumentace: „V-order is disabled by default for all newly created workspaces"), protože zdržuje zápis. Pro read-heavy tabulky pod Direct Lake si ho zapněte explicitně.

Pro naši integraci je podstatné: Direct Lake funguje i nad mirrorovanými Databricks tabulkami (15.4) a nad shortcuty (15.6). Kombinace „Databricks píše gold → mirroring → Direct Lake" je k srpnu 2026 architektonicky nejčistší cesta k rychlému Power BI nad Databricks daty bez placení za SQL Warehouse při každém kliknutí.

Rozhodování v praxi dobře vystihuje jednoduchý strom: nejdřív otázka komu data dáváte, pak jestli máte Fabric kapacitu, a nakonec jak čerstvá a velká data potřebujete.

Kurátorované zdroje

• Mirroring Azure Databricks Unity Catalog (Learn) — koncept, metadata sync, výluky; GA.
• Tutorial: konfigurace mirroringu z Azure Databricks (Learn) — krokový postup.
• Direct Lake overview (Learn) — obě varianty, srovnání módů, guardrails podle SKU.
• Power BI with Azure Databricks (Learn) — konektor, Publish to Power BI, Power BI task, ADBC.
• Databricks Power BI cheat sheet — kondenzovaná výkonová doporučení.
• Integrate OneLake with Azure Databricks (Learn) — ABFS čtení/zápis, serverless varianta.
• OneLake shortcuts (Learn) — typy shortcuts včetně ADLS Gen2.
• Delta Sharing konektor pro Power BI (Learn) — připojení příjemce, row limit.
• Delta Sharing (Databricks docs) — open sharing vs D2D, správa recipientů.
• Co je nového ve Fabricu (Learn) — průběžný přehled novinek a změn stavu preview/GA; k oznámením typu OneLake catalog federation nebo UC managed tables v OneLake sledujte i Microsoft Fabric blog (blog.fabric.microsoft.com).