CU Costs a Capacity Metrics
Cíle kapitoly
- Vysvětlit, co je Capacity Unit a jak F-SKU, smoothing a throttling fungují
- Číst Fabric Capacity Metrics app a počítat s její latencí při demu
- Porovnat CU spotřebu tří ingestních cest a zvolit tu správnou pro daný scénář
- Odhadnout, kdy F2 stačí a kdy ne, a znát základní tipy na optimalizaci nákladů
Úvod
Praktická reference o tom, jak se v Microsoft Fabric platí za kapacitu, jak měřit CU spotřebu a kdy která ingest metoda dává smysl. Postaveno tak, aby šlo přímo použít při výuce DP-600 a aby účastníci pochopili proč nestačí Fabric trial pro produkci.
TL;DR:
- Fabric kapacita F-SKU = předplacená rezerva CU (Capacity Units)
- Nejlevnější placená F2 = ~250 USD/měsíc, 2 CU base s burstable
- Fabric Capacity Metrics app (free) je hlavní pohled na reálnou spotřebu
- Pipeline Copy Activity je obvykle nejlevnější ingest, Spark notebook nejdražší (kvůli startup overheadu)
- Throttling kicks in při překročení dostupných CU per 30s window
Co je Capacity Unit (CU)
Fabric kapacita je rezerva výpočetního výkonu, která se měří v Capacity Units. Běh každé operace (notebook, dataflow, query, semantic model refresh) konzumuje CU-seconds (CU × seconds běhu).
| F-SKU | Base CU | Equivalent Power BI | Typická cena (USD/měsíc, PAYG) |
|---|---|---|---|
| F2 | 2 | – | ~263 |
| F4 | 4 | – | ~526 |
| F8 | 8 | – | ~1052 |
| F16 | 16 | – | ~2103 |
| F32 | 32 | – | ~4206 |
| F64 | 64 | P1 ekvivalent | ~8410 |
| F128 | 128 | P2 ekvivalent | ~16800 |
| F256 | 256 | P3 ekvivalent | ~33700 |
| F512 | 512 | – | ~67500 |
Reservation (1 rok prepay) dává ~40% slevu. Trial je zdarma, ale jen 60 dní a omezené capacity (F64 ekvivalent, ale shared).
Burstable a Smoothing
Klíčový koncept: Fabric vyhlazuje spotřebu přes 24 h. Když máš F2 (2 CU = 172 800 CU-seconds/den) a notebook spálí 10 000 CU-seconds, není to "okamžitý překryv" — distribuuje se do hodin/dnů, jak málo zatížíš jindy.
Burstable = kapacita umožní krátkodobě překročit base. Burst faktor závisí na workloadu — Spark typicky ~3×, Warehouse dotazy až násobně víc; přesné limity ověřte v dokumentaci.
Smoothing = uhlazení spotřeby přes čas. Velký Spark job nedělá throttling instantně, dokud akumulovaný overhead nepřesáhne limit.
Throttling přijde, když v 30sec okně překročíš dostupné CU. Fabric to nedělá hard kill, ale delay subsequent operations (nové operace čekají) až po rejection (operace odmítnuty).
| Throttling stage | Co se děje | Kdy |
|---|---|---|
| Smoothing | Distribuce přes čas | Vždy aktivní |
| Interactive Delay | Interactive operace (queries, report views) zpomaleny | >10 min přetížení |
| Interactive Rejection | Interactive operace odmítány | >60 min přetížení |
| Background Rejection | Pipelines, refreshes odmítány | >24 h přetížení |
Fabric Capacity Metrics app
Co to je
Free Power BI app dostupný ze AppSource. Ukazuje real-time pohled na spotřebu CU per workspace, per item, per operation type.
Install: workspace admin → AppSource → search "Microsoft Fabric Capacity Metrics" → Install → connect to capacity ID.
Co umí
- Multi-metric ribbon chart — spotřeba per workspace v čase
- Timepoint Detail — drill na konkrétní 30s okno, kdo co dělal
- Throttling indicator — kdy nastal background reject / interactive reject
- Items breakdown — který notebook, dataflow, semantic model spotřeboval co
- Operations breakdown — query (ad-hoc, scheduled), refresh, OneLake compute
Latence dat
Kritické pro demo: Capacity Metrics má zpoždění zhruba 10–15 minut bez ohledu na SKU. Live demo „spustím a hned uvidím“ nefunguje.
Pro DP-600 demo strategie: spustit klíčové operace 24 h před kurzem, screenshot Capacity Metrics, ukázat ze screenshot. Live demo Capacity Metrics nemá smysl — data dorazí se zpožděním.
Srovnání CU spotřeby — 3 ingestní cesty
Empirické řády velikosti pro stejný úkol (load 470 K řádků, 5 CSVs, total ~50 MB) na F2:
| Cesta | CU-seconds (cold start) | CU-seconds (steady state) | Wall clock | Komentář |
|---|---|---|---|---|
| Notebook PySpark | 800–1500 | 200–400 | 2–4 min | Spark cold start dominuje |
| Notebook Pure Python (Polars) | 30–80 | 30–80 | 15–30 s | Žádný cluster overhead |
| Dataflow Gen2 | 200–500 | 100–250 | 1–2 min | Mezi tím — dedicated PQ engine |
| Pipeline Copy Activity | 50–150 | 50–150 | 30–60 s | Nejnižší overhead, optimalized I/O |
| Pipeline + Notebook activity | 850–1550 | 250–450 | 2–5 min | = Pipeline overhead + Spark |
Důsledek:
- Pro single-source CSV → Lakehouse je Pipeline Copy nejlevnější
- Pro transformační logiku (joiny, agregace, derived columns) je Pure Python nejlevnější u malých dat, Spark u velkých
- Dataflow Gen2 je premium za UI komfort — vyplatí se hlavně když to píše analytik bez kódu
Když se kdy vyplatí
| Scenario | Doporučení |
|---|---|
| Daily ingest 1 GB CSV → Lakehouse | Pipeline Copy Activity |
| Daily ETL s 20 transformacemi | Notebook (Spark nebo Python) |
| Týdenní replication 50 tabulek z SQL Serveru | Pipeline + ForEach |
| Self-service analytik chce upravit 5 sloupců | Dataflow Gen2 |
| Mirror existing OneLake data bez kopie | OneLake Shortcut (CU = 0!) |
| Streamovaná data | Eventstream → KQL DB |
F2 vs F64 — co reálně vidíš v demu
Stejný úkol, dvě kapacity
Demo: Spark notebook, ingest 5 CSVs, transform, write Delta.
| Operace | F2 wall clock | F64 wall clock | F2 CU-s | F64 CU-s |
|---|---|---|---|---|
| Spark session create | 90–120 s | 30–60 s | ~200 | ~150 |
| Read 5 CSVs | 25–50 s | 8–15 s | ~100 | ~80 |
| GroupBy aggregate | 15–30 s | 4–10 s | ~60 | ~50 |
| Write Delta | 20–40 s | 10–20 s | ~80 | ~70 |
| Total | ~3 min | ~70 s | ~440 | ~350 |
Klíčový insight:
- F64 je ~3× rychlejší end-to-end, ale CU spotřeba se liší jen mírně
- F2 ve skutečnosti CU "sní více" jen kvůli prodlouženému běhu, ale base price F2 je 32× nižší než F64
- Ekonomicky: F2 levnější celkově, F64 lepší user experience
Kdy F2 nestačí
- 10+ účastníků dělá současně reportíky → F2 throttling do hodiny
- Spark notebook >5 GB dat → F2 OOM nebo horror timing
- Multi-region nebo enterprise governance → Premium-class features od F64
Kdy F2 stačí
- Dev/test workspace
- Personal sandbox pro analytika
- 1–3 person team s malými daty
- Demo prostředí
Spark startup spike — proč to není problém
Účastníci se diví, že Spark notebook na F2 trvá 2–3 min. Zde je dobrá zpráva kterou jim řekni:
"Spark spike v Capacity Metrics neukazuje překročení limitu. Smoothing engine to rozprostře přes hodiny. Když F2 base je 172 800 CU-s/den a celý notebook spotřebuje 1 500 CU-s, je to <1% denní rezervy. Throttling kicks in jen pokud byste startovali 100 takových sessions denně."
Doporučení pro reálnou produkci
(Diskusní bod pro Day 4 — administrace.)
Decision tree pro velikost
Otázka 1: Kolik koncových uživatelů s reportem? ├─ <20 → F2 nebo F4 ├─ 20–100 → F8 nebo F16 ├─ 100–500 → F32 nebo F64 (= P1) └─ 500+ → F128+ (= P2/P3) Otázka 2: Kolik dat (Lakehouse + DW celkem)? ├─ <10 GB → F2 OK ├─ 10–100 GB → F4–F8 ├─ 100 GB–1 TB → F16–F32 └─ 1+ TB → F64+ Otázka 3: Real-time / streaming? ├─ Ne → vyber dle 1+2 └─ Ano → minimálně F8 (Eventstream + KQL spotřeba)
Cost optimization tipy
- Pause kapacitu přes UI / API mimo pracovní dobu — neúčtuje se. F2 puštěná jen 8h/den ve workdays = 1/3 ceny.
- OneLake Shortcuts místo kopií dat = 0 CU navíc (jen storage).
- V-Order na Delta tabulkách → menší file scan, méně CU per query.
- Direct Lake místo Import → eliminuje refresh CU.
- Sledovat Capacity Metrics weekly — nejdražší items jsou často semantic models s ne-V-Ordered tabulkami.
Co říct účastníkům jako "main takeaways"
- CU spotřeba je nepředvídatelná u Spark (cold start, executor scaling). Pure Python predictable.
- Capacity Metrics má delay, nedělej rozhodnutí real-time.
- F2 ne pro produkci. F2 pro dev / test / lab.
- Pipeline Copy Activity je obvykle nejlevnější ingest. Notebook když potřebuješ logiku.
- Throttling přichází postupně — Smoothing → Delay → Reject. Máš čas reagovat, ne náraz.
- Reservation 1 rok = ~40% sleva. Pokud je workload stabilní, počítat.
- Pause kapacitu = okamžitá úspora. Většina týmů zapomíná.
Reference
- Capacity Metrics docs: https://learn.microsoft.com/fabric/enterprise/metrics-app
- Throttling logic: https://learn.microsoft.com/fabric/enterprise/throttling
- F-SKU pricing: https://azure.microsoft.com/pricing/details/microsoft-fabric/
- Smoothing explained: Smoothing (v článku o throttlingu)
- V-Order details: https://learn.microsoft.com/fabric/data-engineering/delta-optimization-and-v-order