Dema raporkirina li Excel bi lez winda dibe - meyla ber bi amûrên hêsan ên ji bo pêşkêşkirin û analîzkirina agahdarî di her warî de xuya ye. Me ev demek dirêj e ku di hundurê de li ser dîjîtalkirina raporê nîqaş dikin û pergala analîtîka dîtbarî û karûbarê xweser a Tableau hilbijart. Serokê beşa çareserî û raporên analîtîk a Koma M.Video-Eldorado Alexander Bezugly li ser ezmûn û encamên avakirina dashboarda şer axivî.
Ez ê tavilê bibêjim ku ne her tiştê ku hatî plansaz kirin pêk hat, lê ezmûn balkêş bû, ez hêvî dikim ku ew ê ji we re jî bikêr be. Û eger kesek xwedî ramanek be ku ew çawa dikare çêtir were kirin, ez ê ji bo şîret û ramanên we pir spasdar bim.
Li jêr birîn li ser tiştên ku em pê re rû bi rû ne û em li ser çi fêr bûne hene.
Me ji ku dest pê kir?
M.Video-Eldorado xwedan modelek daneya baş-pêşkeftî ye: agahdariya birêkûpêk bi kûrahiya hilanînê ya pêwîst û hejmareke mezin ji raporên bi forma sabît (bi hûrgulî binêre ). Ji van, analîst an tabloyên pivot an jî nûçenameyên formatkirî yên li Excel, an jî pêşandanên xweş ên PowerPoint-ê ji bo bikarhênerên dawîn çêdikin.
Nêzîkî du sal berê, li şûna raporên bi forma sabît, me dest bi çêkirina raporên analîtîk di SAP Analysis de kir (pêvekek Excel, bi bingehîn tabloyek pivot li ser motora OLAP). Lê ev amûr nekaribû hewcedariyên hemî bikarhêneran bicîh bîne; piraniyê berdewam kir ku agahdariya ku ji hêla analîstan ve hatî hilberandin bikar tîne.
Bikarhênerên me yên dawî di nav sê kategoriyan de ne:
rêveberiya Top. Agahdariyê bi awayek baş pêşkêşî û zelal tê fêm kirin daxwaz dike.
Rêveberiya navîn, bikarhênerên pêşketî. Bi vekolîna daneyê re eleqedar e û heke amûr hebin dikarin bi rengek serbixwe raporan ava bikin. Ew bûn bikarhênerên sereke yên raporên analîtîk ên di SAP Analysis.
bikarhênerên girseyî. Ew ne eleqedar in ku daneyan serbixwe analîz bikin; ew raporên bi astek tixûbdar a azadiyê, di forma nûçenameyan û tabloyên pivot ên di Excel de bikar tînin.
Fikra me ev bû ku em hewcedariyên hemî bikarhêneran veşêrin û amûrek yekane, hêsan bidin wan. Me biryar da ku em bi rêveberiya top dest pê bikin. Ji wan re dashboardên hêsan-a-kar hewce bûn ku encamên karsaziya sereke analîz bikin. Ji ber vê yekê, me bi Tableau dest pê kir û pêşî du rêgez hilbijart: Nîşaneyên firotana firotanê û serhêl bi kûrahî û berfirehiya analîzê ya tixûbdar, ku dê bi qasî 80% ji daneyên ku ji hêla rêveberiya jorîn ve hatî xwestin vehewîne.
Ji ber ku bikarhênerên dashboardê rêveberiya jorîn bûn, KPI-ya din a hilberê xuya bû - leza bersivê. Dê kes 20-30 çirkeyan li benda nûvekirina daneyan neke. Navîgasyon divê di nav 4-5 çirkeyan de, an jî çêtir be, tavilê were kirin. Û mixabin em nekarîn vê bi dest bixin.
Bi vî rengî sêwirana dashboarda meya sereke wekî xuya bû:
Fikra bingehîn ew e ku ajokarên sereke yên KPI-yê, yên ku bi tevahî 19 jê hebûn, li milê çepê bidin hev û dînamîk û dabeşbûna wan ji hêla taybetmendiyên sereke ve li milê rastê pêşkêş bikin. Kar hêsan xuya dike, dîtbarî mentiqî û têgihîştî ye, heya ku hûn di hûrguliyan de neçin.
Detail 1. Hêjmara daneyan
Tabloya meya sereke ji bo firotana salane nêzî 300 mîlyon rêzan digire. Ji ber ku pêdivî ye ku dînamîkên sala borî û salek berê were xuyang kirin, hêjmara daneyên li ser firotana rastîn bi tenê 1 mîlyar xet e. Agahiyên li ser daneyên plansazkirî û bloka firotanê ya serhêl jî ji hev cuda têne hilanîn. Ji ber vê yekê, her çend me di bîra stûnê de DB SAP HANA bikar anî jî, leza lêpirsînê digel hilbijartina hemî nîşanan ji bo hefteyek ji hilgirtina heyî ya li ser firînê bi qasî 15-20 saniyeyan bû. Çareseriya vê pirsgirêkê bixwe pêşniyar dike - materyalkirina zêde ya daneyan. Lê di heman demê de kêmasiyên wê jî hene, li jêr bêtir li ser wan.
Detail 2. Nîşaneyên ne-zêde
Gelek KPI-yên me bi hejmara wergirtinan ve girêdayî ne. Û ev nîşanker COUNT DISTINCT ya hejmara rêzan (sernivîsên kontrolê) nîşan dide û li gorî taybetmendiyên hilbijartî mîqdarên cihêreng nîşan dide. Mînakî, divê ev nîşanker û jêdera wê çawa were hesibandin:
Ji bo ku hûn hesabên xwe rast bikin, hûn dikarin:
- Di hilanînê de nîşaneyên weha di firînê de hesab bikin;
- Hesabên li ser tevahiya qebareya daneyên di Tableau de pêk bînin, yanî. li ser daxwazê li Tableau, hemî daneyan li gorî fîlterên hilbijartî di hûrguliya pozîsyona wergirtinê de peyda bikin;
- Pêşangehek maddî biafirînin ku tê de hemî nîşanker dê di hemî vebijarkên nimûneyî yên ku encamên cûda yên ne-zêde didin de bêne hesibandin.
Eşkere ye ku di nimûneyê de UTE1 û UTE2 taybetmendiyên maddî ne ku hiyerarşiya hilberê temsîl dikin. Ev ne tiştek statîk e; rêveberiya di hundurê pargîdaniyê de bi wê re pêk tê, ji ber ku Rêvebirên cûda ji bo komên hilberên cûda berpirsiyar in. Me gelek revîzyonên gerdûnî yên vê hiyerarşiyê hebûn, dema ku hemî ast hatin guhertin, dema ku têkilî hatin nûve kirin, û guhertinên xala domdar, dema ku komek ji girêkekê derbasî girêka din bû. Di raporên kevneşopî de, ev hemî ji hêla taybetmendiyên materyalê ve têne hesibandin; di mijara materyalkirina van daneyan de, pêdivî ye ku mekanîzmayek ji bo şopandina van guhertinan were pêşve xistin û bixweber vesazkirina daneyên dîrokî. Karekî pir ne hindik e.
Detail 3. Daneyên berhevdana
Ev xal mîna ya berê ye. Rêza jêrîn ev e ku dema ku pargîdaniyek analîz dike, adetî ye ku bi serdema berê re çend astên berhevdanê pêk bînin:
Berawirdkirina bi heyama berê (roj bi roj, hefte bi hefte, meh bi meh)
Di vê berhevdanê de, tê texmîn kirin ku li gorî heyama ku ji hêla bikarhêner ve hatî hilbijartin (mînak, hefteya 33-an a salê), divê em di hefteya 32-an de dînamîk nîşan bidin; heke me daneyên mehekê hilbijart, mînakî Gulan. , wê hingê ev berhevok dê heya Nîsanê dînamîkan nîşan bide.
Berawirdkirin bi sala borî re
Li vir nuwazeya sereke ev e ku dema ku hûn bi roj û hefteyekê bidin ber hev, hûn heman roja sala borî nagirin, yanî. hûn nekarin tenê sala heyî kêm bikin yek. Divê hûn li roja hefteyê ku hûn berhev dikin binêrin. Dema ku mehan berhev dikin, berevajî vê, hûn hewce ne ku tam heman roja salnameya sala borî bigirin. Di heman demê de nuansên bi salên paşîn jî hene. Di depoyên orîjînal de, hemî agahdarî bi roj têne belav kirin; bi hefte, meh, an sal qadên cihê tune. Ji ber vê yekê, ji bo ku hûn di panelê de beşek analîtîk a bêkêmasî bistînin, hûn hewce ne ku ne yek serdemê, mînakî hefteyek, lê 4 hefte bijmêrin, û dûv re van daneyan bidin ber hev, dînamîk, veqetîn nîşan bidin. Li gorî vê yekê, ev mantiqa ji bo çêkirina berhevokan di dînamîk de dikare di Tableau de an jî li kêleka dikanê were bicîh kirin. Erê, û bê guman me di qonaxa sêwiranê de van hûrguliyan dizanibû û difikirîn, lê dijwar bû ku em bandora wan li ser performansa tabloya paşîn pêşbîn bikin.
Dema pêkanîna dashboardê, me riya dirêj a Agile şopand. Erka me ew bû ku bi lez û bez amûrek xebatê bi daneyên pêwîst ji bo ceribandinê peyda bikin. Ji ber vê yekê, em ketin spartekan û dest bi kêmkirina xebata li kêleka depoya heyî kir.
Beş 1: Baweriya bi Tabloyê
Ji bo hêsankirina piştgiriya IT-ê û bi lez pêkanîna guhertinan, me biryar da ku em mantiqê ji bo hesabkirina nîşaneyên ne-zêdekirî û berhevkirina serdemên borî li Tableau çêbikin.
Qonaxa 1. Her tişt Zindî ye, tu guhertinên pencereyê tune.
Di vê qonaxê de, me Tableau bi pêşangehên heyî ve girêda û biryar da ku em bibînin ka dê hejmara wergirtina salekê çawa were hesibandin.
Encam:
Bersiv xemgîn bû - 20 hûrdem. Veguheztina daneyan li ser torê, barkirina zêde li ser Tableau. Me fêhm kir ku pêdivî ye ku mantiqa bi nîşaneyên ne-zêdekirî li ser HANA were bicîh kirin. Vê yekê pir me netirsand, me berê xwedan ezmûnek wekhev bi BO û Analîzê re bû û me zanibû ku meriv çawa pêşangehên bilez di HANA-yê de ava bikin ku nîşaneyên ne-zêdekirî bi rêkûpêk hesabkirî hilberînin. Tiştê ku mabû ew bû ku wan li ser Tabloyê eyar bikin.
Qonaxa 2. Em pêşandanên pêşandanê çêdikin, ne materyalbûn, her tişt li ser firînê.
Me pêşangehek nû ya cihêreng çêkir ku daneyên pêwîst ji bo TABLEAU di firînê de hilberand. Bi gelemperî, me encamek baş girt; me dema hilberîna hemî nîşanan di hefteyekê de daxist 9-10 saniyeyan. Û me bi dilsozî hêvî dikir ku di Tableau de dema bersivê ya dashboardê dê di vekirina yekem de 20-30 saniye be û dûv re jî ji ber cache ji 10 heta 12, ku bi gelemperî dê li gorî me be.
Encam:
Tabloya yekem vekirî: 4-5 hûrdem
Her klîk: 3-4 hûrdem
Kesî hêvî nedikir ku di xebata firoşgehê de zêdebûnek wusa zêde hebe.
Beş 2. Dive nav Tableau
Qonaxa 1. Analîza performansa tabloyê û ahenga bilez
Me dest bi analîzê kir ku Tableau piraniya dema xwe li ku derê derbas dike. Û ji bo vê yekê amûrên pir baş hene, ku, bê guman, plusek Tableau ye. Pirsgirêka sereke ya ku me nas kir pirsên SQL yên pir tevlihev ên ku Tableau ava dikir bû. Ew di serî de bi:
- veguheztina daneyan. Ji ber ku Tableau ji bo veguheztina danehevan ne xwediyê amûran e, ji bo ku em milê çepê yê dashboardê bi nûnertiyek hûrgulî ya hemî KPI-yan ve ava bikin, me neçar ma ku bi karanîna dozek tabloyek çêbikin. Mezinahiya pirsên SQL di databasê de gihîştiye 120 karakteran.
- Hilbijartina dema demê. Lêpirsînek wusa di asta databasê de ji berhevkirinê bêtir wext girt:
Ewan. pêvajoykirina daxwazê 12 çirke + 5 saniye darvekirin.
Me biryar da ku em mantiqa hesabkirinê li aliyê Tableau hêsan bikin û beşek din ji hesabên xwe bigihînin asta dikan û databasê. Vê yekê encamên baş bi xwe re anî.
Pêşîn, me veguheztin di firînê de kir, me ew bi tevlêbûnek derveyî ya tevahî di qonaxa dawîn a hesabkirina VIEW de kir, li gorî vê nêzîkatiya ku li ser wiki hatî diyar kirin. и .
Ango, me tabloyek mîhengê çêkir - matrixek veguheztinê (21x21) û hemî nîşanan bi rêzek rêz- rêz wergirtin.
Bû:
Bû:
Hema bêje ti dem li ser veguheztina databasê bixwe nayê derbas kirin. Daxwaza hemî nîşanan ji bo hefteyekê di nav 10 çirkeyan de berdewam kir. Lê ji hêla din ve, nermbûn di warê avakirina dashboardek li ser bingeha nîşanek taybetî de winda bûye, ango. ji bo aliyê rastê yê tabloya ku dînamîk û veqetandina hûrgulî ya nîşanek taybetî tê pêşkêş kirin, berê pêşangeh di 1-3 çirkeyan de xebitî, ji ber ku daxwaz li ser yek nîşanek bû, û naha databas her gav hemî nîşanan hildibijêre û berî ku encamê vegerîne Tableau encam fîlter kir.
Di encamê de, leza dashboardê hema hema 3 carî kêm bû.
Encam:
- 5 çirke - tabloyên parskirinê, dîmenderxistin
- 15-20 çirke - amadekarî ji bo berhevkirina pirsan bi pêkanîna pêş-hesabên li Tabloyê
- 35-45 çirke - berhevkirina pirsên SQL û darvekirina wan a paralel-rêkûpêk li Hana
- 5 çirke - hilberandina encaman, birêkûpêkkirin, ji nû ve hesabkirina dîmenan di Tableau de
- Bê guman, encamên weha li karsaziyê nebûn, û me xweşbîniyê domand.
Qonaxa 2. Di Tabloyê de mantiqa herî kêm, maddîbûna temam
Me fêm kir ku ne mimkûn e ku li ser pêşangehek ku 10 saniyeyan dimeşîne, dashboardek bi dema bersivdayînê ya çend saniyeyan were çêkirin, û me vebijarkên ji bo materyalkirina daneyan li ser milê databasê bi taybetî ji bo dashboarda pêwîst fikirand. Lê em rastî pirsgirêkek gerdûnî ya ku li jor hatî destnîşan kirin - nîşanên ne-zêdekirî. Me nikarîbû piştrast bikira ku dema ku fîlter an guheztinan diguhezîne, Tableau bi nermî di navbera pêşekên cihêreng û astên ku ji bo hiyerarşiyên hilberên cihêreng hatine sêwirandin veguherî (di nimûne de, sê pirs bêyî UTE, bi UTE1 û UTE2 re encamên cihêreng çêdikin). Ji ber vê yekê, me biryar da ku em dashboardê hêsan bikin, dev ji hiyerarşiya hilberê di dashboardê de berdin û bibînin ka ew di guhertoyek sadekirî de çiqas zû dibe.
Ji ber vê yekê, di vê qonaxa paşîn de, me depoyek cihêreng berhev kir ku tê de me hemî KPI-yên bi forma veguheztin lê zêde kirin. Li ser milê databasê, her daxwazek ji hilanînek wusa di 0,1 - 0,3 çirkeyan de tête kirin. Di dashboardê de me encamên jêrîn wergirtin:
Vekirina yekem: 8-10 çirke
Her klîk: 6-7 çirke
Dema ku ji hêla Tableau ve hatî derbas kirin ev e:
- 0,3 sec. - Parskirina dashboard û berhevkirina pirsên SQL
- 1,5-3 sec. - bicihanîna pirsên SQL li Hana ji bo dîmenên sereke (bi gav 1 re paralel dimeşe)
- 1,5-2 sec. - rendering, ji nû ve hesabkirina dîmenan
- 1,3sec. - pêkanîna pirsên SQL yên din ji bo bidestxistina nirxên parzûnê yên têkildar (Brand, Dabeş, Bajar, Firotan), encamên parskirinê
Bi kurtî bi kurtî
Me amûra Tableau ji perspektîfek dîtbarî hez kir. Di qonaxa prototîpkirinê de, me hêmanên dîtbariyê yên cihêreng nirxand û wan hemî di pirtûkxaneyan de dîtin, di nav de dabeşkirina pir-astî ya tevlihev û şelala pir-ajokar.
Dema ku dashboardên bi nîşangirên sereke yên firotanê bicîh dikin, em rastî dijwariyên performansê hatin ku me hîna nekariye bi ser bikevin. Me ji du mehan zêdetir derbas kir û tabloyek bi fonksiyonel a netemam wergirt, ku leza bersivê ya ku li ser meqbûl e. Û me ji xwe re encam derxist:
- Tableau nikare bi daneyên mezin re bixebite. Ger di modela daneya orîjînal de we ji 10 GB zêdetir daneya (nêzîkî 200 mîlyon X 50 rêz) hebe, wê hingê tablo dê bi giranî hêdî bibe - ji 10 çirkeyan heya çend hûrdeman ji bo her klîk. Me hem bi girêdana zindî û hem jî bi derxistinê ceriband. Leza xebatê berawirdî ye.
- Sînorkirin dema ku gelek depo (danevan) bikar tînin. Rê tune ku meriv pêwendiya di navbera danehevan de bi karanîna rêgezên standard nîşan bide. Heke hûn ji bo girêdana danûstendinan rêgez bikar bînin, ev ê pir bandor li ser performansê bike. Di doza me de, me vebijarka materyalkirina daneyan di her beşê dîtina pêwîst de nirxand û di heman demê de ku parzûnên berê yên hilbijartî diparêzin veguheztinan li ser van danehevên maddî çêkin - ev yek di Tableau de ne gengaz bû ku were kirin.
- Ne gengaz e ku meriv di Tabloyê de pîvanên dînamîkî çêbike. Hûn nikarin parametreyek ku ji bo fîlterkirina danegehekê di jêgirtinekê de an di dema girêdanek zindî de tê bikar anîn bi encama hilbijarkek din a ji berhevokê an encama pirsek SQL-ya din, tenê têketina bikarhênerek xwemalî an domdarek tije bikin.
- Sînorkirinên ku bi avakirina tabloyek bi hêmanên OLAP|PivotTable re têkildar in.
Di MSTR, SAP SAC, SAP Analysis de, heke hûn danesek li raporekê zêde bikin, wê hingê hemî tiştên li ser wê ji hêla xwerû ve bi hevûdu ve girêdayî ne. Tableau viya tune; pêdivî ye ku girêdan bi destan were mîheng kirin. Ev belkî maqûltir e, lê ji bo hemî tabloyên me ev ji bo hêmanan pêdivîyek mecbûrî ye - ji ber vê yekê ev lêçûnên kedê zêde ye. Wekî din, heke hûn fîlterên têkildar çêkin da ku, mînakî, dema fîlterkirina herêmek, navnîşa bajaran tenê bi bajarên vê herêmê re sînordar be, hûn tavilê bi lêpirsînên li pey hev li databasê an Derketinê diqedin, ku ev yek bi rengek berbiçav hêdî hêdî hêdî dike. dashboard. - Sînorên di fonksiyonên. Veguherînên girseyî ne li ser jêgirtinê û ne jî, TAYBETÎ, li ser daneya ji Live-connecta nayê kirin. Ev dikare bi navgîniya Tableau Prep ve were kirin, lê ew karek zêde ye û amûrek din e ku meriv fêr bibe û biparêze. Mînakî, hûn nekarin daneyan veguhezînin an bi xwe re tevlê bibin. Tiştê ku bi veguheztinên li ser stûn an zeviyên kesane ve tê girtin, ku divê bi doz an heke were bijartin, û ev pirsên SQL yên pir tevlihev çêdike, ku tê de databas piraniya dema xwe bi berhevkirina nivîsa pirsnameyê derbas dike. Diviyabû ku ev bêserûberiya amûrê di asta pêşangehê de were çareser kirin, ku dibe sedema hilanîna tevlihev, dakêşandin û veguherînên zêde.
Me dev ji Tabloyê bernedaye. Lê em Tableau-yê wekî amûrek ku bikaribe tabloyên pîşesaziyê û amûrek ku pê re tevayî pergala raporkirina pargîdanî ya pargîdaniyek biguhezîne û dîjîtal bike, nahesibîne.
Em naha bi rengek çalak di amûrek din de dashboardek wekhev pêşve dixin û, di heman demê de, em hewl didin ku mîmariya dashboardê ya li Tableau ji nû ve sererast bikin da ku wê hê bêtir hêsan bikin. Ger civak eleqedar be, em ê ji we re li ser encaman bibêjin.
Em her weha li benda raman an şîretên we ne ka hûn çawa dikarin li Tabeau tabloyên bilez li ser hejmûnên wusa mezin ên daneyan ava bikin, ji ber ku malperek me heye ku tê de ji firotanê pirtir dane hene.
Source: www.habr.com