Valutare e ottimizzare la capacità di Microsoft Fabric

Questo articolo illustra come valutare e ottimizzare il carico sulle capacità di Microsoft Fabric. Descrive anche le strategie per affrontare le situazioni di overload e fornisce indicazioni per ottimizzare il calcolo per ognuna delle esperienze di Fabric.

Se da un lato il modello di capacità di Fabric semplifica la configurazione e abilita la collaborazione, è molto probabile esaurire le risorse di calcolo condivise di una capacità. Potrebbe anche accadere di pagare per più risorse di quelle necessarie. Queste situazioni possono verificarsi quando la progettazione di alcune esperienze di Fabric non segue le procedure consigliate.

È importante ridurre il rischio di esaurimento delle risorse condivise: Fabric, come servizio gestito, risolve automaticamente tali situazioni in due modi.

• Il bursting e lo smoothing garantiscono che le attività a elevato utilizzo di CPU vengano completate rapidamente, senza richiedere uno SKU superiore (e possono essere eseguite in qualsiasi momento del giorno).
• La regolazione ritarda o rifiuta le operazioni quando una capacità è soggetta a una domanda sostenuta e elevata di CPU (superiore al limite dello SKU).

Lo smoothing riduce la probabilità di limitazione (anche se la limitazione può comunque verificarsi). Lo smoothing è il modo in cui l'utilizzo viene allocato rispetto ai limiti, ma è indipendente dall'esecuzione dei lavori. Lo smoothing non modifica le prestazioni, ma si limita a distribuire la contabilizzazione dell'elaborazione consumata su un periodo più lungo, in modo che non sia necessario uno SKU di dimensioni maggiori per gestire il picco della capacità di calcolo.

Per altre informazioni sulla capacità di Fabric, vedere Microsoft Fabric concetti e licenze e Capacità di Fabric - Tutto ciò che è necessario sapere sulle novità e sugli sviluppi futuri.

Strumenti di pianificazione e definizione del budget

