La capacity è l’unità di calcolo che rende utilizzabile tutto ciò che costruisci in Microsoft Fabric. Capire dove si “attacca” al modello di governance è metà del lavoro: l’altra metà è sapere quale impostazione toccare quando arriva il requisito.
La gerarchia: tenant → capacity → workspace → item
- Tenant: un solo tenant Microsoft Entra ID per organizzazione. Nel portale di amministrazione si configurano le tenant settings, che possono essere abilitate per tutti, per gruppi di sicurezza specifici, oppure delegate a livello di capacity o di domain (così un’unità di business può derogare senza aprire tutto il tenant).
- Capacity: risorsa Azure (F-SKU, da F2 a F2048) o capacity di trial (FT1). Vive in una region e ha uno o più capacity admin. È qui che si misurano le CU (Capacity Unit).
- Workspace: contenitore logico assegnato a una sola capacity. Il workspace eredita la region della capacity ed è il livello a cui si applicano ruoli (Admin, Member, Contributor, Viewer), Git integration e il domain.
- Item: lakehouse, warehouse, semantic model, notebook, pipeline, report. Consuma le CU della capacity a cui è assegnato il workspace che lo contiene.
Assegnare o spostare un workspace: Workspace settings → License info → License mode, scegliendo Fabric capacity e la capacity di destinazione; in alternativa dal portale admin (Capacity settings → Workspaces) per riassegnazioni massive. Serve essere admin del workspace e avere permessi sulla capacity di destinazione. Attenzione ai cambi di region: dati OneLake e capacity dovrebbero stare nella stessa area, altrimenti si introduce latenza e possibili blocchi di compliance.
Cosa cambia in base alla licenza
| Requisito | Serve |
|---|---|
| Item Fabric non‑Power BI (lakehouse, warehouse, notebook, pipeline) | Workspace su capacity Fabric (F o trial) |
| Direct Lake su semantic model | Capacity Fabric — non disponibile in workspace Pro/PPU |
| Distribuire contenuti a utenti Free | Capacity F64 o superiore |
| Distribuire da capacity < F64 | Ogni consumer ha bisogno di licenza Pro (o PPU) |
| Creare/pubblicare contenuti Power BI | Licenza Pro/PPU per l’autore, sempre |
La licenza per utente e la capacity sono assi indipendenti: la capacity fornisce il calcolo, la licenza per utente fornisce il diritto di accesso.
Smoothing, bursting, throttling
Fabric non blocca al primo picco. Il bursting consente a un’operazione di usare più CU di quelle nominali per finire prima; lo smoothing spalma poi il consumo nel tempo: circa 5 minuti per le operazioni interattive, fino a 24 ore per quelle background (refresh, job Spark, pipeline). Solo quando il debito accumulato supera le soglie scatta il throttling, in stadi progressivi: prima un ritardo sulle richieste interattive, poi il rifiuto delle interattive, infine il rifiuto anche dei job background.
Regola decisionale d’esame:
- Il carico è costantemente oltre il 100% e lo smoothing non riassorbe → aumenta lo SKU (scale up).
- Il carico complessivo sta nei limiti ma un team “rumoroso” (Spark, refresh massivi) fa throttlare i report di tutti → isola quel workload su una capacity dedicata, spostandoci i suoi workspace.
- Serve visibilità: Microsoft Fabric Capacity Metrics app per identificare item, operazione e timepoint responsabili del sovraccarico.
Ricorda che mettere in pausa una capacity rende inaccessibili gli item dei workspace assegnati e fattura immediatamente il consumo residuo non ancora smoothato.
Workspace settings che contano
- OneLake: opzione per consentire (o negare) l’accesso ai dati OneLake da app esterne a Fabric; i OneLake data access roles aggiungono sicurezza a livello di cartella nel lakehouse.
- Spark settings: starter pool vs custom pool (famiglia di nodi, dimensione, autoscale, dynamic executor allocation), environment predefinito con librerie e configurazioni, high concurrency. Un custom pool troppo grande brucia CU e provoca throttling.
- Default storage format dei semantic model: Large semantic model storage format è necessario per modelli oltre i limiti dello small format e per scenari Direct Lake su modelli estesi.
- Azure Data Lake Storage Gen2: connessione a livello di workspace per l’output dei dataflow.
- Domain: associa il workspace a un dominio Microsoft Purview/Fabric per governance e delega delle tenant settings.
Trappole tipiche d’esame
- Scenario: un report Direct Lake funziona in sviluppo ma fallisce dopo la migrazione in un workspace Pro. → Risposta giusta: riassegnare il workspace a una capacity Fabric; Direct Lake richiede capacity, non basta Pro.
- Scenario: 800 utenti con licenza Free devono solo visualizzare i report, budget da minimizzare. → Risposta giusta: ospitare il workspace su una capacity F64 o superiore, non comprare 800 licenze Pro.
- Scenario: un unico job Spark notturno fa throttlare i report interattivi del mattino, ma l’utilizzo medio giornaliero è al 40%. → Risposta giusta: spostare il workspace di data engineering su una capacity separata, non aumentare lo SKU.
- Scenario: la capacity supera il 100% ogni giorno lavorativo per tutta la giornata. → Risposta giusta: scale up dello SKU (o ottimizzazione dei carichi); lo smoothing non risolve un sovraccarico strutturale.
- Scenario: bisogna consentire l’accesso ai dati del lakehouse a un tool esterno (Azure Databricks) via ADLS API. → Risposta giusta: abilitare l’accesso OneLake da app esterne nelle workspace/tenant settings e assegnare i permessi, non copiare i dati.
- Scenario: serve identificare quale item ha causato il throttling di ieri alle 14:00. → Risposta giusta: Fabric Capacity Metrics app, non il monitoring hub del singolo workspace.