MOC — dny 1 a 2
1. Představení Azure Databricks 2. Výběr a konfigurace compute 3. Objekty v Unity Catalogu 4. Zabezpečení Unity Catalogu 5. Governance Unity Catalogu 6. Datové modelování 7. Ingest dat
MOC — pokračování
8. Čištění a transformace dat 9. Data quality constraints · mimo osnovu 10. Datové pipelines 11. Lakeflow Jobs 12. Vývojový lifecycle · mimo osnovu 13. Monitoring a optimalizace
🏠 Rozcestník kurzu
Pod čarou — den 3
14. Průřez Microsoft Fabric 15. Power BI + Fabric + Databricks 16. Migrace z Oracle
🏠 Rozcestník kurzu
DP-750 · Kapitola 14

Průřez Microsoft Fabric

Základní pojmy, architektura SaaS, OneLake, workloady a odlišnosti od Azure Databricks
🗂 Pod čarou — mimo MOC➕ Vlastní modul mimo oficiální MOC

Cíle kapitoly

  • Popsat, co je Microsoft Fabric a jak se liší jeho SaaS model od PaaS modelu Azure Databricks
  • Vysvětlit model kapacity (F-SKU, Capacity Units) včetně smoothingu a throttlingu
  • Vysvětlit roli OneLake a shortcuts — a jak se z Fabricu dostat k datům v Databricks (a naopak)
  • Zmapovat pojmy Fabricu na pojmy Databricks, které už znáte z kapitol 1–13
  • Rozhodnout, kdy dává smysl Fabric, kdy Databricks a kdy jejich kombinace
14.1

Co je Microsoft Fabric

Microsoft Fabric je analytická platforma dodávaná jako SaaS — jedna služba, která pokrývá celý datový životní cyklus: ingest, transformace, warehouse, streaming, data science i reporting. Nekupujete a nespravujete jednotlivé Azure resources (storage account, Spark cluster, SQL pool) — kupujete jednu capacity a v ní dostanete všechno. Žádné resource groups, žádný ARM, žádné VNETy. Dokonce nepotřebujete ani Azure subscription pro práci — jen pro platbu kapacity.

Pro vás jako Databricks inženýry je nejrychlejší mentální model tento: Fabric je to, co vznikne, když vezmete Power BI service a přistavíte k němu lakehouse, warehouse, pipelines, Spark a streaming — všechno nad jedním sdíleným úložištěm. Fabric totiž skutečně vyrostl z Power BI: portál, workspaces, sdílení, tenant administrace — to vše je evoluce Power BI service, ne nový produkt postavený na zelené louce.

ℹ️
Poznámka: Kdo čeká, že Fabric je „Microsoft verze Databricks", bude zmatený. Fabric je primárně konsolidace — Power BI + Synapse + Data Factory + Azure Data Explorer sbalené do jednoho SaaS balíku. Databricks je engine-first platforma; Fabric je integration-first platforma. Z toho plyne většina rozdílů v této kapitole.

Architektura má tři vrstvy: dole OneLake (jeden logický data lake pro celý tenant), uprostřed platformní služby (governance přes Purview, Copilot, security), nahoře workloady — jednotlivé „zkušenosti" pro různé role. Všechno běží z jedné předplacené kapacity:

Capacity (F-SKU, např. F64) sdílený fond Capacity Units pro vše níže Workspace „Prodej" Lakehouse Notebook (Spark) Pipeline Power BI report items = vše, co ve workspace vytvoříte Workspace „Finance" Warehouse Semantic model Eventhouse (KQL) Dataflow Gen2 OneLake — jeden logický data lake pro celý tenant postaveno na ADLS Gen2, tabulky ve formátu Delta Parquet
Základní stavebnice Fabricu: capacity platí za výpočty, workspaces organizují items, OneLake drží všechna data v Delta formátu.

Klíčová slova, se kterými budeme celou kapitolu pracovat: tenant (jedna organizace, jeden OneLake), capacity (předplacený výpočetní výkon), workspace (kontejner na práci, přiřazený ke kapacitě) a item (cokoli, co ve workspace vytvoříte — lakehouse, notebook, report…).

14.2

Capacity a Capacity Units — jak se ve Fabricu platí

