Tabula mazumtirdzniecībā, vai tieŔām?

AtskaiÅ”u veidoÅ”anas laiks programmā Excel strauji zÅ«d ā€“ tendence uz ērtiem informācijas pasniegÅ”anas un analÄ«zes rÄ«kiem ir redzama visās jomās. Mēs jau ilgu laiku esam iekŔēji apsprieduÅ”i atskaiÅ”u digitalizāciju un izvēlējāmies Tableau vizualizācijas un paÅ”apkalpoÅ”anās analÄ«tikas sistēmu. M.Video-Eldorado Group analÄ«tisko risinājumu un ziņoÅ”anas nodaļas vadÄ«tājs Aleksandrs Bezuglijs stāstÄ«ja par kaujas paneļa izveides pieredzi un rezultātiem.

Uzreiz teikÅ”u, ka ne viss iecerētais tika realizēts, bet pieredze bija interesanta, ceru, ka noderēs arÄ« jums. Un, ja kādam ir idejas, kā to varētu izdarÄ«t labāk, bÅ«Å”u ļoti pateicÄ«gs par padomu un idejām.

Tabula mazumtirdzniecībā, vai tieŔām?

Zem griezuma ir par to, ko mēs sastapām un par ko uzzinājām.

Kur mēs sākām?

M.Video-Eldorado ir labi izstrādāts datu modelis: strukturēta informācija ar nepiecieÅ”amo uzglabāŔanas dziļumu un milzÄ«gs skaits fiksētas formas atskaiÅ”u (skatÄ«t sÄ«kāku informāciju Å”eit ir Å”is raksts). No tām analÄ«tiÄ·i veido vai nu rakurstabulas, vai formatētus biļetenus programmā Excel, vai skaistas PowerPoint prezentācijas galalietotājiem.

Pirms aptuveni diviem gadiem fiksētas formas pārskatu vietā mēs sākām veidot analÄ«tiskos pārskatus programmā SAP Analysis (Excel papildinājums, bÅ«tÄ«bā OLAP dzinēja rakurstabula). Taču Å”is rÄ«ks nespēja apmierināt visu lietotāju vajadzÄ«bas, lielākā daļa turpināja izmantot analÄ«tiÄ·u papildus apstrādāto informāciju.

Mūsu galalietotāji iedalās trīs kategorijās:

Augstākā vadība. Pieprasa informāciju labi pasniegtā un skaidri saprotamā veidā.

Vidējā vadÄ«ba, pieredzējuÅ”i lietotāji. Interesē datu izpēte un spēj patstāvÄ«gi izveidot pārskatus, ja ir pieejami rÄ«ki. Viņi kļuva par galvenajiem SAP analÄ«zes analÄ«tisko pārskatu lietotājiem.

Masu lietotāji. Viņus neinteresē neatkarīga datu analīze, viņi izmanto atskaites ar ierobežotu brīvības pakāpi informatīvo izdevumu un rakurstabulu formātā programmā Excel.

MÅ«su ideja bija aptvert visu lietotāju vajadzÄ«bas un nodroÅ”ināt viņiem vienu, ērtu rÄ«ku. Mēs nolēmām sākt ar augstāko vadÄ«bu. Viņiem bija nepiecieÅ”ami viegli lietojami informācijas paneļi, lai analizētu galvenos biznesa rezultātus. Tātad, mēs sākām ar Tableau un vispirms izvēlējāmies divus virzienus: mazumtirdzniecÄ«bas un tieÅ”saistes pārdoÅ”anas rādÄ«tājus ar ierobežotu analÄ«zes dziļumu un plaÅ”umu, kas aptvertu aptuveni 80% no augstākās vadÄ«bas pieprasÄ«tajiem datiem.

Tā kā informācijas paneļu lietotāji bija augstākā vadÄ«ba, parādÄ«jās vēl viens produkta papildu KPI - reakcijas ātrums. Neviens negaidÄ«s 20-30 sekundes, lÄ«dz dati tiks atjaunināti. Navigācijai vajadzēja notikt 4ā€“5 sekunžu laikā vai, vēl labāk, uzreiz. Un diemžēl mums tas neizdevās.

