Табелата во малопродажба, навистина?

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

Веднаш ќе кажам дека не се реализираше сè што беше планирано, но искуството беше интересно, се надевам дека ќе ви биде корисно и вам. И ако некој има некои идеи за тоа како може да се направи подобро, би бил многу благодарен за вашите совети и идеи.

Под резот е за тоа што наидовме и за што научивме.

Каде почнавме?

M.Video-Eldorado има добро развиен модел на податоци: структурирани информации со потребната длабочина на складирање и огромен број извештаи во фиксна форма (видете повеќе детали тука е овој напис). Од нив, аналитичарите прават или стожерни табели или форматирани билтени во Excel, или прекрасни PowerPoint презентации за крајните корисници.

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

Нашите крајни корисници спаѓаат во три категории:

Врвен менаџмент. Бара информации на добро презентиран и јасно разбирлив начин.

Среден менаџмент, напредни корисници. Заинтересирани за истражување на податоци и способни самостојно да градат извештаи доколку се достапни алатки. Тие станаа клучни корисници на аналитичките извештаи во SAP Analysis.

Масовни корисници. Тие не се заинтересирани за независно анализирање на податоците, тие користат извештаи со ограничен степен на слобода, во формат на билтени и стожерни табели во Excel.

Нашата идеја беше да ги покриеме потребите на сите корисници и да им дадеме единствена, удобна алатка. Решивме да започнеме со врвниот менаџмент. Ним им беа потребни контролни табли кои се лесни за употреба за да ги анализираат клучните деловни резултати. Така, започнавме со Tableau и најпрво избравме две насоки: показатели за продажба на мало и онлајн со ограничена длабочина и широчина на анализа, кои би опфатиле приближно 80% од податоците што ги бара врвниот менаџмент.

Бидејќи корисниците на контролните табли беа врвно раководство, се појави уште еден дополнителен KPI на производот - брзина на одговор. Никој нема да чека 20-30 секунди за да се ажурираат податоците. Навигацијата требаше да се направи во рок од 4-5 секунди, или уште подобро, веднаш. И ние, за жал, не успеавме да го постигнеме тоа.

Вака изгледаше распоредот на нашата главна контролна табла:

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

Детали 1. Обем на податоци

Нашата главна табела за годишна продажба зафаќа околу 300 милиони редови. Бидејќи е неопходно да се одрази динамиката за минатата и претходната година, обемот на податоци само за реалната продажба е околу 1 милијарда линии. Информациите за планираните податоци и блокот за онлајн продажба исто така се чуваат посебно. Затоа, иако го користевме колонообразниот во меморијата DB SAP HANA, брзината на барањето со избирање на сите индикатори за една недела од тековното складирање на летот беше околу 15-20 секунди. Решението на овој проблем се сугерира - дополнителна материјализација на податоците. Но, има и стапици, повеќе за нив подолу.

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

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

За да ги направите вашите пресметки точни, можете:

• Пресметајте ги таквите индикатори на летот во складиштето;
• Вршете пресметки на целиот обем на податоци во Tableau, т.е. по барање во Табела, наведете ги сите податоци според избраните филтри во грануларноста на позицијата на приемот;
• Направете материјализирана изложба во која сите индикатори ќе се пресметуваат во сите опции за примероци кои даваат различни резултати без додавање.

Јасно е дека во примерот UTE1 и UTE2 се материјални атрибути што ја претставуваат хиерархијата на производот. Ова не е статична работа, преку неа се одвива управувањето во компанијата, бидејќи ... Различни менаџери се одговорни за различни групи производи. Имавме многу глобални ревизии на оваа хиерархија, кога сите нивоа се менуваа, кога односите беа ревидирани и постојани промени на точките, кога една група се пресели од еден јазол во друг. Во конвенционалното известување, сето ова се пресметува на лето од атрибутите на материјалот; во случај на материјализација на овие податоци, неопходно е да се развие механизам за следење на таквите промени и автоматско повторно вчитување на историските податоци. Многу нетривијална задача.

