Tableau inom detaljhandeln, är det verkligt?

Rapporteringstiden i Excel försvinner snabbt — trenden med användarvänliga verktyg för presentation och analys av information syns inom alla områden. Vi har länge diskuterat digitalisering av rapporteringsprocessen och valt visualiserings- och självbetjäningsanalysystemet Tableau. Alexander Bezugly, chef för avdelningen för analytiska lösningar och rapportering hos gruppen "M.Video-El Dorado", berättade om erfarenheterna och resultaten från att skapa en realtidsdashboard.

Jag kan direkt säga att inte allt som planerades lyckades, men erfarenheten var intressant, och jag hoppas att den kommer att vara till nytta för er också. Och om någon har idéer om hur det kunde göras bättre – skulle jag vara mycket tacksam för råd och idéer.

Under går vi igenom vad vi stötte på och vad vi lärde oss.

Hur vi började

Hos "M.Video-El Dorado" finns en väl genomarbetad datamodell: strukturerad information med nödvändig lagringsdjup och ett stort antal fasta rapporter (se mer detaljerat denna artikel). Av dessa gör analytiker antingen pivottabeller eller formaterade e-postutskick i Excel, eller vackra presentationer i PowerPoint för slutanvändarna.

För ungefär två år sedan började vi istället för fasta rapporter att skapa analytiska rapporter i SAP Analysis (ett tillägg till Excel, i själva verket — en pivottabell ovanför en OLAP-motor). Men det här verktyget kunde inte tillfredsställa behoven hos alla användare, de flesta fortsatte att använda information som var ytterligare bearbetad av analytiker.

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

Högsta ledningen. Begär information i ett väl presenterat och lättförståeligt format.

Mellanledningen, avancerade användare. Intresserade av datanalys och kapabla att själva skapa rapporter med tillgång till verktyg. Det är de som blev de nyckelanvändare av analytiska rapporter i SAP Analysis.

Massa användare. Inte intresserade av att analysera data själva, de använder rapporter med begränsad frihet, i form av e-postutskick och pivottabeller i Excel.

Vår idé var att tillfredsställa behoven hos alla användare och ge dem ett enhetligt och bekvämt verktyg. Vi började med ledningen, som behövde praktiska paneler för att analysera grundläggande affärsresultat. Vi startade med Tableau och valde först två områden: försäljningsindikatorer för detaljhandel och online med begränsad djup och bredd på analysen, som skulle täcka ungefär 80 % av de uppgifter som ledningen efterfrågade.

Eftersom användarna av instrumentpanelen var ledningen, kom ytterligare en KPI för produkten – svarstiden. Ingen kommer att vänta 20-30 sekunder på att data ska uppdateras. Navigeringen skulle ta 4-5 sekunder, helst omedelbart.Och detta lyckades vi tyvärr inte uppnå.

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

Huvudkonceptet var att samla de viktigaste KPI-drivarna, som totalt blev 19, till vänster och visa deras dynamik och uppdelning efter huvudattribut till höger. Uppgiften verkar inte svår, visualiseringen logisk och förståelig, tills man dyker ner i detaljerna.

Detalj 1. Datavolym

Huvudtabellen över försäljning under året innehåller cirka 300 miljoner rader. Eftersom det är nödvändigt att visa både dynamiken från föregående och det föregående året, är datavolymen bara för faktiska försäljningar cirka 1 miljard rader. Dessutom lagras information om planerade data och blocket för internetförsäljning separat. Därför, trots att vi använde den kolumnbaserade in-memory databasen SAP HANA, tog en fråga om att hämta alla indikatorer under en vecka från aktuella datalager i realtid cirka 15-20 sekunder. Lösningen på denna uppgift föreslår sig själv – ytterligare materialisering av data. Men det finns även fallgropar i detta, som beskrivs nedan.

Detalj 2. Icke-additiva indikatorer

Många av våra KPI:er är kopplade till antalet kvitton. Denna indikator är en COUNT DISTINCT av antalet rader (huvudrader av kvitton) och visar olika belopp beroende på valda attribut. Som exempel, hur denna indikator och dess derivat bör beräknas:

För att säkerställa noggranna beräkningar kan man:

