Az Excel jelentési időszaka gyorsan eltűnik — a kényelmes információábrázolási és elemzési eszközök iránti tendencia minden területen megfigyelhető. Már régóta beszélgetünk a jelentések digitalizálásáról, és kiválasztottuk a Tableau vizualizációs és önkiszolgáló analitikai rendszert. Alexander Bezuglyi, a „M.Video-Eldorado” Csoport analitikai megoldásokért és jelentésekért felelős vezetője beszélt a harci műszerfal kialakításának tapasztalatairól és eredményeiről.
Azt kell mondanom, hogy nem minden, amit elképzeltünk, valósult meg, de érdekes tapasztalat volt, remélem, hogy Önöknek is hasznos lesz. Ha valakinek van ötlete arról, hogyan lehetett volna jobban csinálni – nagyon hálás lennék a tanácsokért és ötletekért.
A továbbiakban arról, mivel szembesültünk és mit tanultunk.
Mivel kezdtük
A „M.Video-Eldorado”-nál egy jól kidolgozott adatmodell áll rendelkezésre: strukturált információ a szükséges tárolási mélységgel és rengeteg fix formátumú jelentés (további részletekért lásd ). Ezekből az elemzők vagy összefoglaló táblázatokat készítenek, vagy formázott jelentéseket küldenek az Excelben, vagy szép prezentációkat készítenek PowerPointban a végfelhasználók számára.
Körülbelül két évvel ezelőtt a fix formátumú jelentések helyett elkezdtünk analitikai jelentéseket készíteni az SAP Analysis-ban (az Excel kiegészítője, lényegében egy összefoglaló táblázat az OLAP motor felett). De ez az eszköz nem tudta kielégíteni minden felhasználó igényeit, a legtöbben még mindig az elemzők által kiegészített információt használták.
A végfelhasználóink három kategóriára oszthatók:
A felső vezetés. Olyan információt kérnek, amely jól ábrázolt és könnyen érthető.
Középvezetők, haladó felhasználók. Érdeklik az adatelemzések, és képesek önállóan jelentéseket készíteni, ha rendelkezésre állnak az eszközök. Éppen ők lettek az SAP Analysis analitikai jelentéseinek kulcsfelhasználói.
Tömeges felhasználók. Nem érdeklik őket az önálló adatelemzések, korlátozott szabadsággal rendelkező jelentéseket használnak, jelentések és összefoglaló táblázatok formátumában az Excelben.
A tervünk az volt, hogy lefedjük minden felhasználó igényeit, és egyetlen kényelmes eszközt biztosítunk számukra. A top menedzsmenttel kezdtük, mivel nekik kényelmes panelekkel volt szükségük a főbb üzleti eredmények elemzésére. Tehát indítottuk a Tableau-val, és két irányt választottunk: a kiskereskedelmi és online értékesítési mutatók elemzése korlátozott mélységgel és szélességgel, amelyek körülbelül az adatok 80%-át lefednék, amelyeket a top menedzsment kérhetett.
Mivel a dashboardok felhasználói a top menedzsment volt, egy újabb KPI is megjelent a termék számára - a válaszidő. Senki sem szeretne 20-30 másodpercet várni, amíg frissülnek az adatok. A navigációnak 4-5 másodperc alatt meg kellett történnie, de a legjobb az lenne, ha azonnal működne. Ezt sajnos nem tudtuk elérni.
Így nézett ki a fő dashboardunk makettje:
A kulcsötlet az, hogy összevonjuk a fő KPI-vezetőket, amelyek végül 19 számot tettek ki, bal oldalon, és jobbra mutatjuk be dinamikájukat és bontásukat a fő attribútumok szerint. A feladat nem tűnik bonyolultnak, a vizualizáció logikusnak és érthetőnek tűnik, amíg nem merülsz el a részletekben.
Részlet 1. Az adatmennyiség
A fő értékesítési táblázatunk egy évre körülbelül 300 millió sort foglal magában. Mivel meg kell jeleníteni a dinamikát az előző és az azt megelőző évben, a tényleges értékesítési adatok körülbelül 1 milliárd sort tesznek ki. Továbbá külön tárolja a tervezett adatok információit és az online értékesítési blokkot. Ezért, még akkor is, ha a SAP HANA oszlop-alapú in-memory DB-t használtuk, az összes mutató egy heti lekérdezésének sebessége a jelenlegi tárolókból körülbelül 15-20 másodperc volt. E feladat megoldása egyértelműen adja magát - további adatok materializálása. De ennek is vannak rejtett buktatói, amelyeket lentebb ismertetünk.
Részlet 2. Nem additív mutatók
Sok KPI-nk a nyugták számához van kötve. Ez a mutató a COUNT DISTINCT sorok számát (a nyugtafejlécek számát) jelenti, és attól függően mutat különböző összegeket, hogy mely attribútumokat választják. Például, hogy ezen mutatót és az abból származókat hogyan kell számolni:
A számítások helyessége érdekében lehet:
- A hasonló mutatók számítását valós időben végezni a tárolóban;
- A számítást a teljes adatmennyiségre végezni a Tableau-ban, azaz a Tableau-ban minden adatot visszaadni a kiválasztott szűrők alapján a nyugta pozícióinak részletességében;
- Készítsen egy materializált bemutatót, amelyben minden mutató kiszámításra kerül minden lekérdezési variációban, amelyek eltérő nem-additív eredményeket adnak.
Nyilvánvaló, hogy az UTÉ1 és UTÉ2 az anyag attribútumai, amelyek a termékhierarchiát képviselik. Ez nem egy statikus dolog, ezen keresztül történik a vállalaton belüli irányítás, mivel különböző termékcsoportokért különböző menedzserek felelnek. Sok globális felülvizsgálatot hajtottunk végre ezen a hierarchián, amikor az összes szint megváltozott, amikor a kölcsönhatásokat felülvizsgálták, valamint állandó pontszerű változtatásokat, amikor egy csoport egyik csomópontból a másikba lépett át. A normál jelentésekben mindezt az anyag attribútumaiból számolják ki menet közben, a várt adatok materializálása esetén szükséges egy olyan mechanizmus kifejlesztése, amely nyomon követi az ilyen módosításokat és automatikus újratöltést végez a történeti adatok esetében. Ez egy meglehetősen összetett feladat.
3. számú rész. Az adatok összehasonlítása
Ez a pont hasonló az előzőhöz. A lényeg az, hogy a vállalatnál az elemzés során több összehasonlítási szintet alakítanak ki a korábbi időszakkal:
Összehasonlítás a korábbi időszakkal (napról napra, héttől hétig, hónapról hónapra)
Ebben az összehasonlításban azt feltételezzük, hogy a kiválasztott felhasználói időszak (például az év 33. hete) alapján meg kell mutatnunk a dinamikát a 32. héthez képest; ha az adatokat például májusra választanánk, akkor ez az összehasonlítás áprilisi dinamikát mutatna.
Összehasonlítás a tavalyi évvel
Itt a fő szempont az, hogy a napok és hetek szerinti összehasonlítás során nem ugyanazt a dátumot kell venni az előző évből, azaz nem lehet egyszerűen csak az aktuális évet csökkenteni eggyel. A vizsgált hét napjának a számítását figyelembe kell venni. Ezzel szemben a hónapok összehasonlításánál pontosan az előző év azonos naptári napját kell venni. Továbbá, figyelembe kell venni a szökőéveket is. Az alap tárolókban minden információ napokra van elosztva, nincsenek külön mezők hetekhez, hónapokhoz vagy évekhez. Ezért a teljes analitikai elemzés érdekében a panelben nem egyetlen időszakot, például egy hetet kell számítani, hanem négy hetet, majd ezeket az adatokat össze kell hasonlítani, hogy tükrözzék a dinamikát és az eltéréseket. Ennek megfelelően ezt a dinamikus összehasonlítási logikát a Tableauban vagy a front-end oldalon is meg lehet valósítani. Igen, és ezekről a részletekről már a tervezési szakaszban tudtunk és gondolkodtunk, de a végső irányítópult teljesítményére gyakorolt hatásuk előrejelzése nehéz volt.
A dashboard implementálásakor hosszú Agile úton haladtunk. Célunk az volt, hogy a lehető leggyorsabban egy működő eszközt biztosítsunk tesztelésre a szükséges adatokkal. Ezért sprintekre épültünk és a jelenlegi tárolón végzett munka minimalizálására összpontosítottunk.
1. rész. Hit a Tableauban
Az IT támogatás egyszerűsítése és a változtatások gyors bevezetése érdekében úgy döntöttünk, hogy a nem aditiv mutatók számításának logikáját és a korábbi időszakok összehasonlítását a Tableauban végezzük.
1. lépés. Minden élő, semmilyen finomítás a front-endnél.
Ezen a lépésen csatlakoztattuk a Tableaut a jelenlegi front-endhez, és megnéztük, hogyan számítják az egy év alatt kiállított bizonylatok számát.
Eredmény:
A válasz sajnos kiábrándító volt – 20 perc. Az adatok átkonvertálása a hálózaton, magas terhelés a Tableaura. Rájöttük, hogy a nem aditiv mutatók logikáját a HANÁ-n kell megvalósítani. Ez nem aggasztott minket, már volt hasonló tapasztalatunk a BO-val és az Analysis-szal, és tudtuk, hogyan kell gyors front-endeket építeni a HANÁ-ban, amelyek helyesen számolják a nem aditiv mutatókat. Most már csak azt kellett beállítani, hogy együttműködjön a Tableaunal.
2. lépés. Finomítjuk a front-endet, semmilyen anyagképzés, minden azonnal.
Külön új megjelenítést készítettünk, amely folyamatosan szolgáltatta a szükséges adatokat a TABLEAU számára. Összességében jó eredményt értünk el, csökkentettük az összes mutató előállításának idejét egy hét alatt 9-10 másodpercre. Őszintén vártuk, hogy a Tableau-ban a műszerfal válaszideje az első megnyitáskor 20-30 másodperc lesz, majd a gyorsítótár miatt 10-12 másodperc, ami összességében kielégítő lett volna számunkra.
Eredmény:
Első megnyitott műszerfal: 4-5 perc
Bármely kattintás: 3-4 perc
Senki sem számított ilyen további növekményre a megjelenítés működésében.
2. rész. Merüljünk el a Tableau-ban
1. lépés. A Tableau teljesítményének elemzése és gyors optimalizálás
Kezdtük elemezni, hogy mire költi a Tableau a legfőbb időt. Erre nézve meglehetősen jó eszközök állnak rendelkezésre, ami természetesen a Tableau előnye. A fő probléma, amit feltártunk, a nagyon bonyolult SQL lekérdezések voltak, amelyeket a Tableau épített. Ezek elsősorban a következőkkel kapcsolatosak:
— az adatok transzponálásával. Mivel a Tableau-nak nincsenek eszközei a datasetek transzponálására, az összes KPI részletes megjelenítéséhez a műszerfal bal oldalán, táblázatot kellett képeznünk case segítségével. Az SQL lekérdezések mérete az adatbázisban elérte a 120 000 karaktert.
— az időszak kiválasztásával. Ez a lekérdezés az adatbázis szintjén több időt igényelt a fordításhoz, mint a végrehajtáshoz:
Tehát a lekérdezés feldolgozása 12 másodperc + 5 másodperc végrehajtás.
Döntöttünk, hogy egyszerűsítjük a számítások logikáját a Tableau oldalán, és további számítási részeket áthelyezünk a megjelenítéshez és az adatbázis szintjére. Ez jó eredményeket hozott.
Először a transzponálást valós időben hajtottuk végre, egy full outer join segítségével az VIEW végső kiszámításának szakaszában, a wiki-n leírt megközelítésnek megfelelően. és .
Tehát készítettünk egy beállító táblázatot – egy transzponáló mátrixot (21x21), és minden mutatót soronkénti bontásban kaptunk.
Régebben:
Most:
Az adatbázis transzponálása szinte nem igényel időt. A heti összes mutatóra vonatkozó lekérdezés továbbra is körülbelül 10 másodperc alatt futott le. Viszont elveszett a rugalmasság a konkrét mutatóra épülő irányítópult létrehozásában, azaz az irányítópult jobb oldalán, ahol a mutató dinamikáját és részletes bontását mutattuk, korábban az adatgyűjtő 1-3 másodperc alatt teljesítette a lekérdezést, mivel a lekérdezés egy mutatóra vonatkozott, most viszont az adatbázis mindig az összes mutatót kiválasztja, és az eredményeket csak azután szűri, hogy azokat visszaküldi a Tableau-nak.
Ennek eredményeként az irányítópult működési sebessége csaknem háromszorosára csökkent.
Eredmény:
- 5 másodperc — az irányítópult és a vizualizációk parszolása
- 15-20 másodperc — előkészítés a lekérdezések összeállítására a Tableau előszámításával
- 35-45 másodperc — SQL-lekérdezések összeállítása és párhuzamos, soros végrehajtásuk a Hanán
- 5 másodperc — az eredmények feldolgozása, rendezése, a vizualizációk újraszámítása a Tableau-ban
- Természetesen ezek az eredmények nem voltak elfogadhatóak az üzlet számára, így folytattuk az optimalizálást.
2. lépés. Minimális logika a Tableau-ban, teljes anyaggyűjtés
Tudtuk, hogy egy olyan irányítópultot, amelynek válaszideje néhány másodperc, nem lehet elkészíteni egy olyan gyűjtőből, amely 10 másodperc alatt működik. Ezért azt a lehetőséget fontolgattuk, hogy az adatokat az adatbázis oldalán anyaggyűjtésre állítsuk elő a megkövetelt irányítópulthoz. De szembesültünk a fent leírt globális problémával - az adatok nem additívak. Nem tudtuk elérni, hogy a Tableau a szűrők vagy kibővítések változásakor rugalmasan váltson a különböző gyűjtők és szintek között, amelyeket különböző termékhierarchiákhoz előszámítottak (a példában a három lekérdezés, az UT1 és UT2 nem additív eredményeket alkot). Ezért úgy döntöttünk, hogy egyszerűsítjük az irányítópultot, elvetjük a termékhierarchiát, és megnézzük, mennyire tud egyszerűsített változatban gyors lenni.
Tehát az utolsó lépésben egy külön tárolót hoztunk létre, amelyben transzponált formában összegyűjtöttük az összes KPI-t. Az adatbázis oldalán bármely lekérdezés egy ilyen tárolóra 0,1 - 0,3 másodperc alatt fut le. Az irányítópultban a következő eredményeket kaptuk:
Első indítás: 8-10 másodperc
Bármely kattintás: 6-7 másodperc
A Tableau által eltöltött idő a következőkből áll:
- 0,3 másodperc — az irányítópult parszolása és SQL-lekérdezések összeállítása
- 1,5-3 másodperc — SQL-lekérdezések végrehajtása a Hanán a fő vizualizációkhoz (párhuzamosan indítva az 1. ponttal)
- 1,5-2 másodperc — renderelés, vizualizációk újraszámítása
- 1,3 másodperc — további SQL lekérdezések végrehajtása releváns szűrőértékek (Márka, Divízió, Város, Bolt) beszerzéséhez, az eredmények kiértékelése
Ha röviden összegeznénk
A Tableau eszközt tetszett a vizualizációk szempontjából. A tervezési szakaszban különböző vizualizációs elemeket vizsgáltunk, és mindet megtaláltuk a könyvtárakban, beleértve a bonyolult, többszintű szegmentálásokat és a több hajtómotoros waterfall vizualizációkat.
Az értékesítési mutatókkal rendelkező műszerfalak bevezetése során teljesítménybeli nehézségekkel találkoztunk, amelyeket eddig nem tudtunk megoldani. Több mint két hónapot töltöttünk ezzel, és egy funkcionálisan hiányos műszerfalat kaptunk, amelynek válaszideje a megengedett határ közelében van. Megfogalmaztuk a következő következtetéseket:
- A Tableau nem tud nagy adatmennyiségekkel dolgozni. Ha a forrásadat-modellben több mint 10 GB adat van (körülbelül 200 millió x 50 sor), akkor a műszerfal jelentősen lelassul — 10 másodperctől több percre minden kattintásnál. Kísérleteztünk élő csatlakozással és lekérdezéssel is. A munka sebessége összehasonlítható.
- Korlátozás több tároló (adatkészlet) használatakor. Nincs lehetőség arra, hogy a standard eszközökkel megadjuk az adatforrások közötti kapcsolatokat. Ha megkerülő megoldásokat használunk az adatforrások összekapcsolására, az jelentősen befolyásolja a teljesítményt. Esetünkben azt a lehetőséget vizsgáltuk, hogy az adatokat minden szükséges dimenzióban anyagiasítani kellene, és ezeket az anyagiasított adatforrásokat használva váltani a korábban kiválasztott szűrők megőrzésével — ezt a Tableau-ban nem tudtuk megvalósítani.
- A Tableau-ban lehetetlen dinamikus paramétereket készíteni. Nem tudja azt a paramétert, amelyet a készlet szűrésére használnak az lekérdezésben vagy élő csatlakozásban, egy másik adatforrás kiválasztásával vagy egy másik SQL lekérdezés eredményével kitölteni, csak natív felhasználói bevitt értéket vagy konstansot.
- Korlátozások a műszerfal olyan elemeinek létrehozása során, amelyek OLAP|összesítő táblázatokat tartalmaznak.
A MSTR, SAP SAC, SAP Analysis rendszerben, ha egy jelentéshez adatbázist ad hozzá, akkor az összes objektum alapértelmezetten összekapcsolódik. A Tableau esetében ez nem így van, a kapcsolatokat manuálisan kell beállítani. Ez valószínűleg rugalmasabb, de minden egyes irányítópultunknál kötelező követelmény az elemekhez, ami így plusz munkát jelent. Ráadásul, ha kapcsolt szűrőket használ, hogy például a régió szűrésekor a városok listáját csak a régió városaira korlátozza, azonnal következő adatbázis-lekérdezéseket vagy kinyeréseket generál, ami észrevehetően lelassítja az irányítópultot. - Megkötések a funkciókban. Sem az kinyerésen, sem pedig a Live-connect adatbázison nem lehet tömeges átalakításokat végezni. Ezt a Tableau Prep segítségével lehet megtenni, de ez plusz munkát és új eszközt jelent, amit meg kell tanulni és karbantartani. Például nem tudja transzponálni az adatokat, vagy egyesíteni azokat önmagukkal. Az egyes oszlopokkal vagy mezőkkel végzett átalakítások esetében, amit case vagy if segítségével kell kiválasztani, nagyon bonyolult SQL-lekérdezéseket generál, amelyek során az adatbázis főleg a lekérdezés szövegének fordítására pazarolja az időt. Ezen eszköz rugalmatlanságait a réteg szintjén kellett megoldanunk, ami a tároló bonyolításához vezetett, plusz terhelésekhez és átalakításokhoz.
Nem mondtunk le a Tableau-ról. De mint eszköz, amely képes ipari jellegű irányítópultokat építeni és arra is alkalmas, hogy a vállalati jelentési rendszert digitális formára váltja, nem tekintünk rá.
Jelenleg egy hasonló irányítópultot fejlesztünk egy másik eszközzel, és párhuzamosan próbáljuk átgondolni a Tableau irányítópult architektúráját, hogy még inkább egyszerűsítsük. Ha a közösséget érdekli, beszámolunk az eredményekről.
Várjuk az ötleteiket vagy tanácsaikat arról, hogyan lehet a Tableau-n gyors irányítópultokat építeni ilyen nagy adatmennyiségek fölött, hiszen a weboldalunkon az adatok mennyisége lényegesen nagyobb, mint a kiskereskedelemben.
Forrás: habr.com
