Condividi tramite

Pianificazione dell'implementazione di Power BI: controllo a livello di dati

  • Articolo

Nota

Questo articolo fa parte della serie di articoli sulla pianificazione dell'implementazione di Power BI. Questa serie è incentrata principalmente sull'esperienza Power BI in Microsoft Fabric. Per un'introduzione alla serie, vedere Pianificazione dell'implementazione di Power BI.

Questo articolo sul controllo a livello di dati è destinato a più gruppi di destinatari:

  • Autori di dati e amministratori dell'area di lavoro: utenti che devono comprendere l'utilizzo, l'adozione e le prestazioni dei modelli semantici, dei flussi di dati e dei datamarts creati, pubblicati e condivisi.
  • Amministratori Power BI: amministratori responsabili della supervisione di Power BI nell'organizzazione. Gli amministratori di Power BI potrebbero dover collaborare con IT, sicurezza, controllo interno e altri team pertinenti. Gli amministratori di Power BI potrebbero anche dover collaborare con creatori di contenuti durante la risoluzione dei problemi relativi alle prestazioni.
  • Amministratori della capacità di Power BI: amministratori responsabili della supervisione della capacità Premium nell'organizzazione. Gli amministratori della capacità di Power BI potrebbero dover collaborare con creatori di contenuti durante la risoluzione dei problemi relativi alle prestazioni.
  • Center of Excellence, team IT e BI: altri team responsabili della supervisione di Power BI. Potrebbe essere necessario collaborare con gli amministratori di Power BI e altri team pertinenti.
  • Amministratori di sistema: il team responsabile della creazione e della protezione delle risorse di Azure Log Analytics e degli amministratori di database che gestiscono le origini dati.

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.

I concetti trattati in questo articolo si applicano principalmente alle soluzioni create per tre ambiti di distribuzione del contenuto, in particolare business intelligence aziendale, business intelligence del reparto e business intelligence per i team. Anche i creatori di soluzioni BI personali potrebbero trovare le informazioni in questo articolo utili; tuttavia, non sono la destinazione primaria.

Ottenere prestazioni ottimali nei report e negli oggetti visivi non è possibile quando il modello semantico sottostante e/o l'origine dati non funziona correttamente. Questo articolo è incentrato sul controllo e il monitoraggio di modelli semantici, flussi di dati e datamarts. È il secondo articolo della serie di controllo e monitoraggio perché gli strumenti e le tecniche sono più complessi rispetto a quanto descritto nell'articolo Controllo a livello di report. Idealmente, è possibile creare modelli semantici condivisi (destinati al riutilizzo tra molti report) prima che gli utenti creino report. Pertanto, è consigliabile leggere questo articolo insieme all'articolo Controllo a livello di report.

Poiché i modelli semantici di Power BI sono basati sul motore tabulare di Analysis Services, è possibile connettersi a un modello di dati locale (in Power BI Desktop) o a un modello semantico Premium (nel servizio Power BI) come se fosse un database di Analysis Services. Di conseguenza, molte delle funzionalità di controllo e monitoraggio di Analysis Services sono supportate per i modelli semantici Power BI Premium.

Nota

Per altre informazioni sui modelli ospitati in Analysis Services, vedere Panoramica del monitoraggio.

La parte restante di questo articolo è incentrata principalmente sui modelli pubblicati nel servizio Power BI.

Log eventi del modello semantico

Nel corso del tempo, gli autori di dati e i proprietari potrebbero riscontrare situazioni con i propri modelli semantici. Un modello semantico può:

Per garantire l'usabilità, le buone prestazioni e l'adozione del contenuto creato, è necessario controllare l'utilizzo e le prestazioni degli asset di dati responsabili della gestione. È possibile usare i log eventi del set di dati, che acquisiscono le attività generate dall'utente e generate dal sistema che si verificano per un modello semantico. Vengono anche definiti eventi di traccia, log dei set di dati o log attività del set di dati. Gli amministratori di sistema spesso li chiamano eventi di traccia di basso livello perché sono dettagliati.

Nota

La modifica del nome del set di dati è stata implementata nella servizio Power BI e nella documentazione, anche se potrebbero esserci alcune istanze, ad esempio con i nomi delle operazioni del registro eventi, in cui la modifica non è ancora stata apportata.

È consigliabile analizzare gli eventi di traccia del modello semantico per:

  • Controllare tutte le attività che si sono verificate in un modello semantico.
  • Risolvere i problemi e ottimizzare le prestazioni del modello semantico, l'utilizzo della memoria e l'efficienza delle query.
  • Analizzare i dettagli e la durata dell'aggiornamento semantico del modello.
  • Monitorare il linguaggio di formula di Power Query (query M) inviato da Power Query.
  • Monitorare le formule e le espressioni DAX inviate al modello semantico (motore di Analysis Services).
  • Verificare se la modalità di archiviazione corretta è stata selezionata in base ai carichi di lavoro e alla necessità di bilanciare i dati aggiornati e le prestazioni ottimali.
  • Controllare quali ruoli di sicurezza a livello di riga vengono richiamati, per quali utenti e su quali modelli semantici.
  • Comprendere il numero di utenti simultanei.
  • Convalidare un modello semantico, ad esempio per verificare la qualità e le prestazioni dei dati prima di approvare un modello semantico o prima di pubblicarlo in un'area di lavoro di produzione.

Gli eventi generati da un modello semantico di Power BI derivano dai log di diagnostica esistenti disponibili per Azure Analysis Services. Esistono molti tipi di eventi di traccia che è possibile acquisire e analizzare, descritti nelle sezioni seguenti.

Log Analytics di Azure

Azure Log Analytics è un componente del servizio Monitoraggio di Azure. L'integrazione di Azure Log Analytics con Power BI consente di acquisire eventi del modello semantico da tutti i modelli semantici in un'area di lavoro di Power BI. È supportato solo per le aree di lavoro Premium. Dopo aver configurato l'integrazione e quando la connessione è abilitata (per un'area di lavoro Power BI Premium), gli eventi del modello semantico vengono acquisiti e inviati continuamente a un'area di lavoro Log Analytics di Azure. I log del modello semantico vengono archiviati in Esplora dati di Azure, ovvero un database di solo accodamento ottimizzato per l'acquisizione di grandi volumi di dati di telemetria quasi in tempo reale.

