U tempu di rapportu in Excel hè rapidamente sparisce - a tendenza versu strumenti convenienti per a presentazione è l'analisi di l'infurmazioni hè visibile in tutti i spazii. Avemu discututu internamente a digitalizazione di i rapporti per un bellu pezzu è hà sceltu u sistema di visualizazione di Tableau è analitica di self-service. Alexander Bezugly, capu di u dipartimentu di suluzioni analitiche è di rapportu di u Gruppu M.Video-Eldorado, hà parlatu di l'esperienza è i risultati di a custruzzione di un dashboard di cummattimentu.
Diciaraghju subitu chì micca tuttu ciò chì era pianificatu hè statu realizatu, ma l'esperienza hè stata interessante, spergu chì serà utile ancu per voi. È se qualchissia hà idee nantu à cumu si puderia fà megliu, aghju da esse assai grati per i vostri cunsiglii è idee.
Sottu u cut hè nantu à ciò chì avemu scontru è ciò chì avemu amparatu.
Induve avemu principiatu ?
M.Video-Eldorado hà un mudellu di dati ben sviluppatu: infurmazione strutturata cù a prufundità di almacenamiento necessaria è un gran numaru di rapporti in forma fissa (vede più dettagli ). Da questi, l'analisti facenu tabelle pivot o newsletters furmatu in Excel, o belli presentazioni PowerPoint per l'utilizatori finali.
Circa dui anni fà, invece di rapporti in forma fissa, avemu cuminciatu à creà rapporti analitici in SAP Analysis (un add-on Excel, essenzialmente una tabella pivot nantu à u mutore OLAP). Ma questu strumentu ùn era micca capaci di risponde à i bisogni di tutti l'utilizatori; a maiuranza cuntinuò à utilizà l'infurmazioni in più processate da l'analista.
I nostri utenti finali sò in trè categorie:
Top management. Richiede infurmazione in una manera ben presentata è chjaramente comprensibile.
A gestione media, utilizatori avanzati. Interessatu à l'esplorazione di dati è capace di custruisce rapporti in modu indipendenti se l'arnesi sò dispunibili. Sò diventati l'utilizatori chjave di i rapporti analitici in SAP Analysis.
utilizatori di massa. Ùn sò micca interessate à analizà i dati indipindentamente; usanu rapporti cù un gradu limitatu di libertà, in u formatu di newsletters è tabelli pivot in Excel.
A nostra idea era di copre i bisogni di tutti l'utilizatori è dà li un strumentu unicu è còmuda. Avemu decisu di principià cù u top management. Avianu bisognu di dashboards faciuli d'utilizà per analizà i risultati chjave di l'affari. Allora, avemu principiatu cù Tableau è prima hà sceltu duie direzzione: indicatori di vendita di vendita in linea è di vendita in linea cù una prufundità è una larghezza di analisi limitata, chì coprerebbe circa 80% di e dati dumandati da u top management.
Siccomu l'utilizatori di i dashboards eranu top management, un altru KPI addiziale di u pruduttu apparsu - a velocità di risposta. Nimu ùn aspittà 20-30 seconde per i dati per esse aghjurnati. A navigazione duveria esse fatta in 4-5 seconde, o megliu, fatta istantaneamente. È noi, sfurtunatamenti, ùn hà micca riesciutu à ottene questu.
Eccu ciò chì u layout di u nostru dashboard principale pareva:
L'idea chjave hè di cunghjuntà i principali mutori di KPI, di quale ci era 19 in totale, à a manca è prisentanu a so dinamica è a ripartizione per attributi principali à a diritta. U compitu pare sèmplice, a visualizazione hè logica è comprensibile, finu à chì si immerge in i dettagli.
Detail 1. Volume di dati
A nostra tavola principale per vendite annuali occupa circa 300 milioni di file. Siccomu hè necessariu di riflette a dinamica per l'annu passatu è l'annu prima, u voluminu di dati nantu à a vendita attuale solu hè di circa 1 billion lines. L'infurmazioni nantu à e dati pianificati è u bloccu di vendita in linea sò ancu almacenati separatamente. Per quessa, ancu s'è avemu usatu a colonna in-memoria DB SAP HANA, a rapidità di a quistione cù a selezzione di tutti l'indicatori per una settimana da u almacenamentu attuale nantu à a mosca era di circa 15-20 seconde. A suluzione à stu prublemu suggerisce stessu - materializazione supplementu di dati. Ma hà ancu trappule, più nantu à elli sottu.
Detail 2. Indicatori senza additivi
Parechji di i nostri KPI sò ligati à u numeru di ricevute. È questu indicatore rapprisenta COUNT DISTINCT di u numeru di fila (verificate intestazioni) è mostra quantità diverse secondu l'attributi selezziunati. Per esempiu, cumu si deve esse calculatu questu indicatore è u so derivatu:
Per fà i vostri calculi curretti, pudete:
- Calculate tali indicatori nantu à a mosca in u almacenamentu;
- Eseguite calculi nantu à tuttu u voluminu di dati in Tableau, i.e. nantu à a dumanda in Tableau, furnisce tutte e dati secondu i filtri selezziunati in a granularità di a pusizione di ricevuta;
- Crea una vetrina materializzata in quale tutti l'indicatori seranu calculati in tutte l'opzioni di mostra chì dà risultati diversi senza additivi.
Hè chjaru chì in l'esempiu UTE1 è UTE2 sò attributi materiali chì rapprisentanu a ghjerarchia di u produttu. Questa ùn hè micca una cosa statica; a gestione in a cumpagnia si faci attraversu, perchè Diversi gestori sò rispunsevuli di diversi gruppi di prudutti. Avemu avutu parechje rivisioni glubale di sta ghjerarchia, quandu tutti i livelli cambiavanu, quandu e rilazioni sò stati rivisioni, è i cambiamenti constantemente puntu, quandu un gruppu si trasfirìu da un node à l'altru. In u rapportu cunvinziunali, tuttu questu hè calculatu nantu à a mosca da l'attributi di u materiale; in u casu di materializazione di sta dati, hè necessariu di sviluppà un mecanismu per seguità tali cambiamenti è ricaricà automaticamente e dati storichi. Un compitu assai micca trivial.
Detail 3. Comparazione di dati
Stu puntu hè simile à u precedente. U fondu hè chì quandu analizà una cumpagnia, hè abitudine di furmà parechji livelli di paraguni cù u periodu precedente:
Comparazione cù u periodu precedente (ghjornu à ghjornu, settimana à settimana, mese à mese)
In questu paragone, si assume chì sicondu u periodu sceltu da l'utilizatore (per esempiu, a 33a settimana di l'annu), duvemu mustrà a dinamica da a 32a settimana; se avemu sceltu dati per un mese, per esempiu, maghju. , tandu sta paragone mostraria a dinamica d'aprile.
Comparazione cù l'annu passatu
A sfumatura principale quì hè chì quandu paragunate per ghjornu è per settimana, ùn site micca pigliatu u stessu ghjornu di l'annu passatu, i.e. ùn pudete micca solu mette l'annu currentu minus unu. Duvete guardà u ghjornu di a settimana chì compara. Quandu si compara mesi, à u cuntrariu, avete bisognu di piglià esattamente u listessu ghjornu di u calendariu di l'annu passatu. Ci sò ancu sfumature cù anni bisestili. In i repositori originali, tutte l'infurmazioni sò distribuite per ghjornu; ùn ci sò campi separati cù settimane, mesi o anni. Dunque, per ottene una sezione trasversale analitica cumpleta in u pannellu, avete bisognu di cuntà micca un periodu, per esempiu una settimana, ma 4 settimane, è poi paragunate sti dati, riflette a dinamica, deviazioni. Per quessa, sta logica per generà paraguni in dinamica pò ancu esse implementata sia in Tableau o in u latu di a tenda. Iè, è di sicuru avemu cunnisciutu è pensatu à sti ditaglii in u stadiu di cuncepimentu, ma era difficiule di predichendu u so impattu nantu à u rendiment di u dashboard finali.
Quandu implementava u dashboard, avemu seguitu a longa strada Agile. U nostru compitu era di furnisce un strumentu di travagliu cù e dati necessarii per a prova u più prestu pussibule. Dunque, andemu in sprints è cuminciamu à minimizzà u travagliu da u latu di u almacenamentu attuale.
Parte 1: Fede in Tableau
Per simplificà u supportu IT è implementà rapidamente i cambiamenti, avemu decisu di fà a logica per calculà indicatori non additivi è paragunà i periodi passati in Tableau.
Stage 1. Tuttu hè Live, senza mudificazione di finestra.
À questu stadiu, avemu cunnessu Tableau à i vetri attuali è decisu di vede cumu u numeru di ricevute per un annu serà calculatu.
Risultatu:
A risposta era deprimente - 20 minuti. Trasferimentu di dati nantu à a reta, alta carica nantu à Tableau. Avemu capitu chì a logica cù indicatori non additivi deve esse implementata in HANA. Questu ùn ci hà micca spaventatu assai, avemu digià avutu una sperienza simile cù BO è Analisi è sapemu cumu custruisce vitrine veloci in HANA chì pruducenu indicatori micca additivi currettamente calculati. Il ne restait plus qu'à l'ajuster à Tableau.
Stage 2. Sintonizemu e vitrine, nisuna materializazione, tuttu nantu à a mosca.
Avemu criatu una nova vitrina separata chì hà pruduttu i dati necessarii per TABLEAU à a mosca. In generale, avemu un bonu risultatu; avemu riduciutu u tempu per generà tutti l'indicatori in una settimana à 9-10 seconde. È onestamente aspittavamu chì in Tableau u tempu di risposta di u dashboard seria 20-30 seconde à a prima apertura è dopu per via di a cache da 10 à 12, chì in generale ci cunvene.
Risultatu:
Prima aperta dashboard: 4-5 minuti
Ogni clic: 3-4 minuti
Nisunu s'aspittava un tali aumentu supplementu in u travagliu di a vetrina.
Parte 2. Immergete in Tableau
Stage 1. Analisi di rendiment di Tableau è sintonizazione rapida
Avemu cuminciatu à analizà induve Tableau passa a maiò parte di u so tempu. E ci sò assai boni strumenti per questu, chì, sicuru, hè un plus di Tableau. U prublema principali chì avemu identificatu era e dumande SQL assai cumplesse chì Tableau hà custruitu. Eranu principalmente assuciati cù:
- trasposizione di dati. Siccomu Tableau ùn hà micca arnesi per trasposite datasets, per custruisce u latu manca di u dashboard cù una rapprisintazioni dettagliata di tutti i KPI, avemu avutu à creà una tavula cù un casu. A dimensione di e dumande SQL in a basa di dati hà righjuntu 120 000 caratteri.
- scelta di u periodu di tempu. Una tale dumanda à u nivellu di basa di dati hà pigliatu più tempu per compilà chè per eseguisce:
Quelli. Trattamentu di dumanda 12 seconde + 5 seconde esecuzione.
Avemu decisu di simplificà a logica di calculu nantu à u latu di Tableau è move una altra parte di i calculi à u livellu di a tenda è a basa di dati. Questu hà purtatu boni risultati.
Prima, avemu fattu a trasposizione nantu à a mosca, l'avemu fattu attraversu una unione esterna completa in a tappa finale di u calculu VIEW, secondu questu approcciu descrittu in u wiki. и .
Questu hè, avemu fattu una tavola di paràmetri - una matrice di trasposizione (21x21) è hà ricevutu tutti l'indicatori in una fila per fila.
Era:
Hè diventatu:
Quasi nisun tempu hè passatu nantu à a trasposizione di a basa di dati stessu. A dumanda per tutti l'indicatori per a settimana cuntinuava à esse processata in circa 10 seconde. Ma da l'altra banda, a flessibilità hè stata persa in quantu à a custruzzione di un dashboard basatu annantu à un indicatore specificu, i.e. per u latu drittu di u dashboard induve a dinamica è a ripartizione dettagliata di un indicatore specificu sò presentati, prima a vitrina funzionava in 1-3 seconde, perchè a dumanda hè stata basatu annantu à un indicatore, è avà a basa di dati hà sempre sceltu tutti l'indicatori è filtratu u risultatu prima di vultà u risultatu à Tableau.
In u risultatu, a vitezza di u dashboard hè diminuitu da quasi 3 volte.
Risultatu:
- 5 sec - parsing dashboards, visualizazioni
- 15-20 seconde - preparazione per a compilazione di e dumande cù l'esecuzione di pre-calculazioni in Tableau
- 35-45 sec - compilazione di e dumande SQL è a so esecuzione parallela-sequenziale in Hana
- 5 sec - trasfurmazioni di i risultati, ordinamentu, ricalculazione di visualizazioni in Tableau
- Di sicuru, tali risultati ùn sò micca adattati à l'affari, è avemu cuntinuatu l'ottimisazione.
Stage 2. Logica minima in Tableau, materializazione cumpleta
Avemu capitu chì era impussibile di custruisce un dashboard cù un tempu di risposta di parechji sicondi nantu à una vetrina chì dura per 10 seconde, è avemu cunsideratu l'opzioni per materializà e dati nantu à a basa di dati specificamente per u dashboard necessariu. Ma avemu scontru un prublema glubale descrittu sopra - indicatori non additivi. Ùn avemu micca pussutu assicurà chì quandu cambia i filtri o drilldowns, Tableau hà cambiatu in modu flessibile trà e diverse vetrine è livelli pre-progettati per diverse gerarchie di prudutti (in l'esempiu, trè dumande senza UTE, cù UTE1 è UTE2 generanu risultati diffirenti). Dunque, avemu decisu di simplificà u dashboard, abbandunà a ghjerarchia di u produttu in u dashboard è vede quantu veloce puderia esse in una versione simplificata.
Allora, in questa ultima tappa, avemu assemblatu un repository separatu in quale aghjunse tutti i KPI in forma trasposta. Da u latu di a basa di dati, ogni dumanda à un tali almacenamentu hè trattatu in 0,1 - 0,3 seconde. In u dashboard avemu ricevutu i seguenti risultati:
Prima apertura: 8-10 seconde
Ogni clicu: 6-7 seconde
U tempu spesu da Tableau hè cumpostu di:
- 0,3 sec. - parsing dashboard è compilazione di e dumande SQL
- 1,5-3 sec. - esecuzione di dumande SQL in Hana per visualizazioni principali (corre in parallelu cù u passu 1)
- 1,5-2 sec. - rendering, recalculazione di visualizazioni
- 1,3 sec. - Esecuzione di dumande SQL supplementari per ottene i valori di filtru pertinenti (Marca, Divisione, Città, Store), analisi di risultati
Per riassume in breve
Ci hè piaciutu u strumentu Tableau da una perspettiva di visualizazione. À u stadiu di prototipu, avemu cunsideratu diversi elementi di visualizazione è truvamu tutti in biblioteche, cumprese a segmentazione cumplessa multi-livellu è a cascata multi-driver.
Mentre implementava dashboards cù indicatori chjave di vendita, avemu scontru difficultà di rendiment chì ùn avemu micca ancu pussutu superà. Avemu passatu più di dui mesi è ricivutu un dashboard funziunale incomplete, a velocità di risposta di quale hè nantu à u puntu di accettabile. È avemu tiratu cunclusioni per noi stessi:
- Tableau ùn pò micca travaglià cù grandi volumi di dati. Se in u mudellu di dati uriginale avete più di 10 GB di dati (circa 200 milioni X 50 fila), u dashboard rallenta seriamente - da 10 seconde à parechji minuti per ogni clic. Avemu sperimentatu sia in live-connect è extract. A velocità di u funziunamentu hè paragunabile.
- Limitazione à l'usu di parechje almacenamenti (sets di dati). Ùn ci hè manera di indicà a relazione trà e datasets cù i mezi standard. Se aduprate soluzioni alternative per cunnette i datasets, questu affettarà assai u rendiment. In u nostru casu, avemu cunsideratu l'opzione di materializà e dati in ogni sezione di vista necessaria è di fà cambiamenti nantu à questi datasets materializzati mentre priservendu i filtri prima selezziunati - questu hè statu impussibile di fà in Tableau.
- Ùn hè micca pussibule di fà paràmetri dinamichi in Tableau. Ùn pudete micca riempie un paràmetru chì hè utilizatu per filtrà un dataset in un estratto o durante una live-connecte cù u risultatu d'una altra selezzione da u dataset o u risultatu d'una altra consulta SQL, solu input nativu di l'utilizatori o una constante.
- Limitazioni assuciate à a creazione di un dashboard cù elementi OLAP | PivotTable.
In MSTR, SAP SAC, SAP Analysis, se aghjunghje un dataset à un rapportu, tutti l'uggetti nantu à questu sò ligati l'un à l'altru per automaticamente. Tableau ùn hà micca questu; a cunnessione deve esse cunfigurata manualmente. Questu hè probabilmente più flessibile, ma per tutti i nostri dashboards hè un requisitu obligatoriu per l'elementi - cusì hè un costu di travagliu supplementu. Inoltre, se fate filtri cunnessi in modu chì, per esempiu, quandu filtra una regione, a lista di e cità hè limitata solu à e cità di sta regione, vi finiscinu immediatamente cù dumande successive à a basa di dati o Estratti, chì rallenta notevolmente u dashboard. - Limitazioni in e funzioni. Trasformazioni di massa ùn ponu esse fattu nè nantu à l'estrattu nè, in particulare, in u dataset da Live-connecta. Questu pò esse fattu attraversu Tableau Prep, ma hè un travagliu supplementu è un altru strumentu per amparà è mantene. Per esempiu, ùn pudete micca traspone dati o unisce cù ellu stessu. Ciò chì hè chjusu attraversu trasfurmazioni nantu à e colonne o campi individuali, chì deve esse sceltu per casu o se, è questu genera dumande SQL assai cumplessu, in quale a basa di dati passa a maiò parte di u so tempu cumpilà u testu di a dumanda. Queste inflessibilità di l'uttellu anu da esse risolta à u livellu di vetrina, chì porta à un almacenamentu più cumplessu, scaricamentu supplementu è trasfurmazioni.
Ùn avemu micca rinunciatu à Tableau. Ma ùn cunsideremu micca Tableau cum'è un strumentu capace di custruisce dashboards industriali è un strumentu cù quale rimpiazzà è digitalizà tuttu u sistema di rapportu corporativu di una cumpagnia.
Avà sviluppemu attivamente un dashboard simili in un altru strumentu è, à u stessu tempu, pruvemu di rivisà l'architettura di dashboard in Tableau per simplificà ancu di più. Se a cumunità hè interessata, vi cuntaremu di i risultati.
Aspittemu ancu e vostre idee o cunsiglii nantu à cumu in Tabeau pudete custruisce dashboards rapidi nantu à volumi cusì grande di dati, perchè avemu un situ web induve ci hè assai più dati chì in u retail.
Source: www.habr.com