Agregacje w Power BI nie są używane - jak sprawdzić i naprawić mapowanie

Power BI - Wydajność modelu i raportu

Agregacje w Power BI nie są używane - jak sprawdzić i naprawić mapowanie

W skrócie

Tabela podsumowań jest gotowa, mapowanie w oknie Zarządzaj agregacjami zapisane, a wizualizacje w modelu złożonym ładują się tak samo długo jak przed zmianą. Agregacje w Power BI nie dają przy tym żadnego komunikatu, więc z samego raportu nie dowiesz się, czy agregat w ogóle jest używany. Na agregacie sprzedaży Nordvelli z kursu sprawdzamy to w Analizatorze wydajności i zbieramy warunki, które muszą być spełnione.

Jak to wygląda w praktyce

Agregacje działają cicho. Gdy zadziałają, raport jest szybszy, a gdy nie, Power BI niczego nie sygnalizuje. Śladem w Power BI Desktop jest Analizator wydajności: wizualizacja obsłużona z agregatu nie ma wiersza Zapytanie bezpośrednie, a ta, która poszła do bazy, ma go zawsze. W teście trzech wizualizacji na modelu Nordvelli z agregatem w Imporcie wykres sprzedaży według miast trwał 70 ms i tabela kategorii 94 ms, obie bez zapytania do bazy, a tabela pojedynczych transakcji 355 ms z wierszem Zapytanie bezpośrednie.

Drugi objaw pojawia się już w oknie mapowania. Gdy agregat ma relacje do wymiarów, a w mapowaniu dodaliśmy kolumny grupowania, okno pokazało komunikat „Nie można agregować kolumny szczegółów z jedną lub większą liczbą kolumn Grupuj według za pomocą silnych relacji.”, a przycisk Zastosuj wszystko pozostał nieaktywny.

Dlaczego tak się dzieje

Agregat obsługuje swoje ziarno i wszystko powyżej, ale nic poniżej. Agregat Nordvelli ma 3 180 wierszy na poziomie rok, miesiąc, sklep i kategoria, wobec 108 675 wierszy sprzedaży. Tabela z SprzedazID schodzi poniżej ziarna, a fragmentator po formie płatności filtruje kolumnę, której w agregacie nie ma, więc w obu przypadkach zapytanie trafia do bazy. Miara z DISTINCTCOUNT też nie skorzysta z sum: liczby pracowników sprzedających w kolejnych 53 miesiącach sumują się do 10 592, a w całym okresie sprzedawało 200 osób.

Dokumentacja Microsoft zaleca budować agregat jako tabelę importowaną w Power Query, a agregacje oparte na relacjach wymagają relacji zwykłych, a nie ograniczonych. Agregat w Imporcie z wymiarem w DirectQuery daje relację ograniczoną, dlatego wymiary ustawia się na Podwójne. Dokumentacja wymienia też inne warunki: tabela szczegółowa musi być w trybie DirectQuery, kolumna szczegółowa musi mieć ten sam typ co kolumna agregatu (poza zliczaniem), USERELATIONSHIP na relacji nieaktywnej nie trafi w agregat, a reguła RLS musi filtrować zarówno agregat, jak i tabelę szczegółową. Agregaty w Imporcie ze źródłem z włączonym logowaniem jednokrotnym (SSO) Power BI pomija. Model w pełni importowany o rozsądnym rozmiarze, jak Nordvella ze 108 675 wierszami, agregatów nie potrzebuje, bo przy takiej liczbie wierszy silnik VertiPaq odpowiada z pamięci w ułamku sekundy.

Zobacz też: Szkolenie Analiza Power BI - DAX + M

Co zrobić krok po kroku

