Przy podłączeniu do niektórych źródeł danych (np. SQL Server) w pracy z Power BI możesz wybrać tryb, w jakim będziesz korzystać danych: Import lub Direct Query. Dodatkowo w Power BI znajdziemy też tryb Live Connection. O co tak właściwie z nimi chodzi? Jakie są ich wady i zalety? Jakie są optymalne scenariusze do korzystania każdego z nich? Prześledźmy razem zagadnienie!
Tryb Import w Power BI – co to tak właściwie jest?
Załóżmy, że budujesz raport, dla którego część danych znajduje się na relacyjnej bazie danych. Może to być Microsoft SQL Server. Przy pobieraniu danych zauważysz dwa dostępne Tryby łączności danych: Importuj oraz Direct Query.
Na karcie Narzędzia główne wybieramy Pobierz dane > SQL Server
Domyślnym i sugerowanym dla Power BI trybem jest Import. Dzięki temu zrzut danych ze źródła jest zapisywany w pamięci. Silnik ten możecie kojarzyć z innych rozwiązań analitycznych np. SSAS czy AAS (Vertipaq). Nazwa silnika stosowanego przez Power BI to xVelocity. Nie wchodząc teraz w wiele szczegółów technicznych, jest to silnik, który posiada techniki kompresji. Dane są zaczytywane do pamięci i tworzy się lokalna instancja modelu. Dzięki temu, że podlegają one kompresji, zajmują fizycznie dużo mniej miejsca, niż na oryginalnym źródle. W literaturze, często spotyka się przelicznik 1:10. Czyli 10 MB danych na źródle będzie „ważyć” po zaimportowaniu do Power BI około 1 MB. Jeśli interesują Cię techniczne niuanse związane z silnikiem Power BI, zachęcam do lektury tego źródła.
Import – zalety i wady
Import jest trybem zalecanym przez Microsoft. Wszystkie interakcje z raportem będą wykonywane względem danych trzymanych w samym silniku. Główną zaletą korzystania z tego trybu jest wydajność. Jest to natywne rozwiązanie od Microsoftu, dzięki czemu wszelkie interakcje z raportem są dużo szybsze, niż w przypadku stosowania trybu Direct Query.
Kolejnym argumentem za korzystaniem z tego trybu jest możliwość korzystania z wszystkich funkcji w Power Query (język M) oraz wszystkich funkcji DAX.
W związku z tym, że dane są importowane w momencie ich odświeżania, minimalizujemy ryzyko związane z niedostępnością źródła. Dane mamy zaciągnięte i czekają do kolejnego odświeżenia.
Warto też być świadomym wad, które możemy tu napotkać, jak w każdym rozwiązaniu.
Jeśli skorzystaliśmy raz z trybu Import, nie jest możliwa zmiana trybu na Direct Query. W Internecie można znaleźć rozwiązania i obejścia, ale wymaga to pewnych modyfikacji i ingerencji w plik. Nie można zrobić tego z poziomu interfejsu Power BI. Otrzymamy następujący błąd:
Warto też pamiętać, że dane zaimportowane do silnika są aktualne na moment wykonania odświeżenia. Jeśli chcemy uzyskać najnowsze dane, musimy pamiętać o ich odświeżeniu z poziomu Power BI Desktop lub ustawieniu harmonogramu odświeżania po publikacji raportów do Power BI Service (rozwiązanie chmurowe) czy też Power BI Report Server (rozwiązanie On-Premise).
Załóżmy, że pracujemy z naprawdę dużym wolumenem danych. Wówczas należy też wziąć pod uwagę ograniczenia związane z publikowaniem raportów do usługi Power BI Service. Jeśli działamy w ramach licencji PRO i nie posiadamy dedykowanej Capacity, maksymalny rozmiar naszego datasetu (źródła do raportu z danymi) może wynieść 1 GB (po kompresji). Limity są mniej uciążliwie, gdy korzystamy z licencji PPU (Premium Per User) czy też posiadamy własną Premium Capacity. Więcej na ten temat możesz przeczytać tu.
Tryb Direct Query w Power BI
Kolejnym trybem jest Direct Query (DQ). Pewnie zastanawiasz się, czym się on tak właściwie różni. W DQ dane są pobierane ze źródła w momencie interakcji z raportem. Każda interakcja z wizualizacją czy zmiany fragmentatorów (slicerów) powodują wysłanie zapytania do źródła. W naszym przykładzie będzie to zapytanie SQL-owe, wysłane do instancji SQL Servera. Innymi słowy, dane w trybie Direct Query nie są przechowywane w ramach silnika Power BI, o którym pisałem wcześniej. Są one „poza” Power BI. Zapytanie jest wykonywane po stronie źródła, zwraca wynik i jest on prezentowany na naszym rozwiązaniu.
Więcej na temat ograniczeń, związanych z używaniem trybu Direct Query znajdziesz tutaj.
W widoku modelu jesteś w stanie łatwo zidentyfikować obiekty, które mają zdefiniowane połączenie typu Direct Query. Posiadają one charakterystyczną, niebieską linię na górze. Dodatkowo, po „najechaniu” na tabelkę, pojawi się okienko z informacją o trybie przechowywania.
Direct Query – wady i zalety:
Część autorytetów w dziedzinie produktów BI spod znaku Microsoftu sugeruje, żeby omijać Direct Query, jeśli jest to tylko możliwe. Do grona tych ekspertów zalicza się np. Nikola Ilić. Ciekawe materiały znajdziesz na jego blogu tutaj. Wskazuje on, że tryb Direct Query nie powinien być rozważany jako technika optymalizacji wydajności raportu. W związku z tym, że źródło jest odpytywane za każdym razem, gdy zachodzi interakcja z raportem.
Korzystając z trybu Direct Query, należy mieć na uwadze to, że nie wszystkie źródła danych go obsługują. Dodatkowo istnieje ryzyko, że nie będzie możliwe skorzystanie ze wszystkich funkcji/transformacji w Power Query i spotkamy się z błędem. W przeszłości pojawiały się też problemy z wykorzystaniem niektórych funkcji DAX.
Tryb DQ posiada też ograniczenie co do ilości pobieranych wierszy, jeśli korzystamy ze źródeł chmurowych (nie on-premise)- możemy pobrać maksymalnie 1 milion wierszy. Jeśli mamy więcej danych, warto by zastanowić się nad możliwością zagregowania danych już na źródle.
Jakie zalety ma zatem tryb Direct Query?
Uzyskujemy dostęp do najbardziej aktualnych danych, gdyż na bieżąco odpytujemy źródło. Nie musimy martwić się o harmonogramy odświeżania danych itp.
Dodatkowo tryb DQ ma plus w postaci skalowalności pod kątem wielkości danych. Nie napotkamy wspomnianych wcześniej limitów wielkości danych (np. 1 GB dataset przy licencji PRO). Możemy operować na naprawdę dużych zbiorach danych. Trzeba jednak pamiętać, że tutaj istotne jest, na ile wydajne jest samo źródło. Wyobraźmy sobie sytuację, w której kilku użytkowników korzysta w tym samym momencie z raportu zbudowanego w oparciu o Direct Query. Jak możemy się domyślać, nasza źródłowa baza danych będzie dostawała wiele zapytań i mogą wystąpić problemy z wydajnością.
Tryb Live connection – połączenie na żywo
Możliwe, że w pracy spotkałeś się z rozwiązaniami analitycznymi typu SQL Server Analysis Services (SSAS) lub Azure Analysis Services (AAS). Oczywiście możliwe jest podłączenie do tych rozwiązań z poziomu Power BI.
W celu podłączenia z użyciem trybu Live (pol. Importuj na żywo) na pasku Narzędzia główne wybierz kolejno: Pobierz dane > Analysis Services
Następnie podaj adres Serwera i wybierz „Połącz na żywo”
W kolejnych krokach wybierz model, z którego chcesz skorzystać.
Po skutecznym nawiązaniu połączenia, w prawym dolnym rogu znajdziesz następującą informację:
Przejdźmy teraz do charakterystyki tego połączenia.
Podobnie jak w trybie Direct Query, rozwiązanie to nie przechowuje danych w silniku Power BI. Dane znajdują się na źródle, do którego się podłączyliśmy. Power BI będzie wysyłał zapytania w momencie odświeżania wizualizacji czy interakcji z raportem. W tym rozwiązaniu wykorzystywane są zalety silnika analitycznego Analysis Services. Dzięki temu, zapytania będą cieszyć się dobrą wydajnością i „książkowo” będą szybsze, niż rozwiązanie oparte o tryb DQ, który również odpytuje źródło.
Warto pamiętać, że połączenie typu live connection może być używane tylko z ograniczoną listą źródeł, a wszystkie są rozwiązaniami Microsoftowymi:
- Azure Analysis Services (AAS),
- SQL Server Analysis Services (Tabular & Multidimensional),
- Zestaw danych Power BI (dataset) osadzony w Power BI Service (rozwiązanie chmurowe)
Pamiętaj, że skorzystanie z trybu połączenia na żywo usuwa możliwość skorzystania z Widoku danych w ramach Power BI Desktop.
Nie jest też możliwe dokonywanie transformacji w Power Query. Zastanawiasz się pewnie dlaczego? Otóż korzystamy z danych, które zostały już zamodelowane w rozwiązaniu analitycznym. Możemy wizualizować dane z gotowego modelu, zyskując wydajność. Cały świat obiektów (wymiary, fakty), relacje czy miary są już zbudowane w rozwiązaniu, które my odpytujemy. Nie musimy tego tworzyć po stronie Power BI. Istnieje możliwość budowania swoich miar na raporcie, korzystając z obiektów dostępnych na modelu (w niektórych starszych „kostkach” tej opcji nie będzie). Miary stworzone w raporcie żyją w ramach danego raportu, nie będą z automatu dodane do rozwiązania analitycznego, które odpytujemy.
W trybie Live Connection nie jest możliwe integrowanie innych źródeł danych np. plików Excel, danych z list Sharepoint’owych czy innych źródeł relacyjnych. Od jakiegoś czasu istnieje możliwość zbudowania modeli kompozytowych (ang. Composite Models), które pozwalają zmienić podłączenie do modeli przez tryb DQ i dodawanie kolejnych danych. Jednakże jest to dość zaawansowany temat i zajmiemy się nim w innym artykule.
Chcę podłączyć się do opublikowanego zestawu danych Power BI! – Jak to zrobić i jaki tryb wybrać?
W pracy możesz spotkać się też z gotowymi Zestawami danych usługi Power BI (ang. Power BI Datasets), które są opublikowane już w usłudze Power BI Service. Chcesz zwizualizować dane, które są dla Ciebie udostępnione w formie Zestawu danych? Oto kilka wskazówek:
Z paska Narzędzia główne wybierz Pobierz Dane > Zestawy danych usługi Power BI
W następnym kroku wybierz opublikowany Dataset, do którego chcesz się podłączyć i wybierz Połącz.
Następnie w Power BI Desktop zauważysz poniższą adnotację:
Jak widzisz, komunikat jest podobny do tego, który opisaliśmy w ramach Trybu Live Connection. Oznacza to, że domyślne połączenie do Zestawu danych jest w trybie live, którego charakterystykę przedstawiliśmy wyżej. W związku z tym typem połączenia domyślnie nie możesz dodawać innych źródeł danych.
Fabric – nowy tryb DirectLake, OneLake – ciekawostki
Jeśli interesujesz się nowinkami ze świata BI, z pewnością nie ominęły Cię ostatnie wiadomości o wprowadzeniu przez Microsoft nowej platformy – Fabric. Warto obejrzeć materiał na kanale YouTube Guy in a Cube, przedstawiający nowy produkt, link znajdziesz tutaj. W skrócie, oprogramowanie integruje ze sobą wiele dotychczas dostępnych usług, dzięki czemu znajdziesz je w jednym miejscu. Dodane zostały też oczywiście nowe funkcjonalności.
Wśród nich jest nowy tryb połączenia danych – Direct Lake. Można go interpretować jako kombinację omawianych wcześniej trybów Import oraz Direct Query. Inżynierowie z Microsoftu opracowali rozwiązanie działające na plikach typu Parquet. W skrócie mówiąc, jest to format plików, które zapewniają bardzo dobrą kompresję (zajmują mniej miejsca) i bardzo dobrą wydajność przy odczytywaniu danych z tych plików. W trybie DirectLake omawiany wcześniej silnik Power BI korzysta z owych plików, z zastrzeżeniem, że nie są one kopiowane do samego silnika. Pliki rezydują dalej w DataLake’u. Jest to bardzo ciekawe podejście – nie powielamy danych, trzymamy je w jednym miejscu (OneLake) i to do nich dobijają się różne usługi w ramach ekosystemu Fabric.
Sam tryb ma cechować się wysoką wydajnością – bardzo podobną do trybu Import.
Fabric jest obecnie w fazie zapoznawczej ang. Preview, przez co część funkcjonalności może jeszcze nie działać w pełni poprawnie. Jeśli jesteś zainteresowany szczegółami, odsyłam do dokumentacji. Z aktualnych ograniczeń warto pamiętać o tym, że na ten moment nie można tworzyć kolumn kalkulowanych, niektóre typy danych są nieobsługiwane, istnieją ograniczenia co do wielkości danych. Aktualnie można działać tylko z poziomu interfejsu webowego. Jeśli interesuje Cię temat związany z DirectLake, polecam też ten artykuł.
Poniżej znajdziesz przykład tabeli z danymi dotyczącymi taksówek z Nowego Jorku, odpytywanej w trybie DirectLake.
Zbiór danych jest trzymany w formie plików Paquet, znajdujących się w DataLake’u.
Oczywiście, wszystkie wcześniej omawiane tryby pozostają dostępne w ramach użytkowania Power BI w usłudze Fabric.
Który tryb w Power BI powinienem wybrać?
Zastanawiasz się teraz pewnie który tryb powinieneś wybrać przy tworzeniu swoich rozwiązań w Power BI?
Jeżeli to możliwe, skłaniaj się ku trybowi Import. Dzięki temu Twoje dane będą przechowywane w wewnętrznym silniku Power BI, zyskasz na wydajności, będziesz mógł korzystać ze wszystkich dobrodziejstw Power Query i języka DAX. Na jednej z prelekcji usłyszałem, żeby unikać trybu Direct Query kiedy, tylko możliwe.
Tryb Direct Query możesz rozważać w sytuacji, gdy masz naprawdę dużo danych na swoim źródle i nie jest możliwe ich zaczytanie w trybie Import.
Inną przesłanką do skorzystania z DQ jest konieczność posiadania danych tzw. Real time. Warto jednak przeanalizować wspomniane wyżej mankamenty tego trybu. Nie wpadajmy w pułapkę związaną z danymi real time 😊. Naprawdę rzadko spotykana jest sytuacja, żeby w systemach raportowych dane musiały być na żywo, a rozwiązanie nie mogłoby być zbudowane w oparciu o harmonogram odświeżania.
Jeszcze jednym aspektem, gdzie DQ może wziąć górę nad trybem Import jest sytuacja, gdy cała logika bezpieczeństwa odnośnie widoczności danych jest wyliczana i zaszyta po stronie źródła.
Jeśli korzystasz z gotowych rozwiązań analitycznych, które są dostępne w ramach Twojej organizacji (modele AAS, SSAS czy też zestawów danych Power BI) warto pokusić się o skorzystanie z trybu Live connection. Pamiętając jednak o jego ograniczeniach.
Podsumowanie
Dobrze mieć świadomość jak funkcjonują opisane wyżej tryby. Warto znać ich wady i zalety. Pamiętaj, żeby korzystać z trybu Import możliwie najczęściej, unikniesz wtedy większości problemów związanych z wydajnością czy brakiem możliwości wykonywania transformacji po stronie Power Query. Warto poświęcić chwilę na analizę źródła danych, żeby w świadomy sposób wybrać tryb w jakim dane będą integrowane z naszym rozwiązaniem zbudowanym w Power BI.
Daj znać, z jakiego trybu najczęściej korzystasz w swoich rozwiązaniach! Może chciałbyś podzielić się jakimiś ciekawymi scenariuszami użycia? Zapraszam do dyskusji! Czy chciałbyś poznać też modele kompozytowe, które umożliwiają łączenia danych np. z modeli AAS i innych źródeł?
