• 18 minuti

DirectQuery rappresenta uno dei modi per avere i dati disponibili in Power BI Desktop. Il metodo DirectQuery prevede la connessione diretta dall'interno di Power BI Desktop ai dati contenuti nel repository di origine. È un'alternativa all'importazione di dati in Power BI Desktop.

Quando si usa il metodo DirectQuery, l'esperienza utente complessiva dipende in larga misura dalle prestazioni dell'origine dati sottostante. Tempi lenti di risposta alle query determinano un'esperienza utente negativa e, in casi estremi, il timeout delle query stesse. Inoltre, il numero di utenti che aprono i report in un dato momento avrà un impatto sul carico posto sull'origine dati. Ad esempio, se un report contiene 20 oggetti visivi e dieci persone lo stanno usando, ci saranno 200 query o più sull'origine dati, perché ogni oggetto visivo emetterà una o più query.

Sfortunatamente, le prestazioni del modello di Power BI in uso dipendono non solo dalle prestazioni dell'origine dati sottostante, ma anche da altri fattori incontrollabili, ad esempio:

• Latenza di rete: le reti più veloci restituiscono i dati più rapidamente.

• Le prestazioni del server dell'origine dati e il numero totale di carichi di lavoro presenti su quel server. Si pensi, ad esempio, alle implicazioni che può avere un aggiornamento del server mentre centinaia di persone lo usano per motivi diversi.

Pertanto, l'uso di DirectQuery comporta un rischio per la qualità delle prestazioni del modello. Per ottimizzare le prestazioni in questa situazione, è necessario avere il controllo del database di origine o disporre del relativo accesso.

Per informazioni più dettagliate, vedere Linee guida per il modello DirectQuery in Power BI Desktop.

Implicazioni dell'uso di DirectQuery

L'importazione dei dati in Power BI Desktop è una procedura consigliata, ma un'organizzazione potrebbe aver bisogno di usare la modalità di connettività ai dati DirectQuery per uno dei seguenti motivi (vantaggi di DirectQuery):

• È adatta nei casi in cui i dati cambiano frequentemente ed è necessario creare report in near real-time.

• Può gestire grandi quantità di dati senza la necessità di preaggregarli.

• Applica restrizioni alla sovranità dei dati per ottemperare ai requisiti legali.

• Si può usare con un'origine dati multidimensionale che contiene misure come SAP Business Warehouse (BN).

Se l'organizzazione ha bisogno di usare DirectQuery, è importante comprenderne chiaramente il comportamento in Power BI Desktop ed essere consapevoli dei suoi limiti. In tal modo si sarà in grado di intervenire per ottimizzare il più possibile il modello DirectQuery.

Comportamento delle connessioni DirectQuery

Quando si usa DirectQuery per connettersi ai dati in Power BI Desktop, tale connessione si comporta nel seguente modo:

• Quando si usa inizialmente la funzionalità Recupera dati in Power BI Desktop, occorre selezionare l'origine. Se si effettua la connessione a un'origine relazionale, è possibile selezionare un set di tabelle; ciascuna di esse definirà una query che restituisce un set di dati a livello logico. Se si seleziona un'origine multidimensionale, come SAP BW, è possibile solo selezionare l'origine.

• Quando si caricano i dati, nessun dato viene importato in Power BI Desktop, ma solo lo schema. Quando si crea un oggetto visivo in Power BI Desktop, le query vengono inviate all'origine sottostante per recuperare i dati necessari. Il tempo necessario per aggiornare l'oggetto visivo dipende dalle prestazioni dell'origine dati sottostante.

• Se vengono apportate modifiche ai dati sottostanti, queste non verranno immediatamente riflesse negli oggetti visivi esistenti in Power BI a causa della memorizzazione nella cache. Per vedere queste modifiche è necessario effettuare un aggiornamento. Per ogni oggetto visivo sono presenti le query necessarie e gli oggetti visivi vengono aggiornati di conseguenza.

