Il tempo della rendicontazione in Excel sta rapidamente svanendo: la tendenza verso strumenti comodi per la presentazione e l'analisi delle informazioni è evidente in tutti i settori. Abbiamo discusso a lungo all'interno della digitalizzazione della costruzione di rendiconti e abbiamo scelto il sistema di visualizzazione e analisi self-service Tableau. Alexander Bezuglyj, responsabile del dipartimento di soluzioni analitiche e rendiconti del gruppo 'M.Video-Eldorado', ha parlato delle esperienze e dei risultati della costruzione di un dashboard operativo.
Dirò subito che non tutto ciò che era stato progettato è stato realizzato, ma l'esperienza è stata interessante, spero sia utile anche a voi. E se qualcuno ha idee su come si potrebbe fare meglio, sarei molto grato per consigli e suggerimenti.
Di seguito parleremo di ciò con cui ci siamo confrontati e di ciò che abbiamo appreso.
Da dove siamo partiti
In 'M.Video-Eldorado' c'è un modello di dati ben sviluppato: informazioni strutturate con la profondità di memorizzazione richiesta e un'enorme quantità di report in formato fisso (vedi più dettagli ). Da essi gli analisti creano tabelle pivot o invii formattati in Excel, oppure belle presentazioni in PowerPoint per gli utenti finali.
Circa due anni fa, invece di report in formato fisso, abbiamo iniziato a creare report analitici in SAP Analysis (un componente aggiuntivo per Excel, in sostanza - una tabella pivot sopra un motore OLAP). Ma questo strumento non è riuscito a soddisfare le esigenze di tutti gli utenti, la maggior parte ha continuato a utilizzare informazioni ulteriormente elaborate dagli analisti.
I nostri utenti finali sono suddivisi in tre categorie:
Top management. Richiede informazioni in un formato chiaramente presentato e facilmente comprensibile.
Middle management, utenti avanzati. Sono interessati a esplorare i dati e sono capaci di generare 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 limitata libertà, in formato di invii e tabelle pivot in Excel.
La nostra idea era di soddisfare le esigenze di tutti gli utenti e fornire loro uno strumento unico e comodo. Abbiamo deciso di iniziare con il top management, che richiedeva panneli intuitivi per l'analisi dei principali risultati aziendali. Così, abbiamo avviato con Tableau e inizialmente abbiamo scelto due direzioni: i risultati delle vendite al dettaglio e online, con una profonda e ampia analisi limitata, che coprisse circa l'80% dei dati richiesti dal top management.
Poiché gli utenti dei cruscotti erano il top management, è emerso un ulteriore KPI aggiuntivo per il prodotto: la velocità di risposta. Nessuno aspetterà 20-30 secondi affinché i dati si aggiornino. La navigazione doveva rientrare in 4-5 secondi, e sarebbe stato meglio se fosse stata immediata. Sfortunatamente, non siamo riusciti a raggiungere questo obiettivo.
Ecco come appariva il layout del nostro cruscotto principale:
L'idea chiave era di unire i principali driver KPI, che alla fine sono diventati 19, a sinistra e di mostrare la loro dinamica e segmentazione per i principali attributi a destra. Sembrerebbe un compito semplice, la visualizzazione è logica e comprensibile, finché non si entra nei dettagli.
Dettaglio 1. Volume dei dati
La tabella principale delle vendite per l'anno contiene circa 300 milioni di righe. Poiché è necessario riflettere anche la dinamica rispetto all'anno scorso e a quello prima, il volume dei dati solamente per le vendite effettive è di circa 1 miliardo di righe. Inoltre, vengono memorizzate separatamente le informazioni sui dati pianificati e sul blocco delle vendite online. Pertanto, anche se abbiamo utilizzato un DB in-memory a colonne SAP HANA, la velocità di esecuzione della query per selezionare tutti i parametri per una settimana dalle attuali memorie in tempo reale era di circa 15-20 secondi. La soluzione a questo problema sembra quasi ovvia: una materializzazione aggiuntiva dei dati. Ma ci sono anche delle insidie, di cui parleremo più avanti.
Dettaglio 2. KPI non additivi
Molti dei nostri KPI sono legati al numero di scontrini. Questo indicatore rappresenta il COUNT DISTINCT del numero di righe (intestazioni degli scontrini) e mostra somme diverse a seconda degli attributi selezionati. Per esempio, come deve essere calcolato questo indicatore e i derivati:
Per la correttezza dei calcoli, è possibile:
- Effettuare il calcolo di tali indicatori in tempo reale nel deposito;
- Eseguire il calcolo su tutto il volume dei dati in Tableau, ad es. a richiesta in Tableau restituire tutti i dati in base ai filtri selezionati nella granularità delle righe degli scontrini;
- Creare una vetrina materializzata in cui saranno calcolati tutti gli indicatori in tutte le varianti di campionamento, dando risultati non additivi diversi.
È chiaro che negli esempi UTE1 e UTE2 ci sono attributi del materiale che rappresentano la gerarchia dei prodotti. Non è una cosa statica, poiché attraverso di essa avviene la gestione all'interno dell'azienda, dato che diversi manager sono responsabili per diversi gruppi di prodotti. Abbiamo avuto molti rivedimenti globali di questa gerarchia, quando sono stati cambiati tutti i livelli, quando sono state riviste le interrelazioni, così come modifiche puntuali continuative, quando un gruppo passa da un nodo all'altro. Nella reportistica normale tutto ciò viene calcolato al volo dagli attributi del materiale; in caso di materializzazione di questi dati, è necessario sviluppare un meccanismo di tracciamento di tali modifiche e di ricarica automatica dei dati storici. Un compito piuttosto non triviale.
Dettaglio 3. Confronto dei dati
Questo punto è simile al precedente. La sostanza è che in azienda, durante l'analisi, è consuetudine formare 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 presume che, a seconda del periodo selezionato dall'utente (ad esempio, la 33ª settimana dell'anno), dobbiamo mostrare la dinamica rispetto alla 32ª settimana; se scegliessimo dati per un mese, ad esempio maggio, questo confronto mostrerebbe la dinamica rispetto ad aprile.
Confronto con l'anno precedente
Qui il punto principale è che, durante il confronto tra giorni e settimane, non si prende lo stesso giorno dell'anno scorso, cioè non si può semplicemente sottrarre uno all'anno corrente. Bisogna considerare il giorno della settimana che si sta confrontando. Ma quando si confrontano i mesi, al contrario, si deve prendere esattamente lo stesso giorno del calendario dell'anno scorso. Ci sono anche peculiarità relative agli anni bisestili. Nei repository 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 considerare non un solo periodo, ad esempio una settimana, ma 4 settimane, e poi confrontare questi dati, riflettendo la dinamica e le deviazioni. Di conseguenza, questa logica di formazione delle comparazioni dinamiche può essere implementata sia in Tableau che dalla parte della vetrina. Sì, e di questi dettagli eravamo chiaramente a conoscenza e avevamo riflettuto già in fase di progettazione, ma prevedere il loro impatto sulle prestazioni del dashboard finale è stato difficile.
Durante l'implementazione del dashboard abbiamo seguito un lungo percorso Agile. Il nostro obiettivo era fornire il prima possibile uno strumento funzionale da testare con i dati necessari. Quindi ci siamo mossi a sprint, puntando alla minimizzazione del lavoro sul repository attuale.
Parte 1. Fede in Tableau
Per semplificare il supporto IT e implementare rapidamente le 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 tempo reale, nessun miglioramento delle vetrine.
In questa fase abbiamo connesso Tableau alle vetrine attuali e abbiamo deciso di controllare come sarebbe stato calcolato il numero di ricevute in un anno.
Risultato:
La risposta è stata deludente: 20 minuti. Trasferimento dei dati sulla rete, alta carica su Tableau. Abbiamo capito che la logica con indicatori non additivi doveva essere implementata su HANA. Questo non ci ha spaventato molto, avevamo già esperienza simile con BO e Analysis e sapevamo come costruire vetrine veloci in HANA che fornivano indicatori non additivi calcolati correttamente. Ora restava solo da adattarli a Tableau.
Fase 2. Ottimizziamo le vetrine, nessuna materializzazione, tutto al volo.
Abbiamo creato una nuova vetrina separata, che generava i dati richiesti per TABLEAU in tempo reale. In generale, abbiamo ottenuto un buon risultato, riducendo il tempo di generazione di tutti gli indicatori a una settimana a 9-10 secondi. E onestamente ci aspettavamo che in Tableau il tempo di risposta del dashboard fosse di 20-30 secondi all'apertura iniziale e successivamente, grazie al caching, di 10-12 secondi, che in generale ci avrebbe soddisfatti.
Risultato:
Primo apertura dei dashboard: 4-5 minuti
Qualsiasi clic: 3-4 minuti
Nessuno si aspettava un tale incremento delle prestazioni della vetrina.
Parte 2. Immersione in Tableau
Fase 1. Analisi delle prestazioni di Tableau e ottimizzazione rapida
Abbiamo iniziato ad analizzare come Tableau spende il suo tempo. E per questo ci sono strumenti piuttosto buoni, il che è senza dubbio un vantaggio di Tableau. Il problema principale che abbiamo identificato sono state le query SQL molto complesse generate da Tableau. Erano principalmente legate a:
— trasposizione dei dati. Poiché Tableau non dispone di strumenti per la trasposizione dei dataset, per costruire la parte sinistra del dashboard con una rappresentazione dettagliata di tutti i KPI, abbiamo dovuto generare una tabella tramite la clausola case. Le dimensioni delle query SQL nel database raggiungevano i 120.000 caratteri.
— selezione del periodo di tempo. Tale query a livello di database richiedeva più tempo per la compilazione che per l'esecuzione:
Cioè, l'elaborazione della query richiedeva 12 secondi + 5 secondi per l'esecuzione.
Abbiamo deciso di semplificare la logica dei calcoli lato Tableau e trasferire un ulteriore insieme di calcoli sulla vetrina e sul livello del database. Questo ha portato a buoni risultati.
Inizialmente abbiamo effettuato la trasposizione in tempo reale, realizzandola tramite un full outer join nella fase finale di calcolo della VIEW, secondo l'approccio descritto su wiki e .
Cioè, abbiamo creato una tabella di configurazione – una matrice di trasposizione (21x21) e abbiamo ottenuto tutti gli indicatori in una ripartizione riga per riga.
Era:
Diventato:
La transposizione del database richiede quasi nessun tempo. La query per tutti gli indicatori della settimana è stata eseguita in circa 10 secondi. Tuttavia, si è persa la flessibilità nella costruzione del dashboard per un indicatore specifico, cioè per la parte destra del dashboard dove è presentata la dinamica e la suddivisione dettagliata di un indicatore specifico; prima il display veniva elaborato in 1-3 secondi, poiché la query riguardava un solo indicatore, mentre 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 quasi di 3 volte.
Risultato:
- 5 sec — parsing del dashboard, visualizzazioni
- 15-20 sec — preparazione alla compilazione delle query con l'esecuzione dei preliminari in Tableau
- 35-45 sec — compilazione delle query SQL e loro esecuzione in modo parallelo-sequenziale in Hana
- 5 sec — elaborazione dei risultati, ordinamento, ricalcolo delle visualizzazioni in Tableau
- Naturalmente, tali risultati non soddisfacevano il business, e abbiamo continuato l'ottimizzazione.
Fase 2. Minimo di logica in Tableau, completa materializzazione
Capivamo che costruire un dashboard con un tempo di risposta di pochi secondi su un display che impiega 10 secondi era impossibile e stavamo considerando opzioni di materializzazione dei dati sul lato del database specificamente per il dashboard richiesto. Tuttavia, ci siamo imbattuti in un problema globale, descritto sopra: indicatori non additivi. Non siamo riusciti a fare in modo che, al cambiare dei filtri o delle espansioni, Tableau si commutasse in modo flessibile tra diversi display e livelli, pre-calcolati per diverse gerarchie di prodotto (nell'esempio, le tre query senza UTE, con UTE1 e UTE2 producono risultati diversi). Pertanto, abbiamo deciso di semplificare il dashboard, rinunciando alla gerarchia del prodotto nel dashboard e di vedere quanto veloce potesse essere nella versione semplificata.
Quindi, in quest'ultima fase, abbiamo creato un deposito separato, in cui abbiamo collocato in forma trasposta tutti i KPI. Sul lato del database, qualsiasi query a tale deposito è elaborata 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 delle query SQL in Hana per le visualizzazioni principali (eseguito parallelamente al punto 1)
- 1,5-2 secondi — rendering, ricalcolo delle visualizzazioni
- 1,3 secondi — esecuzione di query SQL aggiuntive per ottenere valori pertinenti dei filtri (Marca, Divisione, Città, Negozio), parsing dei risultati
Se dobbiamo fare un breve riassunto
Ci è piaciuto lo strumento Tableau dal punto di vista della visualizzazione. Nella fase di progettazione abbiamo considerato diversi elementi di visualizzazione e li abbiamo trovati tutti nelle librerie, comprese segmentazioni complesse multistrato e waterfall multi-driver.
Nell'implementare cruscotti con indicatori chiave di vendita, abbiamo incontrato difficoltà di prestazioni che non siamo riusciti a superare. Abbiamo impiegato più di due mesi e ottenuto un cruscotto funzionalmente incompleto, la cui velocità di risposta è ai limiti dell'accettabile. E per noi abbiamo tratto conclusioni:
- Tableau non riesce a gestire grandi volumi di dati. Se nel modello di dati di origine hai più di 10 GB di dati (circa 200 milioni x 50 righe), il cruscotto si 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 esecuzione è comparabile.
- Limitazioni nell'uso di più archivi (dataset). Non è possibile specificare relazioni tra dataset con strumenti standard. Se si utilizzano soluzioni alternative per collegare i dataset, questo influirà notevolmente sulle prestazioni. Nel nostro caso, abbiamo considerato la possibilità di materializzare i dati in ogni taglio necessario delle visualizzazioni e su questi dataset materializzati effettuare cambiamenti mantenendo i filtri precedentemente selezionati — questo si è rivelato impossibile da realizzare in Tableau.
- In Tableau non è possibile creare parametri dinamici. Non puoi riempire un parametro, che viene utilizzato per filtrare un dataset nell'estrazione o durante il live-connect, con il risultato di un'altra selezione dal dataset o il risultato di un'altra query SQL, solo con l'input nativo dell'utente o una costante.
- Limitazioni legate alla costruzione del cruscotto con elementi OLAP|Tabella pivot.
In MSTR, SAP SAC, SAP Analysis, se aggiungi un dataset al report, tutti gli oggetti su di esso sono collegati l'uno all'altro per impostazione predefinita. In Tableau questo non accade, la connessione deve essere configurata manualmente. Questo è probabilmente più flessibile, ma per tutti i nostri dashboard è un requisito essenziale per gli elementi, quindi comporta costi aggiuntivi. Inoltre, se crei filtri collegati, ad esempio, affinché l'elenco delle città sia limitato solo alle città di quella regione durante la filtrazione della regione, ti trovi subito a dover effettuare query sequenziali al DB o all'estratto, il che rallenta notevolmente il dashboard. - Limitazioni nelle funzioni. Sia sull'estratto che tantomeno sul dataset da Live-connecta non si possono eseguire trasformazioni di massa. Questo può essere fatto tramite Tableau Prep, ma comporta costi aggiuntivi e un ulteriore strumento da studiare e mantenere. Ad esempio, non puoi trasporre i dati, unirli con se stessi. Questo si chiude attraverso trasformazioni su singole colonne o campi, che devono essere selezionati tramite case o if, generando query SQL molto complesse, in cui il database dedica la maggior parte del tempo alla compilazione del testo della query. Queste rigidità dello strumento sono state risolte a livello di vetrina, il che porta a una maggiore complessità del magazzino, carichi e trasformazioni aggiuntive.
Non abbiamo chiuso la porta a Tableau. Ma come strumento capace di costruire dashboard industriali e mezzo attraverso il quale è possibile sostituire e digitalizzare l'intero sistema di reporting aziendale, Tableau non viene considerato.
Attualmente stiamo sviluppando attivamente un dashboard analogo su un altro strumento e stiamo parallelamente cercando di rivedere l'architettura del dashboard in Tableau per semplificarla ulteriormente. Se alla comunità interesserà, condivideremo i risultati.
Aspettiamo anche le vostre idee o suggerimenti su come in Tableau si possono costruire dashboard veloci su volumi di dati così grandi, considerando che abbiamo anche il sito, dove i dati sono di gran lunga superiori a quelli del retail.
Fonte: habr.com
