Microsoft Fabric Capacity Units spiegate: guida agli SKU F e al debito di carry forward

By Mirko Peters · 2026-10-29

Scopri come le capacity unit di Microsoft Fabric, gli SKU F, lo smoothing e il debito di carry forward incidono sugli amministratori di M365. Governa il calcolo cloud da subito.

Automatically translated with AI from the original post. Read the English original

Le capacity unit (CU) di Microsoft Fabric determinano la potenza di calcolo, i limiti di prestazioni e la fatturazione dell'intero tenant. A differenza delle tradizionali risorse di Azure, che sono isolate in gruppi di risorse, Fabric raggruppa tutti i carichi di lavoro di data engineering, data warehousing e reporting in un unico pool di calcolo condiviso, regolato da SKU F, limiti di burst e regole del debito di carry forward.

Punti chiave

• Le capacity unit di Fabric misurano il lavoro di calcolo al secondo in tutti i workspace e funzionano come un pool condiviso per la fatturazione e le prestazioni.
• Gli SKU F (da F2 alle capacità di fascia alta) sostituiscono le capacità legacy di Power BI Premium e possono essere sospesi in Azure in modo flessibile per ridurre i costi.
• Il burst consente una sovrallocazione temporanea del calcolo, ma genera un debito di carry forward che va ripagato nel tempo.
• I processi in background usano una finestra di smoothing di 24 ore, mentre le query interattive degli utenti vengono distribuite su pochi minuti.
• L'app delle metriche di capacità di Fabric è essenziale per monitorare l'utilizzo, identificare i principali consumatori di risorse e impostare avvisi proattivi.

Che cos'è una capacità di Microsoft Fabric?

Quando Microsoft Fabric compare nel tuo tenant di Microsoft 365, non arriva come un insieme di macchine virtuali isolate o di sottoscrizioni Azure separate. Introduce invece un pool di calcolo unificato, chiamato capacità. Misurato in capacity unit (CU), questo pool alimenta ogni fase del ciclo di vita della tua piattaforma dati: acquisizione di eventi, ragionamento e orchestrazione.

Per gli amministratori di M365 e della piattaforma, capire questo modello è fondamentale. Più workspace, spesso appartenenti a reparti diversi, attingono allo stesso identico pool di capacità. Se un team di data engineering dell'area finanza avvia un notebook particolarmente intensivo, quel processo consuma unità di calcolo che altrimenti potrebbero supportare una dashboard del marketing. La capacità funziona come una risorsa condivisa, con un raggio d'impatto per cui un job pesante in un workspace incide direttamente sulle prestazioni di unità di business non correlate.

Orientarsi tra SKU F, SKU P e trial

Scegliere il livello di capacità giusto significa orientarsi tra tre famiglie di SKU distinte, ciascuna con implicazioni operative diverse per gli amministratori IT:

• SKU F (mainline): acquistati direttamente tramite Azure come F2, F4, F8 e superiori, questi SKU mainline consentono di pagare a ore oppure di impegnarsi con le prenotazioni. È importante notare che supportano le funzioni di sospensione e ripresa per ottimizzare la spesa nelle ore non lavorative.
• SKU P (legacy): rappresentano le capacità Power BI Premium meno recenti, che Microsoft non vende più. Se il tuo tenant ha ereditato uno SKU P, funziona all'interno di un percorso legacy che richiede un piano di migrazione pianificato.
• Capacità di trial: capacità gratuite di fascia alta (dimensionate indicativamente come un F64) che scadono dopo un periodo prestabilito. Poiché spesso qualsiasi utente idoneo può avviarne una, rappresentano un punto cieco amministrativo: pipeline business-critical possono dipendere involontariamente da una risorsa temporanea.

Come funzionano lo smoothing, il burst e il debito di carry forward

I carichi di lavoro di calcolo in Microsoft Fabric non si bloccano di colpo e in modo netto nel momento in cui superano il limite di capacità acquistato. La piattaforma si affida invece a due meccanismi sofisticati, chiamati bursting e smoothing, per gestire i picchi temporanei di calcolo.

Smoothing interattivo e in background

