Chakana savdodagi jadval, haqiqatan ham?

Excelda hisobot berish vaqti tezda yo'qolib bormoqda - ma'lumotlarni taqdim etish va tahlil qilish uchun qulay vositalar tendentsiyasi barcha sohalarda ko'rinadi. Biz uzoq vaqt davomida hisobotni raqamlashtirishni ichki muhokama qilib, Tableau vizualizatsiyasi va o'z-o'ziga xizmat ko'rsatish tahlil tizimini tanladik. M.Video-Eldorado guruhining tahliliy yechimlar va hisobotlar bo'limi boshlig'i Aleksandr Bezugli jangovar asboblar panelini qurish tajribasi va natijalari haqida gapirdi.

Darhol aytamanki, rejalashtirilgan hamma narsa amalga oshmadi, lekin tajriba qiziqarli bo'ldi, umid qilamanki, bu siz uchun ham foydali bo'ladi. Va agar kimdir buni qanday qilib yaxshiroq qilish haqida biron bir fikrga ega bo'lsa, men sizning maslahatingiz va g'oyalaringiz uchun juda minnatdorman.

Kesim ostida biz nimaga duch kelganimiz va nimalarni o'rganganimiz haqida.

Biz qayerdan boshladik?

M.Video-Eldorado yaxshi ishlab chiqilgan ma'lumotlar modeliga ega: kerakli saqlash chuqurligiga ega tuzilgan ma'lumotlar va ko'p sonli qat'iy shaklli hisobotlar (batafsil ma'lumotni ko'ring. mana bu maqola). Ulardan tahlilchilar Excelda pivot jadvallar yoki formatlangan axborot byulletenlarini yoki oxirgi foydalanuvchilar uchun chiroyli PowerPoint taqdimotlarini yaratadilar.

Taxminan ikki yil oldin, biz qattiq shakldagi hisobotlar o'rniga SAP tahlilida (Excel qo'shimchasi, asosan OLAP dvigateli ustidagi pivot jadvali) tahliliy hisobotlarni yaratishni boshladik. Ammo bu vosita barcha foydalanuvchilarning ehtiyojlarini qondira olmadi; ko'pchilik tahlilchilar tomonidan qo'shimcha ravishda qayta ishlangan ma'lumotlardan foydalanishda davom etdi.

Bizning oxirgi foydalanuvchilarimiz uchta toifaga bo'linadi:

Yuqori boshqaruv. Ma'lumotni yaxshi taqdim etilgan va tushunarli tarzda so'raydi.

O'rta boshqaruv, ilg'or foydalanuvchilar. Ma'lumotlarni o'rganishga qiziqadi va agar asboblar mavjud bo'lsa, mustaqil ravishda hisobotlarni tuzishga qodir. Ular SAP Analysis’dagi analitik hisobotlarning asosiy foydalanuvchilariga aylanishdi.

Ommaviy foydalanuvchilar. Ular ma'lumotlarni mustaqil ravishda tahlil qilishdan manfaatdor emas, ular Excelda axborot byulletenlari va pivot jadvallari formatida cheklangan erkinlik darajasida hisobotlardan foydalanadilar.

Bizning fikrimiz barcha foydalanuvchilarning ehtiyojlarini qondirish va ularga yagona, qulay vositani berish edi. Biz yuqori boshqaruvdan boshlashga qaror qildik. Asosiy biznes natijalarini tahlil qilish uchun ularga foydalanish uchun qulay boshqaruv paneli kerak edi. Shunday qilib, biz Tableau bilan boshladik va birinchi navbatda ikkita yo'nalishni tanladik: cheklangan chuqurlik va tahlil kengligi bilan chakana va onlayn savdo ko'rsatkichlari, bu yuqori rahbariyat tomonidan so'ralgan ma'lumotlarning taxminan 80 foizini qamrab oladi.

Boshqaruv paneli foydalanuvchilari yuqori boshqaruv bo'lganligi sababli, mahsulotning yana bir qo'shimcha KPI - javob tezligi paydo bo'ldi. Ma'lumotlar yangilanishi uchun hech kim 20-30 soniya kutmaydi. Navigatsiya 4-5 soniya ichida yoki undan ham yaxshisi bir zumda amalga oshirilishi kerak edi. Va biz, afsuski, bunga erisha olmadik.

