Przejście z Import do DirectQuery w Power BI bez utraty miar DAX: plan, który działa

Co najczęściej znika lub psuje się w miarach DAX po przejściu na DirectQuery?

Najczęściej nie „znikają” same miary, tylko przestają działać ich założenia obliczeniowe. Po przejściu z Import do DirectQuery problem pojawia się tam, gdzie miara opierała się na logice wygodnej dla silnika in-memory, ale trudnej albo niemożliwej do skutecznego przetłumaczenia na zapytanie wysyłane do źródła. W praktyce najczęściej psują się miary wykorzystujące złożone iteracje, zależności od tabel pośrednich tworzonych w locie, rozbudowane filtrowanie kontekstu oraz konstrukcje, które wymagają przeliczeń w wielu krokach na dużej liczbie wierszy.

Szczególnie podatne są miary oparte na funkcjach iteracyjnych, takich jak SUMX, AVERAGEX czy FILTER, jeśli pracują na dużych zbiorach i wewnętrznie budują skomplikowany kontekst. W Import takie obliczenia często są akceptowalne wydajnościowo, a w DirectQuery potrafią generować bardzo ciężkie zapytania SQL albo zwracać inne wyniki niż oczekiwane, jeśli źródło nie odwzorowuje logiki modelu tak samo jak silnik VertiPaq. Często problemem są też miary korzystające pośrednio z kolumn lub tabel obliczanych, które w trybie DirectQuery mają ograniczenia albo nie zachowują się identycznie.

Drugą grupą są miary zależne od funkcji czasu i relacji modelu, zwłaszcza gdy wcześniej działały dzięki pełnej tabeli kalendarza, odpowiednim relacjom i kompletności danych po imporcie. Jeśli po zmianie trybu źródło nie dostarcza tych samych danych, relacje są niejednoznaczne albo filtracja odbywa się inaczej, to miary typu YTD, MTD, porównania okres do okresu czy kumulacje bardzo często dają błędne wyniki albo znacząco zwalniają.

Często „psują się” także miary, które bazują na założeniu stabilnego kontekstu filtrowania, na przykład z użyciem CALCULATE, ALL, ALLEXCEPT czy REMOVEFILTERS. W DirectQuery sama składnia może pozostać poprawna, ale wynik końcowy bywa inny, jeśli źródło danych, relacje, kierunki filtrowania albo agregacja nie pozwalają odtworzyć tej samej semantyki co w modelu importowanym.

Najważniejsze jest więc to, że przy DirectQuery ryzyko dotyczy przede wszystkim miar złożonych, kontekstowych i iteracyjnych, a nie prostych agregacji. Miary typu SUM, COUNT, MIN, MAX zwykle przechodzą bez większych problemów, natomiast wszystko, co wymaga wielu etapów przeliczeń, wirtualnych tabel i zaawansowanej manipulacji filtrem, najczęściej wymaga przeglądu i często uproszczenia lub przebudowy.

Czy da się przejść na DirectQuery bez przepisywania miar i kiedy to realne?

Tak, ale tylko w określonych warunkach. Sama zmiana trybu przechowywania danych z Import na DirectQuery nie oznacza automatycznie, że wszystkie miary DAX trzeba pisać od nowa. Jeśli zachowujesz ten sam model logiczny — te same tabele, relacje, nazwy kolumn i podobną granularność danych — wiele miar nadal będzie działać bez zmian, ponieważ DAX odwołuje się do struktury modelu, a nie bezpośrednio do tego, czy dane są importowane, czy wykonywane w źródle.

To jest realne przede wszystkim wtedy, gdy migracja polega na podmianie sposobu dostępu do tych samych danych, a nie na przebudowie modelu. Jeżeli miary opierają się na standardowych agregacjach, filtrach kontekstu, relacjach typu gwiazda i typowych funkcjach takich jak SUM, CALCULATE, DISTINCTCOUNT czy prostych wariantach time intelligence, szansa na zachowanie ich bez zmian jest duża. Warunkiem jest też to, by źródło danych i warstwa SQL były w stanie obsłużyć zapytania generowane przez Power BI z akceptowalną wydajnością.

