Leggere in inglese

Condividi tramite

Guida all'ottimizzazione per Power BI

  • Articolo

Questo articolo offre indicazioni che consentono agli sviluppatori e agli amministratori di produrre e gestire soluzioni Power BI ottimizzate. È possibile ottimizzare la soluzione a livelli diversi dell'architettura. I livelli sono:

  • Origini dati
  • Modello di dati
  • Visualizzazioni, inclusi dashboard e report (impaginati o meno) di Power BI
  • Ambiente, inclusi capacità, gateway dati e 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 Connessione dinamica) e in Power BI sono definiti modelli semantici. È importante comprendere le opzioni disponibili e scegliere il tipo di modello semantico appropriato per la soluzione. Esistono tre modalità di archiviazione delle tabelle del modello semantico: Import, DirectQuery e Composite. Per altre informazioni, vedere modelli semantici nel servizio Power BI e Modalità del modello semantico nel servizio Power BI.

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

Ottimizzazione per autori di report e consumer di modelli

Il modello semantico è la base di tutti i report in Power BI. I consumer del modello semantico possono creare report di Power BI in Power BI Desktop connettendosi a un modello semantico pubblicato o connettendosi ai dati e creando un modello semantico locale. Il modello semantico può essere usato anche per creare report di Power BI nel browser, creare esplorazioni di Power BI, creare report impaginati, creare query DAX e creare report in Excel con Analizza in Excel, connettersi a Power BI in Excel o esportare dati da un oggetto visivo report, nonché molti altri strumenti di creazione di report. Un autore di modelli semantici può aiutare i consumer di modelli semantici a comprendere e usare il modello semantico con la modalità di compilazione del modello.

  • Nomi: tabelle, colonne e misure nel modello semantico con nomi descrittivi. Ad esempio, "Store Sales" come nome di tabella è più intuitivo di "Table1".
  • Descrizioni: le tabelle, le colonne e le misure nel modello possono avere descrizioni aggiunte per fornire maggiori dettagli rispetto al nome. Spiegare non solo ciò che includono, ma come devono essere usati.
  • Nascondi: è possibile nascondere tabelle, colonne e misure nel modello per visualizzare solo ciò che si prevede di usarle in un report. Ad esempio, le colonne di relazione possono essere un ID che non è necessario per la creazione di report e possono essere nascoste perché non devono essere usate in un report o colonne di dati con una misura per aggregare la colonna per incoraggiare l'uso della misura. Gli oggetti nascosti possono essere sempre ignorati in un secondo momento dal consumer del modello, in modo che siano ancora disponibili, ma nascondendo lo stato attivo.
  • Gerarchie: è possibile creare gerarchie per comunicare la gerarchia tra più colonne. Ad esempio, una gerarchia Calendario può contenere colonne Year, Month, Day e una gerarchia Product può contenere le colonne Category, Sub-Category, Product. Fare clic con il pulsante destro del mouse su una colonna per creare una gerarchia.
  • Misure: è possibile usare misure per aggregare le colonne di dati nel modello semantico per garantire la coerenza tra i report. Le misure possono variare dalla SOMMA di una colonna a un indice di integrità combinando più aggregazioni in modo specifico o confrontando le aggregazioni tra periodi di tempo, ad esempio la media giornaliera di questo mese rispetto alla media giornaliera dello stesso mese dell'anno precedente. Le misure possono essere visualizzate anche nella ricerca di Power BI e in altre funzionalità, ad esempio metriche e scorecard.
  • Formati: per impostazione predefinita è possibile specificare la modalità di visualizzazione di una colonna o di una misura in un oggetto visivo. I valori negli oggetti visivi possono essere personalizzati ulteriormente nell'oggetto visivo. Le opzioni di formato includono se contiene migliaia di virgole, il numero di cifre decimali, il modo in cui viene visualizzata una data e così via. È anche possibile applicare formati personalizzati o dinamici .
  • Categoria di dati: è possibile specificare una categoria di dati della colonna, ad esempio se si tratta di un URL Paese o Web.

Si tratta di funzionalità comuni del modello semantico di Power BI che possono essere sfruttate per aiutare gli autori di report e i consumer di modelli. Esistono molti altri, ad esempio gruppi di calcolo, parametri di campo, parametri di simulazione e raggruppamento e colonne binning, che devono essere valutati per verificare se applicano esigenze di creazione di report specifiche.

Ottimizzazione delle visualizzazioni

Le visualizzazioni di Power BI possono essere dashboard o report (impaginati o meno) di Power BI. Ognuna ha architetture diverse e quindi per ognuna valgono indicazioni specifiche.

Dashboard

È importante comprendere che Power BI gestisce una cache per i riquadri del dashboard, ad eccezione dei riquadri dei report dinamici e dei riquadri di streaming. Se il modello semantico impone la sicurezza a livello di riga dinamica, assicurarsi di comprendere le implicazioni relative alle prestazioni, dato che i riquadri vengono memorizzati nella cache in base all'utente.

Quando si aggiungono riquadri di report dinamici a un dashboard, questi non vengono forniti dalla cache di query, Si comportano invece come dei report ed eseguono query su v-core in tempo reale.

Come indicato dal nome, il recupero dei dati dalla cache offre prestazioni migliori e più coerenti rispetto al recupero dall'origine dati. Per sfruttare al meglio questa funzionalità, è consigliabile impostare i dashboard come prima pagina di destinazione per gli utenti. Aggiungere gli oggetti visivi più richiesti e usati di frequente ai dashboard. In questo modo, i dashboard diventano una "prima linea di difesa" che offre prestazioni coerenti con un minor carico sulla capacità. Gli utenti possono comunque fare clic su un report per analizzare i dettagli.

