Tableau ja jaotuses, kas see on tõesti võimalik?

Excelis aruandmisaeg on kiiresti möödas — mugavate info esitamise ja analüüsi tööriistade suundumus on nähtav kõigis valdkondades. Oleme juba ammu arutanud digiteerimistsüklit ja valinud visualiseerimise ja iseteeninduse analüüsi süsteemiks Tableau. Aleksandr Bezugly, analüütiliste lahenduste ja aruandluse osakonna juht M.Video-Eldorado grupis, rääkis lahinguplaani dashboard'i ehitamise kogemusest ja tulemustest.

Saan kohe öelda, et mitte kõike, mis oli plaanitud, ei õnnestunud ellu viia, kuid kogemus oli huvitav, loodan, et see on kasulik ka teile. Kui kellelgi on ideid, kuidas oleks saanud paremini teha – olen väga tänulik nõuannete ja ideede eest.

Allpool on, millega me silmitsi seisime ja mida õppisime.

Kust me alustasime

M.Video-Eldorados on hästi läbimõeldud andmemudel: struktureeritud teave vajaliku salvestuse sügavusega ja tohutu hulk fikseeritud vormi aruandeid (vt lähemalt seda artiklit). Nendest teevad analüütikud kas kokkuvõtteid või vormindatud jagamisi Excelis, või ilusate esitlustena PowerPointis lõppkasutajatele.

Umbes kaks aastat tagasi hakkasime fikseeritud vormi aruannete asemel looma analüütilisi aruandeid SAP Analysis'is (Exceli lisand, põhimõtteliselt — kokkuvõtte tabel OLAP mootoril). Kuid see tööriist ei suutnud katta kõigi kasutajate vajadusi, enamik jätkas teabe kasutamist, mille analüütikud on täiendavalt töötlenud.

Meie lõppkasutajad jagunevad kolme kategooriasse:

Tippjuhtkond. Küsi teavet hästi esitatud ja arusaadavas vormis.

Keskmine juhtkond, edasijõudnud kasutajad. Huvi avaldavad andmete uurimise vastu ja suudavad iseseisvalt aruandeid koostada, kui neil on tööriistad. Just nemad on saanud SAP Analysis'i analüütiliste aruannete võtmekasutajateks.

Mugavad kasutajad. Ei tunne huvi iseseisva andmete analüüsi vastu, kasutavad aruandeid piiratud vabaduse astmega, jagamisformaatides ja kokkuvõtte tabelites Excelis.

Meie idee oli rahuldada kõikide kasutajate vajadused ja anda neile üks mugav tööriist. Otsustasime alustada tippjuhtkonnast. Neil olid vaja mugavaid paneele põhiväärtuste analüüsimiseks. Nii alustasime Tableau'ga ja valisime alguseks kaks suunda: jaemüügimüügi ja online müügi näitajad piiratud sügavuse ja laiusega analüüsis, mis kataks umbes 80% tippjuhtkonna nõutud andmetest.

Kuna armatuurlaudade kasutajad olid tippjuhtkond, lisandus veel üks toote täiendav KPI – reageerimiskiirus. Keegi ei taha oodata 20-30 sekundit, kuni andmed uuenevad. Navigeerimine pidi mahtuma 4-5 sekundi sisse, või veel parem, töötama koheselt. Ja seda me, kahjuks, saavutada ei suutnud.

Nii nägi välja meie põhilaudade makett:

Põhijoon on koondada peamised KPI-mootorid, mida kokku tuli 19, vasakule ja esitada nende dünaamika ja jaotus peamiste atribuutide järgi paremale. Ülesanne näib lihtne, visualiseerimine loogiline ja arusaadav, kuni ei lähe detailidesse.

Detail 1. Andmemaht

Peamine aastane müügitaabel hõlmab meid umbes 300 miljonit rida. Kuna on vajalik peegeldada ka dünaamikat eelnevatest ja üle-eelmistest aastatest, on andmemaht ainult tegelike müükide osas umbes 1 miljard rida. Ja lisaks hoitakse eraldi teavet planeeritud andmete ja internetimüügi kohta. Seetõttu, vaatamata sellele, et kasutasime veergude põhist in-memory andmebaasi SAP HANA, töötas päringu kiirus, mis valis kõik näitajad ühe nädala kohta praegustest ladustamistest reaalajas, umbes 15-20 sekundit. Selle ülesande lahendus on ilmselge – täiendav andmete materialiseerimine. Kuid sellel on ka oma allveesüngid, neist räägime allpool.

Detail 2. Mitteadditiivsed näitajad

Meil on paljusid KPI-sid seotud tšekkide arvu kohta. Ja see näitaja kujutab endast DISTINCT COUNT ridade arvu (tšekkide pealkirjad) ja näitab erinevaid summasid sõltuvalt valitud atribuutidest. Näitena, kuidas seda näitajat ja sellest tulenevat tuleks arvestada:

