Ataskaitų teikimo Excel programoje laikas sparčiai nyksta – tendencija į patogius informacijos pateikimo ir analizės įrankius matoma visose srityse. Ilgą laiką viduje diskutavome apie ataskaitų teikimo skaitmeninimą ir pasirinkome „Tableau“ vizualizacijos ir savitarnos analitikos sistemą. M.Video-Eldorado grupės analitinių sprendimų ir ataskaitų skyriaus vadovas Aleksandras Bezugly pasakojo apie kovinio prietaisų skydelio kūrimo patirtį ir rezultatus.
Iš karto pasakysiu, kad ne viskas, kas buvo suplanuota, buvo įgyvendinta, tačiau patirtis buvo įdomi, tikiuosi, kad ji bus naudinga ir jums. O jei kas turi idėjų, kaip būtų galima tai padaryti geriau, būčiau labai dėkingas už patarimus ir idėjas.
Žemiau pateikiama informacija apie tai, su kuo susidūrėme ir apie ką sužinojome.
Nuo ko pradėjome?
M.Video-Eldorado turi gerai išvystytą duomenų modelį: struktūrizuotą informaciją su reikiamu saugojimo gyliu ir daugybe fiksuotos formos ataskaitų (žr. ). Iš jų analitikai sukuria suvestines lenteles arba suformatuotus naujienlaiškius programoje „Excel“ arba gražius „PowerPoint“ pristatymus galutiniams vartotojams.
Maždaug prieš dvejus metus vietoj fiksuotos formos ataskaitų pradėjome kurti analitines ataskaitas SAP analizėje (Excel priedas, iš esmės OLAP variklio sukamoji lentelė). Tačiau ši priemonė negalėjo patenkinti visų vartotojų poreikių, dauguma ir toliau naudojosi analitikų papildomai apdorota informacija.
Mūsų galutiniai vartotojai skirstomi į tris kategorijas:
Aukščiausia vadovybė. Informacijos prašo gerai ir aiškiai suprantamai.
Vidurio vadovybė, pažengusiems vartotojams. Domina duomenų tyrinėjimas ir gali savarankiškai kurti ataskaitas, jei yra įrankių. Jie tapo pagrindiniais SAP analizės analitinių ataskaitų naudotojais.
Masiniai vartotojai. Jie nėra suinteresuoti savarankiškai analizuoti duomenis, jie naudoja ataskaitas su ribota laisve, naujienlaiškių ir suvestinių lentelių formatu programoje „Excel“.
Mūsų idėja buvo patenkinti visų vartotojų poreikius ir suteikti jiems vieną, patogų įrankį. Nusprendėme pradėti nuo aukščiausios vadovybės. Jiems reikėjo lengvai naudojamų prietaisų skydelių, kad galėtų analizuoti pagrindinius verslo rezultatus. Taigi, mes pradėjome nuo „Tableau“ ir pirmiausia pasirinkome dvi kryptis: mažmeninės prekybos ir internetinio pardavimo rodiklius su ribotu analizės gyliu ir platumu, kurie apimtų maždaug 80% aukščiausios vadovybės prašomų duomenų.
Kadangi prietaisų skydelių vartotojai buvo aukščiausio lygio vadovai, atsirado dar vienas papildomas produkto KPI – atsako greitis. Niekas nelauks 20-30 sekundžių, kol duomenys bus atnaujinti. Navigacija turėjo būti atlikta per 4–5 sekundes, o dar geriau – iškart. Ir mums, deja, to pasiekti nepavyko.
Štai kaip atrodė mūsų pagrindinės prietaisų skydelio išdėstymas:
Pagrindinė idėja yra sujungti pagrindinius KPI tvarkykles, kurių iš viso buvo 19, kairėje pusėje ir pateikti jų dinamiką bei suskirstymą pagal pagrindinius požymius dešinėje. Užduotis atrodo paprasta, vizualizacija logiška ir suprantama, kol pasineri į smulkmenas.
Išsamiau 1. Duomenų apimtis
Mūsų pagrindinė metinių pardavimų lentelė užima apie 300 milijonų eilučių. Kadangi būtina atspindėti praėjusių ir užpernai metų dinamiką, vien faktinių pardavimų duomenų apimtis siekia apie 1 mlrd. eilučių. Informacija apie planuojamus duomenis ir pardavimo internetu blokas taip pat saugomas atskirai. Todėl, nors ir naudojome stulpelinę atmintyje esančią DB SAP HANA, užklausos greitis su visų rodiklių parinkimu vienai savaitei iš esamos saugyklos buvo apie 15-20 sekundžių. Šios problemos sprendimas siūlo pats save – papildoma duomenų materializacija. Tačiau jame taip pat yra spąstų, daugiau apie juos žemiau.
Išsami informacija 2. Nepridedami rodikliai
Daugelis mūsų KPI yra susieti su kvitų skaičiumi. Ir šis indikatorius parodo COUNT DISTINCT nuo eilučių skaičiaus (tikrinti antraštes) ir rodo skirtingas sumas, priklausomai nuo pasirinktų atributų. Pavyzdžiui, kaip turėtų būti apskaičiuojamas šis rodiklis ir jo išvestinė priemonė:
Kad skaičiavimai būtų teisingi, galite:
- Apskaičiuokite tokius rodiklius skrydžio metu saugykloje;
- Atlikti visos Tableau duomenų apimties skaičiavimus, t.y. paprašius Tableau, pateikti visus duomenis pagal pasirinktus filtrus kvito pozicijos detalumu;
- Sukurkite materializuotą vitriną, kurioje visi rodikliai bus skaičiuojami visose pavyzdinėse parinktyse, kurios duoda skirtingus rezultatus be priedų.
Akivaizdu, kad pavyzdyje UTE1 ir UTE2 yra medžiagų atributai, atspindintys produkto hierarchiją. Tai nėra statiškas dalykas, valdymas įmonėje vyksta per jį, nes Skirtingi vadovai yra atsakingi už skirtingas produktų grupes. Turėjome daug pasaulinių šios hierarchijos peržiūrų, kai keitėsi visi lygiai, kai buvo peržiūrimi santykiai, ir nuolat keitėsi taškai, kai viena grupė perėjo iš vieno mazgo į kitą. Įprastinėje ataskaitoje visa tai apskaičiuojama iš medžiagos atributų, o šių duomenų materializavimo atveju būtina sukurti mechanizmą, kaip sekti tokius pokyčius ir automatiškai perkrauti istorinius duomenis. Labai nebanali užduotis.
Detalė 3. Duomenų palyginimas
Šis punktas yra panašus į ankstesnį. Esmė ta, kad analizuojant įmonę įprasta formuoti kelis lyginimo lygius su ankstesniu laikotarpiu:
Palyginimas su ankstesniu laikotarpiu (diena iš dienos, savaitė iš savaitės, mėnuo į mėnesį)
Šiame palyginime daroma prielaida, kad priklausomai nuo vartotojo pasirinkto laikotarpio (pvz., 33-ioji metų savaitė), dinamiką turėtume rodyti iki 32-osios savaitės, jei pasirinktume mėnesio duomenis, pavyzdžiui, gegužės mėn. , tada šis palyginimas parodytų dinamiką iki balandžio mėn.
Palyginimas su praėjusiais metais
Pagrindinis niuansas čia yra tas, kad lyginant pagal dieną ir pagal savaitę, jūs imate ne tą pačią praėjusių metų dieną, t.y. negalite tiesiog sudėti einamųjų metų minus vienetų. Turite žiūrėti į savaitės dieną, kurią lyginate. Lyginant mėnesius, priešingai, reikia imti lygiai tą pačią praėjusių metų kalendorinę dieną. Su keliamaisiais metais taip pat yra niuansų. Pradinėse saugyklose visa informacija paskirstoma dienomis, nėra atskirų laukų su savaitėmis, mėnesiais ar metais. Todėl norint gauti pilną analitinį skerspjūvį skydelyje, reikia skaičiuoti ne vieną laikotarpį, pavyzdžiui, savaitę, o 4 savaites, o tada palyginti šiuos duomenis, atspindėti dinamiką, nuokrypius. Atitinkamai, ši dinamikos palyginimų generavimo logika taip pat gali būti įgyvendinta „Tableau“ arba parduotuvės pusėje. Taip, žinoma, mes žinojome ir galvojome apie šias detales projektavimo etape, tačiau buvo sunku numatyti jų poveikį galutinio prietaisų skydelio veikimui.
Diegdami prietaisų skydelį, ėjome ilgą Agile kelią. Mūsų užduotis buvo kuo greičiau pateikti darbo įrankį su reikalingais duomenimis testavimui. Todėl ėmėmės sprintų ir pradėjome kuo labiau sumažinti darbą dabartinės saugyklos pusėje.
1 dalis: Tikėjimas stalu
Siekdami supaprastinti IT palaikymą ir greitai įgyvendinti pakeitimus, nusprendėme Tableau sukurti logiką, pagal kurią skaičiuojame nesudėtinius rodiklius ir lyginant praėjusius laikotarpius.
1 etapas. Viskas gyvai, jokių langų modifikacijų.
Šiame etape Tableau prijungėme prie dabartinių vitrinų ir nusprendėme pažiūrėti, kaip bus skaičiuojamas vienerių metų kvitų skaičius.
Rezultatas:
Atsakymas buvo slegiantis – 20 min. Duomenų perdavimas tinkle, didelė „Tableau“ apkrova. Supratome, kad HANA turi būti įdiegta logika su nepridedančiais indikatoriais. Tai mūsų labai negąsdino, jau turėjome panašios patirties su BO ir Analysis ir žinojome, kaip greitai HANA sukurti vitrinas, kurios gamina teisingai apskaičiuotus nepridedamus rodiklius. Dabar beliko juos pritaikyti prie Tableau.
2 etapas. Deriname vitrinas, jokios materializacijos, viskas skrendant.
Sukūrėme atskirą naują vitriną, kuri paruošė reikiamus TABLEAU duomenis. Apskritai gavome gerą rezultatą, visų rodiklių generavimo laiką per savaitę sumažinome iki 9-10 sekundžių. Ir nuoširdžiai tikėjomės, kad Tableau prietaisų skydelio reakcijos laikas bus 20-30 sekundžių pirmą kartą atidarius, o vėliau dėl talpyklos nuo 10 iki 12, kas apskritai mums tiktų.
Rezultatas:
Pirmas atidarytas prietaisų skydelis: 4–5 minutės
Bet koks paspaudimas: 3–4 minutės
Niekas nesitikėjo tokio papildomo vitrinos darbo padidėjimo.
2 dalis. Pasinerkite į Tableau
1 etapas. Tableau veiklos analizė ir greitas derinimas
Pradėjome analizuoti, kur Tableau praleidžia daugiausiai laiko. Ir tam yra gana gerų įrankių, o tai, žinoma, yra „Tableau“ pliusas. Pagrindinė problema, kurią nustatėme, buvo labai sudėtingos SQL užklausos, kurias kūrė Tableau. Jie pirmiausia buvo susiję su:
— duomenų perkėlimas. Kadangi „Tableau“ neturi įrankių duomenų rinkiniams perkelti, norėdami sukurti kairiąją prietaisų skydelio pusę su išsamiu visų KPI atvaizdu, turėjome sukurti lentelę naudodami atvejį. SQL užklausų dydis duomenų bazėje siekė 120 000 simbolių.
- laiko pasirinkimas. Tokiai užklausai duomenų bazės lygiu sudaryti prireikė daugiau laiko nei vykdyti:
Tie. užklausos apdorojimas 12 sekundžių + 5 sekundžių vykdymas.
Nusprendėme supaprastinti skaičiavimo logiką Tableau pusėje ir perkelti kitą skaičiavimų dalį į parduotuvės ir duomenų bazės lygį. Tai atnešė gerų rezultatų.
Pirma, mes atlikome perkėlimą skrydžio metu, tai padarėme per pilną išorinį sujungimą paskutiniame VIEW skaičiavimo etape, pagal šį metodą, aprašytą wiki. и .
Tai yra, mes sukūrėme nustatymo lentelę - perkėlimo matricą (21x21) ir gavome visus rodiklius suskirstydami eilutę.
Tai buvo:
Tai tapo:
Beveik neskiriama laiko pačiai duomenų bazei perkelti. Prašymas dėl visų savaitės rodiklių ir toliau buvo apdorotas maždaug per 10 sekundžių. Bet kita vertus, lankstumas buvo prarastas konstruojant prietaisų skydelį pagal konkretų rodiklį, t.y. dešiniajai prietaisų skydelio pusei, kur pateikiama konkretaus indikatoriaus dinamika ir detalus suskirstymas, anksčiau vitrina suveikė per 1-3 sekundes, nes užklausa buvo pagrįsta vienu rodikliu, o dabar duomenų bazė visada atrinkdavo visus rodiklius ir prieš grąžindama rezultatą į „Tableau“ išfiltruodavo rezultatą.
Dėl to prietaisų skydelio greitis sumažėjo beveik 3 kartus.
Rezultatas:
- 5 sek. – informacijos suvestinių, vizualizacijų analizavimas
- 15-20 sekundžių - pasiruošimas sudaryti užklausas, atliekant išankstinius skaičiavimus Tableau
- 35-45 sek - SQL užklausų kompiliavimas ir lygiagretus nuoseklus jų vykdymas Hana
- 5 sek – rezultatų apdorojimas, rūšiavimas, vizualizacijų perskaičiavimas Tableau
- Žinoma, tokie rezultatai verslui netiko, ir mes tęsėme optimizavimą.
2 etapas. Minimali logika Tableau, pilna materializacija
Supratome, kad 10 sekundžių veikiančioje parduotuvėje neįmanoma sukurti prietaisų skydelio, kurio atsako laikas būtų kelios sekundės, ir apsvarstėme duomenų bazės duomenų materializavimo galimybes konkrečiai reikiamai prietaisų skydelyje. Tačiau susidūrėme su aukščiau aprašyta globalia problema – neaddityviniais rodikliais. Negalėjome įsitikinti, kad keisdama filtrus ar išsamią informaciją „Tableau“ lanksčiai perjungė skirtingus parduotuvių vitrinas ir lygius, iš anksto sukurtus skirtingoms produktų hierarchijoms (pavyzdyje trys užklausos be UTE, su UTE1 ir UTE2 generuoja skirtingus rezultatus). Todėl nusprendėme supaprastinti prietaisų skydelį, atsisakyti produktų hierarchijos prietaisų skydelyje ir pažiūrėti, kaip greitai ji galėtų veikti supaprastintoje versijoje.
Taigi, šiame paskutiniame etape surinkome atskirą saugyklą, į kurią įtraukėme visus KPI perkeltine forma. Duomenų bazės pusėje bet kokia užklausa tokiai saugyklai apdorojama per 0,1–0,3 sekundės. Prietaisų skydelyje gavome šiuos rezultatus:
Pirmasis atidarymas: 8-10 sekundžių
Bet koks paspaudimas: 6–7 sekundės
Tableau praleistas laikas susideda iš:
- 0,3 sek. — prietaisų skydelio analizavimas ir SQL užklausų kompiliavimas
- 1,5-3 sek. — SQL užklausų vykdymas programoje Hana pagrindinėms vizualizācijām (vykdomas lygiagrečiai su 1 žingsniu)
- 1,5-2 sek. — vizualizacijų atvaizdavimas, perskaičiavimas
- 1,3 sek. — papildomų SQL užklausų vykdymas, norint gauti atitinkamas filtro reikšmes (prekės ženklas, skyrius, miestas, parduotuvė), analizuoti rezultatus
Trumpai apibendrinant
Mums patiko Tableau įrankis vizualizacijos požiūriu. Prototipų kūrimo etape mes apsvarstėme įvairius vizualizacijos elementus ir juos visus radome bibliotekose, įskaitant sudėtingą kelių lygių segmentavimą ir kelių tvarkyklių krioklį.
Diegdami prietaisų skydelius su pagrindiniais pardavimo rodikliais susidūrėme su našumo sunkumais, kurių dar neįveikėme. Praleidome daugiau nei du mėnesius ir gavome funkciškai nepilną prietaisų skydelį, kurio reakcijos greitis yra ant priimtino ribos. Ir mes patys padarėme išvadas:
- „Tableau“ negali dirbti su dideliais duomenų kiekiais. Jei pradiniame duomenų modelyje turite daugiau nei 10 GB duomenų (maždaug 200 mln. X 50 eilučių), prietaisų skydelis labai sulėtės - nuo 10 sekundžių iki kelių minučių kiekvienam paspaudimui. Eksperimentavome ir su tiesioginiu ryšiu, ir su ištraukimu. Veikimo greitis yra panašus.
- Apribojimas naudojant kelias saugyklas (duomenų rinkinius). Neįmanoma nurodyti ryšio tarp duomenų rinkinių naudojant standartines priemones. Jei naudosite sprendimus duomenų rinkiniams prijungti, tai labai paveiks našumą. Mūsų atveju mes svarstėme galimybę materializuoti duomenis kiekvienoje reikiamo rodinio skiltyje ir perjungti šiuos materializuotus duomenų rinkinius, išsaugant anksčiau pasirinktus filtrus – pasirodė, kad to padaryti Tableau neįmanoma.
- „Tableau“ neįmanoma sukurti dinaminių parametrų. Negalite užpildyti parametro, kuris naudojamas duomenų rinkiniui filtruoti ištraukoje arba tiesioginio prisijungimo metu, su kito pasirinkimo iš duomenų rinkinio rezultatu arba kitos SQL užklausos rezultatu, tik vietine vartotojo įvestimi arba konstanta.
- Apribojimai, susiję su prietaisų skydelio kūrimu naudojant OLAP|PivotTable elementus.
MSTR, SAP SAC, SAP analizėse, jei į ataskaitą įtraukiate duomenų rinkinį, visi jame esantys objektai pagal numatytuosius nustatymus yra susiję vienas su kitu. Tableau to neturi; ryšys turi būti sukonfigūruotas rankiniu būdu. Tai tikriausiai yra lankstesnė, bet visuose mūsų prietaisų skydeliuose tai yra privalomas elementų reikalavimas – taigi, tai yra papildomos darbo sąnaudos. Be to, jei sukursite susijusius filtrus taip, kad, pavyzdžiui, filtruojant regioną miestų sąrašas apsiribotų tik šio regiono miestais, iš karto gausite nuoseklias užklausas į duomenų bazę arba ištrauką, o tai pastebimai sulėtina prietaisų skydelis. - Funkcijų apribojimai. Masinių transformacijų negalima atlikti nei ištraukoje, nei, YPAČ, duomenų rinkinyje iš Live-connecta. Tai galima padaryti naudojant „Tableau Prep“, tačiau tai yra papildomas darbas ir dar vienas įrankis, kurį reikia išmokti ir prižiūrėti. Pavyzdžiui, negalite perkelti duomenų arba sujungti jų su savimi. Kas uždaroma per transformacijas atskiruose stulpeliuose ar laukuose, kuriuos reikia pasirinkti raidėmis arba jei, ir tai generuoja labai sudėtingas SQL užklausas, kuriose duomenų bazė praleidžia didžiąją laiko dalį sudarydama užklausos tekstą. Šis įrankio nelankstumas turėjo būti išspręstas demonstravimo lygmeniu, o tai lemia sudėtingesnę saugyklą, papildomus atsisiuntimus ir transformacijas.
Mes neatsisakėme Tableau. Tačiau mes nelaikome Tableau įrankiu, galinčiu sukurti pramoninius prietaisų skydelius ir įrankį, kuriuo būtų galima pakeisti ir skaitmeninti visą įmonės įmonių ataskaitų teikimo sistemą.
Dabar aktyviai kuriame panašią prietaisų skydelį kitame įrankyje ir tuo pačiu metu bandome peržiūrėti Tableau prietaisų skydelio architektūrą, kad ją dar labiau supaprastintume. Jei bendruomenė susidomės, papasakosime apie rezultatus.
Taip pat laukiame jūsų idėjų ar patarimų, kaip Tabeau galite sukurti greitus prietaisų skydelius per tokius didelius duomenų kiekius, nes turime svetainę, kurioje duomenų yra daug daugiau nei mažmeninėje prekyboje.
Šaltinis: www.habr.com