Przepisywanie miar staje się potrzebne nie dlatego, że DirectQuery „nie obsługuje DAX”, ale dlatego, że zmieniają się ograniczenia wykonania. Problem pojawia się zwykle wtedy, gdy miary korzystają z kosztownych iteracji, złożonych tabel pośrednich, logiki opartej na dużej liczbie wirtualnych tabel albo gdy wcześniej model Import maskował słabości struktury danych. W DirectQuery takie obliczenia mogą działać wolno, zwracać inne wyniki przy niejednoznacznym kontekście albo wymagać przeniesienia części logiki do źródła danych, na przykład do widoków lub kolumn wyliczanych po stronie bazy.

W praktyce przejście bez przepisywania miar jest realne wtedy, gdy zmieniasz tryb techniczny, ale nie zmieniasz semantyki modelu. Jeśli jednak migracja wymaga denormalizacji, usunięcia tabel pomocniczych, zmiany relacji, ograniczenia funkcji DAX albo przebudowy logiki na potrzeby wydajności, część miar trzeba będzie dostosować. Najbezpieczniejsze założenie jest takie: nie każda migracja Import do DirectQuery wymusza przepisanie DAX, ale im bardziej obecny model zależy od złożonych obliczeń wykonywanych w pamięci, tym mniej realne jest przejście bez zmian w miarach.

Jak działa model mieszany (Composite) i jak użyć go do bezpiecznej migracji?

Model mieszany w Power BI pozwala łączyć w jednym modelu tabele działające w trybie Import z tabelami działającymi w trybie DirectQuery. Dzięki temu nie trzeba przenosić całego rozwiązania jednorazowo. Część danych może nadal być przechowywana w pamięci modelu, a część może być pobierana na bieżąco ze źródła. To właśnie czyni Composite praktycznym narzędziem do migracji: umożliwia stopniową zmianę architektury bez konieczności przebudowy wszystkiego od zera.

W kontekście przejścia z Import do DirectQuery najważniejsze jest to, że model mieszany pozwala zachować istniejący model semantyczny, w tym znaczną część miar DAX, relacji i logiki raportowej, podczas gdy tylko wybrane tabele są przenoszone do DirectQuery. Typowy bezpieczny scenariusz polega na pozostawieniu wymiarów i stabilnych, małych tabel w trybie Import, a stopniowym przełączaniu największych tabel faktów na DirectQuery. Dzięki temu można testować wpływ zmiany na wydajność, poprawność wyników i zgodność miar bez pełnego ryzyka produkcyjnego.

Kluczowe jest zrozumienie, że połączenia między tabelami Import i DirectQuery wpływają na sposób wykonywania zapytań. Gdy wizualizacja używa danych z obu światów, Power BI musi połączyć wyniki częściowo z pamięci modelu, a częściowo ze źródła danych. To może zmienić wydajność i w niektórych przypadkach ograniczyć zachowanie pewnych konstrukcji DAX lub logiki relacji. Dlatego migracja w modelu mieszanym powinna zaczynać się od tych tabel, które da się odseparować od najbardziej złożonych obliczeń, a następnie wymaga porównania wyników raportów przed i po zmianie.

Bezpieczne użycie Composite polega więc nie na „włączeniu DirectQuery”, tylko na kontrolowanym etapie pośrednim. Najpierw wybiera się tabelę lub obszar modelu o największym koszcie odświeżania albo rozmiarze, następnie przenosi do DirectQuery tylko ten fragment, zachowując resztę w Import. Po tym kroku należy sprawdzić, czy relacje działają zgodnie z oczekiwaniem, czy miary zwracają te same wyniki oraz czy czas odpowiedzi raportu pozostaje akceptowalny. Jeśli wynik jest poprawny, można przenosić kolejne elementy. Jeśli nie, model mieszany pozwala zatrzymać się na etapie pośrednim bez utraty dotychczasowego rozwiązania.

