Deployment modeli tabelarycznych przy pomocy ALM Toolkit i BISM Normalizer

Deployment wszelkiej maści modeli tabelarycznych może przebiegać w przeróżny sposób. W przypadku modeli zbudowanych przy pomocy Power BI Desktop cały proces jest nieco uproszczony i sprowadza się do opublikowania raportu w określonym obszarze roboczym, a następnie opublikowaniu tzw. Power BI App. Oczywiście mieliśmy i ciągle mamy pewne możliwości automatyzacji poprzez wykorzystanie np. REST API lub mechanizmu OneDrive Refresh jednakże nie mamy takiej dowolności jak np. w przypadku bazy danych SQL. Sytuacja ta ciągle się rozwija i gołym okiem widać, że automatyzacja pewnych czynności jest ważnym aspektem dla Microsoftu. Przykładem może tu być pozostający (na moment pisania tego artykułu) w fazie preview mechanizm Power BI Deployment Pipelines, który w łatwy sposób pomaga zarządzać cyklem życia raportu.

Nieco więcej możliwości mamy do dyspozycji w przypadku modeli budowanych z poziomu Visual Studio – tam możemy wykorzystać MSBuild i Deployment Utility i niejako wpleść to wszystko w istniejący proces CICD dzięki wsparciu tego procesu z poziomu linii komend. Dobrą wiadomością dla nas wszystkich jest fakt, że Azure Analysis Services i Power BI powoli stają się jednym produktem i dzięki wielu udogodnieniom jak np. udostępniony do zapisu i odczytu XMLA Endpoint jesteśmy w stanie już teraz budować zestawy danych przy użyciu kombajnu jakim jest Visual Studio ze wszystkimi jego udogodnieniami. Możliwości deploymentu i automatyzacji cały czas się rozszerzają i nieco upraszczają. Dziś chciałbym powiedzieć o narzędziach BISM Normalizer oraz ALM Toolkit które w niedługim czasie staną się (a w niektórych projektach już są) standardowym podejściem do zarządzania wdrażaniem rozwiązań opartych o model tabelaryczny.

W tym miejscu warto powiedzieć dwa słowa dlaczego piszę o dwóch narzędziach w ramach pojedynczego artykułu. Odpowiedź jest dosyć prosta – ponieważ w gruncie rzeczy są to te same narzędzia oparte o ten sam silnik z tym, że BISM Normalizer jest dodatkiem Visual Studio, a ALM Toolkit jest dedykowany dla Power BI Desktop. Oba produkty są dodatkami i nie są integralną częścią wspomnianych narzędzi dlatego też w celu zapoznania się z najnowszymi wersjami i dokumentacją odsyłam do oficjalnej strony (ALM Toolkit, BISM Normalizer) oraz dokumentu dosyć dokładnie opisującego niemal wszystkie dostępne możliwości (link).

Przejdźmy do praktyki – większość funkcjonalności przedstawię przy pomocy BISM Normalizera jednakże należy zdawać sobie sprawę, że podobne rzeczy możemy osiągnąć w ALM Toolkit. Jak już wspomniałem BISM Normalizer jest dodatkiem do Visual Studio dlatego też w pierwszej kolejności należy go zainstalować wybierając w VS opcje Extensions -> Manage Extensions:

Następnie w Marketplace musimy wyszukać interesujący nas dodatek i po prostu kliknąć Download:

Na powyższym zrzucie ekranowym możecie zobaczyć, że dodatek jest całkowicie darmowy, a jego autorem jest Christian Wade. Nazwisko tego pana polecam sobie zapamiętać ponieważ jako autor Christian jest zaangażowany w szerzenie wiedzy o produkcie i w sieci możecie znaleźć również prowadzone przez niego prelekcje poświęcone obu narzędziom.

Po pobraniu dodatku i zrestartowaniu Visual Studio narzędzie powinno być dla nas dostępne. Aby przedstawić jego możliwości stworzyłem prosty model tabelaryczny zawierający dane z Adventure Works DW:

Mając ten model wrzuciłem go na mój lokalny serwer, a następnie w projekcie dokonałem następujących zmian:

• Dodałem miarę TotalQty będącą sumą pola OrderQuantity w tabeli faktów,
• Ukryłem pole PromotionKey z DimPromotion,
• Usunąłem GeographyKey z DimCustomer,
• zmieniłem relacje pomiędzy FactInternetSales, a DimSalesTerritory na dwustronną.

Mając wykonane te zmiany wybrałem Tools -> New Tabular Model Comparison:

