Wprowadzenie do Power BI Dashboard
Power BI to kompletne rozwiązanie raportowe, używane w wielu organizacjach do tworzenia oszałamiających wizualnie raportów. Po opublikowaniu raportów w usłudze Power BI, są one dostępne dla użytkowników biznesowych i pomagają im w analizie biznesowej wielu kluczowych problemów. Power BI pozwala użytkownikom łatwo przeprowadzać descriptive analytics, np. analizować dane historyczne, aby zrozumieć trendy i wzorce.
Budowa raportu obejmuje kilka kroków, których złożoność zależy od przypadku. Najpierw developer powinien określić, jakie dane zaimportować i zbudować z nich model. Gdy model jest gotowy, developer może zacząć opowiadać historię za pomocą danych, wykorzystując szeroki wybór wizualizacji. Należy podkreślić, że podczas tworzenia raportu zwykle iteruje się między budowaniem modelu a budowaniem wizualizacji, aż do osiągnięcia zadowalającej responsywności raportu.
Projektowanie modelu dla Power BI Dashboard
Developer może wykonywać integrację danych z różnych źródeł za pomocą Power Query. Obsługuje ono wiele źródeł, takich jak SharePoint, Azure SQL server lub Databricks. Pełna lista znajduje się tutaj. Dane z różnych źródeł mogą być używane w jednym raporcie jako jedna lub więcej tabel. Jeśli wymagane są dodatkowe transformacje na załadowanych danych, można je wykonać za pomocą Power Query w sposób low code/no code:
Na górnym menu pokazane są możliwe transformacje (zakładki Home, Transform, Add Column). Po lewej stronie znajduje się lista wszystkich zapytań Power Query w raporcie. Sekcja Applied Steps zawiera wszystkie kroki dla zapytania Product. Wynikiem każdego zapytania jest skalar lub tabela. W poniższym przykładzie zapytanie Products jest tabelą, a jego podgląd można zobaczyć na środku rysunku.
W najprostszym scenariuszu developer tworzy model jako jedną tabelę. To podejście sprawdzi się w bardzo małych raportach z bardzo małą ilością danych. Jednak w większości przypadków developer musi zbudować model gwiazdy z jedną lub więcej tabel faktów, jak ten:
W tym przykładzie tabela Sales jest tabelą faktów i przechowuje informacje biznesowe, które będą później agregowane w wizualizacjach raportu. Tabela faktów jest otoczona tabelami wymiarów, które są używane w raporcie jako filtry i definiują agregację w wizualizacjach. Najczęstsze połączenie między tabelami to 1-*, które jest również nazywane "jeden do wielu". Symbol 1 znajduje się po stronie tabeli wymiarów, a * w tabeli faktów, co oznacza, że tabele są połączone kolumnami, dla których istnieją tylko unikalne wartości w tabeli wymiarów, ale mogą się powtarzać w tabeli faktów. Prawie wszystkie połączenia są zdefiniowane przez linie ciągłe, co oznacza, że są aktywne i będą używane w wizualizacjach (chyba że zostanie to zmienione przez miarę). W poniższym przykładzie tabela date jest tabelą wymiarów odgrywającą rolę, co oznacza, że jej kolumna Date może być datą wysyłki lub datą zamówienia, w zależności od sytuacji. Linia przerywana na diagramie wskazuje, że domyślnie połączenie jest nieaktywne i musi być włączone na poziomie miary.
W powyższym przykładzie w modelu znajduje się tylko jedna tabela faktów. W bardziej ogólnym przypadku może istnieć więcej niż jedna tabela faktów połączona ze sobą za pomocą jednej lub więcej tabel wymiarów.
Najczęściej developer tworzy tabele w trybie Import, co gwarantuje najlepszą wydajność. W przypadku, gdy ilość danych jest duża, np. kilkaset milionów rekordów lub więcej, lub wymaganiem biznesowym jest dostęp w czasie zbliżonym do rzeczywistego, najbardziej optymalnym trybem przechowywania jest direct query. Wraz z niedawną premierą platformy MS Fabric pojawił się nowy, potężny tryb przechowywania: Direct Lake. W Direct Lake raport łączy się bezpośrednio z plikami w formacie kolumnowym Parquet w Lakehouse, co daje wydajność importu i świeżość danych direct query.
Bezpieczeństwo danych w Power BI Dashboards
Podczas pracy z danymi w świecie korporacyjnym bezpieczeństwo jest zwykle jednym z najważniejszych wymagań biznesowych. Developerzy Power BI mogą zabezpieczyć swoje raporty, udostępniając je tylko wymaganym użytkownikom. Zazwyczaj dostęp do raportów jest realizowany za pomocą grup bezpieczeństwa i Azure Active Directory. W niektórych przypadkach dostęp powinien być jeszcze bardziej zawężony, a użytkownicy powinni widzieć tylko część raportu. Można to osiągnąć za pomocą ról row level security (RLS). Na przykład, po skonfigurowaniu RLS jeden użytkownik może widzieć tylko dane dla Europy, a inny tylko dane dla USA. Role można zdefiniować w Power BI desktop za pomocą manage roles:
Wizualizacja danych
Po zbudowaniu i zabezpieczeniu modelu developer może zacząć wypełniać wizualizacje danymi.
Raport
Raport jest najczęstszym sposobem wizualizacji danych przez developera. Developer może wybierać spośród wielu potężnych wizualizacji:
Można używać wykresów liniowych i słupkowych do pokazywania informacji kategorycznych lub szeregów czasowych. W prawie każdym raporcie developer używa wizualizacji filtra, co sprawia, że raporty są dynamiczne. Tabele można wyświetlać za pomocą wizualizacji tabeli lub macierzy. Istnieje również wiele specjalistycznych wizualizacji używanych w różnych sytuacjach. Na przykład, do zarządzania KPI można użyć wizualizacji karty:
Po spędzeniu rozsądnej ilości czasu strona raportu może wyglądać tak:
W ramach raportów można tworzyć wiele stron. Aby udostępnić raport użytkownikom, developer publikuje go w usłudze Power BI.
Dashboard
Aby podsumować raporty na jednej stronie, można użyć interaktywnego dashboardu w usłudze Power BI:
Wszystkie wizualizacje mogą pochodzić z jednego lub więcej raportów. Wizualizacje przypięte do dashboardu pokazują aktualny stan wizualizacji z raportów nadrzędnych.
Mobile BI
Zazwyczaj użytkownicy korzystają z raportów na dużych ekranach, np. 14”>=. Istnieje jednak również możliwość korzystania z nich za pomocą smartfonów:
Należy pamiętać, że widok mobilny nie jest tworzony automatycznie i developer musi go wcześniej utworzyć z wybranych wizualizacji raportu. Ponadto należy zainstalować specjalną aplikację, aby umożliwić korzystanie z raportów na smartfonie.
Power BI App
Zazwyczaj użytkownicy potrzebują dostępu do wielu raportów. Każdy raport ma swój własny link. Aby zmniejszyć liczbę linków, którymi musi zarządzać użytkownik, developer może grupować raporty w Power BI app:
Kolejną zaletą Power BI App jest to, że oddziela środowiska development i production dla raportów: zmiany w wizualizacjach raportu są widoczne dla użytkowników dopiero po zaktualizowaniu aplikacji. Może to być bardzo przydatne, jeśli developer chce omówić z wybranym użytkownikiem biznesowym nową wizualizację w raporcie, ale nie chce, aby wszyscy użytkownicy widzieli ją na tak wczesnym etapie.
CI/CD dla raportów Power BI
Developerzy Power BI mogą używać systemów versioning, takich jak git, oraz podejścia CI/CD, aby poprawić jakość raportów.
Ostatnio do Power BI desktop dodano nową funkcję, która pozwala zapisać raport jako pojedyncze pliki tekstowe w intuicyjnej strukturze folderów. Aby to zrobić, developer powinien wybrać opcję Power BI project (PBIP) podczas zapisywania:
Po zapisaniu raportu jako PBIP jest on przechowywany jako hierarchiczna struktura folderów, która zawiera zarówno model semantyczny, jak i raport:
Developer może utworzyć repozytorium Azure DEV OPS i zatwierdzać każdą zmianę raportu. W obszarze roboczym z włączoną obsługą Fabric można synchronizować element raportu z repozytorium.
Developer może wypychać lokalne zmiany w PBIP do Azure DEV OPS git, a następnie odwiedzić obszar roboczy Fabric i zsynchronizować go z repozytorium. Developer może przełączać się między gałęziami git w obszarze roboczym Fabric, jeśli to konieczne.
Aby postępować zgodnie z podejściem continues integration i continues deployment (CI/CD), developer może utworzyć deployment pipeline z trzema środowiskami, takimi jak:
Po zapisaniu raportu jako PBIP jest przechowywany jako hierarchiczna struktura folderów, która zawiera zarówno model semantyczny, jak i raport:
Deweloper może utworzyć repozytorium Azure DEV OPS i zatwierdzać do niego każdą zmianę raportu. W obszarze roboczym obsługującym Fabric można zsynchronizować element raportu z repozytorium
Deweloper może przesunąć lokalne zmiany w PBIP do usługi Azure DEV OPS git, a następnie odwiedzić obszar roboczy Fabric i zsynchronizować go z repo. W razie potrzeby programista może przełączać się między gałęziami git w obszarze roboczym Fabric. Aby kontynuować integrację i kontynuować wdrażanie (CI/CD), programista może utworzyć potok wdrażania w trzech środowiskach takich jak:
W każdym środowisku używany jest inny obszar roboczy Power BI premium lub Fabric. Poniższy rysunek przedstawia przykład takiego rurociągu:
Dla każdego środowiska używany jest inny Power BI premium lub Fabric workspace. Poniższy obrazek przedstawia przykład takiego pipeline:
Zazwyczaj dla środowiska development ładowane są tylko przykładowe dane do raportów, a wszystkie dane do środowisk testowych i produkcyjnych. Gdy nowa funkcja zostanie dodana do środowiska development, można ją wdrożyć do środowiska Test, a po przetestowaniu można ją wdrożyć do środowiska Production. W przypadku środowiska Production developer może użyć Power BI app, aby udostępnić raporty użytkownikom.
Eksploracja danych---definicja i techniki
Power bi od danych do zaawansowanych raportow
