Power BI zaawansowany – optymalizacja raportów i poprawa ich wydajności

Wprowadzenie: dlaczego raporty Power BI zwalniają i jak podejść do optymalizacji

Raport Power BI może działać płynnie podczas projektowania, a po publikacji reagować na zmianę filtra przez kilka sekund. Często nie odpowiada za to jeden błąd, lecz połączenie kilku czynników: rosnącej ilości danych, kosztownych obliczeń, rozbudowanej strony raportu oraz ograniczeń źródła danych lub środowiska. Skuteczna optymalizacja zaczyna się od ustalenia, na co użytkownik faktycznie czeka — nie od przypadkowego upraszczania formuł czy usuwania wykresów.

Warto najpierw rozdzielić trzy sytuacje, które potocznie określa się jako „wolny raport”:

• Długie otwieranie strony raportu — użytkownik czeka na pierwsze wyniki. Przyczyna może leżeć w zapytaniach, liczbie wyświetlanych elementów, ale też w dostępności zasobów środowiska.
• Opóźnione reakcje na interakcje — zmiana zakresu dat, wybór kategorii lub przejście do szczegółów uruchamia obliczenia, których wykonanie trwa zbyt długo.
• Powolne odświeżanie danych — pobieranie i przetwarzanie danych zajmuje dużo czasu, choć sam raport po zakończeniu tego procesu może działać sprawnie.

To rozróżnienie ma znaczenie praktyczne. Przyspieszenie odświeżania nie musi skrócić oczekiwania na wykres, a uproszczenie strony raportu nie rozwiąże problemu wolnego pobierania danych. Każdy z tych objawów wymaga sprawdzenia innego fragmentu rozwiązania: od źródła i przygotowania danych, przez model i obliczenia, po sposób prezentacji wyników.

Na charakter problemów wpływa również tryb dostępu do danych. W trybie Import zapytania raportu korzystają z danych załadowanych do modelu, dlatego duże znaczenie mają jego konstrukcja i wykonywane obliczenia. W DirectQuery interakcje mogą powodować wysyłanie zapytań do źródła, więc istotne stają się także jego wydajność i czas komunikacji. Import często sprzyja szybkim analizom interaktywnym, natomiast DirectQuery bywa wybierany tam, gdzie ważny jest dostęp do aktualnych danych bez pełnego importowania ich do modelu. Żaden z tych trybów nie zastępuje jednak dobrego projektu.

Zanim wprowadzisz zmiany, określ konkretny scenariusz: która strona zwalnia, przy jakich filtrach, dla jakiego zakresu danych i czy problem występuje w Power BI Desktop, w usłudze, czy w obu miejscach. Uwzględnij też liczbę równoczesnych użytkowników. Raport sprawdzony przez jednego autora niekoniecznie zachowa tę samą szybkość przy większym obciążeniu.

Celem optymalizacji jest krótszy czas wykonania zadania biznesowego przy zachowaniu poprawności wyników. Najpierw ustal punkt odniesienia i oczekiwany czas reakcji, a następnie zmieniaj pojedyncze elementy oraz porównuj efekty w podobnych warunkach. Priorytet nadaj opóźnieniom, które najbardziej utrudniają codzienną pracę — niekoniecznie tym, które najłatwiej usunąć.

Optymalizacja modelu danych: kardynalność, typy danych, relacje i schemat gwiazdy

Model danych wyznacza granice wydajności raportu Power BI. Jeśli przechowuje zbędne szczegóły, zawiera kolumny o dużej liczbie unikalnych wartości lub łączy tabele niejednoznacznymi ścieżkami filtrowania, nawet prosta analiza może wymagać kosztownych operacji. W Cognity często słyszymy pytania, jak praktycznie podejść do optymalizacji modelu danych — odpowiadamy na nie także na blogu. Optymalizację warto zacząć od ustalenia, co oznacza jeden wiersz w każdej tabeli i które dane są rzeczywiście potrzebne odbiorcom raportu. Dopiero na tej podstawie można świadomie ograniczać rozmiar modelu i porządkować jego strukturę.

Kardynalność: znaczenie ma nie tylko liczba wierszy

Kardynalność kolumny to liczba występujących w niej różnych wartości. Kolumna statusu zamówienia może mieć ich kilka, a identyfikator pozycji transakcji — miliony. W modelach korzystających z trybu Import silnik VertiPaq przechowuje dane kolumnowo i kompresuje je. Powtarzalne wartości zwykle sprzyjają kompresji; duża liczba wartości unikalnych może zwiększać zużycie pamięci oraz koszt operacji na danej kolumnie.

Dlatego przegląd modelu powinien obejmować przede wszystkim identyfikatory techniczne, szczegółowe znaczniki czasu, adresy URL i pola opisowe. Jeśli nie służą do analizy, filtrowania ani tworzenia relacji, warto je usunąć z modelu. Ukrycie kolumny w widoku raportu nie usuwa jej danych i nie zmniejsza zajmowanej przez nią pamięci.

