Tableau i detailhandlen, virkelig?

Tiden for rapportering i Excel er hastigt ved at forsvinde - tendensen til praktiske værktøjer til at præsentere og analysere information er synlig på alle områder. Vi har internt diskuteret digitalisering af rapportering i lang tid og valgte Tableau visualisering og selvbetjeningsanalysesystem. Alexander Bezugly, leder af afdelingen for analytiske løsninger og rapportering i M.Video-Eldorado Group, talte om oplevelsen og resultaterne af at bygge et kampdashboard.

Jeg vil med det samme sige, at ikke alt, hvad der var planlagt, blev realiseret, men oplevelsen var interessant, jeg håber, at den også vil være nyttig for dig. Og hvis nogen har nogle ideer til, hvordan det kan gøres bedre, vil jeg være meget taknemmelig for jeres råd og ideer.

Nedenfor klippet handler om, hvad vi stødte på, og hvad vi lærte om.

Hvor startede vi?

M.Video-Eldorado har en veludviklet datamodel: struktureret information med den nødvendige lagringsdybde og et stort antal rapporter i fast form (se flere detaljer denne artikel). Ud fra disse laver analytikere enten pivottabeller eller formaterede nyhedsbreve i Excel eller smukke PowerPoint-præsentationer til slutbrugere.

For omkring to år siden begyndte vi i stedet for faste rapporter at oprette analytiske rapporter i SAP Analyse (en Excel-tilføjelse, i det væsentlige en pivottabel over OLAP-motoren). Men dette værktøj var ikke i stand til at imødekomme alle brugeres behov; flertallet fortsatte med at bruge informationer, der blev behandlet af analytikere.

Vores slutbrugere falder i tre kategorier:

Topledelsen. Anmoder om information på en velpræsenteret og klart forståelig måde.

Mellemledelse, avancerede brugere. Interesseret i dataudforskning og i stand til selvstændigt at opbygge rapporter, hvis værktøjer er tilgængelige. De blev nøglebrugerne af analytiske rapporter i SAP Analyse.

Massebrugere. De er ikke interesserede i selvstændigt at analysere data, de bruger rapporter med en begrænset grad af frihed, i formatet af nyhedsbreve 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 at analysere vigtige forretningsresultater. Så vi startede med Tableau og valgte først to retninger: detail- og onlinesalgsindikatorer med begrænset dybde og bredde af analyser, som ville dække cirka 80 % af de data, som topledelsen anmodede om.

Da brugerne af dashboards var topledelsen, dukkede endnu en ekstra KPI for produktet op - responshastighed. Ingen vil vente 20-30 sekunder på, at dataene bliver opdateret. Navigation skulle have været udført inden for 4-5 sekunder, eller endnu bedre, udført med det samme. Og det lykkedes os desværre ikke at opnå dette.

Sådan så layoutet af vores hoveddashboard ud:

Nøgleideen er at kombinere de vigtigste KPI-drivere, som der var 19 af i alt, til venstre og præsentere deres dynamik og opdeling efter hovedattributter til højre. Opgaven virker simpel, visualiseringen er logisk og forståelig, indtil du dykker ned i detaljerne.

Detalje 1. Datavolumen

Vores hovedtabel for årligt salg fylder omkring 300 millioner rækker. Da det er nødvendigt at afspejle dynamikken for sidste år og året før, er mængden af ​​data om det faktiske salg alene omkring 1 milliard linjer. Oplysninger om planlagte data og online salgsblokken gemmes også separat. Derfor, selvom vi brugte den søjleformede in-memory DB SAP HANA, var hastigheden af ​​forespørgslen med udvælgelsen af ​​alle indikatorer i en uge fra den aktuelle lagring i farten omkring 15-20 sekunder. Løsningen på dette problem foreslår sig selv - yderligere materialisering af data. Men den har også faldgruber, mere om dem nedenfor.

Detalje 2. Ikke-additive indikatorer

Mange af vores KPI'er er knyttet til antallet af kvitteringer. Og denne indikator repræsenterer COUNT DISTINCT af antallet af rækker (check overskrifter) og viser forskellige mængder afhængigt af de valgte attributter. For eksempel, hvordan denne indikator og dens afledte skal beregnes:

For at gøre dine beregninger korrekte kan du:

• Beregn sådanne indikatorer på farten i lageret;
• Udfør beregninger på hele datamængden i Tableau, dvs. efter anmodning i Tableau, angiv alle data i henhold til udvalgte filtre i granulariteten af ​​kvitteringspositionen;
• Opret et materialiseret udstillingsvindue, hvor alle indikatorer vil blive beregnet i alle prøvemuligheder, der giver forskellige ikke-additive resultater.

Det er klart, at UTE1 og UTE2 i eksemplet er materialeattributter, der repræsenterer produkthierarkiet. Dette er ikke en statisk ting; ledelsen i virksomheden foregår gennem det, fordi... Forskellige ledere er ansvarlige for forskellige produktgrupper. Vi havde mange globale revisioner af dette hierarki, da alle niveauer ændrede sig, når relationer blev revideret, og konstante punktændringer, når en gruppe flyttede fra en node til en anden. I konventionel rapportering beregnes alt dette med det samme ud fra materialets egenskaber; i tilfælde af materialisering af disse data er det nødvendigt at udvikle en mekanisme til at spore sådanne ændringer og automatisk genindlæse historiske data. En meget ikke-triviel opgave.

Detalje 3. Datasammenligning

Dette punkt ligner det forrige. Den nederste linje er, at når man analyserer en virksomhed, er det sædvanligt at danne flere niveauer af sammenligning med den foregående periode:

Sammenligning med den foregående periode (dag til dag, uge ​​til uge, måned til måned)

I denne sammenligning antages det, at afhængigt af den periode, brugeren har valgt (for eksempel den 33. uge i året), skal vi vise dynamikken inden den 32. uge; hvis vi valgte data for en måned, for eksempel maj , så ville denne sammenligning vise dynamikken inden april.

Sammenligning med sidste år

Hovednuancen her er, at når man sammenligner efter dag og uge, tager man ikke samme dag sidste år, dvs. du kan ikke bare sætte det nuværende år minus et. Du skal se på den ugedag, du sammenligner. Når du sammenligner måneder, skal du tværtimod tage nøjagtig den samme kalenderdag sidste år. Der er også nuancer med skudår. I de originale arkiver er al information fordelt efter dag; der er ingen separate felter med uger, måneder eller år. Derfor, for at opnå et komplet analytisk tværsnit i panelet, skal du ikke tælle en periode, for eksempel en uge, men 4 uger, og derefter sammenligne disse data, afspejle dynamikken, afvigelserne. Derfor kan denne logik til at generere sammenligninger i dynamik også implementeres enten i Tableau eller på butikssiden. Ja, og selvfølgelig vidste og tænkte vi over disse detaljer på designstadiet, men det var svært at forudsige deres indflydelse på ydeevnen af ​​det endelige dashboard.

Da vi implementerede dashboardet, fulgte vi den lange Agile-sti. Vores opgave var at levere et arbejdsværktøj med de nødvendige data til test så hurtigt som muligt. Derfor gik vi i spurter og startede med at minimere arbejdet på siden af ​​det nuværende lager.

Del 1: Tro på Tableau

For at forenkle IT-support og hurtigt implementere ændringer, besluttede vi at lave logikken for beregning af ikke-additive indikatorer og sammenligning af tidligere perioder i Tableau.

Trin 1. Alt er live, ingen vinduesændringer.

På dette tidspunkt koblede vi Tableau til de nuværende butiksfacader og besluttede at se, hvordan antallet af kvitteringer for et år ville blive beregnet.

Resultat:

Svaret var deprimerende - 20 minutter. Overførsel af data over netværket, høj belastning på Tableau. Vi indså, at logik med ikke-additive indikatorer skal implementeres på HANA. Dette skræmte os ikke meget, vi havde allerede lignende erfaringer med BO og Analyse, og vi vidste, hvordan vi byggede hurtige udstillingsvinduer i HANA, der producerer korrekt beregnede ikke-additive indikatorer. Nu var der kun tilbage at tilpasse dem til Tableau.

Etape 2. Vi tuner montrene, ingen materialisering, alt på farten.

Vi oprettede et separat nyt udstillingsvindue, der producerede de nødvendige data til TABLEAU on the fly. Generelt fik vi et godt resultat; vi reducerede tiden til at generere alle indikatorer på en uge til 9-10 sekunder. Og vi forventede ærligt talt, at i Tableau ville responstiden på instrumentbrættet være 20-30 sekunder ved første åbning og så på grund af cachen fra 10 til 12, hvilket generelt ville passe os.

