Tableau în retail, într-adevăr?

Timpul pentru raportarea în Excel dispare rapid - tendința către instrumente convenabile pentru prezentarea și analiza informațiilor este vizibilă în toate domeniile. Am discutat intern despre digitalizarea raportării de mult timp și am ales sistemul de vizualizare și analiză în sistem self-service Tableau. Alexander Bezugly, șeful departamentului de soluții analitice și raportare al Grupului M.Video-Eldorado, a vorbit despre experiența și rezultatele construirii unui tablou de bord de luptă.

Vă spun imediat că nu s-a realizat tot ce era planificat, dar experiența a fost interesantă, sper să vă fie de folos și vouă. Și dacă cineva are idei despre cum ar putea fi făcut mai bine, aș fi foarte recunoscător pentru sfaturile și ideile dumneavoastră.

Sub tăietura este despre ceea ce am întâlnit și despre ce am învățat.

De unde am început?

M.Video-Eldorado are un model de date bine dezvoltat: informații structurate cu adâncimea de stocare necesară și un număr mare de rapoarte în formă fixă ​​(vezi mai multe detalii aici este acest articol). Din acestea, analiștii realizează fie tabele pivot sau buletine informative formatate în Excel, fie prezentări PowerPoint frumoase pentru utilizatorii finali.

În urmă cu aproximativ doi ani, în loc de rapoarte cu formă fixă, am început să creăm rapoarte analitice în SAP Analysis (un supliment Excel, în esență un tabel pivot peste motorul OLAP). Dar acest instrument nu a fost capabil să răspundă nevoilor tuturor utilizatorilor; majoritatea a continuat să utilizeze informații procesate suplimentar de analiști.

Utilizatorii noștri finali se împart în trei categorii:

Management de top. Solicită informații într-un mod bine prezentat și clar înțeles.

Managementul mediu, utilizatori avansați. Interesat de explorarea datelor și capabil să construiască independent rapoarte dacă instrumentele sunt disponibile. Ei au devenit utilizatorii cheie ai rapoartelor analitice în SAP Analysis.

Utilizatori în masă. Nu sunt interesați să analizeze în mod independent datele; ei folosesc rapoarte cu un grad limitat de libertate, în format de buletine informative și tabele pivot în Excel.

Ideea noastră a fost să acoperim nevoile tuturor utilizatorilor și să le oferim un singur instrument convenabil. Am decis să începem cu top management. Aveau nevoie de tablouri de bord ușor de utilizat pentru a analiza rezultatele cheie ale afacerii. Așadar, am început cu Tableau și am ales mai întâi două direcții: indicatorii de vânzări cu amănuntul și online, cu profunzime și amploare limitate de analiză, care ar acoperi aproximativ 80% din datele solicitate de managementul superior.

Deoarece utilizatorii tablourilor de bord erau management de top, 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ă fie actualizate. Navigarea ar fi trebuit să se facă în 4-5 secunde, sau mai bine zis, făcută instantaneu. Și noi, din păcate, nu am reușit să reușim acest lucru.

Iată cum arăta aspectul tabloului de bord principal:

Ideea cheie este de a combina principalii factori KPI, dintre care au fost 19 în total, în stânga și de a le prezenta dinamica și defalcarea pe principalele atribute în dreapta. Sarcina pare simplă, vizualizarea este logică și de înțeles, până când te scufunzi în detalii.

Detaliu 1. Volumul datelor

Tabelul nostru principal pentru vânzări anuale ocupă aproximativ 300 de milioane de rânduri. Deoarece este necesar să se reflecte dinamica pentru anul trecut și anul precedent, volumul de date doar despre vânzările reale este de aproximativ 1 miliard de linii. Informațiile despre datele planificate și blocul de vânzări online sunt, de asemenea, stocate separat. Prin urmare, chiar dacă am folosit DB SAP HANA în memorie în coloană, viteza interogării cu selecția tuturor indicatorilor timp de o săptămână din stocarea curentă din zbor a fost de aproximativ 15-20 de secunde. Soluția la această problemă se sugerează singură - materializarea suplimentară a datelor. Dar are și capcane, mai multe despre ele mai jos.

Detaliu 2. Indicatori non-aditivi

Multe dintre KPI-urile noastre sunt legate de numărul de chitanțe. Iar acest indicator reprezintă COUNT DISTINCT din numărul de rânduri (verificați anteturile) și arată cantități diferite în funcție de atributele selectate. De exemplu, cum ar trebui calculate acest indicator și derivatul său:

Pentru a face calculele corecte, puteți:

