Tablå i detaljhandeln, verkligen?

Tiden för rapportering i Excel försvinner snabbt – trenden mot smidiga verktyg för att presentera och analysera information syns inom alla områden. Vi har internt diskuterat digitaliseringen av rapportering under lång tid och valde systemet Tableau visualisering och självbetjäningsanalys. Alexander Bezugly, chef för avdelningen för analytiska lösningar och rapportering i M.Video-Eldorado Group, talade om erfarenheten och resultaten av att bygga en stridsinstrumentpanel.

Jag ska genast säga att inte allt som var planerat förverkligades, men upplevelsen var intressant, jag hoppas att den kommer att vara användbar för dig också. Och om någon har några idéer om hur det skulle kunna göras bättre skulle jag vara mycket tacksam för era råd och idéer.

Nedan klippet handlar om vad vi stötte på och vad vi lärde oss om.

Var började vi?

M.Video-Eldorado har en välutvecklad datamodell: strukturerad information med erforderligt lagringsdjup och ett stort antal fasta rapporter (se mer information här är den här artikeln). Av dessa gör analytiker antingen pivottabeller eller formaterade nyhetsbrev i Excel, eller vackra PowerPoint-presentationer för slutanvändare.

För ungefär två år sedan började vi skapa analytiska rapporter i SAP Analysis (ett Excel-tillägg, i huvudsak en pivottabell över OLAP-motorn) istället för rapporter i fast form. Men det här verktyget kunde inte tillgodose behoven hos alla användare, majoriteten fortsatte att använda information som ytterligare bearbetades av analytiker.

Våra slutanvändare delas in i tre kategorier:

Högsta ledningen. Begär information på ett väl presenterat och klart begripligt sätt.

Mellanchef, avancerade användare. Intresserad av datautforskning och kan självständigt bygga rapporter om verktyg finns tillgängliga. De blev nyckelanvändarna av analytiska rapporter i SAP Analysis.

Massanvändare. De är inte intresserade av att självständigt analysera data, de använder rapporter med en begränsad grad av frihet, i formatet nyhetsbrev och pivottabeller i Excel.

Vår idé var att täcka behoven hos alla användare och ge dem ett enda, bekvämt verktyg. Vi bestämde oss för att börja med högsta ledningen. De behövde lättanvända instrumentpaneler för att analysera viktiga affärsresultat. Så vi började med Tableau och valde först två riktningar: detaljhandels- och onlineförsäljningsindikatorer med begränsad djup och bredd av analys, som skulle täcka cirka 80 % av den information som efterfrågas av högsta ledningen.

Eftersom användarna av instrumentpanelerna var högsta ledningen dök ytterligare en KPI för produkten upp - svarshastighet. Ingen kommer att vänta 20-30 sekunder på att uppgifterna ska uppdateras. Navigeringen borde ha gjorts inom 4-5 sekunder, eller ännu bättre, omedelbart. Och vi, tyvärr, misslyckades med att uppnå detta.

Så här såg layouten på vår huvudinstrumentpanel ut:

Nyckelidén är att kombinera de viktigaste KPI-drivkrafterna, av vilka det fanns 19 totalt, till vänster och presentera deras dynamik och uppdelning efter huvudattribut till höger. Uppgiften verkar enkel, visualiseringen är logisk och begriplig, tills du dyker in i detaljerna.

Detalj 1. Datavolym

Vår huvudtabell för årlig försäljning tar upp cirka 300 miljoner rader. Eftersom det är nödvändigt att spegla dynamiken för förra året och året innan, är datavolymen enbart om faktisk försäljning cirka 1 miljard rader. Information om planerade data och onlineförsäljningsblocket lagras också separat. Därför, även om vi använde den kolumnära in-memory DB SAP HANA, var hastigheten på frågan med valet av alla indikatorer under en vecka från den aktuella lagringen i farten cirka 15-20 sekunder. Lösningen på detta problem föreslår sig själv - ytterligare materialisering av data. Men den har också fallgropar, mer om dem nedan.

Detalj 2. Icke-additiva indikatorer

Många av våra nyckeltal är bundna till antalet kvitton. Och den här indikatorn representerar COUNT DISTINCT av antalet rader (kontrollera rubriker) och visar olika mängder beroende på de valda attributen. Till exempel, hur denna indikator och dess derivata ska beräknas:

För att göra dina beräkningar korrekta kan du:

• Beräkna sådana indikatorer i farten i förrådet;
• Utför beräkningar på hela datamängden i Tableau, d.v.s. på begäran i Tableau, tillhandahålla all data enligt valda filter i granulariteten för kvittopositionen;
• Skapa ett materialiserat skyltfönster där alla indikatorer kommer att beräknas i alla exempelalternativ som ger olika icke-additiva resultat.

Det är tydligt att i exemplet är UTE1 och UTE2 materialattribut som representerar produkthierarkin. Detta är inte en statisk sak, ledning inom företaget sker genom det, eftersom Olika chefer ansvarar för olika produktgrupper. Vi hade många globala revisioner av denna hierarki, när alla nivåer ändrades, när relationer reviderades och konstanta punktförändringar, när en grupp flyttade från en nod till en annan. I konventionell rapportering beräknas allt detta direkt från materialets attribut; i fallet med materialisering av dessa data är det nödvändigt att utveckla en mekanism för att spåra sådana förändringar och automatiskt ladda om historiska data. En mycket icke-trivial uppgift.

Detalj 3. Datajämförelse

Denna punkt liknar den föregående. Summan av kardemumman är att när man analyserar ett företag är det vanligt att göra flera jämförelsenivåer med föregående period:

Jämförelse med föregående period (dag till dag, vecka till vecka, månad till månad)

I denna jämförelse antas det att beroende på den period som användaren valt (till exempel den 33:e veckan på året) ska vi visa dynamiken senast den 32:a veckan; om vi valt data för en månad, till exempel maj , då skulle denna jämförelse visa dynamiken i april.

Jämförelse med förra året

Huvudnyansen här är att när man jämför dag och vecka tar man inte samma dag förra året, dvs. du kan inte bara sätta innevarande år minus ett. Du måste titta på den veckodag du jämför. När du jämför månader måste du tvärtom ta exakt samma kalenderdag förra året. Det finns också nyanser med skottår. I de ursprungliga arkiven distribueras all information per dag, det finns inga separata fält med veckor, månader eller år. Därför, för att få ett komplett analytiskt tvärsnitt i panelen, behöver du inte räkna en period, till exempel en vecka, utan 4 veckor, och sedan jämföra dessa data, återspegla dynamiken, avvikelserna. Följaktligen kan denna logik för att generera jämförelser i dynamik också implementeras antingen i Tableau eller på skyltfönstret. Ja, och naturligtvis visste vi och tänkte på dessa detaljer vid designstadiet, men det var svårt att förutsäga deras inverkan på prestandan för den slutliga instrumentbrädan.

När vi implementerade instrumentpanelen följde vi den långa Agile-vägen. Vår uppgift var att tillhandahålla ett arbetsverktyg med nödvändiga data för testning så snabbt som möjligt. Därför gick vi i spurter och utgick från att minimera arbetet på sidan av nuvarande förråd.

Del 1: Tro på tablå

För att förenkla IT-stödet och snabbt implementera förändringar beslutade vi att göra logiken för att beräkna icke-additiva indikatorer och jämföra tidigare perioder i Tableau.

Steg 1. Allt är live, inga fönsterändringar.

I det här skedet kopplade vi Tableau till de nuvarande skyltfönsterna och bestämde oss för att se hur antalet kvitton för ett år skulle beräknas.

Resultat:

Svaret var deprimerande - 20 minuter. Överföring av data över nätverket, hög belastning på Tableau. Vi insåg att logik med icke-additiva indikatorer måste implementeras på HANA. Detta skrämde oss inte särskilt mycket, vi hade redan liknande erfarenheter av BO och Analysis och vi visste hur man bygger snabba utställningar i HANA som producerar korrekt beräknade icke-additiva indikatorer. Nu återstod bara att anpassa dem till Tableau.

Steg 2. Vi ställer in montrarna, ingen materialisering, allt i farten.

Vi skapade en separat ny skyltfönster som producerade de nödvändiga uppgifterna för TABLEAU i farten. Generellt sett fick vi ett bra resultat, vi minskade tiden för att generera alla indikatorer på en vecka till 9-10 sekunder. Och vi förväntade oss ärligt talat att i Tableau skulle svarstiden för instrumentbrädan vara 20-30 sekunder vid första öppningen och sedan på grund av cachen från 10 till 12, vilket i allmänhet skulle passa oss.