• Genomföra beräkningen av dessa indikatorer i realtid i datalager;
• Utföra beräkningen på hela datavolymen i Tableau, det vill säga att ge alla data med valda filter i granualiteten av kvitton.
• Skapa en materialiserad vy där alla mätvärden beräknas för alla urvalsvarianter, vilket ger olika icke-additiva resultat.

Det är tydligt att i exemplet representerar UTE1 och UTE2 materialegenskaper som utgör en produktstruktur. Detta är inget statiskt, utan en del av företagets styrning eftersom olika chefer ansvarar för olika produktgrupper. Vi har genomfört många globala översyner av denna hierarki, där alla nivåer har ändrats, där relationer har setts över, liksom kontinuerliga punktinsatser när en grupp flyttas från en nod till en annan. I vanlig rapportering beräknas allt detta i realtid utifrån materialattribut, men i fallet med materialisering av dessa data måste en mekanism utarbetas för att spåra sådana förändringar och automatiskt ladda om historiska data. Detta är en ganska komplicerad uppgift.

Del 3. Jämförelse av data

Detta punkt liknar den föregående. Kärnan är att företaget vid analys föredrar att skapa flera nivåer av jämförelse med föregående period:

Jämförelse med tidigare period (dag för dag, vecka för vecka, månad för månad)

I denna jämförelse antas att beroende på den period som användaren väljer (till exempel vecka 33 av året) måste vi visa dynamiken i jämförelse med vecka 32, och om vi valde data för en månad, till exempel maj, skulle denna jämförelse visa dynamiken i förhållande till april.

Jämförelse med föregående år

Det huvudsakliga temat här är att när man jämför efter dagar och veckor ska man inte ta samma dag förra året, det vill säga man kan inte bara ta nuvarande år minus ett. Man måste istället titta på den jämförda veckodagen. När man däremot jämför månader, måste man ta exakt samma datum från förra året. Det finns också särskilda aspekter kring skottår. I de ursprungliga lagren är all information distribuerad efter dagar, det finns inga separata fält för veckor, månader eller år. Därför, för att få en fullständig analytisk översikt i panelen, måste man räkna inte bara en period, till exempel en vecka, utan 4 veckor, och sedan jämföra dessa data för att reflektera dynamik och avvikelser. Därmed kan denna logik för att skapa jämförelse i dynamik också realiseras antingen i Tableau eller på vitrinsidan. Ja, och vi var medvetna om dessa detaljer och diskuterade dem redan i designfasen, men att förutspå deras påverkan på den slutliga instrumentpanelen var svårt.

Vid implementeringen av instrumentpanelen tog vi en lång Agile-väg. Vårt mål var att så snabbt som möjligt tillhandahålla ett fungerande verktyg för testning med nödvändiga data. Därför arbetade vi i sprinter och fokuserade på att minimera arbetet på den nuvarande lagersidan.

Del 1. Tro på Tableau

För att förenkla IT-stödet och möjliggöra snabba förändringar beslutade vi att göra logiken för beräkning av icke-additiva indikatorer och jämförelse av tidigare perioder i Tableau.

Steg 1. Allt i Live, inga utvecklingar av vitrin.

I detta steg kopplade vi Tableau till de aktuella vitrinerna och beslutade att se hur antalet kvitton skulle beräknas över ett år.

Resultatet:

Svaret var nedslående – 20 minuter. Datatransfer över nätverket, hög belastning på Tableau. Vi insåg att logiken för icke-additiva indikatorer behövde implementeras i HANA. Detta skrämde oss inte så mycket, vi hade redan liknande erfarenheter med BO och Analysis och kunde bygga snabba vitriner i HANA som ger korrekt beräknade icke-additiva indikatorer. Nu återstod bara att anpassa dem till Tableau.

Steg 2. Vi finjusterar vitrinerna, ingen materialisering, allt på språng.

Vi har skapat en ny, separat vitrin som på språng levererade de nödvändiga data för TABLEAU. Sammantaget fick vi ett bra resultat; vi minskade tiden för att generera alla indikatorer från en vecka till 9-10 sekunder. Vi förväntade oss ärligt att svarstiden för instrumentpanelen i Tableau skulle vara 20-30 sekunder vid första öppningen och därefter, tack vare cachen, mellan 10 och 12, vilket skulle vara acceptabelt för oss.

