Power BI – Best Practices – Part 2
Zgodnie z zapowiedzią zamieszczoną w Power BI – Best Practices – Part 1, w niniejszym artykule omówimy kolejne dobre praktyki dotyczące budowy modeli i raportów. Przedstawimy też porady dotyczące języka DAX i podzielimy się wskazówkami dotyczącymi optymalnego używania wizualizacji. Wszystko to na podstawie Power BI, czyli narzędzia do analizy wydajności.
# Best Practice 5 – Narzędzia do analizy wydajności
Istnieje szereg narzędzi pozwalających analizować wydajność modelu, dających wskazówki jak należy go zoptymalizować. Jednym z wbudowanych w Power BI narzędzi jest Performance Analyzer, który pokazuje ile czasu zajęło obliczenie danego zapytania, a następnie ile czasu zajęło uruchomienie wizualizacji.
Rys 1 – Performance Analyzer
Jeśli zapytania DAX są problematyczne, można skorzystać z programu DAX Studio. Pozwala on podłączyć się do modelu danych w Power BI Desktop i dokonać analizy naszych zapytań.
Rys 2 – Dax Studio
Z kolei analiza użycia przestrzeni w modelu możliwa jest przy pomocy narzędzia Vertipaq Analyzer. Zajmowane miejsce jest pokazane na poziomie każdej kolumny modelu, co pozwala szybko znaleźć wąskie gardła.
# Best Practice 6 – Język DAX
Istnieje kilka istotnych dobrych praktyk tworzenia miar i kolumn obliczeniowych w języku DAX.
Zazwyczaj, gdy developer chce dokonać pewnego obliczenia, powinien zastanowić się na jakim etapie należy to zrobić. Na poziomie hurtowni danych? Czy może w Power Query podczas importu danych lub w modelu używając języka DAX? Odpowiedź na te pytania jest prosta: obliczenie powinno być dokonane tak wcześnie, jak tylko jest to możliwe. Obliczenia w modelu (rozumiane jako kolumny obliczeniowe) powinny być dokonywane w ostateczności. Powyższe rozważania nie dotyczą miar, gdyż są one z natury dynamiczne i obliczane są „w locie”.
Dodatkowo, w Power BI Desktop, kolumny numeryczne mogą być używane jako miara w wizualizacjach lub być punktem odniesienia w danej mierze. W pierwszym przypadku, jest to tzw. miara implicite (ang. implicit measure), natomiast używając kolumny w formule, korzystamy z miary zwanej explicite (ang. explicit measure). Dobrą praktyką jest możliwie jak najczęstsze używanie miar explicite, ponieważ z ich pomocą łatwiej jest dostosować kod w przypadku zmian logiki biznesowej.
Rys 3 – Podział miar na implicite i explicite
Istnieją również różne konwencje nazewnictwa miar i kolumn. Warto przyjąć jednak jeden standard, przynajmniej na poziomie danej organizacji. Przykładowo, odwołując się do kolumn, możemy używać wzorca NazwaTabeli[NazwaKolumny], natomiast do miar: [Nazwa Miary]. Często, tworząc miarę używa się znaku dwukropka oraz znaku równości, natomiast dla kolumny obliczeniowej jest używany sam znak równości. Należy zauważyć, że Power BI zarządza także sam z siebie kolorystką kodu, w celu rozróżniania miar i kolumn obliczeniowych.
Co więcej, język DAX umożliwia używanie zmiennych – przy pomocy polecenia VAR. Pozwalają one na tworzenie bardziej czytelnego i zrozumiałego kodu, ale przede wszystkim umożliwiają zmniejszenie liczby niepotrzebnych obliczeń. To z kolei znacząco wpływa na wydajność modelu.
Pamiętajmy, że w miarę możliwości należy unikać funkcji iterujących (ang. iterator functions). Dokonują one obliczeń wiersz po wierszu, co jest bardzo nieoptymalne, szczególnie jeśli mamy do czynienia z bardzo dużymi zbiorami danych. Do takich funkcji należą: AVERAGEX, SUMX, RANKX oraz MAXX. Podobnie, warto ograniczyć korzystanie z funkcji FILTER na korzyść połączenia funkcji CALCULATE i KEEPFILTERS. W celu korzystania z bogatej gamy funkcji z grupy Time Intelligence, stwórzmy dedykowany wymiar do obsługi dat i skorzystajmy z ustawienia „Mark as Date Table”.
Rys 4 – Opcja „Mark as Date Table”
# Best Practice 7 – Wizualizacje
Jednym z istotnych elementów wpływających na optymalnie działanie raportów Power BI są wizualizacje. Zależność jest prosta: im jest ich więcej, tym raport działa wolniej. Z reguły, najlepiej działają wizualizacje prezentujące dane zagregowane. Nie jest zalecane nadmierne używanie wizualizacji tabelarycznych do prezentacji danych detalicznych, szczególnie, jeśli znajduje się w niej tych danych dużo. Należy pamiętać, że poszczególne wizualizacje mają określone limity danych, jakie mogą przyjąć. Jeśli limit jest przekroczony, wizualizacje stosują określone strategie redukcji danych: https://docs.microsoft.com/pl-pl/power-bi/visuals/power-bi-data-points.
Istotnym elementem jest także redukcja niepotrzebnych zależności (ang. interactions) pomiędzy wizualizacjami. Domyślnie, wszystkie wizualizacje mają między sobą pełne interakcje. Warto się zastanowić, czy w danym przypadku jest to faktycznie konieczne. Zmniejszenie interakcji znacząco poprawia wydajność raportów.
Zdarza się, że wizualizacje wbudowane w programie Power BI Desktop okazują się niewystarczające do danych celów biznesowych. Spróbujmy wówczas zaimportować tzw. custom visuals, które pozwolą przedstawić wizualnie dane w pożądany sposób. Sprawdzoną praktyką jest, aby źródłem tych wizualizacji był Microsoft AppSource – wizualizacje z tego źródła są bowiem certyfikowane. To ważne, ponieważ oznacza, że kod przeszedł rygorystyczne testy wydajnościowe, przez co nie pogorszy wydajności raportu. Certyfikowane wizualizacje są również testowane pod kątem bezpieczeństwa, a to coraz częściej ma istotne znaczenie z punktu widzenia dojrzałej cyfrowo organizacji.
Podsumowanie
Kolejne dobre praktyki za nami! Gorąco zachęcam do ich implementacji w swoich modelach i raportach Power BI. Jednocześnie przypominam o usłudze Power BI Audit świadczonej przez BitPeak. W ramach wspomnianej usługi specjaliści z naszej firmy między innymi pomagają organizacjom zastosować wymienione powyżej praktyki do ulepszania modeli Power BI. Pełen zakres usług Power BI Audit będzie niebawem opisany na naszym blogu.
Mateusz Bargieł
BI Consultant w BitPeak