Quando un job pesante richiede molta potenza di calcolo per un breve periodo, Fabric consente al job di superare le dimensioni dello SKU acquistato. Per evitare un throttling immediato, la piattaforma applica nel tempo un algoritmo di smoothing:

• Operazioni interattive: le attività avviate dagli utenti, come l'apertura di un report o l'esecuzione di una query manuale, vengono distribuite su una finestra breve di pochi minuti per mantenere la reattività.
• Operazioni in background: i aggiornamenti pianificati dei dati, le esecuzioni automatiche delle pipeline e i notebook notturni vengono distribuiti su una finestra completa di 24 ore, riducendo notevolmente il loro impatto immediato sugli utenti che lavorano in tempo reale.

L'impatto del debito di carry forward

Il bursting non è gratuito. Quando un'operazione consuma più unità di quante ne fornisca la capacità, l'eccedenza viene registrata come debito di carry forward. Questo debito va saldato con i cicli di calcolo futuri. Di conseguenza, un job in background non ottimizzato eseguito di lunedì pomeriggio può accumulare debito che, il mercoledì mattina, rallenta i report interattivi, creando un misterioso calo di prestazioni che lascia perplessi gli utenti finali.

Monitoraggio e governance delle capacità

Poiché i sintomi (report lenti) e le cause (modelli di dati fuori controllo) sono spesso separati da tempo e confini tra aree di lavoro, gli amministratori devono affidarsi a strumenti dedicati per mantenere la visibilità. La app Microsoft Fabric Capacity Metrics, disponibile tramite AppSource, è il principale dashboard diagnostico.

Gli amministratori delle capacità possono usare questa app per esaminare le tendenze di utilizzo in tempo reale, monitorare l'accumulo del debito di carry forward e individuare gli elementi che consumano più risorse, come specifici modelli semantici, pipeline o notebook. Inoltre, impostare soglie di avviso intorno all'80% di utilizzo garantisce che i team IT ricevano notifiche prima che si verifichino throttling o errori visibili agli utenti, spostando l'approccio amministrativo dalla gestione reattiva dei problemi alla governance proattiva.

Conclusione

Gestire le capacità di Microsoft Fabric richiede il passaggio dal tradizionale isolamento dei carichi di lavoro a una governance complessiva della piattaforma. Tenendo sotto stretto controllo il dimensionamento degli SKU F, monitorando il debito di carry forward e verificando i maggiori consumatori di risorse tramite l'app delle metriche della capacità, gli amministratori IT possono mantenere prestazioni prevedibili e controllare efficacemente i costi cloud.

Per approfondire le responsabilità degli amministratori, le aree di lavoro e i confini di sicurezza del tenant, non perdere l'occasione di ascoltare l'episodio completo del podcast M365 FM per approfondimenti e strategie pratiche.

Domande frequenti

Che cos'è un'unità di capacità (CU) di Microsoft Fabric?

Un'unità di capacità è una misura aggregata della potenza di calcolo che alimenta tutti i carichi di lavoro di Microsoft Fabric, inclusi l'acquisizione di eventi, il ragionamento e l'orchestrazione, in tutte le aree di lavoro assegnate.

Posso sospendere gli SKU F di Microsoft Fabric per risparmiare?

Sì. Gli SKU F acquistati tramite Azure possono essere sospesi e riattivati, interrompendo la fatturazione del calcolo quando le risorse sono inattive (ad esempio di notte o nel fine settimana), a condizione di tenere conto di eventuale debito di carry forward non ancora saldato.

Che cosa causa il debito di carry forward in Fabric?

Il debito di carry forward si verifica quando le aree di lavoro superano i limiti di capacità acquistati. La potenza di calcolo in eccesso viene trattata come un debito da saldare con i cicli di capacità futuri, il che può rallentare temporaneamente le prestazioni.

In che modo i carichi di lavoro in background e quelli interattivi differiscono in Fabric?

I carichi di lavoro interattivi (clic sui report da parte degli utenti) vengono distribuiti su una finestra breve di pochi minuti, mentre quelli in background (aggiornamenti pianificati e pipeline notturne) vengono distribuiti su una finestra di 24 ore per ridurre al minimo i disagi.