Per DirectQuery e i modelli semantici di connessioni dinamiche, la cache viene aggiornata su base periodica tramite l'esecuzione di query sull'origine dati. Per impostazione predefinita, questo aggiornamento viene eseguito ogni ora, anche se è possibile configurare una frequenza diversa nelle impostazioni del modello semantico. Ogni aggiornamento della cache invia query all'origine dati sottostante. Il numero di query generate dipende dal numero di oggetti visivi aggiunti ai dashboard che si basano sull'origine dati. Tenere presente che se è abilitata la sicurezza a livello di riga, vengono generate query per ogni contesto di sicurezza diverso. Si consideri, ad esempio, l'esistenza di due ruoli diversi per la categorizzazione degli utenti con due visualizzazioni diverse dei dati. Durante l'aggiornamento della cache di query, Power BI genera due set di query.

Report di Power BI

Per l'ottimizzazione delle progettazioni dei report di Power BI è possibile seguire diversi consigli.

Nota

Se i report si basano su un modello semantico DirectQuery, per altre ottimizzazioni della progettazione dei report vedere Linee guida per il modello DirectQuery in Power BI Desktop (ottimizzare le progettazioni di report).

Applicare i filtri più restrittivi

Maggiore è il numero dei dati da visualizzare in un oggetto visivo, più lento sarà il caricamento dell'oggetto stesso. Sebbene questo principio possa sembrare ovvio, spesso lo si dimentica. 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 visualizzare le righe volute, in genere qualche decina.

Un errore comune è lasciare la visualizzazione predefinita della tabella non filtrata, ovvero con oltre 100 milioni di righe. I dati di queste righe vengono caricati nella memoria e decompressi a ogni aggiornamento, provocando una notevole richiesta di memoria. Soluzione: usare il filtro "Primi N" per ridurre il numero massimo di elementi visualizzati dalla tabella. È possibile impostare il numero massimo di elementi su un valore maggiore rispetto a quello necessario per gli utenti, ad esempio 10.000. L'esperienza dell'utente finale non cambia, ma l'uso della memoria diminuisce in modo significativo e, soprattutto, le prestazioni migliorano.

Un approccio di progettazione simile a quello precedente è consigliato per ogni oggetto visivo del report. È importante chiedersi se tutti i dati presenti nell'oggetto visivo sono effettivamente necessari e se è possibile filtrare la quantità di dati visualizzati nell'oggetto visivo con un impatto minimo sull'esperienza dell'utente finale. Si ricordi che le tabelle, in particolare, possono far uso di una quantità considerevole di memoria.

Limitare gli oggetti visivi nelle pagine dei report

Il principio precedente si applica allo stesso modo al numero di oggetti visivi aggiunti a una pagina di un report. È consigliabile limitare il numero di oggetti visivi in una pagina di report specifica al minimo necessario. Le pagine drill-through e le descrizioni comando delle pagine dei report sono un'ottima soluzione per offrire dettagli aggiuntivi senza sovraccaricare la pagina di oggetti visivi.

Valutare le prestazioni degli oggetti visivi

Assicurarsi di testare ogni oggetti visivo personalizzato per garantirne le prestazioni elevate. Gli oggetti visivi di Power BI non ottimizzati possono influire negativamente sulle prestazioni dell'intero report.

Report impaginati di Power BI

È possibile ottimizzare le progettazioni di report impaginati di Power BI applicando le procedure consigliate di progettazione al recupero dati dei report. Per altre informazioni, vedere Linee guida per il recupero dei dati per i report impaginati.

Assicurarsi anche che nella capacità sia allocata memoria sufficiente 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 le capacità, disponibili con power BI Premium (SKU 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 con capacità Fabric (SKU F).

Per altre informazioni, vedere Aggiornamento importante disponibile per le licenze Power BI Premium e Domande frequenti su Power BI Premium.

Ridimensionamento del gateway

Un gateway è necessario ogni volta che Power BI deve accedere a dati non accessibili direttamente tramite Internet. È possibile installare un gateway dati locale in un server locale o in un'infrastruttura IaaS (Infrastructure-as-a-Service) ospitata in una macchina virtuale.

Per comprendere i carichi di lavoro del gateway e per consigli sul ridimensionamento, vedere Ridimensionamento del gateway dati locale.

Latenza di rete

La latenza di rete può influire sulle prestazioni dei report allungando i tempi necessari alle richieste per raggiungere il servizio Power BI e per restituire le risposte. I tenant in Power BI sono assegnati a un'area specifica.

Suggerimento

Per determinare la posizione del tenant, vedere Dove si trova il tenant di Power BI?

Quando gli utenti in un tenant accedono al servizio Power BI, le richieste vengono sempre indirizzate a quest'area. Quando le richieste raggiungono il servizio Power BI, il servizio può inviare richieste aggiuntive, ad esempio al gateway dati o all'origine dati sottostante, a loro volta soggette alla latenza di rete.

Alcuni strumenti, come il 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 tenere le origini dati, i gateway e la capacità di Power BI il più vicini possibile. Preferibilmente all'interno della stessa area. Se la latenza di rete costituisce un problema, provare a cambiare l'area di gateway e origini dati posizionandoli in macchine virtuali ospitate nel cloud in un'area più vicina alla capacità di Power BI.

Monitoraggio delle prestazioni

È possibile monitorare le prestazioni del server per identificare colli di bottiglia. Le query o gli oggetti visivi con esecuzione lenta dovranno essere sottoposti a un'ottimizzazione continua. Il monitoraggio può essere eseguito in fase di progettazione in Power BI Desktop o in carichi di lavoro di produzione in capacità Power BI Premium. Per altre informazioni, vedere Monitorare le prestazioni dei report in Power BI.

Contenuto correlato

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