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

Времето за отчитане в Excel бързо изчезва – тенденцията към удобни инструменти за представяне и анализ на информация е видима във всички области. Дълго време вътрешно обсъждахме дигитализацията на отчетите и избрахме системата за визуализация и анализ на самообслужване Tableau. Александър Безугли, ръководител на отдела за аналитични решения и отчети на M.Video-Eldorado Group, говори за опита и резултатите от изграждането на бойно табло.

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

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

Откъде започнахме

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

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

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

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

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

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

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

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

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

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

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

Нашата основна таблица за годишни продажби заема около 300 милиона реда. Тъй като е необходимо да се отрази динамиката за миналата и предходната година, обемът на данните само за реалните продажби е около 1 милиард реда. Информацията за планираните данни и блока за онлайн продажби също се съхраняват отделно. Следователно, въпреки че използвахме колонната база данни в паметта SAP HANA, скоростта на заявката с избора на всички индикатори за една седмица от текущото хранилище в движение беше около 15-20 секунди. Решението на този проблем се подсказва - допълнителна материализация на данни. Но има и клопки, повече за тях по-долу.

Детайл 2. Неадитивни индикатори

Много от нашите KPI са обвързани с броя на разписките. И този индикатор представлява COUNT DISTINCT от броя на редовете (проверете заглавките) и показва различни суми в зависимост от избраните атрибути. Например, как трябва да се изчисли този показател и неговата производна:

За да направите изчисленията си правилни, можете:

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

Ясно е, че в примера UTE1 и UTE2 са материални атрибути, представляващи продуктовата йерархия. Това не е нещо статично, управлението във фирмата става чрез него, защото... За различни продуктови групи отговарят различни мениджъри. Имахме много глобални ревизии на тази йерархия, когато всички нива се промениха, когато връзките бяха ревизирани и постоянни промени в точките, когато една група се премести от един възел в друг. При конвенционалното отчитане всичко това се изчислява в движение от атрибутите на материала; в случай на материализиране на тези данни е необходимо да се разработи механизъм за проследяване на такива промени и автоматично презареждане на исторически данни. Много нетривиална задача.

Детайл 3. Сравнение на данни

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

Сравнение с предходния период (ден за ден, седмица за седмица, месец за месец)

При това сравнение се предполага, че в зависимост от периода, избран от потребителя (например 33-та седмица от годината), трябва да покажем динамиката до 32-та седмица; ако сме избрали данни за месец, например май , тогава това сравнение ще покаже динамиката към април.

Сравнение с миналата година

Основният нюанс тук е, че при сравняване по дни и по седмици не се взема същия ден от миналата година, т.е. не можете просто да поставите текущата година минус едно. Трябва да погледнете деня от седмицата, който сравнявате. Когато сравнявате месеците, напротив, трябва да вземете точно същия календарен ден от миналата година. Има и нюанси с високосните години. В оригиналните хранилища цялата информация е разпределена по дни; няма отделни полета със седмици, месеци или години. Следователно, за да получите пълно аналитично напречно сечение в панела, трябва да преброите не един период, например седмица, а 4 седмици и след това да сравните тези данни, да отразите динамиката, отклоненията. Съответно, тази логика за генериране на сравнения в динамика може също да бъде приложена или в Tableau, или от страната на витрината. Да, и разбира се, ние знаехме и обмисляхме тези детайли на етапа на проектиране, но беше трудно да се предвиди тяхното въздействие върху работата на крайното арматурно табло.

При внедряването на таблото следвахме дългия Agile път. Нашата задача беше възможно най-бързо да предоставим работещ инструмент с необходимите данни за тестване. Затова тръгнахме на спринтове и започнахме от минимизиране на работата от страна на текущото хранилище.

Част 1: Вяра в Tableau

За да опростим ИТ поддръжката и бързо да внедрим промените, решихме да направим логиката за изчисляване на неадитивни индикатори и сравняване на минали периоди в Tableau.

Етап 1. Всичко е на живо, без модификации на прозореца.

На този етап свързахме 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 няма инструменти за транспониране на набори от данни, за да изградим лявата страна на таблото за управление с подробно представяне на всички KPI, трябваше да създадем таблица, използвайки случай. Размерът на SQL заявките в базата данни достигна 120 000 знака.

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

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

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

Първо, направихме транспонирането в движение, направихме го чрез пълно външно свързване на последния етап от изчислението на VIEW, съгласно този подход, описан в wiki Транспониране - Wikipedia, безплатната енциклопедия и Елементарна матрица - Wikipedia, безплатната енциклопедия.

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

Беше:


Стана:


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

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

Резултати:

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 от гледна точка на визуализация. На етапа на прототипиране разгледахме различни елементи за визуализация и ги намерихме всички в библиотеки, включително сложна многостепенна сегментация и многодрайверен водопад.

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

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

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

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

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

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