Partition Manager – procesowanie dużych modeli Azure Analysis Services

  • by

Azure Analysis Services oferuje nam maksymalnie 400 GB pamięci RAM. Jest to wartość, która bardzo często wystarczy do zbudowania naprawdę skomplikowanego i rozbudowanego modelu danych. Takie rozwiązanie powinno być także regularnie zasilane danymi. Do tego celu można wykorzystać różne narzędzia – warto jednak pamiętać, że taki model powinno się odpowiednio spartycjonować, aby jego późniejsze procesowanie było w ogóle możliwe. W tym artykule zaprezentuję narzędzie służące do procesowania i partycjonowania danych – AS Partition Managera.​

Dlaczego całościowe procesowanie dużych modeli jest kłopotliwe?

Na samym początku warto wspomnieć dlaczego procesowanie dużych modeli jest kłopotliwe i co to oznacza. Przyjmijmy, że duży model to taki, który ma około 100GB danych. W takiej sytuacji procesowanie całościowe może trwać bardzo długo i często jest to już przeszkoda, która wymusza inne podejście (weźmy pod uwagę fakt, że w wielu sytuacjach klient chce otrzymać dane jak najszybciej). Długi czas pobierania danych ze źródła może powodować przerwanie zapytania (timeout), bądź zakleszczenie. Ostatnim utrudnieniem może być brak pamięci AAS – może się to zdarzyć jeśli źle przekalkulujemy rozmiar pobieranych danych. To wszystko sprawia, że procesowanie całościowe tak wielkich modeli może być bardzo trudne, a wręcz niemożliwe i bezsensowne.

Czy zawsze musimy całościowo procesować nasz model?

Warto zadać sobie pytanie – czy w tym konkretnym przypadku konieczne jest całościowe procesowanie modelu? Być może dane, które są wystawiane przez system źródłowy, zmieniają się tylko raz za konkretny zakres i nie ma sensu ładować ich całościowo na nowo? Weźmy pod uwagę taką sytuację – jeżeli  na paragonie pojawi się jakiś błąd, to korekta może być wykonana tylko w przeciągu 30 dni. Zatem jeżeli ładujemy dane do naszego modelu, do tabeli faktu, to nie musimy jej przeładowywać całościowo. wystarczą ostatnie 30 dni.

Partycjonowanie modelu rozwiąże Twój problem!

Analysis Services oferuje nam funkcjonalność partycjonowania, czyli logiczne dzielenie tabeli na mniejsze części. Pojedyncza partycja przechowuje tylko określone dane, na przykład za jeden rok czy miesiąc. Dzięki temu nie musimy już operować na całej tabeli, ale na konkretnych partycjach. Nawiązując do poprzedniego akapitu – możemy  sprocesować tylko 30 dni, a nie całą tabelę faktu! Co z tabelami wymiaru? Te możemy procesować całościowo. Zwykle nie są one zbyt duże i nie zajmie to zbyt dużo czasu. Zatem, podsumowując, przyjmujemy taką strategię: Tabele faktów są procesowane codziennie, do bazy ładujemy dane z ostatnich 30 dni. Tabele wymiarów także są procesowane codziennie, ale całościowo.

W jaki sposób zarządzać partycjami?

Tutaj z pomocą przychodzi nam narzędzie  AS Partition Processing, które jest dostępne na githubie Microsoftu. W jednym miejscu mamy dostępny cały kod źródłowy, jak i bardzo dobrą instrukcję wdrożenia. Dzięki temu narzędziu możliwe jest tworzenie nowych partycji, usuwanie starych, procesowanie zakresu dat, procesowanie całościowe itd. Generalnie warto zapoznać się z instrukcją, bo możliwości ustawień są wręcz ogromne. Samo narzędzie po wdrożeniu konfigurujemy z poziomu bazy konfiguracyjnej. Wpisujemy tam takie informacje jak adres modelu, granularność partycji oraz okres, jaki ma być procesowany. Po poprawnym skonfigurowaniu Partition Manager będzie sam zarządzał partycjami, usuwał te, które są zbyt stare, tworzył nowe, a także procesował konkretny zakres. Narzędzie może być uruchomione z procesu ETL (na przykład ADF) lub z crona.

Dlaczego AS Partition Processing nie działa w chmurze?

Jedyną wadą AS Partition Managera jest to, że rozwiązanie zostało przygotowane tylko do wersji on-premises, co oznacza, że niestety nie wykorzystamy go w Azure Analysis Services. W instrukcji pojawia się co prawda diagram, który przedstawia potencjalne wykorzystanie narzędzia w chmurze z w Azure Functions, ale niestety przy próbie implementacji pojawia się kilka problemów. Z tego powodu postanowiłem przygotować specjalną wersję aplikacji, która będzie działała z Azure Analysis Services, a co więcej będzie prosta do wdrożenia.

