Kas jaemüügis on tõesti võimalik?

Excel'i aruandlus on kiiresti muutumas — trend mugavate andmete esitamise ja analüüsi tööriistade suunas on nähtav kõigis valdkondades. Oleme juba pikalt arutanud aruandluse digitaliseerimist ja oleme valinud visualiseerimise ja iseteeninduse analüütik tööriista Tableau. Alexander Bezugly, analüütiliste lahenduste ja aruandluse juht Grupi «M.Video-Eldorado» juures, jagas oma kogemust ja tulemusi kõige olulisema juhtpaneeli väljatöötamisel.

Ütlen kohe, et ei suutnud ellu viia kõike, mis oli plaanis, kuid kogemus oli huvitav, loodan, et see on kasulik ka teile. Kui kellelgi on ideid, kuidas oleks saanud paremini teha – oleksin väga tänulik nõuannete ja mõtete eest.

Allpool räägin sellest, millega me silmitsi seisime ja mida me õppisime.

Kust me alustasime

Grupil «M.Video-Eldorado» on hästi välja töötatud andmemudel: struktureeritud teave vajaliku salvestus sügavusega ja tohutu hulk staatilisi aruandeid (vt lähemalt seda artiklit). Neist valmistavad analüütikud kas kokkuvõtte tabelid või formaalsed Exceli saadetised, või ka ilusaid esitlusi PowerPointis lõppkasutajatele.

Umbes kaks aastat tagasi hakkasime staatiliste aruannete asemel looma analüütilisi aruandeid SAP Analysis'is (Exceli lisand, olemuselt OLAP mootori peal oleva kokkuvõtte tabel). Kuid see tööriist ei suutnud rahuldada kõiki kasutajate vajadusi, enamus jätkas infot töötlemist, mida analüütikud edastasid.

Meie lõppkasutajad jagunevad kolme kategooriasse:

Tippjuhtkond. Nõuab teavet hästi esitatud ja arusaadavas vormis.

Kesktasandi juhid, edasijõudnud kasutajad. On huvitatud andmete uurimisest ja suudavad iseseisvalt aruandeid koostada, kui neil on tööriistad olemas. Nemad ongi saanud SAP Analysis'i analüütiliste aruannete võtmekasutajateks.

Massiivsed kasutajad. Pole huvitatud iseseisvast andmete analüüsimisest, kasutavad aruandeid piiratud vabadusega, saadetiste ja kokkuvõtete vormingus Excelis.

Meie idee oli katta kõigi kasutajate vajadusi ja anda neile ühine mugav tööriist. Alustasime tippjuhtkonnast. Nende puhul olid vajalikud mugavad paneelid peamiste äritulemuste analüüsimiseks. Nii alustasime Tableau'ga ja valisime esialgu kaks suunda: jaemüügi ja online müügi näitajad piiratud sügavuse ja ulatusega analüüsiks, mis kataks umbes 80% tippjuhtkonna nõudmistest.

Kuna juhtpaneelide kasutajad olid tippjuhtkond, tuli tootele veel üks täiendav KPI – reageerimise kiirus. Keegi ei hakka ootama 20-30 sekundit, et andmed uuenduksid. Navigeerimine peab toimuma 4-5 sekundi jooksul, parem oleks hetkega. Ja seda me, kahjuks, ei saavutanud.

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

Peamine idee oli ühendada 19 peamist KPI-d vasakul ja esitleda nende dünaamikat ja jagunemist peamiste atribuutide lõikes paremal. Ülesanne tundub lihtne, visualiseerimine on loogiline ja arusaadav, kuni ei süüvi detailidesse.

Detail 1. Andmete maht

Aasta müügitaotlus hõlmab umbes 300 miljonit rida. Kuna on vajalik kajastada ka dünaamikat eelmisel ja üleeelsel aastal, on andmemaht ainult tegelike mükide osas umbes 1 miljard rida. Lisaks säilitatakse eraldi planeeritud andmete teave ja internetimüügiblokk. Seega, isegi kui me kasutasime kolonn-pööramisel in-memory DB SAP HANA, oli kõigi näitajate valik ühe nädala jooksul jooksvalt tehtud päringu kiirus umbes 15-20 sekundit. Probleemi lahendus tundub iseenesestmõistetav – lisamaterjaliseerimine andmetest. Kuid selles on samuti oma ahvatlused, neist allpool.

Detail 2. Mitte-additiivsed näitajad

Paljud meie KPI-d on seotud tšekkide arvuga. See näitaja esindab COUNT DISTINCT ridade arvu (tšekkide pealkirjades) ja näitab erinevaid summasid sõltuvalt valitud atribuutidest. Näiteks, kuidas see näitaja ja sellest tuletatud näitajad peaksid olema arvutatud:

Arvutuste täpsuse tagamiseks võime:

• Teha sarnaste näitajate arvutusi jooksvalt andmehõivele;
• Teha arvutused Tableau's kogu andmemahule, st edastada Tableau's kõik andmed valitud filterite kohaselt tšekkide positsioonides;
• Luua materialiseeritud vitriin, kus on arvutatud kõik näitajad kõigis valikutes, andes erinevaid mitte-additiivseid tulemusi.

Selge on, et näites UTE1 ja UTE2 on need materjali atribuudid, mis esindavad kaubanduslikku hierarhiat. See ei ole staatiline asi, vaid selle kaudu toimub haldus ettevõtte sees, sest erinevate tootegruppide eest vastutavad erinevad juhid. Meil oli palju globaalset ülevaadet sellest hierarhiast, kui muutusid kõik tasemed, kui üle vaadati seosed ning pidevad punktmuudatused, kui üks grupp liigub ühest sõlmest teise. Tavalises aruandluses arvestatakse seda kõike jooksvalt materjali atribuutidest; andmete materialiseerimise korral on vajalik välja töötada mehhanism sarnaste muudatuste jälgimiseks ja ajalooliste andmete automaatseks ülevoodamiseks. Tegu on üsna keerulise ülesandega.

Detail 3. Andmete võrdlemine

See punkt on sarnane eelnevale. Asjaolu on see, et ettevõttes analüüsimisel on tavaks koostada mitu võrreldavat taset eelmise perioodiga:

Võrdlemine eelmise perioodiga (päev päeva, nädal nädalasse, kuu kuusse)

Selles võrdlemises eeldatakse, et kasutaja valitud perioodi (näiteks aasta 33. nädal) korral peaksime näitama dünaamikat 32. nädalaga; kui valiksime andmed kuu kohta, näiteks mai, siis see võrdlus näitaks dünaamikat aprilli suhtes.

Võrdlemine eelmise aastaga

Siin on peamine nüanss see, et päevade ja nädalate võrdlemisel ei tohi võtta sama päeva eelmisest aastast, see tähendab, et te ei saa lihtsalt võtta käesoleva aasta minus üks. Peate vaatama võrdlevat nädalapäeva. Kuu võrdlemisel tuleb seevastu võtta täpselt sama kalendripäev eelmisest aastast. Samuti on nüansse liigsetes aastates. Algandmehoidlas on kogu teave jaotatud päevade järgi, seal ei ole eraldi välju nädalate, kuude või aastate jaoks. Seetõttu, et saada täielikku analüütilist lõiget paneelil, tuleb arvestada mitte ühte perioodi, näiteks nädalat, vaid 4 nädalat ja seejärel need andmed veel võrrelda, kajastades dünaamikat ja kõrvalekaldeid. Vastavalt sellele saab seda võrdlemise dünaamika loogikat rakendada kas Tableau'is või vitriini poolel. Jah, ja nendest nüanssidest olime muidugi teadlikud ja mõtlesime juba projekteerimisfaasis, kuid nende mõju lõpp-dashboardi jõudlusele ei olnud kerge prognoosida.

Dashboardi rakendamisel läbisime pika Agile-teekonna. Meie ülesanne oli võimalikult kiiresti pakkuda testimiseks tööriist, mis sisaldab vajalikke andmeid. Seetõttu läksime sprintide kaupa ja lähtusime olemasoleva andmehoidla tööde minimeerimisest.

Osa 1. Usaldus Tableau'sse

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

Etapp 1. Kõik on Live, ei mingit vitriinide täiendamist.

Selles etapis ühendasime Tableau praeguste vitriinidega ja otsustasime vaadata, kuidas arvutatakse tšekkide arvu ühe aasta jooksul.

Tulemus:

Vastus oli pettumust valmistav – 20 minutit. Andmete edastamine võrgu kaudu, suur koormus Tableau'le. Mõistsime, et mitteadditiivsete näitajate loogikat tuleb rakendada HANA-s. See ei hirmutanud meid, meil oli juba sarnane kogemus BO ja Analysis'iga ning teadsime, kuidas luua kiiresti vitriine HANA-s, mis annavad õigesti arvutatud mitteadditiivsed näitajad. Nüüd jäi vaid kohandada need Tableau jaoks.

Etapp 2. Viimistleme vitriine, ei mingit materialiseerimist, kõik reaalajas.

Loomasime täiesti uue vitriini, mis pakkus reaalajas nõutavaid andmeid TABLEAU'le. Kokkuvõttes saime head tulemused, vähendasime kõigi näitajate loomise aega ühe nädala jooksul 9-10 sekundi peale. Ja ausalt öeldes ootasime, et Tableau's oleks dashboardi reageerimise aeg esimesel avamisel 20-30 sekundit ja seejärel tänu vahemälule 10 kuni 12, mis oleks meid kokkuvõttes rahuldanud.

