Od kilku lat zajmuję się tworzeniem rozwiązań w Azure. Miałem okazję wdrażać rozwiązania, od takich trwających kilka dni, po takie, przy których pracowało wielu dostawców, ekspertów z całego świata oraz angażowane były grupy produktowe z Azure. Projekty realizowane w chmurze Azure są różnorodne, poczynając od aplikacji mobilnych, webowych, poprzez migracje firm z on-premises do chmury, IoT dla inteligentnych fabryk oraz miast, analizy obrazów czy inteligentnych chatbotów, kończąc zaś na rozwiązaniach raportowych BI. Dzisiaj opowiem właśnie o tych ostatnich.
Przedstawię swoje doświadczenia i przemyślenia na temat raportowania BI w Azure z ostatnich kilku lat. Które usługi najlepiej sprawdziły się w projektach, a które nie? Na jakie rzeczy warto zwrócić uwagę, projektując swoje rozwiązania? Na koniec zostawię Was z architekturą referencyjną, która sprawdza się na większości projektów i od której można śmiało zacząć projektowanie swoich rozwiązań.
Czyli w wielkim skrócie: jak to jest z tym BI w Azure?
Adam Marczak
Cloud Architect z ponad 8-letnim doświadczeniem w branży IT, aktualnie pracujący w firmie Lingaro. Entuzjasta technologiczny ze szczególnym ukierunkowaniem na technologie Microsoftu oraz chmurę Azure, z którą jest związany zawodowo od kilku lat. Adam wdraża rozwiązania dla dużych firm międzynarodowych. Specjalizuje się w branży FMCG. Najnowszą pasją Adama jest prowadzenie własnego kanału na YouTubie o nazwie „Azure 4 Everyone”.
Od małych projektów wszystko się zaczyna…
Różnorodność projektów BI jest bardzo duża, ale większość wdrożeń raportowych BI da się podsumować w jednym zdaniu – „z Excela do Power BI”. Można śmiało stwierdzić, że Excel to wciąż najpopularniejsze narzędzie BI na świecie. W związku z tym migracje z Excela jeszcze przez długi czas będą powszechną praktyką.
Oczywiście tutaj pojawia się Power BI, który w bardzo krótkim czasie stał się jednym z liderów rynku raportowania.
Naturalnie nasuwa się też pytanie: gdzie ten Azure i czy w ogóle jest potrzebny? Nie zawsze. Sądzę, że Azure stanowi naturalną ścieżkę podczas rozrostu rozwiązań BI. Uwaga całkiem banalna, chociaż wynika ona z ograniczonych możliwości tych narzędzi. Żeby dobrze wyjaśnić, kiedy i dlaczego odpowiedź powinna brzmieć „tak”, trzeba najpierw zrozumieć, czym jest Power BI i dlaczego to właśnie Azure idealnie nadaje się jako ścieżka rozwoju.
Architektura Referencyjna BI Reporting dla Azure i Power BI
Zacznijmy od architektury referencyjnej, która odzwierciedla około 80% średnich i dużych projektów BI dostarczanych przez naszą firmę. Poniższy schemat przedstawia ogólny zarys architektury takich rozwiązań.
Całość procesu orkiestrujemy za pomocą usługi Azure Data Factory. Data Factory używamy również do kopiowania danych ze wszystkich wspieranych źródeł. Zwykle jest to kopiowanie w postaci 1:1 ze źródła do chmury. Do źródeł, których Data Factory nie wspiera, używamy Logic Apps. Zdarza się, choć bardzo rzadko, że korzystamy z Azure Functions, czyli zwykłego kodu C# w chmurze do zaciągania danych z zewnętrznych interfejsów aplikacyjnych, np. Google Analytics etc. Taki komponent wywołujemy wtedy z Logic Apps lub Data Factory w zależności od procesu.
Gdy dane są już w chmurze na usłudze Blob Storage, mamy zapewnione pewne kontrolki – np. w razie błędów podczas procesowania nie musimy obciążać źródeł danych ponownie. Nie obciążamy łączy, więc mamy dane w Data Center, w którym będziemy je przetwarzać, co też redukuje koszty. Biorąc pod uwagę cennik usługi Blob Storage, mamy również bardzo mały koszt przetrzymywania ogromnych ilości danych. Dużo usług bardzo dobrze współpracuje z Blob Storage.
W większości wypadków wrzucamy dane na Blob Storage, ale SQL lub Data Warehouse też się świetnie do tego nadają. Kwestia, dlaczego Analysis Services ładuje dane z Data Warehouse szybciej niż z Blob Storage, to historia na inny czas. Taka architektura zapewnia dużą optymalność kosztową, a jeśli używamy Analysis Services, to nie zawsze potrzebujemy bazy danych. Sama usługa Analysis Services używana jest do budowania modeli danych, gdzie Power BI jest ich konsumentem oraz narzędziem do wizualizacji danych.
Czym jest ten cały Power BI?
Power BI jest usługą do analizy biznesowej dostarczaną przez firmę Microsoft w ramach oferty chmury Office 365. W skład tej usługi wchodzą narzędzia do transformacji danych, ich analizy oraz wizualizacji, jak również współpracy pomiędzy użytkownikami a zespołami. Ilustruje to poniższy schemat.
Wszystko to oczywiście można wyczytać na stronie głównej Microsoftu w instrukcji Power BI. Natomiast to, co warto wiedzieć, to fakt, że narzędzie Power BI Desktop, które jest głównym elementem używanym do tworzenia raportów, jest tak naprawdę czymś, co w środowisku BI w technologiach Microsoftu było znane już od dawna, czyli połączeniem Power Query (oryginalnie znanego jako dodatek do Excela 2013), SQL Server Analysis Services oraz emulatora przeglądarki.
Uproszczone użycie można zaprezentować w następujący sposób:
Poniżej krótki opis tych elementów:
- Power Query – służy do budowania transformacji i ładowania danych do modeli analitycznych w Analysis Services. Jest to proste narzędzie ETL (Extract Transform Load) dla analityków w ramach self-service. Ma świetny interfejs użytkownika.
- SQL Server Analysis Services – umożliwia tworzenie analitycznych modeli relacyjnych (Tabular) oraz analizowanie danych za pomocą języka DAX. Narzędzie to znane jest od dawna jako część rodziny usług Microsoft SQL Server, gdzie służyło jako serwer analityczny dla Reporting Services i PowerPivot dla Excela.
- Browser Process – czyli proces przeglądarki, który wizualizuje dane zwrócone z silnika analitycznego Analysis Services.
Dzięki tym informacjom łatwiej jest zrozumieć, jak działa sam Power BI i w jaki sposób będzie się on skalować dla większych rozwiązań. Przykładowo: wiedząc, że Analysis Services jest silnikiem całego rozwiązania, można bez trudu znaleźć ogromne zasoby wiedzy w internecie dotyczące zarówno samego silnika, jak i sposobów jego optymalizacji czy automatyzacji.
Proces wdrażania BI w Azure
Mówiąc o procesie wdrażania BI w Azure, warto określić zakresy odpowiedzialności i wylistować wszystkie możliwe usługi w Azure, które mogą nas wesprzeć.
Na przykładzie migracji z Power BI podzielmy jego komponenty na odpowiednie zakresy odpowiedzialności:
Warto zwrócić od razu uwagę na poszczególne usługi w Azure, które w prawdzie nie są wszystkimi usługami, których można użyć, ale zaspokoją potrzeby ponad 90% aplikacji.
ETL, czyli procesy ekstrakcji, transformacji i ładowania danych
Azure dostarcza ogromną liczbę narzędzi, które pozwalają na sprawne przetwarzanie danych. Zwykle nie używa się jednego, lecz kilku naraz. Często wynika to z faktu, że każda z usług ma określony zbiór zastosowań, do których idealnie się nadaje. Jest to chyba jedna z najczęściej poruszanych kwestii przez naszych klientów czy programistów, którzy dopiero zaczynają swoją przygodę z Azure. Lepiej używać więcej usług, ale do wyłącznie do zadań im dedykowanych.
Usługa HDInsight (HDI)
HDInsight jest pierwszą z usług opartą na rozwiązaniach z obszaru Big Data. Bazuje na Apache Hadoop, dzięki czemu wspiera wiele frameworków, takich jak Hadoop, Spark, Hive, Kafka, Storm czy też R. Pozwala to na przeniesienie praktycznie każdego procesu ETL bez potrzeby zadawania sobie pytania, czy technologia będzie wystarczająco wydajna. Z doświadczenia wiem, że nie zawsze jest to takie oczywiste podczas używania usług oferowanych w chmurach publicznych.
Krótko mówiąc, HDInsight jest usługą pozwalającą na transformację danych. Narzędziem służącym do tworzenia transformacji są skrypty napisane w znanych językach programistycznych, takich jak Scala, Python czy R. Usługa sama zajmuje się podziałem zadań oraz rozłożeniem ich w odpowiedni sposób na serwerach (nodach). Za skalowanie liczby serwerów odpowiada również sama usługa, dzięki czemu programista musi jedynie stworzyć transformację.
Głównym minusem usługi jest to, że obecnie nie można jej wyłączyć. Nieważne, czy proces działa, czy nie, płacimy za usługę. Najlepsze, co możemy zrobić, to ustawić skalowanie, ale koszty za minimalny rozmiar klastra i tak pozostaną. I tutaj z pomocą przychodzi kolejna usługa, znana jako Azure Databricks.
Dokumentacja HDInsight
Usługa Databricks
Azure Databricks jest drugą usługą z obszaru Big Data. Wprowadzona dość niedawno do Azure, szybko zyskała sobie w naszej firmie miano najlepszej usługi do przetwarzania danych. Podobnie jak HDInsight oparta jest na technologii Apache Spark. Twórcami usługi jest ten sam zespół, który był odpowiedzialny za stworzenie samego Apache Spark.
Warto tutaj zwrócić uwagę, że samo Databricks jest tak naprawdę platformą, a nie usługą Azure. Platforma ta jest produktem komercyjnym, ale nie została stworzona przez Microsoft. Microsoft w partnerstwie z twórcami Databricks zintegrował ją w ramach usług dostarczanych przez chmurę Azure.
Jak to zwykle bywa, takie rozwiązanie ma dobre i złe strony. Zdecydowanie na plus jest uporanie się z widmem Vendor Lockingu. Vendor Locking to sytuacja, kiedy firma używa rozwiązań tylko jednego dostawcy, co stwarza ryzyko związane z monopolizacją i dużym kosztem przeniesienia do innego dostawcy. Jako że usługa Databricks jest zewnętrzną platformą, w bardzo prosty sposób można wszystkie swoje procesy przenieść do innego dostawcy chmurowego lub własnej infrastruktury. Jedynym minusem platformy jest dodatkowa opłata kalkulowana w ramach metryki znanej jako DBU (Databricks Units). To koszt licencji liczonej na każdy rdzeń procesora. Oznacza to, że na papierze usługa jest sporo droższa niż HDInsight.
Usługa ta działa praktycznie w taki sam sposób jak HDIsnight. Nie jest to tematem tego artykułu, ale warto wiedzieć, że dobra współpraca oraz gwarancja najlepiej zoptymalizowanej wersji Apache Spark na rynku, to główne czynniki sprzedażowe tej technologii.
Dokumentacja Databricks
Databricks czy HDInsight
Skoro te usługi są tak do siebie podobne, to którą wybrać? Często słysze to pytanie u nas w firmie. Moja odpowiedź w większości wypadków brzmi: używaj Databricks, ponieważ klastry są powoływane szybciej, co często jest krytycznym wymogiem, aby przetworzyć dane w określonym czasie. Dzięki lepszej wydajności przetwarzanie trwa krócej. Zaobserwowaliśmy, że samo przeniesienie skryptów bez zmian dało nam zysk w czasie przetwarzania na poziomie 10–20%. Dodatkowo Databricks w przeciwieństwie do HDIsnight ma opcję Auto Terminate, czyli po określonym czasie serwery same się wyłączają (czyt. usuwają, przy czym ich konfiguracja jest zapamiętana), przez co sama usługa wychodzi sporo taniej i nie wymaga to pisania dodatkowych skryptów automatyzujących platformę.
Dla mnie to wystarczające argumenty przemawiające za wyborem Databricks.
Data Factory (ADF)
Data Factory jest jedną z moich ulubionych usług w Azure. Jest to idealny przykład, jak powinny wyglądać usługi tworzone w modelu Platform as a Service. Estetyczny i prosty w obsłudze interfejs pozwala na tworzenie rozwiązań w oknie przeglądarki bez dogłębnej wiedzy technicznej.
Głównym założeniem usługi jest orkiestracja procesów oraz przenoszenie danych, chociaż sama usługa potrafi jedynie orkiestrować procesy, a do samych transformacji musi używać innych usług. Możliwości jest tutaj sporo, bo można wykonywać kwerendy zarówno na źródłach danych, jaki i miejscach ich docelowego przeniesienia, ale również HDInsight, Databricks, Batch Service, Data Lake Analytics i Machine Learning.
W chwili pisania artykułu w Preview jest dostępny dodatek do Data Factory, znany jako Data Flows. Element ten adresuje brak możliwości transformacji w samej usłudze dzięki nowemu edytorowi graficznemu, który pozwala na tworzenie w prosty sposób procesów transformacji danych. Tak zbudowany proces Data Factory skompiluje jako paczkę i wyśle do Databricks do przetworzenia. A my zapłacimy jedynie za czas wykonania zadania.
Dokumentacja Data Factory
Logic Apps
Logic Apps jest zdecydowanie moją ulubioną usługą w Azure. Nosi ona znamiona tzw. Enterprise Integration Service. Oznacza to, że jej głównym założeniem jest tworzenie integracji pomiędzy wieloma serwisami, nie tylko tymi z chmury Azure. Sama usługa podobnie jak Data Factory ma bardzo przyjemny interfejs użytkownika.
To, w czym Logic Apps jest o wiele lepsze od Data Factory, to liczba serwisów, z jakimi się integruje. Ponad 200 obecnie dostępnych konektorów do różnych serwisów oraz dziesiątki różnych akcji, dzięki którym tworzenie nawet bardzo kompleksowych procesów nigdy wcześniej nie było proste. Jeśli potrzebujemy wyciągnąć dane z serwisów takich jak Box, OneDrive, SharePoint czy też wysłać e-mail przez Exchange, napisać na kanale Microsoft Teams, to powinna nam to umożliwić właśnie usługa Logic Apps. To idealne dopełnienie procesów orkiestracji w Data Factory.
Dokumentacja Logic Apps
SQL Database (SQL DB) oraz Data Warehouse (SQL DW)
Trudno jest mówić o procesach transformacji danych i nie wspomnieć o Azure SQL Database oraz Data Warehouse. Bazy te są bardzo często nierozłącznym elementem architektury w aplikacjach. Azure SQL jest tradycyjną bazą relacyjna, która została zmigrowana do chmury na bazie produktu Microsoft SQL Server. Natomiast SQL Data Warehouse jest wariancją bazy SQL Server skierowaną na MPP (Multi Parallel Processing).
Bazy te świetnie sprawdzają się jako miejsce do składowania oraz modelowania danych, lecz choć świetnie sobie radzą z przetwarzaniem danych, to w Azure usługi takie jak Databricks niestety w moim mniemaniu mają sporą przewagę pod względem wygody, skalowalności czy też elastycznego modelu kosztowego.
Najłatwiej zobrazować to na przykładzie przetwarzania danych. Poniżej mamy uproszczony schemat czasu przetwarzania na bazie, która ma 100 DTU i 50 DTU (DTU to Data Transaction Unit – czyli jednostka wydajności w ramach usługi Azure SQL).
To, co się dzieje, jest raczej oczywiste: przy dwa razy mniejszej mocy obliczeniowej czas przetwarzania wydłuży się dwukrotnie. Oznacza to, że jeśli mamy wymóg przetworzenia danych w 30 minut, to nie ma innej możliwości niż posiadanie bazy, która ma 100 DTU. Problem, jaki się tutaj pojawia z Azure SQL i SQL DW, jest taki, że obecnie te usługi nie oferują autoskalowania, więc cały czas płacimy za wydajność, której potrzebujemy jedynie w momencie przetwarzania. Oczywiście niektóre projekty tworzą własną logikę autoskalowania za pomocą skryptów, ale nie jest to bez wad, bo bazy SQL zrywają podłączania podczas skalowania. No i chyba najważniejsze: po co? Są usługi, które się skalują, to nie są już czasy, kiedy programiści powinni się zajmować takimi problemami. Po to właśnie jest chmura.
Zostawiłem je na liście głównie dlatego, że są konkretne przypadki, w których sprawdzają się lepiej niż konkurencyjne produkty. Podkreślam jednak, że nie są moim pierwszym wyborem, kiedy tworzę rozwiązania BI w Azure. Ale pamiętajmy, że mówimy tutaj o samym przetwarzaniu (bardzo często używamy ich do składowania danych).
Dokumentacja SQL Database oraz Data Warehouse
- https://docs.microsoft.com/en-us/azure/sql-database/
- https://docs.microsoft.com/en-us/azure/sql-data-warehouse/
Modelowanie i składowanie danych
Gdy już wybierzemy usługi, dzięki którym przetwarzamy dane, to warto się zastanowić, gdzie te dane następnie składować oraz modelować.
Jeśli chodzi o raportowanie oparte na Power BI, trzeba rozważyć dwie opcje:
1. W Azure jedynie składujemy dane, a w Power BI tworzymy modele analityczne.
2. W Azure składujemy dane i tworzymy modele analityczne, a Power BI jedynie je konsumuje.
Trudno podjąć taką decyzję w początkowych fazach projektu. Dla uproszczenia można przyjąć, że dla małych projektów idziemy w opcję 1, dla średnich w 1 lub 2 a dla dużych od razu w 2. Jeśli chodzi o średnie projekty, to nie ma co się martwić decyzją, bo gdy zajdzie potrzeba, zawsze można wprowadzić zmiany. Oczywiście trzeba takie rzeczy wyjaśnić odpowiednio klientom, aby nie było zaskoczenia. Jak już wspomniałem, Power BI ma Analysis Services wewnątrz, co oznacza, że ścieżka migracyjna do Azure Analysis Services jest bardzo prosta.
Analysis Services (AAS)
Analysis Services jest sercem analityki dla rozwiązań opartych na Power BI i Azure. Mówiąc prostymi słowami, jest to relacyjna baza danych skierowana na wysoką wydajność oraz analizowanie modeli danych. Analysis Services posiada potężny język analitycznych zapytań DAX (Data Analysis Expression), który pozwala na analizowanie danych oraz definiowanie dynamicznych miar. Właśnie ten język używany jest w Power BI, w związku z czym zrozumienie limitacji tej technologii pomoże wydłużyć etap, w którym nie trzeba jeszcze migrować z naszym rozwiązaniem do chmury.
Jest to potężna, aczkolwiek dość droga usługa. Warto dobrze poznać jej plusy i minusy. Główną zaletą tej usługi jest jej szybkość. Dzięki modelom trzymanym w pamięci serwera można uzyskać odpowiedzi na zapytania w milisekundach, nawet jeśli tabele mają kilkanaście miliardów wierszy. Jest to krytyczne dla raportów, które będą się łączyć w modelu na żywo do tej usługi.
Najlepiej można to zobrazować na przykładzie pojedynczego raportu Power BI.
Jeśli w zakładce raportu mamy 10 wizualizacji, to Power BI wyśle 10 zapytań do Analysis Services. Oznacza to, że musi na wszystkie 10 zapytań odpowiedzieć maksymalnie w przeciągu kilku sekund, inaczej użytkownicy zaczną odczuwać dyskomfort. Niestety nie jest to na razie do osiągnięcia przy użyciu innych usług w Azure w połączeniu na żywo z Power BI.
Kolejną zaletą usługi jest dobra kompresja. Według dokumentacji mówimy tutaj o wartości pomiędzy 5- a 100-krotnością względem źródła danych. Oczywiście 100 to przypadek specjalnie przygotowanych danych. W naszych projektach zaobserwowaliśmy kompresję na poziomie około 10–20 razy. Wiadomość ta jest krytyczna podczas planowania architektury oraz kosztów, ponieważ wiedząc, ile nasz model będzie zajmować, można łatwo zaplanować, jaki rozmiar tej usługi będziemy potrzebować.
Jeśli już chodzi o sam wybór, to zwykle mówię, że magii tutaj nie ma. Jeśli wasz model po kompresji zajmuje 10 GB pamięci, to niestety nie można tego zrobić bez Analysis Services, które posiada minimum 20 GB dostępnej pamięci (lub Power BI Premium; odpowiednikiem Analysis Services w Power BI service). W Power BI są limitacje na ilość zużytej pamięci przez model i w momencie przekroczenia tego limitu zaczynają się pojawiać błędy na wizualizacjach.
Dokumentacja Azure Analysis Services
Blob Storage oraz Data Lake Storage Gen2 (ADLSv2)
Blob Storage to chyba najbardziej popularna usługa w Azure. Jest to usługa składowania BLOB-ów (Binary Large Object), czyli zwykłych plików, niezależnie od ich formatu. Główną zaletą tej usługi jest niski koszt przetrzymywania danych. Mówimy tutaj o 20$ za 1 TB (terabajt) za miesiąc dla danych, które często modyfikujemy. Jeśli dane modyfikujemy rzadko, to koszt wynosi jedynie 10$, natomiast jeśli archiwizujemy nasz backup i go nie modyfikujemy to kosztuje nas to jedynie 1$ za TB.
Oznacza to, że w większości przypadków najlepiej po prostu wszystko wrzucać na nasz Blob Storage, tam wszystko przetwarzać i docelowo jedynie dane biznesowo poprawne załadować do baz danych, gdzie jednak każdy gigabajt kosztuje sporo więcej. Dla przykładu 1TB w Azure SQL to około 113$ miesięcznie.
Istnieje też usługa okrzyknięta przez naszych klientów mianem Glorified Blob Storage, czyli Data Lake Storage Generation 2. To rozszerzenie Blob Storage, przez co cenowo wypada praktycznie tak samo, aczkolwiek z naszych doświadczeń wynika, że w praktyce wychodzi nawet taniej.
ADLSv2 jest również usługą przetrzymywania plików (BLOB), jednak jej głównym wyróżnikiem jest to, że posiada protokół kompatybilny z systemem plików Hadoop. Jako że używamy Databricks i HDInsight do przewarzania danych, śmiało można stwierdzić, że jest ona ich dobrym dopełnieniem. Usługa również posiada system plików kompatybilny ze standardem POSIX oraz integrację z Azure Active Directory, co w połączeniu pozwala użytkownikom i aplikacjom nadawać dostępy do poszczególnych plików oraz katalogów. ADLSv2 jest dość niedawno na rynku, bo wszedł w GA (General Availability) w lutym tego roku. Jedynym jego minusem jest to, że niewiele systemów go jeszcze wspiera, np. wspomniany wcześniej Analysis Services.
Dokumentacja Blob Storage oraz Data Lake v2
- https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction
- https://docs.microsoft.com/en-us/azure/storage/blobs/data-lake-storage-introduction
SQL Database oraz Data Warehouse
O bazach relacyjnych wspomniałem już wcześniej. Są super rozwiązaniem, jeśli chodzi o przetrzymywanie danych. Jeżeli w projekcie potrzebujemy relacyjnych modeli, przetwarzamy duże agregaty, nie chcemy mieć Analysis Services, a chcemy dostarczyć model biznesowy, to te bazy pozwolą nam zaspokoić te potrzeby. Dodatkowo jednym z rekomendowanych zastosowań według Microsoftu dla SQL Data Warehouse jest „self service” dla analityków, którzy potrzebują pracować na bardzo dużych wolumenach danych.
Obie bazy pozwalają również na połączenia na żywo z Power BI, dzięki czemu raporty, które nie wymagają odpowiedzi w sekundy, są dobrym zamiennikiem dla AAS.
Wizualizacje w Azure? Ale o co chodzi?
Długo się zastanawiałem czy w ogóle stworzyć dział o wizualizacjach w Azure. Tak naprawdę w Azure nie ma narzędzi do wizualizacji danych. Oczywiście wynika to z faktu, że do wizualizacji jest Power BI w chmurze Office 365. W tej sekcji opiszę jedynie usługi, które zdarzyło nam się użyć w ramach Azure, a które są dopełnieniem całości, aczkolwiek mówimy tutaj o około 5% aplikacji.
Power BI Embedded
Power BI Embedded jest to usługa, dzięki której można zagnieżdżać raporty Power BI w aplikacjach webowych. Podobnie jak Power BI Premium w Office 365 kupujemy ukryte przed nami Analysis Services z dodatkami do zarządzania oraz licencjonowaniem. Główną zaletą tej usługi jest właśnie licencjonowanie raportów Power BI, które pozwala na ich zagnieżdżanie w aplikacjach webowych bez potrzeby kupowania licencji użytkownikom. Jest to obecnie jedna z dwóch możliwości, gdzie użytkownicy nie muszą mieć licencji Power BI Pro, aby oglądać czyjeś raporty Power BI. Drugą jest Power BI Premium z Office 365. Czyli jedyna taka możliwość w samym Azure.
Plusem zagnieżdżania raportów Power BI w aplikacjach webowych jest SDK w języku JavaScript, dzięki któremu możemy zintegrować raporty z interfejsem użytkownika w naszym portalu webowym. Chociaż biorąc pod uwagę, jak dużo można robić w samym Power BI, ten argument powoli traci na sile.
Dokumentacja Power BI Embedded
Data Explorer (ADX)
Data Explorer to usługa chmurowa do analizy dużych wolumenów danych. Usługa jest w pełni obsługiwana z przeglądarki, gdzie użytkownicy mogą tworzyć proste modele danych i odpytywać je za pomocą języka KQL (Kusto Query Language). Posiada parę fajnych funkcjonalności, takich jak tabele przestawne, eksport do Excela czy połączenie na żywo z Power BI.
Uważam jednak, że dostępne są lepsze usługi, w których można osiągnąć więcej i często taniej. Zobaczymy, jak w przyszłości usługa się rozwinie, na razie my w tym kierunku nie inwestujemy.
Dokumentacja Data Explorer (ADX)
Dlaczego tak jest i co z tym dalej?
Czy można się tutaj dziwić takiemu kierunkowi? Oczywiście, że nie. Istnieje ogrom argumentów, które przemawiają za Power BI. Jednym z nich jest jego koszt, bo narzędzie jest darmowe w wersji podstawowej. Przy opłacie 9.99 $ miesięcznie można kupić licencję Professional, która posiada zbiór funkcjonalności sprawdzających się idealnie w firmach. Power BI ma również comiesięczny cykl aktualizacyjny, który wdraża naprawdę dużo nowych rozwiązań, dzięki feedbackowi od użytkowników prezentowanemu na forach. Na sam koniec warto podkreślić, że jest to produkt Microsoftu. Oznacza to, że firmy mogą być spokojne o to, że ich narzędzie będzie należycie wspierane, rozwijane i nie zniknie z dnia na dzień. Wisienką na torcie jest to, że Microsoft, który posiada własną chmurę Azure, dostarcza bardzo wiele rozwiązań integracyjnych pomiędzy platformą Power BI a Azure, które zdecydowanie ułatwiają wdrożenia.
Jeśli chodzi o samą architekturę referencyjną, od której zaczęliśmy, to warto wyrzucać nieprzydatne usługi. Jeśli nie potrzebujesz Analysis Services, to polecam dane składować w Azure SQL. Dzięki temu można stworzyć odpowiednie widoki i tabele, aby Power BI sprawnie mógł załadować dane. Natomiast jeśli mamy Analysis Services na pokładzie, to pytanie, po co nam wtedy Azure SQL.
Jeśli ktoś zapyta mnie, czemu nie Data Lake Generation 2, to odpowiem: dlatego że Analysis Services nie potrafi obecnie ciągnąć danych z ADLSv2, chociaż już w preview (na dzień pisania artykułu) pojawia się multi-protocol access dla Blob Storage, dzięki czemu Analysis Services będzie również łączyć się do Data Lake w generacji drugiej.
Architektura referencyjna nie jest odpowiedzią na wszystko. Opisałem moje doświadczenia z ostatnich lat spędzonych na tworzeniu rozwiązań BI i trendy zaobserwowane w naszej firmie. Ostatnio pojawiają się na rynku alternatywy takie jak Snowflake, ale to osobna historia. Czas i wdrożenia pokażą, co dalej.
Chcesz więcej? Posłuchaj DevTalk #93 – O PowerBI z Katarzyną Kulikovich!
Dziękuję za Twój czas i do następnego razu!
Lingaro jest dynamiczną firmą działającą w obszarze Danych i Analityki. Misją firmy jest pomoc Klientom w zdobyciu przewagi konkurencyjnej poprzez szybsze, lepsze i mądrzejsze decyzje w oparciu o Dane i Analitykę. Posiada imponujące doświadczenie zdobyte podczas pracy nad zaawansowanymi rozwiązaniami dla polskich i międzynarodowych klientów z listy Fortune 500.
Dobry materiał na start z przygoda z BI Azure oraz Big Data. Prawdziwa piguła !!! Pozdrawiam