V Databricks platíte DBU za konkrétní běžící compute — cluster, SQL warehouse, serverless job. Když nic neběží, neplatíte (kromě storage). Fabric to má obráceně: kupujete capacity v F-SKU velikostech (F2 až F8192) a ta představuje sdílený fond Capacity Units (CU), ze kterého čerpají všechny operace všech workloadů — notebook, pipeline, SQL dotaz, refresh reportu. Kapacita běží (a účtuje se) nepřetržitě, dokud ji nepozastavíte.

F-SKUCUOrientační cena (PAYG)Poznámka
F22~260 USD/měsícdev/test, sandbox — ne produkce
F88~1 050 USD/měsícmalý tým, menší data
F6464~8 400 USD/měsícekvivalent bývalého Power BI Premium P1
F128–F8192128–8192lineárně výšenterprise, násobky P2/P3 a výš

Ceny berte jako řádové — stav k srpnu 2026, přesné částky ověřte v ceníku Azure. Roční reservation dává zhruba 40% slevu. Důležitá licenční hranice: od F64 výš mohou uživatelé s Free licencí konzumovat Power BI obsah; pod F64 potřebuje každý čtenář reportu Power BI Pro licenci.

Smoothing a throttling

Jak může F2 se 2 CU utáhnout Spark job, který v peaku potřebuje mnohem víc? Přes dva mechanismy. Bursting dovolí operaci krátkodobě přesáhnout base výkon kapacity. Smoothing pak spotřebu účetně rozprostře do delšího okna (u background operací 24 hodin) — špička se „splácí" z klidnějších hodin. Teprve když kumulovaný dluh přeroste možnosti kapacity, nastupuje throttling — a to postupně, ne skokově:

Objem vypůjčené budoucí kapacity (v minutách spotřeby) → Overage protection vše běží normálně, dluh se rozprostírá ≤ 10 min Interactive Delay dotazy a reporty čekají 20 s při submitu > 10 min Interactive Rejection interaktivní operace jsou odmítány > 60 min Background Rejection i pipelines a refreshe jsou odmítány > 24 h Throttling přichází postupně — je čas reagovat (scale-up, pauza jobů), ne náraz do zdi.
Fáze throttlingu podle objemu nasčítaného CU dluhu, vyjádřeného v minutách budoucí spotřeby kapacity: nejdřív overage protection, pak zpoždění interaktivních operací o 20 s, jejich odmítání a nakonec odmítání všeho.
ℹ️
Poznámka k prahům: hodnoty na ose nejsou doba, po kterou je kapacita přetížená, ale objem už vypůjčené budoucí kapacity — kolik minut své vlastní budoucí spotřeby capacity utratila dopředu. Jediný nenažraný job proto může kapacitu poslat do Interactive rejection během pár minut. Dokumentace ten sloupec nazývá jednoduše Usage.
⚠️
Pozor: mentální past pro Databricks inženýry — throttling ve Fabricu je capacity-wide. Jeden nenažraný Spark notebook může zpomalit reporty finančnímu řediteli, protože všichni čerpají ze stejného fondu CU. V Databricks je exploze nákladů izolovaná na cluster/warehouse, tady je izolace jen přes oddělené kapacity.
💡
Tip: kapacitu lze pozastavit (UI nebo API) a po dobu pauzy se neúčtuje. Dev kapacita běžící jen v pracovní době stojí zlomek ceny. Hlavní a nejrychleji dostupný nástroj na monitoring spotřeby je free Fabric Capacity Metrics app (podrobněji jde jít přes workspace monitoring nebo Azure Monitor) — počítejte s latencí dat v řádu jednotek až desítek minut.
Jak se počítá spotřeba: CU-seconds a proč je Spark „drahý"▼

Každá operace spálí CU × sekundy běhu. F2 má denní rozpočet 2 × 86 400 = 172 800 CU-seconds. Z měření na kurzech DP-600: stejný ingest ~50 MB CSV stojí řádově 50–150 CU-s přes Pipeline Copy, 200–500 CU-s přes Dataflow Gen2, ale 800–1 500 CU-s přes PySpark notebook — cold start Spark session dominuje. Pro malá data je ve Fabricu často levnější „pure Python" notebook (Polars/DuckDB, bez Spark clusteru) — koncept, který v Databricks nemá přímou obdobu. Řády se mění s verzemi runtime, berte jako ilustraci.

