Tableau в ритейл, наистина ли?

Времето за отчетност в Excel бързо изчезва – тенденцията към удобни инструменти за представяне и анализ на информацията се вижда във всички сфери. От доста време обсъждаме цифровизацията на отчетността и избрахме системата за визуализация и самостоятелен анализ Tableau. Александър Безуглий, ръководител на отдела за аналитични решения и отчетност в Групата "М.Видео-Елдорадо", разказа за опита и резултатите от изграждането на боевия дашборд.

Ще кажа направо, не всичко, което беше замислено, успяхме да реализираме, но опитът беше интересен, надявам се, че ще бъде полезен и за вас. А ако някой има идеи как можеше да стане по-добре – ще съм много благодарен за съвети и идеи.

Под кат е описано какво срещнахме и какво научихме.

С какво започнахме

В "М.Видео-Елдорадо" има добре разработена модел на данни: структурирана информация с необходимата дълбочина на съхранение и огромен брой отчети с фиксирана форма (вижте по-подробно в тази статия). От тях аналитиците правят или сводни таблици, или форматирани разпратки в Excel, или красиви презентации в PowerPoint за крайните потребители.

Преди около две години вместо отчети с фиксирана форма започнахме да създаваме аналитични отчети в SAP Analysis (добавка за Excel, по същество – сводна таблица над OLAP двигателя). Но този инструмент не успя да задоволи нуждите на всички потребители, повечето от тях продължиха да използват информацията, допълнително обработена от аналитиците.

Нашите крайни потребители се делят на три категории:

Топ-мениджмънт. Заявяват информация в добре представен и визуално разбираем вид.

Среден мениджмънт, напреднали потребители. Интересуват се от проучване на данните и могат самостоятелно да изграждат отчети при наличие на инструменти. Именно те станаха ключови потребители на аналитичните отчети в SAP Analysis.

Масови потребители. Не се интересуват от самостоятелния анализ на данните, използват отчети с ограничена свобода, в формат на разпратки и сводни таблици в Excel.

Нашата идея беше да покрием нуждите на всички потребители и да им предоставим един удобен инструмент. Започнахме с топ-мениджмънта, който се нуждаеше от удобни панели за анализ на основните бизнес резултати. Така стартирахме с Tableau и на първо място избрахме две направления: показатели за продажби на дребно и онлайн с ограничена дълбочина и ширина на анализа, които да покрият около 80% от данните, заявени от топ-мениджмънта.

Тъй като потребителите на дашбордовете бяха топ-мениджмънт, се появи и един допълнителен KPI на продукта - скорост на отговор. Никой не ще чака 20-30 секунди, докато данните се обновят. Навигацията трябваше да бъде в интервала 4-5 секунди, а най-добре - да работи моментално. И за съжаление, не успяхме да постигнем това.

Ето как изглеждаше макетът на нашия основен дашборд:

Ключовата идея е да обединим основните KPI драйвери, които в крайна сметка нараснаха до 19, отляво и да представим тяхната динамика и разбивка по основните атрибути отдясно. Задачата изглежда несложна, визуализацията е логична и ясна, стига да не се потопите в детайлите.

Детайл 1. Обем на данните

Основната таблица по продажбите за година съдържа около 300 млн. реда. Тъй като е необходимо да отразим и динамиката спрямо предходната и по-предходната година, обемът на данните само по фактическите продажби е около 1 млрд. реда. Освен това се съхранява отделно информация за планираните данни и блок интернет-продажби. Ето защо, въпреки че използвахме колоночна in-memory база данни 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 000 символа.

— избор на времеви период. Такава заявка на нивото на базата данни отнемаше повече време за компилация, отколкото за изпълнение:

Т.е. обработката на заявката 12 секунди + 5 секунди изпълнение.

Решихме да опростим логиката на изчисленията от страна на Tableau и да пренесем още една част от изчисленията на витрината и нивото на базата данни. Това донесе добри резултати.

Първо направихме транспонирането на момента, чрез full outer join на финалния етап от изчислението на VIEW, съгласно такъв подход, описан в wiki Transpose — Wikipedia, the free encyclopedia и Elementary matrix — Wikipedia, the free encyclopedia.

Т.е. създадохме настроечна таблица – матрица за транспониране (21х21) и получихме всички показатели в редове.

Беше:


Стана:


Самото транспониране на базата данни почти не отнема време. Запитът за всички показатели за седмицата все още се изпълнява примерно за 10 секунди. Но загубихме гъвкавост в частта за изграждане на табло за конкретен показател, т.е. за дясната част на таблото, където е представена динамиката и детайлният разбив на конкретния показател, преди витрината се изпълняваше за 1-3 секунди, тъй като запитването беше по един показател, а сега базата данни винаги избираше всички показатели и филтрираше резултата вече преди да върне резултата в Tableau.

В резултат на това скоростта на работа на таблото намаля почти три пъти.

Резултат:

1. 5 сек — парсинг на таблото, визуализациите
2. 15-20 сек — подготовка за компилация на запитвания с изпълнение на предварителни изчисления в Tableau
3. 35-45 сек — компилация на SQL запитвания и паралелно-последователно тяхното изпълнение в Hana
4. 5 сек — обработка на резултатите, сортиране, преизчисляване на визуализациите в Tableau
5. Разбира се, такива резултати не удовлетворяваха бизнеса, и ние продължихме оптимизацията.

