In un precedente articolo, era stata posta la domanda se fosse meglio usare M (Power Query) o DAX (Analysis Services Tabular) per arricchire i dati creando, per esempio, una nuova colonna. La domanda ha implicazioni, in parte, anche filosofiche. Qui, come sempre, cercheremo di restare con i piedi per terra e andare diritto al punto.
La domanda non ha una risposta univoca, tranne che nel caso di modelli dati di piccole dimensioni, cioè comprendenti tabelle dei fatti che non eccedano qualche centinaia di migliaia di righe.
Vediamo qualche punto di riflessione riguardo l’interrogativo posto.
- Un colonna calcolata creata in DAX occupa più RAM di una creata con M. La ragione è che, creandola in DAX, non si sfrutta l’algoritmo di compressione per quella colonna, essendo essa creata dopo che la compressione è stata già applicata al modello in fase di importazione. Tuttavia, creandola in M, si risparmierà RAM per quella colonna ma, solitamente, a spese delle altre perché la creazione di una nuova colonna in M, spesso, modifica l’ordine di compressione delle colonne native. Il risultato è che, in generale, le dimensioni complessive del modello dati sono molto simili nei due casi.
- La creazione e modifica del codice della colonna, se creata in DAX, non richiede refresh dell’intera tabella su cui è creata, mentre creandola e modificandola in M si dovrà poi aspettare il refresh di tutta la tabella. Questo può fortemente rallentare lo sviluppo, quando il modello è di dimensioni considerevoli. Da questo punto di vista, DAX è vantaggioso.
- In generale è consigliato creare colonne e tabelle il più possibile vicino alla sorgente dati, qui per una ragione anche filosofica. Rimanendo sul pratico, il codice M può essere centralizzato sul cloud in un Dataflow e dunque riutilizzato in modo piuttosto semplice. Per ottenere la stessa cosa in DAX bisogna creare un Dataset e connettersi ad esso in live connection con un report, perdendo la possibilità di creare altre colonne calcolate, a meno di creare un modello in Direct Query sul Dataset Analysis Services, il che può essere complesso, ha varie limitazioni e offre prestazioni un po’ degradate. Inoltre, la funzionalità è ancora, ad oggi, in preview e dunque non va usata in produzione.
- Alcune colonne sono semplicissime in DAX e complesse in M. Per altre, vale l’opposto. Per esempio, M offre funzionalità che, con un click, permettono calcoli molto complessi dal punto di vista temporale, piuttosto difficili da scrivere in DAX. D’altro canto, l’uso di join in Power Query per generare scenari può essere più complesso e lento che in DAX. Dunque, questo è, nella maggior parte dei casi, il vero interrogativo chiave: dove è più semplice scrivere il codice della colonna?
Conclusioni
Se il modello dati è di dimensioni contenute, come è nella maggior parte dei casi in Italia, la decisione va presa solo sulla base della difficoltà di scrittura del codice, punto 4 sopra riportato.
Se il modello, al contrario, fosse di dimensioni considerevoli, andrebbero anche ponderati i punti 2 e 3 sopra riportati per prendere la migliore decisione: il punto 2 suggerisce di usare DAX, il punto 3 di usare M.
Va notato che il particolare modello in uso, specialmente se di grandi dimensioni, può mostrare aspetti che portano a propendere per una delle due soluzioni che sono talmente specifici da non rientrare in questo articolo che vuole dare delle linee guida generali.
Si consiglia di non farsi influenzare da considerazioni filosofiche al riguardo (per esempio la buona prassi di creare colonne e tabelle il più possibile vicino alla sorgente, a meno dell’uso di Dataflow), ma di puntare diritto alla produttività della progettazione.
Infine, una considerazione naif: sappiamo bene che creare colonne calcolate in DAX è molto più cool che farlo in M, ma, nuovamente, non dobbiamo essere (soltanto) cool ma (soprattutto) efficienti ed efficaci!
Autore del Post
