Koha e raportimit nĂ« Excel Ă«shtĂ« duke u zhdukur me shpejtĂ«si â trendi pĂ«r mjete tĂ« pĂ«rshtatshme pĂ«r paraqitjen dhe analizĂ«n e informacionit Ă«shtĂ« i dukshĂ«m nĂ« tĂ« gjitha fushat. Ne kemi diskutuar prej kohĂ«sh brenda digjitalizimit tĂ« ndĂ«rtimit tĂ« raportimeve dhe kemi zgjedhur sistemin e vizualizimit dhe analytikĂ«s self-service Tableau. AleksandĂ«r Bezugly, drejtori i departamentit tĂ« zgjidhjeve analitike dhe raportimeve tĂ« Grupit «M.Video-Eldorado», tregoi pĂ«r pĂ«rvojĂ«n dhe rezultatet e ndĂ«rtimit tĂ« panelit tĂ« informacioneve operative.
Të them menjëherë, nuk është realizuar gjithçka që ishte menduar, por përvoja ishte interesante, shpresoj se do t'ju ndihmojë edhe juve. Dhe nëse dikush ka ide se si mund të ishte bërë më mirë, do të isha shumë mirënjohës për këshilla dhe ide.
Më poshtë ka për atë që po hasnim dhe çfarë mësuam.
Nga kemi filluar
Në «M.Video-Eldorado» ekziston një model të dhënash shumë i punuar: informacion i strukturuar me thellësinë e nevojshme të ruajtjes dhe një numër të madh raportesh me forma të fixuara (shih më shumë ). Prej tyre analistët krijojnë ose tabela përmbledhëse ose dërgesa të formatuara në Excel, ose prezantime të bukura në PowerPoint për përdoruesit e fundit.
Disa vite mĂ« parĂ«, nĂ« vend tĂ« raporteve me forma tĂ« fiksuara, filluam tĂ« krijojmĂ« raporte analitike nĂ« SAP Analysis (njĂ« shtesĂ« mbi Excel, nĂ« thelb â njĂ« tabelĂ« pĂ«rmbledhĂ«se mbi motorin OLAP). Por ky mjet nuk mundi tĂ« pĂ«rmbushĂ« nevojat e tĂ« gjithĂ« pĂ«rdoruesve, shumica vazhduan tĂ« pĂ«rdorin informacionin e pĂ«rpunuar nga analistĂ«t.
Përdoruesit tanë përfundimtarë ndahen në tri kategori:
Menaxhmenti i lartë. Kërkon informacion në një formë të paraqitur mirë dhe në mënyrë të dukshme.
Menaxhmenti i mesëm, përdorues të avancuar. Janë të interesuar për hetimin e të dhënave dhe janë të aftë të ndërtojnë vetë raportet nëse kanë mjetet. Ata u bënë përdoruesit kyç të raporteve analitike në SAP Analysis.
Përdoruesit masivë. Nuk janë të interesuar për analizimin e të dhënave në mënyrë autonome, përdorin raportet me një shkallë të kufizuar lirie, në formatin e dërgesave dhe tabelave përmbledhëse në Excel.
Ideja jonĂ« ishte tĂ« pĂ«rmbushnim nevojat e tĂ« gjithĂ« pĂ«rdoruesve dhe tâu ofronim atyre njĂ« mjet tĂ« pĂ«rshtatshĂ«m. VendosĂ«m tĂ« fillojmĂ« me menaxhmentin e lartĂ«. Ata kishin nevojĂ« pĂ«r tabela tĂ« pĂ«rshtatshme pĂ«r analizimin e rezultateve kryesore tĂ« biznesit. Pra, filluam me Tableau dhe nĂ« fillim zgjodhĂ«m dy drejtimi: treguesit e shitjeve nĂ« dyqan dhe online me njĂ« thellĂ«si dhe gjerĂ«si tĂ« kufizuar analize, qĂ« do tĂ« mbulonin rreth 80% tĂ« tĂ« dhĂ«nave tĂ« kĂ«rkuara nga menaxhmenti i lartĂ«.
PĂ«r shkak se pĂ«rdoruesit e panelit ishin menaxhmenti i lartĂ«, u shfaq njĂ« KPI shtesĂ« e produktit â shpejtĂ«sia e pĂ«rgjigjes. Askush nuk do tĂ« presĂ« 20-30 sekonda derisa tĂ« rinovohen tĂ« dhĂ«nat. Navigimi duheshin tĂ« pĂ«rfshijĂ« 4-5 sekonda, por mĂ« mirĂ« tĂ« funksiononte menjĂ«herĂ«. Dhe pĂ«r fat tĂ« keq, nuk arritĂ«m ta realizojmĂ« kĂ«tĂ«.
Kështu dukej skica e panelit tonë kryesor:
Ideja kryesore â tĂ« bashkohen elementĂ«t kryesorĂ« tĂ« KPI-sĂ«, tĂ« cilĂ«t pĂ«rfundimisht u grumbulluan nĂ« 19, majtas dhe tĂ« paraqiten dinamikat dhe ndarjet sipas atributĂ«ve kryesorĂ« djathtas. Detyra duket e thjeshtĂ«, vizualizimi logjik dhe i qartĂ«, pĂ«rsa kohĂ« nuk e thellohesh nĂ« detaje.
Detaji 1. Vëllimi i të dhënave
Tabela kryesore për shitjet për vitin përmban rreth 300 milion rreshta. Duke qenë se është e nevojshme të reflektohet edhe dinamika e vitit të kaluar dhe atë para vitit të kaluar, vëllimi i të dhënave vetëm për shitjet faktike është rreth 1 miliard rreshta. Dhe gjithashtu ndahen të dhënat për planet dhe bllokun e shitjeve online. Pra, pavarësisht se përdorim një DB in-memory SAP HANA, shpejtësia e kërkesës për të përzgjedhur të gjithë treguesit për një javë nga magazinat aktuale arrinte rreth 15-20 sekonda. Zgjidhja e kësaj problemi kërkonte natyrshëm materializimin e të dhënave. Por ka edhe pasojat në këtë drejtim, për të cilat do të flasim më poshtë.
Detaji 2. Treguesit jo-additvë
Shumë KPI të tona lidhen me numrin e faturave. Dhe ky tregues përfaqëson COUNT DISTINCT të numrit të rreshtave (titujve të faturave) dhe tregon shuma të ndryshme në varësi të atributeve të zgjedhura. Për shembull, si duhet të llogaritësh këtë tregues dhe derivatët e tij:
Për saktësinë e llogaritjeve mund të:
- Kryejmë llogaritjen e treguesve të tillë në kohë reale në magazinë;
- Kryejmë llogaritjen në gjithë vëllimin e të dhënave në Tableau, dmth. me kërkesë në Tableau të kthejmë të gjithë të dhënat sipas filtrave të zgjedhura në granularitetin e pozicionit të faturave;
- Të krijojmë një vitrinë të materializuar, në të cilën do të llogariten të gjithë treguesit në të gjitha variantet e zgjedhjes që japin rezultate të ndryshme jo-additvë.
ĂshtĂ« e qartĂ« se nĂ« shembullin UTE1 dhe UTE2 janĂ« atribute materiali qĂ« pĂ«rfaqĂ«sojnĂ« hierarkinĂ« e produktit. Kjo nuk Ă«shtĂ« njĂ« gjĂ« statike; pĂ«rmes saj menaxhohet brenda kompanisĂ«, sepse grupe tĂ« ndryshme produktesh menaxhohen nga menaxherĂ« tĂ« ndryshĂ«m. Kemi pasur shumĂ« rishikime globale tĂ« kĂ«saj hierarkie, kur janĂ« ndryshuar tĂ« gjitha nivelet, kur janĂ« rishikur lidhjet, si dhe ndryshime tĂ« vazhdueshme tĂ« pikĂ«s, kur njĂ« grup kalon nga njĂ« nyjĂ« nĂ« njĂ« tjetĂ«r. NĂ« raportimin e zakonshĂ«m, tĂ« gjitha kĂ«to llogariten nĂ« fluks nga atributet e materialeve; nĂ« rastin e materializimit tĂ« kĂ«tyre tĂ« dhĂ«nave, Ă«shtĂ« e nevojshme tĂ« zhvillohet njĂ« mekanizĂ«m pĂ«r monitorimin e kĂ«tyre ndryshimeve dhe mbingarkimin automatik tĂ« tĂ« dhĂ«nave historike. NjĂ« detyrĂ« mjaft jo triviale.
Detaji 3. Krahasimi i të dhënave
Ky pikë është e ngjashme me të kaluarën. Eshte thelbi që në kompani gjatë analizës është e zakonshme të formohen disa nivele krahasimi me periudhën e kaluar:
Krahasimi me periudhën e kaluar (ditë për ditë, javë për javë, muaj për muaj)
Në këtë krahasim supozohet se, në varësi të periudhës të zgjedhur nga përdoruesi (p.sh. java 33 e vitit), duhet të tregojmë dinamikën në javën 32; nëse do të zgjidhnim të dhënat për një muaj, për shembull maj, atëherë ky krahasim do të tregonte dinamikën në prill.
Krahasimi me vitin e kaluar
Këtu nuance kryesore është se në krahasimin me ditët dhe javët, ju merrni jo të njëjtën ditë të vitit të kaluar; pra, nuk mund të merrni thjesht vitin aktual minus një. Duhet të shikoni ditën e krahasueshme të javës. Ndërsa kur krahasoni muajt, përkundrazi, duhet të merrni pikërisht atë ditë të kalendarit nga viti i kaluar. Po ashtu, ka nuanca me vitet e leaps. Në depozitë origjinale, të gjitha informacionet janë të shpërndara për ditë, nuk ka fusha të veçanta për javë, muaj, vit. Prandaj, për të marrë një prerje të plotë analitike në bord, është e nevojshme të llogaritni jo një periudhë, për shembull një javë, por 4 javë dhe pastaj të krahasoni këto të dhëna, të refletoni dinamikën, devijimet. Prandaj, logjika e formimit të krahasimit në dinamikë mund të realizohet ose në Tableau, ose nga ana e ekranit. Po, dhe për këto detaje ne sigurisht e dinim dhe mendonim që në fazën e projektimit, por ndikimi i tyre në performancën e përfundimtare të panelit ishte e vështirë të parashikohej.
Për pajisjen e panelit, ne ndiqnim një rrugë të gjatë Agile. Detyra jonë ishte të ofronim sa më shpejt një mjet të gatshëm për testim me të dhëna të nevojshme. Prandaj, ne punonim në sprint dhe bazohemi në minimizimin e punëve nga ana e depozitës aktuale.
Pjesa 1. Besimi në Tableau
Për të thjeshtuar mbështetje IT dhe për të zbatuar shpejt ndryshimet, ne vendosëm të bënim logjikën e llogaritjes së treguesve jo aditivit dhe krahasimin e periudhave të kaluara në Tableau.
Hapi 1. Të gjithë në Jetë, pa përmirësime të ekranit.
Në këtë fazë, ne lidhem Tableau me ekranet aktuale dhe vendosëm të shohim si do të llogaritej numri i çekëve për një vit.
Rezultati:
PĂ«rgjigjja ishte dĂ«shpĂ«ruese â 20 minuta. ShkĂ«mbimi i tĂ« dhĂ«nave pĂ«rmes rrjetit, ngarkese e lartĂ« nĂ« Tableau. Ne kuptuam se logjika me treguesit jo aditivit duhet tĂ« realizohej nĂ« HANA. Kjo nuk na trembte shumĂ«, sepse kishim pasur pĂ«rvojĂ« tĂ« ngjashme me BO dhe Analysis dhe ishim tĂ« aftĂ« tĂ« ndĂ«rtoshim ekrane tĂ« shpejta nĂ« HANA qĂ« jepnin saktĂ«sisht treguesit e llogaritur jo aditivit. Tani mbeteshim ta pĂ«rshtatim ato me Tableau.
Hapi 2. Jemi duke tuneuar ekranet, asnjë materializim, gjithçka në fluks.
Ne bëmë një ekran të ri të veçantë, i cili nxirrte të dhënat e nevojshme për TABLEAU në fluks. Në përgjithësi, arritëm një rezultat të mirë; reduktuam kohën e formimit të të gjithë treguesve për një javë në 9-10 sekonda. Dhe në sinqerisht priteshim që në Tableau koha e përgjigjes së panelit do të ishte 20-30 sekonda në hapjen e parë dhe më pas falë caches nga 10 deri në 12, që na do të kënaqte.
Rezultati:
Hapja e parë e panelit: 4-5 minuta
Ădo klik: 3-4 minuta
Askush nuk priste një shtesë të tillë në funksionimin e ekranit.
Pjesa 2. Zhytesi në Tableau
Hapi 1. Analiza e performancës së Tableau dhe tuning i shpejtë
Ne filluam të analizojmë se ku shpenzon Tableau kohën kryesore. Dhe për këtë ka një instrument të mirë, që, sigurisht, është një avantazh i Tableau. Problemi kryesor që kemi identifikuar ishte SQL-të shumë të ndërlikuara që formonte Tableau. Këto ishin të lidhura kryesisht me:
â transponimin e tĂ« dhĂ«nave. TĂ« mos kishte mjete pĂ«r transponimin e dataset-eve nĂ« Tableau, pĂ«r ndĂ«rtimin e pjesĂ«s sĂ« majtĂ« tĂ« panelit me njĂ« pĂ«rfaqĂ«sim tĂ« detajuar tĂ« tĂ« gjithĂ« KPI-ve, na duhej tĂ« formonim njĂ« tabelĂ« pĂ«rmes case. MadhĂ«sia e SQL-tĂ« nĂ« DB arriti 120,000 karaktere.
â zgjedhjen e periudhĂ«s sĂ« kohĂ«s. NjĂ« kĂ«rkesĂ« e tillĂ« nĂ« nivelin e DB merrte mĂ« shumĂ« kohĂ« pĂ«r kompilim se pĂ«r ekzekutim:
Pra, përpunimi i kërkesës 12 sekonda + 5 sekonda ekzekutimi.
Ne vendosëm të thjeshtojmë logjikën e llogaritjeve në Tableau dhe të transferojmë një pjesë tjetër të llogaritjeve në vitrinë dhe nivelin e bazës së të dhënave. Kjo solli rezultate të mira.
Fillimisht bëmë transpozimin në kohë reale, duke e bërë atë përmes një full outer join në fazën përfundimtare të llogaritjes së VIEW, sipas një qasje si kjo, e përshkruar në wiki. dhe .
Pra, krijuam njĂ« tabelĂ« konfigurimi â njĂ« matricĂ« transpozimi (21x21) dhe morĂ«m tĂ« gjithĂ« treguesit nĂ« njĂ« ndarje rreshtash.
Ishte:
U bë:
Transpozimi në vetë të dhënat nuk merr gati asnjë kohë. Kërkesa për të gjithë treguesit për një javë vazhdonte të përfundonte ende rreth 10 sekonda. Por kemi humbur fleksibilitetin në ndërtimin e panelit të kontrollit për një tregues të caktuar, pra për pjesën e djathtë të panelit të kontrollit ku paraqitet dinamika dhe ndarja e detajuar e një treguesi konkret, më parë vitrina përfundonte për 1-3 sekonda, pasi kërkesa shkonte për një tregues, ndërsa tani baza e të dhënave gjithmonë përzgjidhte të gjithë treguesit dhe filtroi rezultatin vetëm para se të kthente rezultatin në Tableau.
Si rezultat, shpejtësia e punës së panelit të kontrollit u zvogëlua gati me 3 herë.
Rezultati:
- 5 sek â analizimi i panelit tĂ« kontrollit, vizualizimeve
- 15-20 sek â pĂ«rgatitja pĂ«r kompilimin e kĂ«rkesave me realizimin e parakalkulimeve nĂ« Tableau
- 35-45 sek â kompilimi i kĂ«rkesave SQL dhe ekzekutimi i tyre paralel-pjesĂ«pasĂ« nĂ« Hana
- 5 sek â pĂ«rpunimi i rezultateve, renditja, rinumĂ«rimi i vizualizimeve nĂ« Tableau
- Sigurisht, këto rezultate nuk e kënaqnin biznesin dhe ne vazhduam optimizimin.
Faza 2. Minimalizimi i logjikës në Tableau, materializimi i plotë
Ne e kuptonim se ndĂ«rtimi i njĂ« paneli kontrolli me kohĂ« pĂ«rgjigjeje nĂ« disa sekonda nĂ« njĂ« vitrinĂ« qĂ« punon 10 sekonda Ă«shtĂ« e pamundur, dhe shqyrtuam mundĂ«sitĂ« e materializimit tĂ« tĂ« dhĂ«nave nĂ« anĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave posaçërisht pĂ«r panelin e kĂ«rkuar. Por u pĂ«rballĂ«m me njĂ« problem tĂ« pĂ«rgjithshĂ«m, tĂ« pĂ«rshkruar mĂ« sipĂ«r â treguesit e paaditiv. Nuk arritĂ«m tĂ« bĂ«nim qĂ« me ndryshimin e filtrave ose zgjerimeve Tableau tĂ« kalonte fleksibĂ«l midis vitrinave dhe niveleve tĂ« ndryshme, tĂ« parakalkuluara pĂ«r hierarkitĂ« e ndryshme tĂ« produkteve (nĂ« shembull, tre kĂ«rkesa pa UTE, me UTE1 dhe UTE2 formojnĂ« rezultate tĂ« ndryshme). Prandaj, morĂ«m vendimin tĂ« thjeshtojmĂ« panelin, tĂ« heqim hierarkinĂ« e produkteve nĂ« panelin e kontrollit dhe tĂ« shohim se sa i shpejtĂ« mund tĂ« jetĂ« nĂ« versionin e thjeshtuar.
Pra, nĂ« kĂ«tĂ« fazĂ« tĂ« fundit, krijuam njĂ« depo tĂ« veçantĂ«, ku grumbulluam nĂ« formĂ« tĂ« transpozuar tĂ« gjithĂ« KPI-tĂ«. NĂ« anĂ«n e bazĂ«s sĂ« tĂ« dhĂ«nave, çdo kĂ«rkesĂ« pĂ«r njĂ« depo tĂ« tillĂ« pĂ«rfundon pĂ«r 0,1 â 0,3 sekonda. NĂ« panelin e kontrollit morĂ«m rezultatet e mĂ«poshtme:
Hapja e parë: 8-10 sekonda
Ădo klik: 6-7 sekonda
Koha që harxhon Tableau është:
- 0,3 sek. â analizimi i panelit tĂ« kontrollit dhe kompilimi i kĂ«rkesave SQL
- 1,5-3 sek. â ekzekutimi i kĂ«rkesave SQL nĂ« Hana pĂ«r vizualizimet kryesore (mvijon paralelisht me p.1)
- 1,5-2 sek. â renditja, rinumĂ«rimi i vizualizimeve
- 1,3 sek. â ekzekutimi i kĂ«rkesave SQL shtesĂ« pĂ«r tĂ« marrĂ« vlerat pĂ«rkatĂ«se tĂ« filtrave (MarkĂ«, Divizion, Qytet, Dyqan), analizimi i rezultateve
Nëse përmbledhim shkurtimisht
Na pëlqeu mjeti Tableau nga këndvështrimi i vizualizimit. Në fazën e projektimit shqyrtuam elemente të ndryshme vizualizimi dhe i gjetëm të gjitha në bibliotekat, duke përfshirë segmentimet më të zakonshme dhe waterfall me më shumë motorë.
Duke zbatuar panele me treguesit kryesorë të shitjeve, u përballëm me vështirësi në performancë, të cilat ende nuk arritëm t'i kalojmë. Shqytzuam më shumë se dy muaj dhe morëm një panel funksionalisht të papërfunduar, me shpejtësinë e përgjigjes që është në pragun e pranueshëm. Dhe për vete bëmë përfundime:
- Tableau nuk arrin tĂ« punojĂ« me volume tĂ« mĂ«dha tĂ« dhĂ«nash. NĂ«se nĂ« modelin e tĂ« dhĂ«nave fillestare keni mĂ« shumĂ« se 10 GB tĂ« dhĂ«nash (rreth 200 milionĂ« x 50 rreshta), paneli ngadalĂ«sohet pĂ«r seriozisht â nga 10 sekonda deri nĂ« disa minuta me çdo klik. Eksperimentuam si me live-connect ashtu edhe me ekstrakt. ShpejtĂ«sia e punĂ«s Ă«shtĂ« e krahasueshme.
- Kufizimi kur pĂ«rdorni disa depo (datasete). Nuk ka mundĂ«si standarde pĂ«r tĂ« treguar lidhjen e dataset-eve. NĂ«se pĂ«rdoren zgjidhje alternative pĂ«r lidhjen e dataset-eve, atĂ«herĂ« kjo do tĂ« ndikojĂ« shumĂ« nĂ« performancĂ«. NĂ« rastin tonĂ«, shqyrtuam mundĂ«sinĂ« e materializimit tĂ« tĂ« dhĂ«nave nĂ« çdo prerje tĂ« nevojshme tĂ« pĂ«rfaqĂ«simeve dhe nĂ« kĂ«to dataset-e tĂ« materializuara tĂ« bĂ«jmĂ« kalimet me ruajtjen e filtrave tĂ« zgjedhur mĂ« parĂ« â kjo doli e pamundur tĂ« bĂ«hej nĂ« Tableau.
- Në Tableau, parametrat dinamikë nuk mund të krijohen. Nuk mund të mbushni një parametër, që përdoret për filtrimin e dataset-it në ekstrakt ose gjatë lidhjes live, me rezultatin e një seleksioni tjetër nga dataset-i ose rezultatin e një tjetër kërkese SQL, vetëm me hyrje natyrale të përdoruesit ose një konstantë.
- Kufizimet që lidhen me ndërtimin e dashboard-it me elemente OLAP|Tabela Pivot.
NĂ« MSTR, SAP SAC, SAP Analysis, nĂ«se i shtoni njĂ« dataset raportit, tĂ« gjitha objektet nĂ« tĂ« janĂ« tĂ« lidhura me njĂ«ra-tjetrĂ«n si tĂ« dhĂ«na nga default. NĂ« Tableau, kjo nuk ndodh; lidhja duhet tĂ« konfigurohet manualisht. Kjo, ndoshta, Ă«shtĂ« mĂ« fleksibile, por pĂ«r tĂ« gjithĂ« dashboard-et tanĂ« Ă«shtĂ« njĂ« kĂ«rkesĂ« e domosdoshme pĂ«r elementĂ«t â prandaj kjo solli shpenzime tĂ« tjera tĂ« punĂ«s. PĂ«r mĂ« tepĂ«r, nĂ«se bĂ«ni filtra tĂ« lidhur, pĂ«r shembull, qĂ« kur filtroni rajonin lista e qyteteve tĂ« kufizohet vetĂ«m nĂ« qytetet e atij rajoni, ju menjĂ«herĂ« hasni nĂ« kĂ«rkesa sekondare pĂ«r BD ose Ekstrakt, çka e ngadalĂ«son dukshĂ«m dashboard-in. - Kufizimet nĂ« funksione. As mbi ekstraktin, as aq mĂ« shumĂ« mbi dataset-in nga Live-connecta, nuk mund tĂ« bĂ«hen transformime masive. Kjo mund tĂ« bĂ«het pĂ«rmes Tableau Prep, por kjo sjell shpenzime tĂ« tjera tĂ« punĂ«s dhe njĂ« tjetĂ«r mjet, tĂ« cilin duhet ta mĂ«soni dhe mbani. PĂ«r shembull, nuk mund tĂ« transpononi tĂ« dhĂ«nat, tâi bashkoni ato me vetveten. Kjo ndalon transformimet mbi kolona ose fusha tĂ« veçanta, tĂ« cilat duhet tĂ« zgjidhen pĂ«rmes case ose if dhe kjo krijon shumĂ« kĂ«rkesa komplekse SQL, ku baza kalon mĂ« shumĂ« kohĂ« duke kompiluar tekstin e kĂ«rkesĂ«s. KĂ«to ndĂ«rlikime tĂ« mjetit duhej t'i zgjidhnim nĂ« nivelin e vitrinĂ«s, qĂ« çon nĂ« ndĂ«rlikimin e magazinĂ«s, ngarkesa shtesĂ« dhe transformime.
Ne nuk i kemi vënë një kryq Tableau. Por si një mjet që mund të krijojë dashboard-e industriale dhe si një mjet me të cilin mund të zëvendësohet dhe dixhitalizohet e gjithë sistemi i raportimit korporativ të kompanisë, Tableau nuk e konsiderojmë.
Aktualisht jemi duke zhvilluar njĂ« dashboard tĂ« ngjashĂ«m me njĂ« mjet tjetĂ«r dhe paralelisht po pĂ«rpiqemi tĂ« rishohim arkitekturĂ«n e dashboard-it nĂ« Tableau, pĂ«r ta thjeshtuar edhe mĂ« shumĂ«. NĂ«se komuniteti do tĂ« jetĂ« i interesuar â do tâju informojmĂ« pĂ«r rezultatet.
Gjithashtu, presim idetë ose këshillat tuaja se si në Tableau mund të krijoni dashboard-e të shpejta mbi volumet kaq të mëdha të të dhënave, sepse ne kemi edhe një faqe ku të dhënat janë shumë më të mëdha se në shumicë.
Burimi: habr.com
