Tiden for rapportering i Excel forsvinner raskt â trenden med brukervennlige verktĂžy for presentasjon og analyse av informasjon er tydelig i alle omrĂ„der. Vi har lenge diskutert digitalisering av rapportering og valgte visualiserings- og selvbetjent analyssystemet Tableau. Aleksandr Bezugly, leder for avdelingen for analytiske lĂžsninger og rapportering i «M.Video-Eldorado»-gruppen, delte erfaringene og resultatene fra oppbyggingen av et handlingsdashboard.
Jeg vil si med én gang at ikke alt som ble planlagt, ble gjennomfÞrt, men erfaringen var interessant, og jeg hÄper den vil vÊre nyttig for dere ogsÄ. Hvis noen har ideer om hvordan vi kunne ha gjort det bedre, vil jeg sette stor pris pÄ rÄd og forslag.
Under finner du informasjon om hva vi mĂžtte og det vi lĂŠrte.
Hvordan vi startet
I «M.Video-Eldorado» finnes det en godt utviklet datamodell: strukturert informasjon med nÞdvendig lagringsdybde og et stort antall rapporter i fast format (se mer i ). Av disse lager analytikerne enten pivottabeller eller formaterte utsendelser i Excel, eller flotte presentasjoner i PowerPoint for sluttbrukerne.
For omtrent to Ă„r siden begynte vi Ă„ lage analytiske rapporter i SAP Analysis (en tillegg til Excel, essensielt en pivottabell over OLAP-motoren) i stedet for rapporter i fast format. Men dette verktĂžyet klarte ikke Ă„ dekke behovene til alle brukerne, og de fleste fortsatte Ă„ bruke informasjon bearbeidet av analytikere.
VĂ„re sluttbrukere deles inn i tre kategorier:
Topplederne. Be om informasjon pÄ en godt presentert og lettfattelig mÄte.
Mellomledere, avanserte brukere. De er interessert i datagjennomgang og i stand til Ä lage rapporter selv nÄr de har de rette verktÞyene. Det er de som har blitt nÞkkelbrukerne av analytiske rapporter i SAP Analysis.
Massebrukere. De er ikke interessert i selvstendig dataanalyse, og bruker rapporter med begrenset frihet, i format av utsendelser og pivottabeller i Excel.
VÄr idé var Ä dekke behovene til alle brukere og gi dem et enkelt, praktisk verktÞy. Vi begynte med toppledelsen. De trengte brukervennlige paneler for analyse av de viktigste forretningsresultatene. Slik startet vi med Tableau og valgte i fÞrste omgang to retninger: salgsindikatorer for bÄde detaljhandel og nettbutikk med begrenset dybde og bredde i analysene, som skulle dekke omtrent 80 % av dataene som toppledelsen etterspurte.
Siden brukerne av dashbordene var toppledelsen, oppstod det en ekstra KPI for produktet â responstid. Ingen vil vente 20-30 sekunder mens dataene oppdaterer seg. Navigasjonen mĂ„tte vĂŠre innenfor 4-5 sekunder, helst umiddelbart. Og dette klarte vi dessverre ikke.
Slik sÄ utkastet til vÄrt hoveddashbord:
Hovedideen var Ä samle de viktigste KPI-driverne, som til slutt ble 19, til venstre og presentere deres dynamikk og oppdeling etter hovedattributtene til hÞyre. Oppgaven virker ikke komplisert, visualiseringen er logisk og forstÄelig, inntil man dykker inn i detaljene.
Detalj 1. Datamengde
Hovedtabellen for salg for Äret vÄr har omtrent 300 millioner rader. Siden vi mÄ reflektere dynamikken fra forrige og Äret fÞr der, er datamengden bare for faktiske salg omtrent 1 milliard rader. Og separat blir informasjon om planlagte data og blokken for netthandel lagret. Derfor, selv om vi brukte den kolonnedata in-memory DB SAP HANA, var spÞrringshastigheten for Ä velge alle indikatorene for en uke fra de nÄvÊrende lagrene pÄ farten omtrent 15-20 sekunder. LÞsningen pÄ denne oppgaven er Äpenbar - ekstra materialisering av data. Men dette har ogsÄ sine fallgruver, som vi vil gÄ inn pÄ senere.
Detalj 2. Ikke-additive indikatorer
Mange av vÄre KPI-er er knyttet til antall kvitteringer. Denne indikatoren representerer COUNT DISTINCT av antall rader (overskrifter av kvitteringer) og viser ulike summer avhengig av valgte attributter. For eksempel, hvordan denne indikatoren og dens avledninger bÞr beregnes:
For Ă„ sikre nĂžyaktige beregninger kan man:
- UtfĂžre beregningen av slike indikatorer i sanntid i lagringen;
- UtfÞre beregningen pÄ hele datamengden i Tableau, det vil si ved forespÞrsel i Tableau, levere alle data etter valgte filtre i granulariteten til kvitteringsposisjonene;
- Lag en materialisert visning der alle indikatorer beregnes for alle utvalgsvarianter som gir ulike ikke-additive resultater.
Det er klart at i eksempelet UTE1 og UTE2 er dette attributter for materialet som representerer produkthierarkiet. Dette er ikke noe statisk; gjennom det foregÄr styring internt i selskapet, ettersom forskjellige produktgrupper styres av ulike ledere. Vi har hatt mange globale revisjoner av dette hierarkiet der alle nivÄer har blitt endret, hvor sammenhenger har blitt gjennomgÄtt, samt konstante punktvise endringer nÄr en gruppe flyttes fra en node til en annen. I vanlig rapportering blir alt dette beregnet i sanntid fra materialattributtene, i tilfelle av materialisering av disse dataene er det nÞdvendig Ä utvikle en mekanisme for Ä spore slike endringer og automatisk laste opp historiske data. En temmelig ikke-triviell oppgave.
Detalj 3. Sammenligning av data
Dette punktet ligner pÄ det forrige. Kjerne i saken er at i selskapet ved analyse er det vanlig Ä danne flere nivÄer med sammenligning til forrige periode:
Sammenligning med forrige periode (dag for dag, uke for uke, mÄned for mÄned)
I denne sammenligningen antas det at avhengig av den perioden som brukeren velger (for eksempel 33. uke i Äret), mÄ vi vise utviklingen mot 32. uke. Hvis vi for eksempel velger data for en mÄned, mai, vil denne sammenligningen vise utviklingen mot april.
Sammenligning med fjorÄret
Her er hovedpoenget at nÄr man sammenligner dager og uker, tar man ikke den samme dagen fra Äret fÞr, altsÄ kan man ikke bare ta innevÊrende Är minus én. Man mÄ se pÄ den sammenlignede uken. Ved sammenligning av mÄneder mÄ man derimot ta nÞyaktig den samme kalenderdagen fra Äret fÞr. Det er ogsÄ detaljer med skuddÄr. I de underliggende databasene er all informasjon distribuert over dager, det finnes ingen separate felt for uker, mÄneder, eller Är. Derfor, for Ä fÄ et fullstendig analytisk utsnitt i panelet, mÄ man regne med ikke bare én periode, for eksempel en uke, men fire uker, og deretter sammenligne disse dataene for Ä reflektere dynamikk og avvik. FÞlgelig kan ogsÄ denne logikken for sammenligning i dynamikk implementeres enten i Tableau eller pÄ butikkens side. Ja, og vi var selvfÞlgelig klar over disse detaljene og tenkte pÄ dem allerede i designfasen, men det var vanskelig Ä forutsi deres innvirkning pÄ ytelsen til det endelige dashbordet.
Ved implementeringen av dashbordet fulgte vi en lang Agile-reise. VÄr oppgave var Ä sÄ raskt som mulig gi et testverktÞy med de nÞdvendige dataene. Derfor arbeidet vi i sprinter og fokuserte pÄ Ä minimere arbeidet pÄ den nÄvÊrende datakilde.
Del 1. Troen pÄ Tableau
For Ă„ forenkle IT-stĂžtten og raskt implementere endringer, bestemte vi oss for Ă„ gjĂžre logikken for beregning av ikke-additive indikatorer og sammenligning av tidligere perioder i Tableau.
Trinn 1. Alt live, ingen utvikling av butikkene.
PÄ dette trinnet koblet vi Tableau til de nÄvÊrende butikkene og bestemte oss for Ä se hvordan antallet kvitteringer ville bli beregnet over ett Är.
Resultat:
Svaret var nedslĂ„ende â 20 minutter. DataoverfĂžring via nettverket, hĂžy belastning pĂ„ Tableau. Vi forsto at logikken med ikke-additive indikatorer mĂ„tte implementeres pĂ„ HANA. Dette skremte oss ikke mye, vi hadde allerede erfaring med BO og Analysis, og vi visste hvordan vi skulle bygge raske butikker i HANA som gir riktig beregnede ikke-additive indikatorer. NĂ„ gjensto det bare Ă„ tilpasse dem til Tableau.
Trinn 2. Tunet butikkene, ingen materialisering, alt skjer pÄ farten.
Vi har laget et separat nytt grensesnitt som dynamisk leverte de nĂždvendige dataene for TABLEAU. Generelt fikk vi et godt resultat, vi forkjorte tiden for Ă„ generere alle nĂžkkeltall fra en uke til 9-10 sekunder. Og vi forventet ĂŠrlig talt at responstiden for dashbordet i Tableau ville vĂŠre 20-30 sekunder ved fĂžrste Ă„pning, og deretter, takket vĂŠre cache, fra 10 til 12 sekunder, noe som ville vĂŠrt akseptabelt for oss.
Resultat:
FĂžrste Ă„pning av dashbordene: 4-5 minutter
Hver klikk: 3-4 minutter
Ingen forventet en sÄ betydelig forbedring i ytelsen til grensesnittet.
Del 2. Fordypning i Tableau
Trinn 1. Analyse av ytelsen til Tableau og rask tuning
Vi begynte Ä analysere hva Tableau brukte mest tid pÄ. Og for dette finnes det ganske gode verktÞy, noe som selvfÞlgelig er en fordel med Tableau. Den stÞrste utfordringen vi identifiserte, var de meget kompliserte SQL-spÞrringene som Tableau genererte. Disse var fÞrst og fremst knyttet til:
â transponering av data. Siden Tableau ikke har verktĂžy for Ă„ transponere dataset, mĂ„tte vi lage en tabell ved hjelp av case for Ă„ bygge den venstre delen av dashbordet med en detaljert fremstilling av alle KPI-ene. StĂžrrelsen pĂ„ SQL-spĂžrringene i databasen nĂ„dde 120 000 tegn.
â valg av tidsperiode. En slik spĂžrring pĂ„ databasenivĂ„ tok lengre tid Ă„ kompilere enn Ă„ utfĂžre:
Det vil si at behandlingstiden for forespĂžrselen var 12 sekunder + 5 sekunder for utfĂžrelse.
Vi bestemte oss for Ä forenkle logikken for beregningene pÄ Tableau sin side og flytte en annen del av beregningene til grensesnittet og database nivÄ. Dette ga gode resultater.
FÞrst gjorde vi transponeringen dynamisk, ved Ä bruke full outer join pÄ det siste trinnet i beregningen av VIEW, i henhold til tilnÊrmingen beskrevet pÄ wiki og .
SĂ„ vi lagde en innstillingsmatrise â en transponeringsmatrise (21x21) og fikk alle indikatorene fordelt pĂ„ rader.
Var:
Ble:
Selve transposeeringen av databasen tar nesten ingen tid. ForespÞrselen om alle indikatorer for uken ble fortsatt behandlet pÄ omtrent 10 sekunder. Men fleksibiliteten i oppbyggingen av dashbordet for spesifikke indikatorer gikk tapt, det vil si for den hÞyre delen av dashbordet hvor dynamikken og detaljert inndeling av en spesifikk indikator ble presentert, ble lagret tidligere pÄ 1-3 sekunder, da forespÞrselen gikk pÄ én indikator, men nÄ valgte databasen alltid ut alle indikatorene og filtrerte resultatet fÞr det ble returnert til Tableau.
Som et resultat har hastigheten pÄ dashbordet blitt redusert nesten tre ganger.
Resultat:
- 5 sek â parsing av dashbordet, visualiseringer
- 15-20 sek â forberedelse til kompilering av forespĂžrslene med utfĂžring av forberegninger i Tableau
- 35-45 sek â kompilering av SQL-forespĂžrslene og parallell-sekvensiell utfĂžrelse i Hana
- 5 sek â behandling av resultater, sortering, oppregning av visualiseringer i Tableau
- SelvfĂžlgelig var ikke slike resultater tilfredsstillende for virksomheten, og vi fortsatte Ă„ optimalisere.
Trinn 2. Minst logikk i Tableau, full materialisering
Vi forsto at det ville vĂŠre umulig Ă„ lage et dashbord med responstid pĂ„ noen sekunder nĂ„r vinduet fungerer i 10 sekunder, og vi vurderte alternativer for materialisering av data pĂ„ databasesiden spesifikt for det aktuelle dashbordet. Men vi stĂžtte pĂ„ et globalt problem, beskrevet ovenfor â ikke-additive indikatorer. Vi klarte ikke Ă„ gjĂžre det slik at Tableau fleksibelt kunne bytte mellom forskjellige vinduer og nivĂ„er, forhĂ„ndsberegnet for forskjellige varehierarkier (i eksemplet danner tre forespĂžrsel uten UTE, med UTE1 og UTE2 forskjellige resultater). Derfor besluttet vi Ă„ forenkle dashbordet, gi avkall pĂ„ varehierarkiet i dashbordet og se hvor raskt det kan bli i en forenklet versjon.
SĂ„, i dette siste trinnet samlet vi et eget lager, hvor vi la alle KPI-ene i transponert form. PĂ„ databasesiden behandler enhver forespĂžrsel til et slikt lager pĂ„ 0,1 â 0,3 sekunder. I dashbordet fikk vi fĂžlgende resultater:
FĂžrste Ă„pning: 8-10 sekunder
Enhver klikk: 6-7 sekunder
Tiden som Tableau bruker, bestÄr av:
- 0,3 sek â parsing av dashbordet og kompilering av SQL-forespĂžrslene
- 1,5-3 sek â utfĂžrelse av SQL-forespĂžrslene i Hana for hovedvisualiseringene (kjĂžres parallelt med p.1)
- 1,5-2 sek â rendering, omregning av visualiseringer
- 1,3 sek â utfĂžring av ekstra SQL-spĂžrringer for Ă„ hente relevante verdier fra filtre (Merke, Divisjon, By, Butikk), parsing av resultater
Om vi skal oppsummere kort
Vi likte verktÞyet Tableau med tanke pÄ visualisering. I designfasen vurderte vi ulike visualiseringselementer, og vi fant dem alle i bibliotekene, inkludert komplekse flernivÄsegmenteringer og multidrivende waterfall.
NÄr vi implementerte dashboards med viktige salgsindikatorer, stÞtte vi pÄ ytelsesproblemer som vi ikke har klart Ä overkomme ennÄ. Vi brukte over to mÄneder og fikk et funksjonelt ufullstendig dashboard, hvor responstiden er pÄ kanten av akseptabelt. Og vi har konkludert:
- Tableau klarer ikke Ă„ jobbe med store datamengder. Hvis du har mer enn 10 GB data i den opprinnelige datamodellen (ca. 200 millioner x 50 rader), blir dashboardet betydelig tregere â fra 10 sekunder til flere minutter per klikk. Vi eksperimenterte bĂ„de med live-tilkobling og med eksektrakter. Ytelsen var sammenlignbar.
- Begrensninger ved bruk av flere datakilder (datasett). Det er ikke mulig Ă„ angi forholdet mellom datasettene ved standardmetoder. Hvis man bruker omveier for Ă„ koble sammen datasett, vil dette ha stor innvirkning pĂ„ ytelsen. I vĂ„rt tilfelle vurderte vi alternativet med Ă„ materialisere data i hver nĂždvendig skive av presentasjoner, og at man skulle gjĂžre bytter pĂ„ disse materialiserte datasettene med bevaring av tidligere valgte filtre â noe som viste seg Ă„ vĂŠre umulig i Tableau.
- I Tableau er det ikke mulig Ă„ lage dynamiske parametre. Du kan ikke fylle en parameter som brukes til Ă„ filtrere datasettet i ekstraktet eller ved live-tilkobling med resultatet av et annet utvalg fra datasettet eller resultatet av en annen SQL-spĂžrring, bare brukerens native inndata eller konstant.
- Begrensninger knyttet til bygging av dashboards med OLAP-elementer | Pivot-tabeller.
I MSTR, SAP SAC, SAP Analysis, hvis du legger til et datasett i rapporten, er alle objektene knyttet til hverandre som standard. Dette er ikke tilfelle i Tableau, der mĂ„ du sette opp forbindelsen manuelt. Dette er kanskje mer fleksibelt, men for alle vĂ„re dashbord er det et krav til elementene â derfor medfĂžrer det ekstra arbeidskostnader. Videre, hvis du lager relaterte filtrer slik at for eksempel listen over byer begrenses til bare byene i den valgte regionen, vil du straks oppleve sekvensielle spĂžrringer til databasen eller ekstrakten, noe som merkerbart reduserer hastigheten pĂ„ dashbordet. - Begrensninger i funksjoner. Verken pĂ„ ekstrakten eller ikke minst pĂ„ datasettet fra Live-connect kan du utfĂžre storskala transformasjoner. Dette kan gjĂžres via Tableau Prep, men det medfĂžrer ekstra arbeidskostnader og enda et verktĂžy som mĂ„ lĂŠres og vedlikeholdes. Du kan for eksempel ikke transponere data eller gjĂžre en join med seg selv. Dette blir begrenset gjennom transformasjoner pĂ„ individuelle kolonner eller felt, som mĂ„ velges via case eller if, noe som gir svĂŠrt komplekse SQL-spĂžrringer hvor databasen bruker mesteparten av tiden pĂ„ Ă„ kompilere tekstspĂžrringen. Disse begrensningene i verktĂžyet mĂ„tte adresseres pĂ„ nivĂ„et av vitrinene, noe som fĂžrer til mer kompliserte lagringslĂžsninger, ekstra belastninger og transformasjoner.
Vi har ikke avskrevet Tableau. Men som et verktĂžy som kan bygge industrielle dashbord og som et middel for Ă„ erstatte og digitalisere hele selskapets rapporteringssystem, vurderer vi ikke Tableau.
Vi jobber nÄ aktivt med Ä utvikle et tilsvarende dashbord i et annet verktÞy, samtidig som vi prÞver Ä se pÄ arkitekturen til dashbordet i Tableau for Ä forenkle den ytterligere. Hvis dette interesserer samfunnet, vil vi dele resultatene.
Vi venter ogsÄ pÄ deres idéer eller rÄd om hvordan man kan bygge raske dashbord i Tableau med sÄ store datamengder, ettersom vi har vÄr egen nettside, hvor dataene er mye stÞrre enn i detaljhandelen.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish