Guida all'ottimizzazione per Power BI

  • Articolo

Questo articolo fornisce indicazioni che consentono agli sviluppatori e agli amministratori di produrre e gestire soluzioni Power BI ottimizzate. È possibile ottimizzare la soluzione a livelli architetturali diversi. I livelli includono:

  • Origini dati
  • Modello di dati
  • Visualizzazioni, inclusi dashboard, report di Power BI e report impaginati di Power BI
  • L'ambiente, incluse le capacità, i gateway dati e la rete

Ottimizzazione del modello di dati

Il modello di dati supporta l'intera esperienza di visualizzazione. I modelli di dati sono ospitati nell'ecosistema di Power BI o esternamente (usando DirectQuery o Live Connessione ion) e in Power BI sono definiti modelli semantici, noti in precedenza come set di dati. È importante comprendere le opzioni e scegliere il tipo di modello semantico appropriato per la soluzione. Esistono tre modalità di modello semantico: Import, DirectQuery e Composite. Per altre informazioni, vedere Modelli semantici nelle modalità servizio Power BI e Modello semantico nella servizio Power BI.

Per indicazioni specifiche sulla modalità del modello semantico, vedere:

Ottimizzazione delle visualizzazioni

Le visualizzazioni di Power BI possono essere dashboard, report di Power BI o report impaginati di Power BI. Ognuna ha architetture diverse e quindi ognuna ha le proprie linee guida.

Dashboard

È importante comprendere che Power BI mantiene una cache per i riquadri del dashboard, ad eccezione dei riquadri del report live e dei riquadri di streaming. Se il modello semantico applica la sicurezza dinamica a livello di riga, assicurarsi di comprendere le implicazioni delle prestazioni perché i riquadri verranno memorizzati nella cache per utente.

Quando si aggiungono riquadri del report in tempo reale a un dashboard, non vengono gestiti dalla cache delle query. Si comportano invece come report ed eseguono query su v-core in tempo reale.

Come suggerisce il nome, il recupero dei dati dalla cache offre prestazioni migliori e più coerenti rispetto all'origine dati. Un modo per sfruttare questa funzionalità consiste nel fare in modo che i dashboard siano la prima pagina di destinazione per gli utenti. Aggiungere oggetti visivi usati e altamente richiesti ai dashboard. In questo modo, i dashboard diventano una preziosa "prima linea di difesa", che offre prestazioni coerenti con meno carico sulla capacità. Gli utenti possono comunque fare clic su un report per analizzare i dettagli.

Per i modelli semantici di connessione dinamica e DirectQuery, la cache viene aggiornata periodicamente eseguendo una query sull'origine dati. Per impostazione predefinita, si verifica ogni ora, anche se è possibile configurare una frequenza diversa nelle impostazioni del modello semantico. Ogni aggiornamento della cache invierà query all'origine dati sottostante per aggiornare la cache. Il numero di query generate dipende dal numero di oggetti visivi aggiunti ai dashboard che si basano sull'origine dati. Si noti che se la sicurezza a livello di riga è abilitata, le query vengono generate per ogni contesto di sicurezza diverso. Si consideri, ad esempio, che ci siano due ruoli diversi che classificano gli utenti e hanno due visualizzazioni diverse dei dati. Durante l'aggiornamento della cache delle query, Power BI genera due set di query.

Report di Power BI

Sono disponibili diversi consigli per ottimizzare le progettazioni dei report di Power BI.

Nota

Quando i report sono basati su un modello semantico DirectQuery, per altre ottimizzazioni di progettazione dei report, vedere Linee guida sul modello DirectQuery in Power BI Desktop (Ottimizzare le progettazioni dei report).

Applicare i filtri più restrittivi

Maggiore è il numero di dati che un oggetto visivo deve visualizzare, più lento è il caricamento dell'oggetto visivo. Anche se questo principio sembra ovvio, è facile dimenticare. Si supponga, ad esempio, di avere un modello semantico di grandi dimensioni. In base a tale modello semantico, si compila un report con una tabella. Gli utenti finali usano i filtri dei dati nella pagina per ottenere le righe desiderate, in genere sono interessati solo a poche decine di righe.

Un errore comune consiste nell'lasciare la visualizzazione predefinita della tabella non filtrata, ovvero tutte le 100M+ righe. I dati per queste righe vengono caricati in memoria e non compressi a ogni aggiornamento. Questa elaborazione crea enormi richieste di memoria. Soluzione: usare il filtro "Top N" per ridurre il numero massimo di elementi visualizzati dalla tabella. È possibile impostare l'elemento massimo su più grande di quello necessario per gli utenti, ad esempio 10.000. Il risultato è che l'esperienza dell'utente finale non cambia, ma l'uso della memoria diminuisce notevolmente. E soprattutto, le prestazioni migliorano.

