Aruandluse aeg Excelis kaob kiiresti – trend mugavate info esitamise ja analüüsimise tööriistade poole on nähtav kõikides valdkondades. Oleme aruandluse digitaliseerimise üle sisemiselt arutanud juba pikemat aega ning valisime Tableau visualiseerimis- ja iseteenindusanalüütikasüsteemi. M.Video-Eldorado Grupi analüütiliste lahenduste ja aruandluse osakonna juht Alexander Bezugly rääkis lahingu armatuurlaua ehitamise kogemusest ja tulemustest.
Ütlen kohe, et kõik plaanitu ei realiseerunud, kuid kogemus oli huvitav, loodan, et sellest on ka teile kasu. Ja kui kellelgi on ideid, kuidas saaks paremini teha, siis oleksin väga tänulik nõuannete ja ideede eest.
Lõike all on juttu sellest, mida kohtasime ja mille kohta õppisime.
Kust me alustasime?
M.Video-Eldoradol on hästi arenenud andmemudel: struktureeritud teave vajaliku salvestussügavusega ja tohutu hulk fikseeritud vormiga aruandeid (vt täpsemalt ). Nendest koostavad analüütikud kas pöördetabeleid või vormindatud uudiskirju Excelis või kauneid PowerPointi esitlusi lõppkasutajatele.
Umbes kaks aastat tagasi alustasime fikseeritud vormiga aruannete asemel analüütiliste aruannete loomist rakenduses SAP Analysis (Exceli lisand, sisuliselt OLAP-mootori pivot-tabel). Kuid see tööriist ei suutnud rahuldada kõigi kasutajate vajadusi, enamus jätkas analüütikute täiendavalt töödeldud teabe kasutamist.
Meie lõppkasutajad jagunevad kolme kategooriasse:
Tippjuhtkond. Nõuab teavet hästi esitatud ja selgelt arusaadaval viisil.
Keskastme juhtkond, edasijõudnud kasutajad. Huvitatud andmete uurimisest ja võimalik iseseisvalt koostada aruandeid, kui tööriistad on saadaval. Nendest said SAP Analysis analüütiliste aruannete peamised kasutajad.
Massitarbijad. Nad ei ole huvitatud andmete iseseisvast analüüsist, nad kasutavad piiratud vabadusega aruandeid uudiskirjade ja Exceli pivot-tabelite kujul.
Meie idee oli katta kõigi kasutajate vajadused ja anda neile ühtne mugav tööriist. Otsustasime alustada tippjuhtkonnaga. Peamiste äritulemuste analüüsimiseks vajasid nad lihtsalt kasutatavaid armatuurlaudu. Niisiis alustasime Tableauga ja valisime esmalt kaks suunda: piiratud sügavuse ja ulatusega jaemüügi- ja veebimüüginäitajad, mis kataks ligikaudu 80% tippjuhtkonna nõutud andmetest.
Kuna armatuurlaudade kasutajad olid tippjuhtkond, siis ilmus veel üks toote KPI lisa - reageerimiskiirus. Keegi ei oota 20-30 sekundit andmete uuendamist. Navigeerimine oleks pidanud toimuma 4-5 sekundi jooksul või veel parem, koheselt. Ja kahjuks ei õnnestunud meil seda saavutada.
Meie peamise armatuurlaua paigutus nägi välja selline:
Põhiidee on ühendada peamised KPI draiverid, mida oli kokku 19, vasakul ja esitada nende dünaamika ja jaotus peamiste atribuutide järgi paremal. Ülesanne tundub lihtne, visualiseerimine on loogiline ja arusaadav, kuni detailidesse sukelduda.
Detail 1. Andmemaht
Meie iga-aastase müügi põhitabel sisaldab umbes 300 miljonit rida. Kuna on vaja kajastada eelmise ja üle-eelmise aasta dünaamikat, siis ainuüksi tegeliku müügi andmete maht on umbes 1 miljard rida. Eraldi salvestatakse ka info planeeritud andmete ja veebimüügiploki kohta. Seega, kuigi kasutasime veergude kujul olevat mälusisene DB SAP HANA, oli päringu kiirus ühe nädala jooksul kõigi indikaatorite valikuga praegusest salvestusruumist umbes 15-20 sekundit. Selle probleemi lahendus soovitab ennast - andmete täiendav materialiseerimine. Kuid sellel on ka lõkse, neist lähemalt allpool.
Detail 2. Mitteliituvad indikaatorid
Paljud meie KPI-d on seotud kviitungite arvuga. Ja see indikaator tähistab ridade arvu COUNT DISTINCT (kontrolli päised) ja näitab erinevaid summasid sõltuvalt valitud atribuutidest. Näiteks kuidas seda näitajat ja selle tuletist arvutada:
Arvutuste korrektseks tegemiseks võite:
- Arvutage sellised näitajad laos käigu pealt;
- Tehke arvutused kogu Tableau andmemahu kohta, s.o. nõudmisel Tableau's esitama kõik andmed vastavalt valitud filtritele laekumise positsiooni detailsuses;
- Looge materialiseeritud esitlus, milles arvutatakse kõik näitajad kõigis näidisvalikutes, mis annavad erinevaid mitteliituvaid tulemusi.
On selge, et näites on UTE1 ja UTE2 tootehierarhiat esindavad materjaliatribuudid. See pole staatiline asi, selle kaudu toimub ettevõttesisene juhtimine, sest Erinevate tooterühmade eest vastutavad erinevad juhid. Meil oli palju selle hierarhia globaalseid muudatusi, kui kõik tasemed muutusid, suhteid muudeti ja pidevaid punktimuutusi, kui üks rühm liikus ühest sõlmest teise. Tavaaruandluses arvutatakse see kõik välja materjali atribuutide järgi, nende andmete materialiseerumise korral on vaja välja töötada mehhanism selliste muutuste jälgimiseks ja ajalooliste andmete automaatseks ümberlaadimiseks. Väga mittetriviaalne ülesanne.
Detail 3. Andmete võrdlus
See punkt on sarnane eelmisega. Põhimõte on see, et ettevõtte analüüsimisel on tavaks moodustada mitu võrdlustaset eelmise perioodiga:
Võrdlus eelmise perioodiga (päevast päeva, nädalast nädalasse, kuust kuusse)
Selles võrdluses eeldatakse, et olenevalt kasutaja valitud perioodist (näiteks aasta 33. nädal) peaksime näitama dünaamikat 32. nädalaks, kui valisime kuu andmed näiteks mai kohta. , siis näitaks see võrdlus dünaamikat aprilliks.
Võrdlus eelmise aastaga
Peamine nüanss on siin see, et kui võrrelda päevade ja nädalate lõikes, siis sa ei võta sama eelmise aasta päeva, s.t. te ei saa lihtsalt panna jooksvat aastat miinus üks. Peate vaatama, millist nädalapäeva võrrelda. Kuude võrdlemisel tuleb vastupidiselt võtta täpselt sama kalendripäev eelmisel aastal. Liigaaastatega on ka nüansse. Algsetes hoidlates jaotatakse kogu teave päevade kaupa, eraldi väljad nädalate, kuude või aastatega pole. Seetõttu peate paneelis täieliku analüütilise ristlõike saamiseks arvestama mitte ühte perioodi, näiteks nädala, vaid 4 nädalat, ja seejärel neid andmeid võrdlema, kajastama dünaamikat, kõrvalekaldeid. Sellest tulenevalt saab seda dünaamika võrdluste genereerimise loogikat rakendada ka Tableau või poe poolel. Jah, ja loomulikult teadsime ja mõtlesime nendele detailidele juba projekteerimisetapis, kuid nende mõju lõpliku armatuurlaua toimimisele oli raske ennustada.
Armatuurlaua juurutamisel järgisime pikka Agile teed. Meie ülesandeks oli pakkuda testimiseks vajalike andmetega töövahend võimalikult kiiresti. Seetõttu läksime spurtidesse ja alustasime töö minimeerimisest praeguse hoidla poolel.
1. osa: Faith in Tableau
IT-toe lihtsustamiseks ja muudatuste kiireks juurutamiseks otsustasime mitteliitetavate näitajate arvutamise ja möödunud perioodide võrdlemise loogika teha Tableaus.
1. etapp. Kõik on reaalajas, aknaid ei muudeta.
Selles etapis ühendasime Tableau praeguste vitriinidega ja otsustasime vaadata, kuidas arvutatakse ühe aasta kviitungite arv.
Tulemus:
Vastus oli masendav – 20 minutit. Andmeedastus üle võrgu, Tableau suur koormus. Mõistsime, et HANA-s tuleb rakendada mitteliituvate indikaatoritega loogikat. See meid eriti ei hirmutanud, meil oli juba sarnane kogemus BO ja Analysisiga ning teadsime, kuidas HANA-s ehitada kiireid vitriine, mis toodavad õigesti arvutatud mitteliituvaid näitajaid. Nüüd ei jäänud muud üle kui need Tableau järgi kohendada.
2. etapp. Tuunime vitriine, ei mingit materialiseerimist, kõik käigu pealt.
Lõime eraldi uue vitriin, mis tootis TABLEAU jaoks vajalikud andmed jooksvalt. Üldiselt saime hea tulemuse, vähendasime ühe nädala jooksul kõigi näitajate genereerimise aega 9-10 sekundile. Ja me ausalt eeldasime, et Tableaus on armatuurlaua reaktsiooniaeg esimesel avamisel 20-30 sekundit ja seejärel vahemälu tõttu 10-12, mis meile üldiselt sobiks.
Tulemus:
Esimene avatud armatuurlaud: 4–5 minutit
Iga klõps: 3-4 minutit
Sellist täiendavat poe töö suurenemist ei oodanud keegi.
2. osa. Sukeldu Tableau'sse
1. etapp. Tabeli jõudluse analüüs ja kiirhäälestus
Hakkasime analüüsima, kus Tableau suurema osa ajast veedab. Ja selleks on päris head tööriistad, mis on muidugi Tableau pluss. Peamine probleem, mille tuvastasime, olid väga keerulised SQL-päringud, mida Tableau koostas. Neid seostati peamiselt:
— andmete ülevõtmine. Kuna Tableaul pole tööriistu andmekogumite ülekandmiseks, pidime armatuurlaua vasakpoolse külje koostamiseks kõigi KPI-de üksikasjaliku esitusega looma tabeli, kasutades juhtumit. SQL päringute maht andmebaasis ulatus 120 000 tähemärgini.
- ajaperioodi valik. Sellise päringu andmebaasi tasemel koostamine võttis rohkem aega kui selle käivitamine:
Need. päringu töötlemine 12 sekundit + 5 sekundit täitmine.
Otsustasime Tableau-poolset arvutusloogikat lihtsustada ja teise osa arvutustest viia poe ja andmebaasi tasemele. See tõi häid tulemusi.
Esiteks tegime transponeerimise käigu pealt, VIEW arvutuse viimases etapis täieliku välise liitumise kaudu, vastavalt sellele wikis kirjeldatud lähenemisviisile. и .
See tähendab, et tegime seadistustabeli - transpositsioonimaatriksi (21x21) ja saime kõik näitajad ridade kaupa.
See oli:
Sellest sai:
Andmebaasi enda ülevõtmisele ei kuluta peaaegu üldse aega. Kõikide nädalanäitajate päringu töötlemine jätkus umbes 10 sekundiga. Aga teisalt on kadunud paindlikkus konkreetse näitaja alusel armatuurlaua konstrueerimise osas, s.t. armatuurlaua parema külje jaoks, kus on välja toodud konkreetse indikaatori dünaamika ja detailne jaotus, varem töötas kuva aken 1-3 sekundiga, sest päring põhines ühel indikaatoril ja nüüd valis andmebaas alati kõik näitajad ja filtreeris tulemuse enne Tableau'le tagastamist.
Selle tulemusena vähenes armatuurlaua kiirus peaaegu 3 korda.
Tulemus:
- 5 sek – armatuurlaudade, visualisatsioonide sõelumine
- 15-20 sekundit - ettevalmistus päringute koostamiseks koos eelarvutuste tegemisega Tableau's
- 35-45 sek - SQL-päringute koostamine ja nende paralleelne järjestikune täitmine Hanas
- 5 sek – tulemuste töötlemine, sorteerimine, visualisatsioonide ümberarvutamine Tableaus
- Loomulikult ei sobinud sellised tulemused ettevõttele ja jätkasime optimeerimist.
2. etapp. Minimaalne loogika Tableau's, täielik materialiseerimine
Saime aru, et 10-sekundilisel poe esiküljel on võimatu ehitada mitmesekundilise reaktsiooniajaga armatuurlauda, ning kaalusime võimalusi andmebaasi poole andmete realiseerimiseks spetsiaalselt vajaliku armatuurlaua jaoks. Kuid me puutusime kokku ülalkirjeldatud globaalse probleemiga - mitteliituvate näitajatega. Me ei saanud veenduda, et filtreid või süvendusi vahetades vahetas Tableau paindlikult erinevate kaupluste ja erinevate tootehierarhiate jaoks eelnevalt kavandatud tasemete vahel (näites loovad kolm päringut ilma UTE-ta, UTE1 ja UTE2-ga erinevad tulemused). Seetõttu otsustasime armatuurlauda lihtsustada, loobuda tootehierarhiast armatuurlaual ja vaadata, kui kiire see lihtsustatud versioonis võiks olla.
Nii et selles viimases etapis koostasime eraldi hoidla, kuhu lisasime kõik KPI-d ülevõetud kujul. Andmebaasi poolel töödeldakse iga sellise salvestusruumi päring 0,1–0,3 sekundiga. Armatuurlaual saime järgmised tulemused:
Esimene avamine: 8-10 sekundit
Iga klõps: 6-7 sekundit
Tableau veedetud aeg koosneb:
- 0,3 sek. — armatuurlaua sõelumine ja SQL-päringute kompileerimine
- 1,5-3 sek. — SQL-päringute täitmine Hanas peamiste visualiseerimiste jaoks (töötab paralleelselt sammuga 1)
- 1,5-2 sek. — visualiseerimiste renderdamine, ümberarvutamine
- 1,3 sek. — täiendavate SQL-päringute täitmine asjakohaste filtriväärtuste saamiseks (bränd, osakond, linn, pood), tulemuste sõelumine
Lühidalt kokku võttes
Meile meeldis Tableau tööriist visualiseerimise vaatenurgast. Prototüüpimise etapis kaalusime erinevaid visualiseerimiselemente ja leidsime need kõik teekides, sealhulgas keerulise mitmetasandilise segmenteerimise ja mitme juhiga kose.
Peamiste müüginäitajatega armatuurlaudade juurutamisel puutusime kokku jõudlusraskustega, millest me pole veel üle saanud. Veetsime üle kahe kuu ja saime funktsionaalselt puuduliku armatuurlaua, mille reageerimiskiirus on vastuvõetava piiril. Ja me tegime enda jaoks järeldused:
- Tableau ei saa töötada suurte andmemahtudega. Kui algses andmemudelis on teil rohkem kui 10 GB andmeid (ligikaudu 200 miljonit X 50 rida), siis on armatuurlaud tõsiselt aeglustunud - iga klõpsu puhul 10 sekundist mitme minutini. Katsetasime nii otseühenduse kui ka ekstraktiga. Töökiirus on võrreldav.
- Piirangud mitme salvestusruumi (andmekogumi) kasutamisel. Standardsete vahenditega ei saa andmekogude vahelist seost kuidagi näidata. Kui kasutate andmekogumite ühendamiseks lahendusi, mõjutab see jõudlust oluliselt. Meie puhul kaalusime võimalust realiseerida andmed igas nõutud vaate jaotises ja teha nende materialiseeritud andmekogumite sisselülitamist, säilitades samal ajal eelnevalt valitud filtrid – see osutus Tableau puhul võimatuks.
- Dünaamilisi parameetreid Tableau's teha ei saa. Te ei saa täita parameetrit, mida kasutatakse andmestiku filtreerimiseks väljavõttes või reaalajas ühendamise ajal, andmestikust mõne muu valiku või mõne muu SQL-päringu tulemusega, vaid ainult natiivse kasutaja sisendi või konstandiga.
- OLAP|PivotTable-liigendtabeli elementidega armatuurlaua loomisega seotud piirangud.
Kui lisate MSTR-s, SAP SAC-is, SAP-analüüsis aruandele andmestiku, on kõik sellel olevad objektid omavahel vaikimisi seotud. Tableaul seda pole, ühendus tuleb käsitsi konfigureerida. See on ilmselt paindlikum, kuid kõigi meie armatuurlaudade puhul on see elementide jaoks kohustuslik nõue – seega on tegemist täiendava tööjõukuluga. Veelgi enam, kui teete seotud filtreid nii, et näiteks piirkonna filtreerimisel piirdub linnade loend ainult selle piirkonna linnadega, jõuate kohe järjestikuste päringuteni andmebaasi või Väljavõte, mis aeglustab märgatavalt armatuurlaud. - Funktsioonide piirangud. Massteisendusi ei saa teha ei väljavõttel ega ERITI Live-connecta andmestikul. Seda saab teha Tableau Prepi kaudu, kuid see on lisatöö ja veel üks tööriist, mida õppida ja hooldada. Näiteks ei saa te andmeid üle kanda ega neid iseendaga ühendada. Mis suletakse üksikute veergude või väljade teisendustega, mis tuleb valida läbi case or if, ja see genereerib väga keerukaid SQL päringuid, milles andmebaas veedab suurema osa ajast päringu teksti koostamisel. See tööriista paindumatus tuli lahendada esitluse tasemel, mis toob kaasa keerukama salvestuse, täiendava allalaadimise ja teisendusi.
Me pole Tableau osas alla andnud. Kuid me ei pea Tableaud tööriistaks, mis suudab luua tööstuslikke armatuurlaudu ega vahendit, millega asendada ja digitaliseerida kogu ettevõtte ettevõtte aruandlussüsteem.
Nüüd arendame aktiivselt sarnast armatuurlauda teises tööriistas ja samal ajal proovime Tableau armatuurlaua arhitektuuri üle vaadata, et seda veelgi lihtsustada. Kui kogukond on huvitatud, anname tulemustest teada.
Ootame ka teie ideid või nõuandeid, kuidas saaks Tabeaus nii suurte andmemahtude peale kiireid armatuurlaudu ehitada, sest meil on koduleht, kus andmeid on palju rohkem kui jaemüügis.
Allikas: www.habr.com