La tempo por raporti en Excel rapide malaperas - la tendenco al oportunaj iloj por prezenti kaj analizi informojn estas videbla en ĉiuj areoj. Ni longe diskutas interne pri la ciferecigo de raportado kaj elektis la tablo-bildigon kaj memservan analizan sistemon. Alexander Bezugly, estro de la fako pri analizaj solvoj kaj raportado de la Grupo M.Video-Eldorado, parolis pri la sperto kaj rezultoj de konstruado de batalpanelo.
Mi tuj diros, ke ne ĉio, kio estis planita, realiĝis, sed la sperto estis interesa, mi esperas, ke ĝi estos utila ankaŭ al vi. Kaj se iu havas ideojn pri kiel oni povus fari ĝin pli bone, mi tre dankus viajn konsilojn kaj ideojn.
Sub la tranĉo temas pri tio, kion ni renkontis kaj pri kio ni lernis.
De kie ni komencis?
M.Video-Eldorado havas bonevoluintan datummodelon: strukturita informo kun la bezonata stoka profundo kaj grandega nombro da fiksformaj raportoj (vidu pli da detaloj ). El ĉi tiuj analizistoj faras aŭ pivotajn tabelojn aŭ formatitajn bultenojn en Excel, aŭ belajn PowerPoint-prezentojn por finaj uzantoj.
Antaŭ proksimume du jaroj, anstataŭ fiksformaj raportoj, ni komencis krei analizajn raportojn en SAP-Analizo (aldonaĵo de Excel, esence pivota tablo super la OLAP-motoro). Sed ĉi tiu ilo ne povis renkonti la bezonojn de ĉiuj uzantoj; la plimulto daŭre uzis informojn aldone prilaboritajn de analizistoj.
Niaj finaj uzantoj kategoriiĝas en tri kategorioj:
Plej alta administrado. Petas informojn en bone prezentita kaj klare komprenebla maniero.
Meza administrado, progresintaj uzantoj. Interesas pri datumesplorado kaj kapablas sendepende konstrui raportojn se iloj disponeblas. Ili iĝis la ĉefaj uzantoj de analizaj raportoj en SAP-Analizo.
Amasaj uzantoj. Ili ne interesiĝas pri sendepende analizi datumojn; ili uzas raportojn kun limigita grado de libereco, en la formato de bultenoj kaj pivottabeloj en Excel.
Nia ideo estis kovri la bezonojn de ĉiuj uzantoj kaj doni al ili ununuran oportunan ilon. Ni decidis komenci per supera administrado. Ili bezonis facile uzeblajn panelojn por analizi ŝlosilajn komercajn rezultojn. Do, ni komencis kun Tableau kaj unue elektis du direktojn: podetalaj kaj interretaj vendaj indikiloj kun limigita profundeco kaj amplekso de analizo, kiuj kovrus proksimume 80% de la datumoj petitaj de supera administrado.
Ĉar la uzantoj de la paneloj estis supera administrado, aperis alia plia KPI de la produkto - respondrapideco. Neniu atendos 20-30 sekundojn por ke la datumoj estos ĝisdatigitaj. Navigado devus esti farita ene de 4-5 sekundoj, aŭ pli bone, tuj farita. Kaj ni, ve, ne sukcesis tion atingi.
Jen kiel aspektis la aranĝo de nia ĉefa panelo:
La ŝlosila ideo estas kombini la ĉefajn KPI-ŝoforojn, el kiuj estis 19 entute, maldekstre kaj prezenti ilian dinamikon kaj rompon per ĉefaj atributoj dekstre. La tasko ŝajnas simpla, la bildigo estas logika kaj komprenebla, ĝis vi plonĝas en la detalojn.
Detalo 1. Volumo de datumoj
Nia ĉefa tablo por ĉiujaraj vendoj okupas ĉirkaŭ 300 milionojn da vicoj. Ĉar necesas reflekti la dinamikon por la lasta jaro kaj la antaŭa jaro, la volumo de datumoj nur pri realaj vendoj estas ĉirkaŭ 1 miliardo da linioj. Informoj pri planitaj datumoj kaj la reta venda bloko ankaŭ estas konservitaj aparte. Sekve, kvankam ni uzis la kolonan en-memoran DB SAP HANA, la rapideco de la demando kun la elekto de ĉiuj indikiloj dum unu semajno el la nuna stokado sur la flugo estis ĉirkaŭ 15-20 sekundoj. La solvo de ĉi tiu problemo sugestas sin - plia materiigo de datumoj. Sed ĝi ankaŭ havas malfacilaĵojn, pli pri ili sube.
Detalo 2. Ne-aldonaj indikiloj
Multaj el niaj KPI-oj estas ligitaj al la nombro da kvitancoj. Kaj ĉi tiu indikilo reprezentas COUNT DISTINCT de la nombro da vicoj (kontrolu kapliniojn) kaj montras malsamajn kvantojn depende de la elektitaj atributoj. Ekzemple, kiel ĉi tiu indikilo kaj ĝia derivaĵo devus esti kalkulitaj:
Por korekti viajn kalkulojn, vi povas:
- Kalkulu tiajn indikilojn sur la muŝo en la stokado;
- Faru kalkulojn pri la tuta volumo de datumoj en Tableau, t.e. laŭ peto en Tableau, provizu ĉiujn datumojn laŭ elektitaj filtriloj en la granulareco de la kvitanca pozicio;
- Kreu materiigitan montrofenestron, en kiu ĉiuj indikiloj estos kalkulitaj en ĉiuj specimenaj elektoj, kiuj donas malsamajn ne-aldonajn rezultojn.
Estas klare, ke en la ekzemplo UTE1 kaj UTE2 estas materialaj atributoj reprezentantaj la produktohierarkion. Ĉi tio ne estas senmova afero; administrado ene de la kompanio okazas per ĝi, ĉar Malsamaj administrantoj respondecas pri malsamaj produktgrupoj. Ni havis multajn tutmondajn reviziojn de ĉi tiu hierarkio, kiam ĉiuj niveloj ŝanĝiĝis, kiam rilatoj estis reviziitaj, kaj konstantaj punktoŝanĝoj, kiam unu grupo moviĝis de unu nodo al alia. En konvencia raportado, ĉio ĉi estas kalkulita sur la flugo el la atributoj de la materialo; en la kazo de materialiĝo de ĉi tiuj datumoj, necesas evoluigi mekanismon por spuri tiajn ŝanĝojn kaj aŭtomate reŝargi historiajn datumojn. Tre ne-triviala tasko.
Detalo 3. Komparo de datumoj
Ĉi tiu punkto estas simila al la antaŭa. La fundo estas, ke kiam oni analizas kompanion, estas kutime formi plurajn nivelojn de komparo kun la antaŭa periodo:
Komparo kun la antaŭa periodo (tago al tago, semajno al semajno, monato al monato)
En ĉi tiu komparo, oni supozas, ke depende de la periodo elektita de la uzanto (ekzemple, la 33-a semajno de la jaro), ni devus montri la dinamikon ĝis la 32-a semajno; se ni elektas datumojn por monato, ekzemple, majo. , tiam ĉi tiu komparo montrus la dinamikon antaŭ aprilo.
Komparo kun la pasinta jaro
La ĉefa nuanco ĉi tie estas, ke kiam oni komparas laŭ tago kaj semajno, oni ne prenas la saman tagon de la pasinta jaro, t.e. oni ne povas simple meti la nunan jaron minus unu. Vi devas rigardi la semajnotagon, kiun vi komparas. Komparante monatojn, male, vi devas preni ĝuste la saman kalendaran tagon de la pasinta jaro. Estas ankaŭ nuancoj kun superjaroj. En la originaj deponejoj, ĉiuj informoj estas distribuitaj tage; ekzistas neniuj apartaj kampoj kun semajnoj, monatoj aŭ jaroj. Tial, por akiri kompletan analizan sekcon en la panelo, vi devas kalkuli ne unu periodon, ekzemple semajne, sed 4 semajnojn, kaj poste kompari ĉi tiujn datumojn, reflekti la dinamikon, deviojn. Sekve, ĉi tiu logiko por generi komparojn en dinamiko ankaŭ povas esti efektivigita aŭ en Tableau aŭ ĉe la butikfasado. Jes, kaj kompreneble ni sciis kaj pensis pri ĉi tiuj detaloj en la fazo de dezajno, sed estis malfacile antaŭdiri ilian efikon al la agado de la fina panelo.
Dum la efektivigo de la panelo, ni sekvis la longan Agile vojon. Nia tasko estis provizi laborilon kun la necesaj datumoj por testado kiel eble plej rapide. Sekve, ni iris en sprintoj kaj komencis de minimumigo de laboro flanke de la nuna stokado.
Parto 1: Fido al Tablo
Por simpligi IT-subtenon kaj rapide efektivigi ŝanĝojn, ni decidis fari la logikon por kalkuli nealdonajn indikilojn kaj kompari pasintajn periodojn en Tableau.
Etapo 1. Ĉio estas Viva, neniuj fenestraj modifoj.
En ĉi tiu etapo, ni konektis Tableaun al la nunaj vendejoj kaj decidis vidi kiel la nombro da kvitancoj por unu jaro estos kalkulita.
Rezulto:
La respondo estis malĝojiga - 20 minutoj. Transdono de datumoj tra la reto, alta ŝarĝo sur Tableau. Ni rimarkis, ke logiko kun ne-aldonaj indikiloj devas esti efektivigita sur HANA. Ĉi tio ne multe timigis nin, ni jam havis similan sperton kun BO kaj Analizo kaj ni sciis kiel konstrui rapidajn montrofenestrojn en HANA, kiuj produktas ĝuste kalkulitajn ne-aldonajn indikilojn. Nun restis nur alĝustigi ilin al Tableau.
Etapo 2. Ni agordas la ekranujojn, neniun materiigon, ĉio sur la flugo.
Ni kreis apartan novan montrofenestron kiu produktis la postulatajn datumojn por TABLEAU sur la flugo. Ĝenerale, ni ricevis bonan rezulton; ni reduktis la tempon por generi ĉiujn indikilojn en unu semajno al 9-10 sekundoj. Kaj ni honeste atendis, ke en Tableau la respondtempo de la panelo estus 20-30 sekundoj ĉe la unua malfermo kaj poste pro la kaŝmemoro de 10 ĝis 12, kio ĝenerale konvenus al ni.
Rezulto:
Unua malferma panelo: 4-5 minutoj
Ajna klako: 3-4 minutoj
Neniu atendis tian plian kreskon de la laboro de la vendejo.
Parto 2. Plonĝu en Tablon
Etapo 1. Tabla agado-analizo kaj rapida agordado
Ni komencis analizi kie Tableau pasigas la plej grandan parton de sia tempo. Kaj ekzistas sufiĉe bonaj iloj por ĉi tio, kio, kompreneble, estas pluso de Tableau. La ĉefa problemo, kiun ni identigis, estis la tre kompleksaj SQL-demandoj, kiujn Tableau konstruis. Ili estis ĉefe asociitaj kun:
— transigo de datumoj. Ĉar Tableau ne havas ilojn por transponado de datumaroj, por konstrui la maldekstran flankon de la panelo kun detala reprezentado de ĉiuj KPIoj, ni devis krei tabelon uzante kazon. La grandeco de SQL-demandoj en la datumbazo atingis 120 karakterojn.
- elekto de tempoperiodo. Tia demando ĉe la datumbaza nivelo prenis pli da tempo por kompili ol por efektivigi:
Tiuj. peto prilaborado 12 sekundoj + 5 sekundoj ekzekuto.
Ni decidis simpligi la kalkullogikon ĉe la flanko de Tableau kaj movi alian parton de la kalkuloj al la vendejo kaj datumbaza nivelo. Ĉi tio alportis bonajn rezultojn.
Unue, ni faris la transponon sur la flugo, ni faris ĝin per plena ekstera kunigo ĉe la fina etapo de la kalkulo VIEW, laŭ ĉi tiu aliro priskribita en la vikio. и .
Tio estas, ni faris agordan tablon - transponan matricon (21x21) kaj ricevis ĉiujn indikilojn en vico-post-vica disrompo.
Estis:
Ĝi fariĝis:
Preskaŭ neniu tempo estas elspezita por la datumbaza transponado mem. La peto por ĉiuj indikiloj por la semajno daŭre estis procesita en ĉirkaŭ 10 sekundoj. Sed aliflanke, fleksebleco estis perdita en terminoj de konstruado de instrumentpanelo bazita sur specifa indikilo, t.e. por la dekstra flanko de la panelo, kie la dinamiko kaj detala rompo de specifa indikilo estas prezentitaj, antaŭe la vitrino funkciis en 1-3 sekundoj, ĉar la peto baziĝis sur unu indikilo, kaj nun la datumbazo ĉiam elektis ĉiujn indikilojn kaj filtris la rezulton antaŭ redoni la rezulton al Tableau.
Kiel rezulto, la rapideco de la panelo malpliiĝis preskaŭ 3 fojojn.
Rezulto:
- 5 sek - analizaj paneloj, bildigoj
- 15-20 sekundoj - preparo por kompili demandojn kun farado de antaŭkalkuloj en Tableau
- 35-45 sek - kompilo de SQL-demandoj kaj ilia paralel-sinsekva ekzekuto en Hana
- 5 sek - prilaborado de rezultoj, ordigo, rekalkulado de bildigoj en Tableau
- Kompreneble, tiaj rezultoj ne konvenis al la komerco, kaj ni daŭrigis optimumigon.
Etapo 2. Minimuma logiko en Tableau, kompleta materiigo
Ni komprenis, ke estas neeble konstrui panelon kun responda tempo de pluraj sekundoj sur vendejo kiu funkcias dum 10 sekundoj, kaj ni pripensis eblojn por materiigi datumojn sur la datumbazo specife por la bezonata panelo. Sed ni renkontis tutmondan problemon priskribitan supre - ne-aldonajn indikilojn. Ni ne povis certigi, ke dum ŝanĝado de filtriloj aŭ drilldowns, Tableau flekseble ŝanĝis inter malsamaj butikfasadoj kaj niveloj antaŭdizajnitaj por malsamaj produktaj hierarkioj (en la ekzemplo, tri demandoj sen UTE, kun UTE1 kaj UTE2 generas malsamajn rezultojn). Tial ni decidis simpligi la panelon, forlasi la produktan hierarkion en la panelo kaj vidi kiom rapide ĝi povus esti en simpligita versio.
Do, en ĉi tiu lasta etapo, ni kunvenis apartan deponejon, en kiu ni aldonis ĉiujn KPIojn en transmetita formo. Sur la datumbazo, ajna peto al tia stokado estas procesita en 0,1 - 0,3 sekundoj. En la panelo ni ricevis la sekvajn rezultojn:
Unua malfermo: 8-10 sekundoj
Ajna klako: 6-7 sekundoj
La tempo pasigita de Tableau konsistas el:
- 0,3 sek. — panela analizado kaj kompilo de SQL-demandoj
- 1,5-3 sek. - plenumo de SQL-demandoj en Hana por ĉefaj bildigoj (funkcias paralele kun paŝo 1)
- 1,5-2 sek. — bildigo, rekalkulo de bildigoj
- 1,3 sek. - plenumo de pliaj SQL-demandoj por akiri rilatajn filtrilvalorojn (Marko, Divido, Urbo, Vendejo), analizaj rezultoj
Por resumi ĝin mallonge
Ni ŝatis la ilon Tableau el vidperspektivo. En la prototipa etapo, ni konsideris diversajn bildigajn elementojn kaj trovis ilin ĉiujn en bibliotekoj, inkluzive de kompleksa plurnivela segmentado kaj plur-ŝofora akvofalo.
Dum efektivigado de paneloj kun ŝlosilaj vendaj indikiloj, ni renkontis rendimentajn malfacilaĵojn, kiujn ni ankoraŭ ne povis venki. Ni pasigis pli ol du monatojn kaj ricevis funkcie nekompletan panelon, kies respondrapideco estas akceptebla. Kaj ni mem eltiris konkludojn:
- Tableau ne povas funkcii kun grandaj kvantoj da datumoj. Se en la originala datummodelo vi havas pli ol 10 GB da datumoj (ĉirkaŭ 200 milionoj X 50 vicoj), tiam la panelo serioze malrapidiĝos - de 10 sekundoj ĝis pluraj minutoj por ĉiu klako. Ni eksperimentis per viva-konekto kaj eltiraĵo. La operacia rapideco estas komparebla.
- Limigo dum uzado de multoblaj stokadoj (datumaro). Ne estas maniero indiki la rilaton inter datumaroj uzante normajn rimedojn. Se vi uzas solvojn por konekti datumojn, tio multe influos rendimenton. En nia kazo, ni konsideris la eblon materiigi datumojn en ĉiu bezonata vido-sekcio kaj fari ŝalti tiujn materiigitajn datumarojn konservante la antaŭe elektitajn filtrilojn - tio montriĝis neeble fari en Tableau.
- Ne eblas fari dinamikajn parametrojn en Tableau. Vi ne povas plenigi parametron, kiu estas uzata por filtri datumaron en ekstrakto aŭ dum viva konekto kun la rezulto de alia elekto el la datumaro aŭ la rezulto de alia SQL-demando, nur denaska uzanta enigo aŭ konstanto.
- Limigoj asociitaj kun konstruado de panelo kun elementoj OLAP|PivotTable.
En MSTR, SAP SAC, SAP-Analizo, se vi aldonas datumaron al raporto, tiam ĉiuj objektoj sur ĝi rilatas unu al la alia defaŭlte. Tableau ne havas ĉi tion; la konekto devas esti agordita permane. Ĉi tio verŝajne estas pli fleksebla, sed por ĉiuj niaj paneloj tio estas deviga postulo por elementoj - do tio estas pliaj laborkostoj. Cetere, se vi faras rilatajn filtrilojn tiel ke, ekzemple, kiam filtras regionon, la listo de urboj estas limigita nur al la urboj de ĉi tiu regiono, vi tuj finiĝas kun sinsekvaj demandoj al la datumbazo aŭ Ekstrakto, kiu rimarkeble malrapidigas la panelo. - Limigoj en funkcioj. Amasaj transformoj ne povas esti faritaj nek sur la eltiraĵo nek, PREFEE, sur la datumaro de Live-connecta. Ĉi tio povas esti farita per Tableau Prep, sed ĝi estas plia laboro kaj alia ilo por lerni kaj konservi. Ekzemple, vi ne povas transmeti datumojn aŭ kunigi ĝin kun si mem. Kio estas fermita per transformoj sur unuopaj kolumnoj aŭ kampoj, kiuj devas esti elektitaj per kazo aŭ se, kaj tio generas tre kompleksajn SQL-demandojn, en kiuj la datumbazo pasigas la plej grandan parton de sia tempo kompilante la demandan tekston. Ĉi tiuj neflekseblecoj de la ilo devis esti solvitaj ĉe la montrofenestro, kio kondukas al pli kompleksa stokado, pliaj elŝutoj kaj transformoj.
Ni ne rezignis pri Tableau. Sed ni ne konsideras Tableau kiel ilon kapabla konstrui industriajn instrumentpanelojn kaj ilon per kiu anstataŭigi kaj ciferecigi la tutan kompanian raportsistemon de kompanio.
Ni nun aktive disvolvas similan panelon en alia ilo kaj, samtempe, provas revizii la panelarkitekturon en Tableau por simpligi ĝin eĉ pli. Se la komunumo interesiĝas, ni rakontos al vi pri la rezultoj.
Ni ankaŭ atendas viajn ideojn aŭ konsilojn pri kiel en Tabeau vi povas konstrui rapidajn instrumentpanelojn super tiom grandaj volumoj da datumoj, ĉar ni havas retejon, kie estas multe pli da datumoj ol en podetala komerco.
fonto: www.habr.com