Power BI: la gestione del refresh dei dati ai fini della reportistica

Luca – il nostro consulente immaginario – ha elaborato una strategia precisa per la promozione dei nuovi servizi che il suo studio vuole offrire tramite Power BI.

Luca ha già creato una reportistica interna allo studio come primo test, si sente pronto ad affrontare un vero caso pratico con dati esterni al suo studio. Deve, però chiarire un ultimo dettaglio, prima di procedere con la Newsletter ai suoi clienti per cercare id iniziare un primo progetto verso un cliente.

Data Warehouse (DWH) e reportistica di BI

Il dettaglio è il seguente: il suo tecnico IT gli ha chiarito casi aggiuntivi in cui un Data Warehouse (DWH) serve a rendere possibile la reportistica di BI, rispetto a quelli elencati nell’articolo “Power BI: sveliamo il mistero del Data Warehouse”, che abbiamo raccolto in questo ultimo articolo.

Il tutto è stato originato dalla consapevolezza che, a volte l’IT del cliente non permette, magari perché la casa madre del gestionale non lo permette, di collegarsi al database sottostante il gestionale, che altre volte non è possibile farlo per qualche ragione di politiche del dipartimento IT indipendenti dalla casa madre del gestionale/database e che, infine, a volte i dati non sono su un database.

I casi in cui si deve ricorrere al Data WareHouse (DWH), dagli appunti, sono diversi:

• quando la struttura del database sottostante il gestionale (a cui si possa accedere) non ha la struttura adatta all’analisi dei dati;
   
• quando il database sottostante al gestionale (a cui si possa accedere) non va disturbato (decisione di politica IT);
   
• e quando non è considerato vantaggioso avere dati che cambiano ad ogni refresh ma si preferisca avere un aggiornamento lento (per esempio una volta al giorno, poi i dati restano fissi fino all’indomani)

Nel discutere, dopo la lettura degli appunti, con l’informatico sono emersi altri casi:

• Quando ci sono più database sotto il gestionale o ci sono più gestionali ognuno con uno o più database e si voglia avere un punto unico di accesso ai dati per l’analisi in BI;
   
• Quando un unico gestionale non espone il database sottostante per decisione della casa madre

Nel chiudere la telefonata, Luca rimane spiazzato dall’ultima frase dell’informatico:

“Se userai un DWH, attenzione all’orario in cui si chiede a Power BI di fare refresh dei dati dal cloud, a quell’ora deve essere finito il refresh del DWH”

Due refresh? Ma non era soltanto Power BI Cloud a dovere fare refresh? Eccoci a svelare l’arcano!

Una figura aiuterà.

Nell’ipotesi di usare un Data Ware House, la situazione diventa la seguente:

• per prima cosa, i dati devono essere prelevati, in certi momenti della giornata, dai vari database presenti in azienda sotto uno o più gestionali per essere inseriti dentro il DWH. Di questo si occupa chi sviluppa il DWH;
   
• una volta completato questo passo, e solo una volta completato questo passo, Power BI potrà fare refresh dal cloud per aggiornare i suoi dati prelevandoli dal DWH e soltanto da lì. La sorgente di Power BI diventa, infatti, il DWH. A sua volta, il DWH ha come sorgenti i vari database dell’azienda.

Dunque, pensa Luca, l’uso del DWH pone una sfida in più: bisogna coordinare i refresh.

Infatti, se Power BI iniziasse ad aggiornare i dati dal cloud prima che il DWH abbia finito il suo refresh (o addirittura prima che lo abbia iniziato), i dati che verrebbero caricati sul cloud di Power BI non sarebbero aggiornati, perché il DWH presenterebbe ancora i dati del refresh precedente.

Luca trova la cosa, in prima istanza scomoda. Non sarebbe più facile leggere direttamente dai database?

Poi ci riflette e si rende conto del fatto che:

• facendo così, i dati andrebbero omogeneizzati. Infatti, chi gli garantisce che i dati del gestionale A, tenuto nel database DB/A, siano comparabili con quelli del gestionale B, tenuti nel database DB/B?
  Per esempio, nel database DB/A i dati potrebbero essere in cicli per minuto, nell’altro in cicli per ora. Invece, pensa, chi costruisce il DWH si preoccuperà anche di rendere i dati omogenei;
   
• inoltre, avere una sola sorgente appare comodo. Una sola connessione, un unico punto di prelievo dei dati.

Luca è sorpreso, alla fine l’idea del DWH gli pare molto sensata.

Tuttavia, sa che molti piccoli clienti non l’hanno. Poco male, ormai ha una strategia per qualunque situazione. Sa come collegarsi direttamente ai vari database, nel caso non ci sia un DWH.

Come gestire il refresh in Power Bi?

L’unico punto è: quali sono i metodi per garantire che Power BI cominci il refresh soltanto una volta che il refresh del DWH sia completato?

Ci sono due diversi metodi, con complessità (e affidabilità) crescente:

• settare l’inizio del refresh di Power BI sufficientemente a distanza da quello del DWH, in modo che questa distanza contenga il tempo di refresh del DWH. Si userà un coefficiente di sicurezza per avere margine, in modo puramente empirico;
   
• fare iniziare il refresh di Power BI quando si riceve l’informazione della fine del refresh del DWH.
  Questo può essere fatto con uno script in PowerShell, una soluzione più complessa ma che un tecnico IT può implementare molto facilmente.
  In sostanza, una volta che il DWH abbia finito il refresh, l’informatico fa scattare un evento che lancia l’esecuzione del codice PowerShell, che farà partire il refresh di Power BI al momento giusto.
  A questo punto, non c’è un orario predefinito per il refresh di Power BI (Refresh 2 in figura), questo partirà alla fine del refresh del DWH (Refresh 1 in figura).

Bene, pensa Luca. Adesso siamo veramente pronti. Iniziamo a preparare la Newsletter e vediamo che risposta otteniamo dai clienti!

Ti consigliamo un ottimo, serio, corso per imparare ad usare PowerBI; puoi anche vedere una lezione gratuita, per capire l’impostazione che abbiamo dato, clicca sull’immagine per ulteriori informazioni:

A cura di Francesco Bergamaschi, nella sua pagina trovi tutti gli articoli dedicati al funzionamento di powerBI

Martedì 20 giugno 2023