Bizning asosiy boshqaruv panelimiz shunday ko'rinishga ega edi:

Asosiy g'oya chap tomonda jami 19 ta bo'lgan asosiy KPI drayverlarini birlashtirish va o'ng tomonda ularning dinamikasi va asosiy atributlari bo'yicha taqsimotini taqdim etishdir. Vazifa oddiy ko'rinadi, vizualizatsiya mantiqiy va tushunarli, siz tafsilotlarga sho'ng'ilmaguningizcha.

Batafsil 1. Ma'lumotlar hajmi

Yillik sotuvlar uchun asosiy jadvalimiz taxminan 300 million qatorni egallaydi. O'tgan yil va undan oldingi yil dinamikasini aks ettirish zarur bo'lganligi sababli, faqat haqiqiy sotish bo'yicha ma'lumotlar hajmi taxminan 1 milliard satrni tashkil qiladi. Rejalashtirilgan ma'lumotlar va onlayn savdo bloki haqidagi ma'lumotlar ham alohida saqlanadi. Shuning uchun, biz ustunli xotira DB SAP HANA dan foydalangan bo'lsak ham, joriy saqlashdan bir hafta davomida barcha ko'rsatkichlarni tanlash bilan so'rovning tezligi taxminan 15-20 soniyani tashkil etdi. Ushbu muammoni hal qilish o'zini o'zi taklif qiladi - ma'lumotlarni qo'shimcha moddiylashtirish. Ammo uning tuzoqlari ham bor, ular haqida quyida batafsilroq.

Batafsil 2. Qo'shimcha bo'lmagan ko'rsatkichlar

Ko'pgina KPIlarimiz tushumlar soniga bog'liq. Va bu ko'rsatkich qatorlar sonining COUNT DISTINCT (tekshirish sarlavhalari) ni ifodalaydi va tanlangan atributlarga qarab turli miqdorlarni ko'rsatadi. Masalan, ushbu ko'rsatkich va uning hosilasi qanday hisoblanishi kerak:

Hisob-kitoblarni to'g'ri bajarish uchun siz:

• Bunday ko'rsatkichlarni saqlashda tezda hisoblang;
• Tableau-dagi ma'lumotlarning butun hajmi bo'yicha hisob-kitoblarni bajaring, ya'ni. Tableau-da so'rov bo'yicha, barcha ma'lumotlarni kvitansiya pozitsiyasining granularligida tanlangan filtrlar bo'yicha taqdim eting;
• Moddiylashtirilgan vitrin yarating, unda barcha ko'rsatkichlar har xil qo'shimcha bo'lmagan natijalarni beradigan barcha namunaviy variantlarda hisoblab chiqiladi.

Ko'rinib turibdiki, misolda UTE1 va UTE2 mahsulot ierarxiyasini ifodalovchi moddiy atributlardir. Bu kompaniya ichidagi boshqaruv statik narsa emas, chunki u orqali amalga oshiriladi; Turli menejerlar turli xil mahsulot guruhlari uchun javobgardir. Biz ushbu ierarxiyaning ko'plab global qayta ko'rib chiqishlarini amalga oshirdik, barcha darajalar o'zgarganda, munosabatlar qayta ko'rib chiqilganda va doimiy nuqta o'zgarganda, bir guruh bir tugundan ikkinchisiga o'tganda. An'anaviy hisobotda bularning barchasi materialning atributlari asosida hisoblab chiqiladi, agar ushbu ma'lumotlar moddiylashtirilgan bo'lsa, bunday o'zgarishlarni kuzatish va tarixiy ma'lumotlarni avtomatik ravishda qayta yuklash mexanizmini ishlab chiqish kerak; Juda ahamiyatsiz vazifa.

Batafsil 3. Ma'lumotlarni taqqoslash

Bu nuqta avvalgisiga o'xshaydi. Xulosa shuki, kompaniyani tahlil qilishda oldingi davr bilan taqqoslashning bir necha darajalarini shakllantirish odatiy holdir:

Oldingi davr bilan taqqoslash (kundan kunga, haftadan haftaga, oydan oyga)

Ushbu taqqoslashda, foydalanuvchi tomonidan tanlangan davrga qarab (masalan, yilning 33-haftasi), agar biz bir oy uchun ma'lumotlarni tanlagan bo'lsak, dinamikani 32-haftaga ko'rsatishimiz kerak deb taxmin qilinadi; , keyin bu taqqoslash aprel oyiga qadar dinamikani ko'rsatadi.

O'tgan yil bilan taqqoslash

Bu erda asosiy nuance shundaki, kun va hafta bo'yicha taqqoslashda siz o'tgan yilning xuddi shu kunini olmaysiz, ya'ni. faqat joriy yilni minus bir qo'yish mumkin emas. Siz solishtirayotgan haftaning kuniga qarashingiz kerak. Oylarni solishtirganda, aksincha, o'tgan yilning aynan bir xil kalendar kunini olishingiz kerak. Kabisa yillari bilan nuanslar ham mavjud. Dastlabki omborlarda barcha ma'lumotlar kun bo'yicha taqsimlanadi, haftalar, oylar yoki yillar bilan alohida maydonlar mavjud emas. Shuning uchun panelda to'liq analitik kesmani olish uchun siz bir davrni emas, masalan, bir haftani emas, balki 4 haftani hisoblashingiz kerak, keyin esa bu ma'lumotlarni solishtiring, dinamikani, og'ishlarni aks ettiring. Shunga ko'ra, dinamikada taqqoslashlarni yaratish uchun ushbu mantiq Tableau yoki do'kon tomonida ham amalga oshirilishi mumkin. Ha, va, albatta, biz bu tafsilotlarni dizayn bosqichida bilardik va o'ylab ko'rdik, ammo ularning yakuniy asboblar panelining ishlashiga ta'sirini oldindan aytish qiyin edi.

Boshqaruv panelini amalga oshirishda biz uzoq Agile yo'lidan bordik. Bizning vazifamiz imkon qadar tezroq sinov uchun kerakli ma'lumotlar bilan ishlaydigan vositani taqdim etish edi. Shuning uchun, biz sprintlarga bordik va joriy saqlash tomonidagi ishni minimallashtirishdan boshladik.

1-qism: Jadvalga ishonish

AT qo'llab-quvvatlashni soddalashtirish va o'zgarishlarni tezda amalga oshirish uchun biz qo'shimcha bo'lmagan ko'rsatkichlarni hisoblash va Tableau-da o'tgan davrlarni taqqoslash mantiqini yaratishga qaror qildik.

1-bosqich. Hammasi jonli, oynada o'zgarishlar yo'q.

Ushbu bosqichda biz Tableau-ni joriy do'konlar bilan bog'ladik va bir yil uchun tushumlar soni qanday hisoblanishini ko'rishga qaror qildik.

natija:

Javob tushkunlikka tushdi - 20 daqiqa. Tarmoq orqali ma'lumotlarni uzatish, Tableau-da yuqori yuk. Biz HANA-da qo'shimcha bo'lmagan ko'rsatkichlar bilan mantiqni amalga oshirish kerakligini angladik. Bu bizni unchalik qo'rqitmadi, bizda BO va Analysis bilan o'xshash tajribamiz bor edi va biz HANA-da to'g'ri hisoblangan qo'shimchasiz ko'rsatkichlarni ishlab chiqaradigan tezkor vitrinalar yaratishni bilardik. Endi ularni Tableauga moslashtirishgina qoldi.

2-bosqich. Biz vitrinlarni sozlaymiz, moddiylashtirish yo'q, hamma narsa tezda.

Biz TABLEAU uchun kerakli ma'lumotlarni tezda ishlab chiqaradigan alohida yangi vitrin yaratdik. Umuman olganda, biz yaxshi natijaga erishdik, biz barcha ko'rsatkichlarni bir hafta ichida 9-10 soniyagacha qisqartirdik. Va biz rostini aytsam, Tableau-da asboblar panelining javob vaqti birinchi ochilishda 20-30 soniyani tashkil qiladi, keyin esa kesh tufayli 10 dan 12 gacha bo'ladi, bu umuman bizga mos keladi.