Arvutuste täpsuse tagamiseks saab:

• Selliste näitajate arvutamine reaalajas andmehoidlas;
• Arvutada kogu andmemahu põhjal Tableau's, st Tableau'sse päring tehes anda kõik valitud filtrite järgi andmed tšekkide positsioonide granulaarsuses;
• Luua materialiseeritud vitriin, kus arvutatakse kõik näitajad kõigis valikute variantides, mis annavad erinevaid mitteaditiivseid tulemusi.

On selge, et näites UTE1 ja UTE2 – need on materjali atribuudid, mis esindavad kaubanduslikku hierarhiat. See ei ole staatiline asi, selle kaudu toimub juhtimine ettevõtte sees, kuna erinevate kaubagruppide eest vastutavad erinevad juhid. Meil on olnud palju globaalseid ülevaateid sellest hierarhiast, kui kõik tasemed muutsid, kui vaadati üle omavahelised seosed, samuti pidevaid täiendavaid muudatusi, kui üks grupp liigub ühest sõlmest teise. Tavalises aruandluses arvestatakse seda reaalajas, lähtudes materjali atribuutidest; andmete materialiseerimise korral tuleb välja töötada mehhanism selliste muudatuste jälgimiseks ja ajalooliste andmete automaatseks ülelaadimiseks. See on üsna keeruline ülesanne.

Detail 3. Andmete võrdlemine

See punkt on sarnane eelmisele. Asi on selles, et ettevõttes analüüsi tegemisel on kombeks luua mitu taset võrreldes eelmise perioodiga:

Võrdlemine eelmise perioodiga (päev päevalt, nädal nädalalt, kuu kuult)

Selles võrdluses eeldatakse, et sõltuvalt valitud perioodist (näiteks aasta 33. nädal) peame näitama dünaamikat 32. nädala suhtes; kui valime andmed kuu lõikes, näiteks mai, siis see võrdlus näitaks dünaamikat aprilli suhtes.

Võrdlemine eelmise aastaga

Siin on peamine nüanss selles, et võrreldes päevade ja nädalate kaupa peate te võtma mitte sama päeva eelmisel aastal, st te ei saa lihtsalt võtta praegust aastat miinus üks. Peate vaatama võrdlevat nädala päeva. Samuti, kui võrrelda kuud, tuleb võtta täpselt sama kalendripäev eelmisel aastal. Samuti on olemas nüansid liigaasta koht. Algsetes andmebaasides on kogu teave jaotatud päevade kaupa, seal ei ole eraldi väljandeid nädalate, kuude või aastate kohta. Seetõttu, et saada täielik analüütiline ülevaade paneelil, tuleb arvestada mitte ühte perioodi, näiteks nädalat, vaid 4 nädalat, ja seejärel tuleb neid andmeid veel võrrelda, kajastades dünaamikat ja kõrvalekaldeid. Seega saab seda võrdlemise dünaamika loogikat teostada kas Tableau's või vitriini poolel. Jah, me olime nendele detailidele teadlikud ja mõtlesime nendest juba projekteerimise etapis, kuid nende mõju lõppdashboordi jõudlusele oli keeruline prognoosida.

Dashboardi rakendamisel läksime me pikka Agile-teed. Meie ülesanne oli võimalikult kiiresti pakkuda testimiseks töötav tööriist vajalike andmetega. Seega töötasime sprintides ning lähtusime minimaalsetest töödest praeguses andmebaasis.

Osa 1. Usaldus Tableau'sse

IT-toe lihtsustamiseks ja muudatuste kiireks rakendamiseks otsustasime, et arvutusloogika mitteadditiivsete näitajate ja varasemate perioodide võrdlemiseks tehakse Tableau's.

Etapp 1. Kõik Live, ei mingeid täiustusi vitriinides.

Selles etapis ühendasime Tableau praeguste vitriinidega ja otsustasime vaadata, kuidas arvestatakse tšekkide arvu ühe aastajooksul.

Tulemus:

Vastus oli aeglane – 20 minutit. Andmete edastamine võrgu kaudu, suur koormus Tableau's. Me mõistsime, et mitteadditiivsete näitajate loogikat on vaja rakendada HANA-s. See ei hirmutanud meid, meil oli sarnast kogemust BO ja Analüüsiga ning me oskasime ehitada kiireid vitriine HANA-s, mis annavad õigesti arvutatud mitteadditiivseid näitajaid. Nüüd jäi vaid need Tableau'le kohandada.

Etapp 2. Lihvime vitriine, ei mingit materialiseerimist, kõik otse.

