Power BI – Best Practices - Part 1
Tworzenie modelu danych w Power BI Desktop jest jednym z największych wyzwań konsultantów pracujących z tym narzędziem. Od tego, jak taki model zostanie zbudowany zależy później czy da się go szybko odświeżyć, czy zapytania wykonują się szybko, czy prezentowane wyniki na raportach są poprawne oraz czy raport jest czytelny dla odbiorców, a model dla innych konsultantów Power BI. Poniżej przedstawiona jest część pierwsza listy dobrych praktyk (ang. best practices), które przy odpowiednim zastosowaniu umożliwią budowę optymalnie działających i prezentujących się modeli oraz raportów Power BI.
# Best Practice 1 – Postać modelu danych
Z wielu doświadczeń wynika, iż w Power BI najlepiej sprawdza się model gwiazdy (ang. star schema). Wyróżniane są w nim tabele faktów (ang. fact tables), w których znajdują się informacje o danych transakcyjnych pochodzących ze zdarzeń biznesowych oraz tabele wymiarów (ang. dimension tables), które z kolei opisują te zdarzenia. Tabele faktów są połączone z tabelami wymiarów przy pomocy odpowiednich kluczy. Model gwiazdy może istnieć już na poziomie hurtowni danych lub można go stworzyć podczas importu danych do Power BI. Należy zaznaczyć, że model gwiazdy jest stosunkowo łatwy do zrozumienia przez użytkownika końcowego. Z punktu widzenia Power BI, taki model daje największą wydajność, gdyż w dużym stopniu odzwierciedla to, w jaki sposób odbywa się filtrowanie danych.
Rys 1 – Przykład zastosowania schematu gwiazdy w Power BI Desktop
Uważny czytelnik może zapytać: dlaczego nie umieścić wszystkich danych w jednej, dużej tabeli? Z punktu widzenia silnika Power BI, jest on w stanie sobie z tym poradzić naprawę dobrze poprzez zastosowanie kompresji. Niemniej jednak, wszelkiego rodzaju obliczenia są utrudnione. Przykładowo, analizując sprzedaż, jeden klient może występować w wielu wierszach tabeli. Chcąc przeanalizować średni wiek klienta, nie można użyć prostej miary liczącej średnią wieku, lecz bardziej skomplikowanego obliczenia. Stąd zaleca się używanie modelu gwiazdy.
# Best Practice 2 – Silnik Power BI
Silnik Power BI w dużej mierze opiera się na silniku SSAS Tabular. Istnieje więc kilka prostych sposobów, aby z punktu widzenia silnika model działał wydajnie:
unikanie używania kolumn o dużej liczbie unikalnych wartości – wysokiej kardynalności (ang. high cardinality)
Im większa liczba unikalnych wartości, tym trudniej jest silnikowi je skompresować. Na potrzeby modelu danych warto w szczególności unikać kolumn, w których znajduje się dowolny tekst (ang. free text data columns). Idealnym sposobem na zmniejszenie kardynalności jest również rozdzielenie kolumn typu Date/Time na dwie kolumny Date i Time. Przy okazji warto się zastanowić, czy z punktu widzenia użytkownika faktycznie konieczna jest kolumna Time (bardzo często okazuje się, że nie). W przypadku liczb dziesiętnych, należy możliwie jak najbardziej zmniejszyć liczbę cyfr z rozwinięcia dziesiętnego – często 2 miejsca po przecinku zapewniają wystarczającą dokładność.
Usuwanie niepotrzebnych kolumn
Jest to jedna z podstawowych zasad modelowania Power BI. Jeśli wiadomo, że kolumna nie będzie używana zarówno do wizualizacji, jak i obliczeń – należy niezwłocznie usunąć ją z modelu danych.
Usuwanie pośrednich kolumn
Często podczas testów do wyliczenia skomplikowanych kolumn obliczeniowych, tworzy się kolumny pośrednie. Jeśli finalna kolumna okaże się poprawna, warto spróbować skonsolidować do niej kolumny pośrednie, a następnie je usunąć, aby odchudzić model.
Dążenie do korzystania z miar zamiast kolumn obliczeniowych
Jeśli istnieje taka możliwość, należy starać się korzystać z miar. Do ich głównych przewag należą szybki czas procesowania oraz brak zajmowania przestrzeni w modelu.
Rys 2 – Miejsce wyboru elementu obliczeniowego w Power BI Desktop
Korzystanie z kluczy technicznych
Bardzo złą praktyką w Power BI jest tworzenie klucza poprzez łączenie wszystkich kluczy biznesowych w jeden, który następnie używany jest do połączeń – może to powodować wolne działanie modelu. Dużo lepiej używać jest do połączeń tabel dedykowanych kluczy zastępczych (ang. surrogate keys). Z tego względu warto rozważyć stworzenie hurtowni danych przed przystąpieniem do budowy modelu danych Power BI.
# Best Practice 3 – Power BI Desktop Update
Warto mieć zawsze zainstalowaną najnowszą wersję Power BI Desktop. Aktualizacje aplikacji wydawane są w trybie miesięcznym. Ściągając wersję Power BI Desktop Windows 10, domyślnie aktualizacje instalują się automatycznie. Aby dowiedzieć się o najnowszych zmianach w ostatniej wersji można skorzystać ze strony: https://docs.microsoft.com/en-us/power-bi/fundamentals/desktop-latest-update. Może zdarzyć się również sytuacja, że konieczne jest przywrócenie starszej wersji Power BI – archiwum wersji znajduje się pod adresem https://docs.microsoft.com/en-us/power-bi/fundamentals/desktop-latest-update-archive. Aby sprawdzić aktualnie zainstalowaną wersję Power BI Desktop, należy wybrać z paska narzędzi Plik (ang. File), a następnie Informacje (ang. About).
Rys 3 – Informacja o aktualnie zainstalowanej wersji Power BI Desktop
# Best Practice 4 – Import danych do Power BI Desktop
Istnieje zestaw dobrych praktyk dotyczący importu danych do Power BI Desktop. Edytując zapytania w edytorze Power Query, warto pamiętać o odpowiednim nazewnictwie poszczególnych transformat, tak aby inny developer na pierwszy rzut oka był w stanie stwierdzić, za co dana transformata jest odpowiedzialna. Ponadto, samo zapytanie również powinno być odpowiednio nazwane pod kątem biznesowym.
Również w samym modelu danych, nazwy poszczególnych tabel i kolumn powinny być jak najbardziej zrozumiałe biznesowo dla użytkownika. Złą praktyką natomiast jest używanie przedrostków (ang. prefixes) i przyrostków (ang. suffixes) technicznych oraz nazw schematów pochodzących bezpośrednio z hurtowni danych. Ta dobra praktyka jest szczególnie ważna, gdy planujemy korzystać z funkcjonalności Q&A.
Korzystając z relacyjnych baz danych jako źródeł, należy również unikać importowania całych tabel do modelu danych, lecz korzystać z dedykowanych widoków (ang. views) stworzonych po stronie bazy danych. Widoki takie umożliwiają wybór odpowiednich kolumn, nadanie odpowiednich aliasów biznesowych, a także dokonanie wstępnych transformacji.
W Power BI jest również zaimplementowany mechanizm składania zapytań (ang. query folding). W dużym skrócie chodzi o to, aby jak najwięcej logiki zapytania było przekazywane do źródła. Przykładowo, SQL Server dużo lepiej poradzi sobie z filtrowaniem, agregacją czy obliczeniami na dużych zestawach danych niż silnik Power Query. Trzeba jednak pamiętać o tym, iż nie da się złożyć zapytania dla każdej transformacji. W związku z tym powinny być one wykonywane w zapytaniu najpóźniej, jak tylko się da. W celu sprawdzenia możliwości złożenia transformacji dla danego zapytania, należy kliknąć prawym przyciskiem myszy na transformację i sprawdzić czy opcja „View Native Query” jest włączona.
Rys 4 – Opcja „View Native Query” w menu kontekstowym
Dla części źródeł np. plików tekstowych czy plików Excel składanie zapytań nie jest możliwe. Należy wtedy skłaniać się do możliwie maksymalnego redukowania rozmiaru zestawu danych. Wszelkiego rodzaju filtrowanie danych powinno odbywać się jako jeden z pierwszych kroków zapytania, podobnie z usuwaniem kolumn. Obliczenia powinny być dokonywane w późniejszych krokach.
Może zdarzyć się taka sytuacja, że wiele zapytań wykonuje tę samą transformację, która jest pewnym skomplikowanym obliczeniem. Warto zastanowić się wtedy nad stworzeniem funkcji w języku M, używanej ponownie w każdym z zapytań. Więcej informacji na temat tworzenia funkcji w języku M znajduje się pod adresem: https://docs.microsoft.com/en-us/powerquery-m/understanding-power-query-m-functions.
Podsumowanie
Powyższy zbiór zasad jest na pewno jedynie zbiorem otwartym dobrych praktyk, może on być rozszerzony o kolejne, niemniej jednak stanowi niewątpliwie dobrą bazę podczas tworzenia modelu danych i raportów w Power BI Desktop. Większość tych praktyk wymaga niewielkich nakładów ze strony developera (często w postaci zmiany swoich nawyków), a w zamian pozwala osiągnąć bardzo satysfakcjonujące rezultaty. Wkrótce na blogu BitPeak’a pojawi się również druga część dobrych praktyk, w której zostaną opisane m.in. narzędzia do analizy wydajności, porady dotyczące języka DAX, a także wskazówki co do optymalnego korzystania z wizualizacji.
Warto zaznaczyć, że BitPeak świadczy usługę Power BI Audit, w ramach której specjaliści z naszej firmy pomagają organizacjom zastosować m.in. wymienione praktyki do ulepszania modeli Power BI. Pełen zakres usług Power BI Audit będzie niebawem opisany na naszym blogu.
Na koniec, życzę wszystkim Power BI developerom, żeby Wasze modele i raporty uwzględniając wspomniane best practices miały Power! 😊
Mateusz Bargieł
BI Consultant w BitPeak