natija:

Birinchi ochiq asboblar paneli: 4-5 daqiqa
Har qanday bosish: 3-4 daqiqa
Hech kim do'kon peshtaxtasi ishining bunday qo'shimcha o'sishini kutmagan edi.

2-qism. Jadvalga sho'ng'ish

Bosqich 1. Jadvalda ishlash tahlili va tezkor sozlash

Biz Tableau ko'p vaqtini qayerda o'tkazishini tahlil qila boshladik. Va buning uchun juda yaxshi vositalar mavjud, bu, albatta, Tableau-ning ortiqcha. Biz aniqlagan asosiy muammo Tableau qurayotgan juda murakkab SQL so'rovlari edi. Ular birinchi navbatda quyidagilar bilan bog'liq edi:

- ma'lumotlarni uzatish. Tableau-da ma'lumotlar to'plamini ko'chirish vositalari yo'qligi sababli, asboblar panelining chap tomonini barcha KPIlarning batafsil tasviri bilan qurish uchun biz case yordamida jadval yaratishimiz kerak edi. Ma'lumotlar bazasidagi SQL so'rovlarining hajmi 120 000 belgiga yetdi.

- vaqt oralig'ini tanlash. Ma'lumotlar bazasi darajasidagi bunday so'rovni bajarishdan ko'ra kompilyatsiya qilish ko'proq vaqt talab qildi:

Bular. so'rovni qayta ishlash 12 soniya + 5 soniya bajarilishi.

Biz Tableau tomonida hisoblash mantiqini soddalashtirishga va hisob-kitoblarning yana bir qismini do'kon va ma'lumotlar bazasi darajasiga ko'chirishga qaror qildik. Bu yaxshi natijalar berdi.

Birinchidan, biz transpozitsiyani tezda amalga oshirdik, biz buni wiki-da tasvirlangan ushbu yondashuvga ko'ra, VIEW hisoblashning yakuniy bosqichida to'liq tashqi birlashma orqali amalga oshirdik. Transpose - Vikipediya, bepul ensiklopediya и Elementar matritsa - Vikipediya, bepul ensiklopediya.

Ya'ni, biz sozlash jadvalini tuzdik - transpozitsiya matritsasi (21x21) va barcha ko'rsatkichlarni ketma-ket taqsimlashda oldik.

edi:


Bo'ldi:


Ma'lumotlar bazasini o'tkazishga deyarli vaqt sarflanmaydi. Haftaning barcha ko'rsatkichlari bo'yicha so'rov taxminan 10 soniya ichida ko'rib chiqildi. Ammo boshqa tomondan, ma'lum bir ko'rsatkichga asoslangan asboblar panelini qurish nuqtai nazaridan moslashuvchanlik yo'qolgan, ya'ni. Muayyan indikatorning dinamikasi va batafsil taqsimoti taqdim etiladigan asboblar panelining o'ng tomoni uchun ilgari displey oynasi 1-3 soniyada ishlagan, chunki so'rov bitta ko'rsatkichga asoslangan edi va endi ma'lumotlar bazasi har doim barcha ko'rsatkichlarni tanladi va natijani Tableau ga qaytarishdan oldin natijani filtrlaydi.

Natijada asboblar paneli tezligi deyarli 3 barobar kamaydi.

natija:

1. 5 soniya - asboblar panelini tahlil qilish, vizualizatsiya
2. 15-20 soniya - jadvalda oldindan hisob-kitoblarni amalga oshirish bilan so'rovlarni tuzishga tayyorgarlik
3. 35-45 sek - SQL so'rovlarini kompilyatsiya qilish va ularni Hana'da parallel ketma-ket bajarish
4. 5 soniya - natijalarni qayta ishlash, saralash, jadvalda vizualizatsiyani qayta hisoblash
5. Albatta, bunday natijalar biznesga mos kelmadi va biz optimallashtirishni davom ettirdik.