Największą wartością Composite w migracji jest więc redukcja ryzyka: umożliwia przejście etapami, utrzymanie działających raportów i weryfikację realnych skutków technicznych przed pełnym przełączeniem modelu na DirectQuery. W praktyce jest to najbezpieczniejszy sposób migracji wtedy, gdy priorytetem jest zachowanie istniejących miar DAX i ciągłości działania raportów.

Jakie zmiany w relacjach i modelu danych są konieczne przy DirectQuery?

Przy przejściu na DirectQuery najważniejsze jest uproszczenie i ujednoznacznienie modelu, tak aby zapytania mogły być bezpiecznie i wydajnie tłumaczone na SQL po stronie źródła. W praktyce oznacza to, że model powinien być jak najbliższy klasycznemu układowi gwiazdy: tabele faktów połączone z tabelami wymiarów relacjami 1:* , z jednoznacznym kierunkiem filtrowania z wymiaru do faktu.

Najczęściej konieczne są trzy typy zmian. Po pierwsze, trzeba ograniczyć relacje wiele-do-wielu i relacje o niejednoznacznej ścieżce filtrowania, bo w DirectQuery częściej prowadzą do błędnych agregacji, złożonych zapytań i spadku wydajności. Po drugie, warto unikać dwukierunkowego filtrowania, chyba że jest absolutnie potrzebne i dobrze przetestowane. Po trzecie, klucze używane w relacjach muszą być stabilne, jednoznaczne i zgodne typami danych po obu stronach, ponieważ każda nieścisłość odbija się bezpośrednio w zapytaniach wysyłanych do źródła.

W modelu danych zwykle trzeba też przenieść część logiki z warstwy modelu Power BI do źródła. Dotyczy to zwłaszcza obliczeń, które wcześniej były realizowane przez tabele kalkulowane, kolumny kalkulowane lub skomplikowane transformacje po imporcie. W DirectQuery bezpieczniej jest mieć w źródle gotowe wymiary, klucze techniczne, tabele mapujące i kolumny potrzebne do filtrowania, grupowania oraz sortowania. Model powinien opierać się na danych już przygotowanych do analizy, a nie na intensywnym modelowaniu po stronie Power BI.

• Relacje: preferowane są relacje 1:* zamiast wiele-do-wielu; należy usuwać niejednoznaczne ścieżki filtracji.
• Kierunek filtrowania: domyślnie jednokierunkowy z wymiarów do faktów; dwukierunkowy tylko w uzasadnionych przypadkach.
• Struktura modelu: układ gwiazdy zamiast rozbudowanych zależności między wymiarami i tabelami pośrednimi.
• Przygotowanie danych: więcej logiki w źródle, mniej obliczeń zależnych od modelu importowego.

Jeżeli model działał wcześniej tylko dlatego, że dane były w pamięci i Power BI „radził sobie” z bardziej złożonymi zależnościami, to po przejściu na DirectQuery takie konstrukcje często wymagają przebudowy. Celem nie jest zmiana samych miar DAX, lecz takie uporządkowanie relacji i tabel, aby te same miary miały jednoznaczny kontekst filtrowania i mogły być poprawnie obliczane w modelu opartym na zapytaniach do źródła.

Jak ograniczyć liczbę zapytań generowanych przez miary DAX w DirectQuery?

W DirectQuery każda bardziej złożona interakcja z raportem może uruchamiać wiele zapytań do źródła, ponieważ miary DAX są tłumaczone na zapytania wykonywane poza modelem importowanym. Żeby tę liczbę ograniczyć, trzeba przede wszystkim upraszczać logikę miar i unikać wzorców, które wymuszają wielokrotne przeliczanie tego samego wyniku w różnych kontekstach filtrowania.

Najważniejsze jest ograniczenie iteracji po dużych tabelach. Miary oparte na konstrukcjach takich jak SUMX, FILTER czy zagnieżdżone warunki często generują cięższe tłumaczenia do zapytań źródłowych niż proste agregacje typu SUM, MIN, MAX czy COUNT. Jeśli wynik da się policzyć jako agregację kolumny lub prostą logikę na poziomie źródła, zwykle będzie to mniej kosztowne niż iterowanie w DAX nad dużym zbiorem danych.

Warto też eliminować powtarzanie tej samej logiki w wielu miarach. Jeżeli kilka wizualizacji odwołuje się do podobnych obliczeń, każda z nich może wywoływać osobne zapytania. Dlatego dobrze jest budować miary bazowe, używać zmiennych VAR do przechowywania pośrednich wyników w ramach jednej miary i unikać wielokrotnego liczenia tych samych warunków. To nie zawsze zmniejszy liczbę zapytań do zera, ale często ogranicza redundancję po stronie silnika.

Duże znaczenie ma również sposób używania filtrów. Funkcje zmieniające kontekst, takie jak rozbudowane CALCULATE z wieloma warunkami, relacje niejednoznaczne albo częste operacje na wysokokardynalnych kolumnach mogą prowadzić do większej liczby zapytań lub bardziej złożonych zapytań SQL. Im bardziej przewidywalny model filtrowania i prostsze warunki w miarze, tym łatwiej silnik może wygenerować jedno efektywne zapytanie zamiast kilku pomocniczych.

Praktycznie oznacza to także ograniczanie liczby miar użytych jednocześnie w jednej wizualizacji oraz rezygnację z niepotrzebnie szczegółowych tabel i macierzy. Nawet poprawnie napisana miara będzie uruchamiana wielokrotnie, jeśli raport wymaga liczenia jej dla wielu kombinacji wierszy, kolumn i filtrów. Czasem mniejsza liczba pól w wizualizacji daje większy efekt niż sama optymalizacja DAX.

Jeżeli dana logika jest stabilna biznesowo, warto rozważyć przeniesienie części obliczeń do źródła danych, na przykład do widoku lub warstwy przygotowującej dane. W DirectQuery to często najskuteczniejszy sposób ograniczenia liczby zapytań generowanych pośrednio przez DAX, ponieważ model odwołuje się wtedy do prostszych, gotowych pól zamiast za każdym razem składać złożone obliczenia w locie.

Krótko: mniej zapytań w DirectQuery uzyskuje się przez prostsze miary, mniej iteracji, mniej powtarzanej logiki, ostrożne użycie funkcji zmieniających kontekst oraz ograniczenie liczby obliczeń wykonywanych jednocześnie przez wizualizacje.

Kiedy warto użyć agregacji w Power BI, żeby odzyskać szybkość importu?

Agregacji warto użyć wtedy, gdy po przejściu z trybu Import do DirectQuery największy spadek wydajności dotyczy zapytań opartych na danych zagregowanych, a nie na szczegółowych rekordach. Chodzi głównie o raporty, w których użytkownicy najczęściej analizują sumy, średnie, liczności lub wartości na poziomie dnia, miesiąca, produktu, klienta czy regionu, a zejście do poziomu transakcji jest rzadsze. W takim układzie można zostawić szczegóły w DirectQuery, a równolegle utrzymywać mniejszą tabelę agregatów w Import, dzięki czemu typowe zapytania wracają do szybkości zbliżonej do modelu importowanego.

To rozwiązanie ma sens wtedy, gdy problemem jest czas odpowiedzi przy dużych wolumenach danych i częstych odpytywaniach źródła, a wzorzec użycia raportu jest przewidywalny. Jeśli większość wizualizacji odwołuje się do wysokiego poziomu szczegółowości albo użytkownicy stale pracują na poziomie pojedynczych zdarzeń, agregacje pomogą niewiele, bo zapytania i tak będą trafiały do warstwy DirectQuery. Kluczowe jest więc to, czy da się wyraźnie oddzielić część analityki „sumarycznej” od analityki „drill-through do detalu”.

W praktyce agregacje są szczególnie uzasadnione, gdy model po migracji zachował poprawność miar DAX, ale utracił responsywność na standardowych stronach raportu. Jeśli te strony korzystają z prostych lub średnio złożonych miar, które można obsłużyć na poziomie wcześniej przygotowanych sumowań, Power BI może skierować zapytanie do zaimportowanej tabeli agregatów zamiast do źródła DirectQuery. To właśnie jest moment, w którym odzyskuje się część zalet Import bez rezygnacji z dostępu do aktualnych danych szczegółowych.