14.3

OneLake — jeden logický lake a shortcuts

OneLake je automaticky přítomné úložiště každého Fabric tenantu — postavené na ADLS Gen2, ale plně spravované: žádné storage accounty, žádné kontejnery k zakládání. Dokumentace: „Every Microsoft Fabric tenant automatically includes OneLake… You can't delete OneLake or create multiple OneLakes." Analogie, která na kurzech funguje: OneLake je „OneDrive pro data" — jeden namespace pro celou organizaci, workspaces jsou v něm složky.

Podstatné pro vás: tabulky v OneLake jsou Delta Parquet — stejný formát, jaký používáte v Databricks. Všechny Fabric enginy (Spark, T-SQL warehouse, KQL, Analysis Services pro Power BI) čtou a zapisují tutéž kopii dat; Power BI umí přes Direct Lake mode číst Delta soubory přímo, bez importu do vlastního úložiště. OneLake navíc podporuje interoperabilitu s Apache Iceberg přes virtualizaci metadat a je přístupný přes standardní ADLS Gen2 API — takže se k němu dostanete i z Databricks.

Shortcuts — zero-copy přístup k cizím datům

Shortcut je reference na data ležící jinde — v jiném workspace, v ADLS Gen2, Amazon S3, Google Cloud Storage, Dataverse i v S3-kompatibilních úložištích. Data se nekopírují; ve stromě lakehouse se tváří jako lokální tabulka či složka. Vedle shortcuts existuje Mirroring — kontinuální replikace databází (Azure SQL, Cosmos DB, Snowflake, a také Azure Databricks Unity Catalog) do OneLake v Delta formátu.

ADLS Gen2 existující Azure data lake Amazon S3 bucket v AWS Azure Databricks Delta tabulky pod Unity Catalog OneLake · Lakehouse „Analytika" Tables/orders (lokální Delta) Files/raw_archiv ⤳ shortcut ADLS Files/clickstream ⤳ shortcut S3 Tables/gold_sales ⤳ mirroring z UC vše čitelné každým Fabric enginem vč. Direct Lake zero-copy opačný směr: Databricks čte OneLake přes ADLS Gen2 API (abfss://)
Shortcuts a mirroring dělají z OneLake virtuální vrstvu nad více úložišti — včetně Delta tabulek spravovaných Databricks Unity Catalogem.

Integrace funguje i obráceně — OneLake se z Databricks chová jako běžný ADLS Gen2 endpoint:

PYTHON
# Databricks notebook: cteni Delta tabulky ulozene ve Fabric OneLake
# format: abfss://<workspace>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/
# workspace se chova jako kontejner, lakehouse jako slozka
df = spark.read.format("delta").load(
    "abfss://Prodej@onelake.dfs.fabric.microsoft.com/Analytika.lakehouse/Tables/orders"
)
display(df.limit(10))
💡
Tip: shortcut je nejlevnější „ingest" ve Fabricu — nespotřebuje žádné CU za kopírování, platíte jen dotazy nad daty. Pokud už máte medallion vrstvy v ADLS Gen2 spravované Databricks, shortcut na gold vrstvu je typicky první a nejrychlejší krok integrace s Fabricem.
⚠️
Pozor: shortcut obchází governance zdroje jen zdánlivě — přístup se vyhodnocuje přes credentials uložené u shortcutu. Kdo má přístup k lakehouse, vidí data shortcutu bez ohledu na to, co říká Unity Catalog na straně Databricks. Přesné chování security modelu (OneLake security, propagace oprávnění) se stále vyvíjí — stav k srpnu 2026 ověřte v dokumentaci.
14.4

Workloady a items — co v krabici najdete