Me olime loonud eraldi uue väljundi, mis jooksvalt edastas vajalikud andmed TABLEAU jaoks. Kokkuvõttes saime hea tulemuse, olles lühendanud kõigi näitajate moodustamise aega ühe nädala jooksul 9–10 sekundini. Ootasime ausalt, et Tableau vastuse aeg armatuurlaudade avamisel on esmakordselt 20–30 sekundit ja seejärel tänu vahemälule 10–12, mis oleks meid üldiselt rahuldanud.

Tulemus:

Esimene armatuurlaudade avamine: 4–5 minutit
Iga klikk: 3–4 minutit
Seda täiendavat kasvu väljundi töötamises ei osanud keegi oodata.

Osa 2. Süvenemine Tableau'sse

Etapp 1. Tableau jõudluse analüüs ja kiire häälestamine

Alustasime analüüsi, millele Tableau peamiselt aega kulutab. Selleks on olemas üsna head tööriistad, mis on kindlasti Tableau pluss. Peamine probleem, mille avastasime, olid väga keerulised SQL-päringud, mida Tableau genereeris. Need olid seotud eeskätt:

— andmete transponeerimisega. Kuna Tableau'l puuduvad andmekogumite transponeerimise tööriistad, pidime armatuurlauda vasakpoolsesse ossa KPI-de üksikasjaliku esitluse loomiseks andmete tabelit genereerima läbi case. SQL-päringute suurus andmebaasis ulatus 120 000 tähemärgini.

— ajavahemiku valikuga. Selline päring andmebaasi tasemel kulutas kompileerimiseks rohkem aega kui täitmiseks:

St. päringu töötlemine 12 sekundit + 5 sekundit täitmine.

Otsustasime lihtsustada arvutuste loogikat Tableau poolel ja viia veel osa arvutustest väljundisse ja andmebaasi tasemele. See andis häid tulemusi.

Esmalt tegime transponeerimise jooksvalt, kasutades seda täieliku välist ühendust lõppfaasis VIEW arvutamisel, vastavalt siin kirjeldatud lähenemisele, Transpose – Wikipedia, the free encyclopedia ja Elementary matrix – Wikipedia, the free encyclopedia.

St. lõime seadistustabeli – transponeerimismatriisi (21x21) ja saime kõik näitajad ridade lõikes.

Oli:


On:


Andmete enda transponeerimine ei võta peaaegu üldse aega. Nädala kõikide näitajate päring töötas endiselt umbes 10 sekundi jooksul. Kuid töötas kaotatud paindlikkus konkreetsete näitajate põhjal dashboardsi koostamisel, st dashboardsi paremas osas, kus on esitatud dünaamiline detailne jaotumine, töötas vitriin varasemalt 1-3 sekundi jooksul, kuna päring toimus ühe näitaja järgi, kuid nüüd valis andmebaas alati kõik näitajad ja filtreeris tulemuse alles siis, kui see Tagastati Tableau.

Kokkuvõttes vähenes dashboardsi töökiirus peaaegu kolm korda.

Tulemus:

1. 5 sek - dashboardsi ja visualiseerimise parsimine
2. 15-20 sek - päringute kompileerimise ettevalmistamine Tableau eelõigete teostamisega
3. 35-45 sek - SQL-päringute kompileerimine ja nende järgneva täitmine Hanas
4. 5 sek - tulemuste töötlemine, sortimine, visualiseerimise ümberarvutamine Tableau's
5. Muidugi ei rahuldanud sellised tulemused äri, seetõttu jätkasime optimeerimist.

Etapp 2. Minimaliseeritud loogika Tableau's, täielik materialiseerimine

Mõistsime, et ei ole võimalik ehitada dashboardsi, mille reageerimisaeg on mõne sekundi jooksul vitriinil, mis töötab 10 sekundi jooksul, ning vaatasime andmete materialiseerimise võimalusi andmebaasi pool, et luua nõutud dashboards. Kuid me silmitsi seisime globaalsete probleemidega, nagu on eespool kirjeldatud – mitteaktiivsed näitajad. Me ei suutnud teha nii, et Tableau saaks filtreerimise või võrgu muutmisel paindlikult lülituda erinevate vitriinide ja tasemete vahel, mis on eelnevalt arvutatud erinevate kaubanduslike hierarhiate jaoks (näites kolm päringut ilma UTE, UTE1 ja UTE2 annavad erinevad tulemused). Seega otsustasime ühtlustada dashboardsi, loobuda kaubanduslikust hierarhiast dashboardsis ja vaadata, kui kiireks see saab lihtsustatud versioonis.

Nii et selle viimase etapi käigus kogusime eraldi ladustamise, kuhu panime transponeeritud kujul kõik KPI-d. Andmebaasi pool igasugune päring selle ladustamisele töötab 0,1–0,3 sekundi jooksul. Dashboardsis saime järgmised tulemused:

Esimene avastus: 8-10 sekundit
Iga klõps: 6-7 sekundit