Nie warto natomiast traktować agregacji jako uniwersalnego lekarstwa na każdy problem wydajności. Jeżeli opóźnienia wynikają głównie ze słabego źródła, nieoptymalnych relacji, zbyt złożonych miar albo konieczności liczenia logiki wyłącznie na poziomie rekordu, sama warstwa agregatów nie rozwiąże problemu. Jej największa wartość pojawia się wtedy, gdy znaczna część ruchu raportowego może być przechwycona przez mniejsze, zaimportowane zestawy danych, a tylko część zapytań musi schodzić do pełnego detalu w DirectQuery.

Jak przetestować zgodność wyników miar między Import a DirectQuery przed publikacją?

Najbezpieczniej porównać oba tryby na tej samej logice raportowej, zanim model zostanie opublikowany. W praktyce oznacza to przygotowanie dwóch wersji modelu opartych na tym samym schemacie, relacjach i definicjach miar DAX: jednej w trybie Import, drugiej w DirectQuery. Następnie trzeba zestawić wyniki tych samych miar dla identycznych filtrów, poziomów agregacji i zakresów dat. Test nie może ograniczać się do pojedynczej karty KPI, bo wiele rozbieżności ujawnia się dopiero w podziale na wymiary, na przykład po kliencie, produkcie, miesiącu lub regionie.

Kluczowe jest sprawdzenie, czy różnice nie wynikają z samego źródła danych, lecz z zachowania modelu w DirectQuery. Dlatego przed porównaniem należy upewnić się, że oba warianty odwołują się do tego samego stanu danych, mają identyczne typy danych, relacje, kierunki filtrowania, tabele kalendarza oraz tę samą logikę miar. Jeśli choć jeden z tych elementów się różni, test przestaje potwierdzać zgodność trybów i zaczyna porównywać dwa różne modele.

Najlepsza metoda to zbudowanie strony testowej z tabelą lub macierzą, w której obok siebie pokazujesz wynik z modelu Import i wynik z modelu DirectQuery dla tych samych przekrojów. Do tego warto dodać prostą miarę różnicy, na przykład odejmując jeden wynik od drugiego, oraz miarę sygnalizującą odchylenie większe niż dopuszczalna tolerancja. Tolerancja ma znaczenie głównie dla miar opartych na liczbach zmiennoprzecinkowych, kursach, procentach lub złożonych obliczeniach, gdzie minimalne różnice zaokrągleń mogą być technicznie akceptowalne.

Testy powinny obejmować nie tylko „typowe” przypadki, ale też sytuacje graniczne: puste wartości, brak dopasowania w relacjach, wiele filtrów jednocześnie, wysoką i niską ziarnistość agregacji, zakresy dat częściowo puste oraz miary używające funkcji wrażliwych na kontekst filtrowania. Szczególną uwagę trzeba zwrócić na miary zależne od iteracji, rankingów, inteligencji czasowej i logiki warunkowej, bo to właśnie one najczęściej pokazują różnice po przejściu na DirectQuery.

Jeśli pojawią się rozbieżności, trzeba ustalić, czy wynikają z semantyki DAX, tłumaczenia zapytań do źródła, czy z ograniczeń samego DirectQuery. Pomaga analiza zapytań generowanych do źródła oraz sprawdzenie, czy wynik problematycznej miary da się odtworzyć na prostszym zestawie danych. Celem testu nie jest tylko znalezienie różnicy, ale potwierdzenie, że każda kluczowa miara daje ten sam wynik biznesowy w obu trybach albo że znana różnica została świadomie zaakceptowana i udokumentowana przed publikacją.

Incremental refresh z API w Power BI: jak to ustawić, gdy dane są niestabilne 24 lipca 2026

Row-Level Security w Power BI bez spadku wydajności: błędy, które kosztują najwięcej 22 lipca 2026