• Una volta pubblicato nel servizio Power BI, il report si traduce in un modello semantico nel servizio Power BI, come accade per l'importazione. Tuttavia, nessun dato è incluso in quel modello semantico.

• Quando si apre un report esistente nel servizio Power BI o se ne crea uno nuovo, l'origine sottostante viene nuovamente sottoposta a query per recuperare i dati necessari. A seconda dell'ubicazione dell'origine, potrebbe essere necessario configurare un gateway dati locale.

• È possibile aggiungere oggetti visivi o intere pagine di report come riquadri di dashboard. L'aggiornamento dei riquadri avviene automaticamente secondo una pianificazione, ad esempio ogni ora. È possibile modificare tale frequenza in base alle esigenze. Quando si apre un dashboard, i riquadri riflettono i dati al momento dell'ultimo aggiornamento e potrebbero non includere le ultime modifiche apportate all'origine dati sottostante. È sempre possibile aggiornare un dashboard aperto per assicurarsi che il contenuto sia corrente.

Limiti delle connessioni DirectQuery

L'uso di DirectQuery può avere implicazioni negative. Le limitazioni variano a seconda della specifica origine dati in uso. È opportuno prendere in considerazione i seguenti punti:

• Prestazioni: come indicato in precedenza, l'esperienza utente complessiva dipende in larga misura dalle prestazioni dell'origine dati sottostante.

• Sicurezza: se si usano più origini dati in un modello DirectQuery, è importante comprendere il modo in cui i dati si spostano tra le origini dati sottostanti e le implicazioni di sicurezza associate. Va anche chiarito se regole di sicurezza sono applicabili ai dati nell'origine dati sottostante perché, in Power BI, ogni utente può vedere tali dati.

• Trasformazione dei dati: rispetto ai dati importati, i dati provenienti da DirectQuery presentano delle limitazioni rispetto all'applicazione di tecniche di trasformazione dei dati nell'editor di Power Query. Ad esempio, nel caso di una connessione a un'origine OLAP come SAP BW, non è possibile effettuare alcuna trasformazione: l'intero modello esterno viene tratto dall'origine dati. Se si desidera apportare delle trasformazioni ai dati, sarà necessario farlo nell'origine dati sottostante.

• Modellazione: alcune delle funzionalità di modellazione disponibili con i dati importati non sono disponibili o sono limitate quando si usa DirectQuery.

• Creazione di report: quasi tutte le funzionalità di creazione di report disponibili con i dati importati sono supportate anche per i modelli DirectQuery, a condizione che l'origine sottostante offra un livello di prestazioni adeguato. Tuttavia, quando il report viene pubblicato nel servizio Power BI, le funzionalità Informazioni rapide e Domande e risposte non sono supportate. Inoltre, l'uso della funzionalità Esplora in Excel probabilmente comporterà prestazioni peggiori.

Per informazioni più dettagliate sulle limitazioni relative all'uso di DirectQuery, vedere Implicazioni dell'uso di DirectQuery.

Compreso il funzionamento generale di DirectQuery e i limiti che pone, è possibile intraprendere misure per migliorarne le prestazioni.

Ottimizzazione delle prestazioni

Proseguendo con lo scenario di Tailwind Traders, durante la revisione del modello semantico si scopre che la query ha usato DirectQuery per connettere Power BI Desktop ai dati di origine. Quest'uso di DirectQuery è la ragione per cui gli utenti riscontrano scarse prestazioni nei report. Il caricamento delle pagine nel report richiede troppo tempo e le tabelle non si aggiornano abbastanza rapidamente quando vengono effettuate determinate selezioni. È necessario intervenire per ottimizzare le prestazioni del modello DirectQuery.

È possibile esaminare le query inviate all'origine sottostante e provare a identificare il motivo delle scarse prestazioni delle query. È quindi possibile apportare modifiche in Power BI Desktop e nell'origine dati sottostante per ottimizzare le prestazioni complessive.

Ottimizzazione dei dati in Power BI Desktop

