Il tempo per i report in Excel sta rapidamente svanendo: la tendenza verso strumenti intuitivi per la presentazione e l'analisi delle informazioni è evidente in tutti i settori. Abbiamo da tempo discusso internamente della digitalizzazione nella creazione dei report e abbiamo optato per il sistema di visualizzazione e analisi self-service Tableau. Alexander Bezugly, responsabile del dipartimento soluzioni analitiche e reportistica del Gruppo 'M.Video-Eldorado', ha condiviso la sua esperienza e i risultati ottenuti nella creazione di un dashboard operativo.
Dico subito che non tutto ciò che era previsto è stato realizzato, ma l'esperienza è stata interessante e spero che sia utile anche per voi. E se qualcuno ha idee su come si potesse fare meglio, sarei molto grato per consigli e suggerimenti.
Di seguito, discuteremo delle sfide affrontate e delle scoperte fatte.
Da dove siamo partiti
In 'M.Video-Eldorado' esiste un modello di dati ben strutturato: informazioni organizzate con la necessaria profondità di archiviazione e un'infinità di report di forma fissa (vedi dettagli ). Da questi, gli analisti creano pivot table o mailing formattate in Excel, oppure presentazioni accattivanti in PowerPoint per gli utenti finali.
Circa due anni fa, invece dei report in formato fisso, abbiamo iniziato a creare report analitici in SAP Analysis (un supplemento di Excel, fondamentalmente una tabella pivot sopra un motore OLAP). Tuttavia, questo strumento non è riuscito a soddisfare le esigenze di tutti gli utenti, e la maggior parte ha continuato a utilizzare informazioni ulteriormente elaborate dagli analisti.
I nostri utenti finali si suddividono in tre categorie:
Top management. Richiedono informazioni presentate in modo chiaro e comprensibile.
Middle management, utenti avanzati. Sono interessati all'analisi dei dati e sono in grado di creare report autonomamente quando dispongono degli strumenti. Sono diventati gli utenti chiave dei report analitici in SAP Analysis.
Utenti di massa. Non sono interessati all'analisi autonoma dei dati, utilizzano report con un grado limitato di libertà, in formato di newsletter e tabelle pivot in Excel.
La nostra idea era coprire le esigenze di tutti gli utenti e fornire loro uno strumento unico e conveniente. Abbiamo deciso di iniziare con il top management. Avevano bisogno di pannelli pratici per analizzare i principali risultati aziendali. Così, abbiamo avviato Tableau e inizialmente abbiamo scelto due aree: le vendite al dettaglio e online con una profondità e ampiezza di analisi limitate, in grado di coprire circa l'80% dei dati richiesti dal top management.
Poiché gli utenti dei cruscotti erano il top management, è emersa un'ulteriore KPI del prodotto: la velocità di risposta. Nessuno aspetterà 20-30 secondi perché i dati si aggiornino. La navigazione doveva rimanere entro i 4-5 secondi, o meglio ancora, essere immediata. Purtroppo, non siamo riusciti a raggiungere questo obiettivo.
Ecco come si presentava il layout del nostro cruscotto principale:
L'idea chiave era quella di unire i principali driver KPI, che alla fine sono stati 19, a sinistra e rappresentare la loro dinamica e suddivisione per i principali attributi a destra. L'operazione sembra semplice, la visualizzazione logica e comprensibile, finché non ci si immerge nei dettagli.
Dettaglio 1. Volume dei dati
La tabella principale delle vendite annuali contiene circa 300 milioni di righe. Poiché è necessario mostrare anche la dinamica rispetto all'anno scorso e a quello precedente, il volume dei dati relativi alle vendite effettive è di circa 1 miliardo di righe. Inoltre, sono memorizzate separatamente le informazioni sui dati pianificati e sul blocco delle vendite online. Quindi, nonostante abbiamo utilizzato un DB in-memory a colonne SAP HANA, la velocità della query per recuperare tutti gli indicatori di una settimana dai magazzini attuali in tempo reale era di circa 15-20 secondi. La soluzione a questo problema si propone da sola: una materializzazione aggiuntiva dei dati. Tuttavia, anche questa presenta delle insidie, di cui parleremo dopo.
Dettaglio 2. Indicatori non additivi
Molti dei nostri KPI sono legati al numero di scontrini. Questo indicatore rappresenta il COUNT DISTINCT del numero di righe (testate degli scontrini) e mostra somme diverse a seconda degli attributi selezionati. Per esempio, come questo indicatore e quelli derivati da esso dovrebbero essere calcolati:
Per garantire l'accuratezza dei calcoli, è possibile:
- Eseguire il calcolo di indicatori simili in tempo reale nel magazzino;
- Effettuare il calcolo su tutta la volumetria dei dati in Tableau, ovvero, su richiesta in Tableau restituire tutti i dati in base ai filtri selezionati con granularità delle posizioni dei ricevute;
- Creare una vista materializzata in cui saranno calcolati tutti gli indicatori in tutte le varianti di campionamento che forniscono risultati non additivi diversi.
Chiaramente, nell'esempio UTE1 e UTE2 sono attributi del materiale che rappresentano la gerarchia dei prodotti. Non è una cosa statica; attraverso di essa avviene la gestione all'interno dell'azienda, poiché diversi manager sono responsabili di diversi gruppi di prodotto. Abbiamo effettuato molte revisioni globali di questa gerarchia, in cui sono stati modificati tutti i livelli, rivedendo le relazioni, così come cambiamenti puntuali costanti, quando un gruppo passa da un nodo all'altro. Nella reportistica ordinaria, tutto ciò viene calcolato al volo dagli attributi del materiale; nel caso di materializzazione di questi dati, è necessario sviluppare un meccanismo per monitorare tali cambiamenti e ricaricare automaticamente i dati storici. Un compito piuttosto non triviale.
Dettaglio 3. Confronto dei dati
Questo punto è simile al precedente. La sostanza è che, durante l'analisi in azienda, si tende a creare diversi livelli di confronto con il periodo precedente:
Confronto con il periodo precedente (giorno per giorno, settimana per settimana, mese per mese)
In questo confronto si presuppone che, a seconda del periodo selezionato dall'utente (ad esempio, la 33esima settimana dell'anno), dobbiamo mostrare la dinamica rispetto alla 32esima settimana; se avessimo scelto i dati di un mese, ad esempio maggio, questo confronto mostrerebbe la dinamica rispetto ad aprile.
Confronto con l'anno precedente
Qui il punto principale è che, quando confronti i giorni e le settimane, non prendi lo stesso giorno dell'anno scorso, ossia non puoi semplicemente sottrarre uno dall'anno corrente. Devi considerare il giorno della settimana che stai confrontando. Al contrario, quando si confrontano i mesi, è necessario prendere esattamente lo stesso giorno del mese dell'anno scorso. Ci sono anche aspetti specifici riguardanti gli anni bisestili. Negli archivi originali, tutte le informazioni sono distribuite per giorni, non ci sono campi separati per settimane, mesi o anni. Pertanto, per ottenere un'analisi completa nel pannello, è necessario calcolare non un solo periodo, ad esempio una settimana, ma quattro settimane e poi confrontare questi dati, riflettendo dinamiche e deviazioni. Di conseguenza, questa logica di creazione di confronti dinamici può essere implementata sia in Tableau che sul lato del front-end. Sì, e conoscevamo naturalmente questi dettagli e ne abbiamo discusso già nella fase di progettazione, ma era difficile prevedere il loro impatto sulle prestazioni del dashboard finale.
Nell'implementazione del dashboard, abbiamo seguito un lungo percorso Agile. Il nostro obiettivo era fornire il prima possibile uno strumento funzionante con i dati necessari per i test. Pertanto, ci siamo mossi a sprint, concentrandoci sulla minimizzazione del lavoro sul sistema di archiviazione esistente.
Parte 1. Fiducia in Tableau
Per semplificare il supporto IT e accelerare l'implementazione delle modifiche, abbiamo deciso di gestire la logica di calcolo degli indicatori non additivi e il confronto dei periodi passati in Tableau.
Fase 1. Tutto in Live, nessun adeguamento delle vetrine.
In questa fase, abbiamo collegato Tableau alle vetrine esistenti e abbiamo deciso di vedere come sarebbe stato calcolato il numero di ricevute in un anno.
Risultato:
La risposta è stata deludente: 20 minuti. Trasferimento dei dati in rete, alta sovraccarico su Tableau. Abbiamo capito che la logica degli indicatori non additivi doveva essere implementata su HANA. Questo non ci ha spaventati, poiché avevamo già esperienza con BO e Analysis e sapevamo costruire vetrine veloci in HANA che forniscono correttamente gli indicatori non additivi. Ora rimaneva solo da adattarli a Tableau.
Fase 2. Ottimizziamo le vetrine, nessuna materializzazione, tutto al volo.
Abbiamo creato una nuova vetrina separata che generava al volo i dati richiesti per TABLEAU. In generale, abbiamo ottenuto un buon risultato, riducendo il tempo di generazione di tutte le metriche da una settimana a 9-10 secondi. Ci aspettavamo onestamente che in Tableau il tempo di risposta del dashboard sarebbe stato di 20-30 secondi al primo accesso e poi, grazie alla cache, tra 10 e 12 secondi, il che ci avrebbe soddisfatti.
Risultato:
Primo accesso ai dashboard: 4-5 minuti
Qualsiasi clic: 3-4 minuti
Nessuno si aspettava un tale aumento delle prestazioni della vetrina.
Parte 2. Immersione in Tableau
Fase 1. Analisi delle prestazioni di Tableau e ottimizzazione rapida
Abbiamo iniziato ad analizzare a cosa Tableau dedicava gran parte del tempo. A questo scopo, esistono strumenti piuttosto buoni, il che è sicuramente un vantaggio di Tableau. Il principale problema che abbiamo riscontrato erano le query SQL molto complesse generate da Tableau. Queste erano principalmente legate a:
— trasposizione dei dati. Poiché Tableau non ha strumenti per la trasposizione dei dataset, per costruire la parte sinistra del dashboard con una rappresentazione dettagliata di tutti gli KPI, abbiamo dovuto formulare una tabella tramite case. La dimensione delle query SQL nel database raggiungeva i 120.000 caratteri.
— scelta del periodo di tempo. Tale richiesta a livello di database richiedeva più tempo per la compilazione che per l'esecuzione:
Cioè, l'elaborazione della richiesta 12 secondi + 5 secondi di esecuzione.
Abbiamo deciso di semplificare la logica dei calcoli sul lato di Tableau e spostare un'altra parte dei calcoli nel livello del database. Questo ha portato buoni risultati.
Inizialmente abbiamo effettuato la trasposizione al volo, realizzandola mediante un full outer join nell'ultima fase di calcolo della VIEW, secondo questo approccio descritto su wiki e .
Cioè, abbiamo creato una tabella di configurazione – una matrice di trasposizione (21x21) e abbiamo ottenuto tutti gli indicatori in modo dettagliato per riga.
Era:
Risultato:
La trasposizione del database richiede quasi zero tempo. La query per tutti gli indicatori della settimana continuava a essere eseguita in circa 10 secondi. Tuttavia, si è persa la flessibilità nella costruzione del dashboard per indicatori specifici, cioè, per la parte destra del dashboard dove è mostrata la dinamica e la suddivisione dettagliata di un indicatore specifico, la vista funzionava prima in 1-3 secondi, poiché la query riguardava un solo indicatore, ma ora il database seleziona sempre tutti gli indicatori e filtra il risultato prima di restituirlo a Tableau.
Di conseguenza, la velocità di lavoro del dashboard è diminuita di quasi 3 volte.
Risultato:
- 5 sec — parsing del dashboard, visualizzazioni
- 15-20 sec — preparazione alla compilazione delle query con esecuzione dei calcoli preliminari in Tableau
- 35-45 sec — compilazione delle query SQL e loro esecuzione sequenziale in Hana
- 5 sec — elaborazione dei risultati, ordinamento, ricalcolo delle visualizzazioni in Tableau
- Certamente, tali risultati non soddisfacevano il business, e abbiamo continuato l'ottimizzazione.
Fase 2. Minima logica in Tableau, completa materializzazione
Sapevamo che costruire un dashboard con tempi di risposta di pochi secondi su una vetrina che funziona in 10 secondi fosse impossibile, e abbiamo valutato opzioni per materializzare i dati sul lato del database specificamente per il dashboard richiesto. Tuttavia, ci siamo imbattuti in un problema globale, come descritto sopra: indicatori non aggiuntivi. Non siamo riusciti a fare in modo che, al cambiamento dei filtri o delle espansioni, Tableau commutasse in modo flessibile tra le diverse vetrine e livelli, precalcolati per diverse gerarchie di prodotto (nel esempio tre query senza UTE, con UTE1 e UTE2 producono risultati diversi). Pertanto, abbiamo deciso di semplificare il dashboard, rinunciando alla gerarchia di prodotti e verificando quanto potesse essere veloce nella versione semplificata.
Così, in quest'ultima fase abbiamo creato un deposito separato, dove abbiamo collocato in forma trasposta tutti gli KPI. Sul lato del database, qualsiasi query a tale deposito viene eseguita in 0,1 – 0,3 secondi. Nel dashboard abbiamo ottenuto i seguenti risultati:
Prima apertura: 8-10 secondi
Qualsiasi clic: 6-7 secondi
Il tempo che impiega Tableau è composto da:
- 0,3 sec. — parsing del dashboard e compilazione delle query SQL
- 1,5-3 sec. — esecuzione di query SQL in Hana per le principali visualizzazioni (eseguito in parallelo con il p.1)
- 1,5-2 sec. — rendering, ricalcolo delle visualizzazioni
- 1,3 sec. — esecuzione di query SQL aggiuntive per ottenere valori rilevanti dei filtri (Brand, Divisione, Città, Negozio), parsing dei risultati
In breve
Ci è piaciuto lo strumento Tableau per la visualizzazione. Durante la fase di progettazione, abbiamo esaminato diverse componenti di visualizzazione e le abbiamo trovate tutte nelle librerie, comprese complesse segmentazioni multilivello e waterfall multi-driver.
Implementando dashboard con indicatori di vendita principali, abbiamo riscontrato difficoltà nelle prestazioni che finora non siamo riusciti a superare. Abbiamo impiegato oltre due mesi e ottenuto una dashboard funzionalmente incompleta, la cui velocità di risposta è al limite del tollerabile. E abbiamo tratto le seguenti conclusioni:
- Tableau non gestisce grandi volumi di dati. Se nel modello di dati sorgente hai più di 10 GB di dati (circa 200 milioni x 50 righe), il dashboard rallenta notevolmente – da 10 secondi a diversi minuti per ogni clic. Abbiamo sperimentato sia con il live-connect che con l'estrazione. La velocità di lavoro è simile.
- Limitazione nell'uso di più archivi (dataset). Non è possibile specificare la relazione tra dataset con strumenti standard. Se si utilizzano soluzioni alternative per connettere i dataset, questo avrà un forte impatto sulle prestazioni. Nel nostro caso, abbiamo considerato la possibilità di materializzare i dati in ogni vista necessaria e su questi dataset materializzati effettuare il passaggio mantenendo i filtri precedentemente selezionati – questo si è rivelato impossibile da realizzare in Tableau.
- In Tableau non è possibile creare parametri dinamici. Non puoi utilizzare un parametro, che viene utilizzato per filtrare un dataset nell'estrazione o tramite live-connect, per riempire il risultato di un'altra selezione dal dataset o il risultato di un'altra query SQL, solo input nativo dell'utente o una costante.
- Limitazioni relative alla creazione di dashboard con elementi OLAP|Tabella pivot.
In MSTR, SAP SAC, SAP Analysis, quando aggiungi un dataset al report, tutti gli oggetti su di esso sono collegati tra loro per impostazione predefinita. In Tableau questo non avviene, la connessione deve essere configurata manualmente. Questo è probabilmente più flessibile, ma per tutte le nostre dashboard è un requisito fondamentale per gli elementi – quindi comporta costi aggiuntivi. Inoltre, se crei filtri collegati, ad esempio per limitare l'elenco delle città solo a quelle di una determinata regione durante il filtraggio, ti ritrovi immediatamente con richieste sequenziali al database o all'estratto, il che rallenta notevolmente la dashboard. - Limitazioni delle funzionalità. Non è possibile effettuare trasformazioni di massa sia sull'estratto che sul dataset di Live-connecta. Questo può essere fatto tramite Tableau Prep, ma comporta ulteriori costi di lavoro e un altro strumento da studiare e mantenere. Per esempio, non puoi trasporre dati o fare un join su se stessi. Questo viene limitato da trasformazioni su singole colonne o campi, che devono essere selezionati tramite case o if, il che genera query SQL molto complesse, in cui il database spende la maggior parte del tempo a compilare il testo della query. Queste rigidità dello strumento sono state risolte a livello di vetrina, il che porta a una maggiore complessità del magazzino, a carichi e trasformazioni aggiuntive.
Non abbiamo rinunciato a Tableau. Tuttavia, non lo consideriamo come uno strumento in grado di costruire dashboard industriali e come un mezzo attraverso il quale poter sostituire e digitalizzare l'intero sistema di reportistica aziendale.
Attualmente stiamo sviluppando un dashboard simile con un altro strumento e, parallelamente, stiamo cercando di rivedere l'architettura del dashboard in Tableau per semplificarla ulteriormente. Se alla comunità interessa, condivideremo i risultati.
Siamo anche in attesa delle vostre idee o suggerimenti su come creare dashboard veloci in Tableau su volumi così grandi di dati, poiché abbiamo anche un sito con molte più informazioni rispetto al settore retail.
Fonte: habr.com