Resultat:

Første åbning af dashboard: 4-5 minutter
Ethvert klik: 3-4 minutter
Ingen forventede en sådan yderligere stigning i butiksfacadens arbejde.

Del 2. Dyk ned i Tableau

Trin 1. Tableau præstationsanalyse og hurtig tuning

Vi begyndte at analysere, hvor Tableau bruger det meste af sin tid. Og det er der ganske gode værktøjer til, hvilket selvfølgelig er et plus ved Tableau. Hovedproblemet, vi identificerede, var de meget komplekse SQL-forespørgsler, som Tableau byggede. De var primært forbundet med:

— datatransponering. Da Tableau ikke har værktøjer til at transponere datasæt, for at bygge venstre side af dashboardet med en detaljeret repræsentation af alle KPI'er, var vi nødt til at oprette en tabel ved hjælp af en case. Størrelsen af ​​SQL-forespørgsler i databasen nåede 120 tegn.

- valg af tidsrum. En sådan forespørgsel på databaseniveau tog længere tid at kompilere end at udføre:

De der. anmodningsbehandling 12 sekunder + 5 sekunders eksekvering.

Vi besluttede at forenkle beregningslogikken på Tableau-siden og flytte en anden del af beregningerne til butiksfacade og databaseniveau. Dette gav gode resultater.

Først foretog vi transponeringen i farten, vi gjorde det gennem en fuld ydre sammenføjning i det sidste trin af VIEW-beregningen ifølge denne fremgangsmåde beskrevet på wikien Transponere - Wikipedia, den frie encyklopædi и Elementær matrix - Wikipedia, den frie encyklopædi.

Det vil sige, vi lavede en indstillingstabel - en transponeringsmatrix (21x21) og modtog alle indikatorerne i en række-for-række-opdeling.

Var:


Blev til:


Der bruges næsten ingen tid på selve databasetransponeringen. Anmodningen om alle indikatorer for ugen fortsatte med at blive behandlet på omkring 10 sekunder. Men på den anden side er fleksibiliteten gået tabt i forhold til at konstruere et dashboard ud fra en bestemt indikator, dvs. for højre side af instrumentbrættet, hvor dynamikken og detaljeret opdeling af en specifik indikator er præsenteret, fungerede tidligere displayet på 1-3 sekunder, fordi anmodningen var baseret på én indikator, og nu valgte databasen altid alle indikatorer og filtrerede resultatet, inden resultatet returneredes til Tableau.

Som et resultat faldt hastigheden på instrumentbrættet med næsten 3 gange.

Resultat:

1. 5 sek – parsing af dashboards, visualiseringer
2. 15-20 sekunder - forberedelse til kompilering af forespørgsler med udførelse af forberegninger i Tableau
3. 35-45 sek - kompilering af SQL-forespørgsler og deres parallel-sekventielle udførelse i Hana
4. 5 sek – behandling af resultater, sortering, genberegning af visualiseringer i Tableau
5. Sådanne resultater passede naturligvis ikke forretningen, og vi fortsatte med optimeringen.

Fase 2. Minimum logik i Tableau, komplet materialisering

Vi forstod, at det var umuligt at bygge et dashboard med en responstid på flere sekunder på en butiksfacade, der kører i 10 sekunder, og vi overvejede muligheder for at materialisere data på databasesiden specifikt til det påkrævede dashboard. Men vi stødte på et globalt problem beskrevet ovenfor - ikke-additive indikatorer. Vi var ikke i stand til at sikre, at når vi skiftede filtre eller drilldowns, skiftede Tableau fleksibelt mellem forskellige butiksfacader og niveauer, der var foruddesignet til forskellige produkthierarkier (i eksemplet genererer tre forespørgsler uden UTE, med UTE1 og UTE2 forskellige resultater). Derfor besluttede vi at forenkle dashboardet, opgive produkthierarkiet 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 tilføjede alle KPI'er i transponeret form. På databasesiden behandles enhver anmodning til et sådant lager på 0,1 - 0,3 sekunder. I dashboardet modtog vi følgende resultater:

Første åbning: 8-10 sekunder
Ethvert klik: 6-7 sekunder

Tiden brugt af Tableau består af:

1. 0,3 sek. — dashboard-parsing og kompilering af SQL-forespørgsler
2. 1,5-3 sek. — udførelse af SQL-forespørgsler i Hana til hovedvisualiseringer (kører parallelt med trin 1)
3. 1,5-2 sek. — gengivelse, genberegning af visualiseringer
4. 1,3 sek. — udførelse af yderligere SQL-forespørgsler for at opnå relevante filterværdier (brand, division, by, butik), parsing af resultater

For at opsummere det kort

Vi kunne godt lide Tableau-værktøjet fra et visualiseringsperspektiv. På prototypestadiet overvejede vi forskellige visualiseringselementer og fandt dem alle i biblioteker, inklusive kompleks multi-level segmentering og multi-driver vandfald.

Mens vi implementerede dashboards med vigtige salgsindikatorer, stødte vi på præstationsvanskeligheder, som vi endnu ikke har været i stand til at overvinde. Vi brugte mere end to måneder og modtog et funktionelt ufuldstændigt dashboard, hvis responshastighed er på grænsen til acceptabel. Og vi dragede konklusioner for os selv:

1. Tableau kan ikke arbejde med store mængder data. Hvis du i den originale datamodel har mere end 10 GB data (ca. 200 millioner X 50 rækker), så vil dashboardet for alvor bremse - fra 10 sekunder til flere minutter for hvert klik. Vi eksperimenterede med både live-connect og extract. Driftshastigheden er sammenlignelig.
2. Begrænsning ved brug af flere lager (datasæt). Der er ingen måde at angive forholdet mellem datasæt ved hjælp af standardmidler. Hvis du bruger løsninger til at forbinde datasæt, vil dette i høj grad påvirke ydeevnen. I vores tilfælde overvejede vi muligheden for at materialisere data i hver påkrævet visningssektion og foretage skift på disse materialiserede datasæt, mens de tidligere valgte filtre bevares - dette viste sig at være umuligt at gøre i Tableau.
3. Det er ikke muligt at lave dynamiske parametre i Tableau. Du kan ikke udfylde en parameter, der bruges til at filtrere et datasæt i et udtræk eller under en live-connecte med resultatet af et andet valg fra datasættet eller resultatet af en anden SQL-forespørgsel, kun indbygget brugerinput eller en konstant.
4. Begrænsninger forbundet med at bygge et dashboard med OLAP|PivotTable-elementer.
   I MSTR, SAP SAC, SAP Analysis, hvis du føjer et datasæt til en rapport, er alle objekter på den som standard relateret til hinanden. Tableau har ikke dette; forbindelsen skal konfigureres manuelt. Dette er nok mere fleksibelt, men for alle vores dashboards er dette et obligatorisk krav til elementer - så dette er ekstra arbejdsomkostninger. Desuden, hvis du laver relaterede filtre, så listen over byer f.eks. ved filtrering af en region kun er begrænset til byerne i denne region, ender du med det samme med successive forespørgsler til databasen eller udtræk, hvilket mærkbart bremser dashboard.
5. Begrænsninger i funktioner. Massetransformationer kan ikke udføres hverken på uddraget eller, ISÆR, på datasættet fra Live-connecta. Dette kan gøres gennem Tableau Prep, men det er ekstra arbejde og et andet værktøj til at lære og vedligeholde. For eksempel kan du ikke transponere data eller forbinde dem med sig selv. Hvad lukkes gennem transformationer på enkelte kolonner eller felter, som skal vælges gennem case eller if, og det genererer meget komplekse SQL-forespørgsler, hvor databasen bruger det meste af sin tid på at kompilere forespørgselsteksten. Denne manglende fleksibilitet af værktøjet skulle løses på udstillingsniveau, hvilket fører til mere kompleks lagring, yderligere downloads og transformationer.

Vi har ikke opgivet Tableau. Men vi betragter ikke Tableau som et værktøj, der er i stand til at bygge industrielle dashboards og et værktøj til at erstatte og digitalisere hele en virksomheds virksomhedsrapporteringssystem.

Vi udvikler nu aktivt et lignende dashboard i et andet værktøj og forsøger samtidig at revidere dashboard-arkitekturen i Tableau for at forenkle det endnu mere. Hvis samfundet er interesseret, vil vi fortælle dig om resultaterne.

Vi venter også på dine ideer eller råd til, hvordan du i Tabeau kan bygge hurtige dashboards over så store datamængder, for vi har en hjemmeside, hvor der er meget mere data end i detailhandlen.

Kilde: www.habr.com