Si assegna un'area di lavoro di Power BI Premium a un'area di lavoro Log Analytics in Azure. È necessario creare una nuova risorsa di Log Analytics nella sottoscrizione di Azure per abilitare questo tipo di registrazione.

I log da una o più aree di lavoro di Power BI verranno inviati a un'area di lavoro Log Analytics di destinazione. Ecco alcuni modi in cui è possibile scegliere di organizzare i dati.

  • Un'area di lavoro di destinazione per tutti i dati di controllo: archiviare tutti i dati in un'area di lavoro Log Analytics. Questo è utile quando lo stesso amministratore o gli stessi utenti accedono a tutti i dati.
  • Aree di lavoro di destinazione organizzate in base all'area dell'oggetto: organizzare il contenuto in base all'area dell'oggetto. Questa tecnica è particolarmente utile quando diversi amministratori o utenti sono autorizzati ad accedere ai dati di controllo da Azure Log Analytics. Ad esempio, quando è necessario separare i dati di vendita dai dati delle operazioni.
  • Un'area di lavoro di destinazione per ogni area di lavoro di Power BI: configurare una relazione uno-a-uno tra un'area di lavoro di Power BI e un'area di lavoro Di Azure Log Analytics. Ciò è utile quando si dispone di contenuti particolarmente sensibili o quando i dati sono soggetti a requisiti normativi o di conformità specifici.

Suggerimento

Esaminare attentamente la documentazione e le domande frequenti su questa funzionalità, in modo da avere chiare le possibilità e comprendere i requisiti tecnici. Prima di rendere questa funzionalità disponibile a livello generale per gli amministratori dell'area di lavoro nell'organizzazione, è consigliabile eseguire un modello di verifica tecnico con un'area di lavoro di Power BI.

Importante

Anche se i nomi sono simili, i dati acquisiti da Azure Log Analytics non corrispondono al log attività di Power BI. Azure Log Analytics acquisisce gli eventi di traccia a livello di dettaglio dal motore di Analysis Services. L'unico scopo è quello di analizzare e risolvere i problemi relativi alle prestazioni del modello semantico. L'ambito è a livello di area di lavoro. Al contrario, lo scopo del log attività è quello di comprendere la frequenza con cui si verificano determinate attività utente, ad esempio la modifica di un report, l'aggiornamento di un modello semantico o la creazione di un'app. L'ambito è l'intero tenant di Power BI.

Per altre informazioni sulle attività utente che è possibile controllare per il tenant di Power BI, vedere Controllo a livello di tenant.