Ograniczanie kardynalności musi jednak wynikać z potrzeb biznesowych. Gdy raport analizuje sprzedaż wyłącznie według dni, przechowywanie czasu transakcji z dokładnością do milisekund może być zbędne. Jeżeli użytkownicy badają kolejność zdarzeń, taka szczegółowość może być konieczna. Celem nie jest więc redukcja danych za wszelką cenę, lecz eliminowanie informacji, które nie mają zastosowania w raporcie.

Typy danych: dobieraj je do znaczenia wartości

Typ danych wpływa na sposób przechowywania informacji, poprawność obliczeń i możliwość łączenia tabel. Liczby całkowite, wartości dziesiętne, daty oraz tekst powinny odzwierciedlać rzeczywistą naturę danych. Sam wygląd wartości nie wystarcza: kod pocztowy lub numer produktu z zerami wiodącymi może wymagać typu tekstowego, mimo że składa się z cyfr.

• Klucze relacji: w hurtowniach danych często stosuje się całkowitoliczbowe klucze zastępcze. Mogą być korzystniejsze niż długie klucze tekstowe, ale sama zmiana typu nie zmniejsza liczby unikalnych wartości.
• Wartości liczbowe: liczby całkowite stosuj tam, gdzie nie występują części ułamkowe. Dla kwot rozważ stałą liczbę dziesiętną, jeśli wymagana precyzja mieści się w czterech miejscach po przecinku.
• Daty i czas: zachowuj tylko taką dokładność, jakiej wymaga analiza. Odróżniaj zmianę typu lub wartości od formatowania — wyświetlanie samej daty nie usuwa części czasowej zapisanej w danych.

Schemat gwiazdy: oddziel zdarzenia od ich opisu

Schemat gwiazdy porządkuje model wokół tabel faktów i tabel wymiarów. Tabela faktów przechowuje zdarzenia oraz wartości podlegające analizie, na przykład pozycje sprzedaży, ilości i kwoty. Wymiary opisują te zdarzenia: zawierają produkty, klientów, daty czy lokalizacje. Dzięki temu atrybuty opisowe nie muszą być powielane w każdym wierszu tabeli faktów, a ścieżki filtrowania są czytelniejsze.

Podstawą jest spójna ziarnistość tabeli faktów. Jeśli jeden wiersz odpowiada pozycji zamówienia, nie należy dopisywać do tej samej tabeli miesięcznych podsumowań jako kolejnych rekordów. Takie mieszanie poziomów szczegółowości utrudnia analizę i grozi podwójnym zliczaniem. Wymiary powinny natomiast udostępniać jednoznaczny klucz dla każdego opisywanego obiektu.

Relacje: preferuj prosty, jednoznaczny przepływ filtrów

W schemacie gwiazdy typowym rozwiązaniem jest relacja jeden-do-wielu: unikalny klucz po stronie wymiaru łączy się z wieloma rekordami faktów. Najczęściej wystarcza jednokierunkowe filtrowanie od wymiaru do tabeli faktów. Taki układ ułatwia przewidywanie wyników i ogranicza złożoność propagacji filtrów.

Relacje wiele-do-wielu oraz filtrowanie dwukierunkowe mają uzasadnione zastosowania, ale nie powinny zastępować uporządkowania danych. Mogą tworzyć niejednoznaczne ścieżki i zwiększać koszt obsługi zapytań. Przed ich użyciem sprawdź unikalność kluczy, zgodność typów danych po obu stronach relacji oraz to, czy problem nie wymaga osobnej tabeli pośredniczącej. Dobry model nie ma najmniejszej możliwej liczby tabel — ma strukturę, która wiernie opisuje dane i pozwala filtrować je bez zbędnej złożoności.

Optymalizacja DAX: miary a kolumny, zmienne, kontekst obliczeń i unikanie zbędnych iteratorów

Wydajność DAX zależy nie tyle od długości formuły, ile od zakresu danych i sposobu ich przetwarzania. Krótka miara może wykonywać kosztowne obliczenia dla wielu wierszy, a bardziej rozbudowane wyrażenie — sprawnie korzystać z prostych agregacji. Optymalizację warto zacząć od ustalenia, co musi być obliczane dynamicznie, w jakim kontekście i na jakim zbiorze danych. Dopiero potem należy zmieniać zapis formuły.

Miara czy kolumna obliczeniowa — wybór zależy od zastosowania

Miara jest obliczana podczas obsługi zapytania, z uwzględnieniem bieżącego kontekstu filtrów. Sprawdza się przy sumach, marżach, udziałach procentowych i innych wynikach, które mają reagować na wybór okresu, produktu czy regionu. Jej wartości nie są przechowywane w modelu jako osobna kolumna.