Dopo aver ottimizzato il più possibile l'origine dati, è possibile intraprendere ulteriori azioni all'interno di Power BI Desktop usando l'analizzatore prestazioni, in cui isolare le query per convalidare i piani di query.

È possibile analizzare la durata delle query inviate all'origine sottostante per identificare quelle con tempo di caricamento più lungo. In altre parole, è possibile individuare la posizione dei colli di bottiglia.

Non è necessario adottare un approccio speciale quando si ottimizza un modello DirectQuery: è possibile applicare le stesse tecniche di ottimizzazione impiegate sui dati importati per ottimizzare i dati provenienti dall'origine DirectQuery. Ad esempio, è possibile ridurre il numero di oggetti visivi nella pagina del report o ridurre il numero di campi usati in un oggetto visivo. È inoltre possibile rimuovere colonne e righe non necessarie.

Per indicazioni più dettagliate su come ottimizzare una query DirectQuery, vedere: Linee guida per il modello DirectQuery in Power BI Desktop e Indicazioni per il corretto uso di DirectQuery.

Ottimizzazione dell'origine dati sottostante (database connesso)

La prima tappa è l'origine dati. È necessario ottimizzare il database di origine il più possibile perché qualsiasi azione volta a migliorare le prestazioni di tale database migliorerà a sua volta DirectQuery in Power BI. Le azioni eseguite nel database sono quelle che produrranno i risultati migliori.

Considerare l'uso delle seguenti pratiche di database standard che si applicano alla maggior parte delle situazioni:

• Evitare l'uso di colonne calcolate complesse perché l'espressione di calcolo verrà incorporata nelle query di origine. È più efficiente eseguire il push dell'espressione nell'origine perché evita la fase di push-down. Si potrebbe anche prendere in considerazione l'aggiunta di colonne chiave sostitutive alle tabelle di tipo dimensione.

• Esaminare gli indici e verificare che l'indicizzazione corrente sia corretta. Se è necessario creare nuovi indici, assicurarsi che siano appropriati.

Fare riferimento alla documentazione dell'origine dati e implementare i relativi consigli sulle prestazioni.

Personalizzazione delle opzioni di riduzione delle query

Power BI Desktop offre la possibilità di inviare meno query e di disabilitare determinate interazioni che potrebbero causare un'esperienza insoddisfacente se l'esecuzione delle query risultanti richiede molto tempo. L'applicazione di queste opzioni evita che le query raggiungano continuamente l'origine dati, il che dovrebbe migliorare le prestazioni.

In questo esempio si modificano le impostazioni predefinite per applicare al modello le opzioni disponibili di riduzione dei dati. Per accedere alle impostazioni, selezionare File>Opzioni e impostazioni>Opzioni, scorrere la pagina verso il basso, quindi selezionare l'opzione Riduzione query.

Sono disponibili le seguenti opzioni di riduzione delle query:

• Riduci numero di query inviate: per impostazione predefinita, ogni oggetto visivo interagisce con tutti gli altri oggetti visivi. Selezionando questa casella di controllo si disabilita l'interazione predefinita. È quindi possibile scegliere facoltativamente quali oggetti visivi interagiscono tra loro usando la funzionalità Modifica interazioni.

• Filtri dei dati: per impostazione predefinita, l'opzione Applica immediatamente le modifiche ai filtri dei dati è selezionata. Per forzare gli utenti del report ad applicare manualmente le modifiche ai filtri dei dati, selezionare l'opzione Aggiungi un pulsante Applica a ogni filtro dei dati per applicare le modifiche quando pronto.

• Filtri: per impostazione predefinita, l'opzione Applica immediatamente le modifiche ai filtri di base è selezionata. Per forzare gli utenti del report ad applicare manualmente le modifiche ai filtri, selezionare una delle opzioni alternative:

  • Aggiungi un pulsante Applica a tutti i filtri di base per applicare le modifiche quando pronto

  • Aggiungi un singolo pulsante Applica al riquadro filtri per applicare le modifiche contemporaneamente (anteprima)