Tulemus:

Esimene dashboardi avamine: 4-5 minutit
Iga klikk: 3-4 minutit
Sellist lisakoormust vitriini tööle ei oodanud keegi.

Osa 2. Süvenemine Tableau'sse

Etapp 1. Tableau jõudluse analüüs ja kiire viimistlemine

Alustasime analüüsi, millele Tableau oma peamise aja kulutab. Selleks on olemas üsna head tööriistad, mis on kindlasti Tableau pluss. Peamine probleem, mille me tuvastasime, olid väga keerulised SQL-päringud, mille Tableau koostas. Need olid peamiselt seotud:

— andmete transponimisega. Kuna Tableau'il ei ole tööriistu andmekogumite transponimiseks, pidime koostama tabeli läbi case'i, et luua vasakpoolne osa dashboarist, kus oleks detailsed KPI-ed. SQL-päringute suurus andmebaasis ulatus 120 000 märgini.

— ajaperioodi valimisega. Selline päring andmebaasi tasandil nõudis kompileerimisele rohkem aega kui täitmisele:

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

Otsustasime lihtsustada arvutuste loogikat Tableau küljel ja viia veel ühe osa arvutustest andmemassiivi ja andmebaasi tasemele. See tõi häid tulemusi.

Esmalt viisime läbi transpositsiooni reaalajas, kasutades full outer join'i VIEW lõpparvutuses, kooskõlas sellise lähenemisega, mis on kirjeldatud wiki's. Transpose — Wikipedia, tasuta entsüklopeedia ja Algebraline maatriks — Wikipedia, tasuta entsüklopeedia.

See tähendab, et tegime seadistusliku tabeli – transpositsioonimaatriksi (21x21) ja saime kõik näitajad ridade kaupa.

Oli:


Muudetud:


Andmebaas kulutab transpositsioonile peaaegu ei aega. Näitajate päring nädalas töötas endiselt umbes 10 sekundi jooksul. Kuid kaotasime paindlikkuse spetsiifiliste näitajate, st. paremal pool olevas armatuurlaud, kus näidatakse konkreetses näitaja dünaamikat ja detailset jaotust, varem töötas põhitasand 1-3 sekundiga, kuna päring läks ühe näitaja peale, ja nüüd valib andmebaas alati kõik näitajad ja filtreerib tulemuse enne, kui see tagastatakse Tableau'sse.

Kokkuvõttes vähenes armatuurlauda töökiirus peaaegu kolmandiku võrra.

Tulemus:

1. 5 sek — armatuurlauda ja visualiseerimise parsimine
2. 15-20 sek — päringute koostamise ettevalmistamine Tableau's, sealhulgas eel-arvutused
3. 35-45 sek — SQL-päringute koostamine ja nende järkjärguline täitmine Hanas
4. 5 sek — tulemuste töötlemine, järjestamine, visualiseerimiste rekalkuleerimine Tableau's
5. Loomulikult ei rahuldanud sellised tulemused äri ja jätkasime optimeerimist.

Etapp 2. Minimumpunktid Tableau's, täielik materialiseerimine

Me mõistsime, et armatuurlauda ülesehitamine, mille vastusaeg on mitme sekundi jooksul, on 10 sekundi töötava idufirma jaoks võimatu, ja kaalume andmete materialiseerimise võimalusi andmebaasi poolel just nõutud armatuurlaudade jaoks. Kuid seisime silmitsi ühtse probleemiga, nagu eespool mainitud – mitte-additiivsed näitajad. Me ei suutnud saavutada, et Tableau saaks filtreid või avamisi muutes kiiresti vahetada erinevate vitriinide ja tasemete vahel, mis olid eelnevalt arvutatud erinevate tootehierarhiate jaoks (näide kolme päringu, ilma UTE, UTE1 ja UTE2 kohta, mis moodustavad erinevaid tulemusi). Seetõttu otsustasime armatuurlauda lihtsustada, loobuda tootehierarhiast armatuurlaudades ja vaadata, kui kiireks see lihtsustatud versioonis saab.

Nii et selle viimase etapi käigus kogusime eraldi salvestusruumi, kuhu koondasime transpositsioonitud kõiki KPI-sid. Andmebaasi poolel töötleb mis tahes päring sellise salvestusruumi puhul 0,1–0,3 sekundi jooksul. Armatuurlaudades saime järgmised tulemused:

Esimene avastus: 8-10 sekundi jooksul
Iga klikk: 6-7 sekundit

Aeg, mille Tableau kulutab, koosneb järgmistest:

1. 0,3 sek. — armatuurlauda parsimine ja SQL-päringute koostamine
2. 1,5-3 sek. — SQL-päringute täitmine Hanas peamiste visualiseerimiste jaoks (käivitub paralleelselt p.1-ga)
3. 1,5-2 sek. — renderdamine, visualiseerimiste rekalkuleerimine
4. 1,3 sek. — täiendavate SQL-päringute täitmine, et saada asjakohaseid filtreerimise väärtusi (bränd, divisjon, linn, pood), tulemuste parsimine

Kui kokku võtta lühidalt

Meile meeldis Tableau tööriist visualiseerimise osas. Prototüüpimise etapis kaalume erinevaid visualiseerimise elemente ja kõik need leidsime raamatukogudes, sealhulgas keerulised mitmetasandilised segmentatsioonid ja multi-driver waterfall’id.

Peamiste müügi näitajatega armatuurlaudade rakendamisel seisime silmitsi jõudluse probleemidega, mida me pole veel suutnud ületada. Oleme kulutanud üle kahe kuu ja saanud funktsionaalselt pooliku armatuurlauda, mille vastusaeg on piiripealne. Teeme enda jaoks järgmised järeldused:

1. Tableau ei oska töötada suurte andmehulga korral. Kui teie algses andmemudelis on rohkem kui 10 GB andmeid (umbes 200 mln x 50 rida), siis armatuurlaud aeglustub märkimisväärselt—alates 10 sekundist kuni mitme minutini iga klikki kohta. Oleme katsetanud ja reaalajas ühenduste ning ekstrapoolide korral. Kiirus on sarnane.
2. Piirang mitme salvestuse (andmekogumite) kasutamisel. Standardsete vahenditega ei ole võimalik määrata andmekogumite vahelist seost. Kui kasutada eelnevaid lahendusi andmekogumite vaheliste suhete loomiseks, avaldab see oluliselt mõju jõudlusele. Meie puhul kaalusime andmete materialiseerimise võimalusi igas vajalikus vaates ja sellel materialiseeritud andmekogul vahetamise tegemiseks varasemate valitud filtrite säilitamist—see osutus Tableau's võimatuks.
3. Tableaus ei ole võimalik teha dünaamilisi parameetreid. Te ei saa parameetrit, mida kasutatakse andmestiku filtreerimiseks ekstractis või live-ühenduses, täita teise valiku tulemusega andmestikust või teise SQL-päringu tulemusega, vaid ainult kasutaja natiivse sisestuse või konstantsiga.
4. Piirangud, mis on seotud OLAP|Pivot tabelitega dashboard'i loomisega.
   MSTR, SAP SAC, SAP Analysis programmides, kui lisate aruandesse andmestiku, siis kõik selle objektid on vaikimisi omavahel seotud. Tableaus seda ei tee, seoseid tuleb seadistada käsitsi. See on võib-olla paindlikum, kuid kõigi meie dashboard'ide jaoks on see elementide kohustuslik nõue – seega toob see kaasa lisatööjõu. Rohkem veel, kui loote seotud filtreid, et näiteks piirkonna filtreerimisel piirata linnade loend ainult selle piirkonna linnadega, satute kohe järjestikustesse päringutesse andmebaasi või ekstracti, mis aeglustab dashboard'i märgatavalt.
5. Funktsioonide piirangud. Nii ekstractide kui veelgi enam live-ühenduse andmestike üle ei saa teha massilisi transformatsioone. Seda on võimalik teha Tableau Prep kaudu, kuid see tähendab lisatöötunde ja veel ühe tööriista õppimist ning haldamist. Näiteks ei saa te andmeid transponeerida, teha endaga liite. See sulgub eraldi veergude või väljade kaudu tehtavatesse transformatsioonidesse, mida tuleb valida case'i või if'i kaudu ning see tekitab väga keerulisi SQL-päringuid, mille puhul andmebaas kulutab rohkem aega päringu teksti koostamisele. Need tööriistade paindumatuse probleemid tuli lahendada vitriini tasemel, mis toob kaasa andmehoidla keerukuse, lisakoormuse ja transformatsioonid.

Me ei ole Tableau'l risti ette pannud. Kuid tööriistana, mis suudab ehitada tööstuslikke dashboard'e ja vahendina, millega asendada ja digitaliseerida kogu ettevõtte aruandluse süsteemi, ei pea me Tableau'd sobivaks.

Me arendame aktiivselt sarnast dashboard'i teise tööriista peal ja samal ajal püüame üle vaadata Tableau dashboard'i arhitektuuri, et veelgi enam lihtsustada. Kui kogukonnale huvi pakub – räägime tulemustest.

Ootame ka teie ideid või näpunäiteid selle kohta, kuidas Tableau's luua kiireid dashboard'e suurte andmehulkade üle, arvestades, et meil on ka veebileht, kus andmeid on oluliselt rohkem kui jaeäris.

Allikas: habr.com