Kolumna obliczeniowa przypisuje natomiast wynik do poszczególnych wierszy. W tabelach w trybie Import jej wartości są wyliczane podczas przetwarzania modelu i przechowywane w pamięci. Może służyć do tworzenia kategorii używanych na osiach, w filtrach lub do grupowania danych. Jej zawartość nie zmienia się pod wpływem wyborów użytkownika w raporcie.

Miara nie jest automatycznie szybszym zamiennikiem każdej kolumny. Jeśli jednak potrzebny jest wyłącznie zagregowany wskaźnik, tworzenie dodatkowej kolumny dla każdego wiersza może być nieuzasadnione. Z kolei miara nie zastąpi bezpośrednio kolumny potrzebnej do grupowania danych.

Zmienne VAR: czytelność i kontrola nad obliczeniami

Zmienne pozwalają nazwać wyniki pośrednie i korzystać z nich w dalszej części wyrażenia. Ułatwiają analizę formuły, ograniczają powtarzanie tego samego kodu i mogą zapobiegać ponownemu wykonywaniu identycznych obliczeń. Samo dodanie VAR nie gwarantuje jednak przyspieszenia — znaczenie ma to, jakie wyrażenie zapisujesz i gdzie je definiujesz.

Udzial sprzedazy =
VAR WartoscBiezaca = [Wartosc sprzedazy]
VAR WartoscWszystkichKategorii =
    CALCULATE(
        [Wartosc sprzedazy],
        REMOVEFILTERS('Produkt'[Kategoria])
    )
RETURN
    DIVIDE(WartoscBiezaca, WartoscWszystkichKategorii)

W tym przykładzie licznik zachowuje bieżące filtry, a mianownik usuwa filtr z kolumny kategorii produktu. Pozostałe filtry nadal obowiązują. Funkcja DIVIDE obsługuje również przypadek zerowego lub pustego mianownika — bez podania wyniku alternatywnego zwraca pustą wartość.

Kontekst obliczeń: warunek poprawnej optymalizacji

Kontekst filtra określa, które dane uczestniczą w obliczeniu. Powstaje między innymi na podstawie filtrów raportu oraz pól użytych w wizualizacji. Kontekst wiersza wskazuje natomiast aktualnie przetwarzany wiersz; występuje w kolumnach obliczeniowych i podczas działania iteratorów.

Funkcja CALCULATE pozwala modyfikować kontekst filtra, a w obecności kontekstu wiersza przeprowadza przejście kontekstu. To istotne przy wywoływaniu miar wewnątrz iteratorów: takie wywołanie automatycznie uruchamia przejście kontekstu, co przy rozbudowanej logice może zwiększać koszt obliczeń.

Ważne jest również miejsce definiowania zmiennych. Zmienna zachowuje wartość obliczoną w kontekście swojej definicji. Przekazanie jej do CALCULATE nie powoduje ponownego obliczenia pod zmienionymi filtrami. Dlatego w mianowniku powyższego przykładu użyto miary [Wartosc sprzedazy], a nie zmiennej WartoscBiezaca.

Iteratory: ograniczaj zbędną pracę, nie eliminuj ich za wszelką cenę

Funkcje takie jak SUMX czy AVERAGEX obliczają wyrażenie dla kolejnych wierszy tabeli, a następnie agregują wyniki. Są potrzebne na przykład wtedy, gdy wartość sprzedaży trzeba wyznaczyć jako sumę iloczynów ilości i ceny z poszczególnych pozycji. Iloczyn sum tych kolumn dałby inny wynik.

Jeżeli zadanie sprowadza się do zsumowania istniejącej kolumny, wybierz prosty zapis SUM('Sprzedaz'[Kwota]). Szczególnej uwagi wymagają natomiast zagnieżdżone iteratory oraz wywoływanie złożonych miar dla każdego wiersza dużej tabeli. Tam, gdzie zachowuje to znaczenie obliczenia, warto iterować po mniejszym zbiorze — na przykład unikatowych kategoriach zamiast wszystkich transakcjach.

Nie każdy iterator jest wąskim gardłem: proste wyrażenia silnik potrafi wykonać efektywnie. Celem jest usunięcie niepotrzebnych obliczeń i ograniczenie zakresu przetwarzania, a nie samo wyeliminowanie funkcji z literą X w nazwie. Po zmianie formuły należy sprawdzić także sumy końcowe i wyniki przy różnych filtrach — szybsza miara musi nadal odpowiadać na to samo pytanie biznesowe.

Optymalizacja Power Query: query folding, transformacje i przygotowanie danych pod model

