Kwestia wydajności w Tableau potrafi onieśmielić. Jest mnóstwo zasad i ich poziomów. Nie ma jednej metody na przyspieszenie działania każdego raportu. Podręcznik Performance to 80 stron w języku angielskim. Czy jest jakaś prosta metoda, żeby to ogarnąć? Jest! To właśnie Workbook Optimizer.
Pierwsza w roku wersja Tableau zwykle nie zawiera zbyt wielu nowych, a zwłaszcza rewolucyjnych funkcjonalności. Ale zawsze znajdzie się coś ciekawego. Taką interesującą nowością wersji 2022.1 jest Workbook Optimizer. Wbrew pozorom nie jest to jednak przycisk, pozwalający jednym ruchem poprawić szybkość pracy workbooka. To raczej rodzaj listy kontrolnej i wytycznych, co można zrobić. Lista podpowiedzi, ale nie wyrocznia.
Jak wygląda Workbook Optimizer?
Kiedy w górnym menu tekstowym Tableau Desktop wybierzemy Server/Run Optimizer… wyświetla się okno zaleceń. Program sprawdza, czy przy budowie raportu spełnione było 12 bazowych zasad optymalizacji. Wyniki przeglądu są wyświetlane w 3 kategoriach:
- Take action – te zmiany warto przeprowadzić, bo nie będą miały wpływu na funkcjonalność raportu lub wpływ będzie mały („czerwone”).
- Needs Review – w tych kwestiach warto zrobić przegląd. Mogą wymagać poważniejszych zmian. Również mogą nie być jednoznaczne i wymagać sprawdzenia przy użyciu Performance Recorder’a. Oczywiście, mogą też być skutkiem świadomych decyzji twórcy raportu („żółte”).
- Passed – to lista tych punktów, które są zgodne z zaleceniami („zielone”).
Każdą z kategorii można dalej rozwinąć, by obejrzeć oceny szczegółowe oraz ich uzasadnienie. W przypadku pierwszych dwóch kategorii można się spodziewać konkretnych odniesień do pól, źródeł i arkuszy analizowanego workbooka. Jeśli Tableau uzna, że dana wytyczna została spełniona, komentarz będzie jedynie ogólny.
Co ocenia Workbook Optimizer?
Spróbujmy się zatem przyjrzeć, jakie kwestie ocenia Workbook Optimizer.
- Długość kalkulacji
Jeśli ten punkt znajdzie się w sekcji czerwonej lub żółtej, będzie w nim informacja o długości najdłuższej kalkulacji w całym workbooku. W przypadku moich kalkulacji testowych było to max. 866 znaków. Zazwyczaj taka długość to efekt zagnieżdżania. Wówczas warto część kodu przenieść do kalkulacji pomocniczych. Można też rozważać przeniesienie bardziej skomplikowanych kalkulacji do bazy danych bądź wyliczenie ich w Tableau Prep.
Wadą tego punktu Optimizera jest wliczanie komentarza do długości kalkulacji. W efekcie jednolinijkowa kalkulacja, opatrzona solidnym komentarzem, może być wskazana jako problem. A Komentarz nie ma wpływu na wydajność kalkulacji.
- Kalkulacje wykorzystujące wiele źródeł danych
Kiedy kalkulacja wykorzystuje pola z różnych źródeł, nie ma możliwości zastosowania do niej większości mechanizmów optymalizacyjnych. Kalkulacje muszą być wyliczane lokalnie. Ale uwaga! Dotyczy to głównie trybu live. Gdy korzystamy ze źródła w postaci ekstraktu ten problem w zasadzie nie pojawia się. Należy się go natomiast spodziewać, kiedy konieczne jest blendowanie danych.
Na stronie Tableau znalazłam informacje, że komunikat o tym błędzie może niekiedy pojawić się przy polach zawierających skomplikowane parametry. Mimo, że oparte są na jednym źródle. W moich workbookach testowych – często skomplikowanych – nie było takiej sytuacji.
- Wiele połączeń w źródle danych
Ta uwaga dotyczy głównie źródeł z dużą ilością joinów i unionów przygotowywanych po stronie Tableau. Także gdy korzystamy z Initial SQL. W tych sytuacjach warto korzystać z ekstraktów. Alternatywą może być także połączenie danych w Tableau Prep.
Co ciekawe przy źródle relacyjnym w trybie live Tableau nie widzi problemów.
- Niezmaterializowane kalkulacje
W moich eksperymentach ta uwaga pojawiła się tylko raz, w sekcji Take Action. Dotyczyło to wyjątkowo dużego i dość wolnego raportu. Materializacja kalkulacji jest bowiem czymś, po co sięga się tylko, gdy działanie workbooka odbiega od oczekiwań. To rozwiązanie, gdy niski performance wynika z ilości i czasu zapytań do bazy (querries). Wówczas w górnym menu tekstowym wybieramy Data/[Nazwa ekstraktu]/Compute Calulations Now. Dzięki materializacji kalkulacje będą wyliczane na etapie tworzenia ekstraktu. Przyspieszy to zwłaszcza skomplikowane kalkulacje z operacjami na danych tekstowych lub ciągach znaków.
Nie uda się zmaterializować kalkulacji zawierających: funkcje NOW() i TODAY(), funkcji wykorzystujących kod zewnętrzny np. z R lub RAWSQL, kalkulacji tabelarycznych i LOD. Może być to też niemożliwe przy kalkulacjach zawierających agregacje.
- Liczba źródeł danych
Im więcej źródeł danych podłączonych jest do jednego workbooka, tym dłużej może trwać ładowanie i renderowanie tego raportu. Co można zrobić? Połączyć tabele. Pomocne może być Tableau Prep, ale także wykorzystanie relacji. Alternatywnym rozwiązaniem może być podzielenie jednego raportu na kilka mniejszych, związanych z poszczególnymi źródłami danych.
- Liczba filtrów
Liczba filtrów wykorzystywanych na danym widoku wpływa bezpośrednio na poziom skomplikowania zapytań do bazy, jakie będą konieczne do jego wyświetlania. To z kolei wpływa na szybkość pracy raportu. Stąd stała rada, żeby używać tylko tylu filtrów, ile rzeczywiście jest konieczne. Dodatkowo warto pomyśleć, by filtry nie były stosowane do różnych źródeł danych, by nie nadużywać opcji „Only relevant values”. Dobrze też unikać filtrów z długimi listami opcji i używać przycisku „Apply”. Filtry daty warto opierać na „zielonych pigułkach” daty ciągłej. I wreszcie należy pamiętać, by unikać filtrowania po wartościach nie występujących na widoku.
Co do komunikatu w Workbook Optimizer, niestety ten nieco mnie zawiódł. Jasno wskazuje on liczbę filtrów i fakt, że to wiele. Przy raporcie z jednym widokiem dowiedziałam się, że 11 filtrów na widoku może opóźniać raport. W wielo-dashboardowym raporcie z podobną ilością filtrów w każdym widoku, komentarz pojawił się tylko dla najwolniejszego dashboardu.
- Liczba kalkulacji LOD
Kalkulacje LOD zdecydowanie mogą wpływać na performance. Pół biedy, jeśli wyliczenia odbywają się na wysokim poziomie agregacji. Gorzej jeśli służą do wyliczania bardzo drobnych elementów. Będą to np. kalkulacje FIXED z kilkoma wymiarami wewnątrz.
Workbook Optimizer informuje o występowaniu i liczbie kalkulacji LOD czy będzie ich 4 czy 126. Dlatego proponuję podchodzić do komunikatu z dystansem. 126 kalkulacji LOD to problem. Ale jeśli alternatywą dla nich miałyby okazać się kalkulacje tabelaryczne, mogą być znacznie wolniejsze.
- Liczba widoków na dashboardzie
Jeśli na jeden dashboard składa się więcej niż 10 arkuszy roboczych, Tableau zaleca przegląd. Im więcej arkuszy, tym dłużej trawa ich wgrywanie i wyświetlanie. I rzeczywiście 10 wykresów to może być dużo, ale warto pamiętać, że czasem arkusze, to tylko przyciski lub tytuły.
Co można zrobić, jeśli na dashboardzie rzeczywiście jest tłok? Rozważyć rozbicie go na kilka osobnych połączonych przyciskami nawigacyjnymi albo umieścić wybrane elementy w ukrywanych kontenerach. Pomóc może też wykorzystywanie akcji. Warto jednak pamiętać, że nie wszystkie one są równie szybkie. Najszybsze są te najprostsze: Navigate i Filter Actions. Akcje na parametrach są nieco wolniejsze. Najwolniejsze są na ogół akcje na setach.
- Liczba widocznych arkuszy w raporcie
Im więcej widoków, tym dłużej wgrywa się raport. Proste. Ten konkretny komunikat pojawia się w sekcji żółtej, czyli do wzięcia pod rozwagę, gdy widoków jest ponad 10. Wszystko jedno czy dotyczy do arkuszy roboczych czy dashboardów. Jeśli tylko nie są ukryte, liczą się. Zalecenia? Warto zastanowić się, czy wszystkie widoki są konieczne. Jeśli tak, być może można podzielić je na kilka mniejszych raportów. A może wystarczy część obiektów ukryć!
- Liczba arkuszy ukrytych w raporcie
Ten punkt stanowi w zasadzie przedłużenie poprzedniego. Wiemy, że kiedy arkusze są wykorzystane na dashboardzie możemy je ukryć. Wiadomo też, że nie wszystkie arkusze istniejące w raporcie muszą być widoczne w raporcie opublikowanym na Tableau Online lub Tableau Server. Nie zmienia to faktu, że każdy z nich dokłada się do łącznego czasu ładowania raportu.
- Nieużywane źródła danych
Na czas wgrywania raportu wpływają też źródła danych. Jeśli w raporcie przez przypadek znajdzie się takie, które nie jest już potrzebne, usuwamy je. W górnym menu tekstowym, w zakładce Data, przy danym źródle wybieramy opcję Close.
- Nieużywane pola kalkulowane
Częstym problemem przy tworzeniu źródeł danych jest dobieranie pół zgodnie z filozofią „bo może kiedyś się przyda”. Pół biedy, kiedy po zakończonej budowie raportu, źródło jest ponownie weryfikowane. To pozwala wyłapać nadmiarowe pola. Można je usunąć, ale prawdę mówiąc wcale nie trzeba. Wystarczy w Tableau Desktop w Menu na górze sekcji danych (Data Pane) wybrać opcję Hide All Unused Fields. To spowoduje, że nieużywane pola na pewno nie staną się elementami zapytań do bazy. Niestety przy edycji raportu w przeglądarce nie ma możliwości ukrycia wszystkich pól od razu. Tam konieczne jest ukrywanie ich pojedynczo.
Jak korzystać z Workbook Optimizer?
Workbook optimizer to znakomity zbiór podpowiedzi zarówno dla początkujących, jak i zaawansowanych użytkowników Tableau. Warto do nich zaglądać i analizować je. Nie warto jednak traktować ich jak wyroczni. Jeśli kalkulacje LOD są niezbędne do uzyskania określonego efektu, raczej ich nie unikniemy, chyba że w tym konkretnym przypadku kalkulacje tabelaryczne – też wolne – będą szybsze. Jeśli dla klienta ważny jest wieloarkuszowy raport lub konkretny katalog filtrów również możemy nie mieć wyboru. Niemniej świadomość dobrych praktyk bardzo pomaga w nauce budowania coraz optymalniejszych raportów. Może też umożliwić merytoryczną dyskusję przy decyzjach, co ważniejsze szybki raport czy konkretne funkcjonalności.
Agata Mężyńska, Tableau Desktop Certified Professional