• Calculați astfel de indicatori din mers în depozit;
• Efectuați calcule pe întregul volum de date din Tableau, de ex. la cerere în Tableau, furnizați toate datele conform filtrelor selectate în granularitatea poziției chitanței;
• Creați o vitrină materializată în care toți indicatorii vor fi calculați în toate opțiunile de eșantion care dau rezultate diferite non-aditive.

Este clar că în exemplu UTE1 și UTE2 sunt atribute materiale care reprezintă ierarhia produsului. Acesta nu este un lucru static; managementul în cadrul companiei are loc prin el, pentru că Diferiți manageri sunt responsabili pentru diferite grupuri de produse. Am avut multe revizuiri globale ale acestei ierarhii, când toate nivelurile s-au schimbat, când relațiile au fost revizuite și schimbări constante ale punctelor, când un grup s-a mutat de la un nod la altul. În raportarea convențională, toate acestea sunt calculate din mers din atributele materialului; în cazul materializării acestor date, este necesar să se dezvolte un mecanism de urmărire a acestor modificări și reîncărcare automată a datelor istorice. O sarcină foarte netrivială.

Detaliu 3. Compararea datelor

Acest punct este similar cu cel precedent. Concluzia este că atunci când se analizează o companie, se obișnuiește să se formeze mai multe niveluri de comparație cu perioada anterioară:

Comparație cu perioada anterioară (de la zi la zi, de la săptămână la săptămână, de la lună la lună)

În această comparație, se presupune că, în funcție de perioada selectată de utilizator (de exemplu, a 33-a săptămână a anului), ar trebui să arătăm dinamica până în a 32-a săptămână; dacă am selectat date pentru o lună, de exemplu, mai , atunci această comparație ar arăta dinamica până în aprilie.

Comparatie cu anul trecut

Nuanța principală aici este că, atunci când comparați pe zi și pe săptămână, nu luați aceeași zi a anului trecut, de exemplu. nu poți pune doar anul curent minus unu. Trebuie să vă uitați la ziua săptămânii pe care o comparați. Când comparați luni, dimpotrivă, trebuie să luați exact aceeași zi calendaristică a anului trecut. Există și nuanțe cu anii bisecți. În depozitele originale, toate informațiile sunt distribuite pe zi; nu există câmpuri separate cu săptămâni, luni sau ani. Prin urmare, pentru a obține o secțiune transversală analitică completă în panou, trebuie să numărați nu o perioadă, de exemplu o săptămână, ci 4 săptămâni, apoi să comparați aceste date, să reflectați dinamica, abaterile. În consecință, această logică pentru generarea de comparații în dinamică poate fi implementată fie în Tableau, fie în vitrina. Da, și bineînțeles că am știut și ne-am gândit la aceste detalii în faza de proiectare, dar a fost greu de prezis impactul lor asupra performanței tabloului de bord final.

La implementarea tabloului de bord, am urmat calea lungă Agile. Sarcina noastră a fost să oferim un instrument de lucru cu datele necesare pentru testare cât mai repede posibil. Prin urmare, am mers în sprinturi și am început de la minimizarea lucrărilor pe partea de stocare actuală.

Partea 1: Credința în tablou

Pentru a simplifica suportul IT și a implementa rapid schimbări, am decis să facem logica pentru calcularea indicatorilor non-aditivi și compararea perioadelor trecute în Tableau.

Etapa 1. Totul este live, fără modificări de fereastră.

Î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.

Rezultat:

Răspunsul a fost deprimant - 20 de minute. Transfer de date prin rețea, încărcare mare pe Tableau. Ne-am dat seama că logica cu indicatori non-aditivi trebuie implementată pe HANA. Acest lucru nu ne-a speriat prea mult, aveam deja experiență similară cu BO și Analysis și am știut să construim vitrine rapide în HANA care să producă indicatori non-aditivi calculați corect. Acum nu mai rămânea decât să le adaptăm la Tableau.

Etapa 2. Ajustăm vitrinele, fără materializare, totul din mers.

Am creat o nouă vitrină separată care a produs datele necesare pentru TABLEAU din mers. În general, am obținut un rezultat bun; am redus timpul de generare a tuturor indicatorilor într-o săptămână la 9-10 secunde. Și 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 din cauza cache-ului de la 10 la 12, care în general ni s-ar potrivi.

Rezultat:

Primul tablou de bord deschis: 4-5 minute
Orice clic: 3-4 minute
Nimeni nu se aștepta la o asemenea creștere suplimentară a activității vitrinei.

