Leggere in inglese

Condividi tramite

Valutare e ottimizzare la capacità di Microsoft Fabric

  • Articolo

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 limitazione ritarda o rifiuta le operazioni quando una capacità riceve una richiesta elevata e sostenuta di CPU (al di sopra del limite di 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 l'accounting del calcolo consumato su un periodo più lungo, in modo che non sia necessario uno SKU superiore per gestire il picco del calcolo.

Per ulteriori informazioni sulla capacità di Fabric, vedere Concetti e licenze di Microsoft Fabric e capacità di Fabric: tutto ciò che è necessario sapere sulle novità e su ciò che accadrà.

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 seconda delle operazioni eseguite, del modo in cui sono state eseguite (ad esempio, l'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.

Suggerimento

È sempre una buona strategia iniziare con piccole dimensioni e poi aumentare gradualmente le dimensioni della capacità in base alle esigenze.

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 di Power BI sono richieste on-demand, che sono operazioni interattive, mentre gli aggiornamenti del modello semantico 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 è in esecuzione la limitazione. La limitazione può verificarsi quando sono presenti numerose operazioni interattive o 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 Monitoraggio 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 nei Log Analytics o nel gateway dati locale.

Gestire l'utilizzo elevato del calcolo

Quando una capacità è altamente usata e inizia a mostrare limitazioni o rifiuto, esistono tre strategie per risolverla: ottimizzare, aumentare le prestazioni e aumentare il numero di istanze.

È consigliabile impostare le notifiche per apprendere quando l'utilizzo della capacità supera una soglia impostata. Prendere in considerazione anche l'uso di impostazioni specifiche del carico di lavoro per limitare le dimensioni delle operazioni, ad esempio il timeout delle query di Power BI o i limiti di riga o le impostazioni dell'area di lavoro 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). L’aumento delle prestazioni garantisce che siano disponibili risorse di calcolo sufficienti per tutti gli elementi in una capacità ed evitare la limitazione.

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

Aumentare il numero di istanze

È possibile aumentare il numero di istanze spostando alcune delle aree di lavoro o degli elementi in una capacità di Fabric differente per distribuire il carico di lavoro. Può essere un'opzione valida quando sono necessarie diverse strategie di capacità, impostazioni o amministratori. Il provisioning di più capacità è anche una buona strategia per isolare il calcolo per gli elementi ad alta priorità e anche per il contenuto self-service o di sviluppo. 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 di Power BI nella capacità condivisa, purché gli utenti dispongano di licenze di Power BI Pro che consentano loro 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.

Data warehouse dell'infrastruttura

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 per impostazione predefinita. A questo scopo, sono disponibili meno opzioni di ottimizzazione delle query rispetto a SQL Server o ai pool SQL dedicati di Azure Synapse Analytics.

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 di query che può essere correlata agli ID operazione trovati nell'app per le metriche della 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.

Infrastruttura Ingegneria dei dati e data science dell'infrastruttura

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 usa le CU (unità di capacità) come misura di calcolo utilizzate da vari elementi, tra cui notebook Spark, definizioni di lavoro Spark e lavori 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 ulteriori informazioni, vedere Ottimizzare i lavori Apache Spark in Azure Synapse Analytics e La necessità di ottimizzare la scrittura in 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 aumentare le istanze dei carichi di lavoro di progettazione dei dati accettando lavori Spark paralleli entro i limiti degli 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 Limitazione 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 Azure Data Lake Storage (ADLS) Gen2.

Data Factory

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

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

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

  • Evitare la logica inefficiente di Power Query per ridurre al minimo e ottimizzare le trasformazioni di dati costose, come ad esempio l'unione e l'ordinamento.
  • Cercare di ottenere la riduzione 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 la riduzione delle query non si verifica, Power Query recupera tutti i dati dall'origine dati ed esegue trasformazioni localmente, che possono risultare inefficaci e lente.
  • 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 gestione temporanea, 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 in 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 inefficci o eccessivamente complesse nella logica di Power Query.
  • Assenza di riduzione delle query o aggiornamento incrementale per tabelle dei fatti di grandi dimensioni.
  • Bursting del report, ovvero quando viene generato contemporaneamente un numero elevato di report di Power BI o di report impaginati.

Contenuto correlato

Altre domande? Provare a chiedere alla Community di Fabric.