W Power Query o wydajności decyduje nie tylko to, jakie przekształcenia wykonujesz, lecz także gdzie są wykonywane i ile danych muszą przetworzyć. Ten sam wynik można uzyskać, pobierając całą tabelę i filtrując ją lokalnie albo zlecając filtrowanie bazie danych. Przy dużych zbiorach różnica w czasie przetwarzania i zużyciu pamięci może być znacząca.

W trybie Import optymalizacja Power Query wpływa przede wszystkim na pobieranie, przekształcanie i odświeżanie danych. Nie przyspiesza bezpośrednio obliczeń wykonywanych podczas klikania w raport, choć ograniczenie zakresu ładowanych danych może pomóc również na tym etapie. W DirectQuery sposób przygotowania zapytań ma natomiast znaczenie także podczas korzystania z raportu, ponieważ zapytania trafiają do źródła danych. W Cognity omawiamy optymalizację Power Query zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Query folding — przekaż pracę do źródła

Query folding polega na przełożeniu kroków Power Query na zapytanie wykonywane przez system źródłowy, na przykład bazę SQL. Dzięki temu filtrowanie, wybór kolumn czy część operacji łączenia tabel mogą odbyć się przed przesłaniem wyników do Power Query. Zakres obsługiwanych przekształceń zależy od konektora, źródła i konstrukcji zapytania. Typowe pliki CSV nie oferują takiego mechanizmu jak relacyjna baza danych.

Przykładowo: jeśli raport potrzebuje wyłącznie sprzedaży od początku określonego roku, korzystniej jest przekazać ten warunek bazie niż pobierać pełną historię i dopiero później odrzucać starsze rekordy. Warto sprawdzać możliwość składania zapytania po istotnych zmianach. Dla obsługiwanych źródeł pomocna jest opcja Wyświetl zapytanie natywne przy danym kroku. Jej niedostępność nie zawsze oznacza jednak, że folding nie występuje.

Utrata foldingu w jednym kroku nie musi przekreślać korzyści z wcześniejszych operacji. Może natomiast sprawić, że kolejne przekształcenia będą wykonywane przez silnik Power Query. Dlatego operacje, których nie da się przekazać do źródła, warto — jeśli pozwala na to logika obliczeń — wykonywać po ograniczeniu danych.

Transformacje: mniej danych przed kosztownymi operacjami

Dobrym punktem wyjścia jest wczesne usunięcie zbędnych kolumn i odfiltrowanie niepotrzebnych wierszy. Nie chodzi jednak o mechaniczne przestawianie kroków: Power Query może optymalizować ich wykonanie, a zmiana kolejności niektórych przekształceń zmienia wynik. Najważniejsze jest ograniczenie pracy bez naruszania znaczenia danych.

• Usuwaj sortowanie, które nie służy dalszym obliczeniom. Kolejność wierszy przygotowana w Power Query nie ustala kolejności prezentacji danych na wizualizacjach, a samo sortowanie może być kosztowne.
• Kontroluj scalanie i rozwijanie tabel. Wiele dopasowań po stronie dołączanej tabeli może zwielokrotnić wiersze, zwiększając koszt przetwarzania i prowadząc do błędnych wyników.
• Uważaj na funkcje wywoływane dla każdego wiersza. Szczególnie kosztowne bywają te, które wielokrotnie odczytują pliki lub odpytują zewnętrzne usługi. Tam, gdzie to możliwe, zastąp je operacją na całym zbiorze.

Nie traktuj Table.Buffer jako uniwersalnego przyspieszacza. Buforowanie może zwiększyć zużycie pamięci i uniemożliwić dalszy folding. Ma sens wyłącznie w konkretnym scenariuszu, po potwierdzeniu korzyści pomiarem.

Przygotuj do ładowania tylko potrzebny wynik

Do modelu powinny trafiać dane potrzebne do analizy, bez technicznych kolumn pomocniczych i przypadkowych duplikatów. Przed ładowaniem sprawdź spójność wartości, błędy konwersji oraz to, czy przekształcenia zachowały oczekiwany poziom szczegółowości. Usuwanie błędów lub duplikatów bez ustalenia ich przyczyny może jedynie ukryć problem jakościowy.

Zapytania pomocnicze warto oddzielić od tabel wynikowych i wyłączyć dla nich ładowanie, jeśli nie są potrzebne w modelu. Wyłączenie ładowania nie oznacza jednak wyłączenia przetwarzania: zapytanie nadal może być wykonywane jako zależność innych zapytań. Podobnie odwołanie do wspólnego zapytania porządkuje logikę, ale nie gwarantuje jednorazowego pobrania danych ani współdzielonej pamięci podręcznej.

Jeśli te same złożone przekształcenia są powtarzane w wielu raportach, rozważ przygotowanie danych we wspólnej warstwie, na przykład w bazie lub procesie ETL. Przeniesienie operacji bliżej źródła może ograniczyć powielanie pracy, pod warunkiem że ta warstwa ma odpowiednie zasoby i jest utrzymywana.