Bosqich 2. Tableaudagi minimal mantiq, to'liq moddiylashtirish

Biz 10 soniya davomida ishlaydigan do'kon peshtaxtasida javob vaqti bir necha soniya bo'lgan asboblar panelini qurishning iloji yo'qligini tushundik va biz ma'lumotlar bazasi tomonida ma'lumotlarni kerakli asboblar paneli uchun materiallashtirish variantlarini ko'rib chiqdik. Ammo biz yuqorida tavsiflangan global muammoga duch keldik - qo'shimcha bo'lmagan ko'rsatkichlar. Filtrlar yoki burg'ulashlarni o'zgartirganda, Tableau turli xil mahsulot ierarxiyalari uchun oldindan ishlab chiqilgan turli xil vitrinalar va darajalar o'rtasida moslashuvchan tarzda almashinishiga ishonch hosil qila olmadik (misolda, UTE'siz uchta so'rov, UTE1 va UTE2 bilan turli natijalar beradi). Shuning uchun biz asboblar panelini soddalashtirishga, asboblar panelidagi mahsulot ierarxiyasidan voz kechishga va soddalashtirilgan versiyada qanchalik tez bo'lishi mumkinligini ko'rishga qaror qildik.

Shunday qilib, ushbu oxirgi bosqichda biz barcha KPI-larni transpozitsiyalangan shaklda qo'shadigan alohida omborni yig'dik. Ma'lumotlar bazasi tomonida bunday saqlashga har qanday so'rov 0,1 - 0,3 soniyada qayta ishlanadi. Boshqaruv panelida biz quyidagi natijalarni oldik:

Birinchi ochilish: 8-10 soniya
Har qanday bosish: 6-7 soniya

Tableau sarflagan vaqt quyidagilardan iborat:

1. 0,3 sek. — asboblar panelini tahlil qilish va SQL so'rovlarini kompilyatsiya qilish
2. 1,5-3 sek. — asosiy vizualizatsiya uchun Hana-da SQL so'rovlarini bajarish (1-bosqichga parallel ravishda ishlaydi)
3. 1,5-2 sek. — vizualizatsiyani ko‘rsatish, qayta hisoblash
4. 1,3 soniya. - tegishli filtr qiymatlarini olish uchun qo'shimcha SQL so'rovlarini bajarish (brend, bo'lim, shahar, do'kon), natijalarni tahlil qilish

Buni qisqacha xulosa qilish uchun

Bizga Tableau vositasi vizualizatsiya nuqtai nazaridan yoqdi. Prototiplash bosqichida biz turli vizualizatsiya elementlarini ko'rib chiqdik va ularning barchasini kutubxonalarda, jumladan, murakkab ko'p darajali segmentatsiya va ko'p haydovchili sharsharada topdik.

Savdoning asosiy ko'rsatkichlari bo'lgan asboblar panelini amalga oshirishda biz ishlashda qiyinchiliklarga duch keldik, ularni hali bartaraf eta olmaganmiz. Biz ikki oydan ko'proq vaqt sarfladik va javob tezligi maqbul bo'lgan funktsional to'liq bo'lmagan asboblar panelini oldik. Va biz o'zimiz uchun xulosalar chiqardik:

1. Tableau katta hajmdagi ma'lumotlar bilan ishlay olmaydi. Agar asl ma'lumotlar modelida sizda 10 Gb dan ortiq ma'lumotlar mavjud bo'lsa (taxminan 200 million X 50 qator), u holda asboblar paneli jiddiy ravishda sekinlashadi - har bir bosish uchun 10 soniyadan bir necha daqiqagacha. Biz jonli ulanish va ekstrakt bilan tajriba o'tkazdik. Ishlash tezligi solishtirish mumkin.
2. Bir nechta xotiradan (ma'lumotlar to'plamidan) foydalanishda cheklov. Standart vositalar yordamida ma'lumotlar to'plami o'rtasidagi munosabatni ko'rsatishning hech qanday usuli yo'q. Agar siz ma'lumotlar to'plamlarini ulash uchun vaqtinchalik echimlardan foydalansangiz, bu ishlashga katta ta'sir qiladi. Bizning holatda, biz har bir talab qilinadigan ko'rinish bo'limida ma'lumotlarni materiallashtirish va ilgari tanlangan filtrlarni saqlab qolgan holda ushbu materiallashtirilgan ma'lumotlar to'plamiga o'tish variantini ko'rib chiqdik - Tableau-da buni amalga oshirish mumkin emas edi.
3. Tableau-da dinamik parametrlarni amalga oshirish mumkin emas. Ko‘chirmada yoki jonli ulanish vaqtida ma’lumotlar to‘plamini filtrlash uchun foydalaniladigan parametrni ma’lumotlar to‘plamidan boshqa tanlov natijasi yoki boshqa SQL so‘rovi natijasi bilan to‘ldira olmaysiz, faqat mahalliy foydalanuvchi kiritishi yoki doimiy.
4. OLAP|PivotTable elementlari bilan asboblar panelini yaratish bilan bog'liq cheklovlar.
   MSTR, SAP SAC, SAP Analysis-da, agar siz hisobotga ma'lumotlar to'plamini qo'shsangiz, undagi barcha ob'ektlar sukut bo'yicha bir-biri bilan bog'liq. Tableau-da bu yo'q, ulanish qo'lda sozlanishi kerak. Bu, ehtimol, yanada moslashuvchan, lekin bizning barcha asboblar panellarimiz uchun bu elementlar uchun majburiy talabdir - shuning uchun bu qo'shimcha mehnat xarajatlari. Bundan tashqari, agar siz tegishli filtrlarni yaratsangiz, masalan, mintaqani filtrlashda shaharlar ro'yxati faqat shu mintaqa shaharlari bilan cheklangan bo'lsa, siz darhol ma'lumotlar bazasiga yoki Extractga ketma-ket so'rovlar bilan yakunlanasiz, bu sezilarli darajada sekinlashadi. asboblar paneli.
5. Funktsiyalardagi cheklovlar. Ommaviy o'zgarishlarni ekstraktda ham, ayniqsa, Live-connecta ma'lumotlar to'plamida ham amalga oshirib bo'lmaydi. Buni Tableau Prep orqali amalga oshirish mumkin, ammo bu qo'shimcha ish va o'rganish va saqlash uchun boshqa vositadir. Masalan, siz ma'lumotlarni ko'chira olmaysiz yoki uni o'zi bilan birlashtira olmaysiz. Alohida ustunlar yoki maydonlar bo'yicha o'zgartirishlar orqali nima yopiladi, ular case yoki if orqali tanlanishi kerak va bu juda murakkab SQL so'rovlarini hosil qiladi, bunda ma'lumotlar bazasi ko'p vaqtini so'rov matnini kompilyatsiya qilishga sarflaydi. Asbobning bu moslashuvchanligi vitrin darajasida hal qilinishi kerak edi, bu esa yanada murakkab saqlash, qo'shimcha yuklab olish va o'zgarishlarga olib keladi.

Biz Tableaudan voz kechganimiz yo‘q. Ammo biz Tableau-ni sanoat asboblar panelini yaratishga qodir vosita va kompaniyaning butun korporativ hisobot tizimini almashtirish va raqamlashtirish uchun vosita deb hisoblamaymiz.

Endi biz shunga o'xshash asboblar panelini boshqa vositada faol ravishda ishlab chiqmoqdamiz va shu bilan birga, uni yanada soddalashtirish uchun Tableau-dagi asboblar paneli arxitekturasini qayta ko'rib chiqishga harakat qilmoqdamiz. Jamiyat manfaatdor bo'lsa, natijalar haqida sizga aytib beramiz.

Shuningdek, biz sizning Tabeau-da qanday qilib katta hajmdagi ma'lumotlar bo'yicha tezkor boshqaruv panelini yaratishingiz mumkinligi haqida sizning g'oyalaringizni yoki maslahatlaringizni kutamiz, chunki bizda chakana savdoga qaraganda ancha ko'p ma'lumotlar mavjud veb-sayt mavjud.

Manba: www.habr.com