Czas raportowania w Excelu szybko odchodzi – trend w stronę wygodnych narzędzi do prezentacji i analizy informacji widoczny jest we wszystkich obszarach. Długo dyskutowaliśmy wewnętrznie nad cyfryzacją raportowania i wybraliśmy system wizualizacji i samoobsługowej analityki Tableau. O doświadczeniach i wynikach budowy dashboardu bojowego opowiedział Alexander Bezugly, szef działu rozwiązań analitycznych i raportowania Grupy M.Video-Eldorado.
Od razu powiem, że nie wszystko, co było zaplanowane, zostało zrealizowane, ale doświadczenie było ciekawe, mam nadzieję, że i Tobie się przyda. A jeśli ktoś ma jakiś pomysł jak można by to zrobić lepiej to będę wdzięczny za rady i pomysły.
Poniżej skrót o tym, co spotkaliśmy i czego się dowiedzieliśmy.
Gdzie zaczęliśmy?
M.Video-Eldorado posiada dobrze rozwinięty model danych: ustrukturyzowane informacje z wymaganą głębokością przechowywania oraz ogromną liczbą raportów w ustalonej formie (zobacz więcej szczegółów ). Na ich podstawie analitycy tworzą tabele przestawne, sformatowane biuletyny w programie Excel lub piękne prezentacje programu PowerPoint dla użytkowników końcowych.
Około dwa lata temu zamiast raportów w ustalonej formie zaczęliśmy tworzyć raporty analityczne w SAP Analysis (dodatek do Excela, w zasadzie tabela przestawna nad silnikiem OLAP). Jednak narzędzie to nie było w stanie zaspokoić potrzeb wszystkich użytkowników, większość w dalszym ciągu korzystała z informacji dodatkowo przetworzonych przez analityków.
Nasi użytkownicy końcowi dzielą się na trzy kategorie:
Najwyższe kierownictwo. Prosi o informacje w dobrze przedstawiony i zrozumiały sposób.
Kierownictwo średnie, zaawansowani użytkownicy. Interesuje Cię eksploracja danych i umiejętność samodzielnego tworzenia raportów, jeśli dostępne są narzędzia. Stali się kluczowymi użytkownikami raportów analitycznych w SAP Analysis.
Użytkownicy masowi. Nie interesuje ich samodzielna analiza danych, korzystają z raportów o ograniczonej swobodzie, w formie newsletterów i tabel przestawnych w Excelu.
Naszą ideą było zaspokojenie potrzeb wszystkich użytkowników i udostępnienie im jednego, wygodnego narzędzia. Postanowiliśmy zacząć od najwyższego kierownictwa. Potrzebowali łatwych w użyciu dashboardów do analizowania kluczowych wyników biznesowych. Zaczęliśmy więc od Tableau i najpierw wybraliśmy dwa kierunki: wskaźniki sprzedaży detalicznej i internetowej z ograniczoną głębokością i zakresem analizy, które obejmowałyby około 80% danych żądanych przez najwyższe kierownictwo.
Ponieważ użytkownikami dashboardów była najwyższa kadra menadżerska, pojawił się kolejny dodatkowy KPI produktu – szybkość reakcji. Nikt nie będzie czekał 20-30 sekund na aktualizację danych. Nawigacja powinna zostać wykonana w ciągu 4-5 sekund lub jeszcze lepiej, natychmiast. A nam, niestety, nie udało się tego osiągnąć.
Tak wyglądał układ naszego głównego dashboardu:
Kluczową ideą jest połączenie po lewej stronie głównych czynników KPI, których było łącznie 19, a po prawej przedstawienie ich dynamiki i podziału według głównych atrybutów. Zadanie wydaje się proste, wizualizacja jest logiczna i zrozumiała, dopóki nie zagłębisz się w szczegóły.
Szczegół 1. Ilość danych
Nasza główna tabela rocznej sprzedaży zajmuje około 300 milionów wierszy. Ponieważ konieczne jest odzwierciedlenie dynamiki za rok ubiegły i rok wcześniej, ilość danych o samej rzeczywistej sprzedaży wynosi około 1 miliarda wierszy. Odrębnie przechowywane są także informacje o planowanych danych oraz blok sprzedaży internetowej. Dlatego mimo że korzystaliśmy z kolumnowego in-memory DB SAP HANA, szybkość zapytania z wyborem wszystkich wskaźników na tydzień z aktualnej pamięci w locie wynosiła około 15-20 sekund. Rozwiązanie tego problemu sugeruje się samo - dodatkowa materializacja danych. Ale ma też pułapki, o których więcej poniżej.
Szczegół 2. Wskaźniki nieaddytywne
Wiele naszych wskaźników KPI jest powiązanych z liczbą wpływów. Wskaźnik ten reprezentuje COUNT DISTINCT liczby wierszy (sprawdź nagłówki) i pokazuje różne kwoty w zależności od wybranych atrybutów. Przykładowo, jak należy obliczyć ten wskaźnik i jego pochodną:
Aby obliczenia były prawidłowe, możesz:
- Obliczaj takie wskaźniki na bieżąco w magazynie;
- Wykonuj obliczenia na całym wolumenie danych w Tableau, tj. na żądanie w Tableau podaj wszystkie dane według wybranych filtrów w szczegółowości pozycji paragonu;
- Utwórz zmaterializowaną prezentację, w której wszystkie wskaźniki zostaną obliczone we wszystkich opcjach próbki, które dają różne, nieaddytywne wyniki.
Jasne jest, że w przykładzie UTE1 i UTE2 są atrybutami materialnymi reprezentującymi hierarchię produktów. Nie jest to rzecz statyczna, zarządzanie w firmie odbywa się poprzez nią, ponieważ Za różne grupy produktów odpowiadają różni menedżerowie. Mieliśmy wiele globalnych rewizji tej hierarchii, kiedy zmieniały się wszystkie poziomy, kiedy rewidowano relacje i ciągłe zmiany punktów, kiedy jedna grupa przechodziła z jednego węzła do drugiego. W konwencjonalnym raportowaniu wszystko to wyliczane jest na bieżąco z atrybutów materiału, w przypadku materializacji tych danych konieczne jest opracowanie mechanizmu śledzenia takich zmian i automatycznego ponownego ładowania danych historycznych. Bardzo nietrywialne zadanie.
Szczegół 3. Porównanie danych
Ten punkt jest podobny do poprzedniego. Najważniejsze jest to, że analizując firmę, zwykle tworzy się kilka poziomów porównania z poprzednim okresem:
Porównanie z poprzednim okresem (z dnia na dzień, z tygodnia na tydzień, z miesiąca na miesiąc)
W porównaniu tym zakłada się, że w zależności od wybranego przez użytkownika okresu (np. 33 tydzień roku) powinniśmy pokazać dynamikę do 32 tygodnia, jeżeli wybraliśmy dane za miesiąc, np. maj , to porównanie to pokazałoby dynamikę do kwietnia.
Porównanie z ubiegłym rokiem
Główny niuans polega na tym, że porównując dzień i tydzień, nie bierzesz tego samego dnia w zeszłym roku, tj. nie można po prostu odjąć bieżącego roku od jednego. Musisz zwrócić uwagę na dzień tygodnia, który porównujesz. Przeciwnie, porównując miesiące, należy wziąć dokładnie ten sam dzień kalendarzowy z ubiegłego roku. Istnieją również niuanse z latami przestępnymi. W oryginalnych repozytoriach wszystkie informacje są rozłożone według dnia, nie ma osobnych pól z tygodniami, miesiącami czy latami. Dlatego, aby uzyskać pełny przekrój analityczny w panelu, należy policzyć nie jeden okres, np. tydzień, ale 4 tygodnie, a następnie porównać te dane, odzwierciedlić dynamikę, odchylenia. W związku z tym tę logikę generowania porównań dynamicznych można również zaimplementować w Tableau lub po stronie sklepu. Tak, i oczywiście znaliśmy i myśleliśmy o tych szczegółach na etapie projektowania, ale trudno było przewidzieć ich wpływ na działanie finalnej deski rozdzielczej.
Wdrażając dashboard, podążaliśmy długą ścieżką Agile. Naszym zadaniem było jak najszybsze dostarczenie działającego narzędzia z niezbędnymi danymi do testów. Dlatego poszliśmy sprintem i zaczęliśmy od minimalizacji pracy po stronie bieżącego magazynu.
Część 1: Wiara w Tableau
Aby uprościć obsługę IT i szybko wdrożyć zmiany, postanowiliśmy stworzyć logikę do obliczania wskaźników nieaddytywnych i porównywania minionych okresów w Tableau.
Etap 1. Wszystko jest aktywne, bez modyfikacji okna.
Na tym etapie połączyliśmy Tableau z obecnymi witrynami sklepowymi i postanowiliśmy zobaczyć, jak będzie obliczana liczba paragonów za jeden rok.
Wynik:
Odpowiedź była przygnębiająca – 20 minut. Przesyłanie danych przez sieć, duże obciążenie Tableau. Zdaliśmy sobie sprawę, że w HANA należy wdrożyć logikę ze wskaźnikami nieaddytywnymi. Nie przestraszyło nas to zbytnio, mieliśmy już podobne doświadczenia z BO i Analizą i wiedzieliśmy, jak szybko zbudować w HANA, które dają poprawnie wyliczone wskaźniki nieaddytywne. Teraz pozostało tylko dostosować je do Tableau.
Etap 2. Stroimy gabloty, bez materializacji, wszystko na bieżąco.
Stworzyliśmy osobną nową prezentację, która na bieżąco generowała wymagane dane dla TABLEAU. Ogólnie uzyskaliśmy dobry wynik, skróciliśmy czas generowania wszystkich wskaźników w ciągu jednego tygodnia do 9-10 sekund. I szczerze spodziewaliśmy się, że w Tableau czas reakcji dashboardu przy pierwszym otwarciu wyniesie 20-30 sekund, a potem ze względu na pamięć podręczną od 10 do 12, co w sumie by nam odpowiadało.
Wynik:
Pierwsze otwarcie pulpitu nawigacyjnego: 4-5 minut
Dowolne kliknięcie: 3-4 minuty
Takiego dodatkowego zwiększenia pracy witryny sklepowej nikt się nie spodziewał.
Część 2. Zanurz się w Tableau
Etap 1. Analiza wydajności Tableau i szybkie strojenie
Zaczęliśmy analizować, gdzie Tableau spędza najwięcej czasu. I są do tego całkiem dobre narzędzia, co oczywiście jest plusem Tableau. Głównym problemem, który zidentyfikowaliśmy, były bardzo złożone zapytania SQL tworzone przez Tableau. Były one kojarzone przede wszystkim z:
— transpozycja danych. Ponieważ Tableau nie posiada narzędzi do transpozycji zbiorów danych, aby zbudować lewą stronę dashboardu ze szczegółową reprezentacją wszystkich KPI, musieliśmy stworzyć tabelę za pomocą przypadku. Rozmiar zapytań SQL w bazie danych osiągnął 120 000 znaków.
- wybór okresu. Kompilacja takiego zapytania na poziomie bazy danych zajęła więcej czasu niż wykonanie:
Te. przetwarzanie żądania 12 sekund + 5 sekund wykonania.
Postanowiliśmy uprościć logikę obliczeń po stronie Tableau i przenieść kolejną część obliczeń na poziom sklepu i bazy danych. Przyniosło to dobre rezultaty.
Najpierw zrobiliśmy transpozycję w locie, zrobiliśmy to poprzez pełne złącze zewnętrzne na ostatnim etapie obliczeń VIEW, zgodnie z podejściem opisanym na wiki и .
Oznacza to, że zrobiliśmy tabelę ustawień - macierz transpozycji (21x21) i otrzymaliśmy wszystkie wskaźniki w podziale wiersz po rzędzie.
To było:
Stało się:
Prawie nie poświęca się czasu na samą transpozycję bazy danych. Żądanie dotyczące wszystkich wskaźników na dany tydzień było nadal przetwarzane w ciągu około 10 sekund. Z drugiej jednak strony stracono elastyczność w zakresie konstruowania dashboardu w oparciu o konkretny wskaźnik, tj. dla prawej strony deski rozdzielczej, gdzie prezentowana jest dynamika i szczegółowe rozbicie konkretnego wskaźnika, wcześniej gablota działała w 1-3 sekundy, ponieważ żądanie opierało się na jednym wskaźniku, a teraz baza danych zawsze wybierała wszystkie wskaźniki i filtrowała wynik przed zwróceniem wyniku do Tableau.
W rezultacie prędkość deski rozdzielczej spadła prawie 3 razy.
Wynik:
- 5 sekund – parsowanie dashboardów, wizualizacji
- 15-20 sekund - przygotowanie do kompilacji zapytań z wykonaniem obliczeń wstępnych w Tableau
- 35-45 sek. - Kompilacja zapytań SQL i ich równoległe-sekwencyjne wykonanie w Hana
- 5 sekund – obróbka wyników, sortowanie, przeliczanie wizualizacji w Tableau
- Oczywiście takie wyniki nie odpowiadały biznesowi i kontynuowaliśmy optymalizację.
Etap 2. Minimalna logika w Tableau, pełna materializacja
Zrozumieliśmy, że nie da się zbudować dashboardu z kilkusekundowym czasem reakcji na witrynie sklepowej działającej przez 10 sekund i rozważyliśmy opcje materializacji danych po stronie bazy danych specjalnie dla wymaganego dashboardu. Ale napotkaliśmy globalny problem opisany powyżej - wskaźniki nieaddytywne. Nie byliśmy w stanie zapewnić, że przy zmianie filtrów lub drążeń Tableau elastycznie przełączał się pomiędzy różnymi witrynami sklepowymi i poziomami wstępnie zaprojektowanymi dla różnych hierarchii produktów (w przykładzie trzy zapytania bez UTE, z UTE1 i UTE2 generują różne wyniki). Dlatego postanowiliśmy uprościć dashboard, porzucić hierarchię produktów w dashboardzie i zobaczyć jak szybko mogłoby to działać w uproszczonej wersji.
Zatem na tym ostatnim etapie stworzyliśmy osobne repozytorium, w którym dodaliśmy wszystkie KPI w transponowanej formie. Po stronie bazy danych każde żądanie do takiego magazynu jest przetwarzane w czasie 0,1 - 0,3 sekundy. W dashboardzie otrzymaliśmy następujące wyniki:
Pierwsze otwarcie: 8-10 sekund
Dowolne kliknięcie: 6-7 sekund
Czas spędzony przez Tableau składa się z:
- 0,3 sek. — parsowanie dashboardów i kompilacja zapytań SQL
- 1,5-3 sek. — wykonanie zapytań SQL w Hana dla głównych wizualizacji (przebiega równolegle z krokiem 1)
- 1,5-2 sek. — renderowanie, przeliczanie wizualizacji
- 1,3 sek. — wykonanie dodatkowych zapytań SQL w celu uzyskania odpowiednich wartości filtrów (Marka, Oddział, Miasto, Sklep), parsowanie wyników
Podsumowując krótko
Podobało nam się narzędzie Tableau z punktu widzenia wizualizacji. Na etapie prototypowania rozważyliśmy różne elementy wizualizacji i znaleźliśmy je wszystkie w bibliotekach, w tym złożoną segmentację wielopoziomową i wodospad z wieloma sterownikami.
Wdrażając dashboardy z kluczowymi wskaźnikami sprzedażowymi napotkaliśmy trudności wydajnościowe, których nie udało nam się jeszcze pokonać. Spędziliśmy ponad dwa miesiące i otrzymaliśmy funkcjonalnie niekompletny dashboard, którego szybkość reakcji jest na granicy akceptowalności. I sami wyciągnęliśmy wnioski:
- Tableau nie może pracować z dużymi ilościami danych. Jeśli w oryginalnym modelu danych masz więcej niż 10 GB danych (około 200 milionów X 50 wierszy), to dashboard poważnie zwolni – od 10 sekund do kilku minut na każde kliknięcie. Eksperymentowaliśmy zarówno z połączeniem na żywo, jak i ekstraktem. Szybkość działania jest porównywalna.
- Ograniczenia w przypadku korzystania z wielu magazynów (zestawów danych). Nie ma możliwości wskazania relacji między zbiorami danych przy użyciu standardowych środków. Jeśli zastosujesz obejścia do łączenia zestawów danych, będzie to miało duży wpływ na wydajność. W naszym przypadku rozważaliśmy opcję materializacji danych w każdej wymaganej sekcji widoku i przełączania tych zmaterializowanych zbiorów danych przy zachowaniu wcześniej wybranych filtrów - w Tableau okazało się to niemożliwe.
- W Tableau nie można wprowadzać parametrów dynamicznych. Nie można wypełnić parametru używanego do filtrowania zbioru danych w ekstrakcie lub podczas połączenia na żywo wynikiem innego wyboru ze zbioru danych lub wynikiem innego zapytania SQL, jedynie natywnymi danymi wejściowymi użytkownika lub stałą.
- Ograniczenia związane z budowaniem dashboardu z elementami OLAP|PivotTable.
W MSTR, SAP SAC, SAP Analysis, jeśli dodasz zbiór danych do raportu, to wszystkie znajdujące się na nim obiekty są domyślnie ze sobą powiązane. Tableau tego nie ma; połączenie należy skonfigurować ręcznie. Jest to prawdopodobnie bardziej elastyczne, ale w przypadku wszystkich naszych dashboardów jest to obowiązkowy wymóg dla elementów - a więc są to dodatkowe koszty pracy. Co więcej, jeśli zrobisz powiązane filtry tak, że np. podczas filtrowania regionu lista miast będzie ograniczona tylko do miast tego regionu, od razu skończysz z kolejnymi zapytaniami do bazy danych lub Wyciągu, co zauważalnie spowalnia działanie panel. - Ograniczenia funkcji. Transformacji masowych nie można wykonać ani na ekstrakcie, ani, W SZCZEGÓLNOŚCI, na zbiorze danych z Live-connecta. Można to zrobić za pomocą Tableau Prep, ale jest to dodatkowa praca i kolejne narzędzie do nauki i utrzymania. Na przykład nie można transponować danych ani łączyć ich ze sobą. Co zamyka się poprzez przekształcenia na poszczególnych kolumnach lub polach, które należy wybrać za pomocą wielkości liter lub if, a to generuje bardzo złożone zapytania SQL, w których baza danych większość czasu spędza na kompilowaniu tekstu zapytania. Tę sztywność narzędzia trzeba było rozwiązać na poziomie prezentacji, co prowadzi do bardziej złożonego przechowywania, dodatkowych pobrań i transformacji.
Nie zrezygnowaliśmy z Tableau. Ale nie uważamy Tableau za narzędzie zdolne do budowania przemysłowych dashboardów i narzędzie, za pomocą którego można zastąpić i zdigitalizować cały korporacyjny system raportowania firmy.
Obecnie aktywnie rozwijamy podobny dashboard w innym narzędziu i jednocześnie staramy się zrewidować architekturę dashboardu w Tableau, aby jeszcze bardziej go uprościć. Jeśli społeczność będzie zainteresowana, poinformujemy Cię o wynikach.
Czekamy także na Wasze pomysły lub porady jak w Tabeau można szybko zbudować dashboardy na tak dużych wolumenach danych, ponieważ mamy serwis internetowy, na którym danych jest dużo więcej niż w retailu.
Źródło: www.habr.com