Resultat:

Första öppna instrumentpanelen: 4-5 minuter
Alla klick: 3-4 minuter
Ingen förväntade sig en sådan ytterligare ökning av skyltfönstrets arbete.

Del 2. Dyk ner i tablå

Steg 1. Tabellprestandaanalys och snabbjustering

Vi började analysera var Tableau tillbringar större delen av sin tid. Och det finns ganska bra verktyg för detta, vilket naturligtvis är ett plus med Tableau. Huvudproblemet vi identifierade var de mycket komplexa SQL-frågorna som Tableau byggde. De var främst förknippade med:

— Dataöverföring. Eftersom Tableau inte har verktyg för att överföra datauppsättningar, för att bygga den vänstra sidan av instrumentpanelen med en detaljerad representation av alla KPI:er, var vi tvungna att skapa en tabell med hjälp av ett fall. Storleken på SQL-frågor i databasen nådde 120 000 tecken.

- val av tidsperiod. En sådan fråga på databasnivå tog längre tid att kompilera än att köra:

De där. begäran bearbetning 12 sekunder + 5 sekunder exekvering.

Vi bestämde oss för att förenkla beräkningslogiken på tablåsidan och flytta ytterligare en del av beräkningarna till skyltfönster och databasnivå. Detta gav goda resultat.

Först gjorde vi transponeringen i farten, vi gjorde det genom en fullständig yttre sammanfogning i slutskedet av VIEW-beräkningen, enligt detta tillvägagångssätt som beskrivs på wikin Transponera - Wikipedia, den fria encyklopedin и Elementär matris - Wikipedia, den fria encyklopedin.

Det vill säga, vi gjorde en inställningstabell - en transponeringsmatris (21x21) och fick alla indikatorer i en rad-för-rad-uppdelning.

Var:


Det blev:


Nästan ingen tid ägnas åt själva databastransponeringen. Begäran om alla indikatorer för veckan fortsatte att behandlas på cirka 10 sekunder. Men å andra sidan har flexibiliteten gått förlorad när det gäller att konstruera en instrumentpanel utifrån en specifik indikator, d.v.s. för den högra sidan av instrumentbrädan där dynamiken och detaljerad uppdelning av en specifik indikator presenteras, tidigare fungerade displayen på 1-3 sekunder, eftersom begäran baserades på en indikator, och nu valde databasen alltid alla indikatorer och filtrerade resultatet innan resultatet returnerades till Tableau.

Som ett resultat minskade hastigheten på instrumentbrädan med nästan 3 gånger.

Resultat:

1. 5 sek – analysera instrumentpaneler, visualiseringar
2. 15-20 sekunder - förberedelse för att sammanställa frågor med att utföra förberäkningar i Tableau
3. 35-45 sek - kompilering av SQL-frågor och deras parallellsekventiell exekvering i Hana
4. 5 sek – bearbetning av resultat, sortering, omräkning av visualiseringar i Tableau
5. Sådana resultat passade förstås inte verksamheten och vi fortsatte att optimera.

Steg 2. Minsta logik i Tableau, fullständig materialisering

Vi förstod att det var omöjligt att bygga en instrumentpanel med en svarstid på flera sekunder på ett skyltfönster som körs i 10 sekunder, och vi övervägde alternativ för att materialisera data på databassidan specifikt för den nödvändiga instrumentpanelen. Men vi stötte på ett globalt problem som beskrivs ovan - icke-additiva indikatorer. Vi kunde inte försäkra oss om att Tableau växlade flexibelt mellan olika skyltfönster och nivåer förutformade för olika produkthierarkier (i exemplet genererar tre frågor utan UTE, med UTE1 och UTE2 olika resultat). Därför bestämde vi oss för att förenkla instrumentpanelen, överge produkthierarkin i instrumentpanelen och se hur snabbt det kunde vara i en förenklad version.

Så i detta sista skede satte vi ihop ett separat arkiv där vi lade till alla nyckeltal i transponerad form. På databassidan behandlas varje begäran till en sådan lagring på 0,1 - 0,3 sekunder. I instrumentpanelen fick vi följande resultat:

Första öppning: 8-10 sekunder
Alla klick: 6-7 sekunder

Den tid som Tableau spenderar består av:

1. 0,3 sek. — analys av instrumentpanelen och kompilering av SQL-frågor
2. 1,5-3 sek. — exekvering av SQL-frågor i Hana för huvudvisualiseringar (körs parallellt med steg 1)
3. 1,5-2 sek. — rendering, omräkning av visualiseringar
4. 1,3 sek. — exekvering av ytterligare SQL-frågor för att erhålla relevanta filtervärden (varumärke, division, stad, butik), analysera resultat

För att sammanfatta det kort

Vi gillade Tableau-verktyget ur ett visualiseringsperspektiv. I prototypstadiet övervägde vi olika visualiseringselement och hittade dem alla i bibliotek, inklusive komplex segmentering på flera nivåer och vattenfall med flera drivrutiner.

När vi implementerade instrumentpaneler med viktiga försäljningsindikatorer stötte vi på prestandaproblem som vi ännu inte har kunnat övervinna. Vi tillbringade mer än två månader och fick en funktionellt ofullständig instrumentpanel, vars svarshastighet är på gränsen till acceptabel. Och vi drog slutsatser för oss själva:

1. Tableau kan inte fungera med stora mängder data. Om du i den ursprungliga datamodellen har mer än 10 GB data (ungefär 200 miljoner X 50 rader), så saktas instrumentpanelen rejält ner - från 10 sekunder till flera minuter för varje klick. Vi experimenterade med både live-connect och extrahera. Drifthastigheten är jämförbar.
2. Begränsning vid användning av flera lagringar (dataset). Det finns inget sätt att ange förhållandet mellan datamängder med hjälp av standardmetoder. Om du använder lösningar för att ansluta datauppsättningar kommer detta att påverka prestandan i hög grad. I vårt fall övervägde vi alternativet att materialisera data i varje erforderlig vysektion och göra växlar på dessa materialiserade datamängder samtidigt som vi bevarade de tidigare valda filtren - detta visade sig vara omöjligt att göra i Tableau.
3. Det är inte möjligt att göra dynamiska parametrar i Tableau. Du kan inte fylla en parameter som används för att filtrera en datamängd i ett extrakt eller under en live-connecte med resultatet av ett annat urval från datamängden eller resultatet av en annan SQL-fråga, bara inbyggd användarinmatning eller en konstant.
4. Begränsningar förknippade med att bygga en instrumentpanel med OLAP|PivotTable-element.
   I MSTR, SAP SAC, SAP Analysis, om du lägger till en datauppsättning till en rapport, är alla objekt på den relaterade till varandra som standard. Tableau har inte detta, anslutningen måste konfigureras manuellt. Detta är förmodligen mer flexibelt, men för alla våra instrumentpaneler är detta ett obligatoriskt krav för element - så detta är extra arbetskostnader. Dessutom, om du gör relaterade filter så att, till exempel, när du filtrerar en region, listan över städer endast är begränsad till städerna i denna region, slutar du omedelbart med på varandra följande frågor till databasen eller extrahera, vilket märkbart saktar ner instrumentbräda.
5. Begränsningar i funktioner. Masstransformationer kan inte göras vare sig på extraktet eller, SÄRSKILT, på datasetet från Live-connecta. Detta kan göras genom Tableau Prep, men det är ytterligare arbete och ett annat verktyg att lära sig och underhålla. Du kan till exempel inte överföra data eller sammanfoga den med sig själv. Vad stängs genom transformationer på enskilda kolumner eller fält, som måste väljas genom case eller if, och detta genererar mycket komplexa SQL-frågor, där databasen ägnar större delen av sin tid åt att kompilera frågetexten. Denna oflexibilitet i verktyget måste lösas på utställningsnivå, vilket leder till mer komplex lagring, ytterligare nedladdningar och transformationer.

Vi har inte gett upp Tableau. Men vi betraktar inte Tableau som ett verktyg som kan bygga industriella instrumentpaneler och ett verktyg för att ersätta och digitalisera ett företags hela företagsrapporteringssystem.

Vi utvecklar nu aktivt en liknande dashboard i ett annat verktyg och försöker samtidigt revidera dashboard-arkitekturen i Tableau för att förenkla den ännu mer. Om communityn är intresserad kommer vi att berätta om resultatet.

Vi väntar också på dina idéer eller råd om hur du i Tabeau kan bygga snabba dashboards över så stora datamängder, eftersom vi har en webbplats där det finns mycket mer data än i detaljhandeln.

Källa: will.com