Детал 3. Споредба на податоци

Оваа точка е слична на претходната. Во крајна линија е дека кога се анализира компанија, вообичаено е да се формираат неколку нивоа на споредба со претходниот период:

Споредба со претходниот период (ден на ден, недела во недела, месец до месец)

Во оваа споредба, се претпоставува дека во зависност од периодот што го одбрал корисникот (на пример, 33-та недела од годината), треба да ја прикажеме динамиката до 32-та недела; ако сме избрале податоци за еден месец, на пример, мај , тогаш оваа споредба би ја покажала динамиката до април.

Споредба со минатата година

Главната нијанса овде е дека кога се споредуваат по ден и по недела, не го земате истиот ден од минатата година, т.е. не можете само да ја ставите тековната година минус еден. Мора да го погледнете денот во неделата што го споредувате. Кога споредувате месеци, напротив, треба да го земете точно истиот календарски ден од минатата година. Има и нијанси со престапни години. Во оригиналните складишта, сите информации се дистрибуираат по ден; нема посебни полиња со недели, месеци или години. Затоа, за да добиете целосен аналитички пресек во панелот, треба да броите не еден период, на пример една недела, туку 4 недели, а потоа да ги споредите овие податоци, да ја одразите динамиката, отстапувањата. Според тоа, оваа логика за генерирање споредби во динамиката може да се имплементира или во Tableau или на страната на продавницата. Да, и секако знаевме и размислувавме за овие детали во фазата на дизајнирање, но беше тешко да се предвиди нивното влијание врз перформансите на конечната контролна табла.

При спроведувањето на контролната табла, ја следевме долгата Agile патека. Наша задача беше да обезбедиме работна алатка со потребните податоци за тестирање што е можно побрзо. Затоа, отидовме во спринтови и почнавме со минимизирање на работата на страната на тековното складирање.

Дел 1: Вера во табела

За да ја поедноставиме ИТ поддршката и брзо да ги имплементираме промените, решивме да ја направиме логиката за пресметување на индикатори кои не се додаваат и споредуваат минатите периоди во Tableau.

Фаза 1. Сè е во живо, без модификации на прозорецот.

Во оваа фаза, го поврзавме Tableau со сегашните излози и решивме да видиме како ќе се пресмета бројот на сметки за една година.

Резултатот е:

Одговорот беше депресивен - 20 минути. Пренос на податоци преку мрежа, големо оптоварување на Tableau. Сфативме дека на ХАНА треба да се имплементира логика со неадитивни индикатори. Ова не не исплаши многу, веќе имавме слично искуство со BO и Analysis и знаевме како да изградиме брзи витрини во HANA кои произведуваат правилно пресметани индикатори без додавање. Сега остана само да ги прилагодиме на Табло.

Фаза 2. Ги подесуваме витрините, нема материјализација, сè е во лет.

Создадовме посебна нова изложба која ги произведе потребните податоци за TABLEAU on the fly. Во принцип, добивме добар резултат, го намаливме времето за генерирање на сите индикатори за една недела на 9-10 секунди. И искрено очекувавме дека во Tableau времето на одзив на контролната табла ќе биде 20-30 секунди на првото отворање и потоа поради кешот од 10 до 12, што генерално ќе ни одговара.

Резултатот е:

Прва отворена контролна табла: 4-5 минути
Секое кликнување: 3-4 минути
Никој не очекуваше вакво дополнително зголемување на работата на излогот.

Дел 2. Нурнете во Табела

Фаза 1. Анализа на перформансите на табела и брзо подесување

Почнавме да анализираме каде Tableau го поминува поголемиот дел од своето време. И има доста добри алатки за ова, што, се разбира, е плус на Tableau. Главниот проблем што го идентификувавме беа многу сложените SQL прашања што ги градеше Tableau. Тие првенствено беа поврзани со:

— транспонирање на податоци. Бидејќи Tableau нема алатки за транспонирање на збирки на податоци, за да ја изградиме левата страна на контролната табла со детална репрезентација на сите KPI, моравме да создадеме табела со помош на букви. Големината на SQL барањата во базата на податоци достигна 120 знаци.

- избор на временски период. Ваквото барање на ниво на база на податоци бараше повеќе време да се состави отколку да се изврши:

Оние. обработка на барање 12 секунди + 5 секунди извршување.

Решивме да ја поедноставиме логиката за пресметување на страната на Tableau и да преместиме друг дел од пресметките на излогот и нивото на базата на податоци. Ова донесе добри резултати.

Прво, ја направивме транспозицијата во лет, го направивме тоа преку целосно надворешно спојување во последната фаза од пресметката VIEW, според овој пристап опишан на викито Транспонирање - Википедија, слободната енциклопедија и Елементарна матрица - Википедија, слободна енциклопедија.

Односно, направивме табела за поставки - матрица за транспозиција (21x21) и ги добивме сите индикатори во редослед по ред.

Беше:


Стана:


Речиси не се троши време на самата транспозиција на базата на податоци. Барањето за сите индикатори за неделата продолжи да се обработува за околу 10 секунди. Но, од друга страна, флексибилноста е изгубена во однос на конструирање на контролна табла врз основа на специфичен индикатор, т.е. за десната страна на контролната табла каде што е претставена динамиката и деталното расчленување на одреден индикатор, претходно витрината работеше за 1-3 секунди, бидејќи барањето се засноваше на еден индикатор, а сега базата секогаш ги избираше сите индикатори и го филтрираше резултатот пред да го врати резултатот во Tableau.

Како резултат на тоа, брзината на контролната табла се намали за речиси 3 пати.

Резултатот е:

1. 5 секунди – парсирање на контролни табли, визуелизации
2. 15-20 секунди - подготовка за составување барања со извршување на пред-пресметки во Табела
3. 35-45 сек - компилација на SQL барања и нивно паралелно-секвенцијално извршување во Хана
4. 5 секунди – обработка на резултати, сортирање, повторно пресметување визуелизации во Tableau
5. Се разбира, таквите резултати не одговараа на бизнисот и продолживме со оптимизацијата.

Фаза 2. Минимална логика во Табела, целосна материјализација

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

Така, во оваа последна фаза, составивме посебно складиште во кое ги додадовме сите KPI во транспонирана форма. На страната на базата на податоци, секое барање за такво складирање се обработува за 0,1 - 0,3 секунди. Во контролната табла ги добивме следниве резултати:

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

Времето поминато од Tableau се состои од:

1. 0,3 сек. — Парсирање на контролната табла и компилација на SQL прашања
2. 1,5-3 сек. — извршување на SQL барања во Хана за главни визуелизации (работи паралелно со чекор 1)
3. 1,5-2 сек. — рендерирање, повторна пресметка на визуелизации
4. 1,3 сек. — извршување на дополнителни SQL прашања за да се добијат релевантни вредности на филтер (бренд, дивизија, град, продавница), парсирање резултати

Да го сумираме накратко

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

Додека имплементиравме контролни табли со клучни индикатори за продажба, наидовме на потешкотии во изведбата кои сè уште не сме можеле да ги надминеме. Потрошивме повеќе од два месеци и добивме функционално нецелосна контролна табла, чија брзина на одговор е на работ на прифатлива. И ние самите направивме заклучоци:

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

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

Сега активно развиваме слична контролна табла во друга алатка и, во исто време, се обидуваме да ја ревидираме архитектурата на контролната табла во Tableau со цел да ја поедноставиме уште повеќе. Ако заедницата е заинтересирана, ќе ви кажеме за резултатите.

Исто така, ги чекаме вашите идеи или совети за тоа како во Tabeau можете да изградите брзи контролни табли над толку големи количини на податоци, бидејќи имаме веб-страница каде што има многу повеќе податоци отколку во малопродажбата.

Извор: www.habr.com