Tablå i detaljhandelen, egentlig?

Tiden for rapportering i Excel forsvinner raskt – trenden mot praktiske verktøy for å presentere og analysere informasjon er synlig på alle områder. Vi har internt diskutert digitalisering av rapportering i lang tid og valgte systemet Tableau visualisering og selvbetjeningsanalyse. Alexander Bezugly, leder for analytiske løsninger og rapporteringsavdelingen til M.Video-Eldorado Group, snakket om opplevelsen og resultatene av å bygge et kampdashbord.

Jeg vil si med en gang at ikke alt som var planlagt ble realisert, men opplevelsen var interessant, jeg håper den vil være nyttig for deg også. Og hvis noen har noen ideer om hvordan det kan gjøres bedre, vil jeg være veldig takknemlig for råd og ideer.

Under snittet handler det om hva vi møtte og hva vi lærte om.

Hvor begynte vi?

M.Video-Eldorado har en velutviklet datamodell: strukturert informasjon med nødvendig lagringsdybde og et stort antall rapporter i fast form (se flere detaljer denne artikkelen). Fra disse lager analytikere enten pivottabeller eller formaterte nyhetsbrev i Excel, eller vakre PowerPoint-presentasjoner for sluttbrukere.

For omtrent to år siden begynte vi å lage analytiske rapporter i SAP Analysis (et Excel-tillegg, i hovedsak en pivottabell over OLAP-motoren) i stedet for rapporter i fast form. Men dette verktøyet var ikke i stand til å møte behovene til alle brukere; flertallet fortsatte å bruke informasjon som ble behandlet i tillegg av analytikere.

Våre sluttbrukere faller inn i tre kategorier:

Toppledelse. Ber om informasjon på en godt presentert og klart forståelig måte.

Mellomledere, avanserte brukere. Interessert i datautforskning og i stand til å selvstendig bygge rapporter hvis verktøy er tilgjengelige. De ble nøkkelbrukerne av analytiske rapporter i SAP Analysis.

Massebrukere. De er ikke interessert i å analysere data uavhengig, de bruker rapporter med begrenset grad av frihet, i formatet nyhetsbrev og pivottabeller i Excel.

Vår idé var å dekke behovene til alle brukere og gi dem ett enkelt, praktisk verktøy. Vi bestemte oss for å starte med toppledelsen. De trengte brukervennlige dashboards for å analysere viktige forretningsresultater. Så vi startet med Tableau og valgte først to retninger: detaljhandels- og nettsalgsindikatorer med begrenset dybde og analysebredde, som ville dekke omtrent 80 % av dataene som ble bedt om av toppledelsen.

Siden brukerne av dashbordene var toppledelsen, dukket det opp enda en ekstra KPI for produktet - responshastighet. Ingen vil vente 20-30 sekunder på at dataene skal oppdateres. Navigasjonen burde vært utført innen 4-5 sekunder, eller enda bedre, gjort umiddelbart. Og vi, dessverre, klarte ikke å oppnå dette.

Slik så utformingen av hoveddashbordet vårt ut:

Nøkkelideen er å kombinere de viktigste KPI-driverne, hvorav det var 19 totalt, til venstre og presentere deres dynamikk og inndeling etter hovedattributter til høyre. Oppgaven virker enkel, visualiseringen er logisk og forståelig, helt til du dykker ned i detaljene.

Detalj 1. Datavolum

Vår hovedtabell for årlig omsetning tar opp omtrent 300 millioner rader. Siden det er nødvendig å gjenspeile dynamikken for fjoråret og året før, er datavolumet om faktisk salg alene omtrent 1 milliard linjer. Informasjon om planlagte data og nettsalgsblokken lagres også separat. Derfor, selv om vi brukte den søyleformede DB SAP HANA i minnet, var hastigheten på spørringen med valg av alle indikatorer i én uke fra gjeldende lagring på flukt omtrent 15-20 sekunder. Løsningen på dette problemet foreslår seg selv - ytterligere materialisering av data. Men den har også fallgruver, mer om dem nedenfor.

Detalj 2. Ikke-additive indikatorer

Mange av våre KPIer er knyttet til antall kvitteringer. Og denne indikatoren representerer COUNT DISTINCT av antall rader (sjekk overskrifter) og viser forskjellige mengder avhengig av de valgte attributtene. For eksempel, hvordan denne indikatoren og dens derivater skal beregnes:

For å gjøre beregningene korrekte kan du:

• Beregn slike indikatorer på farten i lageret;
• Utfør beregninger på hele datavolumet i Tableau, dvs. på forespørsel i Tableau, oppgi alle data i henhold til utvalgte filtre i granulariteten til mottaksposisjonen;
• Lag et materialisert utstillingsvindu der alle indikatorer vil bli beregnet i alle prøvealternativer som gir forskjellige ikke-additive resultater.

Det er tydelig at i eksemplet er UTE1 og UTE2 materielle attributter som representerer produkthierarkiet. Dette er ikke en statisk ting; ledelsen i selskapet foregår gjennom det, fordi Ulike ledere har ansvar for ulike produktgrupper. Vi hadde mange globale revisjoner av dette hierarkiet, da alle nivåer endret seg, da relasjoner ble revidert, og konstante punktendringer, når en gruppe flyttet fra en node til en annen. I konvensjonell rapportering beregnes alt dette på flukt fra attributtene til materialet; i tilfelle materialisering av disse dataene er det nødvendig å utvikle en mekanisme for å spore slike endringer og automatisk laste inn historiske data på nytt. En veldig ikke-triviell oppgave.

Detalj 3. Datasammenligning

Dette punktet ligner det forrige. Poenget er at når man analyserer et selskap, er det vanlig å danne flere nivåer av sammenligning med forrige periode:

Sammenligning med forrige periode (dag til dag, uke til uke, måned til måned)

I denne sammenligningen antas det at avhengig av perioden valgt av brukeren (for eksempel den 33. uken i året), skal vi vise dynamikken innen den 32. uken; hvis vi valgte data for en måned, for eksempel mai , så vil denne sammenligningen vise dynamikken innen april.

Sammenligning med fjoråret

Hovednyansen her er at når du sammenligner etter dag og uke, tar du ikke samme dag i fjor, dvs. du kan ikke bare sette inneværende år minus én. Du må se på ukedagen du sammenligner. Når du sammenligner måneder, må du tvert imot ta nøyaktig samme kalenderdag i fjor. Det er også nyanser med skuddår. I de originale depotene er all informasjon distribuert etter dag, det er ingen separate felt med uker, måneder eller år. Derfor, for å få et fullstendig analytisk tverrsnitt i panelet, må du ikke telle en periode, for eksempel en uke, men 4 uker, og deretter sammenligne disse dataene, gjenspeile dynamikken, avvikene. Følgelig kan denne logikken for å generere sammenligninger i dynamikk også implementeres enten i Tableau eller på butikksiden. Ja, og selvfølgelig visste vi og tenkte på disse detaljene på designstadiet, men det var vanskelig å forutsi deres innvirkning på ytelsen til det endelige dashbordet.

Da vi implementerte dashbordet, fulgte vi den lange Agile-veien. Vår oppgave var å gi et arbeidsverktøy med nødvendige data for testing så raskt som mulig. Derfor gikk vi i spurter og tok utgangspunkt i å minimere arbeidet på siden av dagens lager.

Del 1: Tro på tablå

For å forenkle IT-støtte og raskt implementere endringer, bestemte vi oss for å lage logikken for å beregne ikke-additive indikatorer og sammenligne tidligere perioder i Tableau.

Trinn 1. Alt er live, ingen vindusendringer.

På dette stadiet koblet vi Tableau til de nåværende butikkfrontene og bestemte oss for å se hvordan antall kvitteringer for ett år ville bli beregnet.

Resultat:

Svaret var deprimerende - 20 minutter. Overføring av data over nettverket, høy belastning på Tableau. Vi innså at logikk med ikke-additive indikatorer må implementeres på HANA. Dette skremte oss ikke mye, vi hadde allerede lignende erfaring med BO og Analysis, og vi visste hvordan vi kunne bygge raske utstillingsvinduer i HANA som produserer korrekt beregnede ikke-additive indikatorer. Nå gjensto det bare å tilpasse dem til Tableau.

Trinn 2. Vi tuner vitrinene, ingen materialisering, alt på farten.

Vi opprettet et eget nytt utstillingsvindu som produserte de nødvendige dataene for TABLEAU på farten. Generelt fikk vi et godt resultat; vi reduserte tiden for å generere alle indikatorer på en uke til 9-10 sekunder. Og vi forventet ærlig talt at i Tableau ville responstiden til dashbordet være 20-30 sekunder ved første åpning og deretter på grunn av cachen fra 10 til 12, som generelt sett ville passe oss.