Aeg, mille Tableau kulutab, koosneb järgmistest:

1. 0,3 sek - dashboardsi parsimine ja SQL-päringute kompileerimine
2. 1,5-3 sek - SQL-päringute täitmine Hanas peamiste visualiseerimise jaoks (käivitub paralleelselt p.1)
3. 1,5-2 sek - renderimine, visualiseerimise ülekalkulatsioon
4. 1,3 sek - täiendavate SQL-päringute täitmine asjakohaste filtriväärtuste (Bränd, Divisjon, Linn, Pood) saamiseks, tulemuste analüüs

Kui teha lühike kokkuvõte

Meile meeldis Tableau tööriist visualiseerimise osas. Kujundamisetapis vaatasime erinevaid visualiseerimise elemente ja leidsime need kõik raamatukogudest, sealhulgas keerukad mitmeastmelised segmentatsioonid ja mitme draiveriga waterfallid.

Peamise müüginäitajaga juhtpaneelide kasutuselevõtmisel kohtasime jõudluse probleeme, mida me siiani ei ole suutnud ületada. Kulutasime rohkem kui kaks kuud ja saime funktsionaalselt mittetäieliku juhtpaneeli, mille reageerimiskiirus oli piiri peal. Ja selle põhjal jõudsime järeldustele:

1. Tableau ei oska töötada suurte andmemahtudega. Kui teie algandmemudel sisaldab rohkem kui 10 GB andmeid (umbes 200 miljonit x 50 rida), siis juhtpaneel aeglustub tõsiselt - iga klikiga 10 sekunditest mitme minutini. Katsetasime nii live-ühenduse kui ka eksemplaris.
2. Piirangud mitme andmestiku (dataseti) kasutamisel. Standardselt ei ole võimalik andmestike vahelisi seoseid määrata. Kui kasutada ringlahendusi andmestike sidumiseks, mõjutab see oluliselt jõudlust. Meie puhul kaalusime andmete materialiseerimist igas vajalikus vaates ja nendele materialiseeritud datasets'idele vahetuste tegemist, säilitades varem valitud filtrid – see osutus Tableau's võimatuks.
3. Tableaus ei ole võimalik teha dünaamilisi parameetreid. Te ei saa parameetrit, mida kasutatakse andmestiku filtreerimiseks eksemplaris või live-ühenduses, täita teise andmestiku valiku või teise SQL-päringu tulemusega, ainult kasutaja sisendi või konstantidega.
4. Piirangud, mis on seotud juhtpaneeli koostamisega OLAP|Pivot Table elementidega.
   MSTR, SAP SAC, SAP Analysis puhul, kui lisate aruandesse andmekomplekti, siis on kõik objektid omavahel vaikimisi seotud. Tableau's seda ei ole, seoseid tuleb seadistada käsitsi. See on tõenäoliselt paindlikum, kuid meie kõigi juhtpaneelide jaoks on see elementide kohustuslik nõue – seega labour дополнительная затраты. Veelgi enam, kui loote seotud filtrid, nii et näiteks piirkonna filtreerimisel piiratakse linnade loetelu ainult selle piirkonna linnadega, satute kohe järjestikustega päringuteni andmebaasi või ekraani, mis aeglustab juhtpaneeli märgatavalt.
5. Funktsioonide piirangud. Nii ekraanil kui ka veelgi enam, elava ühenduse andmekomplektidega ei saa teha massilisi teisendusi. Seda saab teha Tableau Prepiga, kuid see toob kaasa lisakulusid ja veel ühe tööriista, mida tuleb õppida ja toetada. Näiteks ei saa te andmeid transpositsioneerida ega liita neid iseendaga. See toimub eraldi veergude või väljade kaudu, mida tuleb valida läbi case või if, tekitades väga keerulisi SQL-päringuid, mille puhul andmebaas kulutab enamuse ajast päringu koostamisele. Nende tööriista paindumatuste lahendamine tuli teha vitriini tasemel, mis viis andmehoidla keerukuse, täiendavate koormuste ja teisendusteni.

Me ei ole Tableau'le punkti pannud. Kuid tööriistana, mis suudab luua tööstuslikke juhtpaneele ja vahendina, millega asendada ja digitaliseerida kogu ettevõtte aruandluse süsteemi, ei pea me Tableau't.

Praegu töötame aktiivselt välja sarnast juhtpaneeli teise tööriista abil ja üritame samal ajal üle vaadata Tableau juhtpaneeli arhitektuuri, et seda veelgi lihtsustada. Kui kogukonnale see huvi pakub, siis jagame tulemusi.

Ootame ka teie ideid või nõuandeid selle kohta, kuidas Tableau's suurte andmehulkadega kiiresti juhtpaneele luua, sest meil on ka veebisait, kus andmeid on palju rohkem kui jaekauplustes.

Allikas: habr.com