Wizualizacje i interakcje: ograniczanie liczby elementów, filtrów, tooltipów i cross-highlighting

Strona raportu może reagować powoli nawet przy dobrze przygotowanym modelu danych. Każda wizualizacja wymaga pobrania wyników i ich wyświetlenia, a zmiana zaznaczenia może uruchomić aktualizację wielu elementów jednocześnie. Optymalizacja warstwy wizualnej polega więc nie tylko na zmniejszeniu liczby wykresów, lecz także na ograniczeniu pracy wykonywanej po każdej akcji użytkownika.

Mniej wizualizacji, ale bez utraty informacji

Nie istnieje uniwersalna, bezpieczna liczba wizualizacji na stronie. Kilka rozbudowanych macierzy może obciążać raport bardziej niż kilkanaście prostych wskaźników. Znaczenie mają typ elementu, zakres prezentowanych danych, złożoność obliczeń oraz liczba interakcji z pozostałymi obiektami.

Najlepiej projektować stronę wokół jednego zadania analitycznego. Widok zarządczy powinien pokazywać kluczowe wyniki i odchylenia, a nie równocześnie pełną listę transakcji. Szczegóły można przenieść na osobną stronę dostępną przez drillthrough, czyli przejście do widoku szczegółowego z zachowaniem kontekstu wybranego elementu. Dzięki temu użytkownik otwiera rozbudowaną analizę dopiero wtedy, gdy jej potrzebuje.

• Ogranicz rozmiar tabel i macierzy. Nie pokazuj od razu wszystkich poziomów hierarchii, wielu miar i szczegółowych identyfikatorów. Udostępnij rozwijanie danych zgodnie z potrzebą.
• Zmniejsz liczbę prezentowanych kategorii. Ranking Top N może poprawić czytelność i ograniczyć zakres renderowania, choć samo wyznaczenie rankingu nadal wymaga obliczeń.
• Usuń elementy dublujące przekaz. Wykres, tabela i kilka kart przedstawiających ten sam wynik nie zawsze dostarczają proporcjonalnie większej wartości.
• Dobieraj wizualizacje niestandardowe świadomie. Ich wydajność zależy od implementacji i ilości danych; bardziej efektowny wygląd nie powinien przesądzać o wyborze.

Filtry i fragmentatory: kontroluj liczbę aktualizacji

Filtr i fragmentator służą do zawężania danych, ale pełnią inne role w interfejsie. Filtry na poziomie raportu, strony lub wizualizacji określają zakres analizy bez zajmowania przestrzeni na płótnie. Fragmentatory zapewniają wygodną, widoczną kontrolę wyboru, lecz same również muszą wyświetlać wartości i mogą reagować na inne elementy strony.

Ogranicz fragmentatory do wyborów rzeczywiście potrzebnych podczas codziennej pracy. Pola zawierające tysiące unikalnych wartości, takie jak identyfikatory transakcji, rzadko nadają się do przeglądania w formie listy. Wyszukiwanie lub bardziej ukierunkowana ścieżka przejścia do szczegółów zwykle zapewnią wygodniejszą obsługę. Sama zmiana listy na menu rozwijane oszczędza miejsce, ale nie usuwa kosztu obsługi dużej liczby wartości.

Jeśli użytkownik ustawia kilka kryteriów przed rozpoczęciem analizy, rozważ dostępne mechanizmy zatwierdzania zmian przyciskiem „Zastosuj”, zamiast odświeżania widoku po każdym wyborze. Ma to szczególne znaczenie w raportach DirectQuery, w których kolejne interakcje mogą oznaczać dodatkowe zapytania do źródła. Nie usuwaj jednak filtrów wyłącznie po to, by zmniejszyć ich liczbę — dobrze dobrany filtr może istotnie ograniczyć zakres przetwarzanych danych.

Cross-filtering i cross-highlighting tylko tam, gdzie pomagają

Cross-filtering zawęża dane w wizualizacji docelowej do wybranego zakresu. Cross-highlighting, czyli wyróżnianie krzyżowe, pokazuje wybraną część na tle całości, jeśli dany typ wizualizacji to obsługuje. Pierwsze rozwiązanie ułatwia analizę konkretnego segmentu, drugie — ocenę jego udziału w wyniku ogółem. Oba mogą wymagać ponownych obliczeń; wyróżnianie nie jest wyłącznie zmianą koloru.

W funkcji Edytuj interakcje określ, które elementy mają reagować na wybór w danym wykresie lub fragmentatorze. Wyłącz reakcje tam, gdzie nie wspierają scenariusza analizy, na przykład w niezależnym zestawieniu referencyjnym. Rób to konsekwentnie: użytkownik musi rozumieć, dlaczego część strony odpowiada na zaznaczenie, a część pozostaje bez zmian.

