Tableau in die kleinhandel, regtig?

Die tyd vir verslagdoening in Excel is vinnig besig om te verdwyn - die neiging na gerieflike hulpmiddels vir die aanbieding en ontleding van inligting is op alle gebiede sigbaar. Ons bespreek al lank intern die digitalisering van verslagdoening en het die Tableau-visualisering en selfbedieninganalise-stelsel gekies. Alexander Bezugly, hoof van die afdeling vir analitiese oplossings en verslagdoening van die M.Video-Eldorado Groep, het gepraat oor die ervaring en resultate van die bou van 'n gevegspaneelbord.

Ek sal dadelik sê dat nie alles wat beplan is, gerealiseer is nie, maar die ervaring was interessant, ek hoop dit sal vir jou ook nuttig wees. En as iemand enige idees het oor hoe dit beter gedoen kan word, sal ek baie dankbaar wees vir jou raad en idees.

Onder die snit gaan oor wat ons teëgekom het en waaroor ons geleer het.

Waar het ons begin

M.Video-Eldorado het 'n goed ontwikkelde datamodel: gestruktureerde inligting met die vereiste bergingsdiepte en 'n groot aantal verslae in vaste vorm (sien meer besonderhede Hierdie artikel). Hieruit maak ontleders óf spilpunttabelle óf geformateerde nuusbriewe in Excel, óf pragtige PowerPoint-aanbiedings vir eindgebruikers.

Ongeveer twee jaar gelede, in plaas van verslae in vaste vorm, het ons analitiese verslae in SAP Analysis ('n Excel-byvoeging, in wese 'n spiltabel oor die OLAP-enjin) begin skep. Maar hierdie instrument kon nie aan die behoeftes van alle gebruikers voldoen nie; die meerderheid het voortgegaan om inligting te gebruik wat addisioneel deur ontleders verwerk is.

Ons eindgebruikers val in drie kategorieë:

Topbestuur. Versoek inligting op 'n goed aangebied en duidelik verstaanbare wyse.

Middelbestuur, gevorderde gebruikers. Stel belang in dataverkenning en kan onafhanklik verslae bou as gereedskap beskikbaar is. Hulle het die sleutelgebruikers van analitiese verslae in SAP-analise geword.

Massa gebruikers. Hulle stel nie daarin belang om data onafhanklik te ontleed nie; hulle gebruik verslae met 'n beperkte mate van vryheid, in die formaat van nuusbriewe en spiltabelle in Excel.

Ons idee was om die behoeftes van alle gebruikers te dek en hulle 'n enkele, gerieflike hulpmiddel te gee. Ons het besluit om met topbestuur te begin. Hulle het maklik-om-te-gebruik kontroleskerms nodig gehad om sleutelbesigheidsresultate te ontleed. Dus, ons het met Tableau begin en eers twee rigtings gekies: kleinhandel- en aanlynverkope-aanwysers met beperkte diepte en breedte van analise, wat ongeveer 80% van die data wat deur topbestuur versoek word, sal dek.

Aangesien die gebruikers van die dashboards topbestuur was, het nog 'n bykomende KPI van die produk verskyn - reaksiespoed. Niemand sal 20-30 sekondes wag vir die data om opgedateer te word nie. Navigasie moes binne 4-5 sekondes gedoen gewees het, of beter nog, onmiddellik gedoen. En ons, helaas, het nie daarin geslaag om dit te bereik nie.

Dit is hoe die uitleg van ons hoofpaneelbord gelyk het:

Die sleutelgedagte is om die hoof-KPI-drywers, waarvan daar altesaam 19 was, aan die linkerkant te kombineer en hul dinamika en uiteensetting volgens hoofkenmerke aan die regterkant aan te bied. Die taak lyk eenvoudig, die visualisering is logies en verstaanbaar, totdat jy in die besonderhede duik.

Detail 1. Datavolume