Resultat:

Første åpne dashbord: 4-5 minutter
Ethvert klikk: 3-4 minutter
Ingen forventet en slik ekstra økning i arbeidet med butikkfronten.

Del 2. Dykk ned i Tableau

Trinn 1. Tableau ytelsesanalyse og rask tuning

Vi begynte å analysere hvor Tableau tilbringer mesteparten av tiden sin. Og det er ganske gode verktøy for dette, som selvfølgelig er et pluss med Tableau. Hovedproblemet vi identifiserte var de svært komplekse SQL-spørringene som Tableau bygde. De var først og fremst assosiert med:

— dataoverføring. Siden Tableau ikke har verktøy for å transponere datasett, for å bygge venstre side av dashbordet med en detaljert representasjon av alle KPIer, måtte vi lage en tabell ved hjelp av en case. Størrelsen på SQL-spørringer i databasen nådde 120 000 tegn.

- valg av tidsperiode. En slik spørring på databasenivå tok mer tid å kompilere enn å utføre:

De. forespørselsbehandling 12 sekunder + 5 sekunder utførelse.

Vi bestemte oss for å forenkle beregningslogikken på Tableau-siden og flytte en annen del av beregningene til butikk- og databasenivå. Dette ga gode resultater.

Først gjorde vi transponeringen i farten, vi gjorde det gjennom en fullstendig ytre sammenføyning på sluttfasen av VIEW-beregningen, i henhold til denne tilnærmingen beskrevet på wikien Transponere - Wikipedia, det frie leksikonet и Elementær matrise - Wikipedia, det frie leksikonet.

Det vil si at vi laget en innstillingstabell - en transponeringsmatrise (21x21) og mottok alle indikatorene i en rad-for-rad-sammenbrudd.

Det var:


Det ble:


Det brukes nesten ikke tid på selve databasetransponeringen. Forespørselen om alle indikatorer for uken fortsatte å bli behandlet på omtrent 10 sekunder. Men på den annen side har fleksibiliteten gått tapt når det gjelder å konstruere et dashbord basert på en spesifikk indikator, d.v.s. for høyre side av dashbordet der dynamikken og detaljert sammenbrudd av en spesifikk indikator er presentert, tidligere fungerte displayet på 1-3 sekunder, fordi forespørselen var basert på én indikator, og nå valgte databasen alltid alle indikatorer og filtrerte resultatet før resultatet returnerte til Tableau.

Som et resultat ble hastigheten på dashbordet redusert med nesten 3 ganger.

Resultat:

1. 5 sek – analysering av dashbord, visualiseringer
2. 15-20 sekunder - forberedelse for å kompilere spørringer med å utføre forhåndsberegninger i Tableau
3. 35-45 sek - kompilering av SQL-spørringer og deres parallell-sekvensielle kjøring i Hana
4. 5 sek – behandling av resultater, sortering, rekalkulering av visualiseringer i Tableau
5. Slike resultater passet selvsagt ikke virksomheten, og vi fortsatte optimaliseringen.

Trinn 2. Minimum logikk i Tableau, fullstendig materialisering

Vi forsto at det var umulig å bygge et dashbord med en responstid på flere sekunder på en butikkfront som går i 10 sekunder, og vi vurderte alternativer for å materialisere data på databasesiden spesifikt for det nødvendige dashbordet. Men vi møtte et globalt problem beskrevet ovenfor - ikke-additive indikatorer. Vi var ikke i stand til å forsikre oss om at Tableau byttet fleksibelt mellom forskjellige butikkfronter og nivåer som var forhåndsdesignet for forskjellige produkthierarkier ved endring av filtre eller drilldowns (i eksemplet genererer tre spørringer uten UTE, med UTE1 og UTE2 forskjellige resultater). Derfor bestemte vi oss for å forenkle dashbordet, forlate produkthierarkiet i dashbordet og se hvor raskt det kunne være i en forenklet versjon.

Så på dette siste stadiet samlet vi et eget depot der vi la til alle KPIene i transponert form. På databasesiden behandles enhver forespørsel til en slik lagring på 0,1 - 0,3 sekunder. I dashbordet fikk vi følgende resultater:

Første åpning: 8-10 sekunder
Ethvert klikk: 6-7 sekunder

Tiden brukt av Tableau består av:

1. 0,3 sek. — dashbordparsing og kompilering av SQL-spørringer
2. 1,5-3 sek. — utførelse av SQL-spørringer i Hana for hovedvisualiseringer (kjører parallelt med trinn 1)
3. 1,5-2 sek. — gjengivelse, omberegning av visualiseringer
4. 1,3 sek. - utførelse av ytterligere SQL-spørringer for å oppnå relevante filterverdier (merke, divisjon, by, butikk), analysere resultater

For å oppsummere det kort

Vi likte Tableau-verktøyet fra et visualiseringsperspektiv. På prototypingstadiet vurderte vi ulike visualiseringselementer og fant dem alle i biblioteker, inkludert kompleks flernivåsegmentering og multidriver-fossefall.

Mens vi implementerte dashbord med sentrale salgsindikatorer, møtte vi ytelsesproblemer som vi ennå ikke har klart å overvinne. Vi brukte mer enn to måneder og mottok et funksjonelt ufullstendig dashbord, hvis responshastighet er på grensen til akseptabel. Og vi trakk konklusjoner for oss selv:

1. Tableau kan ikke fungere med store datamengder. Hvis du i den originale datamodellen har mer enn 10 GB med data (omtrent 200 millioner X 50 rader), så bremses dashbordet alvorlig - fra 10 sekunder til flere minutter for hvert klikk. Vi eksperimenterte med både live-connect og extract. Driftshastigheten er sammenlignbar.
2. Begrensning ved bruk av flere lagringer (datasett). Det er ingen måte å indikere forholdet mellom datasett ved bruk av standardmidler. Hvis du bruker løsninger for å koble til datasett, vil dette ha stor innvirkning på ytelsen. I vårt tilfelle vurderte vi muligheten for å materialisere data i hver påkrevd visningsseksjon og gjøre bytter på disse materialiserte datasettene mens vi beholder de tidligere valgte filtrene - dette viste seg å være umulig å gjøre i Tableau.
3. Det er ikke mulig å lage dynamiske parametere i Tableau. Du kan ikke fylle en parameter som brukes til å filtrere et datasett i et uttrekk eller under en live-connecte med resultatet av et annet valg fra datasettet eller resultatet av en annen SQL-spørring, bare innfødt brukerinndata eller en konstant.
4. Begrensninger knyttet til å bygge et dashbord med OLAP|PivotTable-elementer.
   I MSTR, SAP SAC, SAP Analysis, hvis du legger til et datasett i en rapport, er alle objekter på den relatert til hverandre som standard. Tableau har ikke dette, tilkoblingen må konfigureres manuelt. Dette er nok mer fleksibelt, men for alle dashbordene våre er dette et obligatorisk krav til elementer - så dette er ekstra arbeidskostnader. Dessuten, hvis du lager relaterte filtre slik at, for eksempel, når du filtrerer en region, listen over byer er begrenset bare til byene i denne regionen, ender du umiddelbart opp med påfølgende forespørsler til databasen eller uttrekk, noe som merkbart bremser dashbord.
5. Begrensninger i funksjoner. Massetransformasjoner kan ikke gjøres verken på utdraget eller, SPESIELT, på datasettet fra Live-connecta. Dette kan gjøres gjennom Tableau Prep, men det er tilleggsarbeid og et annet verktøy å lære og vedlikeholde. Du kan for eksempel ikke transponere data eller slå dem sammen med seg selv. Hva lukkes gjennom transformasjoner på individuelle kolonner eller felt, som må velges gjennom case eller if, og dette genererer svært komplekse SQL-spørringer, der databasen bruker mesteparten av tiden sin på å kompilere spørringsteksten. Denne ufleksibiliteten til verktøyet måtte løses på utstillingsnivå, noe som fører til mer kompleks lagring, ytterligere nedlastinger og transformasjoner.

Vi har ikke gitt opp Tableau. Men vi anser ikke Tableau som et verktøy som er i stand til å bygge industrielle dashbord og et verktøy for å erstatte og digitalisere hele bedriftens rapporteringssystem.

Vi utvikler nå aktivt et lignende dashbord i et annet verktøy og prøver samtidig å revidere dashbordarkitekturen i Tableau for å forenkle den enda mer. Hvis samfunnet er interessert, vil vi fortelle deg om resultatene.

Vi venter også på dine ideer eller råd om hvordan du i Tabeau kan bygge raske dashboards over så store datamengder, fordi vi har en nettside hvor det er mye mer data enn i detaljhandelen.

Kilde: www.habr.com