Čas na reporting v Exceli sa rýchlo míňa – trend smerom k pohodlným nástrojom na prezentáciu a analýzu informácií je viditeľný vo všetkých oblastiach. O digitalizácii reportingu sme interne diskutovali už dlhšie a vybrali sme si vizualizačný a samoobslužný analytický systém Tableau. Alexander Bezugly, vedúci oddelenia analytických riešení a reportingu skupiny M.Video-Eldorado, hovoril o skúsenostiach a výsledkoch budovania bojového dashboardu.
Hneď poviem, že nie všetko, čo bolo plánované, sa zrealizovalo, ale skúsenosť to bola zaujímavá, dúfam, že bude užitočná aj pre vás. A ak má niekto nejaké nápady, ako by sa to dalo urobiť lepšie, budem veľmi vďačný za vaše rady a nápady.
Pod strihom je o tom, s čím sme sa stretli a o čom sme sa dozvedeli.
Kde sme začali?
M.Video-Eldorado má dobre vyvinutý dátový model: štruktúrované informácie s požadovanou hĺbkou uloženia a obrovské množstvo reportov v pevnej forme (pozri viac podrobností ). Analytici z nich vytvárajú buď kontingenčné tabuľky alebo formátované bulletiny v Exceli, alebo krásne prezentácie v PowerPointe pre koncových používateľov.
Asi pred dvoma rokmi sme namiesto pevných zostáv začali vytvárať analytické zostavy v SAP Analysis (doplnok Excelu, v podstate kontingenčná tabuľka nad OLAP engine). Tento nástroj však nedokázal uspokojiť potreby všetkých používateľov, väčšina naďalej využívala informácie dodatočne spracované analytikmi.
Naši koncoví používatelia sa delia do troch kategórií:
Vrcholový manažment. Požaduje informácie dobre podaným a jasne zrozumiteľným spôsobom.
Stredný manažment, pokročilí používatelia. Zaujímate sa o prieskum údajov a dokážete nezávisle vytvárať prehľady, ak sú k dispozícii nástroje. Stali sa kľúčovými používateľmi analytických zostáv v SAP Analysis.
Masoví používatelia. Nezaujíma ich nezávislá analýza dát, používajú reporty s obmedzenou mierou voľnosti, vo formáte newsletterov a kontingenčných tabuliek v Exceli.
Našou myšlienkou bolo pokryť potreby všetkých používateľov a poskytnúť im jediný pohodlný nástroj. Rozhodli sme sa začať s vrcholovým manažmentom. Potrebovali jednoducho použiteľné dashboardy na analýzu kľúčových obchodných výsledkov. Začali sme teda s Tableau a najprv sme si vybrali dva smery: maloobchodné a online ukazovatele predaja s obmedzenou hĺbkou a šírkou analýzy, ktoré by pokrývali približne 80 % údajov požadovaných vrcholovým manažmentom.
Keďže používateľmi dashboardov boli vrcholový manažment, objavil sa ďalší dodatočný KPI produktu – rýchlosť odozvy. Nikto nebude čakať 20-30 sekúnd na aktualizáciu údajov. Navigácia by mala byť vykonaná do 4-5 sekúnd, alebo ešte lepšie, okamžite. A to sa nám, žiaľ, nepodarilo dosiahnuť.
Takto vyzeralo rozloženie našej hlavnej palubnej dosky:
Kľúčovou myšlienkou je skombinovať hlavné ťahúne KPI, ktorých bolo celkovo 19, vľavo a prezentovať ich dynamiku a členenie podľa hlavných atribútov vpravo. Úloha sa zdá jednoduchá, vizualizácia je logická a zrozumiteľná, kým sa neponoríte do detailov.
Detail 1. Objem dát
Naša hlavná tabuľka ročného predaja zaberá približne 300 miliónov riadkov. Keďže je potrebné premietnuť dynamiku za minulý a predminulý rok, objem údajov len o skutočných tržbách je okolo 1 miliardy riadkov. Oddelene sa ukladajú aj informácie o plánovaných údajoch a blok online predaja. Preto aj keď sme použili stĺpcovú in-memory DB SAP HANA, rýchlosť dotazu s výberom všetkých indikátorov na jeden týždeň z aktuálneho úložiska za chodu bola cca 15-20 sekúnd. Riešenie tohto problému sa navrhuje samo – dodatočná materializácia údajov. Má to však aj úskalia, viac o nich nižšie.
Detail 2. Neaditívne ukazovatele
Mnohé z našich KPI sú viazané na počet príjmov. A tento indikátor predstavuje COUNT DISTINCT počtu riadkov (kontrolných hlavičiek) a zobrazuje rôzne množstvá v závislosti od zvolených atribútov. Napríklad, ako by sa mal tento ukazovateľ a jeho derivát vypočítať:
Aby boli vaše výpočty správne, môžete:
- Vypočítajte takéto ukazovatele za chodu v sklade;
- Vykonajte výpočty na celý objem dát v Tableau, t.j. na požiadanie v Tableau poskytnúť všetky údaje podľa vybraných filtrov v granularite pozície účtenky;
- Vytvorte materializovanú vitrínu, v ktorej budú vypočítané všetky ukazovatele vo všetkých možnostiach vzorky, ktoré poskytujú rôzne neaditívne výsledky.
Je zrejmé, že v príklade UTE1 a UTE2 sú materiálové atribúty reprezentujúce hierarchiu produktov. Nejde o statickú vec, cez ňu prebieha riadenie v rámci firmy, pretože Rôzni manažéri sú zodpovední za rôzne skupiny produktov. Mali sme veľa globálnych revízií tejto hierarchie, keď sa zmenili všetky úrovne, keď sa revidovali vzťahy, a neustále bodové zmeny, keď sa jedna skupina presúvala z jedného uzla do druhého. Pri klasickom reportingu sa to všetko počíta za chodu z atribútov materiálu, v prípade materializácie týchto dát je potrebné vyvinúť mechanizmus na sledovanie takýchto zmien a automatické opätovné načítanie historických dát. Veľmi netriviálna úloha.
Detail 3. Porovnanie údajov
Tento bod je podobný predchádzajúcemu. Pointa je, že pri analýze spoločnosti je zvykom vytvoriť niekoľko úrovní porovnania s predchádzajúcim obdobím:
Porovnanie s predchádzajúcim obdobím (zo dňa na deň, z týždňa na týždeň, z mesiaca na mesiac)
V tomto porovnaní sa predpokladá, že v závislosti od obdobia zvoleného používateľom (napríklad 33. týždeň v roku) by sme mali dynamiku zobraziť do 32. týždňa, ak by sme vybrali údaje za mesiac, napríklad máj , potom by toto porovnanie ukázalo dynamiku do apríla.
Porovnanie s minulým rokom
Hlavnou nuansou je, že pri porovnávaní podľa dňa a týždňa neberiete rovnaký deň minulého roka, t.j. nemôžete dať aktuálny rok mínus jedna. Musíte sa pozrieť na deň v týždni, ktorý porovnávate. Pri porovnávaní mesiacov je naopak potrebné vziať presne ten istý kalendárny deň minulého roka. Existujú aj nuansy s priestupnými rokmi. V pôvodných úložiskách sú všetky informácie distribuované podľa dní, neexistujú žiadne samostatné polia s týždňami, mesiacmi alebo rokmi. Preto, aby ste získali úplný analytický prierez v paneli, musíte počítať nie jedno obdobie, napríklad týždeň, ale 4 týždne, a potom tieto údaje porovnať, odrážať dynamiku, odchýlky. V súlade s tým môže byť táto logika na generovanie porovnaní dynamiky implementovaná buď v Tableau alebo na strane výkladu. Áno, a samozrejme sme o týchto detailoch vedeli a premýšľali o nich už vo fáze návrhu, ale bolo ťažké predpovedať ich vplyv na výkon konečnej palubnej dosky.
Pri implementácii palubnej dosky sme išli dlhou agilnou cestou. Našou úlohou bolo čo najrýchlejšie poskytnúť pracovný nástroj s potrebnými údajmi na testovanie. Preto sme išli do šprintov a začali sme od minimalizácie práce na strane súčasného úložiska.
Časť 1: Viera v tabuľu
Aby sme zjednodušili IT podporu a rýchlo implementovali zmeny, rozhodli sme sa vytvoriť logiku pre výpočet neaditívnych ukazovateľov a porovnávanie minulých období v Tableau.
Fáza 1. Všetko je živé, žiadne úpravy okien.
V tejto fáze sme pripojili Tableau k súčasným výkladom a rozhodli sme sa zistiť, ako sa vypočíta počet účteniek za jeden rok.
Výsledok:
Odpoveď bola deprimujúca – 20 minút. Prenos dát po sieti, vysoká záťaž na Tableau. Uvedomili sme si, že na HANA je potrebné implementovať logiku s neaditívnymi ukazovateľmi. To nás veľmi nevystrašilo, s BO a analýzou sme už mali podobné skúsenosti a vedeli sme v HANA postaviť rýchle vitríny, ktoré produkujú správne vypočítané neaditívne ukazovatele. Teraz ich už len ostávalo upraviť na Tableau.
Etapa 2. Ladíme vitríny, žiadne zhmotňovanie, všetko za pochodu.
Vytvorili sme samostatnú novú vitrínu, ktorá poskytovala požadované údaje pre TABLEAU za chodu. Vo všeobecnosti sme dosiahli dobrý výsledok, čas na generovanie všetkých indikátorov za týždeň sme skrátili na 9-10 sekúnd. A úprimne sme očakávali, že v Tableau bude doba odozvy palubnej dosky 20-30 sekúnd pri prvom otvorení a potom kvôli vyrovnávacej pamäti od 10 do 12, čo by nám vo všeobecnosti vyhovovalo.
Výsledok:
Prvé otvorenie prístrojovej dosky: 4-5 minút
Akékoľvek kliknutie: 3-4 minúty
Nikto neočakával taký dodatočný nárast práce výkladu.
Časť 2. Ponorte sa do Tableau
Fáza 1. Analýza výkonu tabla a rýchle ladenie
Začali sme analyzovať, kde Tableau trávi väčšinu času. A existujú na to celkom dobré nástroje, čo je, samozrejme, plus Tableau. Hlavným problémom, ktorý sme identifikovali, boli veľmi zložité SQL dotazy, ktoré Tableau vytváralo. Súviseli predovšetkým s:
— transpozícia údajov. Keďže Tableau nemá nástroje na transpozíciu množín údajov, na zostavenie ľavej strany dashboardu s podrobným znázornením všetkých KPI sme museli vytvoriť tabuľku pomocou prípadu. Veľkosť SQL dotazov v databáze dosiahla 120 000 znakov.
- výber časového obdobia. Kompilácia takéhoto dotazu na úrovni databázy trvala viac času ako vykonanie:
Tie. spracovanie požiadavky 12 sekúnd + 5 sekúnd vykonanie.
Rozhodli sme sa zjednodušiť výpočtovú logiku na strane Tableau a presunúť ďalšiu časť výpočtov na úroveň obchodu a databázy. To prinieslo dobré výsledky.
Najprv sme urobili transpozíciu za behu, urobili sme to cez úplné vonkajšie spojenie v konečnej fáze výpočtu VIEW, podľa tohto prístupu opísaného na wiki и .
To znamená, že sme urobili nastavovaciu tabuľku - transpozičnú maticu (21x21) a dostali sme všetky ukazovatele v členení podľa riadkov.
To bolo:
Sa stal:
Na samotnú transpozíciu databázy sa nevenuje takmer žiadny čas. Požiadavka na všetky indikátory pre daný týždeň pokračovala v spracovaní približne za 10 sekúnd. No na druhej strane sa stratila flexibilita z hľadiska konštrukcie palubnej dosky na základe konkrétneho ukazovateľa, t.j. pre pravú stranu palubnej dosky, kde je prezentovaná dynamika a podrobný rozpis konkrétneho ukazovateľa, predtým okno displeja fungovalo za 1-3 sekundy, pretože požiadavka bola založená na jednom ukazovateli a teraz databáza vždy vybrala všetky ukazovatele a filtrovala výsledok pred vrátením výsledku do Tableau.
V dôsledku toho sa rýchlosť palubnej dosky znížila takmer 3-krát.
Výsledok:
- 5 sekúnd – analýza dashboardov, vizualizácie
- 15-20 sekúnd - príprava na zostavenie dopytov s vykonaním predbežných výpočtov v Tableau
- 35-45 sek. - kompilácia SQL dotazov a ich paralelné sekvenčné vykonávanie v Hana
- 5 sek – spracovanie výsledkov, triedenie, prepočítavanie vizualizácií v Tableau
- Samozrejme, takéto výsledky biznisu nevyhovovali a pokračovali sme v optimalizácii.
Fáza 2. Minimálna logika v Tableau, úplná materializácia
Pochopili sme, že nie je možné postaviť dashboard s dobou odozvy niekoľkých sekúnd na výklade, ktorý beží 10 sekúnd, a zvážili sme možnosti zhmotnenia údajov na strane databázy špeciálne pre požadovaný dashboard. Ale narazili sme na globálny problém popísaný vyššie - neaditívne ukazovatele. Nedokázali sme sa uistiť, že pri zmene filtrov alebo podrobných analýz Tableau flexibilne prepínalo medzi rôznymi výkladmi a úrovňami vopred navrhnutými pre rôzne hierarchie produktov (v príklade tri dotazy bez UTE, s UTE1 a UTE2 generujú rôzne výsledky). Preto sme sa rozhodli zjednodušiť dashboard, opustiť hierarchiu produktov v dashboarde a pozrieť sa, aký rýchly by mohol byť v zjednodušenej verzii.
V tejto poslednej fáze sme teda zostavili samostatné úložisko, do ktorého sme pridali všetky kľúčové ukazovatele výkonu v transponovanej forme. Na strane databázy je každá požiadavka na takéto úložisko spracovaná za 0,1 – 0,3 sekundy. Na paneli sme dostali nasledujúce výsledky:
Prvé otvorenie: 8-10 sekúnd
Akékoľvek kliknutie: 6-7 sekúnd
Čas strávený Tableau pozostáva z:
- 0,3 sek. — analýza a kompilácia SQL dotazov na dashboarde
- 1,5-3 sek. — vykonávanie SQL dotazov v Hana pre hlavné vizualizácie (beží súbežne s krokom 1)
- 1,5-2 sek. — rendering, prepočet vizualizácií
- 1,3 sek. — vykonanie dodatočných SQL dotazov na získanie relevantných hodnôt filtra (značka, divízia, mesto, obchod), analýza výsledkov
Aby som to stručne zhrnul
Nástroj Tableau sa nám páčil z pohľadu vizualizácie. Vo fáze prototypovania sme zvažovali rôzne prvky vizualizácie a všetky sme ich našli v knižniciach, vrátane komplexnej viacúrovňovej segmentácie a vodopádu s viacerými ovládačmi.
Pri implementácii dashboardov s kľúčovými ukazovateľmi predaja sme narazili na výkonnostné ťažkosti, ktoré sa nám zatiaľ nepodarilo prekonať. Strávili sme viac ako dva mesiace a dostali sme funkčne nekompletný prístrojový panel, ktorého rýchlosť odozvy je na hranici akceptovateľnosti. A vyvodili sme závery pre seba:
- Tableau nedokáže pracovať s veľkým množstvom údajov. Ak máte v pôvodnom dátovom modeli viac ako 10 GB údajov (približne 200 miliónov X 50 riadkov), potom sa palubná doska vážne spomalí - z 10 sekúnd na niekoľko minút na každé kliknutie. Experimentovali sme s live-connect aj extraktom. Prevádzková rýchlosť je porovnateľná.
- Obmedzenie pri používaní viacerých úložísk (súborov údajov). Neexistuje spôsob, ako naznačiť vzťah medzi súbormi údajov pomocou štandardných prostriedkov. Ak na pripojenie množín údajov použijete riešenia, výrazne to ovplyvní výkon. V našom prípade sme zvažovali možnosť materializácie údajov v každej požadovanej sekcii zobrazenia a prepínačov na týchto materializovaných súboroch údajov pri zachovaní predtým zvolených filtrov – to sa v Tableau ukázalo ako nemožné.
- V Tableau nie je možné vytvárať dynamické parametre. Parameter, ktorý sa používa na filtrovanie množiny údajov v extrakte alebo počas živého pripojenia, nemôžete vyplniť výsledkom iného výberu z množiny údajov alebo výsledkom iného dotazu SQL, iba vstupom natívneho používateľa alebo konštantou.
- Obmedzenia spojené s vytváraním dashboardu s prvkami OLAP|PivotTable.
Ak v MSTR, SAP SAC, SAP Analysis pridáte množinu údajov do zostavy, potom všetky objekty na nej budú predvolene navzájom súvisiace. Tableau toto nemá, pripojenie je potrebné nakonfigurovať manuálne. Toto je pravdepodobne flexibilnejšie, ale pre všetky naše prístrojové dosky je to povinná požiadavka na prvky – ide teda o dodatočné náklady na prácu. Navyše, ak urobíte súvisiace filtre tak, že napríklad pri filtrovaní regiónu je zoznam miest obmedzený len na mestá tohto regiónu, okamžite skončíte s postupnými dopytmi do databázy alebo výpisu, čo citeľne spomaľuje prístrojová doska. - Obmedzenia vo funkciách. Hromadné transformácie nie je možné vykonať ani na extrakte, ani HLAVNE na súbore údajov z Live-connecta. Dá sa to urobiť pomocou Tableau Prep, ale je to ďalšia práca a ďalší nástroj, ktorý sa treba naučiť a udržiavať. Nemôžete napríklad transponovať údaje alebo ich spojiť so sebou samými. Čo sa uzatvára cez transformácie na jednotlivých stĺpcoch alebo poliach, ktoré je potrebné voliť cez veľkosť písmen alebo ak, a to generuje veľmi zložité SQL dotazy, pri ktorých databáza väčšinu času strávi zostavovaním textu dotazu. Táto nepružnosť nástroja musela byť vyriešená na úrovni showcase, čo vedie k zložitejšiemu ukladaniu, ďalším sťahovaniam a transformáciám.
Na Tableau sme to nevzdali. Tableau však nepovažujeme za nástroj schopný budovať priemyselné dashboardy a nástroj, pomocou ktorého možno nahradiť a digitalizovať celý firemný systém výkazníctva.
Teraz aktívne vyvíjame podobný dashboard v inom nástroji a zároveň sa snažíme revidovať architektúru dashboardu v Tableau, aby sme ju ešte viac zjednodušili. Ak bude mať komunita záujem, o výsledkoch vás budeme informovať.
Čakáme aj na vaše nápady či rady, ako sa v Tabeau dajú postaviť rýchle dashboardy nad takým veľkým objemom dát, pretože máme web, kde je dát oveľa viac ako v retaile.
Zdroj: hab.com