Mūsu galvenā informācijas paneļa izkārtojums izskatījās Ŕādi:

Tabula mazumtirdzniecībā, vai tieŔām?

Galvenā ideja ir apvienot galvenos KPI draiverus, no kuriem kopā bija 19, kreisajā pusē un parādÄ«t to dinamiku un sadalÄ«jumu pēc galvenajiem atribÅ«tiem labajā pusē. Uzdevums Ŕķiet vienkārÅ”s, vizualizācija loÄ£iska un saprotama, lÄ«dz ienirt detaļās.

Detaļas 1. Datu apjoms

MÅ«su galvenā gada pārdoÅ”anas tabula aizņem aptuveni 300 miljonus rindu. Tā kā ir jāatspoguļo pagājuŔā un aizpagājuŔā gada dinamika, datu apjoms par faktiskajiem pārdoÅ”anas apjomiem vien ir aptuveni 1 miljards rindu. AtseviŔķi tiek glabāta arÄ« informācija par plānotajiem datiem un tieÅ”saistes pārdoÅ”anas bloks. Tāpēc, lai gan mēs izmantojām kolonnu atmiņas DB SAP HANA, vaicājuma ātrums ar visu indikatoru atlasi vienu nedēļu no paÅ”reizējās krātuves bija aptuveni 15-20 sekundes. Å Ä«s problēmas risinājums liek domāt par sevi - datu papildu materializācija. Taču tajā ir arÄ« nepilnÄ«bas, par tām tālāk.

Detaļas 2. NepievienojoŔie rādītāji

Daudzi mÅ«su KPI ir saistÄ«ti ar kvÄ«Å”u skaitu. Un Å”is indikators attēlo COUNT ATŠĶIRÄŖGU rindu skaitu (pārbaudiet galvenes) un parāda dažādas summas atkarÄ«bā no atlasÄ«tajiem atribÅ«tiem. Piemēram, kā jāaprēķina Å”is rādÄ«tājs un tā atvasinājums:

Tabula mazumtirdzniecībā, vai tieŔām?

Lai aprēķini būtu pareizi, varat:

  • Aprēķiniet Ŕādus rādÄ«tājus lidojuma laikā krātuvē;
  • Veikt aprēķinus visam Tableau datu apjomam, t.i. pēc pieprasÄ«juma Tableau sniedz visus datus atbilstoÅ”i atlasÄ«tajiem filtriem saņemÅ”anas pozÄ«cijas granularitātē;
  • Izveidojiet materializētu vitrÄ«nu, kurā tiks aprēķināti visi rādÄ«tāji visās izlases opcijās, kas dod atŔķirÄ«gus nepievienojoÅ”us rezultātus.

Ir skaidrs, ka piemērā UTE1 un UTE2 ir materiāla atribÅ«ti, kas atspoguļo produkta hierarhiju. Tā nav statiska lieta, vadÄ«ba uzņēmumā notiek caur to, jo Par dažādām produktu grupām atbild dažādi vadÄ«tāji. Mums bija daudzas Ŕīs hierarhijas globālas pārskatÄ«Å”anas, kad mainÄ«jās visi lÄ«meņi, kad tika pārskatÄ«tas attiecÄ«bas, un pastāvÄ«gas punktu izmaiņas, kad viena grupa pārcēlās no viena mezgla uz otru. Parastā ziņoÅ”anā tas viss tiek aprēķināts no materiāla atribÅ«tiem, Å”o datu materializācijas gadÄ«jumā ir jāizstrādā mehānisms Ŕādu izmaiņu izsekoÅ”anai un vēsturisko datu automātiskai pārlādÄ“Å”anai. Ä»oti netriviāls uzdevums.

Detaļas 3. Datu salīdzinājums

Å is punkts ir lÄ«dzÄ«gs iepriekŔējam. BÅ«tÄ«ba ir tāda, ka, analizējot uzņēmumu, ir ierasts veidot vairākus salÄ«dzināŔanas lÄ«meņus ar iepriekŔējo periodu:

SalÄ«dzinājums ar iepriekŔējo periodu (no dienas uz dienu, no nedēļas uz nedēļu, no mēneÅ”a uz mēnesi)

