Průřez Microsoft Fabric
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
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.
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:
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…).
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-SKU | CU | Orientační cena (PAYG) | Poznámka |
|---|---|---|---|
| F2 | 2 | ~260 USD/měsíc | dev/test, sandbox — ne produkce |
| F8 | 8 | ~1 050 USD/měsíc | malý tým, menší data |
| F64 | 64 | ~8 400 USD/měsíc | ekvivalent bývalého Power BI Premium P1 |
| F128–F8192 | 128–8192 | lineá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ě:
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.
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.
Integrace funguje i obráceně — OneLake se z Databricks chová jako běžný ADLS Gen2 endpoint:
# 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))
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):
| Workload | Klíčové items | Databricks paralela |
|---|---|---|
| Data Engineering | Lakehouse, Notebook, Spark Job Definition, Environment | notebooky + clusters + Delta |
| Data Factory | Pipeline, Dataflow Gen2, Copy job | Lakeflow Jobs / ADF |
| Data Warehouse | Warehouse (plný T-SQL vč. DML) | Databricks SQL warehouse |
| Real-Time Intelligence | Eventstream, Eventhouse (KQL DB), Activator | Structured Streaming + alerting |
| Data Science | ML Model, Experiment (MLflow uvnitř) | MLflow, Mosaic AI |
| Power BI | Semantic model, Report, Dashboard | AI/BI Dashboards (mnohem slabší) |
| Databases | SQL database, Mirrored database | Lakebase / mirroring zdrojů |
| Fabric IQ | Ontology, 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:
-- 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;
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:
| Koncept | Microsoft Fabric | Azure Databricks |
|---|---|---|
| Nejvyšší jednotka | tenant (1 na organizaci) | account (+ metastore per region) |
| Workspace | složka items, přiřazená ke capacity | samostatný Azure resource s vlastním compute |
| Úložiště | OneLake — spravované, jedno pro tenant | váš ADLS Gen2 / S3 — plná kontrola |
| Lakehouse | konkrétní item (Tables + Files) | architektonický vzor (Delta + Unity Catalog) |
| Formát tabulek | Delta Parquet (+ Iceberg virtualizace) | Delta Lake (+ Iceberg přes UniForm) |
| Notebook + Spark | Fabric notebook, starter pools z CU | notebook, clusters/serverless za DBU |
| SQL vrstva | Warehouse / SQL analytics endpoint | Databricks SQL warehouse |
| Orchestrace | Data Factory pipelines | Lakeflow Jobs |
| Streaming | Eventstream + Eventhouse (KQL) | Structured Streaming, Lakeflow Spark Declarative Pipelines |
| Katalog & governance | OneLake catalog + Purview | Unity Catalog |
| BI | Power BI (nativní součást) | AI/BI Dashboards, konektor na Power BI |
| Jednotka útraty | CU (kapacita běží pořád) | DBU (platí se běžící compute) |
„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á.
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 Fabric | Azure Databricks | |
|---|---|---|
| Model služby | SaaS — vše spravované | PaaS — infrastrukturu ovlivňujete |
| Náklady | fixní kapacita, sdílený fond | pay-per-use, per-workload |
| Ladění výkonu | omezené (velikost SKU, V-Order) | hluboké (cluster config, Photon, tuning) |
| Cílová persona | BI tým, citizen developer, „vše v jednom" | data engineering / ML tým, code-first |
| Multi-cloud | ne (Azure SaaS) | Azure, AWS, GCP |
| BI | Power BI nativně, Direct Lake | přes konektory / AI-BI Dashboards |
Kdy Fabric, kdy Databricks, kdy kombinace
Rozhodnutí málokdy zní „všechno přepneme". Typické vodítko podle charakteru týmu a workloadu:
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í.
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.Čá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.
Shrnutí a zdroje
Kurátorované zdroje
- What is Microsoft Fabric? — přehledová stránka platformy a workloadů
- OneLake overview — jeden logický lake, shortcuts, Iceberg interoperabilita
- Fabric licenses and capacity — F-SKU, CU, licenční pravidla (vč. hranice F64)
- Capacity throttling a Capacity Metrics app — smoothing, fáze throttlingu, monitoring spotřeby
- OneLake shortcuts a Mirroring overview — zero-copy integrace, vč. mirroringu Azure Databricks Unity Catalogu
- Kurz DP-600: Implementing Analytics Solutions Using Microsoft Fabric — navazující čtyřdenní kurz, pokud vás Fabric zaujal do hloubky
- Learn path: Get started with Microsoft Fabric — samoobslužné moduly s hands-on cvičeními zdarma