1. Zrób test na trzech wizualizacjach, tak jak w lekcji o modelach złożonych: wykres z DimSklepy[Miasto] i sumą WartoscNetto, tabela z DimKategorie[Kategoria] i sumą Ilosc oraz tabela z SprzedazID (w menu pola Nie sumuj). W Analizatorze wydajności kliknij Rozpocznij nagrywanie i Odśwież wizualizacje. Pierwsze dwie powinny być bez wiersza Zapytanie bezpośrednie, trzecia z nim. Jak czytać pomiar, opisujemy w lekcji o optymalizacji wydajności modelu.
2. Sprawdź relacje i tryby. Agregat musi mieć relacje do wymiarów, po których filtrujesz raport (w Nordvelli SklepID do DimSklepy i KategoriaID do DimKategorie), a te wymiary muszą być w trybie Podwójne. Tryb zobaczysz w widoku modelu: tabela, panel Właściwości, sekcja Zaawansowane, Tryb przechowywania. Wymiar bez relacji z agregatem sprawia, że silnik nie użyje agregatu w żadnej wizualizacji z tym wymiarem.
3. Sprawdź mapowanie: prawy przycisk na tabeli agregatu, Zarządzaj agregacjami. W Nordvelli WartoscNetto, KosztWlasny i Ilosc mają podsumowanie Sum z odpowiednimi kolumnami FaktSprzedaz, a LiczbaTransakcji ma CountTableRows z pustą kolumną szczegółową. Nazwy podsumowań zostają po angielsku mimo polskiego interfejsu. Typ każdej zmapowanej kolumny musi być taki sam jak typ kolumny szczegółowej.
4. Usuń sprzeczne wpisy. Gdy okno pokazuje komunikat o kolumnach Grupuj według i silnych relacjach, usuń mapowanie grupowania dla kolumn obsłużonych relacjami (w Nordvelli SklepID i KategoriaID) oraz dla Rok i Miesiac. Dokumentacja Microsoft dodaje, że przy agregatach opartych na relacjach wpisy grupowania nie są potrzebne, poza DISTINCTCOUNT, dla którego liczona kolumna musi być wpisem grupowania. Agregat po miesiącach wymagałby wymiaru, którego klucz ma ziarno miesiąca.
5. Dobierz ziarno do wizualizacji i policz wiersze przyszłego agregatu zapytaniem DAX, zanim go zbudujesz. W Nordvelli rok, miesiąc, sklep i kategoria to 3 180 wierszy, po dodaniu formy płatności 14 466, a dzień, sklep i kategoria 53 674. Agregat projektuje się pod wizualizacje otwierane najczęściej, a nie pod najbardziej szczegółowe.

   EVALUATE
   ROW(
       "Ziarno agregatu",
       COUNTROWS(
           SUMMARIZE(
               FaktSprzedaz,
               DimKalendarz[Rok], DimKalendarz[Miesiac],
               FaktSprzedaz[SklepID], DimProdukty[KategoriaID]
           )
       ),
       "Wiersze faktów", COUNTROWS(FaktSprzedaz)
   )

6. Gdy test nadal pokazuje zapytanie do bazy, sprawdź warunki z dokumentacji: tabela szczegółowa w DirectQuery, a nie w Imporcie, miara z USERELATIONSHIP zamiast TREATAS, RLS tylko na tabeli szczegółowej, źródło z logowaniem jednokrotnym. Dokładny ślad trafienia w agregat daje według dokumentacji SQL Profiler ze zdarzeniem Aggregate Table Rewrite Query. Miary z DISTINCTCOUNT omawiamy w poście o liczbie unikatowych klientów.

Jak sprawdzić, że problem zniknął

Porównaj czasy przed podpięciem agregatu i po nim w tych samych warunkach: Wyczyść, dwa odświeżenia, drugie z drugim. W Nordvelli wykres sprzedaży według miast trwał przed podpięciem 342 ms, w tym zapytanie DAX 185 ms i zapytanie bezpośrednie 120 ms, a po podpięciu 144 ms i bez wiersza zapytania bezpośredniego. W teście trzech wizualizacji ten sam wykres miał 70 ms: czasy z różnych serii pomiarów się różnią, więc porównujesz tylko odświeżenia z jednej serii. Zapytanie DAX spadło do 30 ms, bo agregat czyta 3 180 wierszy z pamięci zamiast 108 675 z bazy.

Po każdej zmianie modelu, na przykład nowym wymiarze albo fragmentatorze, powtórz test trzech wizualizacji. Wybór w nowym fragmentatorze po kolumnie spoza agregatu wystarczy, żeby filtrowane nim wizualizacje wróciły do bazy. Inne przyczyny wolnego DirectQuery opisujemy w poście o wolnym DirectQuery.

Źródła i sposób sprawdzenia

• Microsoft Learn: User-defined aggregations (Manage aggregations, Validations, Regular vs. limited relationships) (źródło)
• Microsoft Learn: Use Performance Analyzer to examine report performance (źródło)
• Sprawdzone zapytaniami DAX na modelu Nordvelli: liczba wierszy agregatu przy trzech ziarnach i suma miesięcznych liczb pracowników wobec DISTINCTCOUNT.

Zachowanie programu sprawdziliśmy w Power BI Desktop 2.157 (wydanie z sierpnia 2026 r.) z polskim interfejsem, a przykłady na modelu sieci Nordvella z bezpłatnego kursu Power BI. Microsoft wydaje nową wersję Power BI Desktop co miesiąc, więc nazwy przycisków i limity usługi mogą się zmieniać. Aktualne wartości podaje dokumentacja Microsoft Learn.

Wróć do listy: 131 najczęstszych pytań i problemów związanych z Power BI