Optymalizacja systemow business intelligence w chmurze
Łukasz Bielak

Łukasz Bielak

Optymalizacja systemów Business Intelligence w chmurze

Optymalizacja jest terminem, który pojawia się w najróżniejszych kontekstach począwszy – od naszego ukochanego IT, aż po podatki 🙂 W zasadzie w każdym przypadku chodzi głównie o to, aby mniejszym kosztem osiągnąć takie same bądź lepsze wyniki. Systemy Business Intelligence nie są tutaj wyjątkiem, a zakres optymalizacji może być naprawdę szeroki. Poniżej przedstawiam 3 obszary, w których możesz zoptymalizować swój system Business Intelligence w chmurze.

Optymalizacja szybkości działania

To prawdopodobnie najistotniejszy – z punktu widzenia użytkownika – typ optymalizacji. I to z bardzo prostego powodu. Jeśli coś nie działa wystarczająco szybko, to odechciewa nam się tego używać. Oczywiście wszystko zależy od tego jak wielkie mamy zbiory danych, a także jak bardzo skomplikowane są modele analityczne, procesy pozyskiwania i transformacji danych. Natomiast podstawowa funkcjonalności powinna być na tyle szybka, aby użytkownik w czasie odświeżania nie zdążył zaparzyć sobie herbaty. Co mam tu na myśli? To, że jeśli odświeżamy raport z ustawieniami domyślnymi, to dane powinny pojawić się w krótkim czasie. Niestety nie jest możliwe wskazanie konkretnej liczby sekund. To wszystko zależy od tego jak wymagająca jest grupa użytkowników i co chce widzieć.

Na ogół przy projektowaniu architektury i budowaniu pierwszej wersji projektu każdy deweloper stara się, aby system działał jak naszybciej. Niestety nie wszystko da się przewidzieć. Być może coś, co wydaje się być akceptowane dla dewelopera, może być nie akceptowalne dla użytkownika. W takim przypadku produkt bądź system powinien być optymalizowany.

Jakie są techniki optymalizacji?

Oczywiście technik jest wiele. W niektórych przypadkach do zwiększenie szybkości działania wystarczy po podniesieniu mocy zasobu. Natomiast nie jest to zbyt dobre rozwiązanie, ponieważ w pewnym momencie dojdziemy do granicy, gdzie nie będzie można już dalej skalować zasobów. Dlatego też warto skupić się na problemie i w pierwszej kolejności zlokalizować wąskie gardło. Co może nim być? Pomijając wszystkie kwestie związane z tym, że systemy źródłowe nie wystarczająco szybko zwracają dane, mogą to być na przykład zbyt wolne transformacje, źle zbudowana struktura bazy czy tworzenie niezbyt optymalnych algorytmów.

Jak zlokalizować problem?

Najprostszym sposobem jest uruchomienie poszczególnych elementów procesu i wyłapanie tych, które zabierają najwięcej czasu. Później należy przeanalizować jaka jest przyczyna wolnego działania. Może to być na przykład:

1. Brak indeksów lub nieodświeżone statystki;

2. Błędny typ dystrybucji w przypadku tabeli (dla Synapse Analytics);

3. Źle dobrany algorytm (na przykład najpierw pobranie wszystkich danych, dodanie kolumny kalkulowanej, a dopiero na końcu odfiltrowanie danych);

4. Zbyt duża ilość danych (być może należy je zagregować);

5. Zbyt duża liczba kolumn w zapytaniu;

6. Źle dobrane funkcje, w przypadku języków takich jak DAX i MDX.

Jak naprawić problem?

Przede wszystkim należy go zlokalizować i fragment kodu bądź procesu odłożyć na bok, zmierzyć jego czas i wprowadzać poprawki – do momentu, aż rezultat będzie taki sam, natomiast czas wykonania, bądź zużycie zasobów będzie niższe. Oczywiście każdy z elementów systemu optymalizuje się inaczej, dlatego nie sposób podać tu detali dla ETLa, procedur składowanych czy miar. Chciałbym się jednak podzielić ciekawym linkiem, gdzie Brent Ozar pokazuje jak optymalizować zapytania TSQL. Moim zdaniem warto zobaczyć film choćby ze względu na to, że pokazane są tu nie tylko techniki optymalizacji kodu TSQL, ale także podejście do samego procesu.

Optymalizacja pamięci

Jeszcze kilka lat temu pamięć była bardzo droga. Teraz jest znacznie lepiej, ale to nie powód, żeby niepotrzebnie płacić za przechowywanie danych. Pierwszą rzeczą, od której powinien zacząć każdy dobry architekt, jest dobranie adekwatnych typów danych w kolumnach tabeli. Innymi słowy – jeśli dane są tylko i wyłącznie wartościami całkowitymi, to nie powinniśmy korzystać z typu Decimal. Tak samo w przypadku łańcuchów znaków. Oczywiście im większa baza tym lepsze rezultaty osiągniemy stosując właściwe typy danych. Istotne jest także zaprojektowanie poprawnej struktury bazy danych. Mimo że mamy do czynienia z hurtownią danych, to nie należy przesadzać z redundancją. Warto też pamiętać o tym, że dane trzeba agregować na tyle, na ile jest to możliwe. Czasami nie ma sensu przechowywać każdego pojedynczego sprzedanego produktu. W przypadku baz analitycznych, a zwłaszcza Tabulara, trzeba pamiętać o tym, że dane są kompresowane i należy unikać wartości z wysoką unikalnością. Jeśli nie jest to potrzebne, nie przechowujmy kluczy dla każdej transakcji. Mam tu na myśli oczywiście identyfikator transakcji, a nie klucze obce do tabel wymiarów.

Optymalizacja kosztowa

Jest to chyba największa zaleta chmury – w każdej chwili elastycznie można ciąć koszty. Generalnie optymalizację kosztową można podzielić na dwa rodzaje. Pierwszy to dobieranie właściwych tierów zasobów, czyli takich jakie są rzeczywiście potrzebne, a nie ustawianie ponad potrzeby. Drugi to automatyzacja włączania i wyłączania zasobów, a także zwiększania i zmniejszania tierów w odpowiednich godzinach. Jeżeli nie ma potrzeby aby nasza baza Analysis Services działała na najwyższym możliwym poziomie wydajności przez cały dzień. Dlatego też mamy bardzo dużo gotowych Runbooków. Wystarczy je tylko zaimplementować i ustawić wartości parametrów. Można na przykład w godzinach 7-19 włączyć najwyższy możliwy poziom wydajności, a w nocy albo obniżyć go do do minimum, albo wyłączyć całkowicie, ponieważ w tym czasie nikt nie korzysta z usługi. Dobra automatyzacja pomaga zaoszczędzić dużo pieniędzy, które można wydać na inne zasoby.

Przykłady Runbooków:

  1. Skalowanie i wyłącznie AAS
  2. Skalowanie Azure Synapse
  3. Skalowanie Wirtualnych Maszyn

Podsumowanie

Jak widać systemy BI są podatne na optymalizację, dzięki czemu możliwe jest obniżenie kosztów użytkowania i zwiększenia wydajności niewielkim nakładem pracy. Oczywiście sam proces optymalizacji wymaga dość szczegółowej znajomości systemu, a także jego elementów, natomiast tydzień pracy może szybko zwrócić się w postaci satysfakcji użytkowników. 

Udostępnij post

Share on facebook
Share on twitter
Share on linkedin
Share on print
Share on email

Pozostańmy w kontakcie

Jeżeli chcesz być na bieżąco informowany o nowych wpisach oraz dostawać materiały, których nie publikuję na blogu - zapisz się do newslettera!