W wyniku moich działań powstał nowy plik o rozszerzeniu bsmn, który będzie przechowywał definicję tego co za chwilę skonfigurujemy. Aby rozpocząć pracę wybierzmy przycisk Compare:

Po wybraniu tej opcji naszym oczom powinno ukazać się okno w którym będziemy definiować co chcemy porównywać:

Na powyższym zrzucie możecie zauważyć, że będziemy porównywać aktualnie otwarty projekt o nazwie TabularProject1 z bazą modelu tabelarycznego znajdującą się na serwerze o tej samej nazwie. Baza znajdująca się po lewej stronie jest traktowana jako źródłowa, a po prawej jako docelowa. Poszczególne bazy zawsze możemy zamienić miejscami klikając przycisk dostępny w środkowej części ekranu.

Oczywiście to nie jedyna opcja bo możemy porównywać również dwa projekty pomiędzy sobą, dwie bazy modelu tabelarycznego czy chociażby wskazać plik *.bim z definicją naszego modelu i jego porównać z dowolnym źródłem. Opcji jest całkiem sporo ale na ten moment zostawiłem to tak jak na powyższym zrzucie i kliknąłem OK. Po zatwierdzeniu moim oczom ukazał się raport różnic pomiędzy oboma modelami:

Różnice pomiędzy modelami są raportowane z następującym statusem odzwierciedlającym działanie na bazie docelowej:

• Skip – definicja danego elementu nie różni się między bazami,
• Update – dany element różni się pomiędzy bazami,
• Create – dany element istnieje tylko w bazie oznaczonej jako źródłowa,
• Delete – dany element istnieje tylko w bazie oznaczonej jako docelowa.

Na ten moment mogą nas nie interesować obiekty, które się nie zmieniły i mają tą samą definicję dlatego możemy wybrać opcję Select Actions -> Hide Skip Objects with same Definition:

Dzięki temu nasz widok będzie zawierał kompaktowy spis zmian pomiędzy modelami:

Bardzo fajną opcją jest to, że po wybraniu określonej zmiany to w dolnej części okna zobaczymy kod JSON z tą właśnie zmianą pokolorowaną w odpowiedni sposób co nieco przypomina porównywanie struktury obiektów bazodanowych:

Dodatkowo jeżeli nie chcemy aby definicja jakiegoś elementu została zaktualizowana lub dany obiekt został utworzony/usunięty możemy zawsze zmienić domyślną akcję:

Ewentualnie jeśli chcemy ominąć wszystkie zmiany określonego typu to możemy wykorzystać opcje dostępne w przedstawionym wcześniej oknie Select Actions:

Jak już dokonaliśmy wyboru, które obiekty chcemy deployować, a które nie możemy wybrać opcję Validate Selection aby program sprawdził czy wszystko jest w porządku i udostępnił nam opcje wdrażania:

Gdy walidacja zakończyła się pomyślnie warto zwrócić uwagę na okno Warning List, które zawiera ewentualne ostrzeżenia oraz skróconą listę operacji jakie zostaną wykonane. To właśnie w poniższym oknie możemy wykryć wszelkie problemy z deploymentem jak chociażby problemy z obiektami, które są od siebie zależne itd. dlatego tym bardziej zachęcam do śledzenia tego co narzędzie chce nam zasygnalizować:

Jest to również o tyle istotne, że może się zdarzyć, że jakiejś zmiany nie zapisaliśmy i nie zostanie ona uwzględniona w deploymencie.

Gdy wszystko jest gotowe to możemy nasze zmiany wrzucić bezpośrednio na serwer, wygenerować skrypt różnicowy lub wygenerować Excela z podsumowaniem zmian:

O opcjach wspomnimy za chwile ja na tą chwilę wybrałem opcję Generate Script, która powinna pokazać wygenerowany przez narzędzie skrypt. Skrypt ten jest niczym innym jak komendą w JSON zawierającą definicję obiektów zbudowaną na podstawie tego wybraliśmy w interfejsie graficznym:

Taki skrypt możemy wykonać ręcznie na serwerze lub też wybrać dostępną z paska opcję Update aby narzędzie zrobiło to za nas:

Jeśli wszystko przebiegło poprawnie to powinniśmy otrzymać komunikat o powodzeniu operacji:

Dosyć ciekawie przedstawiają się również opcje narzędzia:

To właśnie w tym miejscu możemy ustalić czy narzędzie podczas porównywania struktury ma uwzględniać m.in. perspektywy, role czy też partycje. Dodatkowo to właśnie tu możemy wskazać czy po deploymencie ma nastąpić procesowanie czy też nie. Mimo, że narzędzie wygląda na dosyć proste w obsłudze to czasem możemy napotkać na trudne do obsługi problemy jak np. zależności pomiędzy obiektami w skomplikowanych modelach jednakże po pewnym czasie każdy jest w stanie nabrać płynności w posługiwaniu się BISM Normalizerem. Jest on naprawdę przydatne narzędzie nawet podczas tworzenia modelu gdzie chcielibyśmy jedynie wrzucić określoną miarę itp., a nie chcielibyśmy odpalać całego Deployment Utility aby przerzucić tylko jedną małą miarę.

Dodatkową zaletą narzędzia jest możliwość automatyzacji dzięki linii komend. Składnia sprowadza się do wskazania pliku bsmn oraz kilku dodatkowych przełączników. Na samym początku spróbujmy znaleźć lokalizację pliku BISMNormalizer.exe. Do tego celu polecam przejść do lokalizacji gdzie przechowywane są ustawienia oraz rozszerzenia do Visual Studio i tam po prostu wyszukać plik. W moim przypadku ścieżka wygląda następująco:

C:\Users\adria\AppData\Local\Microsoft\VisualStudio\16.0_7037198f\Extensions\kwi24b4k.hrj

Dlatego też używając konsoli Powershell z poziomu Visual Studio Code przeszedłem do tej lokalizacji aby swobodnie się odwoływać do pliku exe. W najprostszej postaci wywołanie BISM Normalizera wygląda następująco:

.\BismNormalizer.exe C:\Users\adria\source\repos\TabularProject1\TabularCompare1.bsmn /Log:C:\Users\adria\source\repos\TabularProject1\log.txt

pierwszym parametrem jest wskazanie pliku bsmn, następnie wskazałem plik loga w którym mogłyby być zapisane informacje o przebiegu deploymentu. Przed deploymentem celowo dokonałem kilku zmian w projekcie modelu tabelarycznego i te właśnie zmiany zostały odzwierciedlone w informacjach zawartych w pliku loga:

About to deserialize C:\Users\adria\source\repos\TabularProject1\TabularCompare1.bsmn

Source Project File: C:\Users\adria\source\repos\TabularProject1\TabularProject1\TabularProject1.smproj
Target Database: localhost;TabularProject1

--Comparing ...
--Done

--Validating ...
Informational Message for Table: Update table 'FactInternetSales'. 
Informational Message for Measure: Update measure / KPI TotalQty.
--Done

--Updating ...
Deployed changes to database TabularProject1.
Passwords have not been set for impersonation accounts (setting passwords for data sources is not supported in command-line mode). Ensure the passwords are set before processing.
--Done

Z dostępnych przełączników mamy do dyspozycji:

• Log – użyty wyżej przełącznik wskazujący gdzie ma wylądować log z operacji,
• Script – przełącznik wskazujący gdzie ma być zapisany skrypt wygenerowany przez BISM Normalizera (sama operacja aktualizacji modelu docelowego nie zostanie wykonana),
• Skip – wskazanie które elementy mają zostać pominięte – dostępne opcje to MissingInSource MissingInTarget oraz DifferentDefinitions. Możliwe jest użycie tych przełączników łącznie co może być przydatne np. w przypadku gdy kilku deweloperów wrzuca zmiany do tej samej bazy i nie chcą sobie nadpisać zmian,
• CredsProvided -wskaźnik tego czy zostały podane dane uwierzytelniające do serwera SSAS,
• SourceUserName – użytkownik modelu oznaczonego jako źródło,
• SourcePassword – hasło użytkownika modelu oznaczonego jako źródło,
• TargetUsername – użytkownik modelu oznaczonego jako miejsce docelowe,
• TargetPassword – hasło użytkownika modelu oznaczonego jako miejsce docelowe,
• WorkspaceServer – adres serwera workspace dla modelu znajdującego się w pliku projektu.

Jak widzicie możliwości jest całkiem sporo i nieco rozszerzają one to co mamy do dyspozycji w standardowym Deployment Utility. Należy pamiętać, że narzędzie samo w sobie nie pozwala na zarządzanie sposobem uwierzytelniania do źródeł danych, które powinniśmy obsłużyć sobie osobno. Mówiąc źródło danych mam tutaj na myśli źródło samego modelu, a nie źródłowy model danych użyty do porównania.

Warto sobie przećwiczyć możliwości oferowane przez narzędzie szczególnie jeśli mamy na myśli automatyzację deploymentów, ale nie tylko bo jak już wspomniałem w codziennej pracy również może ono okazać się przydatne.