Етап 2. Минимум логика в Tableau, пълна материализация

Разбирахме, че да изградим табло с време за отговор от няколко секунди на витрина, която работи 10 секунди, е невъзможно, и разглеждахме варианти за материализация на данните на страна на базата данни именно под изискваното табло. Но се сблъскахме с глобален проблем, описан по-горе – неадитивни показатели. Не успяхме да направим така, че при промяна на филтрите или разгъването Tableau гъвкаво да превключва между различни витрини и нива, предварително изчислени за различни търговски йерархии (в примера три запитвания без UTE, с UTE1 и UTE2 формират различни резултати). Затова взехме решение да опростим таблото, да се откажем от търговската йерархия в таблото и да видим колко бързо може да бъде в опростена версия.

И така, на този последен етап събрахме отделно хранилище, в което събрахме в транспониран вид всички KPI. На страната на базата данни всяко запитване към такова хранилище се изпълнява за 0,1 – 0,3 секунди. В таблото получихме следните резултати:

Първо отваряне: 8-10 секунди
Всеки клик: 6-7 секунди

Времето, което отнема Tableau, се състои от:

1. 0,3 сек. — парсинг на таблото и компилация на SQL запитвания
2. 1,5-3 сек. — изпълнение на SQL запитвания в Hana за основните визуализации (стартира паралелно с т.1)
3. 1,5-2 сек. — рендериране, преизчисляване на визуализациите
4. 1,3 сек. — изпълнение на допълнителни SQL запитвания за получаване на релевантни стойности на филтри (Бранд, Дивизия, Град, Магазин), парсинг на резултати

Ако обобщим накратко

На нас ни хареса инструментът Tableau по отношение на визуализацията. В етапа на макетиране разгледахме различни елементи на визуализация и ги намерихме всички в библиотеките, включително сложни многостепенни сегментации и многодрайверни waterfall.

При внедряване на дашбордове с основни показатели за продажби се сблъскахме с проблеми с производителността, които все още не успяхме да преодолеем. Похарчихме повече от два месеца и получихме функционално непълен дашборд, скоростта на отговора на който е на границата на допустимото. И си направихме изводи:

1. Tableau не може да работи с големи обеми данни. Ако в основния модел на данните имате над 10 Гб данни (приблизително 200 млн. Х 50 реда), дашбордът значително забавя - от 10 секунди до няколко минути за всеки клик. Експериментирахме както при live-connect, така и при екстракт. Скоростта на работа е сравнима.
2. Ограничение при използване на няколко хранилища (датасети). Няма възможност стандартно да се указва взаимовръзката на датасетите. Ако се използват обходни решения за свързване на датасетите, това ще се отрази сериозно на производителността. В нашия случай разглеждахме опцията за материализиране на данните във всеки необходим разрез на представленията и на тези материализирани датасети да правим превключвания със запазване на предишно избраните филтри - това се оказа невъзможно да се направи в Tableau.
3. В Tableau не е възможно да се създават динамични параметри. Не може да попълните параметър, който се използва за филтриране на датасета в екстракта или при live-connect, с резултата от друга извадка от датасета или резултата от друга SQL заявка, само нативно въвеждане на потребителя или константа.
4. Ограничения, свързани с изграждането на дашборд с елементи на OLAP|Сводни таблици.
   В MSTR, SAP SAC, SAP Analysis, когато добавяте данни към отчет, всички обекти са свързани помежду си по подразбиране. В Tableau това липсва, свързаността трябва да се настройва ръчно. Вероятно е по-гъвкаво, но за всички наши контролни табла това е задължително изискване към елементите – затова представлява допълнителни трудозатрати. Освен това, ако правите свързани филтри, за да ограничите списъка на градовете до тези в региона, веднага попадате на последователни заявки към базата данни или екстракта, което значително забавя контролното табло.
5. Ограничения в функциите. Както при екстракта, така и особено при датасета от Live-connect не могат да се правят масови преобразования. Това може да стане чрез Tableau Prep, но изисква допълнителни усилия и още един инструмент, който трябва да се изучава и поддържа. Например, не можете да транспонирате данни, да направите join на самите тях. Това се закрива чрез преобразования по отделни колони или полета, които трябва да избирате чрез case или if, и това поражда много сложни SQL-запитвания, при които базата основно време губи за компилация на текста на запитването. Тези негъвкавости на инструмента трябваше да бъдат решавани на ниво витрина, което води до усложняване на хранилището, допълнителни натоварвания и трансформации.

Не сме поставили кръст на Tableau. Но като инструмент, способен да изгражда промишлени контролни табла и средство, с което може да заменя и дигитализира цялата система за корпоративна отчетност на компанията, Tableau не разглеждаме.

Сега активно разработваме аналогично контролно табло с друг инструмент и паралелно опитваме да преразгледаме архитектурата на контролното табло в Tableau, за да я опростим още повече. Ако на обществото му бъде интересно – ще споделим резултатите.

Също така очакваме вашите идеи или съвети за това как в Tableau може да се изграждат бързи контролни табла над толкова големи обеми данни, тъй като имаме и сайт, където данните са много повече, отколкото в търговията.

Източник: habr.com