Tiden til rapportering i Excel forsvinder hastigt — trenden mod brugervenlige værktøjer til præsentation og analyse af information er synlig i alle områder. Vi har længe diskuteret digitalisering af rapporteringsopbygning og valgt visualiserings- og self-service analytics systemet Tableau. Alexander Bezugly, leder af analytiske løsninger og rapportering i 'M.Video-Eldorado' gruppen, delte sin erfaring og resultaterne af opbygningen af et operationelt dashboard.
Jeg siger med det samme, at ikke alt, hvad der var planlagt, blev realiseret, men erfaringen var interessant, og jeg håber, den vil være nyttig for jer også. Og hvis nogen har ideer til, hvordan vi kunne have gjort det bedre, vil jeg være meget taknemmelig for råd og idéer.
Under her om, hvad vi stødte på og hvad vi lærte.
Hvordan vi startede
I 'M.Video-Eldorado' er der en veludviklet datamodel: struktureret information med den nødvendige dybde af opbevaring og et stort antal faste rapporter (se nærmere ). Af dem laver analytikere enten pivottabeller eller formaterede forsendelser i Excel, eller flotte præsentationer i PowerPoint til slutbrugerne.
For cirka to år siden begyndte vi at skabe analytiske rapporter i SAP Analysis (et tillæg til Excel, i bund og grund — en pivottabel over OLAP-motoren) i stedet for faste rapporter. Men dette værktøj kunne ikke dække alle brugeres behov, og de fleste fortsatte med at bruge information, som analytikerne yderligere behandlede.
Vores slutbrugere opdeles i tre kategorier:
Topledelsen. Anmoder om information i en godt præsenteret og letforståelig form.
Mellemledelsen, avancerede brugere. Er interesseret i dataforskning og i stand til at opbygge rapporter selv, når de har værktøjerne. Det er netop dem, der blev de nøglebrugere af analytiske rapporter i SAP Analysis.
Massebrugere. Er ikke interesseret i selvstændig dataanalyse, bruger rapporter med begrænset frihed, i form af forsendelser og pivottabeller i Excel.
Vores idé var at dække behovene hos alle brugere og give dem et enkelt, praktisk værktøj. Vi besluttede at starte med topledelsen. De havde brug for brugervenlige dashboards til analyse af nøgleforretningsresultater. Så vi startede med Tableau og valgte to områder: salgsresultater i detailhandel og online med en begrænset dybde og bredde af analysen, som ville dække cirka 80% af de data, som topledelsen efterspurgte.
Da brugerne af dashboards var topledelsen, kom der endnu en ekstra KPI til produktet – svartiden. Ingen vil vente 20-30 sekunder på, at dataene opdateres. Navigationen skulle finde sted inden for 4-5 sekunder, og helst skulle det ske øjeblikkeligt. Og det lykkedes desværre ikke for os.
Sådan så layoutet af vores primære dashboard ud:
Den nøgleidé var at samle de vigtigste KPI-drivere, som endte med at blive 19, på venstre side og præsentere deres dynamik og opdeling efter de vigtigste attributter til højre. Opgaven virker enkel, visualiseringen er logisk og forståelig, indtil man dykker ned i detaljerne.
Detail 1. Mængden af data
Den primære tabel for salg i løbet af året indeholder omkring 300 millioner rækker. Da det er nødvendigt at afspejle både dynamikken i forhold til sidste år og det forrige år, er mængden af data kun for faktiske salg omkring 1 milliard rækker. Derudover opbevares oplysninger om planlagte data og blokken for internet-salg separat. Så selvom vi brugte den kolonne-baserede in-memory DB SAP HANA, tog forespørgslen for at vælge alle indikatorer for en uge fra de nuværende lager på farten omkring 15-20 sekunder. Løsningen på denne opgave er åbenbar – yderligere materialisering af data. Men der er også faldgruber i den, som beskrevet nedenfor.
Detail 2. Ikke-additive indikatorer
Mange af vores KPI'er er knyttet til antallet af kvitteringer. Denne indikator repræsenterer COUNT DISTINCT antallet af rækker (overskrifter for kvitteringer) og viser forskellige beløb afhængigt af de valgte attributter. For eksempel, hvordan denne indikator og dens afledte værdier skal beregnes:
For at sikre korrektheden af beregningerne kan man:
- Udføre beregningen af sådanne indikatorer på farten i lageret;
- Udføre beregningen på hele datamængden i Tableau, dvs. ved forespørgsel i Tableau at returnere alle data i henhold til de valgte filtre i granuleringsniveauet for kvitteringspositioner;
- Opret en materialiseret visning, hvor alle målinger beregnes i alle varianter af udtræk, der giver forskellige ikke-additive resultater.
Det er klart, at i eksemplet UTE1 og UTE2 repræsenterer disse materialeattributter den kommercielle hierarki. Det er ikke en statisk ting; der styres internt i virksomheden, da forskellige ledere har ansvar for forskellige produktgrupper. Vi har haft mange globale gennemgange af dette hierarki, hvor alle niveauer ændres, når relationer revideres, samt konstant punktvise ændringer, hvor en gruppe flyttes fra en node til en anden. I almindelig rapportering beregnes alt dette i realtid fra materialeattributterne. I tilfælde af materialisering af disse data er det nødvendigt at udvikle en mekanisme til at overvåge sådanne ændringer og automatisk genindlæse historiske data. Det er en ret ikke-trivial opgave.
Detalje 3. Sammenligning af data
Dette punkt ligner det forrige. Essensen er, at virksomheden ved analyse plejer at danne flere niveauer af sammenligning med fortiden:
Sammenligning med fortiden (dag til dag, uge til uge, måned til måned)
I denne sammenligning antages det, at afhængigt af den periode, brugeren vælger (for eksempel uge 33 i året), skal vi vise udviklingen fra uge 32. Hvis vi valgte data for en måned, for eksempel maj, ville denne sammenligning vise udviklingen i forhold til april.
Sammenligning med sidste år
Den primære nuance her er, at når man sammenligner dage og uger, skal man ikke tage den samme dag fra året før, altså kan man ikke bare tage det nuværende år minus én. Man skal se på den sammenlignede ugedag. Men når man sammenligner måneder, skal man derimod tage præcis samme kalenderdag fra året før. Der er også nuancer med skudår. I de oprindelige datalagre er al information fordelt på dage, der er ingen separate felter for uger, måneder, eller år. Derfor, for at få et fuldstændigt analytisk indsigt i panelet, er man nødt til at tælle ikke bare én periode, for eksempel en uge, men 4 uger, og derefter skal disse data sammenlignes for at afspejle dynamik og afvigelser. Denne logik for at skabe sammenligninger i dynamik kan også implementeres enten i Tableau eller på terminalens side. Ja, og vi vidste naturligvis om disse detaljer og tænkte på dem allerede i designfasen, men det var svært at forudse deres indflydelse på ydeevnen af det endelige dashboard.
Ved implementeringen af dashboardet fulgte vi en lang Agile-rejse. Vores mål var at kunne levere et fungerende værktøj med de nødvendige data til test så hurtigt som muligt. Derfor arbejdede vi i sprint og fokuserede på at minimere arbejdet på den nuværende datalager.
Del 1. Troen på Tableau
For at forenkle IT-support og hurtigt implementere ændringer besluttede vi at skabe logikken for beregningen af ikke-additive indikatorer og sammenligning af tidligere perioder i Tableau.
Trin 1. Alt Live, ingen tilpasninger til terminaler.
I denne fase tilsluttede vi Tableau til de nuværende terminaler og besluttede at se, hvordan antallet af kvitteringer ville blive beregnet over et år.
Resultat:
Svaret var nedslående – 20 minutter. Dataoverførsel over netværket, høj belastning på Tableau. Vi forstod, at logikken med ikke-additive indikatorer skulle implementeres på HANA. Dette skræmte os ikke meget, da vi allerede havde erfaring med BO og Analyse og vidste, hvordan man bygger hurtige terminaler i HANA, som giver korrekt beregnede ikke-additive indikatorer. Nu skulle de bare tilpasses til Tableau.
Trin 2. Vi optimerer terminalerne, ingen materialisering, alt sker on-the-fly.
Vi har oprettet et helt nyt dashboards, der on-the-fly genererede de nødvendige data til TABLEAU. Alt i alt opnåede vi et godt resultat, hvor vi reducerede tiden for at generere alle målinger fra en uge til 9-10 sekunder. Ærligt talt forventede vi, at svartiden for dashboardet i Tableau ville være 20-30 sekunder ved første åbning og derefter, takket være cache, mellem 10 og 12, hvilket i det hele taget ville have været acceptabelt for os.
Resultat:
Første åbning af dashboards: 4-5 minutter
Enhver klik: 3-4 minutter
Ingen forventede en så stor forbedring i dashboards' arbejdstid.
Del 2. Dyk ned i Tableau
Trin 1. Analyse af Tableau-performance og hurtig optimering
Vi begyndte at analysere, hvad Tableau bruger mest tid på. Og der findes ganske gode værktøjer til dette, hvilket naturligvis er et plus for Tableau. Den primære problemstilling, vi identificerede, var meget komplekse SQL-forespørgsler, som Tableau genererede. De var primært relateret til:
— transponering af data. Da Tableau ikke har værktøjer til at transponere dataset, måtte vi for at opbygge den venstre del af dashboardet med en detaljeret fremstilling af alle KPI'er, lave en tabel ved hjælp af case. Størrelsen på SQL-forespørgslerne i databasen nåede 120.000 tegn.
— valg af tidsperiode. En sådan forespørgsel på databasens niveau tog længere tid at kompilere end at udføre:
Det vil sige, behandling af forespørgslen 12 sekunder + 5 sekunder udførelse.
Vi besluttede at forenkle logikken for beregningerne på Tableau-siden og flytte endnu en del af beregningerne til dashboardet og databaseniveauet. Det gav gode resultater.
Først lavede vi transponeringen on-the-fly via en full outer join i den endelige beregning af VIEW, i henhold til denne tilgang beskrevet på wiki og .
Det vil sige, vi lavede en opsætningsmatrix – en transponeringsmatrix (21x21) og fik alle målinger opdelt i rækker.
Tidligere:
Er blevet:
Transponeringen af databasen tager næsten ikke tid. Forespørgslen på alle parametre har taget cirka 10 sekunder som før. Men fleksibiliteten i opbygningen af dashboardet for det specifikke mål er gået tabt, dvs. for den højre del af dashboardet, hvor dynamik og detaljeret opdeling præsenteres, arbejdede tidligere vinduet på 1-3 sekunder, da forespørgslen gik efter ét mål, men nu trækker databasen altid alle mål og filtrerer resultatet, inden det returneres til Tableau.
Som følge heraf er hastigheden på dashboardet næsten faldet med 3 gange.
Resultat:
- 5 sek – parsing af dashboardet, visualiseringer
- 15-20 sek – forberedelse til kompilering af forespørgsler med udførelse af forberegninger i Tableau
- 35-45 sek – kompilering af SQL-forespørgsler og samtidig sekventiel udførelse i Hana
- 5 sek – behandling af resultater, sortering, genberegning af visualiseringer i Tableau
- Selvfølgelig var sådanne resultater ikke acceptable for virksomheden, og vi fortsatte optimeringen.
Trin 2. Minimalt logik i Tableau, fuld materialisering
Vi forstod, at det var umuligt at bygge et dashboard med en responstid på et par sekunder på et vindue, der tager 10 sekunder, og overvejede muligheder for materialisering af data på databasesiden specifikt til det krævede dashboard. Men vi stødte på det store problem beskrevet ovenfor – additive indikatorer. Vi kunne ikke få Tableau til fleksibelt at skifte mellem forskellige vinduer og niveauer, som var forudberegnet til forskellige produkthierarkier (i eksemplet giver tre forespørgsler uden UTE, med UTE1 og UTE2 forskellige resultater). Derfor besluttede vi at forenkle dashboardet, opgive det produktmæssige hierarki i dashboardet og se, hvor hurtigt det kunne være i en forenklet version.
Så på dette sidste trin samlede vi et separat lager, hvor vi i transponeret form lagde alle KPI'er. På databasesiden tager enhver forespørgsel til et sådant lager 0,1 – 0,3 sekunder. I dashboardet fik vi følgende resultater:
Første åbning: 8-10 sekunder
Enhver klik: 6-7 sekunder
Tiden, som Tableau bruger, består af:
- 0,3 sek. – parsing af dashboardet og kompilering af SQL-forespørgsler
- 1,5-3 sek. – udførelse af SQL-forespørgsler i Hana for de primære visualiseringer (startes samtidigt med punkt 1)
- 1,5-2 sek. — rendering, genberegning af visualiseringer
- 1,3 sek. — udførelse af ekstra SQL-forespørgsler for at opnå relevante filterværdier (Brand, Division, By, Butik), parsing af resultater
For at opsummere kort
Vi var glade for Tableau-værktøjet med hensyn til visualisering. I designfasen overvejede vi forskellige visualiseringselementer, og vi fandt dem alle i bibliotekerne, herunder komplekse flerlagede segmenteringer og multitrekants waterfall.
Ved implementering af dashboards med nøgle salgsindikatorer stødte vi på præstationsvanskeligheder, som vi endnu ikke har kunnet overvinde. Vi brugte mere end to måneder og fik et funktionelt ufuldstændigt dashboard, hvis reageringshastighed var på grænsen af acceptabelt. Og vi har konkluderet:
- Tableau kan ikke arbejde med store datamængder. Hvis der i den oprindelige datamodel er mere end 10 GB data (ca. 200 mio. x 50 rækker), så bremser dashboardet alvorligt ned — fra 10 sekunder til flere minutter pr. klik. Vi eksperimenterede både med live-forbindelse og med ekstrakt. Hastigheden er sammenlignelig.
- Begrænsninger ved brug af flere datalagre (datasæt). Der er ikke mulighed for standardmæssigt at angive relationen mellem datasæt. Hvis der anvendes workaround-løsninger til at forbinde datasæt, vil det have stor indflydelse på præstationen. I vores tilfælde overvejede vi muligheden for at materialisere data i hver nødvendig dimension af visningerne og på disse materialiserede datasæt lave skift med bevarelse af tidligere valgte filtre — dette viste sig at være umuligt i Tableau.
- I Tableau er det umuligt at lave dynamiske parametre. Du kan ikke udfylde en parameter, der bruges til filtrering af datasættet i ekstrakten eller ved live-forbindelse, med resultatet af et andet udvalg fra datasættet eller resultatet af en anden SQL-forespørgsel, kun brugerens native input eller en konstant.
- Begrænsninger relateret til opbygning af dashboards med OLAP|Pivot-tabel elementer.
I MSTR, SAP SAC, SAP Analysis, hvis du tilføjer et datasæt til rapporten, så er alle objekter på det forbundet som standard. Dette findes ikke i Tableau, her skal forbindelsen indstilles manuelt. Det er sikkert mere fleksibelt, men for alle vores dashboards er dette et obligatorisk krav til elementerne – derfor er det ekstra arbejdsomkostninger. Desuden, hvis du laver relaterede filtre, så du for eksempel kun ser byer i en region ved filtrering af den region, så får du straks sekventielle forespørgsler til databasen eller ekstraktet, hvilket væsentligt forsinker dashboardet. - Begrænsninger i funktioner. Hverken på ekstraktet eller ISÆR på datasættet fra Live-connecta kan der laves masseændringer. Det kan gøres gennem Tableau Prep, men det kræver ekstra arbejdsomkostninger og endnu et værktøj, som skal læres og vedligeholdes. Du kan for eksempel ikke transponere data eller lave join med dem selv. Det lukkes via transformationer af enkelte kolonner eller felter, der skal vælges gennem case eller if, hvilket skaber meget komplekse SQL-forespørgsler, hvor databasen bruger det meste af tiden på at kompilere forespørgsesteksten. Disse begrænsninger i værktøjet måtte løses på niveauet for vinduet, hvilket fører til en kompleks opbevaringsstruktur, ekstra belastninger og transformationer.
Vi har ikke opgivet Tableau. Men som et værktøj, der er i stand til at bygge industrielle dashboards og som et middel til at erstatte og digitalisere hele virksomhedens rapporteringssystem, betragter vi ikke Tableau.
Vi udvikler i øjeblikket et lignende dashboard i et andet værktøj og prøver parallelt at revurdere arkitekturen af dashboardet i Tableau for at forenkle det endnu mere. Hvis samfundet er interesseret, vil vi dele resultaterne.
Vi ser også frem til jeres ideer eller råd om, hvordan man i Tableau kan bygge hurtige dashboards over sådanne store datamængder, da vi har en hjemmeside, hvor dataene er langt større end i detailhandlen.
Kilde: habr.com
