De tijd voor rapportage in Excel is snel aan het verdwijnen - de trend naar handige tools voor het presenteren en analyseren van informatie is op alle gebieden zichtbaar. We discussieerden intern al lang over de digitalisering van de rapportering en kozen voor het visualisatie- en selfservice analytics-systeem van Tableau. Alexander Bezugly, hoofd van de afdeling analytische oplossingen en rapportage van de M.Video-Eldorado Group, sprak over de ervaring en resultaten van het bouwen van een gevechtsdashboard.
Ik zal meteen zeggen dat niet alles wat gepland was, is gerealiseerd, maar de ervaring was interessant, ik hoop dat het ook voor jou nuttig zal zijn. En als iemand ideeën heeft over hoe het beter kan, zou ik zeer dankbaar zijn voor uw advies en ideeën.
Hieronder staat wat we tegenkwamen en wat we leerden.
Waar zijn we begonnen?
M.Video-Eldorado heeft een goed ontwikkeld datamodel: gestructureerde informatie met de vereiste opslagdiepte en een groot aantal rapporten in vaste vorm (zie meer details ). Hiervan maken analisten draaitabellen of opgemaakte nieuwsbrieven in Excel, of prachtige PowerPoint-presentaties voor eindgebruikers.
Ongeveer twee jaar geleden zijn we in plaats van rapporten in vaste vorm begonnen met het maken van analytische rapporten in SAP Analysis (een Excel-add-on, in wezen een draaitabel over de OLAP-engine). Maar deze tool kon niet aan de behoeften van alle gebruikers voldoen; de meerderheid bleef informatie gebruiken die bovendien door analisten was verwerkt.
Onze eindgebruikers vallen in drie categorieën:
Topmanagement. Vraagt om informatie op een goed gepresenteerde en duidelijk begrijpelijke manier.
Middenmanagement, gevorderde gebruikers. Geïnteresseerd in dataverkenning en in staat om zelfstandig rapporten op te stellen als er tools beschikbaar zijn. Zij werden de belangrijkste gebruikers van analytische rapporten in SAP Analysis.
Massale gebruikers. Ze zijn niet geïnteresseerd in het zelfstandig analyseren van gegevens; ze gebruiken rapporten met een beperkte mate van vrijheid, in de vorm van nieuwsbrieven en draaitabellen in Excel.
Ons idee was om aan de behoeften van alle gebruikers te voldoen en hen één handig hulpmiddel te bieden. We besloten om te beginnen met het topmanagement. Ze hadden gebruiksvriendelijke dashboards nodig om de belangrijkste bedrijfsresultaten te analyseren. We zijn dus begonnen met Tableau en hebben eerst twee richtingen gekozen: retail- en online verkoopindicatoren met een beperkte diepte en breedte van de analyse, die ongeveer 80% van de door het topmanagement opgevraagde gegevens zouden bestrijken.
Omdat de gebruikers van de dashboards het topmanagement waren, verscheen er nog een extra KPI van het product: reactiesnelheid. Niemand wacht 20-30 seconden totdat de gegevens zijn bijgewerkt. De navigatie had binnen 4-5 seconden moeten plaatsvinden, of beter nog, onmiddellijk. En helaas zijn we er niet in geslaagd dit te bereiken.
Zo zag de lay-out van ons hoofddashboard eruit:
Het belangrijkste idee is om de belangrijkste KPI-drivers, waarvan er in totaal 19 waren, aan de linkerkant te combineren en aan de rechterkant hun dynamiek en uitsplitsing naar hoofdkenmerken weer te geven. De taak lijkt eenvoudig, de visualisatie is logisch en begrijpelijk, totdat je in de details duikt.
Detail 1. Datavolume
Onze hoofdtabel voor de jaarlijkse omzet beslaat ongeveer 300 miljoen rijen. Omdat het nodig is om de dynamiek van vorig jaar en het jaar daarvoor te weerspiegelen, bedraagt de hoeveelheid gegevens over de werkelijke verkoop alleen al ongeveer 1 miljard regels. Informatie over geplande gegevens en het online verkoopblok worden ook afzonderlijk opgeslagen. Daarom was de snelheid van de query met de selectie van alle indicatoren voor een week uit de huidige opslag ongeveer 15-20 seconden, ook al gebruikten we de kolomvormige in-memory DB SAP HANA. De oplossing voor dit probleem doet zich voor: extra materialisatie van gegevens. Maar er zijn ook valkuilen, waarover hieronder meer.
Detail 2. Niet-additieve indicatoren
Veel van onze KPI’s zijn gekoppeld aan het aantal ontvangstbewijzen. En deze indicator vertegenwoordigt COUNT DISTINCT van het aantal rijen (controleer headers) en toont verschillende bedragen, afhankelijk van de geselecteerde attributen. Hoe deze indicator en zijn afgeleide bijvoorbeeld moeten worden berekend:
Om uw berekeningen correct te maken, kunt u:
- Bereken dergelijke indicatoren direct in de opslag;
- Voer berekeningen uit op het volledige gegevensvolume in Tableau, d.w.z. geef op verzoek in Tableau alle gegevens op volgens geselecteerde filters in de granulariteit van de ontvangstpositie;
- Creëer een gematerialiseerde showcase waarin alle indicatoren worden berekend in alle steekproefopties die verschillende niet-additieve resultaten opleveren.
Het is duidelijk dat in het voorbeeld UTE1 en UTE2 materiaalattributen zijn die de producthiërarchie vertegenwoordigen. Dit is geen statisch iets; het management binnen het bedrijf vindt erdoor plaats, omdat Voor verschillende productgroepen zijn verschillende managers verantwoordelijk. We hebben veel globale herzieningen van deze hiërarchie gehad, toen alle niveaus veranderden, toen relaties werden herzien, en constante puntveranderingen, toen de ene groep van het ene knooppunt naar het andere verhuisde. Bij conventionele rapportage wordt dit allemaal direct berekend op basis van de kenmerken van het materiaal; in het geval van materialisatie van deze gegevens is het noodzakelijk om een mechanisme te ontwikkelen om dergelijke veranderingen te volgen en historische gegevens automatisch opnieuw te laden. Een zeer niet-triviale taak.
Detail 3. Gegevensvergelijking
Dit punt is vergelijkbaar met het vorige. Het komt erop neer dat het bij het analyseren van een bedrijf gebruikelijk is om verschillende vergelijkingsniveaus te maken met de voorgaande periode:
Vergelijking met de vorige periode (van dag tot dag, van week tot week, van maand tot maand)
In deze vergelijking wordt aangenomen dat we, afhankelijk van de door de gebruiker geselecteerde periode (bijvoorbeeld de 33e week van het jaar), de dynamiek tegen de 32e week moeten weergeven; als we gegevens voor een maand selecteren, bijvoorbeeld mei , dan zou deze vergelijking de dynamiek in april laten zien.
Vergelijking met vorig jaar
De belangrijkste nuance hier is dat wanneer u per dag en per week vergelijkt, u niet dezelfde dag van vorig jaar neemt, d.w.z. je kunt het huidige jaar niet zomaar op één zetten. U moet kijken naar de dag van de week die u vergelijkt. Bij het vergelijken van maanden moet u daarentegen precies dezelfde kalenderdag van vorig jaar nemen. Er zijn ook nuances met schrikkeljaren. In de oorspronkelijke repositories wordt alle informatie per dag verspreid; er zijn geen aparte velden met weken, maanden of jaren. Om een volledige analytische dwarsdoorsnede in het panel te verkrijgen, moet u daarom niet één periode tellen, bijvoorbeeld een week, maar vier weken, en deze gegevens vervolgens vergelijken, de dynamiek en afwijkingen weerspiegelen. Dienovereenkomstig kan deze logica voor het genereren van vergelijkingen in de dynamiek ook worden geïmplementeerd in Tableau of aan de winkelzijde. Ja, en natuurlijk kenden we deze details en dachten we erover na in de ontwerpfase, maar het was moeilijk om de impact ervan op de prestaties van het uiteindelijke dashboard te voorspellen.
Bij de implementatie van het dashboard hebben we het lange Agile-pad gevolgd. Onze taak was om zo snel mogelijk een werkinstrument te leveren met de nodige gegevens voor het testen. Daarom zijn we in sprints gegaan en zijn we begonnen met het minimaliseren van de werkzaamheden aan de huidige opslag.
Deel 1: Geloof in tableau
Om de IT-ondersteuning te vereenvoudigen en snel veranderingen door te voeren, hebben we besloten om de logica voor het berekenen van niet-additieve indicatoren en het vergelijken van afgelopen perioden in Tableau te maken.
Fase 1. Alles is live, geen vensterwijzigingen.
In dit stadium hebben we Tableau gekoppeld aan de huidige winkelpuien en besloten we te kijken hoe het aantal bonnen voor een jaar zou worden berekend.
Resultaat:
Het antwoord was deprimerend: 20 minuten. Gegevensoverdracht via het netwerk, hoge belasting van Tableau. We realiseerden ons dat logica met niet-additieve indicatoren moet worden geïmplementeerd op HANA. Dit maakte ons niet erg bang, we hadden al vergelijkbare ervaring met BO en Analyse en we wisten hoe we snelle showcases in HANA moesten bouwen die correct berekende niet-additieve indicatoren produceerden. Nu hoefde je ze alleen nog maar aan te passen aan Tableau.
Fase 2. We stemmen de vitrines af, geen materialisatie, alles in een mum van tijd.
We hebben een aparte nieuwe showcase gemaakt die de benodigde gegevens voor TABLEAU on-the-fly produceerde. Over het algemeen hebben we een goed resultaat behaald: we hebben de tijd voor het genereren van alle indicatoren in één week teruggebracht tot 9-10 seconden. En we hadden eerlijk gezegd verwacht dat in Tableau de responstijd van het dashboard bij de eerste opening 20-30 seconden zou zijn en daarna vanwege de cache van 10 naar 12, wat over het algemeen bij ons zou passen.
Resultaat:
Eerste geopend dashboard: 4-5 minuten
Elke klik: 3-4 minuten
Niemand had een dergelijke extra toename van het werk aan de winkel verwacht.
Deel 2. Duik in Tableau
Fase 1. Tableau-prestatieanalyse en snelle afstemming
We zijn begonnen met analyseren waar Tableau de meeste tijd doorbrengt. En daar zijn behoorlijk goede tools voor, wat natuurlijk een pluspunt is van Tableau. Het belangrijkste probleem dat we identificeerden, waren de zeer complexe SQL-query's die Tableau aan het bouwen was. Ze werden voornamelijk geassocieerd met:
— gegevenstransmissie. Omdat Tableau geen tools heeft voor het transponeren van datasets, moesten we, om de linkerkant van het dashboard te bouwen met een gedetailleerde weergave van alle KPI's, een tabel maken met behulp van een case. De omvang van de SQL-query's in de database bereikte 120 tekens.
- keuze van tijdsperiode. Een dergelijke zoekopdracht op databaseniveau kostte meer tijd om te compileren dan om uit te voeren:
Die. verzoekverwerking 12 seconden + 5 seconden uitvoering.
We hebben besloten de berekeningslogica aan de Tableau-kant te vereenvoudigen en een ander deel van de berekeningen naar storefront- en databaseniveau te verplaatsen. Dit leverde goede resultaten op.
Eerst hebben we de transpositie on-the-fly uitgevoerd, we hebben dit gedaan via een volledige outside join in de laatste fase van de VIEW-berekening, volgens deze aanpak die op de wiki wordt beschreven. и .
Dat wil zeggen, we hebben een settingtabel gemaakt - een transpositiematrix (21x21) en alle indicatoren per rij ontvangen.
Het was:
Het werd:
Er wordt bijna geen tijd besteed aan de databasetranspositie zelf. Het verzoek om alle indicatoren voor de week werd binnen ongeveer 10 seconden verwerkt. Maar aan de andere kant is er flexibiliteit verloren gegaan bij het construeren van een dashboard op basis van een specifieke indicator, d.w.z. voor de rechterkant van het dashboard waar de dynamiek en gedetailleerde uitsplitsing van een specifieke indicator worden gepresenteerd, werkte de vitrine voorheen in 1-3 seconden, omdat het verzoek was gebaseerd op één indicator, en nu selecteerde de database altijd alle indicatoren en filterde het resultaat voordat het resultaat naar Tableau werd teruggestuurd.
Als gevolg hiervan nam de snelheid van het dashboard bijna 3 keer af.
Resultaat:
- 5 sec – dashboards en visualisaties analyseren
- 15-20 seconden - voorbereiding op het compileren van queries met het uitvoeren van voorberekeningen in Tableau
- 35-45 sec - compilatie van SQL-query's en hun parallel-sequentiële uitvoering in Hana
- 5 sec – resultaten verwerken, sorteren, visualisaties opnieuw berekenen in Tableau
- Dergelijke resultaten pasten natuurlijk niet bij het bedrijf en we gingen door met optimaliseren.
Fase 2. Minimale logica in Tableau, volledige materialisatie
We begrepen dat het onmogelijk was om een dashboard te bouwen met een responstijd van enkele seconden op een storefront die 10 seconden draait, en we hebben opties overwogen om gegevens aan de databasekant specifiek voor het benodigde dashboard te materialiseren. Maar we kwamen een mondiaal probleem tegen dat hierboven werd beschreven: niet-additieve indicatoren. We konden er niet voor zorgen dat Tableau bij het wijzigen van filters of drilldowns flexibel kon schakelen tussen verschillende storefronts en niveaus die vooraf waren ontworpen voor verschillende producthiërarchieën (in het voorbeeld genereren drie query's zonder UTE, waarbij UTE1 en UTE2 verschillende resultaten opleveren). Daarom hebben we besloten om het dashboard te vereenvoudigen, de producthiërarchie in het dashboard achterwege te laten en te kijken hoe snel het zou kunnen zijn in een vereenvoudigde versie.
Daarom hebben we in deze laatste fase een aparte repository samengesteld waarin we alle KPI’s in getransponeerde vorm hebben toegevoegd. Aan de databasekant wordt elk verzoek om een dergelijke opslag in 0,1 - 0,3 seconden verwerkt. In het dashboard ontvingen we de volgende resultaten:
Eerste opening: 8-10 seconden
Elke klik: 6-7 seconden
De tijdsbesteding van Tableau bestaat uit:
- 0,3 sec. — dashboardparsing en compilatie van SQL-query's
- 1,5-3 sec. — uitvoering van SQL-query's in Hana voor hoofdvisualisaties (wordt parallel uitgevoerd met stap 1)
- 1,5-2 sec. — weergave, herberekening van visualisaties
- 1,3 sec. — uitvoering van aanvullende SQL-query's om relevante filterwaarden te verkrijgen (merk, divisie, stad, winkel), parseerresultaten
Om het even kort samen te vatten
We vonden de Tableau-tool leuk vanuit een visualisatieperspectief. In de prototypefase hebben we verschillende visualisatie-elementen overwogen en ze allemaal in bibliotheken gevonden, inclusief complexe segmentatie op meerdere niveaus en een waterval met meerdere stuurprogramma's.
Bij het implementeren van dashboards met belangrijke verkoopindicatoren kwamen we prestatieproblemen tegen die we nog niet hebben kunnen overwinnen. We zijn ruim twee maanden bezig geweest en hebben een functioneel onvolledig dashboard ontvangen, waarvan de reactiesnelheid op de rand van acceptabel ligt. En we trokken voor onszelf conclusies:
- Tableau kan niet werken met grote hoeveelheden data. Als u in het oorspronkelijke datamodel meer dan 10 GB aan gegevens heeft (ongeveer 200 miljoen x 50 rijen), wordt het dashboard ernstig vertraagd - van 10 seconden tot enkele minuten voor elke klik. We hebben geëxperimenteerd met zowel live-connect als extract. De werksnelheid is vergelijkbaar.
- Beperking bij gebruik van meerdere opslagplaatsen (datasets). Er is geen manier om de relatie tussen datasets met standaardmiddelen aan te geven. Als u tijdelijke oplossingen gebruikt om datasets met elkaar te verbinden, heeft dit een grote invloed op de prestaties. In ons geval hebben we de optie overwogen om gegevens in elke vereiste weergavesectie te materialiseren en schakelaars aan te brengen op deze gematerialiseerde datasets met behoud van de eerder geselecteerde filters - dit bleek onmogelijk te doen in Tableau.
- Het is niet mogelijk om dynamische parameters te maken in Tableau. U kunt een parameter die wordt gebruikt om een dataset te filteren in een uittreksel of tijdens een live-verbinding niet vullen met het resultaat van een andere selectie uit de dataset of het resultaat van een andere SQL-query, alleen native gebruikersinvoer of een constante.
- Beperkingen die verband houden met het bouwen van een dashboard met OLAP|PivotTable-elementen.
Als u in MSTR, SAP SAC en SAP Analysis een gegevensset aan een rapport toevoegt, zijn alle objecten daarin standaard aan elkaar gerelateerd. Tableau heeft dit niet; de verbinding moet handmatig worden geconfigureerd. Dit is waarschijnlijk flexibeler, maar voor al onze dashboards is dit een verplichte vereiste voor elementen - dit zijn dus extra arbeidskosten. Als u bovendien gerelateerde filters maakt, zodat bijvoorbeeld bij het filteren van een regio de lijst met steden alleen beperkt is tot de steden van deze regio, krijgt u onmiddellijk opeenvolgende zoekopdrachten naar de database of Extract, wat de verwerking merkbaar vertraagt. dashboard. - Beperkingen in functies. Massatransformaties kunnen niet worden uitgevoerd op het extract of, VOORAL, op de dataset van Live-connecta. Dit kan worden gedaan via Tableau Prep, maar het is extra werk en een extra hulpmiddel om te leren en te onderhouden. U kunt gegevens bijvoorbeeld niet transponeren of met zichzelf samenvoegen. Wat wordt afgesloten door transformaties op individuele kolommen of velden, die moeten worden geselecteerd via hoofdlettergebruik of if, en dit genereert zeer complexe SQL-query's, waarbij de database het grootste deel van zijn tijd besteedt aan het samenstellen van de querytekst. Deze inflexibiliteit van de tool moest op showcaseniveau worden opgelost, wat leidde tot complexere opslag, extra downloads en transformaties.
We hebben Tableau niet opgegeven. Maar we beschouwen Tableau niet als een tool die industriële dashboards kan bouwen en een tool waarmee het volledige bedrijfsrapportagesysteem van een bedrijf kan worden vervangen en gedigitaliseerd.
We zijn nu actief bezig met het ontwikkelen van een soortgelijk dashboard in een andere tool en proberen tegelijkertijd de dashboardarchitectuur in Tableau te herzien om deze nog verder te vereenvoudigen. Als de gemeenschap geïnteresseerd is, zullen we u over de resultaten vertellen.
We wachten ook op uw ideeën of advies over hoe u in Tabeau snelle dashboards kunt bouwen over zulke grote hoeveelheden gegevens, omdat we een website hebben waar veel meer gegevens te vinden zijn dan in de detailhandel.
Bron: www.habr.com