Koha për raportim në Excel po zhduket me shpejtësi - tendenca drejt mjeteve të përshtatshme për paraqitjen dhe analizimin e informacionit është e dukshme në të gjitha fushat. Ne kemi diskutuar nga brenda për dixhitalizimin e raportimit për një kohë të gjatë dhe kemi zgjedhur sistemin e vizualizimit dhe analitikës së vetë-shërbimit Tableau. Alexander Bezugly, kreu i departamentit të zgjidhjeve analitike dhe raportimit të Grupit M.Video-Eldorado, foli për përvojën dhe rezultatet e ndërtimit të një pulti luftarak.
Unë do të them menjëherë se jo gjithçka që ishte planifikuar u realizua, por përvoja ishte interesante, shpresoj se do të jetë e dobishme edhe për ju. Dhe nëse dikush ka ndonjë ide se si mund të bëhet më mirë, do të isha shumë mirënjohës për këshillat dhe idetë tuaja.
Më poshtë prerja është për atë që kemi hasur dhe për çfarë kemi mësuar.
Ku e nisëm?
M.Video-Eldorado ka një model të dhënash të zhvilluar mirë: informacion të strukturuar me thellësinë e kërkuar të ruajtjes dhe një numër të madh raportesh me formë fikse (shih më shumë detaje ). Nga këto, analistët bëjnë ose tabela kryesore ose gazeta të formatuara në Excel, ose prezantime të bukura në PowerPoint për përdoruesit fundorë.
Rreth dy vjet më parë, në vend të raporteve me formë fikse, filluam të krijonim raporte analitike në SAP Analysis (një shtesë Excel, në thelb një tabelë kryesore mbi motorin OLAP). Por ky mjet nuk ishte në gjendje të plotësonte nevojat e të gjithë përdoruesve; shumica vazhdoi të përdorte informacione të përpunuara shtesë nga analistët.
Përdoruesit tanë përfundimtarë ndahen në tre kategori:
Menaxhimi i lartë. Kërkon informacion në një mënyrë të mirëprezantuar dhe të kuptueshme.
Menaxhimi i mesëm, përdorues të avancuar. Të interesuar në eksplorimin e të dhënave dhe të aftë për të ndërtuar në mënyrë të pavarur raporte nëse mjetet janë të disponueshme. Ata u bënë përdoruesit kryesorë të raporteve analitike në SAP Analysis.
Përdorues masiv. Ata nuk janë të interesuar të analizojnë në mënyrë të pavarur të dhënat; ata përdorin raporte me një shkallë të kufizuar lirie, në formatin e buletineve dhe tabelave kryesore në Excel.
Ideja jonë ishte të mbulonim nevojat e të gjithë përdoruesve dhe t'u jepnim atyre një mjet të vetëm e të përshtatshëm. Ne vendosëm të fillojmë me menaxhmentin e lartë. Ata kishin nevojë për panele të lehta për t'u përdorur për të analizuar rezultatet kryesore të biznesit. Pra, ne filluam me Tableau dhe fillimisht zgjodhëm dy drejtime: treguesit e shitjeve me pakicë dhe online me thellësi dhe gjerësi të kufizuar analizash, të cilat do të mbulonin afërsisht 80% të të dhënave të kërkuara nga drejtuesit e lartë.
Meqenëse përdoruesit e pultit ishin drejtues të lartë, u shfaq një KPI tjetër shtesë i produktit - shpejtësia e përgjigjes. Askush nuk do të presë 20-30 sekonda që të dhënat të përditësohen. Lundrimi duhet të ishte bërë brenda 4-5 sekondave, ose më mirë akoma, të bëhej menjëherë. Dhe ne, mjerisht, nuk arritëm ta arrijmë këtë.
Ja si dukej faqosja e pultit tonë kryesor:
Ideja kryesore është të kombinohen drejtuesit kryesorë të KPI, nga të cilët gjithsej 19, në të majtë dhe të paraqesim dinamikën dhe ndarjen e tyre sipas atributeve kryesore në të djathtë. Detyra duket e thjeshtë, vizualizimi është logjik dhe i kuptueshëm, derisa të zhyteni në detaje.
Detaji 1. Vëllimi i të dhënave
Tabela jonë kryesore për shitjet vjetore zë rreth 300 milionë rreshta. Duke qenë se është e nevojshme të pasqyrohet dinamika për vitin e kaluar dhe një vit më parë, vëllimi i të dhënave vetëm për shitjet aktuale është rreth 1 miliard rreshta. Informacioni mbi të dhënat e planifikuara dhe blloku i shitjeve në internet ruhen gjithashtu veçmas. Prandaj, edhe pse përdorëm DB SAP HANA në memorie kolone, shpejtësia e pyetjes me zgjedhjen e të gjithë treguesve për një javë nga ruajtja aktuale në fluturim ishte rreth 15-20 sekonda. Zgjidhja e këtij problemi sugjeron vetë - materializim shtesë të të dhënave. Por ka edhe gracka, më shumë rreth tyre më poshtë.
Detaji 2. Treguesit jo shtues
Shumë nga KPI-të tona janë të lidhura me numrin e faturave. Dhe ky tregues përfaqëson COUNT DISTINCT të numrit të rreshtave (titujt e kontrollit) dhe tregon shuma të ndryshme në varësi të atributeve të zgjedhura. Për shembull, si duhet të llogaritet ky tregues dhe derivati i tij:
Për të bërë llogaritjet tuaja të sakta, mund të:
- Llogaritni tregues të tillë në fluturim në ruajtje;
- Kryeni llogaritjet në të gjithë vëllimin e të dhënave në Tableau, d.m.th. sipas kërkesës në Tabelë, jepni të gjitha të dhënat sipas filtrave të zgjedhur në granularitetin e pozicionit të faturës;
- Krijoni një vitrinë të materializuar në të cilën të gjithë treguesit do të llogariten në të gjitha opsionet e mostrës që japin rezultate të ndryshme jo shtesë.
Është e qartë se në shembullin UTE1 dhe UTE2 janë atribute materiale që përfaqësojnë hierarkinë e produktit. Kjo nuk është një gjë statike, menaxhimi brenda kompanisë bëhet përmes saj, sepse Menaxherë të ndryshëm janë përgjegjës për grupe të ndryshme produktesh. Kemi pasur shumë rishikime globale të kësaj hierarkie, kur të gjitha nivelet ndryshuan, kur marrëdhëniet u rishikuan dhe ndryshime konstante në pikë, kur një grup lëvizte nga një nyje në tjetrën. Në raportimin konvencional, e gjithë kjo llogaritet në fluturim nga atributet e materialit; në rastin e materializimit të këtyre të dhënave, është e nevojshme të zhvillohet një mekanizëm për gjurmimin e ndryshimeve të tilla dhe ringarkimin automatik të të dhënave historike. Një detyrë shumë jo e parëndësishme.
Detaji 3. Krahasimi i të dhënave
Kjo pikë është e ngjashme me atë të mëparshme. Në fund të fundit është se kur analizohet një kompani, është zakon të formohen disa nivele krahasimi me periudhën e mëparshme:
Krahasimi me periudhën e mëparshme (ditë në ditë, javë në javë, muaj në muaj)
Në këtë krahasim, supozohet se në varësi të periudhës së përzgjedhur nga përdoruesi (për shembull, java e 33-të e vitit), duhet të tregojmë dinamikën deri në javën e 32-të; nëse kemi zgjedhur të dhëna për një muaj, për shembull, maj. , atëherë ky krahasim do të tregonte dinamikën deri në prill.
Krahasimi me vitin e kaluar
Nuanca kryesore këtu është se kur krahasoni sipas ditës dhe javës, nuk po merrni të njëjtën ditë të vitit të kaluar, d.m.th. ju nuk mund të vendosni vetëm vitin aktual minus një. Duhet të shikoni ditën e javës që po krahasoni. Kur krahasoni muajt, përkundrazi, duhet të merrni saktësisht të njëjtën ditë kalendarike të vitit të kaluar. Ka edhe nuanca me vitet e brishtë. Në magazinat origjinale, i gjithë informacioni shpërndahet në ditë; nuk ka fusha të veçanta me javë, muaj ose vite. Prandaj, për të marrë një seksion kryq analitik të plotë në panel, duhet të numëroni jo një periudhë, për shembull një javë, por 4 javë, dhe më pas të krahasoni këto të dhëna, të pasqyroni dinamikën, devijimet. Prandaj, kjo logjikë për gjenerimin e krahasimeve në dinamikë mund të zbatohet edhe në Tableau ose në anën e vitrinës. Po, dhe sigurisht që ne i dinim dhe menduam për këto detaje në fazën e projektimit, por ishte e vështirë të parashikohej ndikimi i tyre në performancën e pultit përfundimtar.
Gjatë zbatimit të pultit, ne ndoqëm rrugën e gjatë Agile. Detyra jonë ishte të siguronim një mjet pune me të dhënat e nevojshme për testim sa më shpejt të jetë e mundur. Prandaj, ne shkuam në sprint dhe filluam nga minimizimi i punës në anën e ruajtjes aktuale.
Pjesa 1: Besimi në Tablo
Për të thjeshtuar mbështetjen e TI-së dhe për të zbatuar shpejt ndryshimet, vendosëm të bëjmë logjikën për llogaritjen e treguesve jo shtesë dhe krahasimin e periudhave të kaluara në Tableau.
Faza 1. Gjithçka është Live, pa modifikime të dritares.
Në këtë fazë, ne lidhëm Tableau me vitrinat aktuale dhe vendosëm të shohim se si do të llogaritet numri i faturave për një vit.
Rezultati:
Përgjigja ishte dëshpëruese - 20 minuta. Transferimi i të dhënave përmes rrjetit, ngarkesë e lartë në Tableau. Kuptuam se logjika me tregues jo-aditivë duhet të zbatohet në HANA. Kjo nuk na trembi shumë, ne kishim tashmë përvojë të ngjashme me BO dhe Analizën dhe dinim të ndërtonim vitrina të shpejta në HANA që prodhojnë tregues të llogaritur saktë jo shtesë. Tani gjithçka që mbetej ishte t'i përshtateshin ato në Tableau.
Faza 2. Ne akordojmë vitrinët, pa materializim, gjithçka në fluturim.
Ne krijuam një vitrinë të re të veçantë që prodhoi të dhënat e kërkuara për TABLEAU në fluturim. Në përgjithësi, ne morëm një rezultat të mirë; ne ulëm kohën për gjenerimin e të gjithë treguesve në një javë në 9-10 sekonda. Dhe sinqerisht prisnim që në Tableau koha e përgjigjes së pultit të ishte 20-30 sekonda në hapjen e parë dhe më pas për shkak të cache nga 10 në 12, gjë që në përgjithësi do të na përshtatej.
Rezultati:
Paneli i parë i hapur: 4-5 minuta
Çdo klikim: 3-4 minuta
Askush nuk e priste një rritje të tillë shtesë në punën e vitrinës.
Pjesa 2. Zhyt në Tablo
Faza 1. Analiza e performancës së tabelës dhe akordimi i shpejtë
Filluam të analizojmë se ku e kalon Tableau pjesën më të madhe të kohës. Dhe ka mjete mjaft të mira për këtë, gjë që, natyrisht, është një plus i Tableau. Problemi kryesor që identifikuam ishin pyetjet shumë komplekse SQL që po ndërtonte Tableau. Ata ishin të lidhur kryesisht me:
- transpozimi i të dhënave. Meqenëse Tableau nuk ka mjete për transpozimin e grupeve të të dhënave, për të ndërtuar anën e majtë të panelit me një paraqitje të detajuar të të gjithë KPI-ve, na u desh të krijonim një tabelë duke përdorur një rast. Madhësia e pyetjeve SQL në bazën e të dhënave arriti në 120 karaktere.
- Zgjedhja e periudhës kohore. Një pyetje e tillë në nivelin e bazës së të dhënave mori më shumë kohë për t'u përpiluar sesa për të ekzekutuar:
Ato. përpunimi i kërkesës 12 sekonda + 5 sekonda ekzekutim.
Ne vendosëm të thjeshtojmë logjikën e llogaritjes në anën e Tabelës dhe të zhvendosim një pjesë tjetër të llogaritjeve në vitrinën dhe nivelin e bazës së të dhënave. Kjo solli rezultate të mira.
Së pari, ne e bëmë transpozimin menjëherë, e bëmë atë përmes një bashkimi të plotë të jashtëm në fazën përfundimtare të llogaritjes VIEW, sipas kësaj qasjeje të përshkruar në wiki и .
Kjo do të thotë, ne bëmë një tabelë vendosjeje - një matricë transpozimi (21x21) dhe morëm të gjithë treguesit në një ndarje rresht pas rreshti.
ishte:
U bë:
Pothuajse nuk harxhohet kohë në vetë transpozimin e bazës së të dhënave. Kërkesa për të gjithë treguesit e javës vazhdoi të përpunohej në rreth 10 sekonda. Por nga ana tjetër, fleksibiliteti ka humbur në drejtim të ndërtimit të një pulti bazuar në një tregues specifik, d.m.th. për anën e djathtë të pultit ku paraqitet dinamika dhe zbërthimi i detajuar i një treguesi specifik, më parë vitrina punonte në 1-3 sekonda, sepse kërkesa bazohej në një tregues, dhe tani baza e të dhënave zgjidhte gjithmonë të gjithë treguesit dhe filtronte rezultatin përpara se ta kthente rezultatin në Tableau.
Si rezultat, shpejtësia e pultit u ul me pothuajse 3 herë.
Rezultati:
- 5 sekonda - analiza e paneleve, vizualizimet
- 15-20 sekonda - përgatitja për përpilimin e pyetjeve me kryerjen e llogaritjeve paraprake në Tableau
- 35-45 sek - përpilimi i pyetjeve SQL dhe ekzekutimi i tyre paralel-sekuencial në Hana
- 5 sek – përpunimi i rezultateve, renditja, rillogaritja e vizualizimeve në Tableau
- Sigurisht, rezultate të tilla nuk i përshtaten biznesit dhe ne vazhduam optimizimin.
Faza 2. Logjika minimale në Tableau, materializim i plotë
Ne e kuptuam se ishte e pamundur të ndërtonim një panel kontrolli me një kohë përgjigjeje prej disa sekondash në një vitrinë që funksionon për 10 sekonda dhe kemi shqyrtuar opsionet për materializimin e të dhënave në anën e bazës së të dhënave në mënyrë specifike për pultin e kërkuar. Por ne hasëm një problem global të përshkruar më sipër - tregues jo shtesë. Ne nuk ishim në gjendje të sigurohenim që kur ndryshonim filtrat ose programet, Tableau kalonte në mënyrë fleksibël midis vitrinave të ndryshme dhe niveleve të para-projektuara për hierarki të ndryshme produktesh (në shembull, tre pyetje pa UTE, me UTE1 dhe UTE2 gjenerojnë rezultate të ndryshme). Prandaj, vendosëm të thjeshtojmë pultin, të braktisim hierarkinë e produktit në panel dhe të shohim se sa shpejt mund të jetë në një version të thjeshtuar.
Pra, në këtë fazë të fundit, ne mblodhëm një depo të veçantë në të cilën shtuam të gjithë KPI-të në formë të transpozuar. Në anën e bazës së të dhënave, çdo kërkesë për një ruajtje të tillë përpunohet në 0,1 - 0,3 sekonda. Në panelin e kontrollit morëm rezultatet e mëposhtme:
Hapja e parë: 8-10 sekonda
Çdo klikim: 6-7 sekonda
Koha e kaluar nga Tableau përbëhet nga:
- 0,3 sek. — analizimi i panelit të kontrollit dhe përpilimi i pyetjeve SQL
- 1,5-3 sek. — ekzekutimi i pyetjeve SQL në Hana për vizualizimet kryesore (drejtohet paralelisht me hapin 1)
- 1,5-2 sek. — kthimi, rillogaritja e vizualizimeve
- 1,3 sek. - ekzekutimi i pyetjeve shtesë SQL për të marrë vlerat përkatëse të filtrit (Marka, Divizioni, Qyteti, Dyqani), analizimi i rezultateve
Për ta përmbledhur shkurtimisht
Na pëlqeu mjeti Tableau nga një këndvështrim vizualizimi. Në fazën e prototipit, ne shqyrtuam elementë të ndryshëm vizualizimi dhe i gjetëm të gjitha në biblioteka, duke përfshirë segmentimin kompleks me shumë nivele dhe ujëvarën me shumë drejtues.
Gjatë zbatimit të tabelave me treguesit kryesorë të shitjeve, kemi hasur në vështirësi të performancës që ende nuk kemi mundur t'i kapërcejmë. Kaluam më shumë se dy muaj dhe morëm një panel funksionalisht jo të plotë, shpejtësia e përgjigjes së të cilit është në prag të pranueshme. Dhe ne kemi nxjerrë përfundime për veten tonë:
- Tableau nuk mund të funksionojë me sasi të mëdha të dhënash. Nëse në modelin origjinal të të dhënave keni më shumë se 10 GB të dhëna (afërsisht 200 milion X 50 rreshta), atëherë paneli i kontrollit do të ngadalësohet seriozisht - nga 10 sekonda në disa minuta për çdo klikim. Ne eksperimentuam si me lidhjen live ashtu edhe me ekstraktin. Shpejtësia e funksionimit është e krahasueshme.
- Kufizimi kur përdorni memorie të shumta (bashkësi të dhënash). Nuk ka asnjë mënyrë për të treguar lidhjen midis grupeve të të dhënave duke përdorur mjete standarde. Nëse përdorni zgjidhje për të lidhur grupet e të dhënave, kjo do të ndikojë shumë në performancën. Në rastin tonë, ne shqyrtuam opsionin e materializimit të të dhënave në çdo seksion të kërkuar të pamjes dhe vendosjen e çelsave në këto grupe të dhënash të materializuara duke ruajtur filtrat e zgjedhur më parë - kjo doli të ishte e pamundur të bëhej në Tableau.
- Nuk është e mundur të bëhen parametra dinamikë në Tableau. Nuk mund të plotësoni një parametër që përdoret për të filtruar një grup të dhënash në një ekstrakt ose gjatë një lidhjeje të drejtpërdrejtë me rezultatin e një përzgjedhjeje tjetër nga grupi i të dhënave ose rezultatin e një pyetjeje tjetër SQL, vetëm hyrjen e përdoruesit vendas ose një konstante.
- Kufizimet që lidhen me ndërtimin e një pulti me elemente OLAP|PivotTable.
Në MSTR, SAP SAC, SAP Analysis, nëse shtoni një grup të dhënash në një raport, atëherë të gjitha objektet në të lidhen me njëri-tjetrin si parazgjedhje. Tableau nuk e ka këtë; lidhja duhet të konfigurohet manualisht. Kjo është ndoshta më fleksibël, por për të gjitha panelet tona kjo është një kërkesë e detyrueshme për elementët - kështu që kjo është kosto shtesë e punës. Për më tepër, nëse bëni filtra të lidhur në mënyrë që, për shembull, kur filtroni një rajon, lista e qyteteve kufizohet vetëm në qytetet e këtij rajoni, menjëherë përfundoni me pyetje të njëpasnjëshme në bazën e të dhënave ose Ekstrakt, gjë që ngadalëson dukshëm pult. - Kufizimet në funksione. Transformimet masive nuk mund të bëhen as në ekstraktin, as në veçanti, në grupin e të dhënave nga Live-connecta. Kjo mund të bëhet përmes Tableau Prep, por është punë shtesë dhe një mjet tjetër për të mësuar dhe mbajtur. Për shembull, nuk mund të transpozoni të dhëna ose t'i bashkoni ato me vetveten. Ajo që mbyllet përmes transformimeve në kolona ose fusha individuale, të cilat duhet të zgjidhen përmes rasteve ose nëse, dhe kjo gjeneron pyetje shumë komplekse SQL, në të cilat baza e të dhënave shpenzon shumicën e kohës duke përpiluar tekstin e pyetjes. Këto jofleksibilitete të mjetit duhej të zgjidheshin në nivelin e vitrinës, gjë që çon në ruajtje më komplekse, shkarkime shtesë dhe transformime.
Ne nuk kemi hequr dorë nga Tableau. Por ne nuk e konsiderojmë Tableau si një mjet të aftë për të ndërtuar panele industriale dhe një mjet me të cilin zëvendësohet dhe dixhitalizohet i gjithë sistemi i raportimit të korporatave të një kompanie.
Tani po zhvillojmë në mënyrë aktive një pult të ngjashëm në një mjet tjetër dhe, në të njëjtën kohë, po përpiqemi të rishikojmë arkitekturën e pultit në Tableau për ta thjeshtuar atë edhe më shumë. Nëse komuniteti është i interesuar, ne do t'ju tregojmë për rezultatet.
Ne po presim gjithashtu idetë ose këshillat tuaja se si në Tabeau mund të ndërtoni panele të shpejta mbi vëllime kaq të mëdha të dhënash, sepse ne kemi një faqe interneti ku ka shumë më shumë të dhëna sesa në shitje me pakicë.
Burimi: www.habr.com