Ons hooftabel vir jaarlikse verkope beslaan ongeveer 300 miljoen rye. Aangesien dit nodig is om die dinamika vir verlede jaar en die vorige jaar te weerspieël, is die volume data oor werklike verkope alleen ongeveer 1 miljard lyne. Inligting oor beplande data en die aanlynverkopeblok word ook apart gestoor. Daarom, alhoewel ons die kolomvormige in-geheue DB SAP HANA gebruik het, was die spoed van die navraag met die keuse van alle aanwysers vir een week van die huidige berging op die vlieg ongeveer 15-20 sekondes. Die oplossing vir hierdie probleem stel homself voor - bykomende materialisering van data. Maar dit het ook slaggate, meer daaroor hieronder.

Detail 2. Nie-additiewe aanwysers

Baie van ons KPI's is gekoppel aan die aantal kwitansies. En hierdie aanwyser verteenwoordig die COUNT ONDERSKEI van die aantal rye (kontroleer opskrifte) en toon verskillende hoeveelhede na gelang van die geselekteerde eienskappe. Byvoorbeeld, hoe hierdie aanwyser en sy afgeleide bereken moet word:

Om jou berekeninge korrek te maak, kan jy:

• Bereken sulke aanwysers dadelik in die stoor;
• Voer berekeninge uit op die hele volume data in Tableau, d.w.s. op versoek in Tableau, verskaf alle data volgens geselekteerde filters in die korreligheid van die kwitansieposisie;
• Skep 'n gematerialiseerde vertoonvenster waarin alle aanwysers bereken sal word in alle voorbeeldopsies wat verskillende nie-bykomende resultate gee.

Dit is duidelik dat in die voorbeeld UTE1 en UTE2 wesenlike eienskappe is wat die produkhiërargie verteenwoordig. Dit is nie 'n statiese ding nie; bestuur binne die maatskappy vind daardeur plaas, want Verskillende bestuurders is verantwoordelik vir verskillende produkgroepe. Ons het baie globale hersienings van hierdie hiërargie gehad, toe alle vlakke verander het, toe verhoudings hersien is, en konstante puntveranderinge, wanneer een groep van een nodus na 'n ander beweeg het. In konvensionele verslagdoening word dit alles onmiddellik uit die eienskappe van die materiaal bereken; in die geval van materialisering van hierdie data is dit nodig om 'n meganisme te ontwikkel om sulke veranderinge op te spoor en historiese data outomaties te herlaai. 'n Baie nie-triviale taak.

Detail 3. Datavergelyking

Hierdie punt is soortgelyk aan die vorige een. Die slotsom is dat wanneer 'n maatskappy ontleed word, dit gebruiklik is om verskeie vlakke van vergelyking met die vorige tydperk te vorm:

Vergelyking met die vorige tydperk (dag tot dag, week tot week, maand tot maand)

In hierdie vergelyking word aanvaar dat, afhangende van die tydperk wat die gebruiker gekies het (byvoorbeeld, die 33ste week van die jaar), ons die dinamika teen die 32ste week moet wys; as ons data vir 'n maand gekies het, byvoorbeeld Mei , dan sal hierdie vergelyking die dinamika teen April wys.

Vergelyking met verlede jaar

Die belangrikste nuanse hier is dat wanneer jy volgens dag en week vergelyk, jy nie dieselfde dag van verlede jaar neem nie, d.w.s. jy kan nie net die huidige jaar minus een stel nie. Jy moet kyk na die dag van die week wat jy vergelyk. Wanneer jy maande vergelyk, moet jy inteendeel presies dieselfde kalenderdag van verlede jaar neem. Daar is ook nuanses met skrikkeljare. In die oorspronklike bewaarplekke word alle inligting per dag versprei; daar is geen aparte velde met weke, maande of jare nie. Daarom, om 'n volledige analitiese deursnee in die paneel te verkry, moet jy nie een periode tel nie, byvoorbeeld 'n week, maar 4 weke, en dan hierdie data vergelyk, weerspieël die dinamika, afwykings. Gevolglik kan hierdie logika vir die generering van vergelykings in dinamika ook geïmplementeer word in Tableau of aan die winkelfrontkant. Ja, en natuurlik het ons hierdie besonderhede in die ontwerpstadium geweet en daaroor gedink, maar dit was moeilik om die impak daarvan op die prestasie van die finale paneelbord te voorspel.