Tooltip powinien uzupełniać wykres, nie zastępować całej strony

Standardowy tooltip prezentuje krótki zestaw informacji o wskazanym punkcie. Tooltip oparty na stronie raportu może zawierać wykresy, karty i dodatkowe miary, dlatego jego wyświetlenie może wiązać się z kolejnymi zapytaniami oraz renderowaniem elementów.

Umieszczaj w nim tylko dane potrzebne do szybkiej interpretacji wskazanego wyniku. Rozbudowaną tabelę lub analizę wielowymiarową lepiej udostępnić przez drillthrough. W ten sposób najechanie kursorem pozostaje lekką interakcją, a koszt bardziej szczegółowego widoku pojawia się dopiero po świadomej decyzji użytkownika.

Agregacje, incremental refresh i strategia odświeżania: kiedy i jak stosować

Raport może szybko reagować na filtry, a jednocześnie potrzebować godzin na pobranie nowych danych. Może też odświeżać się sprawnie, lecz zbyt długo wyświetlać zestawienia obejmujące całą historię sprzedaży. To dwa różne problemy. Agregacje ograniczają ilość danych przetwarzanych podczas obsługi zapytań, natomiast odświeżanie przyrostowe zmniejsza zakres danych przetwarzanych podczas kolejnych odświeżeń. Strategia odświeżania określa z kolei, kiedy i z jaką częstotliwością aktualizować model, aby zapewnić wymaganą świeżość danych bez niepotrzebnego obciążania infrastruktury.

Agregacje — szybsze podsumowania bez przeglądania całej historii

Jeżeli raport najczęściej pokazuje sprzedaż według miesiąca, kategorii produktu i regionu, obsługa takich widoków nie musi za każdym razem wymagać odczytu pojedynczych pozycji transakcji. Tabela agregacyjna może przechowywać wartości już podsumowane na potrzebnym poziomie. Jej rozmiar bywa znacznie mniejszy niż rozmiar tabeli szczegółowej, co pozwala ograniczyć pracę wykonywaną przy zapytaniach.

Szczególnie użyteczny jest model złożony, w którym agregacje działają w trybie Import, a dane szczegółowe pozostają dostępne przez DirectQuery. Zapytania zgodne z poziomem agregacji mogą być obsługiwane z pamięci, a te wymagające szczegółów trafiają do źródła. Wymaga to jednak właściwej konfiguracji mapowań agregacji i modelu — samo dodanie tabeli z podsumowaniami nie gwarantuje automatycznego wykorzystania jej przez istniejące miary.

Poziom agregacji należy dobrać do rzeczywistych analiz. Zbyt szczegółowa tabela niewiele zmniejszy wolumen danych, a zbyt ogólna nie obsłuży wielu filtrów i przekrojów. Trzeba również uwzględnić charakter obliczeń: średniej nie należy wyliczać jako prostej średniej z podsumowanych średnich, a liczby unikalnych klientów nie można bezwarunkowo sumować między okresami. Agregacje zajmują też pamięć i wymagają aktualizacji, dlatego warto tworzyć je dla często używanych zestawień.

Incremental refresh — aktualizacja tylko potrzebnego zakresu

Odświeżanie przyrostowe sprawdza się w dużych tabelach faktów zawierających datę pozwalającą podzielić dane na okresy. Można przykładowo przechowywać pięć lat historii, a podczas kolejnych odświeżeń przetwarzać ponownie tylko ostatnie czternaście dni. Power BI zarządza wtedy partycjami zgodnie z ustawioną polityką, zamiast za każdym razem odświeżać pełną historię.

Konfiguracja opiera się na parametrach RangeStart i RangeEnd, filtrze daty oraz polityce określającej okres przechowywania i zakres odświeżania. Dla wydajności kluczowe jest, aby ograniczenie zakresu danych zostało wykonane po stronie źródła, a nie dopiero po pobraniu całej tabeli. Pierwsze odświeżenie po publikacji może nadal być kosztowne, ponieważ trzeba wtedy załadować wymagany zakres historyczny.

Okno odświeżania powinno obejmować nie tylko nowe rekordy, lecz także typowy okres korekt. Jeśli dokumenty bywają poprawiane po miesiącu, aktualizacja wyłącznie ostatnich kilku dni pozostawi część zmian poza modelem. Korekty starszych okresów wymagają osobnej procedury ponownego przetworzenia odpowiednich partycji lub szerszego zakresu danych.

Strategia odświeżania — częstotliwość wynikająca z potrzeb

Harmonogram warto ustalać od końca: kiedy użytkownik potrzebuje aktualnych danych i kiedy źródło faktycznie je udostępnia? Odświeżanie modelu co godzinę nie poprawi świeżości raportu, jeśli hurtownia jest zasilana raz na dobę. Aktualizację należy uruchamiać po zakończeniu procesów źródłowych, a przy zmiennym czasie ich trwania lepiej powiązać ją z potwierdzonym zakończeniem zasilania niż wyłącznie ze stałą godziną.

Wspólny plan powinien uwzględniać zależności między tabelami szczegółowymi i agregacjami, dostępność bramy danych oraz limity właściwe dla używanej licencji i pojemności. Warto rozłożyć ciężkie operacje w czasie i ustalić sposób reagowania na nieudane odświeżenia. O jakości strategii decyduje nie liczba aktualizacji, lecz to, czy raport udostępnia spójne dane o wymaganej świeżości w akceptowalnym czasie i przy rozsądnym zużyciu zasobów.

Diagnostyka i narzędzia: Performance Analyzer, DAX Studio oraz metody pomiaru

Skuteczna optymalizacja zaczyna się od ustalenia, na co raport rzeczywiście traci czas. Długie oczekiwanie na wykres może wynikać z wykonania zapytania, renderowania wizualizacji albo oczekiwania na inne operacje. Każdy z tych przypadków wymaga innej reakcji. Dlatego przed zmianą modelu czy miary warto zapisać wynik bazowy i wskazać konkretną czynność, która działa zbyt wolno: otwarcie strony, zmianę fragmentatora lub przejście do szczegółów.

Performance Analyzer — znajdź kosztowną wizualizację

Performance Analyzer, czyli Analizator wydajności, pozwala rejestrować czas operacji związanych z poszczególnymi wizualizacjami. W Power BI Desktop uruchom nagrywanie, odśwież wizualizacje lub wykonaj wybraną interakcję, a następnie porównaj wyniki. To dobry punkt wyjścia, gdy raport reaguje z opóźnieniem, ale nie wiadomo jeszcze, który element odpowiada za problem.

Najważniejsze jest rozróżnienie czasu zapytania DAX, wyświetlania wizualizacji oraz kategorii „Inne”. Wysoki czas zapytania uzasadnia dalszą analizę obliczeń, natomiast długie renderowanie kieruje uwagę na warstwę prezentacji. Kategoria „Inne” nie wskazuje jednej konkretnej usterki — może obejmować między innymi oczekiwanie na pozostałe wizualizacje. Nie należy więc interpretować jej jako bezpośredniego dowodu na wolny model danych.

DAX Studio — sprawdź wykonanie zapytania

Gdy podejrzenie pada na zapytanie, można skopiować je z Analizatora wydajności i uruchomić w DAX Studio po połączeniu z otwartym modelem Power BI Desktop. Dzięki temu analizujesz zapytanie wygenerowane przez problematyczną wizualizację, z uwzględnieniem jej filtrów, zamiast testować miarę w oderwaniu od rzeczywistego użycia.

Funkcja Server Timings pomaga rozdzielić pracę silnika formuł (Formula Engine) i silnika magazynującego (Storage Engine), a także przyjrzeć się zapytaniom kierowanym do tego drugiego. To narzędzie do diagnozowania wykonania zapytań, nie do pomiaru renderowania wykresów. Z tego powodu czas uzyskany w DAX Studio nie musi odpowiadać czasowi całej interakcji w raporcie.

Jak mierzyć, żeby porównanie miało sens

Wiarygodny test wymaga powtarzalnych warunków. Zapisz badaną stronę, stan filtrów, zakres danych i środowisko, a następnie stosuj prostą procedurę:

• Zmierz punkt wyjścia. Wykonaj kilka prób tej samej czynności i zachowaj wyniki, zamiast opierać ocenę na pojedynczym odczycie.
• Rozdziel testy z zimną i rozgrzaną pamięcią podręczną. Pierwsze wykonanie może być wolniejsze niż kolejne; porównuj odpowiadające sobie warunki.
• Wprowadzaj jedną zmianę naraz. Powtórz test i sprawdź zarówno czas, jak i poprawność zwracanych wyników.
• Zweryfikuj efekt w docelowym środowisku. Wyniki z Desktop nie gwarantują identycznej szybkości w usłudze Power BI, gdzie znaczenie mają również obciążenie pojemności, brama i źródło danych.

Osobno oceniaj szybkość interakcji i czas odświeżania danych — to różne procesy, wymagające odrębnych pomiarów. O skuteczności zmiany świadczy nie tylko krótsze wykonanie pojedynczego zapytania, lecz przede wszystkim powtarzalna poprawa czasu wykonania zadania przez użytkownika, bez pogorszenia poprawności raportu.

Checklisty i praktyka: audyt wydajności oraz przykładowy plan działań krok po kroku

