Śledząc informacje na temat nowych usług dostępnych w chmurze, a także patrząc, jak szybko zwiększa się wydajność serwerów, można odnieść wrażenie, że podczas budowania systemu BI w chmurze absolutnie nic nas nie ogranicza. Wydawać by się mogło, że jeśli mamy nieograniczone środki finansowe, możemy w nieskończoność zwiększać wydajność i przyspieszać pracę sytemu. Niestety – nawet w świecie technologii wszystko ma swoje ograniczenia. Sztuką jest więc tak budować system, aby te limity nie były osiągane. W dzisiejszym poście zaprezentuję kilka ograniczeń narzucanych przez usługi Azure, na które powinniśmy zwrócić uwagę, kiedy projektujemy duże systemy Business Intelligence w chmurze.
Zanim zaczniemy projektować - zbierzmy wymagania
Niby przysłowiowa „oczywista oczywistość”, ale już na etapie analizy konieczna jest weryfikacja, czy możemy spełnić oczekiwania klienta. Mam tutaj na myśli sprawdzenie, czy komponenty planowane do budowy systemu spełnią jego wymagania. Tutaj bardzo cenne jest doświadczenie architekta, który projektuje rozwiązanie – bardzo prawdopodobne, że mierzył się już z podobnymi problemami. Natomiast z uwagi na to, że usługi dość dynamicznie się rozwijają, powinniśmy prześledzić dokumentacje techniczną. Często okazuje się, że w przeciągu roku coś się zmieniło i funkcjonalność, która była niedostępna jeszcze 2 miesiące temu, teraz może być wykorzystana. Szczególnie zwróćmy uwagę na ograniczenia poszczególnych zasobów, o których więcej opowiem w kolejnych akapitach. Warto ustrzec się przed sytuacją, w której po wdrożeniu sytemu okaże się, że nie spełnia on postawionych przed nim zadań.
Integracja systemów - czy dane będą na czas?
Business Intelligence to integracja danych z różnych systemów. Z tego powodu, przez rozpoczęciem pracy, powinniśmy upewnić się czy do każdego z nich mamy dostęp. Chodzi tu przede wszystkim o otwarty ruch sieciowy, jak i niezbędne do pobrania danych uprawnienia. Oprócz tego czasami konieczne jest sprawdzenie, jak szybko jesteśmy w stanie przetransferować dane z konkretnego systemu do naszego. Może zdarzyć się sytuacja, w której mimo iż nasza infrastruktura jest bardzo wydajna, to system źródłowy nie zwraca wyników w oczekiwanym czasie. Przyczyn tego może być wiele – np. słabo zoptymalizowana lub zbyt mocno eksploatowana baza źródłowa.
Zwykle jest tak, że dostajemy dostęp do bazy, która jest przeznaczona tylko do odczytu, aby nie obciążać systemu transakcyjnego. Dlatego na samym początku warto upewnić się, że na styku systemu transakcyjnego i BI nie występują żadne wąskie gardła, gdyż wtedy nawet najlepiej zaprojektowane rozwiązanie będzie miało opóźnienie w czasie ładowania danych. W tym celu dobrze jest wykonać testy i pobrać próbki danych z systemu transakcyjnego, aby znać orientacyjny czas jaki jest potrzebny do wykonania transferu.
Azure SQL Data Warehouse - uważaj na równoległe zapytania!
Hurtownia danych jest centralnym elementem systemu BI. To w niej powinny być składowane dane wysokiej jakości, co do których mamy absolutną pewność. Przy dużych systemach będziemy potrzebowali narzędzia skrojonego na miarę, a takim jest właśnie Azure Data Warehouse. Wydajność, jaką nam oferuje, jest wręcz imponująca – podobnie jak cena :).
Niestety, ale dosyć istotny jest fakt, że w zależności od warstwy, w jakiej mamy zasób, mamy bardzo ograniczoną liczbę jednoczesnych zapytań. W przypadku najniższej możliwej warstwy DWU100, są to tylko 4 zapytania (na chwilę pisania posta), jeśli podniesiemy wydajność do DWU2000, a jest to już dość droga zabawa, mamy do wykorzystania 48 równoległych zapytań. Oznacza to, że niestety ale Azure Data Warehouse średnio wypada jako baza, z której będą mogli korzystać analitycy – mimo dostępnych zasobów nie będzie można uruchomić zapytań. Oczywiście, w takiej sytuacji powinniśmy przygotować Data Marty, które będą właśnie częścią systemu przeznaczoną dla analityków, jednakże jest to dodatkowy nakład pracy i redundancja danych. Warto też wziąć pod uwagę to, że dane z hurtowni mogą być też wykorzystywane w raportowaniu i uruchamianie na niej zapytań w trybie Direct Query należy stosować bardzo roztropnie.
Azure SQL Data Warehouse. T-SQL i (nie)szczęsne skalowanie
Kolejną ciekawostką, jeśli chodzi o ADWH, jest fakt, że nie wszystkie wyrażenie T-SQL można wykorzystywać w swoich zapytaniach. Mnie osobiście bardzo brakuje polecenia IIF, ale braków jest trochę więcej. Może to oznaczać, że niektóre zapytania trzeba będzie przepisać. Nie jest to jednak ograniczenie, którego nie można obejść. W trakcie mojej pracy nie natknąłem się na coś, czego nie można zrobić w inny sposób, jednak trzeba pamiętać, że może to zwiększyć nakład pracy.
Na koniec wisienka, czyli skalowanie. Niestety, ale na obecną chwilę czas skalowania bazy do innej warstwy jest bardzo niedeterministyczny. Czasami jest wręcz konieczny kontakt ze wsparciem technicznym, bo przez kilka godzin baza jest w trybie skalowania i nie można z niej korzystać. Oczywiście to nie jest tak, że za każdym razem kiedy będziemy skalować ADWH będzie z tym problem, ale póki co należy pamiętać, że może nas to ograniczyć przed dostarczeniem danych na czas. Osobiście liczę na to, że problem ten zostanie rozwiązany i w chwili czytania tego tekstu nie będzie już istniał :).
Azure Analysis Services / Power BI Premium - Dane i wydajność zapytań
Ostatnią warstwą systemu Business Intelligence często jest raportowanie. W tym celu wykorzystujemy takie usługi jak Azure Analysis Services czy Power BI Premium. Oba rozwiązania łączy ten sam limit pamięci, który wynosi 400GB. W związku z bardzo dobrymi algorytmami kompresji jest to dość dużo pamięci. Natomiast należy zauważyć, że ta pamięć jest przeznaczona nie tylko na model, ale także jest potrzebna w trakcie wykonywania zapytań. Co więcej, w trakcie procesowania, miejsce zajęte przez model także się zwiększa. To wszystko sprawia, że 400GB może być niewystarczające. Jedyne co możemy zrobić, to budować model w taki sposób, aby dane były kompresowane jak najlepiej, a także w miarę możliwości przechowywać tylko niezbędne kolumny i zakresy danych.
Kolejnym elementem, na który należy zwracać szczególną uwagę, są miary kalkulowane. Często przy dużych rozwiązaniach logika miar może być bardzo skomplikowana, a każdy poziom komplikacji wpływa na wydajność. Od raportów, zwłaszcza tych w Power BI, oczekujemy dużej responsywności, a główną przyczyną jej braku są właśnie wolne miarki. W tym przypadku dużo zależy od developera, który może wspierać się różnymi technikami, takimi jak optymalizacja zapytania czy wsparcia się agregacjami. Natomiast trzeba pamiętać, że i w tym przypadku można osiągnąć limit i szybciej już nie będzie.
To tylko część ograniczeń
Niestety, ale trzeba pamiętać, że wraz z rozwojem systemu BI w chmurze, będą pojawiały się nowe ograniczenia. Natomiast zawsze trzeba szukać alternatywnych rozwiązań i starać się omijać wszelkie trudności. Więcej ograniczeń poszczególnych usług można znaleźć w dokumentacji.
Pomocne Linki:
Limity Współbieżności ADWH
Limity ADWH
Limity AAS
Limity Azure