De tiid foar rapportaazje yn Excel ferdwynt rap - de trend nei handige ark foar it presintearjen en analysearjen fan ynformaasje is op alle gebieten sichtber. Wy hawwe in lange tiid yntern besprutsen oer de digitalisearring fan rapportaazje en keas foar it Tableau-fisualisaasje- en self-service-analytyksysteem. Alexander Bezugly, haad fan 'e analytyske oplossingen en rapportaazjeôfdieling fan' e M.Video-Eldorado Group, spruts oer de ûnderfining en resultaten fan it bouwen fan in fjochtsdashboard.
Ik sil daliks sizze dat net alles dat pland wie realisearre, mar de ûnderfining wie nijsgjirrich, ik hoopje dat it ek nuttich foar jo sil wêze. En as immen hat ideeën oer hoe't it koe wurde dien better, Ik soe wêze hiel tankber foar jo advys en ideeën.
Under de besuniging giet oer wat wy tsjinkamen en wat wy leard oer.
Wêr binne wy begûn?
M.Video-Eldorado hat in goed ûntwikkele gegevensmodel: strukturearre ynformaasje mei de fereaske opslachdjipte en in grut oantal rapporten yn fêste foarm (sjoch mear details ). Fan dizze meitsje analysten of pivottabellen of opmakke nijsbrieven yn Excel, as prachtige PowerPoint-presintaasjes foar ein brûkers.
Sawat twa jier lyn, yn stee fan rapporten mei fêste foarm, begûnen wy analytyske rapporten te meitsjen yn SAP Analysis (in Excel-tafoeging, yn wêzen in draaitabel oer de OLAP-motor). Mar dit ark wie net by steat om te foldwaan oan de behoeften fan alle brûkers; de mearderheid bleau te brûken ynformaasje ekstra ferwurke troch analysts.
Us ein brûkers falle yn trije kategoryen:
Top behear. Freget ynformaasje op in goed presinteare en dúdlik begryplike manier.
Middelste behear, avansearre brûkers. Ynteressearre yn gegevensferkenning en kinne selsstannich rapporten bouwe as ark beskikber binne. Se waarden de kaai brûkers fan analytyske rapporten yn SAP Analysis.
Massa brûkers. Se binne net ynteressearre yn it ûnôfhinklik analysearjen fan gegevens; se brûke rapporten mei in beheinde graad fan frijheid, yn it formaat fan nijsbrieven en pivottabellen yn Excel.
Us idee wie om de behoeften fan alle brûkers te dekken en har ien, handich ark te jaan. Wy besletten om te begjinnen mei it topmanagement. Se hiene maklik te brûken dashboards nedich om wichtige saaklike resultaten te analysearjen. Dat, wy begûnen mei Tableau en keas earst twa rjochtingen: detailhannel en online ferkeap yndikatoaren mei beheinde djipte en breedte fan analyze, dy't soe dekke likernôch 80% fan de gegevens oanfrege troch top management.
Sûnt de brûkers fan 'e dashboards topbehear wiene, ferskynde in oare ekstra KPI fan it produkt - antwurdsnelheid. Gjinien sil wachtsje 20-30 sekonden foar de gegevens wurde bywurke. Navigaasje soe binnen 4-5 sekonden moatte wurde dien, of better noch, direkt dien. En dit slaggen wy, helaas, net.
Dit is hoe't de yndieling fan ús haaddashboard der útseach:
It wichtichste idee is om de wichtichste KPI-bestjoerders te kombinearjen, wêrfan d'r yn totaal 19 wiene, oan 'e lofterkant en presintearje har dynamyk en ferdieling troch haadattributen rjochts. De taak liket ienfâldich, de fisualisaasje is logysk en begryplik, oant jo yn 'e details dûke.
Detail 1. Data folume
Us haadtabel foar jierlikse ferkeap nimt sawat 300 miljoen rigen op. Om't it nedich is om de dynamyk foar ferline jier en it jier dêrfoar te reflektearjen, is it folume fan gegevens oer werklike ferkeap allinich sawat 1 miljard rigels. Ynformaasje oer plande gegevens en it online ferkeapblok wurde ek apart opslein. Dêrom, ek al brûkten wy de kolomme yn-ûnthâld DB SAP HANA, de snelheid fan de query mei de seleksje fan alle yndikatoaren foar ien wike út de hjoeddeiske opslach op 'e fly wie oer 15-20 sekonden. De oplossing foar dit probleem suggerearret himsels - ekstra materialization fan gegevens. Mar it hat ek pitfalls, mear oer harren hjirûnder.
Detail 2. Non-additive yndikatoaren
In protte fan ús KPI's binne bûn oan it oantal ûntfangsten. En dizze yndikator fertsjintwurdiget COUNT DISTINCT fan it oantal rigen (kontrôlekoppen) en toant ferskate bedraggen ôfhinklik fan 'e selekteare attributen. Bygelyks, hoe't dizze yndikator en syn derivative moatte wurde berekkene:
Om jo berekkeningen korrekt te meitsjen, kinne jo:
- Berekkenje sokke yndikatoaren op 'e flecht yn' e opslach;
- Útfiere berekkeningen op it hiele folume fan gegevens yn Tableau, i.e. op oanfraach yn Tableau, jouwe alle gegevens neffens selektearre filters yn de granularity fan de ûntfangst posysje;
- Meitsje in materialisearre showcase wêryn alle yndikatoaren sille wurde berekkene yn alle sample-opsjes dy't ferskate net-additive resultaten jouwe.
It is dúdlik dat yn it foarbyld UTE1 en UTE2 materiële attributen binne dy't de produkthierargy fertsjintwurdigje. Dit is gjin statysk ding; behear binnen it bedriuw fynt dêrtroch plak, om't Ferskillende managers binne ferantwurdlik foar ferskate produktgroepen. Wy hiene in protte globale ferzjes fan dizze hiërargy, doe't alle nivo's feroare, doe't relaasjes waarden herzien, en konstante punt feroarings, doe't ien groep ferhuze fan de iene knooppunt nei de oare. Yn konvinsjonele rapportaazje wurdt dit alles op 'e flecht berekkene út' e attributen fan it materiaal; yn it gefal fan materialisaasje fan dizze gegevens is it nedich om in meganisme te ûntwikkeljen foar it folgjen fan sokke feroaringen en automatysk opnij laden fan histoaryske gegevens. In tige net-triviale taak.
Detail 3. Data ferliking
Dit punt is fergelykber mei de foarige. De ûnderste rigel is dat by it analysearjen fan in bedriuw it gewoanlik is om ferskate nivo's te foarmjen fan fergeliking mei de foarige perioade:
Fergeliking mei de foarige perioade (dei oant dei, wike oant wike, moanne oant moanne)
Yn dizze fergeliking wurdt oannommen dat ôfhinklik fan 'e perioade selekteare troch de brûker (bygelyks de 33e wike fan it jier), wy de dynamyk moatte sjen litte troch de 32e wike; as wy gegevens foar in moanne selekteare, bygelyks maaie , dan soe dizze fergeliking de dynamyk oant april sjen litte.
Fergeliking mei ferline jier
De wichtichste nuânse hjir is dat by it fergelykjen fan dei en troch wike, jo net nimme deselde dei fan ferline jier, d.w.s. jo kinne it hjoeddeistige jier net gewoan min ien sette. Jo moatte sjen nei de dei fan 'e wike dy't jo fergelykje. By it fergelykjen fan moannen, krekt oarsom, moatte jo krekt deselde kalinderdei fan ferline jier nimme. Der binne ek nuânses mei in skrikkeljier. Yn 'e orizjinele repositories wurdt alle ynformaasje per dei ferspraat; d'r binne gjin aparte fjilden mei wiken, moannen of jierren. Dêrom, om in folsleine analytyske dwerstrochsneed yn it paniel te krijen, moatte jo net ien perioade telle, bygelyks in wike, mar 4 wiken, en dan fergelykje dizze gegevens, reflektearje de dynamyk, ôfwikingen. Dêrtroch kin dizze logika foar it generearjen fan fergelikingen yn dynamyk ek wurde ymplementearre itsij yn Tableau as oan 'e kant fan' e winkel. Ja, en fansels wisten wy en tochten oer dizze details op it ûntwerpstadium, mar it wie lestich om har ynfloed te foarsizzen op 'e prestaasjes fan it definitive dashboard.
By it ymplementearjen fan it dashboard folgen wy it lange Agile-paad. Us taak wie om sa rap mooglik in wurkmiddel te foarsjen mei de nedige gegevens foar testen. Dêrom gongen wy yn sprints en begûnen fan it minimalisearjen fan wurk oan 'e kant fan' e hjoeddeistige opslach.
Diel 1: Faith in Tableau
Foar it ferienfâldigjen fan IT-stipe en fluch wizigingen útfiere, hawwe wy besletten om de logika te meitsjen foar it berekkenjen fan net-additive yndikatoaren en it fergelykjen fan ferline perioaden yn Tableau.
Stage 1. Alles is Live, gjin finster modifikaasjes.
Op dit stadium hawwe wy Tableau ferbûn oan 'e hjoeddeistige winkelfronten en besletten om te sjen hoe't it oantal ûntfangsten foar ien jier soe wurde berekkene.
Resultaat:
It antwurd wie deprimearjend - 20 minuten. It oerdragen fan gegevens oer it netwurk, hege lading op Tableau. Wy realisearre dat logika mei net-additive yndikatoaren moatte wurde ymplementearre op HANA. Dit makke ús net folle bang, wy hienen al ferlykbere ûnderfining mei BO en Analysis en wy wisten hoe't wy snelle showcases bouwe yn HANA dy't korrekt berekkene net-additive yndikatoaren produsearje. No wie alles oerbleaun om se oan te passen oan Tableau.
Fase 2. Wy tune de display gefallen, gjin materialization, alles op 'e flecht.
Wy hawwe in aparte nije showcase makke dy't de fereaske gegevens produsearre foar TABLEAU on the fly. Yn 't algemien krigen wy in goed resultaat; wy fermindere de tiid foar it generearjen fan alle yndikatoaren yn ien wike nei 9-10 sekonden. En wy hawwe earlik ferwachte dat yn Tableau de reaksjetiid fan it dashboard 20-30 sekonden wêze soe by de earste iepening en dan troch de cache fan 10 nei 12, dy't yn 't algemien ús passe.
Resultaat:
Earste iepen dashboard: 4-5 minuten
Elke klik: 3-4 minuten
Gjinien ferwachte sa'n ekstra ferheging fan it wurk fan de winkel.
Diel 2. Dûk yn Tableau
Stage 1. Tableau prestaasjes analyze en flugge tuning
Wy begon te analysearjen wêr't Tableau it measte fan syn tiid trochbringt. En d'r binne heul goede ark foar dit, wat, fansels, in plus fan Tableau is. It wichtichste probleem dat wy identifisearre wie de heul komplekse SQL-fragen dy't Tableau boude. Se waarden benammen ferbûn mei:
- gegevens oerdracht. Sûnt Tableau gjin ark hat foar it transponearjen fan datasets, om de linkerkant fan it dashboard te bouwen mei in detaillearre fertsjintwurdiging fan alle KPI's, moasten wy in tabel meitsje mei in saak. De grutte fan SQL-fragen yn 'e databank berikte 120 tekens.
- kar fan tiid perioade. Sa'n query op it databanknivo naam mear tiid om te kompilearjen dan út te fieren:
Dy. fersyk ferwurkjen 12 sekonden + 5 sekonden útfiering.
Wy besletten om te ferienfâldigjen de berekkening logika oan de Tableau kant en ferpleatse in oar part fan de berekkeningen oan de winkel en databank nivo. Dit brocht goede resultaten.
Earst diene wy de transposysje op 'e flecht, wy diene it troch in folsleine bûtenste join yn' e lêste faze fan 'e VIEW-berekkening, neffens dizze oanpak beskreaun op' e wiki и .
Dat is, wy makken in ynstellingstafel - in transposysjematrix (21x21) en krigen alle yndikatoaren yn in rige-foar-rige-yndieling.
wie:
It waard:
Der wurdt hast gjin tiid bestege oan de databanktransposysje sels. It fersyk foar alle yndikatoaren foar de wike bleau yn sawat 10 sekonden ferwurke. Mar oan 'e oare kant is fleksibiliteit ferlern gien yn termen fan it bouwen fan in dashboard basearre op in spesifike yndikator, d.w.s. foar de rjochterkant fan it dashboard wêr't de dynamyk en detaillearre ferdieling fan in spesifike yndikator wurde presintearre, earder wurke it display yn 1-3 sekonden, om't it fersyk wie basearre op ien yndikator, en no selektearre de databank altyd alle yndikatoaren en filtere it resultaat foardat it werombringen fan it resultaat nei Tableau.
As gefolch, de snelheid fan it dashboard sakke mei hast 3 kear.
Resultaat:
- 5 sekonden - parsearjen fan dashboards, fisualisaasjes
- 15-20 sekonden - tarieding foar it kompilearjen fan fragen mei it útfieren fan pre-berekkeningen yn Tableau
- 35-45 sek - kompilaasje fan SQL-queries en har parallel-sekwinsjele útfiering yn Hana
- 5 sek - resultaten ferwurkjen, sortearjen, werrekkenjen fan fisualisaasjes yn Tableau
- Fansels pasten sokke resultaten net by it bedriuw, en wy bleauwen optimalisearje.
Stage 2. Minimum logika yn Tableau, folsleine materialization
Wy begrepen dat it ûnmooglik wie om in dashboard te bouwen mei in reaksjetiid fan ferskate sekonden op in winkel dy't 10 sekonden rint, en wy beskôgje opsjes foar it materialisearjen fan gegevens op 'e databankkant spesifyk foar it fereaske dashboard. Mar wy tsjinkamen in globaal probleem beskreaun hjirboppe - net-additive yndikatoaren. Wy koenen der net foar soargje dat by it feroarjen fan filters of drilldowns, Tableau fleksibel skeakele tusken ferskate winkelfronten en nivo's foarôf ûntwurpen foar ferskate produkthierarchyen (yn it foarbyld generearje trije queries sûnder UTE, mei UTE1 en UTE2 ferskillende resultaten). Dêrom besleaten wy it dashboard te ferienfâldigjen, de produkthiërargy yn it dashboard te ferlitten en te sjen hoe fluch it koe wêze yn in ferienfâldige ferzje.
Dat, yn dit lêste stadium, hawwe wy in apart repository gearstald wêryn wy alle KPI's yn transponearre foarm tafoege. Oan 'e databankkant wurdt elk fersyk nei sa'n opslach ferwurke yn 0,1 - 0,3 sekonden. Yn it dashboard krigen wy de folgjende resultaten:
Earste iepening: 8-10 sekonden
Elke klik: 6-7 sekonden
De tiid bestege troch Tableau bestiet út:
- 0,3 sek. - parsing en kompilaasje fan dashboard fan SQL-fragen
- 1,5-3 sek. - útfiering fan SQL-fragen yn Hana foar haadfisualisaasjes (rint parallel mei stap 1)
- 1,5-2 sek. - rendering, herberekkening fan fisualisaasjes
- 1,3 sek. - útfiering fan ekstra SQL-fragen om relevante filterwearden te krijen (merk, divyzje, stêd, winkel), resultaten analysearje
Om it koart te summjen
Wy hâlde fan it Tableau-ark út in fisualisaasjeperspektyf. Yn it prototypingstadium hawwe wy ferskate fisualisaasjeeleminten beskôge en fûnen se allegear yn biblioteken, ynklusyf komplekse segmentaasje op meardere nivo's en wetterfal mei meardere bestjoerders.
By it ymplementearjen fan dashboards mei wichtige ferkeapyndikatoaren, tsjinkamen wy prestaasjesproblemen dy't wy noch net kinne oerwinne. Wy hawwe mear as twa moannen trochbrocht en krigen in funksjoneel ûnfolslein dashboard, wêrfan de reaksjesnelheid op 'e râne fan akseptabel is. En wy lutsen konklúzjes foar ússels:
- Tableau kin net wurkje mei grutte hoemannichten gegevens. As jo yn it orizjinele gegevensmodel mear as 10 GB oan gegevens hawwe (likernôch 200 miljoen X 50 rigen), dan sil it dashboard serieus fertrage - fan 10 sekonden oant ferskate minuten foar elke klik. Wy eksperiminteare mei sawol live-connect as extract. De operaasje snelheid is fergelykber.
- Beheining by it brûken fan meardere opslach (datasets). D'r is gjin manier om de relaasje tusken datasetten oan te jaan mei standertmiddels. As jo oplossingen brûke om datasetten te ferbinen, sil dit in protte ynfloed hawwe op prestaasjes. Yn ús gefal hawwe wy de opsje beskôge om gegevens yn elke fereaske werjefteseksje te materialisearjen en skeakels te meitsjen op dizze materialisearre datasets, wylst de earder selektearre filters behâlden wurde - dit die bliken ûnmooglik te dwaan yn Tableau.
- It is net mooglik om dynamyske parameters te meitsjen yn Tableau. Jo kinne gjin parameter ynfolje dy't brûkt wurdt om in dataset te filterjen yn in extract of tidens in live-connecte mei it resultaat fan in oare seleksje út 'e dataset of it resultaat fan in oare SQL-query, allinich native brûkersynput of in konstante.
- Beheinings ferbûn mei it bouwen fan in dashboard mei OLAP|PivotTable-eleminten.
Yn MSTR, SAP SAC, SAP Analysis, as jo in dataset tafoegje oan in rapport, dan binne alle objekten dêrop standert relatearre oan elkoar. Tableau hat dit net; de ferbining moat mei de hân konfigurearre wurde. Dit is wierskynlik fleksibeler, mar foar al ús dashboards is dit in ferplichte eask foar eleminten - dus dit binne ekstra arbeidskosten. Boppedat, as jo besibbe filters meitsje sadat, bygelyks, by it filterjen fan in regio, de list mei stêden allinich beheind is ta de stêden fan dizze regio, dan komme jo daliks mei opienfolgjende fragen nei de databank of Extract, wat de dashboard. - Beheinings yn funksjes. Massatransformaasjes kinne net dien wurde op it úttreksel of, BESAL, op 'e dataset fan Live-connecta. Dit kin dien wurde fia Tableau Prep, mar it is ekstra wurk en in oar ark om te learen en te ûnderhâlden. Jo kinne bygelyks gegevens net transponearje of gearwurkje mei harsels. Wat wurdt sletten troch transformaasjes op yndividuele kolommen of fjilden, dy't moatte wurde selektearre troch gefal of as, en dit genereart tige komplekse SQL-fragen, wêryn de databank it measte fan har tiid besteget oan it kompilearjen fan de querytekst. Dizze ûnfleksibiliteit fan it ark moast wurde oplost op it showcase-nivo, wat liedt ta kompleksere opslach, ekstra downloads en transformaasjes.
Wy hawwe it Tableau net opjûn. Mar wy beskôgje Tableau net as in ark dat by steat is om yndustriële dashboards te bouwen en in ark wêrmei't it hiele bedriuwsrapportsysteem fan in bedriuw kin ferfange en digitalisearje.
Wy ûntwikkelje no aktyf in ferlykber dashboard yn in oar ark en besykje tagelyk de dashboard-arsjitektuer yn Tableau te feroarjen om it noch mear te ferienfâldigjen. As de mienskip ynteressearre is, sille wy jo fertelle oer de resultaten.
Wy wachtsje ek op jo ideeën of advys oer hoe't jo yn Tabeau rappe dashboards kinne bouwe oer sokke grutte folumes fan gegevens, om't wy in webside hawwe wêr't folle mear gegevens binne as yn detailhannel.
Boarne: www.habr.com