Power BI to, oprócz normalnych wdrożeń, doskonałe narzędzie do przygotowywania wstępnej analizy jakiegoś zestawu danych czy też projektów typu Proof of Concept. Takie projekty często kończą się po prostu prezentacją lub na takim etapie, że klient końcowy jest w stanie otworzyć plik w Power BI Desktop oraz przyjrzeć się danym samodzielnie. Raport może zostać przygotowany oraz odświeżony/załadowany na dowolnym komputerze i po skopiowaniu dane będę zapisane w samym pliku raportu. Dzisiaj chciałbym poruszyć jednak problem w którym chcielibyśmy osobie trzeciej udostępnić możliwość dalszej pracy z danymi wraz z możliwością ich dalszego modelowania. Problem polega na tym, że w takim przypadku musimy zadbać o udostępnienie danych do pracy z Power BI. Jeżeli dane nie zostaną dostarczone niemożliwa będzie jakakolwiek możliwość edycji danych (zapytań).
Podczas udostępniania danych chcielibyśmy pewnie zadbać o prostotę zarówno dla osoby, która dane będzie udostępniała, jak i o wygodę osoby, która te dane ma otrzymać. Poniżej postaram się wymienić różne opcje udostępniania danych wraz z ich plusami oraz minusami.
Plusy | Minusy | |
Eksport do plików płaskich (.txt, .json) | Format znany każdemu | Duża liczba plików |
Brak potrzeby instalacji dodatkowego oprogramowania i sterowników | Problematyczne w przypadku większych zbiorów danych | |
Potrzeba przygotowania mechanizmu do eksportu np SSIS | ||
Brak ochrony hasłem – możliwość spakowania do archiwum oraz ustawienia hasła do archiwum | ||
Eksport do Excela | Format znany każdemu | Problematyczne lub niemożliwe w przypadku większych zbiorów danych |
Brak potrzeby instalacji dodatkowych sterowników | Potrzeba przygotowania mechanizmu do eksportu np. SSIS | |
Potrzeba posiadania Microsoft Excel | ||
Brak ochrony hasłem – możliwość spakowania do archiwum oraz ustawienia hasła do archiwum. Uwaga – arkusze wspierane hasłem niewspierane w tym momencie | ||
Eksport do bazy Microsoft Access | Format znany większości | Potrzeba posiadania Microsoft Access (dostępny w Office 365 lub Office Professional) |
Prosty import z bazy danych za pomocą kreatora | Potrzeba posiadania takiej samej wersji Office i Power BI Desktop (32bit lub 64bit lub konieczność instalacji dodatkowego sterownika | |
Stosunkowo wydajny w przypadku większych zbiorów danych (do 2gb na jeden plik) | Brak ochrony hasłem – możliwość spakowania do archiwum oraz ustawienia hasła do archiwum. Uwaga – bazy wspierane hasłem niewspierane w tym momencie | |
Jeden plik dla wszystkich danych | ||
Możliwość łatwego podejrzenia/modyfikacji danych w samym MS Access | ||
Backup bazy danych (dowolnej) | Jeden plik dla wszystkich danych | Potrzeba posiadania serwera bazy danych |
Wydajny w przypadku większych zbiorów danych | Potrzebna znajomość administracji serwera bazy danych | |
Prosty eksport – wykonanie backupu | Możliwość ustawienia hasła/zaszyfrowania | |
Przygotowanie skryptów do utworzenia bazy danych (dowolnej) |
Duża liczba plików | |
Potrzeba podstawowej znajomości bazy danych | ||
Potrzeba posiadania serwera bazy danych | ||
Raczej nie wydajne w przypadku większych zbiorów danych | ||
Brak ochrony hasłem – możliwość spakowania do archiwum oraz ustawienia hasła do archiwum. Uwaga – arkusze wspierane hasłem niewspierane w tym momencie | ||
Eksport do bazy danych SQL Lite | Jeden plik bazy danych | Konieczność przygotowania mechanizmu do eksportu np SSIS |
Stosunkowo wydajne w przypadku większych zbiorów danych | Konieczność instalacji dodatkowych sterowników na komputerze klienta (SQLLite ODBC Driver) | |
Konieczność skonfigurowania połączenia ODBC w systemie | ||
Możliwość ustawienia hasła/szyfrowania | ||
Eksport do chmury prywatnej (własny serwer, chmura prywatna, NAS) | Połączenie bezpośrednio do bazy danych | Konieczność posiadania chmury prywatnej |
Wydajne dla dużych zbiorów danych | Konieczność przesyłania danych poprzez Internet lub dość skomplikowana konfiguracja | |
Możliwość ustawienia hasła/szyfrowania | ||
Eksport do chmury publicznej | Połączenie bezpośrednio do bazy danych | Konieczność posiadania subskrypcji/chmury publicznej |
Wydajne dla dużych zbiorów danych | Konieczność przesyłania danych przez Internet lub dość skomplikowana konfiguracja | |
Możliwość ustawienia hasła/szyfrowania |
Według mnie najkorzystniejszym scenariuszem jest posiadanie jednego pliku, który można przenieść/wysłać na inny komputer. W idealnym świecie plik ten powinien umożliwić przechowywanie większej ilości danych (kilka – kilkanaście milionów, kilka – kilkanaście tabel). Dodatkowo ważnym aspektem jest ewentualna możliwość zaszyfrowania lub ochrony hasłem przesyłanego zbioru danych. Z drugiej strony, duża ilość plików płaskich może wprowadzić niepotrzebne zamieszanie oraz ewentualne problemy z odświeżaniem na innym komputerze. W przypadku plików płaskich sama ich generacja będzie wymagać również dodatkowej pracy. Biorąc pod uwagę powyższe, w moim odczuciu, wygrywa eksport do bazy danych Access. Wydaje mi się, że nie jest to najbardziej oczywisty wybór. Mimo, że połączenie do bazy danych lub Analysis Services w np. Azure wygląda korzystniej to niestety trzeba posiadać odpowiednie zasoby. Baza danych Access zapewnia prosty import danych z bazy danych, pozwoli zaimportować stosunkowo duże ilości danych (do 2gb dla pliku wynikowego bazy) oraz, co ważne, w wyniku otrzymujemy jeden plik. Oczywiście Power BI Desktop posiada znaczniej więcej możliwości połączenia do różnych źródeł i pewnie wiele zależy od preferencji, natomiast dla mnie w tym konkretnym przypadku Microsoft Access wygrywa. Jak to wygląda z waszej perspektywy?
- Docker dla amatora danych – Tworzenie środowiska (VM) w Azure i VirtualBox (skrypt) - April 20, 2020
- Power-up your BI project with PowerApps – materiały - February 5, 2020
- Docker dla “amatora” danych – kod źródłowy do prezentacji - November 18, 2019
Dzięki za interesujący post.
Mam pytanie, wspomniałeś eksport do bazy danych SQL Lite, w jaki sposób można ograniczyć dostęp do danych dla SQL Lite, tak aby ktoś kto ma dostęp do pliku( który stanowi bazę danych) nie mógł się dostać do bazy i wyciągnąć dane.
Spotkałem się z tym problemem w praktyce. Sql Lite nie posiada sam w sobie opcji ustawiania użytkowników i haseł, tym samym ktoś kto ma dostęp do pliku ma dostęp do danych.
Jednym z rozwiązań tego jest hashowanie/szyfrowanie danych docelowo w samej bazie – jednak wymaga to często płatnych pluginów oraz ogranicza wydajność po stronie bazy danych. Za wskazówki będę wdzięczny.