Analogicznym narzędziem jest ALM Toolkit, który oferuje podobne możliwości wewnątrz Power BI Desktop. Narzędzie możecie pobrać ze strony głównej projektu znajdującej się tutaj. Instalacja nie jest czymś wyszukanym więc pozwolę ją sobie opuścić. Po instalacji możemy włączyć Power BI Desktop i tam na wstążce pod External Tools znajdziemy pożądane przez nas narzędzie:

Dla przykładu stworzyłem dwa pliki pbix w Power BI Desktop różniące się jedynie tym, że pierwszy z nich posiada miarę Total Qty, a drugi nie. Po włączeniu narzędzia z poziomu pierwszego raportu naszym oczom ukaże się dosyć podobny interfejs w stosunku do tego co widzieliśmy w BISM Normalizerze:

Fajne jest to, że narzędzie potrafi automatycznie zlokalizować instancje Analysis Services kryjące się pod otwartymi raportami i dzięki temu możemy je wybrać do porównania. Dodatkowo możemy tutaj wybrać adres workspace’a oraz plik bim lub pbit. Dosyć ciekawe rozwiązanie ale o nim za chwilę. Po dokonaniu porównania otrzymaliśmy znajome okienko z różnicami (odfiltrowałem obiekty o tej samej strukturze podobnie jak w BISM Normalizerze przy pomocy Select Actions):

Schemat działania jest identyczny i okna dialogowe wyglądają dokładnie atak samo tak więc po kliknięciu Validate Selection mamy możliwość wygenerowania skryptu lub bezpośredniej aktualizacji drugiego plik pbix poprzez kliknięcie Update. Wybrałem tą drugą opcję w efekcie dostałem następujące okno:

Wygląda na to, że wszystko przebiegło zgodnie z planem. Dlaczego nastąpiło procesowanie? W opcjach możemy zauważyć, że domyślnie, że ustawione mamy Process Default co być może w naszym przypadku nie jest najlepszym możliwym ustawieniem jednakże nic nie stoi na przeszkodzie aby to zmienić:

Co ciekawe gdy sobie podejrzymy drugi raport to zobaczymy, że nasza miara rzeczywiście tam się znalazła i cały plik został zaktualizowany i zapisany w poprawny sposób:

Jeszcze ciekawiej robi się gdy jako Target wskażemy Dataset/Model znajdujący się w chmurze:

Konkretny workspace podajemy używając następującego wzorca: powerbi://api.powerbi.com/v1.0/myorg/NazwaWorkspace – wtedy też dostaniemy okno logowania do serwisu Power BI i jeśli wszystko przebiegło poprawnie to będziemy w stanie wybrać z listy rozwijanej dostępne zestawy danych ze wskazanego workspace i dokonać porównania struktury:

Z poziomu BISM Normalizera również jesteśmy w stanie to zrobić jedyna różnica jest taka, że modele stworzone w Power BI Desktop generują nieco inne metadane w porównaniu z tym co generuje Visual Studio co może powodować dosyć kłopotliwe do utrzymania zmiany – dlatego też w ostatecznym rozrachunku warto wybrać jeden sposób działania.

Czy jest zatem jakaś różnica pomiędzy oboma narzędziami? Tak, przede wszystkim BISM Normalizer będąc częścią VS jest nieco bardziej przystosowany do do automatyzacji i nieco bardziej “korporacyjnego Business Intelligence” gdzie w moim opinii ALM Toolkit jest bardziej przydatny do scenariuszy gdzie to właśnie Power BI Desktop jest głównym narzędziem deweloperski modeli tabelarycznych czy też w przypadku podejścia  Self – Service BI. Zaletą obu narzędzi jest to, że mają one niemal identyczny interfejs dzięki czemu bardzo łatwo się “przesiąść” z jednego na drugi. Różnicą jest również linia komend dostępna w BISM Normalzer oraz to, że ALM Toolkit pozwala wskazać nie tylko na plik BIM zawierający definicję modelu ale również plik pbit czyli template z Power BI Desktop.

Ogólnie rzecz biorąc uważam, że oba narzędzia powinny się znaleźć w niezbędniku każdego specjalisty związanego z platformą danych Microsoft. Otwierają one przed nami mnóstwo ciekawych możliwości jak chociażby praca wielu ludzi nad jednym zestawem danych, czy też podział pracy w Power BI gdzie ktoś zajmuje się modelem i ETL, a jeszcze ktoś inny pracuje nad warstwą wizualizacji. Zachęcam do śledzenia dokumentacji i zapoznania się z narzędziami – pozdrawiam!