Čas za poročanje v Excelu hitro izginja – trend priročnih orodij za predstavitev in analizo informacij je viden na vseh področjih. Interno smo se že dlje časa pogovarjali o digitalizaciji poročanja in izbrali sistem za vizualizacijo in samopostrežno analitiko Tableau. Alexander Bezugly, vodja oddelka za analitične rešitve in poročanje skupine M.Video-Eldorado, je spregovoril o izkušnjah in rezultatih izdelave bojne armaturne plošče.
Takoj bom rekel, da ni bilo uresničeno vse, kar je bilo načrtovano, vendar je bila izkušnja zanimiva, upam, da bo koristna tudi vam. In če ima kdo kakšno idejo, kako bi to naredili bolje, bi bil zelo hvaležen za nasvet in ideje.
Spodaj je o tem, s čim smo se srečali in o čem smo se naučili.
Kje smo začeli?
M.Video-Eldorado ima dobro razvit podatkovni model: strukturirane informacije z zahtevano globino shranjevanja in ogromno število poročil v fiksni obliki (glej več podrobnosti ). Iz teh analitiki naredijo vrtilne tabele ali oblikovana glasila v Excelu ali čudovite PowerPoint predstavitve za končne uporabnike.
Pred približno dvema letoma smo namesto poročil s fiksno obliko začeli ustvarjati analitična poročila v SAP Analysis (dodatek za Excel, v bistvu vrtilna tabela preko mehanizma OLAP). Vendar to orodje ni moglo zadovoljiti potreb vseh uporabnikov, večina je še naprej uporabljala informacije, ki so jih dodatno obdelali analitiki.
Naši končni uporabniki so razdeljeni v tri kategorije:
Najvišje vodstvo. Zahteva informacije na dobro predstavljen in jasno razumljiv način.
Srednje vodstvo, napredni uporabniki. Zanima me raziskovanje podatkov in lahko samostojno sestavi poročila, če so na voljo orodja. Postali so ključni uporabniki analitičnih poročil v SAP Analysis.
Množični uporabniki. Samostojno analiziranje podatkov jih ne zanima, uporabljajo poročila z omejeno mero svobode, v obliki glasil in vrtilnih tabel v Excelu.
Naša ideja je bila pokriti potrebe vseh uporabnikov in jim ponuditi eno samo priročno orodje. Odločili smo se, da začnemo pri najvišjem vodstvu. Za analizo ključnih poslovnih rezultatov so potrebovali nadzorne plošče, ki so preproste za uporabo. Tako smo začeli s Tableau in najprej izbrali dve smeri: kazalnike maloprodaje in spletne prodaje z omejeno globino in širino analize, ki bi zajemala približno 80 % podatkov, ki jih zahteva najvišje vodstvo.
Ker so bili uporabniki nadzornih plošč najvišje vodstvo, se je pojavil še en dodaten KPI izdelka - odzivna hitrost. Nihče ne bo čakal 20-30 sekund, da se podatki posodobijo. Navigacija bi morala biti opravljena v 4-5 sekundah ali še bolje, opravljena takoj. In tega nam, žal, ni uspelo doseči.
Tako je izgledala postavitev naše glavne nadzorne plošče:
Ključna ideja je združiti glavne dejavnike KPI, ki jih je bilo skupaj 19, na levi strani in predstaviti njihovo dinamiko in razčlenitev po glavnih atributih na desni. Naloga se zdi preprosta, vizualizacija je logična in razumljiva, dokler se ne potopite v podrobnosti.
Podrobnost 1. Obseg podatkov
Naša glavna tabela za letno prodajo obsega približno 300 milijonov vrstic. Ker je treba odražati dinamiko za lansko in predlansko leto, je obseg podatkov samo o dejanski prodaji približno 1 milijarda vrstic. Ločeno se hranijo tudi podatki o planiranih podatkih in bloku spletne prodaje. Torej, čeprav smo uporabili stolpčni in-memory DB SAP HANA, je bila hitrost poizvedbe z izbiro vseh indikatorjev za en teden iz trenutnega pomnilnika sproti približno 15-20 sekund. Rešitev tega problema se kaže sama od sebe – dodatna materializacija podatkov. Ima pa tudi pasti, o njih več v nadaljevanju.
Detajl 2. Neaditivni indikatorji
Številni naši KPI-ji so vezani na število prejemkov. In ta indikator predstavlja COUNT DISTINCT števila vrstic (preverite glave) in prikazuje različne količine, odvisno od izbranih atributov. Na primer, kako je treba izračunati ta indikator in njegov derivat:
Da bodo izračuni pravilni, lahko:
- Izračunajte takšne kazalnike sproti v shrambi;
- Izvedite izračune na celotnem obsegu podatkov v Tableau, tj. na zahtevo v Tableau posreduje vse podatke po izbranih filtrih v razdrobljenosti prejemne pozicije;
- Ustvarite materializirano predstavitev, v kateri bodo vsi kazalniki izračunani v vseh vzorčnih možnostih, ki dajejo različne neaditivne rezultate.
Jasno je, da sta v primeru UTE1 in UTE2 materialna atributa, ki predstavljata hierarhijo izdelkov. To ni statična stvar, skozi to poteka upravljanje znotraj podjetja, saj Za različne skupine izdelkov so odgovorni različni vodje. Imeli smo veliko globalnih revizij te hierarhije, ko so se spremenile vse ravni, ko so bili revidirani odnosi in stalne spremembe točk, ko se je ena skupina premaknila iz enega vozlišča v drugega. Pri klasičnem poročanju se vse to izračuna sproti iz atributov gradiva, v primeru materializacije teh podatkov pa je treba razviti mehanizem za sledenje takim spremembam in samodejno ponovno nalaganje zgodovinskih podatkov. Zelo netrivialna naloga.
Podrobnost 3. Primerjava podatkov
Ta točka je podobna prejšnji. Bistvo je, da je pri analizi podjetja običajno oblikovati več ravni primerjave s prejšnjim obdobjem:
Primerjava s prejšnjim obdobjem (iz dneva v dan, iz tedna v teden, iz meseca v mesec)
Pri tej primerjavi predpostavljamo, da moramo glede na obdobje, ki ga je izbral uporabnik (na primer 33. teden v letu), prikazati dinamiko do 32. tedna; če smo izbrali podatke za mesec, npr. , potem bi ta primerjava pokazala dinamiko do aprila.
Primerjava z lanskim letom
Glavna niansa pri tem je, da pri primerjavi po dnevih in po tednih ne vzamete istega dneva prejšnjega leta, tj. ne morete samo dati tekočega leta minus ena. Pogledati morate dan v tednu, ki ga primerjate. Nasprotno, ko primerjate mesece, morate vzeti popolnoma enak koledarski dan prejšnjega leta. Obstajajo tudi nianse s prestopnimi leti. V izvirnih repozitorijih so vse informacije razporejene po dnevih; ni ločenih polj s tedni, meseci ali leti. Zato, da bi dobili popoln analitični prerez na plošči, morate šteti ne eno obdobje, na primer teden, ampak 4 tedne, nato pa te podatke primerjati, odražati dinamiko, odstopanja. V skladu s tem je to logiko za ustvarjanje primerjav v dinamiki mogoče implementirati tudi v Tableau ali na strani izložbe. Da, in seveda smo vedeli in razmišljali o teh podrobnostih v fazi načrtovanja, vendar je bilo težko predvideti njihov vpliv na delovanje končne armaturne plošče.
Pri implementaciji armaturne plošče smo sledili dolgi agilni poti. Naša naloga je bila čim hitreje zagotoviti delujoče orodje s potrebnimi podatki za testiranje. Zato smo šli v sprinte in začeli z zmanjševanjem dela na strani trenutnega skladišča.
1. del: Vera v Tableau
Za poenostavitev IT podpore in hitro implementacijo sprememb smo se odločili, da logiko za izračun neaditivnih kazalnikov in primerjavo preteklih obdobij naredimo v Tableau.
Faza 1. Vse je v živo, brez sprememb oken.
Na tej stopnji smo Tableau povezali s trenutnimi izložbami in se odločili videti, kako se bo izračunalo število prejemkov za eno leto.
Rezultat:
Odgovor je bil depresiven - 20 minut. Prenos podatkov po omrežju, visoka obremenitev Tableau. Ugotovili smo, da je treba na HANA implementirati logiko z neaditivnimi indikatorji. To nas ni veliko prestrašilo, imeli smo že podobne izkušnje z BO in Analysis in znali smo zgraditi hitre vitrine v HANA, ki proizvajajo pravilno izračunane neaditivne indikatorje. Zdaj jih je preostalo le še prilagoditi Tableau.
2. faza. Vitrine uglasimo, brez materializacije, vse sproti.
Ustvarili smo ločeno novo predstavitev, ki je sproti proizvajala zahtevane podatke za TABLEAU. Na splošno smo dobili dober rezultat, zmanjšali smo čas za generiranje vseh indikatorjev v enem tednu na 9-10 sekund. In pošteno smo pričakovali, da bo v Tableau odzivni čas armaturne plošče ob prvem odpiranju 20-30 sekund, nato pa zaradi predpomnilnika od 10 do 12, kar bi nam na splošno ustrezalo.
Rezultat:
Prva odprta armaturna plošča: 4-5 minut
Vsak klik: 3-4 minute
Nihče ni pričakoval tako dodatnega povečanja dela izložbe.
2. del. Potopite se v Tableau
Faza 1. Analiza zmogljivosti Tableau in hitra nastavitev
Začeli smo analizirati, kje Tableau preživi največ časa. In za to obstajajo precej dobra orodja, kar je seveda plus Tableau. Glavna težava, ki smo jo ugotovili, so bile zelo zapletene poizvedbe SQL, ki jih je gradil Tableau. Povezani so bili predvsem z:
— prenos podatkov. Ker Tableau nima orodij za prenos naborov podatkov, smo morali za izdelavo leve strani nadzorne plošče s podrobno predstavitvijo vseh KPI ustvariti tabelo s primerom. Velikost poizvedb SQL v bazi podatkov je dosegla 120 znakov.
- izbira časovnega obdobja. Prevajanje takšne poizvedbe na ravni baze podatkov je trajalo več časa za prevajanje kot za izvedbo:
Tisti. obdelava zahtevka 12 sekund + 5 sekund izvedba.
Odločili smo se, da poenostavimo logiko izračuna na strani Tableau in drugi del izračunov premaknemo na raven trgovine in baze podatkov. To je prineslo dobre rezultate.
Najprej smo transpozicijo izvedli sproti, to smo izvedli s popolnim zunanjim združevanjem v končni fazi izračuna VIEW, v skladu s tem pristopom, opisanim v wikiju и .
To pomeni, da smo naredili nastavitveno tabelo - transpozicijsko matriko (21x21) in prejeli vse kazalnike v razčlenitvi po vrsticah.
Bilo je:
Postati:
Skoraj nič časa se ne porabi za sam prenos baze podatkov. Zahteva za vse kazalnike za teden se je nadaljevala v približno 10 sekundah. Toda po drugi strani se je izgubila fleksibilnost v smislu konstruiranja armaturne plošče na podlagi določenega indikatorja, tj. za desno stran armaturne plošče, kjer je predstavljena dinamika in podrobna razčlenitev določenega kazalnika, je prej zaslon deloval v 1-3 sekundah, ker zahteva je temeljila na enem indikatorju, zdaj pa je zbirka podatkov vedno izbrala vse indikatorje in filtrirala rezultat, preden je rezultat vrnila v Tableau.
Posledično se je hitrost armaturne plošče zmanjšala za skoraj 3-krat.
Rezultat:
- 5 sekund – razčlenjevanje nadzornih plošč, vizualizacije
- 15-20 sekund - priprava na sestavljanje poizvedb z izvajanjem predizračunov v Tableau
- 35-45 sek - sestavljanje poizvedb SQL in njihovo vzporedno-zaporedno izvajanje v Hani
- 5 sec – obdelava rezultatov, sortiranje, preračunavanje vizualizacij v Tableau
- Takšni rezultati seveda niso ustrezali poslu in smo nadaljevali z optimizacijo.
Faza 2. Minimalna logika v Tableau, popolna materializacija
Razumeli smo, da je nemogoče zgraditi nadzorno ploščo z odzivnim časom nekaj sekund na izložbi, ki deluje 10 sekund, zato smo razmislili o možnostih materializacije podatkov na strani baze podatkov posebej za zahtevano nadzorno ploščo. Toda naleteli smo na zgoraj opisan globalni problem - neaditivni kazalniki. Nismo se mogli prepričati, da je Tableau pri spreminjanju filtrov ali vrtanja prožno preklapljal med različnimi izložbami in ravnmi, vnaprej zasnovanimi za različne hierarhije izdelkov (v primeru tri poizvedbe brez UTE, z UTE1 in UTE2 ustvarijo različne rezultate). Zato smo se odločili poenostaviti nadzorno ploščo, opustiti hierarhijo izdelkov na nadzorni plošči in preveriti, kako hitra bi lahko bila v poenostavljeni različici.
Tako smo na zadnji stopnji sestavili ločeno skladišče, v katerega smo dodali vse KPI-je v preneseni obliki. Na strani baze podatkov je vsaka zahteva za takšno shrambo obdelana v 0,1 - 0,3 sekunde. Na nadzorni plošči smo prejeli naslednje rezultate:
Prvo odpiranje: 8-10 sekund
Vsak klik: 6-7 sekund
Čas, ki ga porabi Tableau, je sestavljen iz:
- 0,3 s — razčlenjevanje nadzorne plošče in zbiranje poizvedb SQL
- 1,5-3 sek. — izvajanje poizvedb SQL v Hani za glavne vizualizacije (teče vzporedno s 1. korakom)
- 1,5-2 sek. — upodabljanje, preračunavanje vizualizacij
- 1,3 sekunde — izvedba dodatnih poizvedb SQL za pridobitev ustreznih vrednosti filtra (Brand, Division, City, Store), rezultati razčlenjevanja
Če na kratko povzamem
Orodje Tableau nam je bilo všeč z vidika vizualizacije. Na stopnji izdelave prototipov smo upoštevali različne elemente vizualizacije in jih vse našli v knjižnicah, vključno s kompleksno segmentacijo na več ravneh in slapom z več gonilniki.
Pri implementaciji nadzornih plošč s ključnimi kazalniki prodaje smo naleteli na težave pri delovanju, ki nam jih še ni uspelo premagati. Porabili smo več kot dva meseca in prejeli funkcionalno nedokončano armaturno ploščo, katere odzivnost je na meji sprejemljivega. In sami smo naredili zaključke:
- Tableau ne more delati z velikimi količinami podatkov. Če imate v izvirnem podatkovnem modelu več kot 10 GB podatkov (približno 200 milijonov X 50 vrstic), se bo nadzorna plošča resno upočasnila - od 10 sekund do nekaj minut za vsak klik. Eksperimentirali smo s povezovanjem v živo in izvlečkom. Hitrost delovanja je primerljiva.
- Omejitev pri uporabi več shramb (naborov podatkov). Ni načina, da bi s standardnimi sredstvi označili razmerje med nizi podatkov. Če uporabite rešitve za povezovanje naborov podatkov, bo to močno vplivalo na zmogljivost. V našem primeru smo upoštevali možnost materializacije podatkov v vsakem zahtevanem odseku pogleda in preklopov na te materializirane nize podatkov ob ohranjanju predhodno izbranih filtrov - izkazalo se je, da je to v Tableau nemogoče narediti.
- V Tableau ni mogoče ustvariti dinamičnih parametrov. Parametra, ki se uporablja za filtriranje nabora podatkov v izvlečku ali med povezovanjem v živo, ne morete izpolniti z rezultatom druge izbire iz nabora podatkov ali rezultatom druge poizvedbe SQL, samo izvornim uporabniškim vnosom ali konstanto.
- Omejitve, povezane z izdelavo nadzorne plošče z elementi OLAP|PivotTable.
V MSTR, SAP SAC, SAP Analysis, če v poročilo dodate nabor podatkov, so vsi objekti v njem privzeto povezani med seboj. Tableau tega nima, povezavo je treba nastaviti ročno. To je verjetno bolj prilagodljivo, a za vse naše armaturne plošče je to obvezna zahteva za elemente – torej so to dodatni stroški dela. Poleg tega, če naredite povezane filtre, tako da je na primer pri filtriranju regije seznam mest omejen samo na mesta te regije, takoj končate z zaporednimi poizvedbami v zbirki podatkov ali izvlečku, kar opazno upočasni armaturna plošča. - Omejitve funkcij. Masovnih transformacij ni mogoče izvesti niti na izvlečku niti, POSEBEJ, na naboru podatkov iz Live-connecta. To je mogoče storiti s Tableau Prep, vendar je to dodatno delo in še eno orodje za učenje in vzdrževanje. Podatkov na primer ne morete prenesti ali jih združiti samih s seboj. Kaj se zapre s transformacijami na posameznih stolpcih ali poljih, ki jih je treba izbrati skozi case ali if, kar generira zelo zapletene SQL poizvedbe, pri katerih baza porabi večino časa za sestavljanje besedila poizvedbe. To neprilagodljivost orodja je bilo treba rešiti na ravni predstavitve, kar vodi do bolj zapletenega shranjevanja, dodatnih prenosov in transformacij.
Tableau nismo obupali. Toda Tableau ne smatramo za orodje, ki bi lahko zgradilo industrijske nadzorne plošče in orodje, s katerim bi nadomestili in digitalizirali celoten sistem korporativnega poročanja podjetja.
Zdaj aktivno razvijamo podobno nadzorno ploščo v drugem orodju in hkrati poskušamo spremeniti arhitekturo nadzorne plošče v Tableau, da bi jo še bolj poenostavili. Če bo skupnost zainteresirana, vam bomo sporočili rezultate.
Čakamo tudi na vaše ideje ali nasvete, kako v Tabeau zgraditi hitre nadzorne plošče nad tako velikimi količinami podatkov, saj imamo spletno stran, kjer je veliko več podatkov kot v maloprodaji.
Vir: www.habr.com