Partea 2. Scufundați-vă în Tableau

Etapa 1. Analiza performanței tabloului și reglarea rapidă

Am început să analizăm unde își petrece Tableau cea mai mare parte a timpului. Și există instrumente destul de bune pentru asta, ceea ce, desigur, este un plus pentru Tableau. Principala problemă pe care am identificat-o au fost interogările SQL foarte complexe pe care Tableau le construia. Au fost asociate în principal cu:

— transpunerea datelor. Deoarece Tableau nu are instrumente pentru transpunerea seturi de date, pentru a construi partea stângă a tabloului de bord cu o reprezentare detaliată a tuturor KPI-urilor, a trebuit să creăm un tabel folosind un caz. Dimensiunea interogărilor SQL din baza de date a ajuns la 120 de caractere.

- alegerea perioadei de timp. O astfel de interogare la nivel de bază de date a durat mai mult timp pentru compilare decât pentru executare:

Acestea. procesarea cererii 12 secunde + execuție 5 secunde.

Am decis să simplificăm logica de calcul din partea Tableau și să mutăm o altă parte a calculelor la nivelul vitrinei și bazei de date. Acest lucru a adus rezultate bune.

În primul rând, am făcut transpunerea din mers, am făcut-o printr-o îmbinare exterioară completă în etapa finală a calculului VIEW, conform acestei abordări descrise pe wiki Transpunere - Wikipedia, enciclopedia liberă и Matrice elementară - Wikipedia, enciclopedia liberă.

Adică, am făcut un tabel de setare - o matrice de transpunere (21x21) și am primit toți indicatorii într-o defalcare rând cu rând.

A fost:


A devenit:


Aproape că nu se petrece timp pentru transpunerea bazei de date în sine. Solicitarea pentru toți indicatorii pentru săptămână a continuat să fie procesată în aproximativ 10 secunde. Dar, pe de altă parte, flexibilitatea a fost pierdută în ceea ce privește construirea unui tablou de bord bazat pe un indicator specific, de exemplu. pentru partea dreaptă a tabloului de bord unde sunt prezentate dinamica și defalcarea detaliată a unui indicator specific, anterior vitrina funcționa în 1-3 secunde, deoarece cererea se baza pe un indicator, iar acum baza de date selecta întotdeauna toți indicatorii și filtra rezultatul înainte de a returna rezultatul în Tableau.

Ca urmare, viteza tabloului de bord a scăzut de aproape 3 ori.

Rezultat:

1. 5 secunde – parsare tablouri de bord, vizualizări
2. 15-20 de secunde - pregătire pentru compilarea interogărilor cu efectuarea de precalculări în Tableau
3. 35-45 sec - compilarea interogărilor SQL și execuția lor paralel-secvențială în Hana
4. 5 secunde – procesarea rezultatelor, sortarea, recalcularea vizualizărilor în Tableau
5. Desigur, astfel de rezultate nu s-au potrivit afacerii și am continuat optimizarea.

Etapa 2. Logica minimă în Tableau, materializare completă

Am înțeles că este imposibil să construim un tablou de bord cu un timp de răspuns de câteva secunde pe o vitrină care rulează timp de 10 secunde și am luat în considerare opțiunile de materializare a datelor pe partea bazei de date în mod specific pentru tabloul de bord necesar. Dar ne-am confruntat cu o problemă globală descrisă mai sus - indicatorii non-aditivi. Nu am putut să ne asigurăm că atunci când schimbam filtrele sau analizele, Tableau a comutat în mod flexibil între diferite vitrine și niveluri pre-proiectate pentru diferite ierarhii de produse (în exemplu, trei interogări fără UTE, cu UTE1 și UTE2 generează rezultate diferite). Prin urmare, am decis să simplificăm tabloul de bord, să renunțăm la ierarhia produselor din tabloul de bord și să vedem cât de rapid ar putea fi într-o versiune simplificată.

Deci, în această ultimă etapă, am asamblat un depozit separat în care am adăugat toți KPI-urile în formă transpusă. Pe partea bazei de date, orice cerere către o astfel de stocare este procesată în 0,1 - 0,3 secunde. În tabloul de bord am primit următoarele rezultate:

Prima deschidere: 8-10 secunde
Orice clic: 6-7 secunde

Timpul petrecut de Tableau este format din:

1. 0,3 sec. — analizarea tabloului de bord și compilarea interogărilor SQL
2. 1,5-3 sec. — executarea de interogări SQL în Hana pentru vizualizările principale (se rulează în paralel cu pasul 1)
3. 1,5-2 sec. — randare, recalcularea vizualizărilor
4. 1,3 sec. — executarea de interogări SQL suplimentare pentru a obține valori relevante ale filtrului (Brand, Division, City, Store), analizarea rezultatelor