Toe ons die dashboard geïmplementeer het, het ons die lang Agile-pad gevolg. Ons taak was om so vinnig as moontlik 'n werkende hulpmiddel te voorsien met die nodige data vir toetsing. Daarom het ons in naellope gegaan en begin om werk aan die kant van die huidige berging te minimaliseer.

Deel 1: Geloof in Tableau

Om IT-ondersteuning te vereenvoudig en veranderinge vinnig te implementeer, het ons besluit om die logika te maak vir die berekening van nie-bykomende aanwysers en die vergelyking van vorige tydperke in Tableau.

Fase 1. Alles is lewendig, geen vensterwysigings nie.

Op hierdie stadium het ons Tableau aan die huidige winkelfronte gekoppel en besluit om te kyk hoe die aantal kwitansies vir een jaar bereken sou word.

Gevolg:

Die antwoord was neerdrukkend – 20 minute. Oordrag van data oor die netwerk, hoë las op Tableau. Ons het besef dat logika met nie-byvoegende aanwysers op HANA geïmplementeer moet word. Dit het ons nie baie laat skrik nie, ons het reeds soortgelyke ondervinding met BO en Analysis gehad en ons het geweet hoe om vinnige vertoonvensters in HANA te bou wat korrek berekende nie-byvoegende aanwysers produseer. Nou was al wat oorgebly het om hulle by Tableau aan te pas.

Fase 2. Ons stem die vertoonkaste in, geen materialisering nie, alles op die vlieg.

Ons het 'n aparte nuwe vertoonvenster geskep wat die vereiste data vir TABLEAU op die vlug gelewer het. Oor die algemeen het ons 'n goeie resultaat gekry; ons het die tyd vir die generering van alle aanwysers in een week verminder tot 9-10 sekondes. En ons het eerlikwaar verwag dat in Tableau die reaksietyd van die dashboard 20-30 sekondes sou wees by die eerste opening en dan as gevolg van die kas van 10 tot 12, wat ons oor die algemeen sal pas.

Gevolg:

Eerste oop dashboard: 4-5 minute
Enige klik: 3-4 minute
Niemand het so 'n bykomende toename in die werk van die winkelfront verwag nie.

Deel 2. Duik in Tableau

Fase 1. Tableau prestasie-analise en vinnige tuning

Ons het begin om te ontleed waar Tableau die meeste van sy tyd deurbring. En daar is nogal goeie gereedskap hiervoor, wat natuurlik 'n pluspunt van Tableau is. Die hoofprobleem wat ons geïdentifiseer het, was die baie komplekse SQL-navrae wat Tableau besig was om te bou. Hulle was hoofsaaklik geassosieer met:

- datatransposisie. Aangesien Tableau nie gereedskap het om datastelle te transponeer nie, om die linkerkant van die dashboard te bou met 'n gedetailleerde voorstelling van alle KPI's, moes ons 'n tabel met 'n geval skep. Die grootte van SQL-navrae in die databasis het 120 000 karakters bereik.

- keuse van tydperk. So 'n navraag op die databasisvlak het meer tyd geneem om saam te stel as om uit te voer:

Dié. versoek verwerking 12 sekondes + 5 sekondes uitvoering.

Ons het besluit om die berekeningslogika aan die Tableau-kant te vereenvoudig en 'n ander deel van die berekeninge na die winkelfront- en databasisvlak te skuif. Dit het goeie resultate gebring.

Eerstens het ons die transposisie dadelik gedoen, ons het dit gedoen deur 'n volledige buitenste aansluiting by die finale stadium van die VIEW-berekening, volgens hierdie benadering wat op die wiki beskryf word Transponeer - Wikipedia, die vrye ensiklopedie и Elementêre matriks - Wikipedia, die vrye ensiklopedie.

