Ang oras para sa pag-uulat sa Excel ay mabilis na nawawala - ang trend patungo sa maginhawang mga tool para sa pagpapakita at pagsusuri ng impormasyon ay makikita sa lahat ng mga lugar. Panloob naming tinatalakay ang digitalization ng pag-uulat sa loob ng mahabang panahon at pinili ang Tableau visualization at self-service analytics system. Si Alexander Bezugly, pinuno ng analytical solutions at reporting department ng M.Video-Eldorado Group, ay nagsalita tungkol sa karanasan at resulta ng pagbuo ng combat dashboard.
Sasabihin ko kaagad na hindi lahat ng binalak ay natupad, ngunit ang karanasan ay kawili-wili, umaasa ako na ito ay magiging kapaki-pakinabang din sa iyo. At kung sinuman ang may anumang mga ideya kung paano ito magagawa nang mas mahusay, ako ay lubos na nagpapasalamat para sa iyong mga payo at ideya.
Sa ibaba ng hiwa ay tungkol sa kung ano ang aming nakatagpo at kung ano ang aming natutunan.
Saan tayo nagsimula?
Ang M.Video-Eldorado ay may isang mahusay na binuo na modelo ng data: nakabalangkas na impormasyon na may kinakailangang lalim ng storage at isang malaking bilang ng mga fixed-form na ulat (tingnan ang higit pang mga detalye ). Mula sa mga ito, gumagawa ang mga analyst ng alinman sa mga pivot table o mga naka-format na newsletter sa Excel, o mga magagandang PowerPoint presentation para sa mga end user.
Humigit-kumulang dalawang taon na ang nakalipas, sa halip na mga fixed-form na ulat, nagsimula kaming gumawa ng mga analytical na ulat sa SAP Analysis (isang Excel add-on, na isang pivot table sa ibabaw ng OLAP engine). Ngunit ang tool na ito ay hindi natugunan ang mga pangangailangan ng lahat ng mga gumagamit; ang karamihan ay patuloy na gumagamit ng impormasyon na pinoproseso din ng mga analyst.
Ang aming mga end user ay nahahati sa tatlong kategorya:
Nangungunang pamamahala. Humihiling ng impormasyon sa isang mahusay na ipinakita at malinaw na nauunawaan na paraan.
Gitnang pamamahala, mga advanced na user. Interesado sa paggalugad ng data at nakapag-iisa na bumuo ng mga ulat kung available ang mga tool. Sila ang naging pangunahing gumagamit ng analytical na ulat sa SAP Analysis.
Mass users. Hindi sila interesado sa hiwalay na pagsusuri ng data; gumagamit sila ng mga ulat na may limitadong antas ng kalayaan, sa format ng mga newsletter at pivot table sa Excel.
Ang aming ideya ay upang matugunan ang mga pangangailangan ng lahat ng mga gumagamit at bigyan sila ng isang solong, maginhawang tool. Nagpasya kaming magsimula sa nangungunang pamamahala. Kailangan nila ng mga dashboard na madaling gamitin para pag-aralan ang mga pangunahing resulta ng negosyo. Kaya, nagsimula kami sa Tableau at unang pumili ng dalawang direksyon: mga tagapagpahiwatig ng retail at online na benta na may limitadong lalim at lawak ng pagsusuri, na sasakupin ang humigit-kumulang 80% ng data na hinihiling ng nangungunang pamamahala.
Dahil ang mga gumagamit ng mga dashboard ay nangungunang pamamahala, isa pang karagdagang KPI ng produkto ang lumitaw - bilis ng pagtugon. Walang maghihintay ng 20-30 segundo para ma-update ang data. Navigation dapat ay tapos na sa loob ng 4-5 segundo, o mas mabuti pa, tapos na agad. At kami, sayang, nabigo upang makamit ito.
Ganito ang hitsura ng layout ng aming pangunahing dashboard:
Ang pangunahing ideya ay pagsamahin ang mga pangunahing driver ng KPI, kung saan mayroong 19 sa kabuuan, sa kaliwa at ipakita ang kanilang mga dinamika at pagkasira ayon sa mga pangunahing katangian sa kanan. Ang gawain ay tila simple, ang visualization ay lohikal at naiintindihan, hanggang sa sumisid ka sa mga detalye.
Detalye 1. Dami ng data
Ang aming pangunahing talahanayan para sa taunang mga benta ay tumatagal ng humigit-kumulang 300 milyong mga hilera. Dahil kinakailangang ipakita ang dynamics para sa nakaraang taon at sa nakaraang taon, ang dami ng data sa aktwal na mga benta lamang ay humigit-kumulang 1 bilyong linya. Ang impormasyon sa nakaplanong data at ang online na bloke ng pagbebenta ay nakaimbak din nang hiwalay. Samakatuwid, kahit na ginamit namin ang columnar in-memory na DB SAP HANA, ang bilis ng query sa pagpili ng lahat ng indicator para sa isang linggo mula sa kasalukuyang storage on the fly ay humigit-kumulang 15-20 segundo. Ang solusyon sa problemang ito ay nagmumungkahi mismo - karagdagang materyalisasyon ng data. Ngunit mayroon din itong mga pitfalls, higit pa tungkol sa mga ito sa ibaba.
Detalye 2. Non-additive indicators
Marami sa aming mga KPI ay nakatali sa bilang ng mga resibo. At ang indicator na ito ay kumakatawan sa COUNT DISTINCT ng bilang ng mga row (check header) at nagpapakita ng iba't ibang halaga depende sa mga napiling attribute. Halimbawa, kung paano dapat kalkulahin ang indicator na ito at ang derivative nito:
Upang gawing tama ang iyong mga kalkulasyon, maaari mong:
- Kalkulahin ang mga naturang tagapagpahiwatig sa mabilisang imbakan;
- Magsagawa ng mga kalkulasyon sa buong dami ng data sa Tableau, i.e. kapag hiniling sa Tableau, ibigay ang lahat ng data ayon sa mga napiling filter sa granularity ng posisyon ng resibo;
- Gumawa ng materialized showcase kung saan kakalkulahin ang lahat ng indicator sa lahat ng sample na opsyon na nagbibigay ng iba't ibang resulta na hindi additive.
Malinaw na sa halimbawa ang UTE1 at UTE2 ay mga materyal na katangian na kumakatawan sa hierarchy ng produkto. Ito ay hindi isang static na bagay; ang pamamahala sa loob ng kumpanya ay nagaganap sa pamamagitan nito, dahil Iba't ibang tagapamahala ang may pananagutan para sa iba't ibang pangkat ng produkto. Nagkaroon kami ng maraming pandaigdigang rebisyon ng hierarchy na ito, noong nagbago ang lahat ng antas, noong binago ang mga ugnayan, at nagbabago ang mga punto, nang lumipat ang isang grupo mula sa isang node patungo sa isa pa. Sa maginoo na pag-uulat, ang lahat ng ito ay kinakalkula sa mabilisang mula sa mga katangian ng materyal; sa kaso ng materyalisasyon ng data na ito, kinakailangan upang bumuo ng isang mekanismo para sa pagsubaybay sa mga naturang pagbabago at awtomatikong i-reload ang makasaysayang data. Isang napaka walang kuwentang gawain.
Detalye 3. Paghahambing ng datos
Ang puntong ito ay katulad ng nauna. Ang ilalim na linya ay kapag pinag-aaralan ang isang kumpanya, kaugalian na bumuo ng ilang mga antas ng paghahambing sa nakaraang panahon:
Paghahambing sa nakaraang panahon (araw-araw, linggo-linggo, buwan-buwan)
Sa paghahambing na ito, ipinapalagay na depende sa panahon na pinili ng user (halimbawa, ang ika-33 linggo ng taon), dapat naming ipakita ang dynamics sa ika-32 linggo; kung pinili namin ang data para sa isang buwan, halimbawa, Mayo , pagkatapos ay ipapakita ng paghahambing na ito ang dynamics sa Abril.
Paghahambing sa nakaraang taon
Ang pangunahing nuance dito ay na kapag inihambing sa araw at sa pamamagitan ng linggo, hindi ka kumukuha ng parehong araw ng nakaraang taon, i.e. hindi mo na lang ilagay ang kasalukuyang taon na minus one. Dapat mong tingnan ang araw ng linggo na iyong inihahambing. Kapag naghahambing ng mga buwan, sa kabaligtaran, kailangan mong kunin ang eksaktong parehong araw ng kalendaryo ng nakaraang taon. Mayroon ding mga nuances na may mga taon ng paglukso. Sa orihinal na mga repositoryo, ang lahat ng impormasyon ay ipinamamahagi ayon sa araw; walang hiwalay na mga field na may mga linggo, buwan, o taon. Samakatuwid, upang makakuha ng isang kumpletong analytical cross-section sa panel, kailangan mong magbilang ng hindi isang panahon, halimbawa sa isang linggo, ngunit 4 na linggo, at pagkatapos ay ihambing ang mga data na ito, sumasalamin sa dynamics, deviations. Alinsunod dito, ang lohika na ito para sa pagbuo ng mga paghahambing sa dynamics ay maaari ding ipatupad alinman sa Tableau o sa gilid ng storefront. Oo, at siyempre alam at naisip namin ang tungkol sa mga detalyeng ito sa yugto ng disenyo, ngunit mahirap hulaan ang epekto nito sa pagganap ng panghuling dashboard.
Kapag ipinatupad ang dashboard, sinundan namin ang mahabang Agile path. Ang aming gawain ay magbigay ng isang gumaganang tool na may kinakailangang data para sa pagsubok sa lalong madaling panahon. Samakatuwid, nagpunta kami sa mga sprint at nagsimula sa pagliit ng trabaho sa gilid ng kasalukuyang imbakan.
Bahagi 1: Pananampalataya sa Tableau
Upang pasimplehin ang suporta sa IT at mabilis na ipatupad ang mga pagbabago, nagpasya kaming gawin ang lohika para sa pagkalkula ng mga hindi additive na tagapagpahiwatig at paghahambing ng mga nakaraang panahon sa Tableau.
Stage 1. Lahat ay Live, walang pagbabago sa window.
Sa yugtong ito, ikinonekta namin ang Tableau sa kasalukuyang mga storefront at nagpasyang makita kung paano kakalkulahin ang bilang ng mga resibo para sa isang taon.
Resulta:
Ang sagot ay nakapanlulumo - 20 minuto. Paglilipat ng data sa network, mataas na load sa Tableau. Napagtanto namin na kailangang ipatupad sa HANA ang logic na may mga non-additive indicator. Hindi kami gaanong natakot nito, mayroon na kaming katulad na karanasan sa BO at Analysis at alam namin kung paano bumuo ng mga mabilis na showcase sa HANA na gumagawa ng mga wastong kalkuladong non-additive indicator. Ngayon ang lahat na natitira ay upang ayusin ang mga ito sa Tableau.
Stage 2. Isinasaayos namin ang mga display case, walang materialization, everything on the fly.
Gumawa kami ng hiwalay na bagong showcase na gumawa ng kinakailangang data para sa TABLEAU on the fly. Sa pangkalahatan, nakakuha kami ng magandang resulta; binawasan namin ang oras para sa pagbuo ng lahat ng indicator sa isang linggo hanggang 9-10 segundo. At tapat naming inaasahan na sa Tableau ang oras ng pagtugon ng dashboard ay magiging 20-30 segundo sa unang pagbubukas at pagkatapos ay dahil sa cache mula 10 hanggang 12, na sa pangkalahatan ay angkop sa amin.
Resulta:
Unang bukas na dashboard: 4-5 minuto
Anumang pag-click: 3-4 minuto
Walang inaasahan ang gayong karagdagang pagtaas sa gawain ng storefront.
Bahagi 2. Sumisid sa Tableau
Stage 1. Tableau performance analysis at mabilis na pag-tune
Sinimulan naming pag-aralan kung saan ginugugol ng Tableau ang halos lahat ng oras nito. At may mga napakahusay na tool para dito, na, siyempre, ay isang plus ng Tableau. Ang pangunahing problema na natukoy namin ay ang napakakomplikadong mga query sa SQL na binuo ng Tableau. Pangunahing nauugnay ang mga ito sa:
- transposisyon ng data. Dahil ang Tableau ay walang mga tool para sa paglilipat ng mga dataset, para buuin ang kaliwang bahagi ng dashboard na may detalyadong representasyon ng lahat ng KPI, kinailangan naming gumawa ng talahanayan gamit ang isang case. Ang laki ng mga query sa SQL sa database ay umabot sa 120 character.
- pagpili ng tagal ng panahon. Ang ganitong query sa antas ng database ay tumagal ng mas maraming oras upang mag-compile kaysa sa pagpapatupad:
Yung. humiling ng pagproseso ng 12 segundo + 5 segundong pagpapatupad.
Nagpasya kaming gawing simple ang lohika ng pagkalkula sa gilid ng Tableau at ilipat ang isa pang bahagi ng mga kalkulasyon sa storefront at antas ng database. Nagdulot ito ng magagandang resulta.
Una, ginawa namin ang transposisyon sa mabilisang, ginawa namin ito sa pamamagitan ng isang buong panlabas na pagsali sa huling yugto ng pagkalkula ng VIEW, ayon sa pamamaraang ito na inilarawan sa wiki ΠΈ .
Iyon ay, gumawa kami ng isang setting table - isang transposition matrix (21x21) at natanggap ang lahat ng mga indicator sa isang row-by-row breakdown.
Ito ay:
Ito ay naging:
Halos walang oras na ginugugol sa mismong database transposition. Ang kahilingan para sa lahat ng mga tagapagpahiwatig para sa linggo ay patuloy na naproseso sa humigit-kumulang 10 segundo. Ngunit sa kabilang banda, nawala ang kakayahang umangkop sa mga tuntunin ng pagbuo ng isang dashboard batay sa isang tiyak na tagapagpahiwatig, i.e. para sa kanang bahagi ng dashboard kung saan ipinakita ang dynamics at detalyadong breakdown ng isang partikular na indicator, dati ay gumana ang display case sa loob ng 1-3 segundo, dahil ang kahilingan ay batay sa isang tagapagpahiwatig, at ngayon ang database ay palaging pinipili ang lahat ng mga tagapagpahiwatig at sinasala ang resulta bago ibalik ang resulta sa Tableau.
Bilang resulta, ang bilis ng dashboard ay bumaba ng halos 3 beses.
Resulta:
- 5 segundo β pag-parse ng mga dashboard, mga visualization
- 15-20 segundo - paghahanda para sa pag-compile ng mga query sa pagsasagawa ng mga pre-calculations sa Tableau
- 35-45 sec - compilation ng mga SQL query at ang kanilang parallel-sequential execution sa Hana
- 5 seg β pagpoproseso ng mga resulta, pag-uuri, muling pagkalkula ng mga visualization sa Tableau
- Siyempre, hindi nababagay sa negosyo ang mga naturang resulta, at ipinagpatuloy namin ang pag-optimize.
Stage 2. Minimum na lohika sa Tableau, kumpletong materialization
Naunawaan namin na imposibleng bumuo ng isang dashboard na may oras ng pagtugon ng ilang segundo sa isang storefront na tumatakbo nang 10 segundo, at isinasaalang-alang namin ang mga opsyon para sa pag-materialize ng data sa panig ng database partikular para sa kinakailangang dashboard. Ngunit nakatagpo kami ng isang pandaigdigang problema na inilarawan sa itaas - mga hindi additive na tagapagpahiwatig. Hindi namin natiyak na kapag nagpapalit ng mga filter o drilldown, ang Tableau ay flexible na lumipat sa pagitan ng iba't ibang storefront at mga antas na paunang nakalkula para sa iba't ibang hierarchy ng produkto (sa halimbawa, tatlong query na walang UTE, na may UTE1 at UTE2 ay bumubuo ng magkaibang mga resulta). Samakatuwid, nagpasya kaming pasimplehin ang dashboard, iwanan ang hierarchy ng produkto sa dashboard at tingnan kung gaano ito kabilis sa isang pinasimpleng bersyon.
Kaya, sa huling yugtong ito, nag-assemble kami ng hiwalay na repository kung saan idinagdag namin ang lahat ng KPI sa transposed form. Sa panig ng database, ang anumang kahilingan sa naturang storage ay pinoproseso sa loob ng 0,1 - 0,3 segundo. Sa dashboard natanggap namin ang mga sumusunod na resulta:
Unang pagbubukas: 8-10 segundo
Anumang pag-click: 6-7 segundo
Ang oras na ginugol ng Tableau ay binubuo ng:
- 0,3 seg. β dashboard parsing at compilation ng SQL query
- 1,5-3 seg. β pagpapatupad ng mga query sa SQL sa Hana para sa mga pangunahing visualization (tumatakbo nang kahanay sa hakbang 1)
- 1,5-2 seg. β rendering, muling pagkalkula ng mga visualization
- 1,3sec. β pagpapatupad ng karagdagang mga query sa SQL upang makakuha ng mga nauugnay na halaga ng filter (Brand, Division, City, Store), mga resulta ng pag-parse
Sa madaling sabi
Nagustuhan namin ang Tableau tool mula sa pananaw ng visualization. Sa yugto ng prototyping, isinaalang-alang namin ang iba't ibang elemento ng visualization at nakita namin silang lahat sa mga library, kabilang ang kumplikadong multi-level na segmentation at multi-driver waterfall.
Habang nagpapatupad ng mga dashboard na may mga pangunahing tagapagpahiwatig ng benta, nakatagpo kami ng mga kahirapan sa pagganap na hindi pa namin nalampasan. Kami ay gumugol ng higit sa dalawang buwan at nakatanggap ng isang functionally incomplete na dashboard, na ang bilis ng pagtugon ay nasa bingit ng katanggap-tanggap. At gumawa kami ng mga konklusyon para sa aming sarili:
- Ang tableau ay hindi maaaring gumana sa malalaking halaga ng data. Kung sa orihinal na modelo ng data mayroon kang higit sa 10 GB ng data (humigit-kumulang 200 milyong X 50 na mga hilera), kung gayon ang dashboard ay seryosong bumagal - mula 10 segundo hanggang ilang minuto para sa bawat pag-click. Nag-eksperimento kami sa parehong live-connect at extract. Ang bilis ng pagpapatakbo ay maihahambing.
- Limitasyon kapag gumagamit ng maraming imbakan (mga dataset). Walang paraan upang ipahiwatig ang kaugnayan sa pagitan ng mga dataset gamit ang karaniwang paraan. Kung gagamit ka ng mga workaround upang ikonekta ang mga dataset, lubos itong makakaapekto sa performance. Sa aming kaso, isinaalang-alang namin ang opsyon ng pag-materialize ng data sa bawat kinakailangang seksyon ng view at paggawa ng mga switch sa mga materialized na dataset na ito habang pinapanatili ang mga dating napiling filter - naging imposible itong gawin sa Tableau.
- Hindi posibleng gumawa ng mga dynamic na parameter sa Tableau. Hindi mo maaaring punan ang isang parameter na ginagamit upang i-filter ang isang dataset sa isang extract o sa panahon ng isang live-connecte na may resulta ng isa pang pagpipilian mula sa dataset o ang resulta ng isa pang SQL query, native na input ng user lamang o isang pare-pareho.
- Mga limitasyong nauugnay sa pagbuo ng dashboard gamit ang OLAP|PivotTable na mga elemento.
Sa MSTR, SAP SAC, SAP Analysis, kung magdaragdag ka ng dataset sa isang ulat, ang lahat ng object dito ay magkakaugnay sa isa't isa bilang default. Ang Tableau ay wala nito; ang koneksyon ay dapat na i-configure nang manu-mano. Ito ay malamang na mas nababaluktot, ngunit para sa lahat ng aming mga dashboard ito ay isang ipinag-uutos na kinakailangan para sa mga elemento - kaya ito ay mga karagdagang gastos sa paggawa. Bukod dito, kung gagawa ka ng mga kaugnay na filter upang, halimbawa, kapag nag-filter ng isang rehiyon, ang listahan ng mga lungsod ay limitado lamang sa mga lungsod ng rehiyong ito, agad kang napupunta sa sunud-sunod na mga query sa database o Extract, na kapansin-pansing nagpapabagal sa dashboard. - Mga limitasyon sa mga pag-andar. Hindi maaaring gawin ang mga mass transformation sa extract o, LALO, sa dataset mula sa Live-connecta. Magagawa ito sa pamamagitan ng Tableau Prep, ngunit ito ay karagdagang trabaho at isa pang tool upang matutunan at mapanatili. Halimbawa, hindi mo maaaring ilipat ang data o isama ito sa sarili nito. Ano ang isinara sa pamamagitan ng mga pagbabagong-anyo sa mga indibidwal na column o field, na dapat piliin sa pamamagitan ng case o kung, at ito ay bumubuo ng napakakumplikadong mga query sa SQL, kung saan ginugugol ng database ang halos lahat ng oras nito sa pag-compile ng query text. Ang hindi kakayahang umangkop na ito ng tool ay kailangang lutasin sa antas ng showcase, na humahantong sa mas kumplikadong storage, karagdagang pag-download at pagbabago.
Hindi kami sumuko sa Tableau. Ngunit hindi namin isinasaalang-alang ang Tableau bilang isang tool na may kakayahang bumuo ng mga pang-industriya na dashboard at isang tool para palitan at gawing digital ang buong corporate reporting system ng isang kumpanya.
Aktibo na kaming gumagawa ng katulad na dashboard sa isa pang tool at, sa parehong oras, sinusubukang baguhin ang arkitektura ng dashboard sa Tableau upang mas pasimplehin ito. Kung interesado ang komunidad, sasabihin namin sa iyo ang tungkol sa mga resulta.
Hinihintay din namin ang iyong mga ideya o payo kung paano ka makakagawa ng mabilis na mga dashboard sa Tabeau sa napakaraming dami ng data, dahil mayroon kaming website kung saan mas maraming data kaysa sa retail.
Pinagmulan: www.habr.com