Timpul de raportare în Excel trece rapid — tendința către instrumente convenabile de prezentare și analiză a informațiilor este vizibilă în toate domeniile. Am discutat de multă vreme despre digitalizarea procesului de raportare și am ales sistemul de vizualizare și analiză self-service Tableau. Alexandr Bezuglyi, șeful departamentului de soluții analitice și raportare al Grupului „M.Video-Eldorado”, a vorbit despre experiența și rezultatele construirea unui tablou de bord operațional.
Voi spune din start că nu tot ce a fost planificat a fost realizat, dar experiența a fost interesantă, sper că va fi utilă și pentru voi. Și dacă cineva are idei despre cum ar fi putut fi realizat mai bine – aș fi foarte recunoscător pentru sfaturi și propuneri.
Sub articol se află informații despre cu ce ne-am confruntat și ce am învățat.
De unde am început
La „M.Video-Eldorado” există un model de date bine structurat: informații structurate cu adâncimea de stocare necesară și un număr imens de rapoarte cu formă fixă (vezi mai multe detalii ). Din acestea, analiștii realizează fie tabele pivott, fie trimiteri formatate în Excel, fie prezentări frumoase în PowerPoint pentru utilizatorii finali.
Aproximativ acum doi ani, în loc de rapoarte cu formă fixă, am început să creăm rapoarte analitice în SAP Analysis (un add-in pentru Excel, care este, în esență, un tabel pivot asupra unui motor OLAP). Dar acest instrument nu a putut satisface nevoile tuturor utilizatorilor, majoritatea au continuat să folosească informațiile prelucrate suplimentar de analiști.
Utilizatorii noștri finali sunt împărțiți în trei categorii:
Top management. Solicită informații într-o formă bine prezentată și ușor de înțeles.
Middle management, utilizatori avansați. Sunt interesați de investigarea datelor și capabili să construiască raporturi pe cont propriu atunci când au instrumentele necesare. Aceștia au devenit utilizatorii cheie ai rapoartelor analitice în SAP Analysis.
Utilizatori obișnuiți. Nu sunt interesați de analiza independentă a datelor, folosesc rapoarte cu un grad limitat de libertate, sub formă de trimiteri și tabele pivot în Excel.
Ideea noastră a fost să acoperim nevoile tuturor utilizatorilor și să le oferim un instrument unic și convenabil. Am decis să începem cu managementul de vârf. Aceștia aveau nevoie de panouri utile pentru analizarea principalelor rezultate de afaceri. Astfel, am început cu Tableau și, inițial, am ales două direcții: indicatori de vânzări în retail și online, cu o adâncime și lățime limitată a analizei, care să acopere aproximativ 80% din datele solicitate de managementul de vârf.
Având în vedere că utilizatorii tablourilor de bord erau din managementul de vârf, a apărut un alt KPI suplimentar al produsului – viteza de răspuns. Nimeni nu va aștepta 20-30 de secunde pentru ca datele să se actualizeze. Navigarea trebuie să se încadreze în 4-5 secunde, iar ideal ar fi să fie instantanee. Din păcate, acest lucru nu ne-a reușit.
Iată cum arăta schița tabloului nostru de bord principal:
Ideea cheie este să unim principalii driveri KPI, care în final au ajuns la 19, în stânga și să le prezentăm dinamica și detalierea pe principalele atribute în dreapta. Sarcina pare simplă, vizualizarea logică și clară, până nu te aprofundezi în detalii.
Detaliu 1. Volumul de date
Tabelul principal cu vânzările pe parcursul unui an are aproximativ 300 de milioane de rânduri. Deoarece este necesar să reflectăm atât dinamica din anul trecut, cât și din anul precedent, volumul de date pentru vânzările efective este de aproximativ 1 miliard de rânduri. De asemenea, informațiile despre datele planificate și blocul vânzărilor online sunt stocate separat. Prin urmare, chiar și cu utilizarea unei baze de date in-memory pe coloane, SAP HANA, viteza de execuție a interogării pentru selectarea tuturor indicatorilor dintr-o săptămână din stocurile curente în timp real era de aproximativ 15-20 de secunde. Soluția acestei probleme se impune de la sine – materializarea suplimentară a datelor. Dar există și capcane în această abordare, despre care vom discuta mai jos.
Detaliu 2. Indicatori neaditivi
Mulți dintre KPI-urile noastre sunt legați de numărul de bonuri. Acest indicator reprezintă COUNT DISTINCT al numărului de rânduri (titlurilor bonurilor) și indică sume diferite în funcție de atributele selectate. Ca exemplu, iată cum ar trebui să fie calculat acest indicator și derivatul său:
Pentru acuratețea calculelor putem:
- Realiza calcule de acest tip în timp real în stoc;
- Realiza calculul pe întregul volum de date în Tableau, adică, la cerere în Tableau, să returneze toate datele pe filtrele selectate la nivelul granularității bonurilor;
- Realizați o vitrină materializată care va calcula toate indicatorii pentru toate variantele de selecție, generând rezultate non-aditive diferite.
Este clar că în exemplul UTE1 și UTE2 – acestea sunt atributele materialului care reprezintă ierarhia produselor. Nu este un lucru static, prin aceasta se realizează managementul în companie, deoarece diferite grupuri de produse au manageri diferiți. Am avut multe revizuiri globale ale acestei ierarhii, când au fost schimbate toate nivelurile, când au fost revizuite relațiile, precum și modificări punctuale constante, când un grup trece dintr-un nod în altul. În raportarea obișnuită, toate acestea sunt calculate pe loc din atributele materialului, iar în cazul materializării acestor date, este necesar să dezvoltăm un mecanism de urmărire a acestor modificări și de reîncărcare automată a datelor istorice. Este o sarcină destul de non-trivială.
Detaliu 3. Compararea datelor
Această secțiune este similară cu cea anterioară. Esența este că, în companie, la analiză se formează mai multe niveluri de comparație cu perioada anterioară:
Compararea cu perioada anterioară (zi cu zi, săptămână cu săptămână, lună cu lună)
În această comparație se presupune că, în funcție de perioada aleasă de utilizator (de exemplu, săptămâna 33 a anului), trebuie să arătăm dinamica față de săptămâna 32. Dacă am alege datele pentru o lună, de exemplu, mai, această comparație ar arăta dinamica față de aprilie.
Compararea cu anul trecut
Principala nuanță aici este că, atunci când comparați zilele și săptămânile, nu luați aceeași zi din anul trecut, adică nu puteți pur și simplu să faceți anul curent minus unul. Trebuie să examinați ziua corespunzătoare a săptămânii. Și când comparați lunile, dimpotrivă, trebuie să luați exact aceeași zi calendaristică din anul anterior. De asemenea, există nuanțe cu anii bisecți. În stocurile de date originale, toate informațiile sunt distribuite pe zile, nu există câmpuri separate pentru săptămâni, luni, ani. Prin urmare, pentru a obține o imagine analitică completă în panou, trebuie să calculați nu o singură perioadă, de exemplu o săptămână, ci 4 săptămâni și apoi să comparați aceste date, să reflectați dinamica, abaterile. Prin urmare, această logică de formare a comparării în dinamică poate fi realizată fie în Tableau, fie pe partea de vitrină. Da, și despre aceste detalii bineînțeles că știm și am gândit despre ele încă din faza de proiectare, dar influența lor asupra performanței tabelului final a fost greu de prevăzut.
În timp ce implementam tabloul de bord, am parcurs un drum lung Agile. Obiectivul nostru era să oferim cât mai repede un instrument funcțional pentru testare cu datele necesare. Așadar, ne-am desfășurat în sprinturi și ne-am bazat pe minimizarea lucrărilor din partea actualului depozit.
Partea 1. Credința în Tableau
Pentru a simplifica suportul IT și a implementa rapid modificările, am decis să facem logica de calculare a indicatorilor neaditivi și compararea perioadelor anterioare în Tableau.
Etapa 1. Totul în Live, fără modificări ale vitrinelor.
În această etapă, am conectat Tableau la vitrinele actuale și am decis să vedem cum va fi calculat numărul de chitanțe pentru un an.
Rezultatul:
Răspunsul a fost descurajant - 20 de minute. Transferul datelor prin rețea, încărcarea mare pe Tableau. Am realizat că logica indicatorilor neaditivi trebuie să fie implementată pe HANA. Acest lucru nu ne-a speriat prea mult, deoarece aveam deja experiență similară cu BO și Analysis și știam să construim vitrine rapide în HANA, care oferă indicatori neaditivi calculați corect. Acum rămânea doar să le adaptăm pentru Tableau.
Etapa 2. Îmbunătățim vitrinele, fără nicio materializare, totul pe loc.
Am creat o nouă interfață separată, care genera în mod dinamic datele necesare pentru TABLEAU. În general, am obținut un rezultat bun, am redus timpul de generare a tuturor indicatorilor de la o săptămână la 9-10 secunde. Ne așteptam sincer ca în Tableau timpul de răspuns al tabloului de bord să fie de 20-30 de secunde la prima deschidere și apoi, datorită cache-ului, între 10 și 12 secunde, ceea ce ne-ar fi mulțumit în totalitate.
Rezultatul:
Prima deschidere a tablourilor de bord: 4-5 minute
Orice clic: 3-4 minute
Nimeni nu se aștepta la o astfel de creștere suplimentară a performanței interfeței.
Partea 2. Imersiune în Tableau
Etapa 1. Analiza performanței Tableau și optimizarea rapidă
Am început să analizăm pe ce timp își consumă Tableau resursele. Există unele instrumente bune pentru acest lucru, ceea ce este, desigur, un avantaj al Tableau. Principala problemă pe care am identificat-o au fost cererile SQL foarte complexe generate de Tableau. Acestea erau în principal legate de:
— transpunerea datelor. Deoarece Tableau nu are instrumente pentru transpunerea dataset-urilor, pentru a construi partea stângă a tabloului de bord cu o prezentare detaliată a tuturor KPI-urilor, a trebuit să formăm o tabelă prin intermediul case-ului. Dimensiunea cererilor SQL în DB a ajuns la 120.000 de caractere.
— selectarea perioadei de timp. O astfel de cerere la nivel de DB dura mai mult timp pentru compilare decât pentru execuție:
Adică, procesarea cererii 12 secunde + 5 secunde execuție.
Am decis să simplificăm logica calculului pe partea de Tableau și să mutăm o altă parte a calculului pe interfață și nivelul DB. Aceasta a adus rezultate bune.
Mai întâi am făcut transpunerea în mod dinamic, realizând-o printr-un full outer join în etapa finală de calculare a VIEW-ului, conform unei abordări descrise pe wiki și .
Adică, am creat o tabelă de configurare – o matrice de transpunere (21x21) și am obținut toate indicatorii într-o desfășurare pe linii.
A fost:
A devenit:
Transpunerea bazei de date nu durează aproape deloc. Cererea pentru toate indicatorii din săptămână a fost procesată în continuare în aproximativ 10 secunde. Însă, am pierdut flexibilitatea în construirea tabloului de bord pentru un indicator specific, adică pentru partea dreaptă a tabloului de bord unde este reprezentată dinamica și detalierea unui indicator specific, vitrina se procesa înainte în 1-3 secunde, deoarece cererea se făcea pentru un singur indicator, iar acum baza de date selectează întotdeauna toți indicatorii, filtrând rezultatul înainte de a-l returna în Tableau.
În consecință, viteza de funcționare a tabloului de bord a scăzut aproape de 3 ori.
Rezultatul:
- 5 sec — parsarea tabloului de bord, vizualizărilor
- 15-20 sec — pregătirea pentru compilarea cererilor cu efectuarea precalculărilor în Tableau
- 35-45 sec — compilarea cererilor SQL și executarea lor simultană și secvențială în Hana
- 5 sec — procesarea rezultatelor, sortarea, recalcularea vizualizărilor în Tableau
- Desigur, astfel de rezultate nu au fost acceptabile pentru afacere, așa că am continuat optimizarea.
Faza 2. Minim de logică în Tableau, materializare completă
Ne-am dat seama că construirea unui tablou de bord cu un timp de răspuns de câteva secunde pe o vitrină care funcționează în 10 secunde este imposibilă și am analizat opțiunile pentru materializarea datelor pe partea bazei de date exact pentru tabloul de bord necesar. Dar ne-am confruntat cu o problemă globală, descrisă mai sus – indicatori neaditivi. Nu am reușit să facem ca, la modificarea filtrelor sau desfășurărilor, Tableau să se comute flexibil între diferite vitrine și niveluri, precalculată pentru diferite ierarhii de produse (în exemplu, trei cereri fără UTE, cu UTE1 și UTE2 formează rezultate diferite). Prin urmare, am decis să simplificăm tabloul de bord, renunțând la ierarhia de produse în tablou și să vedem cât de rapid poate fi în versiunea simplificată.
Așadar, în această ultimă etapă, am adunat un depozit separat, în care am stocat în format transpus toate KPI-urile. Pe partea bazei de date, orice cerere către acest depozit se procesează în 0,1 – 0,3 secunde. În tabloul de bord am obținut următoarele rezultate:
Prima deschidere: 8-10 secunde
Orice clic: 6-7 secunde
Timpul pe care îl petrece Tableau constă din:
- 0,3 sec — parsarea tabloului de bord și compilarea cererilor SQL
- 1,5-3 sec — executarea cererilor SQL în Hana pentru vizualizările principale (se lansează paralel cu punctul 1)
- 1,5-2 sec. — rendering, recalculating visualizations
- 1,3 sec. — executing additional SQL queries to obtain relevant filter values (Brand, Division, City, Store), parsing results
If we summarize briefly
We liked the Tableau tool in terms of visualization. During the prototyping stage, we considered various visualization elements and found all of them in the libraries, including complex multi-level segmentations and multi-driver waterfalls.
When implementing dashboards with key sales indicators, we encountered performance difficulties that we have not yet been able to overcome. We spent more than two months and produced a functionally incomplete dashboard, whose response speed is on the verge of acceptable. And we drew the following conclusions:
- Tableau cannot handle large volumes of data. If your original data model contains more than 10 GB of data (approximately 200 million x 50 rows), then the dashboard significantly slows down — from 10 seconds to several minutes for each click. We experimented both with live connection and with extracts. The performance was comparable.
- Limitations when using multiple data stores (datasets). There is no standard way to specify the relationships between datasets. If you use workaround solutions for connecting datasets, it will significantly affect performance. In our case, we considered materializing data in every necessary dimension for the views and making switches on these materialized datasets while maintaining the previously selected filters — this turned out to be impossible to do in Tableau.
- It is impossible to create dynamic parameters in Tableau. You cannot fill a parameter used for filtering a dataset in an extract or during live connection with results from another selection from the dataset or the result of another SQL query; it can only be a native user input or a constant.
- Limitations associated with constructing a dashboard containing OLAP elements | Pivot tables.
În MSTR, SAP SAC, SAP Analysis, atunci când adăugați un set de date în raport, toate obiectele de pe acesta sunt legate între ele în mod implicit. În Tableau nu există acest lucru, trebuie să configurați legătura manual. Probabil că este mai flexibil, dar pentru toate dashboard-urile noastre aceasta este o cerință obligatorie pentru elemente – prin urmare, necesită un efort suplimentar. În plus, dacă creați filtre legate, astfel încât, de exemplu, atunci când filtrați regiunea, lista orașelor să fie limitată doar la orașele din acea regiune, veți ajunge la interogări secvențiale către DB sau Extragere, ceea ce încetinește vizibil dashboard-ul. - Limitări ale funcțiilor. Atât pe extracție, cât și mai ales pe setul de date din Live-connect, nu se pot face transformări masive. Acest lucru se poate face prin Tableau Prep, dar reprezintă un efort suplimentar și un instrument care trebuie studiat și întreținut. De exemplu, nu puteți transpune datele, să le faceți join cu ele însele. Acest lucru este restricționat prin transformări pe coloane sau câmpuri separate, care trebuie selectate prin case sau if, iar aceasta generează interogări SQL foarte complexe, când baza de date pierde mult timp la compilarea textului interogării. Aceste rigidități ale instrumentului au trebuit rezolvate la nivelul vitrinei, ceea ce duce la complicarea stocării, sarcini suplimentare și transformări.
Nu am renunțat la Tableau. Dar ca instrument capabil să construiască dashboard-uri industriale și ca mijloc prin care se poate înlocui și digitaliza întreaga sistemă de raportare corporativă a companiei, nu îl considerăm.
În prezent, lucrăm activ la un dashboard similar cu un alt instrument și, în paralel, încercăm să revizuim arhitectura dashboard-ului în Tableau pentru a o simplifica și mai mult. Dacă comunității îi va fi de interes, vom împărtăși rezultatele.
De asemenea, așteptăm ideile sau sfaturile dvs. despre cum în Tableau pot fi construite dashboard-uri rapide pe volume atât de mari de date, având în vedere că avem și un site cu mult mai multe date decât în retail.
Sursa: habr.com