L'impostazione tenant Connessione di Azure Log Analytics per gli amministratori dell'area di lavoro controlla quali gruppi di utenti (con il ruolo di amministratore dell'area di lavoro necessario) possono connettere un'area di lavoro di Power BI a un'area di lavoro Log Analytics esistente.

Prima di poter configurare l'integrazione, è necessario soddisfare i prerequisiti di sicurezza. È pertanto consigliabile abilitare l'impostazione del tenant di Power BI solo per gli amministratori dell'area di lavoro di Power BI che dispongono anche delle autorizzazioni necessarie in Azure Log Analytics o che possono ottenere tali autorizzazioni su richiesta.

Suggerimento

Collaborare con l'amministratore di Azure all'inizio del processo di pianificazione, soprattutto quando si riceve l'approvazione per creare una nuova risorsa di Azure è una sfida nell'organizzazione. Sarà anche necessario pianificare i prerequisiti di sicurezza. Decidere se concedere l'autorizzazione all'amministratore dell'area di lavoro di Power BI in Azure o se concedere l'autorizzazione all'amministratore di Azure in Power BI.

I log del modello semantico acquisiti da Azure Log Analytics includono le query del modello semantico, le statistiche delle query, l'attività di aggiornamento dettagliata, il tempo di CPU utilizzato nelle capacità Premium e altro ancora. Poiché si tratta di log a livello di dettaglio dal motore di Analysis Services, i dati possono essere dettagliati. I volumi di dati di grandi dimensioni sono comuni per le aree di lavoro di grandi dimensioni che riscontrano un'attività di modello semantico elevato.

Per ottimizzare i costi quando si usa Azure Log Analytics con Power BI:

  • Connettere le aree di lavoro di Power BI ad Azure Log Analytics solo quando si esegue attivamente la risoluzione dei problemi, i test, l'ottimizzazione o l'analisi dell'attività del modello semantico. Quando si è connessi, una traccia viene eseguita su tutti i modelli semantici nell'area di lavoro.
  • Disconnettere Azure Log Analytics da un'area di lavoro di Power BI quando non è più necessario risolvere i problemi, testare, ottimizzare o analizzare l'attività del modello semantico. Disconnettendosi, l'esecuzione della traccia viene interrotta in tutti i modelli semantici nell'area di lavoro.
  • Assicurarsi di comprendere il modello di costo per la fatturazione di Azure Log Analytics per l'inserimento dei dati, l'archiviazione e le query.
  • Non archiviare i dati in Log Analytics per più tempo rispetto al periodo di conservazione predefinito di 30 giorni. Ciò è dovuto al fatto che l'analisi semantica del modello è in genere incentrata sulle attività immediate di risoluzione dei problemi.

Esistono diversi modi per accedere agli eventi inviati ad Azure Log Analytics. Puoi usare:

  • L'app modello predefinita Log Analytics per i modelli semantici di Power BI.
  • Il connettore Power BI Desktop per Esplora dati di Azure (Kusto). Usare il linguaggio di query Kusto (KQL) per analizzare i dati archiviati in Log Analytics. Se si ha esperienza con query SQL, si riscontreranno molte analogie con KQL.
  • L'esperienza di query basata sul Web in Esplora dati di Azure.
  • Qualsiasi strumento di query in grado di eseguire query KQL.

Suggerimento

Poiché è presente un volume elevato di eventi di traccia del modello semantico, è consigliabile sviluppare un modello DirectQuery per analizzare i dati. Un modello DirectQuery consente di eseguire query sui dati quasi in tempo reale. Gli eventi arrivano in genere entro cinque minuti.

Per altre informazioni, vedere Gestire le connessioni di Azure.

Elenco di controllo - Quando si prevede di usare Azure Log Analytics, le decisioni chiave e le azioni includono:

  • Prendere in considerazione un modello di verifica tecnico: pianificare un progetto di piccole dimensioni per assicurarsi di comprendere appieno i requisiti tecnici, i requisiti di sicurezza, gli eventi da acquisire e come analizzare i log.
  • Decidere quali aree di lavoro devono essere integrate con Log Analytics: determinare quali aree di lavoro Premium contengono modelli semantici da analizzare.
  • Decidere se Log Analytics deve essere abilitato a tempo pieno per le aree di lavoro: per l'ottimizzazione dei costi, determinare se ci sono situazioni (o aree di lavoro specifiche) in cui la registrazione deve essere abilitata in modo permanente. Decidere se le aree di lavoro devono essere disconnesse quando la risoluzione dei problemi non si verifica.
  • Decidere per quanto tempo conservare i dati di Log Analytics: determinare se è necessario impostare un periodo di conservazione più lungo rispetto al valore predefinito di 30 giorni.
  • Chiarire il processo per richiedere una nuova area di lavoro Log Analytics: collaborare con l'amministratore di Azure per chiarire in che modo le richieste di una nuova risorsa di Log Analytics devono essere inviate dagli amministratori dell'area di lavoro di Power BI.
  • Decidere come funzionerà la sicurezza: collaborare con l'amministratore di Azure per decidere se è più fattibile concedere a un amministratore dell'area di lavoro di Power BI i diritti per un'area di lavoro Log Analytics di Azure o concedere a un amministratore di Azure i diritti per un'area di lavoro di Power BI. Quando si prende questa decisione di sicurezza, prendere in considerazione il piano per connettersi e disconnettere regolarmente le aree di lavoro (per l'ottimizzazione dei costi).
  • Decidere come organizzare le aree di lavoro Log Analytics di destinazione: valutare il numero di aree di lavoro di Azure Log Analytics appropriate per organizzare i dati da una o più aree di lavoro di Power BI. Allineare questa decisione alle decisioni relative alla sicurezza per chi può accedere ai dati di log.
  • Decidere quali amministratori dell'area di lavoro possono connettersi: determinare quali gruppi di amministratori dell'area di lavoro possono connettere un'area di lavoro di Power BI a un'area di lavoro Log Analytics. Definire l'impostazione tenant Connessione di Azure Log Analytics per gli amministratori dell'area di lavoro per allinearla a questa decisione.
  • Creare la risorsa di Azure Log Analytics: collaborare con l'amministratore di Azure per creare ogni area di lavoro Log Analytics. Verificare e aggiornare le autorizzazioni assegnate in Azure per assicurarsi che la configurazione di Power BI possa avere luogo senza problemi. Verificare che i dati archiviati in Azure si trovino nell'area geografica corretta.
  • Impostare la connessione Log Analytics per ogni area di lavoro di Power BI: collaborare con gli amministratori dell'area di lavoro di Power BI per configurare la connessione a Log Analytics per ogni area di lavoro di Power BI. Verificare che i dati di log vengano trasmessi correttamente all'area di lavoro Log Analytics.
  • Creare query per analizzare i dati: configurare le query KQL per analizzare i dati in Log Analytics in base al caso d'uso e alle esigenze correnti.
  • Includere indicazioni per gli amministratori dell'area di lavoro di Power BI: fornire informazioni e prerequisiti agli amministratori dell'area di lavoro di Power BI per richiedere una nuova area di lavoro Log Analytics e come connettersi a un'area di lavoro di Power BI. Spiegare anche quando è opportuno disconnettere un'area di lavoro di Power BI.
  • Fornire indicazioni e query di esempio per l'analisi dei dati: creare query KQL per gli amministratori dell'area di lavoro per semplificare l'analisi dei dati acquisiti.
  • Monitorare i costi: collaborare con l'amministratore di Azure per monitorare i costi di Log Analytics in modo continuativo.

SQL Server Profiler

È possibile usare SQL Server Profiler (SQL Profiler) per acquisire gli eventi del modello semantico di Power BI. Si tratta di un componente di SQL Server Management Studio (SSMS). La connettività a un modello semantico di Power BI è supportata con SSMS perché si basa sull'architettura di Analysis Services originata in SQL Server.

È possibile usare SQL Profiler in diverse fasi del ciclo di vita di un modello semantico.

  • Durante lo sviluppo di modelli di dati: SQL Profiler può connettersi a un modello di dati in Power BI Desktop come strumento esterno. Questo approccio è utile per i modelli di dati che vogliono convalidare il modello di dati o eseguire l'ottimizzazione delle prestazioni.
  • Dopo la pubblicazione del modello semantico nel servizio Power BI: SQL Profiler può connettersi a un modello semantico in un'area di lavoro Premium. SSMS è uno dei molti strumenti client supportati che possono usare l'endpoint XMLA per la connettività. Questo approccio è utile quando si vuole controllare, monitorare, convalidare, risolvere i problemi o ottimizzare un modello semantico pubblicato nel servizio Power BI.

È anche possibile usare SQL Profiler come strumento esterno all'interno di DAX Studio. È possibile usare DAX Studio per avviare una traccia del profiler, analizzare i dati e formattare i risultati. I modelli di dati che usano DAX Studio spesso preferiscono questo approccio rispetto all'uso diretto di SQL Profiler.

Nota

L'uso di SQL Profiler è un caso d'uso diverso per l'attività dei dati di profilatura. È possibile profilare i dati nell'editor di Power Query per ottenere una comprensione più approfondita delle relative caratteristiche. Anche se la profilatura dei dati è un'attività importante per i modelli di dati, non rientra nell'ambito di questo articolo.

Prendere in considerazione l'uso di SQL Profiler invece di Azure Log Analytics quando:

  • L'organizzazione non consente di usare o creare risorse di Azure Log Analytics in Azure.
  • Si vogliono acquisire eventi per un modello di dati in Power BI Desktop (che non è stato pubblicato in un'area di lavoro Premium nel servizio Power BI).
  • Si vogliono acquisire eventi per un modello semantico per un breve periodo di tempo, anziché per tutti i modelli semantici in un'area di lavoro Premium.
  • Si vogliono acquisire determinati eventi solo durante una traccia, ad esempio solo l'evento Query End.
  • Si vogliono avviare e arrestare le tracce su base frequente, ad esempio quando è necessario acquisire gli eventi del modello semantico che si verificano ora.

Analogamente ad Azure Log Analytics (descritto in precedenza in questo articolo), gli eventi del modello semantico acquisiti da SQL Profiler derivano dai log di diagnostica esistenti disponibili per Azure Analysis Services. Esistono tuttavia alcune differenze negli eventi disponibili.

Suggerimento

L'uso di SQL Profiler per il monitoraggio di Analysis Services è illustrato in molti libri, articoli e post di blog. La maggior parte di queste informazioni è rilevante per il monitoraggio di un modello semantico di Power BI.

Importante

È anche possibile usare SQL Profiler per monitorare le query inviate dal servizio Power BI alle origini dati sottostanti, ad esempio a un database relazionale di SQL Server. Tuttavia, la funzionalità di tracciare un database relazionale è deprecata. La connessione al motore di Analysis Services è supportata e non è deprecata. Se si ha familiarità con gli eventi estesi di Analysis Services e si preferisce usarli, è possibile usare la connettività da SSMS per un modello di dati in Power BI Desktop. Tuttavia, non è supportato per Power BI Premium. Di conseguenza, questa sezione è incentrata solo sulla connettività standard di SQL Profiler.

L'impostazione tenant Consenti endpoint XMLA e analizza in Excel con modelli semantici locali controlla quali gruppi di utenti (a cui sono assegnati anche i ruoli dell'area di lavoro Collaboratore, Membro o Amministratore oppure l'autorizzazione di compilazione per il singolo modello semantico) possono usare l'endpoint XMLA per eseguire query e/o gestire modelli semantici nel servizio Power BI. Per altre informazioni sull'uso dell'endpoint XMLA, vedere lo scenario di utilizzo di gestione avanzata dei modelli di dati.

Nota

È anche possibile usare SQL Profiler per eseguire il debug e la risoluzione dei problemi relativi a espressioni DAX specifiche. È possibile connettere SQL Profiler a Power BI Desktop come strumento esterno. Cercare la classe di evento DAX Evaluation Log per visualizzare i risultati intermedi di un'espressione DAX. Tale evento viene generato quando si usa la funzione DAX EVALUATEANDLOG in un calcolo del modello.

Questa funzione è destinata solo a scopi di sviluppo e test. È consigliabile rimuoverla dai calcoli del modello di dati prima di pubblicare il modello di dati in un'area di lavoro di produzione.

Elenco di controllo - Quando si prevede di usare SQL Profiler, le decisioni chiave e le azioni includono:

  • Decidere chi può avere SSMS o DAX Studio installato: determinare se consentire a tutti gli autori di contenuti di Power BI nell'organizzazione di installare SSMS e/o DAX Studio in modo che possano usare SQL Profiler. Decidere se questi strumenti ausiliari debbano essere installati su richiesta o come parte di un set standard di software installato per autori di dati approvati nell'organizzazione.
  • Aggiungere SQL Profiler al menu Strumenti esterni in Power BI Desktop: se gli autori di dati useranno spesso SQL Profiler, chiedere all'IT di aggiungerlo automaticamente al menu Strumenti esterni in Power BI Desktop per questi utenti.
  • Decidere chi può usare l'endpoint XMLA: determinare se tutti gli utenti possono connettersi a modelli semantici pubblicati usando l'endpoint XMLA o se sono limitati solo agli autori di dati approvati. Definire l'impostazione tenant Consenti endpoint XMLA e analizza in Excel con i modelli semantici locali per allinearsi a questa decisione.
  • Fornire indicazioni e query di esempio per l'analisi dei dati: creare la documentazione per gli autori di dati in modo da comprendere il modo consigliato per controllare e monitorare i modelli semantici. Fornire indicazioni per i casi d'uso comuni per semplificare la raccolta e l'analisi dei dati di traccia.

Metadati del modello dati

Poiché i modelli semantici di Power BI sono basati sul motore di Analysis Services, è possibile accedere agli strumenti che possono eseguire query sui metadati di un modello di dati. I metadati includono tutti gli elementi relativi al modello di dati, inclusi nomi di tabella, nomi di colonna ed espressioni di misura.

DMV

Le DMV (Dynamic Management Views) di Analysis Services possono eseguire query sui metadati del modello di dati. È possibile usare le DMV per controllare, documentare e ottimizzare i modelli di dati in un momento specifico.

In particolare, è possibile:

  • Controllare le origini dati usate da un modello.
  • Individuare gli oggetti che utilizzano la maggior quantità di memoria in un modello.
  • Determinare in che modo i dati delle colonne possono essere compressi in modo efficiente.
  • Trovare colonne in un modello che non vengono usate.
  • Controllare le sessioni e le connessioni utente attive.
  • Verificare la struttura del modello.
  • Esaminare le espressioni DAX usate da tabelle calcolate, colonne calcolate, misure e regole di sicurezza a livello di riga.
  • Identificare le dipendenze tra oggetti e misure.

Suggerimento

Le DMV recuperano informazioni sullo stato corrente di un modello semantico. Si considerino i dati restituiti dalle DMV come snapshot degli eventi che si verificano in un determinato momento. Viceversa, i registri eventi del modello semantico (descritti in precedenza in questo articolo) recuperano informazioni sulle attività che si sono verificate per un modello semantico mentre era attiva una connessione di traccia.

SSMS è uno strumento comunemente usato per eseguire query DMV. È anche possibile usare il cmdlet di PowerShell Invoke-ASCmd per creare ed eseguire script XMLA che eseguono query sulle DMV.

Gli strumenti di terze parti e gli strumenti esterni sono diffusi anche nella community di Power BI. Questi strumenti usano le DMV documentate pubblicamente per semplificare l'accesso e usare i dati restituiti dalle DMV. Un esempio è DAX Studio, che include funzionalità esplicite per accedere alle DMV. DAX Studio include anche una funzionalità predefinita View Metrics, comunemente nota come Vertipaq Analyzer. Vertipaq Analyzer dispone di un'interfaccia utente per l'analisi della struttura e delle dimensioni di tabelle, colonne, relazioni e partizioni in un modello di dati. È anche possibile esportare (o importare) i metadati del modello di dati in un file con estensione vpax. Il file esportato contiene solo metadati relativi alla struttura e alle dimensioni del modello di dati, senza archiviare dati del modello.

Suggerimento

È consigliabile condividere un file con estensione vpax con un utente quando è necessaria assistenza per un modello di dati. In questo modo, i dati del modello non verranno condivisi con tale persona.

È possibile usare query DMV durante diverse fasi del ciclo di vita di un modello semantico.

  • Durante lo sviluppo di modelli di dati: lo strumento preferito può connettersi a un modello di dati in Power BI Desktop come strumento esterno. Questo approccio è utile per i modelli di dati che vogliono convalidare il modello di dati o eseguire l'ottimizzazione delle prestazioni.
  • Dopo la pubblicazione del modello semantico nel servizio Power BI: lo strumento preferito può connettersi a un modello semantico in un'area di lavoro Premium. SSMS è uno dei molti strumenti client supportati che usano l'endpoint XMLA per la connettività. Questo approccio è utile quando si vuole controllare o convalidare un modello semantico pubblicato nel servizio Power BI.

Suggerimento

Se si decide di scrivere query DMV personalizzate, ad esempio in SSMS, tenere presente che le DMV non supportano tutte le operazioni SQL. Inoltre, alcune DMV non sono supportate in Power BI perché richiedono autorizzazioni di amministratore del server Analysis Services non supportate da Power BI.

L'impostazione tenant Consenti endpoint XMLA e analizza in Excel con modelli semantici locali controlla quali gruppi di utenti (a cui sono assegnati anche i ruoli dell'area di lavoro Collaboratore, Membro o Amministratore oppure l'autorizzazione di compilazione per il singolo modello semantico) possono usare l'endpoint XMLA per eseguire query e/o gestire modelli semantici nel servizio Power BI.

Per altre informazioni sull'uso dell'endpoint XMLA, degli strumenti di terze parti e degli strumenti esterni, vedere lo scenario di utilizzo di gestione avanzata dei modelli di dati.

Best Practice Analyzer

Best Practice Analyzer (BPA) è una funzionalità di Tabular Editor, uno strumento di terze parti che ha raggiunto l'adozione diffusa dalla community di Power BI. BPA include un set di regole personalizzabili che consentono di controllare la qualità, la coerenza e le prestazioni del modello di dati.

Suggerimento

Per configurare BPA, scaricare il set di regole consigliate fornite da Microsoft su GitHub.

Principalmente, BPA consente di migliorare la coerenza dei modelli rilevando decisioni di progettazione non ottimali che possono ridurre i problemi di prestazioni. È utile quando si dispone di modelli di dati self-service distribuiti in diverse aree dell'organizzazione.

BPA consente anche di controllare e gestire i modelli di dati. Ad esempio, è possibile verificare se un modello di dati include ruoli di sicurezza a livello di riga. In alternativa, è possibile verificare se tutti gli oggetti modello hanno una descrizione. Questo è utile quando, ad esempio, l'obiettivo è garantire che un modello di dati includa un dizionario dati.

BPA può esporre problemi di progettazione che possono aiutare il Centro di eccellenza a determinare se è necessaria una maggiore formazione o documentazione. Può intervenire per informare gli autori di dati sulle procedure consigliate e sulle linee guida organizzative.

Suggerimento

Tenere presente che BPA può rilevare l'esistenza di una caratteristica, ad esempio la sicurezza a livello di riga. Tuttavia, potrebbe essere difficile determinare se è configurato correttamente. Per questo motivo, un esperto di materia potrebbe dover condurre una revisione . Al contrario, la non esistenza di una particolare caratteristica non significa necessariamente una progettazione errata. Il modello di dati potrebbe avere una buona ragione per produrre una progettazione specifica.

Elenco di controllo - Quando si pianifica l'accesso ai metadati per i modelli di dati, le decisioni chiave e le azioni includono:

  • Decidere chi può avere SSMS installato: determinare se si consentirà a tutti gli autori di contenuti di Power BI nell'organizzazione di installare SSMS in modo che possano connettersi ai modelli semantici pubblicati. Decidere se debba essere installato su richiesta o come parte di un set standard di software installato per autori di dati approvati nell'organizzazione.
  • Decidere chi può avere strumenti di terze parti installati: determinare se consentire a tutti gli autori di contenuti di Power BI nell'organizzazione di installare strumenti di terze parti (ad esempio DAX Studio e Editor tabulare) in modo che possano monitorare i modelli di dati locali e/o i modelli semantici pubblicati. Decidere se debbano essere installati su richiesta o come parte di un set standard di software installato per autori di dati approvati nell'organizzazione.
  • Configurare le regole delle procedure consigliate: decidere quali regole di Best Practice Analyzer possono analizzare i modelli di dati nell'organizzazione.
  • Decidere chi può usare l'endpoint XMLA: determinare se tutti gli utenti possono connettersi a modelli semantici usando l'endpoint XMLA o se sono limitati solo agli autori di dati approvati. Definire l'impostazione tenant Consenti endpoint XMLA e analizza in Excel con i modelli semantici locali per allinearsi a questa decisione.
  • Fornire indicazioni per gli autori di contenuti: creare la documentazione per gli autori di dati in modo che comprendano i modi consigliati per analizzare i modelli semantici. Fornire indicazioni per i casi d'uso comuni per facilitare la raccolta e l'analisi dei risultati DMV e/o l'uso di Best Practice Analyzer.

Modello di dati e prestazioni delle query

Power BI Desktop include diversi strumenti che consentono agli autori di dati di risolvere i problemi e analizzare i modelli di dati. Queste funzionalità sono destinate ai modellatori di dati che vogliono convalidare il modello di dati ed eseguire l'ottimizzazione delle prestazioni prima della pubblicazione nel servizio Power BI.

Analizzatore prestazioni

Usare Analizzatore prestazioni, disponibile in Power BI Desktop, per controllare e analizzare le prestazioni di un modello di dati. Performance Analyzer consente agli autori di report di misurare le prestazioni dei singoli elementi del report. In genere, tuttavia, la causa radice dei problemi di prestazioni è correlata alla progettazione del modello di dati. Per questo motivo, anche un creatore di modelli semantici può trarre vantaggio dall'uso di Performance Analyzer. Se sono presenti creatori di contenuti diversi responsabili della creazione di report rispetto a modelli semantici, è probabile che debbano collaborare durante la risoluzione di un problema di prestazioni.

Suggerimento

È possibile usare DAX Studio per importare e analizzare i file di log generati da Analizzatore prestazioni.

Per altre informazioni su Analizzatore prestazioni, vedere Controllo a livello di report.

Diagnostica query

Usare Diagnostica query, disponibile in Power BI Desktop, per analizzare le prestazioni di Power Query. Sono utili per la risoluzione dei problemi e per quando è necessario comprendere le operazioni del motore di Power Query.

Le informazioni che è possibile ottenere da Diagnostica query includono:

  • Dettagli aggiuntivi relativi ai messaggi di errore (quando si verifica un'eccezione).
  • Query inviate a un'origine dati.
  • Indica se la riduzione delle query si verifica o meno.
  • Numero di righe restituite da una query.
  • Potenziali rallentamenti durante un'operazione di aggiornamento dati.
  • Eventi in background e query generate dal sistema.

A seconda di ciò che si sta cercando, è possibile abilitare uno o tutti i log: aggregati, dettagliati, contatori delle prestazioni e partizioni di privacy dei dati.

È possibile avviare la diagnostica della sessione nell'editor di Power Query. Dopo l'abilitazione, le operazioni di query e aggiornamento vengono raccolte fino a quando non viene arrestata la traccia diagnostica. I dati vengono popolati direttamente nell'editor di query non appena la diagnostica viene arrestata. Power Query crea un gruppo di Diagnostica (cartella) e aggiunge diverse query. È quindi possibile usare la funzionalità standard di Power Query per visualizzare e analizzare i dati di diagnostica.

In alternativa, è possibile abilitare una traccia in Power BI Desktop nella sezione Diagnostica della finestra Opzioni. I file di log vengono salvati in una cartella nel computer locale. Questi file di log vengono popolati con i dati dopo la chiusura di Power BI Desktop, al momento in cui la traccia viene arrestata. Una volta chiuso Power BI Desktop, è possibile aprire i file di log con il programma preferito (ad esempio un editor di testo) per visualizzarli.

Valutazione e riduzione delle query

Power Query supporta varie funzionalità che consentono di comprendere la valutazione delle query, incluso il piano di query. Può anche essere utile per determinare se la riduzione delle query si verifica per un'intera query o per un subset di passaggi in una query. La riduzione delle query è uno degli aspetti più importanti dell'ottimizzazione delle prestazioni. È anche utile esaminare le query native inviate da Power Query durante il monitoraggio di un'origine dati, descritta più avanti in questo articolo.

App per le metriche Premium

Durante la risoluzione dei problemi, può essere utile collaborare con l'amministratore della capacità di Power BI Premium. L'amministratore della capacità ha accesso all'app di utilizzo e metriche di Power BI Premium. Questa app può fornire un'ampia gamma di informazioni sulle attività che si verificano nella capacità. Queste informazioni consentono di risolvere i problemi del modello semantico.

Suggerimento

L'amministratore della capacità Premium può concedere l'accesso ad altri utenti (amministratori non di capacità) per consentire loro di accedere all'app metriche Premium.

L'app metriche Premium include un modello semantico interno e un set iniziale di report. Consente di eseguire il monitoraggio quasi in tempo reale di una capacità Power BI Premium (SKU P) o di una capacità power BI Embedded (SKU A). Include i dati per le ultime due o quattro settimane (a seconda della metrica).

Usare l'app metriche Premium per risolvere i problemi e ottimizzare i modelli semantici. Ad esempio, è possibile identificare i modelli semantici con un footprint della memoria elevato o che riscontrano un utilizzo della CPU elevato. È anche uno strumento utile per trovare modelli semantici che si avvicinano al limite delle dimensioni della capacità.

Elenco di controllo - Quando si valutano gli approcci da usare per il monitoraggio del modello di dati e delle prestazioni delle query, le decisioni chiave e le azioni includono:

  • Identificare le destinazioni di prestazioni delle query del modello semantico: assicurarsi di avere una buona conoscenza delle prestazioni del modello semantico. Determinare quando sono necessarie destinazioni specifiche per le prestazioni delle query, ad esempio le query per supportare il rendering dei report entro cinque secondi. In tal caso, assicurarsi che le destinazioni vengano comunicate agli autori di dati nell'organizzazione.
  • Identificare le destinazioni di prestazioni di aggiornamento semantico del modello: determinare quando sono necessarie destinazioni di aggiornamento dati specifiche, ad esempio il completamento di un'operazione di aggiornamento dati entro 15 minuti e prima delle 5:00. In tal caso, assicurarsi che le destinazioni vengano comunicate agli autori di dati nell'organizzazione.
  • Informare il team di supporto: assicurarsi che il team di supporto utenti interno abbia familiarità con le funzionalità di diagnostica in modo che siano pronti a supportare gli utenti di Power BI quando hanno bisogno di assistenza.
  • Connettere il team di supporto e gli amministratori del database: assicurarsi che il team di supporto sappia come contattare gli amministratori corretti per ogni origine dati (ad esempio, durante la risoluzione dei problemi di riduzione delle query).
  • Collaborare con l'amministratore della capacità Premium: collaborare con l'amministratore della capacità per risolvere i problemi relativi ai modelli semantici che risiedono in un'area di lavoro assegnata alla capacità Premium o alla capacità di Power BI Embedded. Quando appropriato, richiedere l'accesso all'app per le metriche Premium.
  • Fornire indicazioni per gli autori di contenuti: creare la documentazione per gli autori di dati in modo che comprendano le azioni da intraprendere durante la risoluzione dei problemi.
  • Includere nei materiali di training: fornire indicazioni agli autori di dati su come creare modelli di dati con buone prestazioni. Aiutarli ad adottare le buone abitudini di design in anticipo. Concentrarsi sull'insegnamento ai creatori di dati su come prendere decisioni di progettazione corrette.

Monitoraggio dell'origine dati

A volte è necessario monitorare direttamente un'origine dati specifica a cui Si connette Power BI. Ad esempio, si potrebbe avere un data warehouse che riscontra un aumento del carico di lavoro e gli utenti segnalano una riduzione delle prestazioni. In genere, un amministratore del database o un amministratore di sistema monitora le origini dati.

È possibile monitorare un'origine dati per:

  • Controllare quali utenti inviano query all'origine dati.
  • Controllare quali applicazioni, ad esempio Power BI, inviano query all'origine dati.
  • Esaminare le istruzioni di query inviate all'origine dati, quando e da quali utenti.
  • Determinare il tempo necessario per l'esecuzione di una query.
  • Controllare il modo in cui la sicurezza a livello di riga viene richiamata dal sistema di origine quando usa l'accesso Single Sign-On (SSO).

Un creatore di contenuti di Power BI può eseguire molte azioni dopo l'analisi dei risultati del monitoraggio. Potrebbero:

  • Ottimizzare e perfezionare le query inviate all'origine dati in modo che siano il più efficienti possibile.
  • Convalidare e ottimizzare le query native inviate all'origine dati.
  • Ridurre il numero di colonne importate in un modello di dati.
  • Rimuovere colonne ad alta precisione e cardinalità elevata importate in un modello di dati.
  • Ridurre la quantità di dati cronologici importati in un modello di dati.
  • Modificare i tempi di aggiornamento dei dati di Power BI per facilitare la distribuzione della domanda per l'origine dati.
  • Usare l'aggiornamento incrementale dei dati per ridurre il carico sull'origine dati.
  • Ridurre il numero di aggiornamenti dei dati di Power BI consolidando più modelli semantici in un modello semantico condiviso.
  • Regolare le impostazioni di aggiornamento automatico della pagina per aumentare la frequenza di aggiornamento e quindi ridurre il carico nell'origine dati.
  • Semplificare i calcoli per ridurre la complessità delle query inviate all'origine dati.
  • Modificare la modalità di archiviazione dei dati, ad esempio in modalità di importazione anziché DirectQuery, per ridurre il carico coerente delle query nell'origine dati.
  • Usare tecniche di riduzione delle query per ridurre il numero di query inviate all'origine dati.

Gli amministratori di sistema potrebbero eseguire altre azioni. Potrebbero:

  • Introdurre un livello dati intermedio, ad esempio i flussi di dati di Power BI (quando un data warehouse non è un'opzione valida). Gli autori di contenuti di Power BI possono usare i flussi di dati come origine dati anziché connettersi direttamente alle origini dati. Un livello dati intermedio può ridurre il carico in un sistema di origine. Offre inoltre il vantaggio di centralizzare la logica di preparazione dei dati. Per altre informazioni, vedere lo scenario di utilizzo di preparazione dei dati self-service.
  • Modificare il percorso dell'origine dati per ridurre l'impatto della latenza di rete, ad esempio usare la stessa area dati per il servizio Power BI, le origini dati e i gateway.
  • Ottimizzare l'origine dati in modo da recuperare in modo più efficiente i dati per Power BI. Diverse tecniche comuni includono la creazione di indici di tabella, la creazione di viste indicizzate, la creazione di colonne calcolate persistenti, la gestione delle statistiche, l'uso di tabelle columnstore o in memoria e la creazione di viste materializzate.
  • Indirizzare gli utenti a usare una replica di sola lettura dell'origine dati anziché un database di produzione originale. Una replica potrebbe essere disponibile come parte di una strategia di database a disponibilità elevata. Uno dei vantaggi di una replica di sola lettura consiste nel ridurre la contesa nel sistema di origine.

Gli strumenti e le tecniche che è possibile usare per monitorare le origini dati dipendono dalla piattaforma tecnologica. Ad esempio, l'amministratore del database può usare eventi estesi o Query Store per il monitoraggio del database SQL di Azure e dei database di SQL Server.

In alcuni casi Power BI accede a un'origine dati tramite un gateway dati. I gateway gestiscono la connettività dal servizio Power BI a determinati tipi di origini dati. Tuttavia, non si limitano a connettersi ai dati. Un gateway include un motore mashup che esegue trasformazioni di elaborazione e dati nel computer. Comprime e crittografa anche i dati in modo che possano essere trasmessi in modo efficiente e sicuro al servizio Power BI. Pertanto, un gateway non gestito o non ottimizzato può contribuire ai colli di bottiglia delle prestazioni. È consigliabile rivolgersi all'amministratore del gateway per assistenza per il monitoraggio dei gateway.

Suggerimento

L'amministratore di Power BI può compilare un inventario tenant completo (che include la derivazione) e accedere alle attività utente nel log attività. Correlando le attività di derivazione e utente, gli amministratori possono identificare le origini dati e i gateway usati più di frequente.

Per altre informazioni sull'inventario tenant e sul log attività, vedere Controllo a livello di tenant.

Elenco di controllo - Quando si pianifica il monitoraggio di un'origine dati, le decisioni chiave e le azioni includono:

  • Determinare obiettivi specifici: quando si monitora un'origine dati, ottenere chiarezza esattamente su ciò che è necessario raggiungere e sugli obiettivi per la risoluzione dei problemi.
  • Collaborare con gli amministratori di database: collaborare con il database o gli amministratori di sistema per ottenere assistenza durante il monitoraggio di un'origine dati specifica.
  • Collaborare con gli amministratori del gateway: per le origini dati che si connettono tramite un gateway dati, collaborare con l'amministratore del gateway durante la risoluzione dei problemi.
  • Connettere il team di supporto e gli amministratori del database: assicurarsi che il team di supporto sappia come contattare gli amministratori corretti per ogni origine dati (ad esempio, durante la risoluzione dei problemi di riduzione delle query).
  • Aggiornare il training e le linee guida: includere informazioni chiave e suggerimenti per gli autori di dati su come usare le origini dati dell'organizzazione. Includere informazioni sulle operazioni da eseguire quando si verifica un errore.

Monitoraggio dell'aggiornamento dati

Un'operazione di aggiornamento dati comporta l'importazione di dati da origini dati sottostanti in un modello semantico, un flusso di dati o un datamart di Power BI. È possibile pianificare un'operazione di aggiornamento dati o eseguirla su richiesta.

Contratto di servizio

Il personale IT usa in genere contratti di servizio per documentare le aspettative per gli asset di dati. Per Power BI, prendere in considerazione l'uso di un contratto di servizio per il contenuto critico o il contenuto a livello aziendale. In genere include quando gli utenti possono aspettarsi che i dati aggiornati in un modello semantico siano disponibili. Ad esempio, è possibile avere un contratto di servizio che tutti gli aggiornamenti dei dati devono essere completati dalle 7:00 ogni giorno.

Log del modello semantico

I log eventi del modello semantico di Azure Log Analytics o SQL Profiler (descritti in precedenza in questo articolo) includono informazioni dettagliate su ciò che accade in un modello semantico. Gli eventi acquisiti includono l'attività di aggiornamento semantico del modello. I log eventi sono particolarmente utili quando è necessario risolvere i problemi e analizzare gli aggiornamenti semantici del modello.

Modelli semantici di capacità Premium

Quando si dispone di contenuto ospitato in una capacità Power BI Premium, sono disponibili più funzionalità per monitorare le operazioni di aggiornamento dei dati.

  • La pagina riepiloghi degli aggiornamenti di Power BI nel portale di amministrazione include un riepilogo della cronologia degli aggiornamenti. Questo riepilogo fornisce informazioni sulla durata dell'aggiornamento e sui messaggi di errore.
  • L'app di utilizzo e metriche di Power BI Premium include anche informazioni utili sull'aggiornamento. È utile quando è necessario analizzare l'attività di aggiornamento per una capacità Power BI Premium (SKU P) o una capacità di Power BI Embedded (SKU A).

Aggiornamenti avanzati del modello semantico

Gli autori di contenuti possono avviare aggiornamenti semantici del modello a livello di codice usando l'aggiornamento avanzato con l'API REST di Power BI Aggiornare set di dati nel gruppo. Quando si usa l'aggiornamento avanzato, è possibile monitorare le operazioni di aggiornamento storiche, correnti e in sospeso.

Monitoraggio della pianificazione dell'aggiornamento dati

Gli amministratori di Power BI possono monitorare le pianificazioni degli aggiornamenti dei dati nel tenant per determinare se sono presenti numerose operazioni di aggiornamento pianificate simultaneamente durante un intervallo di tempo specifico (ad esempio, tra le 5:00 e le 7:00, che potrebbero essere un orario di aggiornamento dati particolarmente occupato). Gli amministratori hanno l'autorizzazione per accedere ai metadati della pianificazione dell'aggiornamento del modello semantico dalle API di analisi dei metadati, note come API dello scanner.

API REST di Power BI

Per i modelli semantici critici, non basarsi esclusivamente sulle notifiche tramite posta elettronica per il monitoraggio dei problemi di aggiornamento dei dati. Valutare la possibilità di compilare la cronologia degli aggiornamenti dati in un archivio centralizzato in cui è possibile monitorare, analizzare e agire su di esso.

È possibile recuperare la cronologia dell'aggiornamento dati usando:

Suggerimento

È consigliabile monitorare la cronologia degli aggiornamenti dei modelli semantici per assicurarsi che i dati correnti siano disponibili per report e dashboard. Aiuta anche a sapere se vengono soddisfatti i contratti di servizio.

Elenco di controllo - Quando si pianifica il monitoraggio dell'aggiornamento dei dati, le decisioni chiave e le azioni includono:

  • Determinare obiettivi specifici: quando si monitora l'aggiornamento dei dati, ottenere maggiore chiarezza su ciò che è necessario eseguire e sull'ambito del monitoraggio (ad esempio, modelli semantici di produzione, modelli semantici certificati e altri).
  • Valutare la possibilità di configurare un contratto di servizio: determinare se un contratto di servizio sarebbe utile per impostare le aspettative di disponibilità dei dati e quando devono essere eseguite le pianificazioni dell'aggiornamento dati.
  • Collaborare con amministratori di database e gateway: collaborare con gli amministratori del database o del sistema e con gli amministratori del gateway per monitorare o risolvere i problemi relativi all'aggiornamento dei dati.
  • Trasferimento delle informazioni per il team di supporto: assicurarsi che il team di supporto sappia come aiutare gli autori di contenuti quando si verificano problemi di aggiornamento dei dati.
  • Aggiornare il training e le linee guida: includere informazioni chiave e suggerimenti per gli autori di dati su come aggiornare i dati da origini dati aziendali e origini dati comuni. Includere le procedure consigliate e le preferenze organizzative per la gestione dell'aggiornamento dei dati.
  • Usare un indirizzo di posta elettronica di supporto per le notifiche: per il contenuto critico, configurare le notifiche di aggiornamento per l'uso di un indirizzo di posta elettronica di supporto.
  • Configurare il monitoraggio centralizzato degli aggiornamenti: usare le API REST di Power BI per compilare la cronologia degli aggiornamenti dati.

Monitoraggio del flusso di dati

Si crea un flusso di dati di Power BI con Power Query Online. Molte delle funzionalità di prestazioni delle query e la diagnostica di Power Query, descritte in precedenza, sono applicabili.

Facoltativamente, è possibile impostare le aree di lavoro per l'uso di Azure Data Lake Storage Gen2 per l'archiviazione dei flussi di dati (nota come bring-your-own-storage) anziché per l'archiviazione interna. Quando si usa bring-your-own-storage, è consigliabile abilitare i dati di telemetria in modo da poter monitorare le metriche per l'account di archiviazione. Per altre informazioni, vedere lo scenario di preparazione dei dati self-service e di preparazione avanzata dei dati.

È possibile usare le API REST di Power BI per monitorare le transazioni del flusso di dati. Ad esempio, usare l'API Recuperare transazioni del flusso di dati per controllare lo stato degli aggiornamenti del flusso di dati.

È possibile tenere traccia delle attività utente per i flussi di dati di Power BI con il log attività di Power BI. Per altre informazioni, vedere Controllo a livello di tenant.

Suggerimento

Esistono molte procedure consigliate che è possibile adottare per ottimizzare le progettazioni dei flussi di dati. Per altre informazioni, vedere Procedure consigliate per i flussi di dati.

Monitoraggio di Datamart

Un datamart di Power BI include diversi componenti integrati, tra cui un flusso di dati, un database gestito e un modello semantico. Per informazioni sul controllo e il monitoraggio di ogni componente, vedere le sezioni precedenti di questo articolo.

È possibile tenere traccia delle attività degli utenti per i datamarts di Power BI usando il log attività di Power BI. Per altre informazioni, vedere Controllo a livello di tenant.

Contenuto correlato

Nell'articolo successivo di questa serie sono presenti informazioni sul controllo a livello di tenant.