Pianificare le dimensioni di una capacità può essere una sfida. Ciò è dovuto al fatto che il calcolo richiesto può variare notevolmente a causa delle operazioni eseguite, della loro esecuzione (ad esempio, dell'efficienza di una query DAX o del codice Python in un notebook) o del livello di concorrenza.

Per determinare le dimensioni corrette della capacità, è possibile effettuare il provisioning delle capacità di valutazione o degli SKU F con pagamento in base al consumo per misurare le dimensioni effettive della capacità necessarie prima di acquistare un'istanza riservata dello SKU F.

Monitora capacità

È consigliabile monitorare l'utilizzo delle capacità per sfruttarle al meglio. Prima di tutto, è importante comprendere che le operazioni di Fabric sono interattive o in background. Ad esempio, le query DAX di un report Power BI sono richieste su richiesta che sono operazioni interattive, mentre gli aggiornamenti semantici del modello sono operazioni in background. Per ulteriori informazioni sulle operazioni e su come usano le risorse all'interno di Fabric, vedere Operazioni Fabric.

Il monitoraggio può rivelare all'utente che la limitazione è attivata. La limitazione può verificarsi quando sono presenti numerose operazioni interattive oppure operazioni a esecuzione prolungata. In genere, le operazioni in background correlate alle esperienze SQL e Spark sono fluidificate, ovvero vengono distribuite in un periodo di 24 ore.

L'app Fabric Capacity Metrics è il modo migliore per monitorare e visualizzare l'utilizzo recente. L'app si suddivide in base al tipo di elemento (modello semantico, notebook, pipeline e altri) e ti consente di identificare elementi o operazioni che usano livelli elevati di calcolo (in modo che possano essere ottimizzati).

Gli amministratori possono usare l'area di lavoro di monitoraggio dell'amministratore per ottenere informazioni sugli elementi usati di frequente (e sull'adozione complessiva). Possono anche usare l'hub di monitoraggio per visualizzare le attività correnti e recenti nel tenant. Ulteriori informazioni su alcune operazioni potrebbero essere disponibili anche da Log Analytics o dai log del gateway dati on-premises.

Gestire l'utilizzo elevato del calcolo

Quando una capacità è altamente usata e inizia a mostrare strozzamento o rifiuti delle richieste, esistono tre strategie per risolverla: ottimizzare, potenziare, e scalare orizzontalmente.

È consigliabile impostare le notifiche per apprendere quando l'utilizzo della capacità supera una soglia impostata. Prendere inoltre in considerazione l'uso di impostazioni specifiche del carico di lavoro per limitare le dimensioni delle operazioni, ad esempio impostando un timeout delle query o limiti di righe in Power BI, o le impostazioni dell'area di lavoro di Spark.

Ottimizzazione

Gli autori di contenuti devono sempre ottimizzare la progettazione degli elementi di Fabric per garantire che sia efficiente e usi meno risorse di calcolo possibili. Le linee guida specifiche per ogni esperienza di Fabric vengono fornite più avanti in questo articolo.

Aumentare le prestazioni

È possibile aumentare la capacità per aumentare temporaneamente o in modo permanente le dimensioni dello SKU (con maggiore capacità di calcolo). Il potenziamento garantisce che siano disponibili risorse di calcolo sufficienti per tutti gli elementi in una capacità ed evitare il throttling.

È anche possibile ridimensionare, sospendere e riprendere gli SKU F di Fabric per allinearsi ai modelli di consumo.

Espandere orizzontalmente

È possibile espandere la capacità trasferendo alcune delle aree di lavoro o degli elementi a una capacità di Fabric diversa per bilanciare il carico di lavoro. Può essere un'opzione valida quando sono necessarie diverse strategie di capacità, impostazioni o amministratori. Isolare le risorse di calcolo per gli elementi ad alta priorità, così come per i contenuti di autoservizio o di sviluppo, è una strategia utile anche nell'approvvigionamento di più capacità. Ad esempio, i dirigenti dell'organizzazione si aspettano report e dashboard altamente reattivi. Questi report e dashboard possono risiedere in una capacità separata dedicata alla creazione di report esecutivi.

È anche possibile spostare le aree di lavoro Power BI nella capacità condivisa, purché gli utenti abbiano le licenze Power BI Pro che consentano di continuare ad accedere al contenuto.

Configurare la protezione contro le sovratensioni

protezione contro i picchi consente di limitare l'utilizzo eccessivo della capacità limitando la quantità totale di processi di calcolo in background utilizzati. Questo riduce il carico di elaborazione totale, rendendo meno probabile la presenza di ritardi interattivi o di rifiuti. Consente anche di recuperare più rapidamente la capacità se è presente un periodo di limitazione o rifiuto. Configura la protezione da sovratensioni per ciascuna capacità. La protezione contro i picchi aiuta a evitare limitazioni e rigetti, ma non è un sostituto per l'ottimizzazione della capacità, l'incremento delle prestazioni e il ridimensionamento.

Quando la protezione da picchi è attiva, i processi in background vengono rifiutati. Ciò significa che c'è un impatto sulla capacità anche quando è abilitata la protezione contro i picchi. Usando la protezione da sovratensioni, si sta ottimizzando la capacità per rimanere entro un intervallo di utilizzo che bilancia al meglio le esigenze di calcolo all'interno della capacità disponibile. Per proteggere completamente le soluzioni critiche, è consigliabile isolarle in una capacità di dimensioni adeguate.

Ottimizzazione del calcolo in base all'esperienza Fabric

Le esperienze e gli elementi in Fabric funzionano in modo diverso, quindi non è necessario ottimizzarli nello stesso modo. Questa sezione elenca gli elementi di Fabric in base all'esperienza e le azioni che è possibile eseguire per ottimizzarli.

Infrastruttura Data Warehouse

Il data warehouse usa un'architettura serverless e i relativi nodi vengono gestiti automaticamente dal servizio. L'utilizzo della capacità viene calcolato in base ai secondi di unità di capacità attiva per ciascuna query anziché alla quantità di tempo di provisioning dei nodi front-end e back-end.

Tutte le operazioni del data warehouse sono operazioni in background e vengono fluidificate in un periodo di 24 ore.

L'endpoint di analisi SQL mira a offrire prestazioni di default ottimizzate. A questo scopo, sono disponibili meno opzioni di ottimizzazione delle query rispetto a SQL Server o Azure Synapse Analytics pool SQL dedicati.

Ecco alcuni punti da considerare per ridurre al minimo il calcolo.

• Scrivere query usando il T-SQL più ottimale possibile. Quando possibile, limitare il numero di colonne, calcoli, aggregazioni e altre operazioni che potrebbero aumentare inutilmente l'utilizzo delle risorse di query.
• Progettare tabelle per usare i tipi di dati più piccoli possibili. La scelta del tipo di dati può influire notevolmente sui piani di query generati dal motore SQL. Ad esempio, la riduzione di un campo VARCHAR di lunghezza da 500 a 25 o la modifica da DECIMAL(32, 8) a DECIMAL(10, 2) può comportare una diminuzione significativa delle risorse assegnate per una query.
• Usare la progettazione di schemi star per ridurre il numero di righe lette e per ridurre al minimo i join delle query.
• Verificare che le statistiche esistano e siano aggiornate. Le statistiche svolgono un ruolo fondamentale nella generazione del piano di esecuzione ottimale. Vengono create automaticamente in fase di esecuzione, ma potrebbe essere necessario aggiornarle manualmente, soprattutto dopo il caricamento o l'aggiornamento dei dati. Provare a creare statistiche tramite l'opzione FULLSCAN anziché basarsi sulle statistiche generate automaticamente che usano il campionamento.
• Usare le viste predefinite per monitorare le query e l'utilizzo, soprattutto durante la risoluzione dei problemi.
  • La DMV (Dynamic Management View) sys.dm_exec_requests fornisce informazioni su tutte le query in esecuzione attiva, ma non archivia informazioni cronologiche. La casella degli strumenti di Fabric fornisce una query che usa questa DMV e semplifica l'uso del risultato della query tramite l'aggiunta ad altre visualizzazioni per fornire dettagli come il testo della query.
  • Informazioni dettagliate sulle query, una funzionalità del data warehousing di Fabric, offre una visualizzazione olistica della cronologia delle attività di query nell'endpoint di analisi SQL. In particolare, la visualizzazione queryinsights.exec_requests_history fornisce informazioni su ogni richiesta SQL completa. Presenta tutti i dettagli pertinenti per ogni esecuzione delle query che possono essere correlati agli ID operazione trovati nell'app delle metriche di capacità. Le colonne più importanti per il monitoraggio dell'utilizzo della capacità sono: distributed_statement_id, comando (testo della query), start_time e end_time.

Ingegneria dei dati di Fabric e Data Science di Fabric

Le esperienze di Data science e di Ingegneria dei dati usano il calcolo Spark per elaborare, analizzare e archiviare i dati in un lakehouse di Fabric. Il calcolo Spark viene configurato e misurato in termini di vCore. Tuttavia, Fabric utilizza i CU (unità di calcolo) come misura del calcolo consumato da vari elementi, tra cui notebook Spark, definizioni di lavori Spark e lavori nel lakehouse.

In Spark, una CU si traduce in due vCore spark di calcolo. Ad esempio, quando un cliente acquista uno SKU F64, sono disponibili 128 v-Core Spark per le esperienze Spark.

Tutte le operazioni Spark sono operazioni in background e vengono fluidificate in un periodo di 24 ore.

Per ulteriori informazioni, vedere Report di fatturazione e utilizzo in Fabric Spark.

Ecco alcuni punti da considerare per ridurre al minimo il calcolo.

• Cercare sempre di scrivere codice Spark efficiente. Per altre informazioni, vedere Ottimizzare i lavori Apache Spark in Azure Synapse Analytics e La necessità di ottimizzare la scrittura su Apache Spark.
• Riservare gli executor necessari per i lavori Spark per liberare risorse per altri lavori o carichi di lavoro Spark. In caso contrario, si aumenta la probabilità che i lavori Spark non vadano a buon fine, con uno stato HTTP 430, ovvero un numero eccessivo di richieste rispetto alla capacità. È possibile visualizzare il numero di executor assegnati a un notebook nell'hub di monitoraggio di Fabric, in cui è anche possibile determinare il numero effettivo di executor usati dal notebook. I lavori Spark riservano solo i nodi necessari e consentono invii paralleli entro i limiti dello SKU.
• Il pool di Spark può essere configurato solo per usare il numero massimo di vCore supportati dallo SKU. Tuttavia, è possibile scalare i carichi di lavoro di ingegneria dei dati accettando lavori Spark paralleli entro i limiti dello SKU. Questo approccio è comunemente noto come fattore di burst ed è abilitato per impostazione predefinita per i carichi di lavoro Spark a livello di capacità. Per altre informazioni, vedere Gestione e accodamento della concorrenza.
• Le sessioni Spark attive possono accumulare l’utilizzo di CU su una capacità. Per questo motivo, è importante arrestare le sessioni Spark attive quando non sono in uso. Si noti che l'ora di scadenza della sessione Spark predefinita è impostata su 20 minuti. Gli utenti possono modificare il timeout della sessione in un notebook o nella definizione del lavoro di Spark.

Intelligence in tempo reale

Il consumo di CU del database KQL viene calcolato in base al numero di secondi in cui il database è attivo e al numero di vCore usati. Ad esempio, quando il database usa quattro vCore ed è attivo per 10 minuti, si useranno 2.400 (4 x 10 x 60) secondi di CU.

Tutte le operazioni di database KQL sono operazioni interattive.

Un meccanismo di scalabilità automatica viene usato per determinare le dimensioni del database KQL. Questo garantisce che le prestazioni migliori e ottimizzate per i costi vengano ottenute in base ai modelli di utilizzo.

Per consentire la disponibilità dei dati ad altri motori di Fabric, il database KQL viene sincronizzato con OneLake. In base al numero di letture e transazioni di scrittura eseguite dal database KQL, le CPU vengono utilizzate dalla capacità. Usa i contatori di lettura e scrittura di OneLake, equivalenti alle operazioni di lettura e scrittura negli account di Azure Data Lake Storage (ADLS) Gen2.

Fabbrica di Dati

Questa sezione riguarda le ottimizzazioni per i flussi di dati e le pipeline in Data Factory.

Tutte le operazioni sono processi in background e vengono distribuite su un periodo di 24 ore.

Ecco alcuni punti da considerare per ridurre al minimo il calcolo.

• Evitare logica inefficiente in Power Query per ottimizzare e ridurre al minimo le costose trasformazioni dei dati, quali l'unione e l'ordinamento.
• Sforzarsi di ottenere il raggruppamento delle query quando possibile. Questa può migliorare le prestazioni dei flussi di dati riducendo la quantità di dati da trasferire tra l'origine dati e la destinazione. Quando il folding delle query non si verifica, Power Query recupera tutti i dati dall'origine dati ed esegue trasformazioni localmente, il che può risultare inefficiente e lento.
• Disabilitare la gestione temporanea quando si lavora con volumi di dati di piccole dimensioni e/o si eseguono trasformazioni semplici. In alcuni casi potrebbe essere necessaria la messa in scena, ad esempio quando si carica un data warehouse.
• Evitare di aggiornare i dati più frequentemente rispetto alle esigenze dell'origine dati. Ad esempio, se l'origine dati viene aggiornata una sola volta ogni 24 ore, l'aggiornamento dei dati ogni ora non fornirà più valore. Prendere invece in considerazione l'aggiornamento dei dati a una frequenza appropriata per assicurarsi che siano aggiornati e precisi.

Power BI

Le operazioni di Power BI sono interattive o in background.

Le operazioni interattive seguenti comportano in genere un utilizzo elevato del calcolo.

• Modelli semantici che non seguono le procedure consigliate. Ad esempio, potrebbero non adottare la progettazione dello schema star con relazioni uno-a-molti. In alternativa, potrebbero includere filtri di sicurezza a livello di riga complessi e costosi. Provare a usare l'editor tabulare e l'analizzatore delle procedure consigliate per determinare se vengono seguite le procedure consigliate.
• Le misure DAX sono inefficienti.
• Le pagine del report contengono troppi oggetti visivi, che possono comportare un aggiornamento visivo lento.
• Gli oggetti visivi del report visualizzano risultati con cardinalità elevata (troppe righe o colonne) oppure contengono troppe misure.
• La capacità presenta una concorrenza elevata perché sono presenti troppi utenti per le dimensioni della capacità. Valutare la possibilità di abilitare la scalabilità orizzontale delle query per migliorare l'esperienza utente per i modelli semantici con concorrenza elevata (ma non comporta un aumento del calcolo totale).

Le operazioni in background seguenti comportano in genere un utilizzo elevato del calcolo.

• Trasformazioni di dati inefficienti o eccessivamente complesse nella logica di Power Query.
• Assenza di piegatura delle query o aggiornamento incrementale per tabelle dei fatti di grandi dimensioni.
• Report bursting, ovvero quando un elevato numero di report di Power BI o report paginati viene generato simultaneamente.

Contenuto correlato

• Microsoft Fabric concetti e licenze
• Blog: Capacità di Fabric: tutto ciò che è necessario sapere sulle novità e su ciò che accadrà

Altre domande? Prova a chiedere alla Comunità di Fabric.