Час справаздачнасці ў Excel імкліва сыходзіць - трэнд на зручныя прылады прадстаўлення і аналізу інфармацыі бачны ва ўсіх сферах. Мы даўно абмяркоўвалі ўнутры цыфравізацыі пабудовы справаздачнасці і абралі сістэму візуалізацыі і self-service аналітыкі Tableau. Аляксандр Бязуглы, кіраўнік аддзела аналітычных рашэнняў і справаздачнасці Групы «М.Відэа-Эльдарада», распавёў пра досвед і вынікі пабудовы баявога дашборда.
Скажу адразу, не ўсё, што было задумана, удалося рэалізаваць, але вопыт быў цікавы, спадзяюся, ён будзе карысны і вам. А калі ў кагосьці ўзнікнуць ідэі, як можна было зрабіць лепш - буду вельмі ўдзячны за парады і ідэі.
Пад катом аб тым, з чым мы сутыкнуліся і аб чым даведаліся.
З чаго мы пачыналі
У "М. Відэа-Эльдарада" ёсць добра прапрацаваная мадэль дадзеных: структураваная інфармацыя з патрабаванай глыбінёй захоўвання і велізарная колькасць справаздач фіксаванай формы (гл. падрабязней ). З іх аналітыкі робяць альбо зводныя табліцы ці фарматаваныя рассылкі ў Excel, альбо прыгожыя прэзентацыі ў PowerPoint для канчатковых карыстачоў.
Прыкладна два гады таму замест справаздач фіксаванай формы мы пачалі ствараць аналітычныя справаздачы ў SAP Analysis (надбудова на Excel, у сутнасці – зводная табліца над OLAP рухавіком). Але гэтая прылада не змагла зачыніць запатрабаванні ўсіх карыстачоў, большасць так і працягнулі выкарыстоўваць інфармацыю, дадаткова апрацаваную аналітыкамі.
Нашы канчатковыя карыстальнікі падзяляюцца на тры катэгорыі:
Топ-мэнэджмент. Запытвае інфармацыю ў добра прадстаўленым і наглядна зразумелым выглядзе.
Middle-менеджмент, Прасунутыя юзэры. Зацікаўлены ў даследаванні дадзеных і здольныя самастойна будаваць справаздачы пры наяўнасці інструментаў. Менавіта яны сталі ключавымі карыстальнікамі аналітычных справаздач у SAP Analysis.
Масавыя карыстальнікі. Не зацікаўлены ў самастойным аналізе дадзеных, выкарыстоўваюць справаздачы з абмежаванай ступенню свабоды, у фармаце рассылак і зводных табліц у Excel.
Наша ідэя складалася ў тым, каб пакрыць запатрабаванні ўсіх карыстачоў і даць ім адзіная зручная прылада. Пачаць вырашылі з топ-мэнэджменту. Ім патрабаваліся зручныя панэлі для аналізу асноўных бізнэс-вынікаў. Так, мы стартавалі з Tableau і для пачатку абралі два кірункі: паказчыкі продажаў у розніцы і анлайн з абмежаванай глыбінёй і шырынёй аналізу, якія пакрылі б прыкладна 80% дадзеных, запытаных топ-мэнэджментам.
Паколькі карыстальнікамі дашбордаў быў топ-менеджмент, з'явіўся яшчэ адзін дадатковы KPI прадукта - хуткасць водгуку. Ніхто не будзе чакаць 20-30 секунд, пакуль абновяцца дадзеныя. Навігацыя павінна была ўкладвацца ў 4-5 секунд, а лепш адпрацоўваць маментальна. І гэтага нам дабіцца, нажаль, не атрымалася.
Вось так выглядаў макет нашага асноўнага дашборда:
Ключавая ідэя - аб'яднаць асноўныя KPI-драйверы, якіх у выніку набралася 19, злева і ўяўляць іх дынаміку і разбіўку па асноўных атрыбутах справа. Задача здаецца нескладанай, візуалізацыя лагічнай і зразумелай, пакуль не апускаешся ў дэталі.
Дэталь 1. Аб'ём даных
Асноўная табліца па продажах за год займае ў нас каля 300 млн. радкоў. Бо неабходна адбіць і дынаміку да мінулага і пазамінулага года, аб'ём дадзеных толькі па фактычных продажах каля 1 млрд радкоў. А яшчэ асобна захоўваецца інфармацыя па планавых дадзеных і блок інтэрнэт-продажаў. Таму, нават нягледзячы на тое, што мы выкарыстоўвалі пакалонкавую in-memory DB SAP HANA, хуткасць працы запыту з выбарам усіх паказчыкаў за адзін тыдзень з бягучых сховішчаў на лёце складала каля 15-20 секунд. Рашэнне гэтай задачы напрошваецца само сабой - дадатковая матэрыялізацыя дадзеных. Але ў ёй таксама ёсць падводныя камяні, аб іх ніжэй.
Дэталь 2. Неадытыўныя паказчыкі
У нас многія KPI завязаны на колькасці чэкаў. І гэты паказчык уяўляе сабой COUNT DISTINCT колькасці радкоў (загалоўкаў чэкаў) і паказвае розныя сумы ў залежнасці ад выбраных атрыбутаў. Для прыкладу, як гэты паказчык і вытворны ад яго павінны лічыцца:
Для карэктнасці разлікаў можна:
- Праводзіць разлік падобных паказчыкаў на лета ў сховішча;
- Праводзіць разлік на ўсім аб'ёме дадзеных у Tableau, г.зн. па запыце ў Tableau аддаваць усе дадзеныя па абраных фільтрах у гранулярнасці пазіцыі чэкаў;
- Зрабіць матэрыялізаваную вітрыну, у якой будуць разлічаны ўсе паказчыкі ва ўсіх варыянтах выбарак, якія даюць розныя неадытыўныя вынікі.
Зразумела, што ў прыкладзе УТЕ1 і УТЕ2 - гэта атрыбуты матэрыялу, якія прадстаўляюць таварную іерархію. Гэта не статычная рэч, праз яе ідзе кіраванне ўнутры кампаніі, т.я. за розныя таварныя групы адказваюць розныя менеджэры. У нас было шмат глабальных пераглядаў гэтай іерархіі, калі мяняліся ўсе ўзроўні, калі пераглядаліся ўзаемасувязі, так і пастаянных кропкавых змен, калі адна група пераходзіць з аднаго вузла ў іншы. У звычайнай справаздачнасці ўсё гэта лічыцца на лёце з атрыбутаў матэрыялу, у выпадку матэрыялізацыі гэтых дадзеных неабходна распрацаваць механізм адсочвання падобных змен і аўтаматычнай перагрузкі гістарычных дадзеных. Вельмі нетрывіяльная задача.
Дэталь 3. Параўнанне даных
Гэты пункт падобны да папярэдняга. Сутнасць у тым, што ў кампаніі пры аналізе прынята фармаваць некалькі ўзроўняў параўнання з мінулым перыядам:
Параўнанне з мінулым перыядам (дзень да дня, тыдзень да тыдня, месяц да месяца)
У гэтым параўнанні мяркуецца, што ў залежнасці ад абранага карыстальнікам перыяду (да прыкладу 33 тыдзень года) мы павінны паказаць дынаміку да 32 тыдні, калі б мы абралі дадзеныя за месяц, напрыклад травень, то гэтае параўнанне паказала б дынаміку да красавіка.
Параўнанне з мінулым годам
Тут асноўны нюанс у тым, што пры параўнанні па днях і па тыднях вы бераце не той жа самы дзень мінулага года, г.зн. вы не можаце проста паставіць бягучы год мінус адзін. Вы павінны глядзець параўноўваны дзень тыдня. А пры параўнанні месяцаў, наадварот, трэба браць роўна той самы каляндарны дзень мінулага года. Таксама ёсць нюансы з высакоснымі гадамі. У зыходных сховішчах уся інфармацыя размеркавана па днях, тамака няма асобных палёў з тыднямі, месяцамі, гадамі. Таму для атрымання поўнага аналітычнага зрэзу ў панэлі, трэба лічыць не адзін перыяд, напрыклад тыдзень, а 4 тыдні, і потым гэтыя дадзеныя яшчэ параўнаць, адбіць дынаміку, адхіленні. Адпаведна, гэтую логіку фармавання параўнання ў дынаміку таксама можна рэалізоўваць альбо ў Tableau, альбо на боку вітрыны. Так, і пра гэтыя дэталі мы вядома ведалі і думалі яшчэ на этапе праектавання, але іх уплыў на прадукцыйнасць канчатковага дашборда спрагназаваць было складана.
Пры ўкараненні дашборда ішлі мы доўгім Agile-шляхам. Наша задача была як мага хутчэй даць на тэсціраванне працоўны інструмент з патрэбнымі дадзенымі. Таму мы ішлі спрынтамі і адштурхоўваліся ад мінімізацыі работ на баку бягучага сховішча.
Частка 1. Вера ў Tableau
Для спрашчэння ІТ-падтрымкі і хуткага ўкаранення змен мы прынялі рашэнне рабіць логіку разліку неадытыўная паказчыкаў і параўнанне мінулых перыядаў у Tableau.
Этап 1. Усё ў Live, ніякіх дапрацовак вітрын.
На гэтым этапе мы падлучылі Tableau да бягучых вітрынаў і вырашылі паглядзець, як будзе лічыцца колькасць чэкаў за адзін год.
Вынік:
Адказ быў гнятлівы - 20 хвілін. Перагонка дадзеных па сетцы, высокая нагрузка на Tableau. Мы зразумелі, што логіку з неадытыўнымі паказчыкамі трэба рэалізоўваць на HANA. Гэта нас не моцна пудзіла, у нас ужо быў падобны досвед з BO і Analysis і будаваць хуткія вітрыны ў HANA, якія выдаюць правільна палічаныя неаддытыўныя паказчыкі, мы ўмелі. Цяпер заставалася падбудаваць іх пад Tableau.
Этап 2. Цюнім вітрыны, ніякай матэрыялізацыі, усё на ляту.
Мы зрабілі асобную новую вітрыну, якая на ляту выдавала патрабаваныя дадзеныя для TABLEAU. У цэлым у нас атрымаўся добры вынік, мы скарацілі час фармавання ўсіх паказчыкаў за адзін тыдзень да 9-10 секунд. І сапраўды чакалі, што ў Tableau час водгуку дашборда будзе 20-30 секунд на першым адкрыцці і далей за рахунак кэша ад 10 да 12, што ў цэлым нас бы задаволіла.
Вынік:
Першае адкрытыя дашборда: 4-5 хвіліны
Любы клік: 3-4 хвіліны
Такога дадатковага дадатку да працы вітрыны ніхто не чакаў.
Частка 2. Апусканне ў Tableau
Этап 1. Аналіз прадукцыйнасці Tableau і хуткі цюнінг
Мы пачалі аналізаваць, на што Tableau марнуе асноўны час. І для гэтага ёсць суцэль добры інструментар, што, вядома, плюс Tableau. Асноўнай праблемай, якую мы выявілі, сталі вельмі складаныя SQL-запыты, якія будаваў Tableau. Звязаныя яны былі першым чынам з:
- транспанаваннем дадзеных. Бо Tableau няма прылад для транспанавання dataset'ов, то для пабудовы левай часткі дашборда з дэталёвым уяўленнем усіх KPI, нам прыйшлося фармаваць табліцу праз case. Памер SQL-запытаў у БД дасягаў 120 знакаў.
- Выбарам перыяду часу. Такі запыт на ўзроўні БД займаў больш часу на кампіляцыю, чым на выкананне:
Г.зн. апрацоўка запыту 12 секунд + 5 секунд выкананне.
Мы вырашылі спрасціць логіку вылічэнняў на баку Tableau і перанесці яшчэ адну частку вылічэнняў на вітрыну і ўзровень БД. Гэта прынесла добрыя вынікі.
Спачатку мы зрабілі транспанаванне на лета, зрабілі яго праз full outer join на фінальным этапе разліку VIEW, паводле вось такога падыходу, апісанага на wiki и .
Гэта значыць мы зрабілі наладкавую табліцу - матрыцу транспанавання (21х21) і атрымалі ўсе паказчыкі ў парадковай разбіўцы.
было:
стала:
На самое транспанаванне БД часу амаль не марнуе. Запыт па ўсіх паказчыках за тыдзень адпрацоўваў па-ранейшаму прыкладна за 10 секунд. Але затое згубілася гнуткасць у частцы пабудовы дашборда па канрэтным паказчыку, г.зн. для правай часткі дашборда дзе прадстаўлена дынаміка і дэталёвая разбіўка канкрэтнага паказчыка раней вітрына адпрацоўвала за 1-3 секунды, т.я. запыт ішоў па адным паказчыку, а зараз БД заўсёды адбірала ўсе паказчыкі і фільтравала вынік ужо перад тым як вярнуць вынік у Tableau.
У выніку хуткасць працы дашборда скарацілася амаль у 3 разы.
Вынік:
- 5 сек - парсінг дашборда, візуалізацый
- 15-20 сек - падрыхтоўка да кампіляцыі запытаў з выкананнем прадлікаў у Tableau
- 35-45 сек - кампіляцыя SQL-запытаў і паралельна-паслядоўнае іх выкананне ў Hana
- 5 сек - апрацоўка вынікаў, сартаванне, пералік візуалізацый у Tableau
- Вядома, такія вынікі не задавальнялі бізнэс, і мы працягнулі аптымізацыю.
Этап 2. Мінімум логікі ў Tableau, поўная матэрыялізацыя
Мы разумелі, што пабудаваць дашборд з часам водгуку ў некалькі секунд на вітрыне, якая працуе 10 секунд немагчыма, і разглядалі варыянты матэрыялізацыі дадзеных на баку БД менавіта пад патрабаваны дашборд. Але сутыкнуліся з глабальнай праблемай, апісанай вышэй - неаддзіціны паказчыкі. Мы не змаглі зрабіць так, каб пры змене фільтраў ці разгортак Tableau гнутка перамыкаўся паміж рознымі вітрынамі і ўзроўнямі, разлічанымі для розных таварных іерархій (у прыкладзе тры запыты без УТЕ, з УТЕ1 і УТЕ2 фармуюць розныя вынікі). Таму мы прынялі рашэнне спрасціць дашборд, адмовіцца ад таварнай іерархіі ў дашбордзе і паглядзець, наколькі хуткім ён зможа быць у спрошчанай версіі.
Такім чынам, на гэтым апошнім этапе мы сабралі асобнае сховішча, у якім склалі ў транспанаваным выглядзе ўсё KPI. На баку БД любы запыт да такога сховішча адпрацоўвае за 0,1 - 0,3 секунды. У дашбордзе мы атрымалі наступныя вынікі:
Першае адкрыццё: 8-10 секунд
Любы клік: 6-7 секунд
Час, якое марнуе Tableau, складаецца з:
- 0,3 сек. - парсінг дашборда і кампіляцыя SQL-запытаў
- 1,5-3 сек. - Выкананне SQL-запытаў у Hana для асноўных візуалізацый (запускаецца паралельна з п.1)
- 1,5-2 сек. - Рэндэрынг, пералік візуалізацый
- 1,3сек. - Выкананне дадатковых SQL-запытаў для атрымання рэлевантных значэнняў фільтраў (Брэнд, Дывізіён, Горад, Крама), парсінг вынікаў
Калі падводзіць кароткі вынік
Нам спадабалася прылада Tableau з пункта гледжання візуалізацыі. На этапе макетавання мы разглядалі розныя элементы візуалізацыі і ўсе іх знайшлі ў бібліятэках, у тым ліку складаныя шматузроўневыя сегментацыі і шматдрайверныя waterfall.
Укараняючы дашборды з асноўнымі паказчыкамі продажаў, мы сутыкнуліся са складанасцямі ў прадукцыйнасці, якія пакуль не змаглі пераадолець. Мы патрацілі больш за два месяцы і атрымалі функцыянальна няпоўны дашборд, хуткасць водгуку якога на мяжы дапушчальнага. І для сябе зрабілі высновы:
- Tableau не ўмее працаваць з вялікімі аб'ёмамі дадзеных. Калі ў зыходнай мадэлі дадзеных у вас больш за 10 Гб дадзеных (прыкладна 200 млн. Х 50 радкоў), то дашборд сур'ёзна запавольваецца - ад 10 секунд да некалькіх хвілін на кожны клік. Мы эксперыментавалі і пры live-connect'е і пры экстракце. Хуткасць працы супастаўная.
- Абмежаванне пры выкарыстанні некалькіх сховішчаў (датасэтаў). Няма магчымасці стандартнымі сродкамі паказваць узаемасувязь датасетаў. Калі выкарыстоўваць абыходныя рашэнні для сувязі датасетаў, тое гэта моцна адаб'ецца на прадукцыйнасці. У нашым выпадку мы разглядалі варыянт матэрыялізацыі дадзеных у кожным патрэбным разрэзе ўяўленняў і на гэтых матэрыялізаваных датасетах рабіць пераключэнні з захаваннем абраных раней фільтраў – гэта аказалася немагчыма зрабіць у Tableau.
- У Tableau немагчыма зрабіць дынамічныя параметры. Вы не можаце параметр, якія выкарыстоўваецца для фільтравання датасета ў экстракце або пры live-connecte, запаўняць вынікам іншай выбаркі з датасета або выніку іншага SQL-запыту, толькі натыўны ўвод карыстальніка або канстанта.
- Абмежаванні, звязаныя з пабудовай дашборда з элементамі OLAP|Зводнай табліцы.
У MSTR, SAP SAC, SAP Analysis, калі вы ў справаздачу дадаеце датасет, то ўсе аб'екты на ім злучаны сябар з сябрам па змаўчанні. У Tableau гэтага няма, сувязь трэба наладжваць уручную. Гэта, напэўна, больш гнутка, але для ўсіх нашых дашбордаў гэта абавязковае патрабаванне да элементаў - таму гэта дадатковыя працавыдаткі. Больш за тое, калі вы робіце злучаныя фільтры, каб, да прыкладу, пры фільтрацыі рэгіёна спіс гарадоў быў абмежаваны толькі гарадамі гэтага рэгіёна, вы адразу пападаеце на паслядоўныя запыты да БД ці Экстракту, што прыкметна запавольвае дашборд. - Абмежаванні ў функцыях. Як над экстрактам, так і ТЫМ БОЛЬШ над датасетам з Live-connecta нельга рабіць масавыя пераўтварэнні. Гэта можна рабіць праз Tableau Prep, але гэта дадатковыя працавыдаткі і яшчэ адна прылада, якія трэба вывучаць і падтрымліваць. Вы, напрыклад, не можаце транспанаваць дадзеныя, зрабіць join іх саміх з сабой. Што зачыняецца праз пераўтварэнні па асобных слупках або палях, якія трэба выбіраць праз case альбо if і гэта спараджае, вельмі складаныя SQL-запыты, пры якіх база асноўны час марнуе на кампіляцыю тэксту запыту. Гэтыя нягнуткасці прылады прыйшлося вырашаць на ўзроўні вітрыны, што прыводзіць да ўскладнення сховішча, доп.загрузкам і трансфармацыям.
Мы не паставілі крыж на Tableau. Але як на прыладу, здольны будаваць прамысловыя дашборды і сродак, з дапамогай якога можна замяніць і дыджыялізаваць усю сістэму карпартатыўнай справаздачнасці кампаніі, Tableau не разгляданы.
Цяпер актыўна распрацоўваем аналагічны дашборд на іншай прыладзе і раўналежна спрабуем перагледзець архітэктуру дашборда ў Tableau, каб яшчэ больш яе спрасціць. Калі супольнасці будзе цікава - раскажам аб выніках.
Таксама чакаем вашых ідэй ці парад, пра тое, як у Tabeau можна будаваць хуткія дашборды над такімі вялікімі аб'ёмамі дадзеных, бо ў нас і сайт, дзе дадзеных значна больш чым у розніцы.
Крыніца: habr.com