Å ajā salÄ«dzinājumā tiek pieņemts, ka atkarÄ«bā no lietotāja izvēlētā perioda (piemēram, gada 33. nedēļa) dinamika jāparāda lÄ«dz 32. nedēļai, ja atlasÄ«jām datus par mēnesi, piemēram, maijs. , tad Å”is salÄ«dzinājums parādÄ«tu dinamiku lÄ«dz aprÄ«lim.

Salīdzinājums ar pagājuŔo gadu

Galvenā nianse Å”eit ir tāda, ka, salÄ«dzinot pa dienām un nedēļām, jÅ«s neņemat to paÅ”u pagājuŔā gada dienu, t.i. jÅ«s nevarat vienkārÅ”i likt kārtējo gadu mÄ«nus viens. Jums ir jāskatās, kura nedēļas diena tiek salÄ«dzināta. SalÄ«dzinot mēneÅ”us, gluži pretēji, jums jāņem tieÅ”i tā pati pagājuŔā gada kalendārā diena. Ir arÄ« nianses ar garajiem gadiem. Sākotnējās krātuvēs visa informācija tiek izplatÄ«ta pa dienām, nav atseviŔķu lauku ar nedēļām, mēneÅ”iem vai gadiem. Tāpēc, lai panelÄ« iegÅ«tu pilnÄ«gu analÄ«tisko Ŕķērsgriezumu, ir jāskaita nevis viens periods, piemēram, nedēļa, bet 4 nedēļas, un pēc tam jāsalÄ«dzina Å”ie dati, jāatspoguļo dinamika, novirzes. AttiecÄ«gi Å”o dinamikas salÄ«dzinājumu Ä£enerÄ“Å”anas loÄ£iku var ieviest arÄ« Tableau vai veikala pusē. Jā, un, protams, mēs zinājām un domājām par Ŕīm detaļām jau projektÄ“Å”anas stadijā, taču bija grÅ«ti paredzēt to ietekmi uz galÄ«gā informācijas paneļa veiktspēju.

IevieÅ”ot informācijas paneli, mēs gājām garo Agile ceļu. MÅ«su uzdevums bija pēc iespējas ātrāk nodroÅ”ināt darba rÄ«ku ar testÄ“Å”anai nepiecieÅ”amajiem datiem. Tāpēc mēs devāmies sprintā un sākām, samazinot darbu paÅ”reizējās krātuves malā.

1. daļa: Ticība Tabulai

Lai vienkārÅ”otu IT atbalstu un ātri ieviestu izmaiņas, mēs nolēmām Tableau izveidot nepievienojoÅ”o rādÄ«tāju aprēķināŔanas un iepriekŔējo periodu salÄ«dzināŔanas loÄ£iku.

1. posms. Viss ir tieÅ”raidē, bez loga izmaiņām.

Å ajā posmā mēs savienojām Tableau ar paÅ”reizējām skatlogām un nolēmām redzēt, kā tiks aprēķināts čeku skaits par vienu gadu.

Rezultāts:

Atbilde bija nomācoÅ”a ā€“ 20 minÅ«tes. Datu pārsÅ«tÄ«Å”ana tÄ«klā, liela slodze uz Tableau. Mēs sapratām, ka HANA ir jāievieÅ” loÄ£ika ar nepievienojoÅ”iem rādÄ«tājiem. Tas mÅ«s Ä«paÅ”i nebiedēja, mums jau bija lÄ«dzÄ«ga pieredze ar BO un Analysis, un mēs zinājām, kā HANA izveidot ātras vitrÄ«nas, kas rada pareizi aprēķinātus nepievienojoÅ”us rādÄ«tājus. Tagad atlika tikai tās pielāgot Tableau.

2. posms. Uzskaņojam vitrīnas, nekādas materializācijas, viss lidojumā.

Mēs izveidojām atseviŔķu jaunu vitrÄ«nu, kurā tika iegÅ«ti nepiecieÅ”amie dati par TABLEAU. Kopumā saņēmām labu rezultātu, visu rādÄ«tāju Ä£enerÄ“Å”anas laiku vienā nedēļā samazinājām lÄ«dz 9-10 sekundēm. Un mēs godÄ«gi gaidÄ«jām, ka Tableau pirmajā atvērÅ”anas reizē informācijas paneļa reakcijas laiks bÅ«s 20-30 sekundes un pēc tam keÅ”atmiņas dēļ no 10 lÄ«dz 12, kas kopumā mums derētu.

Rezultāts:

Pirmo reizi atvērts informācijas panelis: 4ā€“5 minÅ«tes
JebkurŔ klikŔķis: 3-4 minūtes
Neviens nebija gaidījis Ŕādu papildu veikala darba pieaugumu.

2. daļa. Ienirstiet Tableau

1. posms. Tabulas veiktspējas analÄ«ze un ātrā regulÄ“Å”ana

Mēs sākām analizēt, kur Tableau pavada lielāko daļu sava laika. Un tam ir diezgan labi rīki, kas, protams, ir Tableau pluss. Galvenā problēma, ko mēs identificējām, bija ļoti sarežģītie SQL vaicājumi, ko veidoja Tableau. Tie galvenokārt bija saistīti ar:

ā€” datu transponÄ“Å”ana. Tā kā Tableau nav datu kopu transponÄ“Å”anas rÄ«ku, lai izveidotu informācijas paneļa kreiso pusi ar detalizētu visu KPI attēlojumu, mums bija jāizveido tabula, izmantojot lietu. SQL vaicājumu lielums datu bāzē sasniedza 120 000 rakstzÄ«mju.

Tabula mazumtirdzniecībā, vai tieŔām?

- laika perioda izvēle. Šāda vaicājuma apkopoÅ”ana datu bāzes lÄ«menÄ« prasÄ«ja vairāk laika nekā izpilde:

Tabula mazumtirdzniecībā, vai tieŔām?

Tie. pieprasījuma apstrāde 12 sekundes + 5 sekundes izpilde.

Mēs nolēmām vienkārÅ”ot aprēķinu loÄ£iku Tableau pusē un pārvietot citu aprēķinu daļu uz veikala un datu bāzes lÄ«meni. Tas deva labus rezultātus.

Pirmkārt, mēs veicām transponÄ“Å”anu lidojuma laikā, mēs to veicām, izmantojot pilnu ārējo savienojumu VIEW aprēķina pēdējā posmā saskaņā ar Å”o wiki aprakstÄ«to pieeju. Transponēt ā€” Wikipedia, brÄ«vā enciklopēdija Šø Elementārā matrica - Wikipedia, brÄ«vā enciklopēdija.

Tabula mazumtirdzniecībā, vai tieŔām?

Tas ir, mēs izveidojām iestatÄ«jumu tabulu - transponÄ“Å”anas matricu (21x21) un saņēmām visus rādÄ«tājus rindu pa rindām.

Bija:
Tabula mazumtirdzniecībā, vai tieŔām?

Kļuva:
Tabula mazumtirdzniecībā, vai tieŔām?

GandrÄ«z netiek tērēts laiks paÅ”as datu bāzes transponÄ“Å”anai. Visu nedēļas rādÄ«tāju pieprasÄ«jums turpinājās apstrādāt aptuveni 10 sekundēs. Taču, no otras puses, ir zudusi elastÄ«ba attiecÄ«bā uz informācijas paneļa konstruÄ“Å”anu, pamatojoties uz konkrētu rādÄ«tāju, t.i. priekÅ” paneļa labās puses, kur ir parādÄ«ta konkrēta indikatora dinamika un detalizēts sadalÄ«jums, iepriekÅ” vitrÄ«na nostrādāja 1-3 sekundēs, jo pieprasÄ«jums tika balstÄ«ts uz vienu rādÄ«tāju, un tagad datu bāze vienmēr atlasÄ«ja visus rādÄ«tājus un filtrēja rezultātu pirms rezultāta atgrieÅ”anas Tableau.

Rezultātā informācijas paneļa ātrums samazinājās gandrīz 3 reizes.