Un approccio di progettazione simile a quello precedente è consigliato per ogni oggetto visivo nel report. Chiedere se stessi, tutti i dati in questo oggetto visivo sono necessari? Esistono modi per filtrare la quantità di dati visualizzati nell'oggetto visivo con un impatto minimo sull'esperienza dell'utente finale? Tenere presente che le tabelle in particolare possono essere costose.

Limitare gli oggetti visivi nelle pagine del report

Il principio precedente si applica allo stesso modo al numero di oggetti visivi aggiunti a una pagina del report. È consigliabile limitare il numero di oggetti visivi in una determinata pagina del report solo a ciò che è necessario. Le pagine drill-through e le descrizioni comando della pagina del report sono ottimi modi per fornire dettagli aggiuntivi senza bloccare altri oggetti visivi nella pagina.

Valutare le prestazioni degli oggetti visivi personalizzati

Assicurarsi di mettere ogni oggetto visivo personalizzato attraverso i suoi ritmi per garantire prestazioni elevate. Gli oggetti visivi di Power BI non ottimizzati possono influire negativamente sulle prestazioni dell'intero report.

Report impaginati di Power BI

Le progettazioni di report impaginati di Power BI possono essere ottimizzate applicando la progettazione delle procedure consigliate al recupero dei dati del report. Per altre informazioni, vedere Indicazioni sul recupero dei dati per i report impaginati.

Assicurarsi inoltre che la capacità disponga di memoria sufficiente allocata al carico di lavoro dei report impaginati.

Ottimizzazione dell'ambiente

È possibile ottimizzare l'ambiente Power BI configurando le impostazioni di capacità, ridimensionando i gateway dati e riducendo la latenza di rete.

Impostazioni di capacità

Quando si usano capacità, disponibili con SKU Power BI Premium (P), licenze Premium per utente (PPU) o Power BI Embedded (SKU A, A4-A6), è possibile gestire le impostazioni di capacità. Per altre informazioni, vedere Licenze di capacità di Microsoft Fabric e Gestione delle capacità Premium.

Importante

A volte questo articolo si riferisce a Power BI Premium o alle relative sottoscrizioni di capacità (SKU P). Tenere presente che Microsoft sta attualmente consolidando le opzioni di acquisto e ritirando gli SKU di Power BI Premium per capacità. I clienti nuovi ed esistenti devono invece prendere in considerazione l'acquisto di sottoscrizioni della capacità di Fabric (SKU F).

Per altre informazioni, vedere Aggiornamenti importanti in arrivo per le licenze di Power BI Premium e Domande frequenti su Power BI Premium.

Dimensionamento del gateway

Un gateway è necessario ogni volta che Power BI deve accedere ai dati che non sono accessibili direttamente tramite Internet. È possibile installare il gateway dati locale in un server locale o un'infrastruttura distribuita come servizio (IaaS) ospitata in una macchina virtuale.

Per informazioni sui carichi di lavoro e sulle dimensioni dei gateway, vedere Dimensionamento del gateway dati locale.

Latenza di rete

La latenza di rete può influire sulle prestazioni del report aumentando il tempo necessario per consentire alle richieste di raggiungere il servizio Power BI e per il recapito delle risposte. I tenant in Power BI vengono assegnati a un'area specifica.

Suggerimento

Per determinare dove si trova il tenant, vedere Dove si trova il tenant di Power BI?

Quando gli utenti di un tenant accedono al servizio Power BI, le richieste instradano sempre a questa area. Quando le richieste raggiungono il servizio Power BI, il servizio può quindi inviare richieste aggiuntive, ad esempio all'origine dati sottostante o a un gateway dati, che sono soggette anche alla latenza di rete.

Strumenti come Test di velocità di Azure forniscono un'indicazione della latenza di rete tra il client e l'area di Azure. In generale, per ridurre al minimo l'impatto della latenza di rete, cercare di mantenere le origini dati, i gateway e la capacità di Power BI il più vicino possibile. Preferibilmente, risiedono all'interno della stessa area. Se la latenza di rete è un problema, provare a individuare gateway e origini dati più vicine alla capacità di Power BI inserendoli all'interno di macchine virtuali ospitate nel cloud.

Monitoraggio delle prestazioni

È possibile monitorare le prestazioni per identificare i colli di bottiglia. Le query lente, o gli oggetti visivi del report, devono essere un punto focale dell'ottimizzazione continua. Il monitoraggio può essere eseguito in fase di progettazione in Power BI Desktop o nei carichi di lavoro di produzione nelle capacità di Power BI Premium. Per altre informazioni, vedere Monitoraggio delle prestazioni dei report in Power BI.

Contenuto correlato

Per altre informazioni su questo articolo, consultare le risorse seguenti: