Timpul raportărilor în Excel trece rapid — tendința de a utiliza instrumente convenabile pentru prezentarea și analiza informațiilor este vizibilă în toate domeniile. Am discutat de mult timp despre digitalizarea generării rapoartelor și am ales sistemul de vizualizare și analiză self-service Tableau. Alexander Bezugly, șeful departamentului de soluții analitice și raportare al Grupului „M.Video-Eldorado”, a povestit despre experiența și rezultatele construirii unui tablou de bord operațional.
Voi spune din start, nu tot ce a fost planificat a reușit să fie realizat, dar experiența a fost interesantă și sper că va fi utilă și pentru voi. Iar dacă cineva are idei despre cum ar fi putut fi făcut mai bine, voi fi foarte recunoscător pentru sfaturi și idei.
Sub titlu, despre ce ne-am confruntat și despre ce am învățat.
De unde am început
În „M.Video-Eldorado” există un model de date bine elaborat: informație structurată cu adâncimea necesară de stocare și o cantitate enormă de rapoarte de formă fixă (vezi mai multe detalii ). Din acestea, analiștii fac fie tabele pivotante sau buletine informative formatate în Excel, fie prezentări atrăgătoare în PowerPoint pentru utilizatorii finali.
Aproximativ acum doi ani, în loc de rapoarte de formă fixă, am început să creăm rapoarte analitice în SAP Analysis (un addon pentru Excel, în esență — un tabel pivotat pe un motor OLAP). Dar acest instrument nu a reușit să satisfacă nevoile tuturor utilizatorilor, majoritatea continuând să utilizeze informația suplimentar procesată de analiști.
Utilizatorii noștri finali se împart în trei categorii:
Top management. Solicitați informații într-o formă bine prezentată și ușor de înțeles.
Middle management, utilizatori avansați. Sunt interesați de explorarea datelor și capabili să genereze singuri rapoarte când au instrumentele necesare. Ei au devenit utilizatorii cheie ai rapoartelor analitice din SAP Analysis.
Utilizatori de masă. Nu sunt interesați de analiza independentă a datelor, folosesc rapoarte cu un grad limitat de libertate, în formă de buletine informative și tabele pivotante î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 ușor de utilizat pentru analiza principalelor rezultate de afaceri. Astfel, am început cu Tableau și, pentru început, am ales două direcții: indicatori de vânzări în retail și online, cu o adâncime și o lățime de analiză limitate, care să acopere aproximativ 80% din datele solicitate de top management.
Având în vedere că utilizatorii tablourilor de bord erau 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 trebuia să dureze în 4-5 secunde sau, mai bine, să fie instantanee. Și din păcate, nu am reușit să atingem acest obiectiv.
Așa arăta schița tabloului nostru principal de bord:
Ideea cheie este să reunim principalii conducători KPI, care în final au fost 19, pe partea stângă și să le prezentăm dinamica și segmentarea pe principalele atribute pe partea dreaptă. Sarcina pare simplă, vizualizarea este logică și ușor de înțeles, până nu te adâncești în detalii.
Detaliul 1. Volumul de date
Tabelul principal cu vânzările pe un an are aproximativ 300 de milioane de rânduri. Deoarece este necesar să reflectăm și dinamica din anul trecut și din anul precedent, volumul de date doar pentru vânzările efective este de aproximativ 1 miliard de rânduri. De asemenea, sunt stocate separat informațiile privind datele planificate și blocul de vânzări online. Așadar, chiar dacă am folosit DB in-memory SAP HANA, viteza de execuție a unei interogări pentru selectarea tuturor indicatorilor pentru o săptămână din depozitele curente a fost de aproximativ 15-20 de secunde. Soluția acestei probleme se iese de la sine – materializarea suplimentară a datelor. Dar și în cazul acesta există capcane, despre care vom discuta mai jos.
Detaliul 2. Indicatori neaditivi
Mulți dintre KPI-urile noastre depind de numărul de bonuri. Acest indicator reprezintă COUNT DISTINCT al numărului de rânduri (anteturi de bonuri) și arată sume diferite în funcție de atributele selectate. De exemplu, cum ar trebui să fie calculat acest indicator și derivatul său:
Pentru a asigura corectitudinea calculelor, se poate:
- Efectua calcule asemănătoare în timp real în depozit;
- Efectua calcule pe întregul volum de date în Tableau, adică, la cerere în Tableau, să se returneze toate datele conform filtrelor selectate la granularitatea posturilor bonurilor;
- Crearea unei prezentări materializate, în care vor fi calculate toate indicatorii pentru toate variantele de selecție, care oferă rezultate non-aditive diferite.
Este clar că în exemplul UTE1 și UTE2 – acestea sunt atribute ale materialului, reprezentând ierarhia produselor. Aceasta nu este o entitate statică, prin ea se realizează managementul în interiorul companiei, deoarece diferite grupuri de produse sunt răspunzătoare de diferiți manageri. Am avut multe revizuiri globale ale acestei ierarhii, când toate nivelurile s-au schimbat, când relațiile au fost reevaluate, dar și modificări punctuale constante, când un grup trece dintr-un nod în altul. În raportarea obișnuită, toate acestea sunt calculate în timp real din atributele materialului; în cazul materializării acestor date, este necesară dezvoltarea unui mecanism pentru a urmări astfel de modificări și pentru a reîncărca datele istorice în mod automat. O sarcină destul de complexă.
Detaliu 3. Compararea datelor
Această secțiune este similară cu cea anterioară. Esența este că, în cadrul companiei, la analiză, este obiceiul de a forma mai multe niveluri de comparare 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 anterior
Aici, aspectul principal este că atunci când compari pe zile și pe săptămâni, nu iei aceeași zi din anul precedent, adică nu poți să pui pur și simplu anul curent minus unu. Trebuie să te uiți la ziua comparată a săptămânii. În schimb, când compari luni, trebuie să iei exact aceeași zi din calendar a anului trecut. De asemenea, există nuanțe cu anii bisecți. În depozitele originale, toate informațiile sunt distribuite pe zile, nu există câmpuri separate pentru săptămâni, luni, ani. Astfel, pentru a obține un tablou analitic complet în panou, trebuie să calculezi nu o singură perioadă, de exemplu, o săptămână, ci 4 săptămâni, și apoi să compari aceste date, să reflectezi dinamica și abaterile. Prin urmare, această logică de formare a comparației în dinamică poate fi implementată fie în Tableau, fie pe partea vitrinei. Da, și despre aceste detalii, bineînțeles, știm și am gândit încă din etapa de proiectare, dar influența lor asupra performanței tabloului de bord final a fost greu de prognozat.
În implementarea tabloului de bord, am urmat un parcurs lung Agile. Sarcina noastră a fost să oferim cât mai repede un instrument funcțional pentru testare, cu datele necesare. Așadar, am mers pe sprinturi și ne-am bazat pe minimizarea muncii pe partea depozitului actual.
Partea 1. Credința în Tableau
Pentru a simplifica suportul IT și a implementa rapid modificările, am decis să facem logica calculului indicatorilor neaditiv și compararea perioadelor anterioare în Tableau.
Etapa 1. Totul în Live, fără dezvoltări pentru vitrine.
În această etapă, am conectat Tableau la vitrinele actuale și am decis să vedem cum se va calcula numărul de bonuri pentru un an.
Rezultatul:
Răspunsul a fost descurajant - 20 de minute. Transferul de date pe rețea, încărcare mare pe Tableau. Am realizat că logica cu indicatorii neaditiv trebuie să fie implementată în HANA. Acest lucru nu ne-a speriat prea mult, deoarece aveam deja experiență similară cu BO și Analysis și știm cum să construim vitrine rapide în HANA care oferă indicatori neaditiv corect calculați. Acum, doar trebuia să le adaptăm pentru Tableau.
Etapa 2. Ajustăm vitrinele, fără materializare, totul în timp real.
Am realizat un nou panou separat, care oferea datele necesare pentru TABLEAU în timp real. Î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. Și sincer, ne așteptam ca timpul de răspuns al dashboard-ului în Tableau să fie de 20-30 de secunde la prima deschidere și ulterior, datorită cache-ului, între 10 și 12 secunde, ceea ce ne-ar fi mulțumit în totalitate.
Rezultatul:
Timpul de deschidere a dashboard-ului: 4-5 minute
Orice clic: 3-4 minute
Nimeni nu se aștepta la un astfel de supliment în funcționarea panoului.
Partea 2. Imersie în Tableau
Etapa 1. Analiza performanței Tableau și ajustări rapide
Am început să analizăm pe ce cheltuie Tableau cel mai mult timp. Și există un instrument destul de bun pentru aceasta, ceea ce este, desigur, un avantaj al Tableau. Principala problemă pe care am identificat-o a fost interogările SQL foarte complexe pe care le construia Tableau. Acestea erau legate, în special, de:
— transpunerea datelor. Deoarece Tableau nu are instrumente pentru transpunerea dataset-urilor, pentru a construi partea stângă a dashboard-ului cu o prezentare detaliată a tuturor KPI-urilor, a trebuit să formăm o tabelă folosind case. Dimensiunea interogărilor SQL în baza de date a ajuns la 120.000 de caractere.
— alegerea perioadei de timp. O astfel de interogare la nivel de bază de date necesita mai mult timp pentru compilare decât pentru execuție:
Adică, procesarea interogării 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 panou și la nivelul bazei de date. Acest lucru a adus rezultate bune.
Mai întâi, am efectuat transpunerea în timp real, făcând-o prin full outer join în etapa finală a calculului VIEW, conform unei astfel de abordări descrise pe wiki. și .
Adică, am creat o tabelă de configurare – matricea de transpunere (21x21) și am obținut toți indicatorii într-o defalcare pe linii.
A fost:
A devenit:
Transpunerea bazei de date consumă aproape fără timp. Cererea pentru toate indicatorii pe săptămână a fost procesată, în continuare, în aproximativ 10 secunde. Însă, s-a pierdut flexibilitatea în ceea ce privește construirea tabloului de bord pentru un indicator specific, adică pentru partea dreaptă a tabloului de bord, unde este reprezentată dinamica și detaliile unui indicator specific, vitrina a fost procesată înainte în 1-3 secunde, deoarece cererea se făcea pe un singur indicator, iar acum baza de date selecționează întotdeauna toți indicatorii și filtrează rezultatul înainte de a-l returna în Tableau.
În consecință, viteza de lucru a tabloului de bord a scăzut aproape de 3 ori.
Rezultatul:
- 5 sec — parsarea tabloului de bord, vizualizări
- 15-20 sec — pregătirea pentru compilarea cererilor cu realizarea pre-calculelor în Tableau
- 35-45 sec — compilarea cererilor SQL și executarea lor în paralel-secvențial în Hana
- 5 sec — procesarea rezultatelor, sortarea, recalcularea vizualizărilor în Tableau
- Desigur, astfel de rezultate nu erau acceptabile pentru afacere, așa că am continuat optimizarea.
Etapa 2. Minim de logică în Tableau, materializare completă
Ne-am dat seama că este imposibil să construim un tablou de bord cu un timp de răspuns de câteva secunde pe o vitrină care funcționează în 10 secunde și am luat în considerare opțiuni de materializare a datelor pe partea de bază de date exact pentru tabloul de bord solicitat. Dar ne-am confruntat cu o problemă globală, descrisă mai sus – indicatori neadiționali. Nu am reușit să facem ca, la schimbarea filtrelor sau desfășurărilor, Tableau să comute flexibil între diferite vitrine și niveluri, pre-calculate pentru diferite ierarhii de produse (în exemplu, cele trei cereri fără UTE, cu UTE1 și UTE2 formează rezultate diferite). Prin urmare, am luat decizia de a simplifica tabloul de bord, de a renunța la ierarhia de produse în tablou și de a vedea cât de rapid poate fi într-o versiune simplificată.
Așadar, în această ultimă etapă, am adunat un depozit separat, în care am stocat, în formă transpusă, toate KPI-urile. Pe partea de bază de date, orice cerere către un astfel de depozit este procesată în 0,1 – 0,3 secunde. În tabloul de bord am obținut următoarele rezultate:
Prima deschidere: 8-10 secunde
Fiecare clic: 6-7 secunde
Timpul pe care îl folosește Tableau este format 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ă în paralel cu pct. 1)
- 1,5-2 sec. — renderare, recalcularea vizualizărilor
- 1,3 sec. — execuția interogărilor SQL suplimentare pentru obținerea valorilor relevante ale filtrului (Brand, Divizie, Oraș, Magazin), parsarea rezultatelor
Dacă ar fi să facem un rezumat scurt
Ne-a plăcut instrumentul Tableau din punctul de vedere al vizualizării. În etapa de proiectare am analizat diferite elemente de vizualizare și le-am găsit pe toate în biblioteci, inclusiv segmentări complexe multi-nivel și grafice de tip waterfall cu multiple unități de măsură.
Implementând tablouri de bord cu indicatori cheie de vânzări, ne-am confruntat cu dificultăți de performanță pe care nu le-am putut depăși până acum. Am petrecut mai mult de două luni și am obținut un tablou de bord funcțional incomplet, al cărui timp de răspuns se află la limita acceptabilității. Și am tras concluziile pentru noi:
- Tableau nu poate lucra cu volume mari de date. Dacă în modelul de date de bază aveți mai mult de 10 GB de date (aproximativ 200 mil. x 50 rânduri), tabloul de bord se îngreunează serios – de la 10 secunde până la câteva minute pentru fiecare clic. Am experimentat atât cu live-connect, cât și cu extragerea. Viteza de lucru este similară.
- Limitări la utilizarea mai multor depozite (seturi de date). Nu există opțiunea standard de a specifica relațiile dintre seturile de date. Dacă folosiți soluții ocolitoare pentru a lega seturile de date, acest lucru va afecta semnificativ performanța. În cazul nostru, am considerat varianta materializării datelor în fiecare segment de prezentare necesar și pe aceste seturi de date materializate să facem comutări cu păstrarea filtrelor selectate anterior – acest lucru s-a dovedit imposibil de realizat în Tableau.
- În Tableau, nu este posibil să creați parametrii dinamici. Nu puteți completa un parametru, care este utilizat pentru filtrarea unui set de date în extracție sau la live-connect, cu rezultatul unei alte selecții din setul de date sau rezultatul unei alte interogări SQL, doar cu input nativ al utilizatorului sau o constantă.
- Limitări legate de construirea tabloului de bord cu elemente OLAP|Tabele pivot.
În MSTR, SAP SAC, SAP Analysis, atunci când adăugați un dataset în raport, toate obiectele de pe el sunt legate între ele implicit. În Tableau, acest lucru nu se întâmplă; trebuie să configurați legăturile manual. Poate că este mai flexibil, dar pentru toate tablourile noastre de bord este o cerință obligatorie, așa că aceasta adaugă muncă suplimentară. În plus, dacă faceți filtre legate, astfel încât, de exemplu, la filtrarea regiunii lista orașelor să fie limitată doar la orașele din acea regiune, veți ajunge imediat la interogări secvențiale la baza de date sau la Extract, ceea ce încetinește semnificativ tabloul de bord. - Limitări în funcții. Atât pe extract, cât și CU ATENȚIE pe dataset-ul din Live-connect nu pot fi realizate transformări de masă. Acest lucru se poate face prin Tableau Prep, dar aceasta implică un efort suplimentar și un alt instrument care trebuie studiat și întreținut. De exemplu, nu puteți transpune datele, face un join al acestora cu sine. Ce se blochează prin transformări pe coloane sau câmpuri individuale, care trebuie selectate prin case sau if, generând interogări SQL foarte complexe, unde baza de date își petrece cel mai mult timp compilând textul interogării. Aceste inflexibilități ale instrumentului au trebuit rezolvate la nivelul vitrinei, ceea ce duce la complicarea stocării, încărcărilor și transformărilor suplimentare.
Nu am abandonat Tableau. Dar ca instrument capabil să construiască tablouri de bord industriale și ca mijloc prin care să putem înlocui și digitaliza întreaga sistemă de raportare corporativă a companiei, nu îl considerăm.
În prezent, dezvoltăm activ un tablou de bord similar pe un alt instrument și încercăm, în paralel, să revizuim arhitectura tabloului de bord în Tableau pentru a o simplifica și mai mult. Dacă comunității îi va părea interesant, vom împărtăși rezultatele.
Așteptăm, de asemenea, ideile sau sfaturile dumneavoastră despre cum se pot construi tablouri de bord rapide în Tableau cu astfel de volume mari de date, deoarece avem și un site, unde datele sunt mult mai numeroase decât în comerțul cu amănuntul.
Sursa: habr.com