Dit wil sê, ons het 'n opsteltabel gemaak - 'n transposisiematriks (21x21) en al die aanwysers in 'n ry-vir-ry-uiteensetting ontvang.

Was:


Dit het geword:


Byna geen tyd word aan die databasistransposisie self bestee nie. Die versoek vir alle aanwysers vir die week is voortgegaan om in ongeveer 10 sekondes verwerk te word. Maar aan die ander kant het buigsaamheid verlore gegaan in terme van die bou van 'n dashboard gebaseer op 'n spesifieke aanwyser, d.w.s. vir die regterkant van die dashboard waar die dinamika en gedetailleerde uiteensetting van 'n spesifieke aanwyser aangebied word, het die vertoonkas voorheen in 1-3 sekondes gewerk, want die versoek was gebaseer op een aanwyser, en nou het die databasis altyd alle aanwysers gekies en die resultaat gefiltreer voordat die resultaat na Tableau teruggestuur is.

As gevolg hiervan het die spoed van die paneelbord met byna 3 keer afgeneem.

Gevolg:

1. 5 sekondes – ontleed dashboards, visualiserings
2. 15-20 sekondes - voorbereiding vir die opstel van navrae met die uitvoer van voorafberekeninge in Tableau
3. 35-45 sekondes - samestelling van SQL-navrae en hul parallel-opeenvolgende uitvoering in Hana
4. 5 sekondes – verwerking van resultate, sortering, herberekening van visualisasies in Tableau
5. Natuurlik het sulke resultate nie by die besigheid gepas nie, en ons het voortgegaan met optimalisering.

Fase 2. Minimum logika in Tableau, volledige materialisering

Ons het verstaan ​​dat dit onmoontlik was om 'n dashboard met 'n reaksietyd van etlike sekondes te bou op 'n winkelfront wat vir 10 sekondes loop, en ons het opsies oorweeg om data aan die databasiskant spesifiek vir die vereiste dashboard te materialiseer. Maar ons het 'n wêreldwye probleem teëgekom wat hierbo beskryf is - nie-toevoegende aanwysers. Ons was nie in staat om seker te maak dat wanneer ons filters of afrondings verander het, Tableau buigsaam oorgeskakel het tussen verskillende winkelfronte en vlakke wat vooraf ontwerp is vir verskillende produkhiërargieë nie (in die voorbeeld genereer drie navrae sonder UTE, met UTE1 en UTE2 verskillende resultate). Daarom het ons besluit om die dashboard te vereenvoudig, die produkhiërargie in die dashboard te laat vaar en te kyk hoe vinnig dit in 'n vereenvoudigde weergawe kan wees.

Dus, in hierdie laaste stadium het ons 'n aparte bewaarplek saamgestel waarin ons al die KPI's in getransponeerde vorm bygevoeg het. Aan die databasiskant word enige versoek na so 'n berging in 0,1 - 0,3 sekondes verwerk. In die dashboard het ons die volgende resultate ontvang:

Eerste opening: 8-10 sekondes
Enige klik: 6-7 sekondes

Die tyd wat Tableau spandeer, bestaan ​​uit:

1. 0,3 sek. - dashboard-ontleding en samestelling van SQL-navrae
2. 1,5-3 sek. - uitvoering van SQL-navrae in Hana vir hoofvisualisering (loop parallel met stap 1)
3. 1,5-2 sek. — weergawe, herberekening van visualiserings
4. 1,3 sek. - uitvoering van addisionele SQL-navrae om relevante filterwaardes te verkry (handelsmerk, afdeling, stad, winkel), ontleedresultate

Om dit kortliks op te som

Ons het van die Tableau-instrument gehou vanuit 'n visualiseringsperspektief. Op die prototiperingstadium het ons verskeie visualiseringselemente oorweeg en hulle almal in biblioteke gevind, insluitend komplekse multivlaksegmentering en multibestuurderwaterval.