Fabric organizuje funkce do workloadů („experiences") — sad nástrojů pro určitou roli. Každý workload produkuje items ve workspace. Přehled toho podstatného (stav k srpnu 2026 — seznam se rozšiřuje, ověřte v dokumentaci):

WorkloadKlíčové itemsDatabricks paralela
Data EngineeringLakehouse, Notebook, Spark Job Definition, Environmentnotebooky + clusters + Delta
Data FactoryPipeline, Dataflow Gen2, Copy jobLakeflow Jobs / ADF
Data WarehouseWarehouse (plný T-SQL vč. DML)Databricks SQL warehouse
Real-Time IntelligenceEventstream, Eventhouse (KQL DB), ActivatorStructured Streaming + alerting
Data ScienceML Model, Experiment (MLflow uvnitř)MLflow, Mosaic AI
Power BISemantic model, Report, DashboardAI/BI Dashboards (mnohem slabší)
DatabasesSQL database, Mirrored databaseLakebase / mirroring zdrojů
Fabric IQOntology, data agent, Fabric Graph (preview)Genie / agentní vrstva

Dvě věci, které Databricks inženýra překvapí. Zaprvé lakehouse má dva endpointy: Spark vidí Tables i Files, a automaticky vzniklý SQL analytics endpoint nabízí T-SQL čtení týchž Delta tabulek — ale read-only. Kdo chce plný T-SQL s INSERT/UPDATE, potřebuje item Warehouse. Zadruhé nad každým lakehousem i warehousem automaticky vzniká default semantic model pro Power BI — dobrý na prototyp, na produkci se staví explicitní model.

Enginy se liší, data ne — takže T-SQL umí spojit items v rámci jednoho workspace obyčejným three-part naming:

SQL
-- Fabric warehouse: join pres lakehouse a warehouse v jednom workspace
SELECT o.order_id, o.amount_eur * fx.rate AS amount_czk
FROM lakehouse_prodej.dbo.orders AS o
JOIN warehouse_finance.dbo.fx_rates AS fx
  ON o.currency = fx.currency;
⚠️
Pozor: cross-database dotazy fungují jen v rámci aktuálního workspace — dokumentace to říká výslovně: „You can write cross database queries to warehouses and databases in the current active workspace." Přes hranici workspace three-part naming nefunguje; cílovou tabulku si nejdřív zpřístupněte shortcutem do lakehouse ve svém workspace.
ℹ️
Poznámka: Fabric přidává workloady tempem několika za rok (naposledy Databases a Fabric IQ, ten je k srpnu 2026 v preview). Na certifikaci ani v architektuře se nespoléhejte na zapamatovaný seznam — ověřte aktuální stav v dokumentaci.
14.5

Mapování pojmů: Fabric ↔ Azure Databricks

Nejrychlejší cesta, jak se ve Fabricu zorientovat, je přeložit si jeho pojmy do těch, které znáte z kapitol 1–13. Pozor — některá slova (workspace, lakehouse) existují v obou světech, ale znamenají něco jiného:

KonceptMicrosoft FabricAzure Databricks
Nejvyšší jednotkatenant (1 na organizaci)account (+ metastore per region)
Workspacesložka items, přiřazená ke capacitysamostatný Azure resource s vlastním compute
ÚložištěOneLake — spravované, jedno pro tenantváš ADLS Gen2 / S3 — plná kontrola
Lakehousekonkrétní item (Tables + Files)architektonický vzor (Delta + Unity Catalog)
Formát tabulekDelta Parquet (+ Iceberg virtualizace)Delta Lake (+ Iceberg přes UniForm)
Notebook + SparkFabric notebook, starter pools z CUnotebook, clusters/serverless za DBU
SQL vrstvaWarehouse / SQL analytics endpointDatabricks SQL warehouse
OrchestraceData Factory pipelinesLakeflow Jobs
StreamingEventstream + Eventhouse (KQL)Structured Streaming, Lakeflow Spark Declarative Pipelines
Katalog & governanceOneLake catalog + PurviewUnity Catalog
BIPower BI (nativní součást)AI/BI Dashboards, konektor na Power BI
Jednotka útratyCU (kapacita běží pořád)DBU (platí se běžící compute)
ℹ️
Poznámka: největší falešný přítel je lakehouse. V Databricks je to filozofie celé platformy; ve Fabricu je to jeden konkrétní typ itemu — v podstatě „spravovaná složka" s Tables a Files. Druhý je workspace: ve Fabricu je to lehká složka (klidně desítky na tenant), v Databricks těžký resource s vlastní správou.
Časté omyly při prvním kontaktu s Fabricem▼

„SQL analytics endpoint je warehouse." Není — je read-only. SQL vývojáři se pravidelně diví, proč nejde UPDATE; zápis do lakehouse tabulek patří Sparku (Delta immutability + zápis přes engine), plný T-SQL DML má jen item Warehouse.

„Purview = Unity Catalog." Jen zhruba. Unity Catalog je jeden konzistentní model oprávnění vynucovaný enginem (GRANT na katalog/schéma/tabulku, lineage, audit). Ve Fabricu se governance skládá z více vrstev: workspace role, item permissions, OneLake security a nad tím Purview pro labels, katalogizaci a compliance. Silnější na compliance a M365 integraci, roztříštěnější na data-level ACL.

„Direct Lake = Import mode bez refreshů zadarmo." Direct Lake čte Delta soubory přímo do paměti Analysis Services (tzv. framing, bez kopie), ale při nevhodných datech (velká kardinalita, mnoho malých souborů, DAX nad nepodporovanou konstrukcí) padá do DirectQuery fallbacku. V-Order optimalizace Parquetu tomu výrazně pomáhá.

14.6

Zásadní odlišnosti — kde se světy rozcházejí

SaaS vs. PaaS. Fabric vám bere infrastrukturní rozhodnutí z rukou: žádné volby instance typů, runtime verzí per cluster, VNET injection, spot instancí. To je úleva pro týmy bez platformních inženýrů — a frustrace pro ty, kdo jsou zvyklí compute ladit. V Databricks si vyberete node type, autoscaling, Photon; ve Fabricu dostanete „nějaký" Spark ze starter poolu a hlavní páka je velikost kapacity.

Billing model. Databricks = platíte, když něco běží; náklady rostou s workloadem a dají se přičíst konkrétnímu jobu. Fabric = platíte kapacitu nepřetržitě; náklady jsou předvídatelné (fixní měsíční částka), ale sdílené — a když se do kapacity nevejdete, řešíte throttling nebo scale-up celé kapacity. FinOps disciplína se přesouvá z „vypínej clustery" na „hlídej Capacity Metrics a izoluj hlučné workloady do vlastních kapacit".

Governance. Unity Catalog je jednotný, engine-vynucovaný model. Fabric má vrstvený model (workspace role → item permissions → OneLake security) plus vestavěný Purview pro sensitivity labels, katalog a audit — silná integrace na Microsoft 365 a compliance procesy, ale více míst, kde se oprávnění definují.

Otevřenost. Obě platformy stojí na Delta/Parquet a obě dnes mluví i Iceberg (Fabric přes metadata virtualizaci, Databricks přes UniForm) — data tedy nejsou zamčená ani v jednom světě. Rozdíl je v enginech a ekosystému: Databricks staví na open-source jádru (Spark, Delta, MLflow) a běží na třech cloudech; Fabric enginy (Warehouse, KQL, Analysis Services) jsou proprietární a platforma existuje jen jako Microsoft SaaS.

Microsoft FabricAzure Databricks
Model službySaaS — vše spravovanéPaaS — infrastrukturu ovlivňujete
Nákladyfixní kapacita, sdílený fondpay-per-use, per-workload
Ladění výkonuomezené (velikost SKU, V-Order)hluboké (cluster config, Photon, tuning)
Cílová personaBI tým, citizen developer, „vše v jednom"data engineering / ML tým, code-first
Multi-cloudne (Azure SaaS)Azure, AWS, GCP
BIPower BI nativně, Direct Lakepřes konektory / AI-BI Dashboards
⚠️
Pozor: srovnání „který je lepší" je špatná otázka — platformy míří na jiné těžiště. Fabric optimalizuje čas-do-reportu a šířku záběru pro celou organizaci; Databricks optimalizuje výkon, škálu a inženýrskou kontrolu. Proto je v praxi tak častá kombinace obou (viz další sekce).
14.7

Kdy Fabric, kdy Databricks, kdy kombinace

Rozhodnutí málokdy zní „všechno přepneme". Typické vodítko podle charakteru týmu a workloadu:

Co ve vaší organizaci převažuje? workloady · týmy · skills · cloud strategie BI & self-service obojí naplno engineering & ML Spíš Fabric • těžiště = Power BI a reporting • menší DE tým, low-code preference • Microsoft 365 / Azure-only • predikovatelný fixní rozpočet • jedna platforma pro vše stačí → capacity + OneLake, end-to-end Kombinace • DE/ML tým už jede na Databricks • byznys chce Power BI self-service • Databricks: bronze → silver → gold • shortcut / mirroring gold do OneLake • Power BI Direct Lake nad gold → nejčastější enterprise vzor 2026 Spíš Databricks • masivní ETL, streaming, ML/GenAI • code-first tým, CI/CD, IaC • potřeba ladit výkon a náklady • multi-cloud / exit strategie • jednotná governance (Unity Catalog) → BI přes konektor / export Sdílený jmenovatel: Delta/Parquet v otevřeném úložišti dobře navržený lake umožňuje rozhodnutí později změnit bez migrace dat
Rozhodovací vodítko: čistý Fabric pro BI-first organizace, čistý Databricks pro engineering-first týmy, kombinace jako nejčastější enterprise vzor.

Kombinovaný vzor stojí za rozvedení, protože se s ním potkáte nejčastěji: Databricks vlastní zpracování (ingest, kvalita, medallion až po gold, ML features), gold vrstva leží jako Delta v ADLS Gen2 nebo přímo v Unity Catalogu, a Fabric vlastní konzumaci — shortcut či mirroring zpřístupní gold v OneLake a Power BI nad ním jede v Direct Lake módu bez kopírování a bez refresh oken. Každý tým zůstává v nástroji, který umí.

💡
Tip: v kombinovaném scénáři si pohlídejte dvě věci: 1) V-Order — Parquet zapsaný z Databricks není V-Ordered. Pozor ale, že V-Order je dnes defaultně vypnutý i pro nově zakládané Fabric workspaces (spark.sql.parquet.vorder.default = false, kvůli výkonu zápisu), takže rozdíl proti Fabricu není automatický. Zapněte ho vědomě tam, kde nad tabulkou stojí Direct Lake a čte se z ní podstatně častěji, než se do ní zapisuje; 2) dvojí governance — dohodněte, že zdrojem pravdy pro přístupy ke gold vrstvě je jedna strana (typicky Unity Catalog), a Fabric přístup řešte na úrovni workspace/items.
A co cena kombinace? Nezaplatím dvakrát?▼