Pentru a rezuma pe scurt

Ne-a plăcut instrumentul Tableau din perspectiva vizualizării. La etapa de prototipare, am luat în considerare diverse elemente de vizualizare și le-am găsit pe toate în biblioteci, inclusiv segmentarea complexă pe mai multe niveluri și cascada cu mai multe drivere.

În timpul implementării tablourilor de bord cu indicatori cheie de vânzări, am întâmpinat dificultăți de performanță pe care încă nu am reușit să le depășim. Am petrecut mai mult de două luni și am primit un tablou de bord incomplet funcțional, a cărui viteză de răspuns este pe punctul de a fi acceptabilă. Și am tras concluziile pentru noi înșine:

1. Tableau nu poate funcționa cu cantități mari de date. Dacă în modelul de date original aveți mai mult de 10 GB de date (aproximativ 200 de milioane X 50 de rânduri), atunci tabloul de bord va încetini serios - de la 10 secunde la câteva minute pentru fiecare clic. Am experimentat atât live-connect, cât și extract. Viteza de funcționare este comparabilă.
2. Limitare la utilizarea mai multor stocări (seturi de date). Nu există nicio modalitate de a indica relația dintre seturile de date folosind mijloace standard. Dacă utilizați soluții pentru a conecta seturi de date, acest lucru va avea un impact semnificativ asupra performanței. În cazul nostru, am luat în considerare opțiunea de a materializa datele în fiecare secțiune de vizualizare necesară și de a face comutări pe aceste seturi de date materializate, păstrând în același timp filtrele selectate anterior - acest lucru s-a dovedit a fi imposibil de realizat în Tableau.
3. Nu este posibil să creați parametri dinamici în Tableau. Nu puteți completa un parametru care este utilizat pentru a filtra un set de date într-un extras sau în timpul unei conexiuni live cu rezultatul unei alte selecții din setul de date sau rezultatul unei alte interogări SQL, doar o intrare de utilizator nativă sau o constantă.
4. Limitări asociate cu construirea unui tablou de bord cu elemente OLAP|PivotTable.
   În MSTR, SAP SAC, SAP Analysis, dacă adăugați un set de date la un raport, atunci toate obiectele de pe acesta sunt legate între ele în mod implicit. Tableau nu are acest lucru; conexiunea trebuie configurată manual. Acest lucru este probabil mai flexibil, dar pentru toate tablourile de bord aceasta este o cerință obligatorie pentru elemente - deci este vorba de costuri suplimentare cu forța de muncă. Mai mult, dacă faci filtre aferente astfel încât, de exemplu, la filtrarea unei regiuni, lista de orașe să fie limitată doar la orașele din această regiune, ajungi imediat la interogări succesive către baza de date sau Extract, ceea ce încetinește vizibil bord.
5. Limitări ale funcțiilor. Transformările în masă nu pot fi făcute nici pe extras, nici mai ales pe setul de date din Live-connecta. Acest lucru se poate face prin Tableau Prep, dar este o muncă suplimentară și un alt instrument de învățat și întreținut. De exemplu, nu puteți transpune date sau nu le puteți asocia. Ceea ce se închide prin transformări pe coloane sau câmpuri individuale, care trebuie selectate prin caz sau dacă, și acest lucru generează interogări SQL foarte complexe, în care baza de date își petrece cea mai mare parte a timpului compilând textul interogării. Această inflexibilitate a instrumentului a trebuit să fie rezolvată la nivel de vitrină, ceea ce duce la stocare mai complexă, descărcări suplimentare și transformări.

Nu am renunțat la Tableau. Dar nu considerăm Tableau ca un instrument capabil să construiască tablouri de bord industriale și un instrument cu care să înlocuim și să digitalizăm întregul sistem de raportare corporativă al unei companii.

Acum dezvoltăm în mod activ un tablou de bord similar într-un alt instrument și, în același timp, încercăm să revizuim arhitectura tabloului de bord în Tableau pentru a o simplifica și mai mult. Dacă comunitatea este interesată, vă vom spune despre rezultate.

De asemenea, așteptăm ideile sau sfaturile voastre cu privire la modul în care în Tabeau puteți construi tablouri de bord rapide pe volume atât de mari de date, deoarece avem un site web unde există mult mai multe date decât în ​​retail.

Sursa: www.habr.com