Tableau nella vendita al dettaglio, davvero?

Il tempo per i report in Excel sta rapidamente scomparendo: la tendenza verso strumenti convenienti per presentare e analizzare le informazioni è visibile in tutti i settori. Da tempo discutiamo internamente della digitalizzazione del reporting e abbiamo scelto il sistema di visualizzazione e analisi self-service di Tableau. Alexander Bezugly, capo del dipartimento soluzioni analitiche e reporting del gruppo M.Video-Eldorado, ha parlato dell'esperienza e dei risultati della costruzione di un dashboard di combattimento.

Dico subito che non tutto quello che era stato pianificato si è realizzato, ma l'esperienza è stata interessante, spero possa essere utile anche a te. E se qualcuno ha qualche idea su come si potrebbe fare meglio, sarei molto grato per i vostri consigli e idee.

Sotto il taglio è riportato ciò che abbiamo incontrato e ciò che abbiamo imparato.

Da dove abbiamo iniziato?

M.Video-Eldorado ha un modello dati ben sviluppato: informazioni strutturate con la profondità di archiviazione richiesta e un numero enorme di report in formato fisso (vedi maggiori dettagli questo articolo). Da questi, gli analisti creano tabelle pivot o newsletter formattate in Excel o bellissime presentazioni 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 componente aggiuntivo di Excel, essenzialmente una tabella pivot sul motore OLAP). Ma questo strumento non è stato in grado di soddisfare le esigenze di tutti gli utenti; la maggior parte ha continuato a utilizzare informazioni ulteriormente elaborate dagli analisti.

I nostri utenti finali rientrano in tre categorie:

Alta direzione. Richiede informazioni in modo ben presentato e chiaramente comprensibile.

Gestione intermedia, utenti avanzati. Interessato all'esplorazione dei dati e in grado di creare report in modo indipendente se gli strumenti sono disponibili. Sono diventati gli utenti chiave dei report analitici in SAP Analysis.

Utenti di massa. Non sono interessati ad analizzare i dati in modo indipendente; utilizzano report con un grado di libertà limitato, sotto forma di newsletter e tabelle pivot in Excel.

La nostra idea era quella di coprire le esigenze di tutti gli utenti e fornire loro un unico strumento conveniente. Abbiamo deciso di iniziare dal top management. Avevano bisogno di dashboard facili da usare per analizzare i principali risultati aziendali. Quindi siamo partiti da Tableau e abbiamo scelto innanzitutto due direzioni: indicatori di vendita al dettaglio e online con profondità e ampiezza di analisi limitate, che coprissero circa l’80% dei dati richiesti dal top management.

Poiché gli utenti dei dashboard erano il top management, è apparso un altro KPI aggiuntivo del prodotto: la velocità di risposta. Nessuno aspetterà 20-30 secondi affinché i dati vengano aggiornati. La navigazione avrebbe dovuto essere eseguita entro 4-5 secondi o, meglio ancora, immediatamente. E noi, ahimè, non siamo riusciti a raggiungere questo obiettivo.

Ecco come appariva il layout della nostra dashboard principale:

L’idea chiave è quella di combinare i principali fattori KPI, 19 in totale, sulla sinistra e presentare le loro dinamiche e la suddivisione per attributi principali sulla destra. Il compito sembra semplice, la visualizzazione è logica e comprensibile, finché non ti immergi nei dettagli.

Dettaglio 1. Volume di dati

La nostra tabella principale per le vendite annuali occupa circa 300 milioni di righe. Poiché è necessario riflettere le dinamiche dell'anno scorso e dell'anno precedente, il volume dei dati sulle sole vendite effettive ammonta a circa 1 miliardo di righe. Anche le informazioni sui dati pianificati e sul blocco delle vendite online vengono archiviate separatamente. Pertanto, anche se abbiamo utilizzato il DB in-memory colonnare SAP HANA, la velocità della query con la selezione al volo di tutti gli indicatori per una settimana dall'archivio corrente è stata di circa 15-20 secondi. La soluzione a questo problema suggerisce se stessa: ulteriore materializzazione dei dati. Ma presenta anche delle insidie, di cui parleremo più avanti.

Dettaglio 2. Indicatori non additivi

Molti dei nostri KPI sono legati al numero di ricevute. E questo indicatore rappresenta COUNT DISTINCT del numero di righe (intestazioni di controllo) e mostra importi diversi a seconda degli attributi selezionati. Ad esempio, come dovrebbero essere calcolati questo indicatore e il suo derivato:

Per rendere corretti i calcoli, puoi:

• Calcolare tali indicatori al volo nello spazio di archiviazione;
• Esegui calcoli sull'intero volume di dati in Tableau, ad es. su richiesta in Tableau, fornire tutti i dati secondo i filtri selezionati nella granularità della posizione della ricevuta;
• Creare una vetrina materializzata in cui tutti gli indicatori verranno calcolati in tutte le opzioni campione che forniscono risultati diversi non additivi.

È chiaro che nell'esempio UTE1 e UTE2 sono attributi materiali che rappresentano la gerarchia del prodotto. Questa non è una cosa statica; la gestione all'interno dell'azienda avviene attraverso di essa, perché Diversi manager sono responsabili di diversi gruppi di prodotti. Abbiamo avuto molte revisioni globali di questa gerarchia, quando tutti i livelli sono cambiati, quando le relazioni sono state riviste e i punti costanti sono cambiati, quando un gruppo si è spostato da un nodo a un altro. Nel reporting convenzionale, tutto ciò viene calcolato al volo dagli attributi del materiale; nel caso della materializzazione di questi dati, è necessario sviluppare un meccanismo per tenere traccia di tali cambiamenti e ricaricare automaticamente i dati storici. Un compito davvero non banale.

Dettaglio 3. Confronto dei dati

Questo punto è simile al precedente. La conclusione è che quando si analizza un'azienda, è 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 presuppone che a seconda del periodo selezionato dall'utente (ad esempio la 33a settimana dell'anno), dovremmo mostrare la dinamica entro la 32a settimana; se selezionassimo i dati per un mese, ad esempio, maggio , quindi questo confronto mostrerebbe la dinamica entro aprile.

Confronto con l'anno scorso

La sfumatura principale qui è che quando si confronta per giorno e per settimana, non si prende lo stesso giorno dell'anno scorso, ad es. non puoi semplicemente mettere l'anno corrente meno uno. Devi guardare il giorno della settimana che stai confrontando. Quando si confrontano i mesi, al contrario, è necessario prendere esattamente lo stesso giorno di calendario dell'anno scorso. Ci sono anche sfumature con gli anni bisestili. Nei repository originali, tutte le informazioni sono distribuite per giorno; non ci sono campi separati con settimane, mesi o anni. Pertanto, per ottenere uno spaccato analitico completo nel pannello, è necessario contare non un periodo, ad esempio una settimana, ma 4 settimane, quindi confrontare questi dati, riflettere le dinamiche, le deviazioni. Di conseguenza, questa logica per generare confronti nelle dinamiche può essere implementata anche in Tableau o sul lato del negozio. Sì, e ovviamente conoscevamo e riflettevamo su questi dettagli in fase di progettazione, ma era difficile prevederne l'impatto sulle prestazioni del dashboard finale.

Nell'implementare la dashboard abbiamo seguito il lungo percorso Agile. Il nostro compito era fornire uno strumento di lavoro con i dati necessari per i test nel più breve tempo possibile. Pertanto, abbiamo fatto degli sprint e abbiamo iniziato riducendo al minimo il lavoro sul lato dello storage attuale.

Parte 1: Fede nel Tableau

Per semplificare il supporto IT e implementare rapidamente le modifiche, abbiamo deciso di creare la logica per il calcolo degli indicatori non additivi e il confronto dei periodi passati in Tableau.

Fase 1. Tutto è live, nessuna modifica alla finestra.

A questo punto, abbiamo collegato Tableau ai negozi attuali e abbiamo deciso di vedere come verrebbe calcolato il numero di ricevute per un anno.

Il risultato:

La risposta è stata deprimente: 20 minuti. Trasferimento di dati in rete, carico elevato su Tableau. Ci siamo resi conto che la logica con indicatori non additivi deve essere implementata su HANA. Questo non ci ha spaventato più di tanto, avevamo già esperienze simili con BO e Analisi e sapevamo come costruire vetrine veloci in HANA che producono indicatori non additivi calcolati correttamente. Ora non restava che adattarli a Tableau.

Fase 2. Mettiamo a punto le vetrine, nessuna materializzazione, tutto al volo.

Abbiamo creato una nuova vetrina separata che ha prodotto al volo i dati richiesti per TABLEAU. In generale, abbiamo ottenuto un buon risultato: abbiamo ridotto il tempo per generare tutti gli indicatori in una settimana a 9-10 secondi. E onestamente ci aspettavamo che in Tableau il tempo di risposta della dashboard fosse di 20-30 secondi alla prima apertura e poi a causa della cache da 10 a 12, che in generale ci andrebbe bene.

Il risultato:

Prima dashboard aperta: 4-5 minuti
Qualsiasi clic: 3-4 minuti
Nessuno si aspettava un ulteriore aumento del lavoro del negozio.

Parte 2. Tuffati in Tableau

Fase 1. Analisi delle prestazioni di Tableau e messa a punto rapida

Abbiamo iniziato ad analizzare dove Tableau trascorre la maggior parte del tempo. E ci sono strumenti abbastanza buoni per questo, il che, ovviamente, è un vantaggio di Tableau. Il problema principale che abbiamo identificato riguardava le query SQL molto complesse che Tableau stava creando. Erano principalmente associati a:

— trasposizione dei dati. Poiché Tableau non dispone di strumenti per la trasposizione dei set di dati, per creare il lato sinistro della dashboard con una rappresentazione dettagliata di tutti i KPI, abbiamo dovuto creare una tabella utilizzando un caso. La dimensione delle query SQL nel database ha raggiunto i 120 caratteri.

- scelta del periodo. Una query di questo tipo a livello di database ha richiesto più tempo per la compilazione che per l'esecuzione:

Quelli. elaborazione della richiesta 12 secondi + 5 secondi di esecuzione.

Abbiamo deciso di semplificare la logica di calcolo lato Tableau e spostare un'altra parte dei calcoli a livello di vetrina e database. Ciò ha portato buoni risultati.

Per prima cosa abbiamo effettuato la trasposizione al volo, l'abbiamo fatta tramite un full external join nella fase finale del calcolo di VIEW, secondo questo approccio descritto sul wiki Trasporre -Wikipedia, l'enciclopedia libera и Matrice elementare - Wikipedia, l'enciclopedia libera.

Cioè, abbiamo creato una tabella di impostazione: una matrice di trasposizione (21x21) e abbiamo ricevuto tutti gli indicatori suddivisi riga per riga.

Era:


È diventato:


Quasi nessun tempo viene dedicato alla trasposizione del database stesso. La richiesta per tutti gli indicatori della settimana ha continuato ad essere elaborata in circa 10 secondi. D’altro canto, però, si è persa la flessibilità in termini di costruzione di un dashboard basato su un indicatore specifico, ad es. per il lato destro del cruscotto dove vengono presentate le dinamiche e la ripartizione dettagliata di un indicatore specifico, in precedenza la vetrina funzionava in 1-3 secondi, perché la richiesta era basata su un indicatore e ora il database selezionava sempre tutti gli indicatori e filtrava il risultato prima di restituirlo a Tableau.

Di conseguenza, la velocità del cruscotto è diminuita di quasi 3 volte.

Il risultato:

1. 5 secondi: analisi di dashboard e visualizzazioni
2. 15-20 secondi - preparazione per la compilazione di query con esecuzione di precalcoli in Tableau
3. 35-45 sec - compilazione di query SQL e loro esecuzione sequenziale parallela in Hana
4. 5 secondi: elaborazione dei risultati, ordinamento, ricalcolo delle visualizzazioni in Tableau
5. Naturalmente, tali risultati non erano adatti al business e abbiamo continuato a ottimizzare.

Fase 2. Logica minima in Tableau, materializzazione completa

Abbiamo capito che era impossibile creare un dashboard con un tempo di risposta di diversi secondi su una vetrina che funziona per 10 secondi e abbiamo considerato le opzioni per materializzare i dati sul lato database appositamente per il dashboard richiesto. Ma abbiamo riscontrato un problema globale sopra descritto: gli indicatori non additivi. Non siamo stati in grado di garantire che, quando si modificano filtri o approfondimenti, Tableau passasse in modo flessibile tra diverse vetrine e livelli pre-progettati per diverse gerarchie di prodotti (nell'esempio, tre query senza UTE, con UTE1 e UTE2 generano risultati diversi). Pertanto, abbiamo deciso di semplificare la dashboard, abbandonare la gerarchia dei prodotti nella dashboard e vedere quanto potrebbe essere veloce in una versione semplificata.

Quindi, in quest'ultima fase, abbiamo assemblato un repository separato in cui abbiamo aggiunto tutti i KPI in forma trasposta. Dal lato del database, qualsiasi richiesta a tale spazio di archiviazione viene elaborata in 0,1 - 0,3 secondi. Nella dashboard abbiamo ricevuto i seguenti risultati:

Prima apertura: 8-10 secondi
Qualsiasi clic: 6-7 secondi

Il tempo trascorso da Tableau è costituito da:

1. 0,3 secondi — analisi e compilazione del dashboard di query SQL
2. 1,5-3 secondi. — esecuzione di query SQL in Hana per le visualizzazioni principali (funziona in parallelo con il passaggio 1)
3. 1,5-2 secondi. — rendering, ricalcolo delle visualizzazioni
4. 1,3 secondi — esecuzione di query SQL aggiuntive per ottenere valori di filtro rilevanti (Marca, Divisione, Città, Negozio), analisi dei risultati

Per riassumere brevemente

Ci è piaciuto lo strumento Tableau dal punto di vista della visualizzazione. Nella fase di prototipazione, abbiamo considerato vari elementi di visualizzazione e li abbiamo trovati tutti nelle librerie, inclusa la complessa segmentazione multilivello e la cascata multi-driver.

Durante l'implementazione delle dashboard con gli indicatori chiave delle vendite, abbiamo riscontrato difficoltà prestazionali che non siamo ancora riusciti a superare. Abbiamo impiegato più di due mesi e abbiamo ricevuto una dashboard funzionalmente incompleta, la cui velocità di risposta è quasi accettabile. E abbiamo tratto conclusioni per noi stessi:

1. Tableau non può funzionare con grandi quantità di dati. Se nel modello dati originale sono presenti più di 10 GB di dati (circa 200 milioni x 50 righe), la dashboard viene seriamente rallentata, da 10 secondi a diversi minuti per ogni clic. Abbiamo sperimentato sia la connessione live che l'estrazione. La velocità operativa è paragonabile.
2. Limitazione quando si utilizzano più archivi (set di dati). Non è possibile indicare la relazione tra i set di dati utilizzando mezzi standard. Se utilizzi soluzioni alternative per connettere i set di dati, ciò influirà notevolmente sulle prestazioni. Nel nostro caso, abbiamo considerato la possibilità di materializzare i dati in ciascuna sezione di visualizzazione richiesta e di effettuare modifiche su questi set di dati materializzati preservando i filtri precedentemente selezionati: ciò si è rivelato impossibile da fare in Tableau.
3. Non è possibile creare parametri dinamici in Tableau. Non è possibile riempire un parametro utilizzato per filtrare un set di dati in un'estrazione o durante una connessione live con il risultato di un'altra selezione dal set di dati o il risultato di un'altra query SQL, ma solo con l'input utente nativo o una costante.
4. Limitazioni associate alla creazione di un dashboard con elementi OLAP|Tabella pivot.
   In MSTR, SAP SAC, SAP Analysis, se si aggiunge un set di dati a un report, tutti gli oggetti in esso contenuti sono correlati tra loro per impostazione predefinita. Tableau non dispone di questo; la connessione deve essere configurata manualmente. Questo è probabilmente più flessibile, ma per tutti i nostri dashboard questo è un requisito obbligatorio per gli elementi, quindi si tratta di costi di manodopera aggiuntivi. Inoltre, se crei filtri correlati in modo che, ad esempio, quando filtri una regione, l'elenco delle città sia limitato solo alle città di quella regione, ti ritroverai immediatamente con query successive al database o all'Estrazione, il che rallenta notevolmente la velocità pannello di controllo.
5. Limitazioni nelle funzioni. Non è possibile effettuare trasformazioni di massa né sull'estratto né, SOPRATTUTTO, sul dataset da Live-connecta. Questo può essere fatto tramite Tableau Prep, ma è un lavoro aggiuntivo e un altro strumento da apprendere e mantenere. Ad esempio, non è possibile trasporre dati o unirli a se stessi. Ciò viene chiuso tramite trasformazioni su singole colonne o campi, che devono essere selezionati tramite case o if, e questo genera query SQL molto complesse, nelle quali il database passa la maggior parte del suo tempo a compilare il testo della query. Questa rigidità dello strumento ha dovuto essere risolta a livello di vetrina, il che porta a un'archiviazione più complessa, a download e trasformazioni aggiuntivi.

Non abbiamo rinunciato a Tableau. Ma non consideriamo Tableau come uno strumento in grado di costruire dashboard industriali e uno strumento con cui sostituire e digitalizzare l’intero sistema di reporting aziendale di un’azienda.

Ora stiamo sviluppando attivamente una dashboard simile in un altro strumento e, allo stesso tempo, stiamo cercando di rivedere l'architettura della dashboard in Tableau per semplificarla ancora di più. Se la comunità sarà interessata, vi racconteremo i risultati.

Aspettiamo anche le vostre idee o consigli su come costruire rapidamente dashboard su volumi di dati così grandi in Tabeau, perché abbiamo un sito web in cui ci sono molti più dati che nella vendita al dettaglio.

Fonte: habr.com