Pierwsze co zrobiłem, to zaimplementowałem możliwość korzystania z Service Principala przy połączeniu z aplikacji do Analysis Services. Wszystko jest opisane na blogu byoBI.com.  Niestety okazało się, że to za mało. Musiałem więc wdrożyć także wzorzec funkcji trwałych, aby można było uruchamiać proces z Azure Data Factory. By uprościć wdrażanie napisałem także kilka skryptów CLI, aby nie trzeba było ręcznie tworzyć zasobów. Wszystko jest dostępne na moim githubie.

Czego potrzebujemy do wdrożenia Partition Managera?

Aby całe rozwiązanie działało poprawnie potrzebne nam będą 3 elementy:

  1. Baza Konfiguracyjna (Azure SQL Database, nawet najniższy tier)
  2. Azure Functions i App Service Plan (te zasoby zostaną utworzone w skryptach wdrażających)
  3. Rejestracja Aplikacji w Azure AD

Jak widać wymagania nie są zbyt wygórowane. Przejdźmy do wdrożenia.

Wdrożenie Partition Managera

Przejdźmy teraz do wdrożenia rozwiązania z przykładową konfiguracją. Do celów demonstracyjnych użyję prostej bazy AAS opartej na WorldWideImporters. Efektem końcowym będzie utworzenie nowych partycji i sprocesowanie ich.

1. Pierwszą czynnością, jaką powinniśmy wykonać, jest pobranie projektu demo z githuba.

2. Następnie wdrażamy bazę konfiguracyjną – aby to zrobić wystarczy otworzyć solucję w Visual Studio, wybrać projekt bazodanowy, kliknąć Publish i ustawić destynację. Zostanie wdrożona przykładowa konfiguracja, warto zapoznać się z dokumentacją, aby wiedzieć do czego służą poszczególne kolumny.

3. Kolejnym krokiem jest dodanie do bazy użytkownika, który będzie mógł logować zdarzenia do bazy, a także pobierać z niej konfigurację. W tym celu z katalogu Security uruchamiamy kolejno skrypty:

  • LoginForConfigurationReader
  • UserForConfigurationReader
  • RoleMembership

    Należy także pamiętać o ustawieniu hasła.

4. Teraz należy otworzyć plik DeploymentScript.ps1 i ustawić wartości parametrów:

  • ResourceGroup – nazwa grupy zasobów, gdzie będzie wdrożona nasza aplikacja;
  • AppServiceName – nazwa app service’u, który zostanie utworzony;
  • FunctionAppName – nazwa function appa, który zostanie utworzony;
  • StorageAccountName – nazwa konta storage’owego, które zostanie utworzone na potrzeby funkcji;
  • StorageAccountLocation – lokalizacja konta storage’owego;
  • StorageAccountLocation – SKU konta storage’owego.

5. Przygotowany skrypt należy uruchomić za pośrednictwem CLI Azure, wdrożona zostanie aplikacja i właściwe to główny punkt jest już gotowy!

6. Teraz należy zarejestrować aplikację, aby możliwe było uwierzytelnienie w Azure Analysis Services

7. Po rejestracji należy skopiować App ID i App Key i wkleić do drugiej części skryptu.

Uwaga! Takie dane powinny być trzymane bezwględnie w Key Vaulcie, jako parametr powinny zostać użyte referencje. Do celów demonstracyjnych użyto zwykłego tekstu.

8. Następnie powinniśmy wypełnić pozostałe parametry i uruchomić skrypt w Azure CLI:

  • ConfigurationServerAddress – adres serwera, na którym znajdują się tabele z konfiguracją;
  • ConfigurationServerDatabaseName – nazwa bazy danych, która zawiera tabele konfiguracyjne;
  • ConfigurationServerDatabaseUser – nazwa użytkownika, którym będziemy logowali się do bazy danych i pobierali konfigurację;
  • ConfigurationServerDatabaseUserPassword – hasło użytkownika bazodanowego.

Uwaga! Takie dane powinny być trzymane bezwględnie w Key Vaulcie, jako parametr powinny zostać użyte referencje. Do celów demonstracyjnych użyłem zwykłego tekstu.

9. Przedostatnim krokiem jest dodanie aplikacji jako administratora bazy AAS.

10. Na sam koniec pozostaje nam uruchomienie aplikacji i sprawdzenie czy partycje zostały utworzone. Pamiętajmy, że trzeba uruchomić funkcję PartitionManager_HttpStart. Wynika to z wzorca projektowego funkcji trwałych. Logi z procesowania można sprawdzić w tabelce:

Podsumowanie

Generalnie wdrożenie powinno zakończyć się sukcesem. Ze względu na bardzo duże możliwości konfiguracji o Partition Managerze będę pisał jeszcze przez jakiś czas. Pokażę, że nadaje się on do bardzo wielu typów procesowania, a także zaprezentuję jak uruchomić go z procesu ETL z Azure Data Factory. Także zachęcam do regularnego zaglądania tutaj!