Audyt Power BI to techniczna ocena modeli semantycznych, raportów i środowiska Power BI Service. Ma pokazać nie tylko to, co należy poprawić, ale też dlaczego powstaje problem i jaki wpływ ma na użytkowników . Inaczej bada się pojedynczy wolny raport, a inaczej środowisko, w którym kilka zespołów publikuje własne modele tych samych danych.
Model semantyczny i miary DAX
Od modelu danych często zaczyna się audyt wydajności i poprawności raportowania. Nawet dobrze napisane miary nie rozwiążą problemów wynikających z niejasnych relacji lub mieszania danych o różnej szczegółowości.
- Relacje i struktura tabel. Czy model rozdziela tabele faktów i wymiarów? Czy kardynalność, kierunki filtrowania i poziom szczegółowości danych odpowiadają pytaniom biznesowym?
- Rozmiar modelu. Czy wczytywane są nieużywane kolumny, zbędne tabele i szczegółowe dane, których żaden raport nie potrzebuje? Dotyczy to szczególnie modeli pracujących w trybie Import.
- Logika obliczeń. Czy miary DAX (Data Analysis Expressions) zwracają poprawne wyniki w różnych kontekstach filtrowania? Czy obliczenia nie powielają się w wielu raportach?
- Przygotowanie danych. Czy transformacje Power Query można usprawnić, a część operacji wykonać wcześniej w źródle lub hurtowni? Przy wybranych źródłach istotne jest zachowanie query folding.
Warto sprawdzić również, czy model nie wymusza nadmiernie złożonych miar. Jeśli do policzenia podstawowego wskaźnika potrzebne są liczne obejścia w DAX, problem może leżeć w strukturze danych, a nie w samej formule.
Dlaczego raport Power BI działa wolno?
Oczekiwanie na otwarcie raportu nie zawsze oznacza przeciążenie całego środowiska. Opóźnienie może wynikać z pojedynczej wizualizacji, kosztownego zapytania, relacji w modelu lub czasu odpowiedzi źródła w trybie DirectQuery.
Performance Analyzer pomaga sprawdzić czas ładowania poszczególnych elementów raportu, w tym czas wykonywania zapytań DAX. Wyniki warto zestawić z modelem i sposobem połączenia ze źródłami, zamiast oceniać wydajność wyłącznie na podstawie odczucia użytkownika.
Przykład: po zmianie filtra raport czeka kilka sekund na odświeżenie tabeli, choć pozostałe wykresy reagują od razu. Zanim zwiększymy pojemność, należy sprawdzić zapytanie generowane przez tę wizualizację, jej miary i liczbę przetwarzanych danych.
Osobno analizuje się czas odświeżania modelu. Wolne zasilanie danych i wolne wyświetlanie raportu mogą mieć zupełnie różne przyczyny i wymagają innych poprawek.
Power BI Service - publikacja i utrzymanie
Raport, który działa w Power BI Desktop, może sprawiać problemy po publikacji. Audyt usługi obejmuje więc nie tylko zawartość obszarów roboczych (workspaces), ale też konfigurację odświeżania, połączenia ze źródłami i odpowiedzialność za zasoby.
Sprawdzamy przede wszystkim, kto jest właścicielem modeli semantycznych, jakie konta i bramy danych (gateways) obsługują zasilanie, czy błędy odświeżania są zauważane oraz czy użytkownicy otrzymują raporty przez właściwie skonfigurowane aplikacje Power BI. Przy większych środowiskach znaczenie mają również zależności między raportami i modelami, zasady zatwierdzania modeli oraz proces przenoszenia zmian do produkcji.
Praktycznym sygnałem ostrzegawczym jest sytuacja, w której kluczowy raport zależy od poświadczeń jednej osoby. Dopóki działa jej konto, problem może pozostawać niewidoczny. Dopiero zmiana hasła lub odejście pracownika ujawnia brak właściwego modelu utrzymania.
Bezpieczeństwo, RLS i uprawnienia
Ocena bezpieczeństwa nie kończy się na sprawdzeniu ról RLS (Row-Level Security, zabezpieczenia na poziomie wierszy). Trzeba ustalić, kto może otworzyć raport, kto ma uprawnienia do modelu semantycznego, kto może edytować zawartość obszaru roboczego i jakie są możliwości dalszego udostępniania danych.
RLS nie ogranicza użytkowników z rolami Admin, Member i Contributor w danym workspace. Ograniczenia RLS mają zastosowanie do odbiorców korzystających z uprawnień właściwych do przeglądania danych, np. z rolą Viewer. Weryfikacja samych definicji ról RLS, bez sprawdzenia rzeczywistych uprawnień użytkowników, może dawać fałszywe poczucie bezpieczeństwa.
W audycie należy przeanalizować także grupy dostępu, sposób udostępniania aplikacji i raportów, uprawnienia Build oraz zasady eksportowania danych. Istotne jest przetestowanie widoczności informacji na kontach odpowiadających rzeczywistym grupom odbiorców.
Licencje, pojemność i rzeczywiste wykorzystanie
Konfiguracja licencji powinna wynikać z tego, kto tworzy raporty, kto je odbiera i w jaki sposób zawartość jest udostępniana. Przy ocenie kosztów trzeba odróżnić licencje użytkowników od zasobów pojemności obliczeniowej, jeśli organizacja z nich korzysta.
W środowiskach pracujących na pojemności Fabric lub Power BI Premium pomocna jest aplikacja Microsoft Fabric Capacity Metrics , która pozwala analizować wykorzystanie zasobów i obciążenia. Nie należy jednak zakładać, że każdy wolny raport wymaga zwiększenia pojemności. Często bardziej opłacalne będzie usprawnienie modelu, zapytania lub harmonogramu odświeżania.
Przegląd licencjonowania powinien uwzględniać aktualne warunki Microsoft oraz sposób dystrybucji treści. Nie ma jednej konfiguracji odpowiedniej dla każdej organizacji.
Co powinno znaleźć się w wynikach audytu?
Dobry wynik audytu nie jest listą ogólnych zaleceń w rodzaju „zoptymalizować DAX” albo „uporządkować uprawnienia”. Każdy istotny problem powinien mieć wskazaną przyczynę, dowód i proponowany sposób naprawy.
Na przykład: zamiast zalecenia „poprawić wydajność raportu” warto wskazać konkretną stronę lub wizualizację, wynik pomiaru, podejrzaną miarę oraz sposób sprawdzenia efektu po zmianie. Rekomendacje dotyczące bezpieczeństwa powinny z kolei podawać, które uprawnienia są zbyt szerokie i jakie ryzyko z tego wynika.
Priorytety ustala się według wpływu na dane i użytkowników. Błąd udostępniania poufnych informacji wymaga innej pilności niż nieużywana kolumna w modelu. Część poprawek można wprowadzić od razu, a zmiany architektoniczne zaplanować osobno.
Najczęstsze pytania o audyt Power BI
Czy audyt Power BI oznacza konieczność przebudowania raportów?
Nie. Audyt może zakończyć się listą drobnych zmian, na przykład poprawą relacji w modelu, ograniczeniem zbędnych kolumn lub zmianą uprawnień. Przebudowa ma sens dopiero wtedy, gdy przyczyna problemów leży w architekturze rozwiązania.
Czy wolny raport Power BI wymaga większej pojemności?
Niekoniecznie. Najpierw trzeba sprawdzić czas wykonywania zapytań, konstrukcję modelu, miary DAX, źródła danych i obciążenie pojemności. Zwiększenie zasobów nie naprawi błędnej relacji ani nieefektywnego zapytania.
Czy RLS chroni użytkowników z uprawnieniami do edycji obszaru roboczego?
Nie. RLS nie ogranicza osób z rolami Admin, Member i Contributor w obszarze roboczym. Dlatego audyt powinien obejmować jednocześnie role obszaru, role RLS w modelu i sposób udostępniania zawartości.
Czy audyt Power BI można wykonać bez uprawnień administratora?
Tak, ale jego zakres będzie ograniczony. Można zbadać udostępnione raporty i modele semantyczne, natomiast pełny przegląd ustawień dzierżawy, aktywności użytkowników czy konfiguracji pojemności wymaga odpowiednich uprawnień i dostępu do danych administracyjnych.
Dokumentacja techniczna Microsoft
Podczas przeglądu modeli, uprawnień i wydajności można odwołać się do następujących materiałów Microsoft Learn:
- Modelowanie danych i schemat gwiazdy w Power BI
- Pomiar wydajności raportów za pomocą Performance Analyzer
- Role i uprawnienia w obszarach roboczych Power BI
- Monitorowanie pojemności w Fabric Capacity Metrics
Powiązane materiały
Potrzebujesz wdrożenia lub audytu?
MicrosoftBI wyjaśnia podejście i architekturę. Jeżeli chcesz przejść do realizacji, sprawdź usługę Antdata odpowiadającą temu obszarowi.
Wdrożenia Power BI w Antdata →