Rezultāts:

  1. 5 sek ā€“ informācijas paneļu, vizualizāciju parsÄ“Å”ana
  2. 15-20 sekundes - sagatavoÅ”anās vaicājumu apkopoÅ”anai ar iepriekŔēju aprēķinu veikÅ”anu Tableau
  3. 35-45 sek - SQL vaicājumu kompilācija un to paralēlā secīgā izpilde programmā Hana
  4. 5 sek ā€“ rezultātu apstrāde, kārtoÅ”ana, vizualizāciju pārrēķināŔana Tableau
  5. Protams, Ŕādi rezultāti biznesam nederēja, un mēs turpinājām optimizāciju.

2. posms. Minimālā loģika Tableau, pilnīga materializācija

Mēs sapratām, ka nav iespējams izveidot informācijas paneli ar vairāku sekunžu reakcijas laiku veikalā, kas darbojas 10 sekundes, un mēs apsvērām iespējas materializēt datus tieÅ”i vajadzÄ«gajam informācijas panelim datu bāzes pusē. Bet mēs saskārāmies ar iepriekÅ” aprakstÄ«to globālo problēmu - nepievienojoÅ”iem rādÄ«tājiem. Mēs nevarējām pārliecināties, ka, mainot filtrus vai detalizētus datus, Tableau elastÄ«gi pārslēdzās starp dažādām veikalu skatlogām un lÄ«meņiem, kas iepriekÅ” izstrādāti dažādām produktu hierarhijām (piemērā trÄ«s vaicājumi bez UTE, ar UTE1 un UTE2 Ä£enerē dažādus rezultātus). Tāpēc mēs nolēmām vienkārÅ”ot informācijas paneli, atteikties no produktu hierarhijas informācijas panelÄ« un noskaidrot, cik ātri tas varētu bÅ«t vienkārÅ”otā versijā.

Tāpēc Å”ajā pēdējā posmā mēs izveidojām atseviŔķu repozitoriju, kurā pievienojām visus KPI transponētā veidā. Datu bāzes pusē jebkurÅ” pieprasÄ«jums Ŕādai krātuvei tiek apstrādāts 0,1ā€“0,3 sekundēs. Informācijas panelÄ« mēs saņēmām Ŕādus rezultātus:

Pirmā atvērÅ”ana: 8-10 sekundes
JebkurŔ klikŔķis: 6-7 sekundes

Tableau pavadītais laiks sastāv no:

  1. 0,3 sek. ā€” informācijas paneļa parsÄ“Å”ana un SQL vaicājumu apkopoÅ”ana
  2. 1,5-3 sek. ā€” SQL vaicājumu izpilde programmā Hana galvenajām vizualizācijām (darbojas paralēli 1. darbÄ«bai)
  3. 1,5-2 sek. ā€” vizualizāciju atveidoÅ”ana, pārrēķins
  4. 1,3 sek. ā€” papildu SQL vaicājumu izpilde, lai iegÅ«tu atbilstoÅ”as ā€‹ā€‹filtra vērtÄ«bas (zÄ«mols, nodaļa, pilsēta, veikals), rezultātu parsÄ“Å”ana

ÄŖsumā apkopojot

Mums patika Tableau rīks no vizualizācijas viedokļa. Prototipu izstrādes posmā mēs izskatījām dažādus vizualizācijas elementus un atradām tos visus bibliotēkās, tostarp sarežģītu daudzlīmeņu segmentāciju un vairāku draiveru ūdenskritumu.