Audyt wydajności raportu Power BI powinien zakończyć się konkretną decyzją: co poprawić najpierw, jak sprawdzić efekt i kiedy uznać pracę za zakończoną. Sama lista potencjalnych usprawnień nie wystarczy. Potrzebujesz punktu odniesienia, priorytetów oraz testów, które potwierdzą, że szybszy raport nadal zwraca prawidłowe wyniki.

Na początku rozdziel trzy problemy: wolne otwieranie strony raportu, opóźnione reakcje na działania użytkownika i długie odświeżanie danych. Każdy dotyczy innego scenariusza pracy. Skrócenie odświeżania nie musi przyspieszyć filtrowania, a poprawa działania pojedynczej wizualizacji nie oznacza jeszcze, że cały raport będzie wygodniejszy w użyciu.

Checklista audytu: co ustalić przed wprowadzaniem zmian

• Zakres problemu: zapisz, które strony i czynności są wolne. Zamiast „raport się zacina” zanotuj konkretny scenariusz, np. zmianę zakresu dat na stronie podsumowania sprzedaży.
• Warunki występowania: sprawdź, czy opóźnienie pojawia się w Power BI Desktop, w usłudze Power BI, czy w obu środowiskach. Odnotuj aktywne filtry, zakres danych oraz rolę zabezpieczeń, jeśli stosujesz RLS.
• Punkt odniesienia: zmierz czas wykonania wybranych scenariuszy przed zmianami. Przeprowadź kilka powtórzeń, oddzielając pierwsze uruchomienie od kolejnych, które mogą korzystać z pamięci podręcznej.
• Znaczenie biznesowe: ustal, ilu użytkowników dotyczy problem i jak często wykonują daną czynność. Codziennie używana strona zwykle zasługuje na wyższy priorytet niż sporadycznie otwierany widok pomocniczy.
• Kryteria odbioru: uzgodnij oczekiwany czas reakcji, dopuszczalne okno odświeżania i wymaganą aktualność danych. Nie przyjmuj jednego uniwersalnego progu dla wszystkich raportów.
• Bezpieczeństwo zmian: zachowaj wersję wyjściową oraz zestaw wyników kontrolnych. Uwzględnij sumy, wybrane przekroje danych i dostęp użytkowników do informacji.

Przykładowy plan działań krok po kroku

W Cognity łączymy teorię z praktyką – dlatego zagadnienia optymalizacji raportów rozwijamy także w formie ćwiczeń na szkoleniach. Poniższy plan pomoże Ci uporządkować pracę nad własnym raportem: od wyboru scenariuszy testowych po weryfikację efektów w środowisku docelowym.

1. Wybierz reprezentatywne scenariusze. Zacznij na przykład od otwarcia najczęściej używanej strony, zmiany głównego filtra i przejścia do szczegółów. Odświeżanie danych potraktuj jako osobny test. Taki zakres pozwala rozpocząć pracę bez sprawdzania każdej możliwej kombinacji interakcji.
2. Przypisz problem do obszaru wymagającego analizy. Na podstawie pomiarów wskaż, czy dalszej kontroli wymaga model, obliczenia, przygotowanie danych, warstwa wizualna czy środowisko wykonania. Zapisz hipotezę, zamiast od razu przebudowywać raport.
3. Ustal kolejność poprawek. Oceń spodziewaną korzyść, nakład pracy i ryzyko każdej zmiany. Najpierw testuj usprawnienia istotne dla użytkowników, łatwe do zweryfikowania i możliwe do wycofania.
4. Wprowadzaj zmiany pojedynczo. Po każdej powtórz te same scenariusze w możliwie porównywalnych warunkach. Zanotuj wynik oraz warunki testu. Jeśli poprawa nie jest powtarzalna, nie traktuj jej jako potwierdzonego sukcesu.
5. Sprawdź poprawność i skutki uboczne. Porównaj wyniki z wersją wyjściową. Zweryfikuj, czy usprawnienie jednej strony nie pogorszyło działania innych, nie zmieniło logiki obliczeń ani nie ograniczyło potrzebnych funkcji.
6. Potwierdź efekt po publikacji. Przetestuj raport w środowisku docelowym, z uwzględnieniem rzeczywistych uprawnień i typowego obciążenia. Wyznacz osobę odpowiedzialną za ponowną kontrolę po istotnym wzroście danych lub rozbudowie raportu.

Rezultatem audytu powinien być krótki rejestr: problem, pomiar początkowy, wprowadzona zmiana, wynik testu i decyzja o wdrożeniu. Taki zapis pozwala odróżnić rzeczywistą poprawę od chwilowego przyspieszenia i ułatwia utrzymanie wydajności przy kolejnych modyfikacjach raportu.

Jak wykorzystać ChatGPT i Copilot w codziennej pracy firmy budowlanej? 06 października 2026

Power Query – 10 najczęstszych problemów z danymi i sposoby ich rozwiązania 04 października 2026