Tableau в търговията на дребно, наистина?

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

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

Под катa за това, с какво се сблъскахме и какво научихме.

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

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

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

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

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

Среден мениджмънт, напреднали потребители. Интересуват се от анализ на данни и могат самостоятелно да изграждат отчети при наличие на инструменти. Именно те станаха ключови потребители на аналитичните отчети в 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 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 да се прехвърля гъвкаво между различни витрини и нива, предварително изчислени за различни търговски йерархии (в примера три запитвания без УТЕ, с УТЕ1 и УТЕ2 формират различни резултати). Затова взехме решение да опростим таблото, да се откажем от търговската йерархия в таблото и да видим колко бързо може да бъде в опростена версия.

Така, на този последен етап, събрахме отделно хранилище, в което съхранявахме в транспониран вид всички 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-connection не могат да се правят масови преобразования. Това може да се направи чрез Tableau Prep, но това са допълнителни усилия и още един инструмент, който трябва да се изучава и поддържа. Например, не можете да транспонирате данни, да направите join с тях самите. Това, което се затваря чрез преобразования по отделни колони или полета, които трябва да избирате чрез case или if, поражда много сложни SQL заявки, при които базата изразходва основното си време за компилация на текста на заявката. Тези негъвкавости в инструмента трябваше да се решават на нивото на витрината, което води до усложняване на хранилището, допълнителни натоварвания и трансформации.

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

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

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

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