Částečně ano — platíte DBU za zpracování a k tomu Fabric kapacitu za servírování. Prakticky ale BI-only kapacita vychází relativně malá: shortcuts nestojí CU, Direct Lake eliminuje refresh náklady a interaktivní dotazy jsou smoothed. Rozhodující je licenční hranice F64 pro free čtenáře reportů — pod ní platíte Power BI Pro per user, což u stovek konzumentů převáží cenu kapacity. Spočítejte obě varianty; ceny a pravidla k srpnu 2026 ověřte v aktuálním ceníku.

14.8

Shrnutí a zdroje

✓
Shrnutí: Fabric je SaaS analytická platforma vyrostlá z Power BI: jedna capacity (F-SKU, sdílený fond CU se smoothingem a postupným throttlingem), jeden OneLake (Delta Parquet, shortcuts a mirroring pro zero-copy přístup — i do Databricks) a sada workloadů od Data Factory po Power BI. Proti Databricks stojí jinak: SaaS místo PaaS, fixní kapacita místo pay-per-use, vrstvená governance s Purview místo Unity Catalogu, integrace místo inženýrské kontroly. V praxi nejčastěji vítězí kombinace: Databricks zpracovává do gold, Fabric přes Direct Lake servíruje do Power BI — a díky společnému Delta formátu se obě strany potkávají nad jednou kopií dat.
ℹ️
Poznámka: Fabric se mění rychleji než cokoli, co jsme v kurzu probírali — workloady, preview funkce, SKU i licenční pravidla. Vše v této kapitole odpovídá stavu k srpnu 2026; než začnete architektonicky rozhodovat, projděte aktuální dokumentaci a release notes.

Kurátorované zdroje