Koha e raportimit nĂ« Excel po ikĂ«n me shpejtĂ«si â prirja drejt mjeteve mĂ« tĂ« pĂ«rshtatshme pĂ«r paraqitjen dhe analizĂ«n e informacionit Ă«shtĂ« e dukshme nĂ« tĂ« gjitha fushat. Prej kohĂ«sh kishim diskutuar brenda kompanisĂ« dixhitalizimin e ndĂ«rtimit tĂ« raportimit dhe zgjodhĂ«m sistemin e vizualizimit dhe analitikĂ«s self-service Tableau. Aleksandr Bezuglyi, drejtues i departamentit tĂ« zgjidhjeve analitike dhe raportimit tĂ« Grupit «M.Video-Eldorado», tregoi pĂ«r pĂ«rvojĂ«n dhe rezultatet e krijimit tĂ« njĂ« dashboard-i operacional.
Po e them menjĂ«herĂ«: jo gjithçka qĂ« kishim planifikuar arritĂ«m ta realizonim, por pĂ«rvoja ishte interesante dhe shpresoj qĂ« tĂ« jetĂ« e dobishme edhe pĂ«r ju. NĂ«se dikush ka ide se si mund tĂ« ishte bĂ«rĂ« mĂ« mirĂ«, do tâi jem shumĂ« mirĂ«njohĂ«s pĂ«r kĂ«shillat dhe sugjerimet.
Më poshtë flasim për atë me çfarë u përballëm dhe çfarë mësuam.
Si e nisëm
Te «M.Video-Eldorado» ekziston një model i mirëpunuar i të dhënave: informacion i strukturuar me thellësinë e nevojshme të ruajtjes dhe një numër shumë i madh raportesh me formë fikse (shihni më shumë hollësi ). Mbi bazën e tyre, analistët krijojnë ose tabela përmbledhëse dhe dërgesa 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, nisĂ«m tĂ« krijonim raporte analitike nĂ« SAP Analysis (njĂ« shtesĂ« pĂ«r Excel, nĂ« thelb â njĂ« tabelĂ« pĂ«rmbledhĂ«se mbi njĂ« motor OLAP). Por ky mjet nuk arriti tĂ« mbulonte nevojat e tĂ« gjithĂ« pĂ«rdoruesve, ndaj shumica vazhduan tĂ« pĂ«rdornin informacionin e pĂ«rpunuar mĂ« tej nga analistĂ«t.
Përdoruesit tanë fundorë ndahen në tri kategori:
Menaxhmenti i lartë. Kërkon informacion në një formë të prezantuar mirë dhe lehtësisht të kuptueshme vizualisht.
Menaxhmenti i mesëm, përdorues të avancuar. Janë të interesuar për eksplorimin e të dhënave dhe janë në gjendje të ndërtojnë vetë raporte nëse kanë mjetet e duhura. Pikërisht ata u bënë përdoruesit kryesorë të raporteve analitike në SAP Analysis.
Përdoruesit masivë. Nuk janë të interesuar për analizë të pavarur të të dhënave; përdorin raporte me shkallë të kufizuar lirie, në formatin e dërgesave dhe tabelave përmbledhëse në Excel.
Ideja jonĂ« ishte tĂ« mbulonim nevojat e tĂ« gjithĂ« pĂ«rdoruesve dhe tâu ofronim njĂ« mjet unik e tĂ« pĂ«rshtatshĂ«m. VendosĂ«m tĂ« nisnim nga top-menaxhmenti. Atyre u nevojiteshin panele tĂ« pĂ«rshtatshme pĂ«r analizĂ«n e rezultateve kryesore tĂ« biznesit. KĂ«shtu, e nisĂ«m me Tableau dhe fillimisht zgjodhĂ«m dy drejtime: treguesit e shitjeve nĂ« retail dhe online, me thellĂ«si dhe gjerĂ«si tĂ« kufizuar analize, qĂ« do tĂ« mbulonin rreth 80% tĂ« tĂ« dhĂ«nave tĂ« kĂ«rkuara nga top-menaxhmenti.
MeqenĂ«se pĂ«rdoruesit e dashboard-eve ishin drejtuesit e lartĂ«, u shfaq edhe njĂ« KPI shtesĂ« i produktit â shpejtĂ«sia e reagimit. Askush nuk do tĂ« presĂ« 20-30 sekonda derisa tĂ« pĂ«rditĂ«sohen tĂ« dhĂ«nat. Navigimi duhej tĂ« pĂ«rfundonte brenda 4-5 sekondash, ose edhe mĂ« mirĂ«, tĂ« funksiononte menjĂ«herĂ«. FatkeqĂ«sisht, kĂ«tĂ« nuk arritĂ«m ta realizonim.
Kështu dukej prototipi i dashboard-it tonë kryesor:
Ideja kryesore ishte të bashkonim në të majtë drejtuesit kryesorë të KPI-ve, të cilët në fund arritën në 19, dhe në të djathtë të paraqisnim dinamikën e tyre dhe ndarjen sipas atributeve kryesore. Detyra duket e thjeshtë, ndërsa vizualizimi logjik dhe i kuptueshëm, derisa të futesh në detaje.
Detaji 1. Vëllimi i të dhënave
Tabela kryesore e shitjeve pĂ«r njĂ« vit zĂ« tek ne rreth 300 milionĂ« rreshta. MeqenĂ«se duhet tĂ« pasqyrohet edhe dinamika krahasuar me vitin e kaluar dhe me paraardhĂ«sin e tij, vĂ«llimi i tĂ« dhĂ«nave vetĂ«m pĂ«r shitjet faktike arrin rreth 1 miliard rreshta. PĂ«rveç kĂ«saj, veçmas ruhet informacioni pĂ«r tĂ« dhĂ«nat e planifikuara dhe blloku i shitjeve online. Prandaj, edhe pse pĂ«rdorĂ«m DB in-memory me kolona SAP HANA, shpejtĂ«sia e ekzekutimit tĂ« njĂ« kĂ«rkese me pĂ«rzgjedhjen e tĂ« gjithĂ« treguesve pĂ«r njĂ« javĂ« nga depozitat aktuale nĂ« kohĂ« reale ishte rreth 15-20 sekonda. Zgjidhja e kĂ«tij problemi duket e qartĂ« vetvetiu â materializim shtesĂ« i tĂ« dhĂ«nave. Por edhe kĂ«tu ka sfida tĂ« fshehura, pĂ«r tĂ« cilat mĂ« poshtĂ«.
Detaji 2. Tregues joaditivë
Tek ne shumë KPI varen nga numri i kuponëve fiskalë. Dhe ky tregues përfaqëson COUNT DISTINCT të numrit të rreshtave (header-at e kuponëve) dhe jep shuma të ndryshme në varësi të atributeve të zgjedhura. Për shembull, ja si duhet të llogaritet ky tregues dhe ai derivat prej tij:
Për korrektësinë e llogaritjeve mund të bëhet:
- Të kryhet llogaritja e treguesve të tillë në kohë reale në depozitë;
- TĂ« kryhet llogaritja mbi tĂ« gjithĂ« vĂ«llimin e tĂ« dhĂ«nave nĂ« Tableau, pra sipas kĂ«rkesĂ«s tâi dĂ«rgohen Tableau tĂ« gjitha tĂ« dhĂ«nat sipas filtrave tĂ« zgjedhur nĂ« granularitetin e pozicioneve tĂ« kuponĂ«ve fiskalĂ«;
- Të krijohet një pamje e materializuar, ku do të llogariten të gjithë treguesit për të gjitha variantet e përzgjedhjeve që japin rezultate të ndryshme joadditive.
ĂshtĂ« e qartĂ« se nĂ« shembullin UTE1 dhe UTE2 janĂ« atribute tĂ« materialit qĂ« pĂ«rfaqĂ«sojnĂ« hierarkinĂ« e produkteve. Kjo nuk Ă«shtĂ« diçka statike; pĂ«rmes saj kryhet menaxhimi i brendshĂ«m i kompanisĂ«, pasi pĂ«r grupe tĂ« ndryshme produktesh pĂ«rgjigjen menaxherĂ« tĂ« ndryshĂ«m. Kemi pasur shumĂ« rishikime globale tĂ« kĂ«saj hierarkie, kur ndryshonin tĂ« gjitha nivelet dhe rishikoheshin ndĂ«rlidhjet, si edhe ndryshime tĂ« vazhdueshme tĂ« synuara, kur njĂ« grup kalon nga njĂ« nyje nĂ« tjetrĂ«n. NĂ« raportimin e zakonshĂ«m, e gjithĂ« kjo llogaritet nĂ« kohĂ« reale nga atributet e materialit; nĂ« rastin e materializimit tĂ« kĂ«tyre tĂ« dhĂ«nave, duhet tĂ« zhvillohet njĂ« mekanizĂ«m pĂ«r ndjekjen e kĂ«tyre ndryshimeve dhe ringarkimin automatik tĂ« tĂ« dhĂ«nave historike. NjĂ« detyrĂ« mjaft jotriviale.
Detaji 3. Krahasimi i të dhënave
Ky element është i ngjashëm me të mëparshmin. Thelbi është se në kompani, gjatë analizës, është praktikë të formohen disa nivele krahasimi me periudhën e mëparshme:
Krahasimi me periudhën e mëparshme (ditë me ditë, javë me javë, muaj me muaj)
Në këtë krahasim supozohet që, në varësi të periudhës së zgjedhur nga përdoruesi (për shembull java e 33-të e vitit), ne duhet të tregojmë dinamikën ndaj javës së 32-të; nëse do të zgjidhnim të dhënat për një muaj, për shembull majin, atëherë ky krahasim do të tregonte dinamikën ndaj prillit.
Krahasimi me vitin e kaluar
KĂ«tu nuanca kryesore Ă«shtĂ« se, kur krahasoni sipas ditĂ«ve dhe javĂ«ve, nuk merrni tĂ« njĂ«jtĂ«n ditĂ« tĂ« vitit tĂ« kaluar, pra nuk mund tĂ« vendosni thjesht viti aktual minus njĂ«. Duhet tĂ« shikoni ditĂ«n pĂ«rkatĂ«se tĂ« javĂ«s. NdĂ«rsa kur krahasoni muajt, pĂ«rkundrazi, duhet tĂ« merrni saktĂ«sisht tĂ« njĂ«jtĂ«n ditĂ« kalendarike tĂ« vitit tĂ« kaluar. Ka gjithashtu nuanca qĂ« lidhen me vitet e brishta. NĂ« depozitat burimore, i gjithĂ« informacioni Ă«shtĂ« i shpĂ«rndarĂ« sipas ditĂ«ve; atje nuk ka fusha tĂ« veçanta pĂ«r javĂ«, muaj apo vite. Prandaj, pĂ«r tĂ« marrĂ« njĂ« pamje tĂ« plotĂ« analitike nĂ« panel, duhet tĂ« llogarisni jo njĂ« periudhĂ« tĂ« vetme, pĂ«r shembull njĂ« javĂ«, por 4 javĂ«, dhe mĂ« pas tâi krahasoni kĂ«to tĂ« dhĂ«na, tĂ« pasqyroni dinamikĂ«n dhe devijimet. PĂ«rkatĂ«sisht, kjo logjikĂ« e formimit tĂ« krahasimit nĂ« dinamikĂ« mund tĂ« zbatohet ose nĂ« Tableau, ose nĂ« anĂ«n e vitrinĂ«s sĂ« tĂ« dhĂ«nave. Po, dhe pĂ«r kĂ«to detaje sigurisht qĂ« dinim dhe kishim menduar qĂ« nĂ« fazĂ«n e projektimit, por ndikimi i tyre nĂ« performancĂ«n e dashboard-it pĂ«rfundimtar ishte i vĂ«shtirĂ« tĂ« parashikohej.
Gjatë zbatimit të dashboard-it, ndoqëm një rrugë të gjatë Agile. Detyra jonë ishte të ofronim sa më shpejt për testim një mjet funksional me të dhënat e nevojshme. Prandaj punuam me sprinte dhe u fokusuam në minimizimin e punës në anën e depozitës aktuale të të dhënave.
Pjesa 1. Besimi te Tableau
Për të thjeshtuar mbështetjen IT dhe për të përshpejtuar zbatimin e ndryshimeve, vendosëm që logjika e llogaritjes së treguesve joadditivë dhe krahasimi i periudhave të mëparshme të realizoheshin në Tableau.
Faza 1. Gjithçka në Live, pa asnjë përshtatje të vitrinave.
Në këtë fazë e lidhëm Tableau me vitrinat aktuale dhe vendosëm të shihnim si do të llogaritej numri i faturave për një vit.
Rezultati:
PĂ«rgjigjja ishte dĂ«shpĂ«ruese â 20 minuta. Transferim i tĂ« dhĂ«nave pĂ«rmes rrjetit, ngarkesĂ« e lartĂ« mbi Tableau. E kuptuam se logjika e treguesve joadditivĂ« duhej tĂ« zbatohej nĂ« HANA. Kjo nuk na trembi shumĂ«, sepse kishim tashmĂ« pĂ«rvojĂ« tĂ« ngjashme me BO dhe Analysis, dhe dinim tĂ« ndĂ«rtonim vitrina tĂ« shpejta nĂ« HANA qĂ« jepnin tregues joadditivĂ« tĂ« llogaritur saktĂ«. Tani mbetej vetĂ«m tâi pĂ«rshtatnim ato pĂ«r Tableau.
Faza 2. Optimizojmë vitrinat, pa materializim, gjithçka në kohë reale.
Krijuam një pasqyrë të re të veçantë, e cila jepte në kohë reale të dhënat e nevojshme për TABLEAU. Në përgjithësi arritëm një rezultat të mirë: e ulëm kohën e gjenerimit të të gjithë treguesve nga një javë në 9-10 sekonda. Dhe, sinqerisht, prisnim që në Tableau koha e përgjigjes së dashboard-it të ishte 20-30 sekonda në hapjen e parë dhe më pas, falë cache-it, 10-12 sekonda, gjë që në përgjithësi do të na kënaqte.
Rezultati:
Hapja e parë e dashboard-it: 4-5 minuta
Ădo klikim: 3-4 minuta
Askush nuk e priste një rritje të tillë shtesë të kohës së punës së pasqyrës.
Pjesa 2. Thellim në Tableau
Faza 1. Analiza e performancës së Tableau dhe optimizim i shpejtë
Nisëm të analizojmë se ku e shpenzon Tableau pjesën më të madhe të kohës. Dhe për këtë ka mjete mjaft të mira, çka sigurisht është një plus i Tableau. Problemi kryesor që identifikuam ishin pyetjet SQL shumë komplekse që ndërtonte Tableau. Ato lidhen para së gjithash me:
â transpozimin e tĂ« dhĂ«nave. MeqĂ« Tableau nuk ka mjete pĂ«r transpozimin e dataset-eve, pĂ«r tĂ« ndĂ«rtuar pjesĂ«n e majtĂ« tĂ« dashboard-it me paraqitje tĂ« detajuar tĂ« tĂ« gjithĂ« KPI-ve, na u desh tĂ« formonim tabelĂ«n pĂ«rmes case. MadhĂ«sia e pyetjeve SQL nĂ« BD arriti nĂ« 120 000 karaktere.
â pĂ«rzgjedhjen e periudhĂ«s kohore. NjĂ« pyetje e tillĂ« nĂ« nivelin e BD-sĂ« merrte mĂ« shumĂ« kohĂ« pĂ«r kompilim sesa pĂ«r ekzekutim:
Pra, përpunimi i pyetjes 12 sekonda + 5 sekonda ekzekutim.
Vendosëm të thjeshtonim logjikën e llogaritjeve në anën e Tableau dhe të zhvendosnim një pjesë tjetër të llogaritjeve në pasqyrë dhe në nivelin e BD-së. Kjo solli rezultate të mira.
Fillimisht bëmë transpozimin në kohë reale, e realizuam përmes full outer join në fazën përfundimtare të llogaritjes së VIEW, sipas kësaj qasjeje të përshkruar në wiki dhe .
Pra, krijuam njĂ« tabelĂ« konfigurimi â matricĂ«n e transpozimit (21x21) dhe morĂ«m tĂ« gjithĂ« treguesit nĂ« ndarje sipas rreshtave.
Ishte:
U bë:
Vetë transpozimi i DB-së pothuajse nuk kërkonte kohë. Kërkesa për të gjithë treguesit për një javë vazhdonte të ekzekutohej në rreth 10 sekonda. Megjithatë, humbi fleksibiliteti në ndërtimin e dashboard-it për një tregues të caktuar, pra për pjesën e djathtë të dashboard-it, ku paraqitet dinamika dhe zbërthimi i detajuar i një treguesi specifik. Më parë, data mart ekzekutohej për 1-3 sekonda, sepse kërkesa bëhej vetëm për një tregues, ndërsa tani DB-ja gjithmonë merrte të gjithë treguesit dhe e filtronte rezultatin vetëm përpara se ta kthente në Tableau.
Si rezultat, shpejtësia e funksionimit të dashboard-it u ul pothuajse 3 herë.
Rezultati:
- 5 sek â parsimi i dashboard-it, vizualizimeve
- 15-20 sek â pĂ«rgatitja pĂ«r kompilimin e kĂ«rkesave me ekzekutimin e parapĂ«rllogaritjeve nĂ« Tableau
- 35-45 sek â kompilimi i kĂ«rkesave SQL dhe ekzekutimi i tyre paralel-sekuencial nĂ« Hana
- 5 sek â pĂ«rpunimi i rezultateve, renditja, rillogaritja e vizualizimeve nĂ« Tableau
- Natyrisht, rezultate të tilla nuk e kënaqnin biznesin dhe ne vazhduam optimizimin.
Faza 2. Minimum logjike në Tableau, materializim i plotë
E kuptonim se ishte e pamundur tĂ« ndĂ«rtohej njĂ« dashboard me kohĂ« pĂ«rgjigjeje prej disa sekondash mbi njĂ« data mart qĂ« punon pĂ«r 10 sekonda, ndaj shqyrtuam opsionet e materializimit tĂ« tĂ« dhĂ«nave nĂ« anĂ«n e DB-sĂ« posaçërisht pĂ«r dashboard-in e kĂ«rkuar. Por u pĂ«rballĂ«m me problemin global tĂ« pĂ«rshkruar mĂ« sipĂ«r â treguesit jo aditivĂ«. Nuk arritĂ«m tĂ« bĂ«nim qĂ«, kur ndryshonin filtrat ose nivelet e zgjerimit, Tableau tĂ« kalonte nĂ« mĂ«nyrĂ« fleksibile midis data mart-eve dhe niveleve tĂ« ndryshme, tĂ« parapĂ«rllogaritura pĂ«r hierarki tĂ« ndryshme produktesh (nĂ« shembull, tre kĂ«rkesa pa UTE, me UTE1 dhe UTE2 formojnĂ« rezultate tĂ« ndryshme). Prandaj morĂ«m vendimin ta thjeshtonim dashboard-in, tĂ« hiqnim dorĂ« nga hierarkia e produkteve nĂ« dashboard dhe tĂ« shihnim sa i shpejtĂ« mund tĂ« ishte nĂ« versionin e thjeshtuar.
Pra, nĂ« kĂ«tĂ« fazĂ« tĂ« fundit, ndĂ«rtuam njĂ« depo tĂ« veçantĂ« ku vendosĂ«m tĂ« gjithĂ« KPI-tĂ« nĂ« formĂ« tĂ« transpozuar. NĂ« anĂ«n e DB-sĂ«, çdo kĂ«rkesĂ« ndaj kĂ«saj depoje ekzekutohet pĂ«r 0,1â0,3 sekonda. NĂ« dashboard morĂ«m rezultatet e mĂ«poshtme:
Hapja e parë: 8-10 sekonda
Ădo klikim: 6-7 sekonda
Koha që shpenzon Tableau përbëhet nga:
- 0,3 sek. â parsimi i dashboard-it dhe kompilimi i kĂ«rkesave SQL
- 1,5-3 sek. â ekzekutimi i kĂ«rkesave SQL nĂ« Hana pĂ«r vizualizimet kryesore (niset paralelisht me pikĂ«n 1)
- 1,5-2 sek. â renderimi, rillogaritja e vizualizimeve
- 1,3 sek. â ekzekutimi i kĂ«rkesave shtesĂ« SQL pĂ«r tĂ« marrĂ« vlera pĂ«rkatĂ«se tĂ« filtrave (Marka, Divizioni, Qyteti, Dyqani), si dhe parsimi i rezultateve
Nëse do ta përmbledhim shkurt
Na pëlqeu mjeti Tableau nga pikëpamja e vizualizimit. Në fazën e krijimit të maketeve shqyrtuam elemente të ndryshme të vizualizimit dhe i gjetëm të gjitha në biblioteka, përfshirë segmentime komplekse me shumë nivele dhe waterfall me shumë driverë.
GjatĂ« zbatimit tĂ« dashboard-eve me treguesit kryesorĂ« tĂ« shitjeve, u pĂ«rballĂ«m me vĂ«shtirĂ«si nĂ« performancĂ« qĂ« ende nuk kemi arritur tâi kapĂ«rcejmĂ«. Kaluam mĂ« shumĂ« se dy muaj dhe morĂ«m njĂ« dashboard funksionalisht jo tĂ« plotĂ«, me shpejtĂ«si reagimi nĂ« kufijtĂ« e pranueshĂ«m. Nga kjo nxorĂ«m kĂ«to pĂ«rfundime:
- Tableau nuk di tĂ« punojĂ« me vĂ«llime tĂ« mĂ«dha tĂ« dhĂ«nash. NĂ«se nĂ« modelin burimor tĂ« tĂ« dhĂ«nave keni mĂ« shumĂ« se 10 GB tĂ« dhĂ«na (rreth 200 mln. x 50 rreshta), dashboard-i ngadalĂ«sohet ndjeshĂ«m â nga 10 sekonda deri nĂ« disa minuta pĂ«r çdo klikim. Kemi eksperimentuar si me live-connect, ashtu edhe me extract. ShpejtĂ«sia e punĂ«s Ă«shtĂ« e krahasueshme.
- Ka kufizime gjatĂ« pĂ«rdorimit tĂ« disa depozitave tĂ« tĂ« dhĂ«nave (datasets). Nuk ka mundĂ«si qĂ« me mjetet standarde tĂ« pĂ«rcaktohen marrĂ«dhĂ«niet ndĂ«rmjet datasets. NĂ«se pĂ«rdoren zgjidhje alternative pĂ«r lidhjen e datasets, kjo ndikon shumĂ« nĂ« performancĂ«. NĂ« rastin tonĂ«, shqyrtuam opsionin e materializimit tĂ« tĂ« dhĂ«nave nĂ« çdo prerje tĂ« nevojshme tĂ« pamjeve dhe realizimin e kalimeve mbi kĂ«to datasets tĂ« materializuara duke ruajtur filtrat e zgjedhur mĂ« parĂ« â por kjo doli e pamundur tĂ« realizohej nĂ« Tableau.
- Në Tableau është e pamundur të krijohen parametra dinamikë. Parametrin që përdoret për filtrimin e dataset-it në extract ose gjatë live-connect nuk mund ta mbushni me rezultatin e një përzgjedhjeje tjetër nga dataset-i ose me rezultatin e një kërkese tjetër SQL; lejohet vetëm hyrja native nga përdoruesi ose një konstante.
- Kufizime që lidhen me ndërtimin e një dashboard-i me elemente OLAP|tabele përmbledhëse.
NĂ« MSTR, SAP SAC dhe SAP Analysis, nĂ«se shtoni njĂ« dataset nĂ« raport, tĂ« gjitha objektet nĂ« tĂ« lidhen mes tyre si parazgjedhje. NĂ« Tableau kjo nuk ndodh: lidhjet duhen konfiguruar manualisht. Ndoshta kjo jep mĂ« shumĂ« fleksibilitet, por pĂ«r tĂ« gjithĂ« dashboard-et tona kjo Ă«shtĂ« njĂ« kĂ«rkesĂ« e detyrueshme pĂ«r elementet, prandaj sjell punĂ« shtesĂ«. PĂ«r mĂ« tepĂ«r, nĂ«se krijoni filtra tĂ« ndĂ«rlidhur qĂ«, pĂ«r shembull, gjatĂ« filtrimit sipas rajonit lista e qyteteve tĂ« kufizohet vetĂ«m te qytetet e atij rajoni, menjĂ«herĂ« kaloni nĂ« kĂ«rkesa sekuenciale ndaj DB ose Extract, gjĂ« qĂ« e ngadalĂ«son ndjeshĂ«m dashboard-in. - Kufizime nĂ« funksionalitet. Si mbi extract-in, ashtu edhe, aq mĂ« tepĂ«r, mbi njĂ« dataset nga Live-connect nuk mund tĂ« bĂ«ni transformime masive. Kjo mund tĂ« bĂ«het pĂ«rmes Tableau Prep, por kjo do tĂ« thotĂ« punĂ« shtesĂ« dhe edhe njĂ« mjet tjetĂ«r qĂ« duhet mĂ«suar dhe mirĂ«mbajtur. PĂ«r shembull, nuk mund tĂ« transpozoni tĂ« dhĂ«nat ose tĂ« bĂ«ni join tĂ« tyre me vetveten. Kjo zĂ«vendĂ«sohet me transformime mbi kolona ose fusha tĂ« veçanta, tĂ« cilat duhen pĂ«rzgjedhur me case ose if, dhe kjo krijon SQL query shumĂ« komplekse, ku baza shpenzon pjesĂ«n mĂ« tĂ« madhe tĂ« kohĂ«s duke kompiluar tekstin e query-t. KĂ«to mungesa fleksibiliteti tĂ« mjetit na u desh tâi zgjidhnim nĂ« nivelin e data mart, gjĂ« qĂ« çon nĂ« ndĂ«rlikim tĂ« warehouse-it, ngarkesa shtesĂ« dhe transformime tĂ« tjera.
Nuk kemi hequr dorë nga Tableau. Por si mjet i aftë për të ndërtuar dashboard-e industriale dhe si zgjidhje me të cilën mund të zëvendësohet dhe digjitalizohet i gjithë sistemi i raportimit korporativ të kompanisë, Tableau nuk po e konsiderojmë.
Aktualisht po zhvillojmë në mënyrë aktive një dashboard të ngjashëm në një mjet tjetër dhe paralelisht po përpiqemi të rishikojmë arkitekturën e dashboard-it në Tableau për ta thjeshtuar edhe më shumë. Nëse komuniteti do të jetë i interesuar, do të ndajmë rezultatet.
Gjithashtu presim idetë ose këshillat tuaja se si në Tableau mund të ndërtohen dashboard-e të shpejta mbi vëllime kaq të mëdha të dhënash, sepse ne kemi edhe një faqe interneti ku të dhënat janë shumë më të shumta se në retail.
Burimi: habr.com