Resultatet:

Första öppna instrumentpanelen: 4-5 minuter
Varje klick: 3-4 minuter
Ingen förväntade sig något sådant ytterligare tillskott till vitrinens arbete.

Del 2. Fördjupning i Tableau

Steg 1. Analys av Tableau-prestanda och snabb justering

Vi började analysera vad Tableau spenderade mest tid på. Det finns faktiskt mycket bra verktyg för detta, vilket är en fördel med Tableau. Det största problemet vi identifierade var mycket komplexa SQL-frågor som Tableau skapade. Dessa var främst kopplade till:

— transponering av data. Eftersom Tableau inte har verktyg för att transponera dataset, var vi tvungna att skapa en tabell genom case för att bygga den vänstra delen av instrumentpanelen med detaljerad information om alla KPI. Storleken på SQL-frågorna i databasen nådde 120 000 tecken.

— val av tidsperiod. En sådan fråga på databasenivå tog längre tid att kompilera än att genomföra:

Det vill säga, bearbetning av frågan 12 sekunder + 5 sekunder utförande.

Vi beslutade att förenkla beräkningslogiken på Tableau-sidan och flytta en annan del av beräkningarna till vitrin och databasenivå. Detta gav bra resultat.

Först gjorde vi transponeringen i realtid, genomförde den via full outer join i det sista steget av beräkningen av VIEW, enligt ett sådant tillvägagångssätt som beskrivs på wiki. Transpose — Wikipedia, den fria encyklopedin och Elementary matrix — Wikipedia, den fria encyklopedin.

Vi skapade alltså en inställningstabell – en transponeringsmatris (21x21) och fick alla indikatorer i radbrytning.

Förut:


Nu:


Själva transponeringen av databasen tar nästan ingen tid. Frågan för alla indikatorer under veckan svarade fortfarande på ungefär 10 sekunder. Men flexibiliteten i att bygga en dashboard för en specifik indikator förlorades, dvs. för den högra delen av dashboards där dynamik och detaljerad uppdelning av en specifik indikator presenterades, svarade skylten tidigare på 1-3 sekunder, eftersom frågan gick på en indikator, men nu valde databasen alltid alla indikatorer och filtrerade resultatet innan det returnerades till Tableau.

Som ett resultat minskade hastigheten på dashboarden nästan tre gånger.

Resultatet:

1. 5 sek - parsing av dashboard, visualiseringar
2. 15-20 sek - förberedelse för kompilering av frågor med förreduceringar i Tableau
3. 35-45 sek - kompilering av SQL-frågor och parallell-sekventiell utförande i Hana
4. 5 sek - bearbetning av resultat, sortering, omberäkning av visualiseringar i Tableau
5. Självklart var sådana resultat oacceptabla för verksamheten, och vi fortsatte med optimeringen.

Steg 2. Minst logik i Tableau, full materialisering

Vi förstod att det var omöjligt att bygga en dashboard med en svarstid på några sekunder på en skylta som arbetar på 10 sekunder och undersökte möjligheter för materialisering av data på databasens sida specifikt för den nödvändiga dashboarden. Men vi stötte på ett globalt problem som beskrivits ovan – icke-additativa indikatorer. Vi kunde inte få Tableau att flexibelt växla mellan olika skylta och nivåer, förberäknade för olika produkt hierarkier (i exemplet ger tre frågor utan UTE, med UTE1 och UTE2 olika resultat). Därför beslutade vi att förenkla dashboarden, avstå från produkt hierarkin i dashboarden och se hur snabbt den kunde bli i en förenklad version.

Så, i detta sista steg samlade vi ett separat lager där vi lagrade alla KPI i transponerad form. På databassidan bearbetas varje fråga till ett sådant lager på 0,1 - 0,3 sekunder. I dashboarden fick vi följande resultat:

Första öppningen: 8-10 sekunder
Varje klick: 6-7 sekunder

Tiden som Tableau spenderar består av:

1. 0,3 sek - parsing av dashboard och kompilering av SQL-frågor
2. 1,5-3 sek - utförande av SQL-frågor i Hana för de viktigaste visualiseringarna (startar parallellt med punkt 1)
3. 1,5-2 sek. — rendering, omberäkning av visualiseringar
4. 1,3 sek. — utförande av ytterligare SQL-frågor för att få relevanta värden för filter (Märke, Division, Stad, Affär), parse av resultat

Om vi sammanfattar kort

Vi gillade verktyget Tableau sett ur ett visualiseringsperspektiv. Under designfasen övervägde vi olika visualiseringselement och vi fann alla i biblioteken, inklusive komplexa flerskiktade segmenteringar och flerdelade waterfall.

När vi implementerade dashboards med viktiga försäljningsindikatorer stötte vi på prestandasvårigheter som vi ännu inte har kunnat övervinna. Vi spenderade mer än två månader och fick en funktionellt ofullständig dashboard vars svarstid ligger på gränsen av det acceptabla. Vi drog slutsatser:

1. Tableau klarar inte av stora datamängder. Om din ursprungliga datamodell har mer än 10 GB data (ungefär 200 miljoner x 50 rader), så saktar dashboarden ner avsevärt – från 10 sekunder till flera minuter per klick. Vi experimenterade både med live-anslutning och med extrahering. Arbetsfarten var jämförbar.
2. Begränsningar vid användning av flera datalager (datasets). Det går inte att använda standardmetoder för att ange relationen mellan datasets. Om man använder omvägar för att koppla datasets kommer det att påverka prestandan kraftigt. I vårt fall övervägde vi att materialisera data i varje nödvändig dimension av visualiseringar och göra byten på dessa materialiserade datasets med bibehållna tidigare valda filter – detta visade sig vara omöjligt att göra i Tableau.
3. I Tableau är det omöjligt att skapa dynamiska parametrar. Du kan inte fylla en parameter, som används för att filtrera ett dataset i extraheringen eller vid live-anslutningen, med resultatet från ett annat urval från datasetet eller resultatet av en annan SQL-fråga, endast användarens inmatning eller en konstant.
4. Begränsningar relaterade till skapandet av dashboards med OLAP|Pivot-tabeller.
   I MSTR, SAP SAC, SAP Analysis, när du lägger till ett dataset i rapporten är alla objekt kopplade till varandra som standard. Det finns inte i Tableau; kopplingen måste ställas in manuellt. Det är kanske mer flexibelt, men för alla våra instrumentpaneler är detta ett obligatoriskt krav på elementen – därför innebär det extra arbetsinsatser. Dessutom, om du gör relaterade filter, så att till exempel när du filtrerar regionen är listan över städer begränsad till endast städer i den regionen, hamnar du genast i sekventiella databasfrågor eller extrakt, vilket märkbar saktar ner instrumentpanelen.
5. Begränsningar i funktionerna. Både över extraktet och SÅ MYCKET mer över datasetet från Live-connect får man inte göra massiva omvandlingar. Det kan göras via Tableau Prep, men det innebär ytterligare arbetsinsatser och ytterligare ett verktyg som måste läras in och underhållas. Till exempel kan du inte transponera data eller göra en join av dem själva. Det stängs av genom omvandlingar av individuella kolumner eller fält som måste väljas via case eller if, vilket ger upphov till mycket komplexa SQL-frågor där databasen huvudsakligen spenderar tid på att kompilera texten i frågan. Dessa brister i verktyget har vi varit tvungna att lösa på nivå av en vy, vilket leder till en komplicering av lagret, extra belastningar och omvandlingar.

Vi har inte gett upp på Tableau. Men som ett verktyg som kan bygga industriella instrumentpaneler och ett medel som kan ersätta och digitalisera hela systemet för företagsrapportering, betraktar vi inte Tableau.

Vi utvecklar för närvarande en liknande instrumentpanel i ett annat verktyg och samtidigt försöker vi ompröva arkitekturen i instrumentpanelen i Tableau för att förenkla den ännu mer. Om kommuniteten är intresserad kommer vi att berätta om resultaten.

Vi ser också fram emot era idéer eller råd om hur man i Tableau kan bygga snabba instrumentpaneler över sådana stora datamängder, då vi har en webbplats där datan är mycket större än i detaljhandeln.

Källa: habr.com