IevieÅ”ot informācijas paneļus ar galvenajiem pārdoÅ”anas rādÄ«tājiem, mēs saskārāmies ar veiktspējas grÅ«tÄ«bām, kuras vēl neesam spējuÅ”i pārvarēt. Mēs pavadÄ«jām vairāk nekā divus mēneÅ”us un saņēmām funkcionāli nepilnÄ«gu informācijas paneli, kura reakcijas ātrums ir uz pieņemama robežas. Un secinājumus izdarÄ«jām paÅ”i:

  1. Tableau nevar strādāt ar lielu datu apjomu. Ja sākotnējā datu modelÄ« jums ir vairāk nekā 10 GB datu (apmēram 200 miljoni X 50 rindu), tad informācijas panelis nopietni palēnināsies - no 10 sekundēm lÄ«dz vairākām minÅ«tēm par katru klikŔķi. Mēs eksperimentējām gan ar tieÅ”raides savienojumu, gan ar ekstraktu. DarbÄ«bas ātrums ir salÄ«dzināms.
  2. Ierobežojums, izmantojot vairākas krātuves (datu kopas). Nav iespējams norādÄ«t attiecÄ«bas starp datu kopām, izmantojot standarta lÄ«dzekļus. Ja datu kopu savienoÅ”anai izmantojat risinājumus, tas ievērojami ietekmēs veiktspēju. MÅ«su gadÄ«jumā mēs apsvērām iespēju materializēt datus katrā nepiecieÅ”amajā skata sadaļā un veikt slēdžus uz Ŕīm materializētajām datu kopām, vienlaikus saglabājot iepriekÅ” atlasÄ«tos filtrus - tas izrādÄ«jās neiespējami izdarÄ«t Tableau.
  3. Tableau nav iespējams izveidot dinamiskus parametrus. Parametru, kas tiek izmantots datu kopas filtrÄ“Å”anai ekstraktā vai tieŔā savienojuma laikā, nevar aizpildÄ«t ar citas datu kopas atlases vai cita SQL vaicājuma rezultātu, tikai ar vietējo lietotāja ievadi vai konstanti.
  4. Ierobežojumi, kas saistīti ar informācijas paneļa izveidi ar OLAP | PivotTable elementiem.
    Programmā MSTR, SAP SAC, SAP Analysis, ja pārskatam pievienojat datu kopu, visi tajā esoÅ”ie objekti pēc noklusējuma ir saistÄ«ti viens ar otru. Tableau tā nav; savienojums ir jākonfigurē manuāli. Tas, iespējams, ir elastÄ«gāks, taču visiem mÅ«su informācijas paneļiem tā ir obligāta prasÄ«ba elementiem ā€” tātad tās ir papildu darbaspēka izmaksas. Turklāt, ja izveidojat saistÄ«tus filtrus tā, lai, piemēram, filtrējot reÄ£ionu, pilsētu saraksts bÅ«tu ierobežots tikai ar Ŕī reÄ£iona pilsētām, jÅ«s nekavējoties nonāksiet pie secÄ«giem datubāzes vai Ekstrakta vaicājumiem, kas ievērojami palēnina mērinstrumentu panelis.
  5. Funkciju ierobežojumi. Masveida transformācijas nevar veikt ne ekstraktā, ne, ÄŖPAÅ I, Live-connecta datu kopā. To var izdarÄ«t, izmantojot Tableau Prep, taču tas ir papildu darbs un vēl viens rÄ«ks, kas jāapgÅ«st un jāuztur. Piemēram, jÅ«s nevarat transponēt datus vai savienot tos ar sevi. Kas tiek aizvērts ar transformācijām atseviŔķās kolonnās vai laukos, kas ir jāizvēlas, izmantojot reÄ£istru vai ja, un tas Ä£enerē ļoti sarežģītus SQL vaicājumus, kuros datu bāze lielāko daļu laika pavada vaicājuma teksta sastādÄ«Å”anai. Å Ä« rÄ«ka neelastÄ«ba bija jāatrisina vitrÄ«nas lÄ«menÄ«, kas rada sarežģītāku krātuvi, papildu lejupielādes un transformācijas.

Mēs neesam atteikuÅ”ies no Tableau. Taču mēs neuzskatām, ka Tableau ir rÄ«ks, kas spēj izveidot rÅ«pnieciskos informācijas paneļus un rÄ«ku, ar kuru aizstāt un digitalizēt visu uzņēmuma korporatÄ«vo pārskatu sistēmu.

Tagad mēs aktÄ«vi izstrādājam lÄ«dzÄ«gu informācijas paneli citā rÄ«kā un tajā paŔā laikā cenÅ”amies pārskatÄ«t Tableau informācijas paneļa arhitektÅ«ru, lai to vēl vairāk vienkārÅ”otu. Ja sabiedrÄ«ba ir ieinteresēta, mēs jums pastāstÄ«sim par rezultātiem.

Gaidām arī jūsu idejas vai padomu par to, kā Tabeau var izveidot ātrus informācijas paneļus pār tik lielu datu apjomu, jo mums ir vietne, kurā ir daudz vairāk datu nekā mazumtirdzniecībā.

Avots: www.habr.com

Pievieno komentāru