Terwyl ons dashboards met sleutelverkope-aanwysers geïmplementeer het, het ons prestasieprobleme ondervind wat ons nog nie kon oorkom nie. Ons het meer as twee maande spandeer en 'n funksioneel onvolledige dashboard ontvang, waarvan die reaksiespoed op die rand van aanvaarbaar is. En ons het vir onsself gevolgtrekkings gemaak:

1. Tableau kan nie met groot hoeveelhede data werk nie. As jy in die oorspronklike datamodel meer as 10 GB data het (ongeveer 200 miljoen X 50 rye), dan word die dashboard ernstig vertraag - van 10 sekondes tot 'n paar minute vir elke klik. Ons het geëksperimenteer met beide live-connect en extract. Die werkspoed is vergelykbaar.
2. Beperking by die gebruik van veelvuldige bergings (datastelle). Daar is geen manier om die verwantskap tussen datastelle met behulp van standaardmiddele aan te dui nie. As jy oplossings gebruik om datastelle te verbind, sal dit werkverrigting grootliks beïnvloed. In ons geval het ons die opsie oorweeg om data in elke vereiste aansig-afdeling te materialiseer en skakelaars op hierdie gematerialiseerde datastelle te maak, terwyl die voorheen geselekteerde filters behoue ​​bly - dit was onmoontlik om in Tableau te doen.
3. Dit is nie moontlik om dinamiese parameters in Tableau te maak nie. Jy kan nie 'n parameter invul wat gebruik word om 'n datastel in 'n uittreksel of tydens 'n lewendige verbinding te filtreer met die resultaat van 'n ander keuse uit die datastel of die resultaat van 'n ander SQL-navraag nie, slegs inheemse gebruikerinvoer of 'n konstante.
4. Beperkings wat verband hou met die bou van 'n kontroleskerm met OLAP|Draaitabel-elemente.
   In MSTR, SAP SAC, SAP Analysis, as jy 'n datastel by 'n verslag voeg, is alle voorwerpe daarop by verstek aan mekaar verwant. Tableau het dit nie; die verbinding moet met die hand gekonfigureer word. Dit is waarskynlik meer buigsaam, maar vir al ons dashboards is dit 'n verpligte vereiste vir elemente - so dit is bykomende arbeidskoste. Verder, as jy verwante filters maak sodat, byvoorbeeld, wanneer 'n streek gefiltreer word, die lys van stede slegs beperk is tot die stede van hierdie streek, eindig jy dadelik met opeenvolgende navrae na die databasis of Uittreksel, wat merkbaar vertraag die dashboard.
5. Beperkings in funksies. Massa-transformasies kan nie op die uittreksel of, VERAL, op die datastel van Live-connecta gedoen word nie. Dit kan gedoen word deur Tableau Prep, maar dit is bykomende werk en nog 'n hulpmiddel om te leer en in stand te hou. Jy kan byvoorbeeld nie data transponeer of dit met homself verbind nie. Wat word gesluit deur transformasies op individuele kolomme of velde, wat gekies moet word deur geval of as, en dit genereer baie komplekse SQL-navrae, waarin die databasis die meeste van sy tyd spandeer om die navraagteks saam te stel. Hierdie onbuigsaamheid van die instrument moes op die vertoonvenstervlak opgelos word, wat lei tot meer komplekse berging, bykomende aflaaie en transformasies.

Ons het nie opgegee op Tableau nie. Maar ons beskou Tableau nie as 'n instrument wat in staat is om industriële dashboards te bou en 'n instrument waarmee 'n maatskappy se hele korporatiewe verslagdoeningstelsel vervang en gedigitaliseer kan word nie.

Ons ontwikkel nou aktief 'n soortgelyke paneelbord in 'n ander instrument en probeer terselfdertyd om die paneelbordargitektuur in Tableau te hersien om dit nog meer te vereenvoudig. As die gemeenskap belangstel, sal ons jou van die resultate vertel.

Ons wag ook vir jou idees of raad oor hoe jy in Tabeau vinnige dashboards oor sulke groot volumes data kan bou, want ons het 'n webwerf waar daar baie meer data is as in kleinhandel.

Bron: will.com