Composite models: 7 wzorców łączenia DirectQuery i Import bez utraty kontroli nad wydajnością

1. Czym są composite models w Power BI: Import vs DirectQuery i pojęcia kluczowe

Composite models (modele złożone) w Power BI to podejście, w którym w jednym modelu semantycznym łączysz różne tryby przechowywania danych i/lub różne źródła. Najczęściej oznacza to współistnienie tabel w trybie Import i DirectQuery, tak aby raport korzystał jednocześnie z szybkiej analityki na danych w pamięci oraz z dostępu do świeżych danych w systemie źródłowym.

Kluczowa idea composite modelu nie polega na „włączeniu obu trybów naraz”, lecz na świadomym podziale odpowiedzialności: które zapytania mają być realizowane błyskawicznie na danych załadowanych do modelu, a które mogą (lub muszą) być wykonywane na żywo w źródle.

Import vs DirectQuery — podstawowe różnice

• Import: dane są ładowane do modelu (in-memory), a wizualizacje najczęściej odpytywane są lokalnie. Typowe korzyści to wysoka interaktywność i większa swoboda modelowania. Ograniczeniem jest to, że dane odświeżają się zgodnie z harmonogramem i mechaniką odświeżania, więc nie są „zawsze aktualne”.
• DirectQuery: dane pozostają w systemie źródłowym, a Power BI generuje zapytania do źródła podczas interakcji użytkownika. Korzyścią jest dostęp do aktualnych danych (w granicach możliwości źródła i infrastruktury). Kosztem bywa większa wrażliwość na wydajność źródła, opóźnienia sieci, współbieżność oraz ograniczenia w zakresie transformacji i niektórych funkcji modelowania.

W praktyce wybór trybu to kompromis między czasem odpowiedzi, świeżością danych, kosztem infrastruktury i złożonością modelu. Composite models pozwalają te kompromisy „mieszać” zamiast wybierać jedną skrajność.

Po co composite models — typowe zastosowania

• Połączenie szybkości z aktualnością: agregacje lub często używane przekroje w Import, a wybrane analizy „na żywo” w DirectQuery.
• Stopniowa migracja: przejście z jednego podejścia na drugie bez przebudowy całego raportowania naraz.
• Rozdzielenie profili użycia: większość użytkowników potrzebuje szybkich odpowiedzi na typowe pytania, a tylko część wymaga dostępu do szczegółów lub danych bieżących.
• Łączenie domen danych: sytuacje, w których pewne obszary danych są dostępne tylko jako DirectQuery (np. z powodów polityk lub wolumenów), a inne wygodniej trzymać w Import.

Pojęcia kluczowe, które porządkują temat

Storage mode (tryb przechowywania) to właściwość tabeli określająca, czy jest ona ładowana do modelu (Import), odpytywana na żywo (DirectQuery), czy zachowuje się elastycznie w zależności od kontekstu (tryby hybrydowe, jeśli są dostępne w danym scenariuszu). W composite models kluczowe jest, że to tabela (a nie cały raport) ma swój tryb, co pozwala mieszać zachowania w obrębie jednego modelu.

Model semantyczny (semantic model) to warstwa, w której definiujesz tabele, relacje, miary i logikę analityczną. Composite model to nadal jeden model semantyczny, ale z różnymi strategiami dostępu do danych.

Relacje i propagacja filtrów nabierają szczególnego znaczenia, ponieważ filtr może przechodzić między tabelami o różnych trybach. To, czy filtr „pociągnie” za sobą zapytanie do źródła DirectQuery, zależy od układu relacji, kierunku filtrowania i tego, które tabele biorą udział w zapytaniu.

Query folding (składanie zapytań) dotyczy tego, czy transformacje danych są tłumaczone na język źródła. W DirectQuery ma to bezpośredni wpływ na to, jakie zapytania trafią do bazy i czy będą one wydajne. W Import wpływa na czas odświeżania i obciążenie źródła podczas ładowania.

Granularność danych (szczegółowość) jest praktycznym kryterium podziału: dane szczegółowe są najczęściej najcięższe kosztowo do trzymania i odświeżania, a jednocześnie rzadziej potrzebne w codziennych przekrojach. To naturalnie prowadzi do miksowania strategii przechowywania.

Wydajność end-to-end w composite models to suma kilku składowych: czasu generacji zapytania, wykonania w źródle, transferu wyników, oraz pracy silnika modelu. Dlatego „szybki raport” to nie tylko szybki model, ale także przewidywalne zachowanie zapytań w zależności od interakcji użytkownika.

Najważniejsza zasada: intencjonalność zamiast przypadkowego miksu

Composite models dają dużą elastyczność, ale ta elastyczność działa na korzyść tylko wtedy, gdy świadomie określisz, które pytania biznesowe mają być obsługiwane z pamięci (Import), które mają iść do źródła (DirectQuery) oraz jak ma zachowywać się filtrowanie między tymi obszarami. W przeciwnym razie model może stać się nieprzewidywalny: raz bardzo szybki, a raz nagle zależny od ciężkich zapytań do źródła.

Wzorzec 1: Agregacje w Import + szczegóły w DirectQuery (drill-through) — zastosowania, ryzyka i testy wydajności

Ten wzorzec łączy szybkość Import dla większości interakcji użytkownika (widoki zagregowane) z aktualnością i szczegółowością DirectQuery dla „zejścia w dół” do transakcji (drill-through, szczegóły rekordu, audyt). W praktyce oznacza to, że typowe wykresy i KPI liczą się na lokalnym, skompresowanym modelu w pamięci, a dopiero na żądanie użytkownika wykonywane jest zapytanie do źródła po wiersze szczegółowe. Podczas szkoleń Cognity ten temat wraca regularnie – dlatego zdecydowaliśmy się go omówić również tutaj.

Kiedy ten wzorzec ma największy sens

• Raporty operacyjne i analityczne jednocześnie: większość odbiorców potrzebuje trendów i podsumowań, a tylko część użytkowników okazjonalnie weryfikuje pojedyncze dokumenty lub transakcje.
• Bardzo duże tabele faktów: importowanie całej szczegółowości byłoby kosztowne pamięciowo, czasowo lub organizacyjnie, ale agregaty (np. po dniu/produkcie/oddziale) mieszczą się komfortowo.
• Wymóg świeżych danych tylko na poziomie szczegółu: podsumowania mogą być odświeżane cyklicznie, natomiast przy drill-through użytkownik ma trafić w możliwie aktualne rekordy w systemie źródłowym.
• Ograniczenie obciążenia źródła: zamiast każdej interakcji wykonywać w DirectQuery, do źródła trafiają tylko zapytania „detaliczne” z natury rzadsze.

Jak to działa na poziomie zachowania raportu

Użytkownik widzi stronę z podsumowaniami, które odpowiadają na większość pytań biznesowych. Gdy kliknie element (np. segment, słupek, wiersz w macierzy) i przejdzie do szczegółów, model powinien przełączyć się na pobranie danych z warstwy DirectQuery, ograniczając zakres filtrami wynikającymi z kontekstu (np. konkretna data, klient, produkt). Kluczową ideą jest to, aby zapytań do DirectQuery było mało, a każde z nich było maksymalnie selektywne.

Najważniejsze ryzyka i typowe pułapki

• Niezgodność ziarnistości i definicji miar: agregaty muszą odpowiadać temu, co później ma się zgadzać na szczegółach. Jeśli agregujesz po innych kluczach niż wynika to z logiki raportu, użytkownik zobaczy rozjazdy między podsumowaniem a detalem.
• „Fałszywe poczucie szybkości”: strona agregatów działa błyskawicznie, ale drill-through może nagle stać się bardzo wolny, jeśli filtr nie ogranicza wystarczająco danych albo źródło ma słabe indeksy.
• Zbyt szerokie zapytania detaliczne: niepozorne interakcje (np. brak jednoznacznego wyboru, wiele zaznaczeń, brak wymaganego filtra) mogą skutkować pobieraniem ogromnej liczby wierszy z bazy.
• Niejednorodna aktualność danych: agregaty importowane są „z wczoraj”, a detal jest „na teraz”. Jeśli komunikacja w raporcie jest nieczytelna, użytkownik może uznać to za błąd lub niespójność danych.
• Ograniczenia źródła w trybie DirectQuery: przy dużej liczbie równoległych użytkowników nawet rzadkie drill-through potrafią skumulować obciążenie, zwłaszcza gdy zapytania są kosztowne.
• Ryzyko niekontrolowanej propagacji filtrów: jeśli model pozwala filtrom „przeciekać” w nieprzewidywalny sposób, zapytania do DirectQuery mogą być bardziej złożone niż oczekiwano (więcej warunków, joinów, wyrażeń).

Jak utrzymać kontrolę nad doświadczeniem użytkownika

• Projektuj podsumowania tak, by odpowiadały na 80–90% pytań: im rzadziej użytkownik potrzebuje detalu, tym mniej ryzykujesz wąskie gardła w DirectQuery.
• Wymuszaj selektywność drill-through: strony szczegółowe powinny być zaprojektowane tak, aby naturalnie zawężały kontekst (np. do jednego dnia, jednego dokumentu, jednego klienta), a nie zachęcały do przeglądania „wszystkiego”.
• Ograniczaj liczbę wizualizacji na stronie detalu: każda dodatkowa wizualizacja może generować osobne zapytania do źródła, zwłaszcza jeśli pokazuje inne przekroje.
• Dbaj o spójne definicje: to, co użytkownik rozumie jako „sprzedaż” czy „liczbę transakcji”, musi mieć tę samą interpretację w agregacie i w detalu.

Testy wydajności: co sprawdzić, zanim wdrożysz

• Scenariusze kliknięć, nie tylko odświeżenie strony: testuj typową ścieżkę użytkownika od podsumowania do drill-through, w tym wielokrotne przejścia i zmianę selekcji.
• Najgorszy przypadek selekcji: sprawdź, co się stanie, gdy użytkownik przejdzie do detalu bez zawężenia (lub z minimalnym zawężeniem). To często ujawnia ryzyko zapytań „zbyt szerokich”.
• Równoległość: zasymuluj kilku/kilkunastu użytkowników wykonujących drill-through w tym samym czasie. W tym wzorcu problemy zwykle wychodzą dopiero przy współbieżności.
• Stabilność czasów odpowiedzi: monitoruj nie tylko średnią, ale też skoki opóźnień. Pojedyncze „piki” często wynikają z kosztownych planów zapytań lub blokad po stronie źródła.
• Porównanie zgodności agregat vs detal: weryfikuj, czy suma detalu odpowiada temu, co pokazuje agregat dla tego samego kontekstu. Wydajność bez zgodności jest pozorna.

W dobrze zaprojektowanym wariancie tego wzorca użytkownik ma wrażenie, że raport jest „importowy” (szybki i responsywny), a jednocześnie ma dostęp do transakcji wtedy, gdy ich potrzebuje. Kluczem jest świadome ograniczanie zakresu zapytań DirectQuery oraz upewnienie się, że agregaty rzeczywiście pokrywają większość interakcji.

Wzorzec 2: Dual tables (wymiary w trybie Dual) — kiedy używać, pułapki i metody weryfikacji zapytań

Dual to tryb przechowywania tabeli w modelu composite, w którym Power BI może traktować tę samą tabelę jak Import lub jak DirectQuery — wybór jest podejmowany dynamicznie na podstawie zapytania. W praktyce najczęściej dotyczy to wymiarów (np. data, produkt, klient), które łączą fakty w Import i/lub DirectQuery.

Po co istnieje tryb Dual i co realnie zmienia?

Dual ma rozwiązać typowy konflikt: chcemy szybko filtrować i agregować (korzystając z pamięci Import), ale jednocześnie nie chcemy zrywać zgodności z częścią modelu opartą o DirectQuery. Dzięki Dual silnik może:

• obsłużyć zapytanie lokalnie (jak Import), gdy wszystko da się policzyć na danych w pamięci,
• albo „przełączyć” tabelę na tryb DQ, gdy zapytanie wymusza dotknięcie źródła DQ (np. przez miarę z faktu w DQ, bezpieczeństwo, warunki, których nie ma w Import).

Kiedy używać Dual (najczęstsze scenariusze)

• Wymiary współdzielone między faktami w Import i factami w DirectQuery, gdy zależy Ci na minimalizacji liczby zapytań DQ przy typowych raportach agregacyjnych.
• Wysoka interaktywność raportu (slicery, cross-filtering), gdzie wymiary są intensywnie używane do filtrowania, a część wizualizacji ma pozostać szybka.
• Model „agregacje + szczegóły”, w którym agregacje liczą się z Import, a dopiero część wizualizacji schodzi do szczegółów w DQ — Dual na wymiarach pomaga utrzymać spójny kontekst filtrów.
• Minimalizacja kosztu joinów przy zapytaniach, które w przeciwnym razie wymagałyby częstych połączeń do źródła DQ tylko po to, aby zastosować filtry z wymiaru.

Dual vs Import vs DirectQuery (w pigułce)

Pułapki i ryzyka, o których łatwo zapomnieć

• „Niespodziewane” przełączenie na DQ: dodanie miary lub kolumny z tabeli DQ do wizualizacji może spowodować, że filtr z wymiaru Dual zostanie rozstrzygnięty w backendzie, generując dodatkowe zapytania.
• Więcej zapytań niż oczekujesz: przy niektórych układach wizualizacji silnik potrafi wysłać kilka zapytań do źródła (np. osobno dla wartości, osobno dla sum kontrolnych, osobno dla legendy), a Dual nie zawsze je „absorbuje”.
• Nieoptymalne relacje i kierunki filtrowania: błędna kardynalność, relacje typu wiele-do-wielu lub dwukierunkowe filtrowanie mogą powodować drogie propagacje kontekstu i wymuszać DQ.
• RLS i zgodność filtrów: jeśli logika bezpieczeństwa (RLS) lub warunki filtrów nie są możliwe do rozstrzygnięcia lokalnie, Dual częściej będzie korzystał z DQ. To może zmienić profil wydajności po wdrożeniu, gdy dojdą role.
• Rozjazdy semantyki między Import a DQ: różnice w typach danych, kolacjach, mapowaniach wartości (np. spacje, wielkość liter) mogą prowadzić do trudnych do diagnozy różnic w wynikach, jeśli część zapytania liczy się lokalnie, a część w źródle.
• Wielkość wymiaru ma znaczenie: Dual na „wymiarze”, który jest w praktyce dużą tabelą transakcyjną, może zwiększyć pamięciożerność i pogorszyć wydajność (bo Import tej tabeli nie jest już „mały”).

Jak weryfikować, czy Dual faktycznie pomaga (i czy nie generuje DQ „po cichu”)

W tym wzorcu kluczowe jest ustalenie, kiedy zapytania idą do backendu oraz co je wyzwala. Najpewniejsze metody kontroli:

• Performance Analyzer w Power BI Desktop: sprawdzaj czas „DAX query” oraz „Visual display”, a przede wszystkim kopiuj zapytania DAX i porównuj zachowanie po zmianie trybu wymiaru (Import vs Dual).
• Query Diagnostics / logi źródła: w SQL/Synapse patrz na realnie wykonywane zapytania (czas, plan, liczba wywołań). Jeśli po dodaniu slicera wzrasta liczba zapytań, Dual prawdopodobnie przełącza się na DQ.
• DAX Studio (gdy to możliwe): weryfikuj, czy pojawiają się zdarzenia wskazujące na odpytywanie źródła oraz porównuj czasy Storage Engine vs Formula Engine, aby zobaczyć, czy obciążenie przenosi się na backend.
• Testy A/B na tej samej stronie raportu: twórz dwie wersje strony (lub pliku): (1) wymiar Import, (2) wymiar Dual — i porównuj liczbę zapytań do źródła oraz czasy renderowania przy tych samych interakcjach (klik w slicer, cross-highlighting, drill).

Minimalny zestaw praktyk, które zwykle stabilizują Dual

• Utrzymuj w Dual tylko prawdziwe wymiary (relatywnie małe, stabilne), które są wspólne dla faktów.
• Dbaj o jednoznaczne klucze i spójne typy danych między faktami i wymiarami (Import i DQ), aby uniknąć kosztownych konwersji i niezgodności.
• Ostrożnie z dwukierunkowym filtrowaniem i relacjami M:M — jeśli są konieczne, traktuj je jako potencjalny wyzwalacz DQ i testuj każdą kluczową wizualizację.
• Waliduj zachowanie po dodaniu RLS oraz po publikacji do usługi (profil zapytań może się różnić od Desktop).

Dual tables są jednym z najprostszych sposobów, by poprawić interaktywność modeli mieszanych, ale wymagają świadomego testowania: to, że tabela jest ustawiona na Dual, nie oznacza, że raport „z definicji” przestanie odpytywać źródło DirectQuery.

Wzorzec 3: Hybrid tables (Incremental Refresh + Real-time) — scenariusze near real-time, ryzyka i testy obciążeniowe

Hybrid tables w Power BI to podejście, w którym jedna tabela faktów jest logicznie „jedna”, ale fizycznie działa w dwóch trybach naraz: historyczna część danych jest przechowywana w trybie Import (z odświeżaniem przyrostowym), a najświeższy „ogon” danych jest pobierany w DirectQuery w momencie interakcji użytkownika. Celem jest near real-time bez rezygnowania z szybkości zapytań po danych historycznych.

Jak to działa (intuicyjnie)

• History: partycje danych starszych niż określone okno czasu (np. > 1 dzień) są zaimportowane do modelu i obsługiwane przez silnik VertiPaq.
• Real-time: najnowsze dane (np. ostatnie 1–2 dni lub ostatnie X godzin) trafiają jako część obsługiwana przez DirectQuery, czyli z opóźnieniem zależnym od źródła, sieci i obciążenia.
• Użytkownik widzi jedną tabelę w modelu i jedną miarę DAX, ale wykonanie zapytań może łączyć wyniki z Import i DirectQuery.

Kiedy to ma sens (typowe scenariusze near real-time)

• Monitorowanie operacyjne: dashboardy, gdzie liczy się „co dzieje się teraz”, ale analizy trendów i porównania okresów bazują na dużej historii.
• Raporty SLA/alerty na świeżych danych: np. statusy zamówień/incydentów, gdzie ostatnie godziny muszą być „na żywo”, a starsze dane nie zmieniają się często.
• Duże wolumeny + okno gorących danych: gdy pełny DirectQuery byłby zbyt wolny/kosztowny, a pełny Import nie spełnia wymagań świeżości.

Podstawowe różnice względem „czystego” Import i „czystego” DirectQuery

Najważniejsze elementy konfiguracji (na poziomie koncepcji)

• Incremental Refresh: definiuje okno przechowywania historii i okno przyrostu (np. przechowuj 5 lat, odświeżaj ostatnie 7 dni).
• Real-time: definiuje, jaka część najnowszych danych ma być pobierana w DirectQuery (okno „gorące”).
• Klucz czasu: hybryda opiera się na kolumnie daty/czasu, która musi stabilnie rozdzielać partycje (to podstawa przewidywalności).

Ryzyka i pułapki (co najczęściej psuje „kontrolę nad wydajnością”)

• Źle dobrane okno real-time: zbyt szerokie okno „ogona” powoduje, że rośnie udział DirectQuery w większości wizualizacji, a raport zaczyna zachowywać się jak pełny DQ. Zespół trenerski Cognity zauważa, że właśnie ten aspekt sprawia uczestnikom najwięcej trudności.
• Niejednorodne filtry czasu: jeśli użytkownicy często analizują okres obejmujący zarówno historię, jak i „ogon”, Power BI musi złożyć wynik z dwóch światów; to potrafi ujawnić wąskie gardła w źródle.
• Skoki obciążenia: w godzinach szczytu (dużo użytkowników) zapytania do „ogona” mnożą się i mogą wywołać throttling/limity po stronie źródła.
• Spójność i opóźnienia: gdy dane w źródle są dopisywane z opóźnieniem albo aktualizowane wstecz, może dojść do chwilowych rozjazdów między częścią Import a DQ (np. korekty w danych z ostatnich dni).
• Niejednoznaczna semantyka miar: miary liczące „ostatnie X” muszą być odporne na fakt, że część okresu jest w Import, a część w DQ; inaczej użytkownicy zobaczą niespójne wyniki przy tych samych filtrach.
• Trudniejsza diagnostyka: jedna wizualizacja może generować zarówno pracę VertiPaq, jak i zapytania do źródła; bez dyscypliny testowej łatwo błędnie przypisać przyczynę spowolnień.

Minimalny zestaw testów obciążeniowych i wydajnościowych

W hybrydzie kluczowe jest sprawdzenie zachowania w trzech strefach: tylko Import, tylko Real-time (DQ) oraz zakres mieszany. Poniżej zestaw testów, które dają szybki obraz ryzyka.

• Test 1: „Cold start” raportu
  • Mierz czas pierwszego otwarcia strony z wizualami obejmującymi „ogon”.
  • Cel: ocenić narzut inicjalny, cache oraz wrażliwość na opóźnienia sieci/źródła.
• Test 2: Okres historyczny (Import-only)
  • Ustaw filtr czasu tak, aby wykluczyć okno real-time (np. 30–60 dni wstecz).
  • Cel: potwierdzić, że dla historii raport osiąga oczekiwaną szybkość i nie generuje niepotrzebnych odwołań do źródła.
• Test 3: Okno real-time (DQ-only)
  • Filtruj wyłącznie w obrębie „ogona” (np. ostatnie 2 godziny/1 dzień).
  • Cel: ocenić maksymalny koszt zapytań do źródła oraz stabilność przy szybkich interakcjach (slicery, cross-filter).
• Test 4: Zakres mieszany
  • Wybierz zakres obejmujący granicę partycji (np. ostatnie 14 dni przy real-time = 2 dni).
  • Cel: zobaczyć, czy mieszanie Import + DQ nie powoduje skokowego wzrostu czasu odpowiedzi.
• Test 5: Test współbieżności
  • Symuluj równoległe odpytywanie raportu (np. 10/50/100 użytkowników) na wizualach dotykających „ogona”.
  • Cel: wykryć limity źródła (CPU, pamięć, concurrency), a także ewentualne time-outy.
• Test 6: Test „backfill”/korekt
  • Sprawdź, co się dzieje, gdy dane są korygowane w ostatnich dniach (w obszarze granicznym między Import a DQ).
  • Cel: ocenić ryzyko rozjazdów i wymagania co do okna odświeżania przyrostowego.

Praktyczna heurystyka doboru okna real-time

• Dobieraj okno real-time tak, aby obejmowało tylko ten fragment, gdzie faktycznie wymagana jest świeżość (np. „dzisiaj” albo „ostatnie 2 godziny”), a nie „dla wygody” ostatnie tygodnie.
• Jeśli większość kluczowych stron raportu filtruje się na „ostatnie 30 dni”, a okno real-time to 30 dni, hybryda prawie na pewno będzie zachowywać się jak DirectQuery.
• Okno real-time powinno wynikać z celów biznesowych (SLA świeżości) oraz z możliwości źródła (czas odpowiedzi i concurrency), a nie z samej wielkości danych.

Hybrid tables są szczególnie skuteczne, gdy potrafisz wyraźnie oddzielić „gorące” zapytania operacyjne od „zimnej” analityki historycznej, a następnie potwierdzić w testach, że zakres mieszany nie wprowadza niekontrolowanego długu wydajnościowego.

Wzorzec 4: Model mieszany faktów (część faktów Import, część DirectQuery) — partycjonowanie danych, ryzyka i testowanie

Model mieszany faktów to wariant composite model, w którym tabele faktów są rozdzielone według „temperatury” danych: część trafia do Import (najczęściej historyczne, stabilne wolumeny), a część pozostaje w DirectQuery (najczęściej bieżące lub wymagające natychmiastowej aktualności). Dzięki temu można utrzymać szybkie raportowanie dla większości zapytań, a jednocześnie nie rezygnować z aktualności tam, gdzie jest potrzebna.

Na czym polega „mieszanie faktów”

W praktyce spotkasz najczęściej dwa układy:

• Ten sam proces biznesowy w dwóch tabelach faktów: np. Sales_Import (historia) + Sales_DQ (ostatnie dni/godziny). Obie tabele mają zbliżoną ziarnistość i wspólne wymiary.
• Różne fakty o różnej dynamice: np. zdarzenia transakcyjne w Import, a „stan na teraz” (inventory, statusy, kolejki) w DirectQuery.

Typowe zastosowania

• Raporty operacyjno-analityczne: większość analiz na danych historycznych działa w Import, a elementy typu „dzisiaj/teraz” dociągane są w DQ.
• Duże wolumeny + potrzeba świeżości: historia jest zbyt duża lub zbyt kosztowna do częstego odświeżania, ale bieżący wycinek musi być aktualny.
• Stopniowe przejście pomiędzy podejściami (np. migracja hurtowni, zmiana strategii odświeżania) bez przebudowy całego modelu.

Partycjonowanie danych: jak wyznaczyć granicę Import vs DirectQuery

Kluczowe jest ustalenie jednoznacznej reguły podziału, która minimalizuje nakładanie się danych i pozwala przewidywać wydajność. Najczęstsze kryteria:

• Czas (rolling window): np. DQ = ostatnie 7/30 dni, Import = starsze.
• Status: np. DQ = zamówienia „otwarte”, Import = „zamknięte”.
• Źródło/region/kanal: stosowane rzadziej, gdy różne segmenty mają inne SLA lub inne źródła danych.

Dobra reguła podziału spełnia trzy warunki: stabilność (nie zmienia się co chwilę), rozłączność (brak duplikatów) oraz łatwość filtrowania (można ją efektywnie zastosować w źródle dla DQ i w Power Query dla Import).

Jak spiąć to w modelu: warianty semantyczne

W raportach chcesz zwykle zachowania „jak jedna tabela faktów”. Są dwa podejścia koncepcyjne:

• Warstwa semantyczna po stronie modelu: miary agregują oba fakty (Import + DQ) i zwracają jednolity wynik.
• Warstwa semantyczna po stronie źródła: jeśli to możliwe, logika łączenia jest „wypchnięta” do widoku/warstwy pośredniej, a Power BI widzi to jako spójny kontrakt danych (z zachowaniem różnych trybów przechowywania w zależności od tabel).

W obu przypadkach krytyczne jest, aby wymiary (np. Data, Produkt, Klient) były zgodne i jednoznacznie łączyły się z obiema tabelami faktów.

Porównanie: model mieszany faktów vs „wszystko Import” i „wszystko DQ”

Najczęstsze ryzyka i jak je ograniczać

• Podwójne liczenie (overlap): jeśli zakres Import i DQ się nakłada, wyniki miar będą zawyżone. Ograniczaj to przez rozłączną regułę partycjonowania oraz testy kontrolne (np. suma z obu tabel vs suma z referencyjnego źródła).
• Luki w danych (gaps): przy nieostrej granicy (np. opóźnione zasilanie źródła) możesz „zgubić” okres pomiędzy Import i DQ. Stosuj bufor bezpieczeństwa (np. Import do T-2, DQ od T-1) albo jawne reguły weryfikacyjne.
• Nieprzewidywalne przełączanie ścieżki zapytań: wizualizacje mogą nieświadomie opierać się na DQ, jeśli filtr/relacje wymuszają sięgnięcie po bieżący fakt. Pomaga konsekwentny projekt miar i testowanie scenariuszy filtracji.
• Niespójne klucze i ziarnistość: różnice w typach danych, formacie kluczy, strefach czasowych lub poziomie szczegółowości prowadzą do rozjazdów. Ujednolicaj klucze (format, typ), a daty rozstrzygaj w jednej konwencji.
• Wąskie gardło w źródle DQ: nawet jeśli 90% zapytań idzie w Import, pozostałe 10% potrafi przeciążyć bazę. Ograniczaj zapytania DQ przez redukcję kolumn, stosowanie indeksów w źródle i kontrolę funkcji/wyrażeń utrudniających składanie zapytań.

Minimalny schemat miary łączącej oba fakty

W najprostszym ujęciu miary sumują wartość z obu faktów. To przykład ideowy (w praktyce dochodzą warunki graniczne i ochrona przed overlap/gaps):

Total Sales :=
VAR SalesImport = SUM ( Sales_Import[Amount] )
VAR SalesDQ     = SUM ( Sales_DQ[Amount] )
RETURN
SalesImport + SalesDQ

Testowanie: co sprawdzić, żeby nie stracić kontroli nad wydajnością

• Testy poprawności: zgodność sum i liczników dla kluczowych przekrojów (dzień/tydzień, region, produkt) oraz test „granicy” (okresy tuż przed i tuż po cutoff).
• Testy wydajności interakcji: oddzielnie dla widoków historycznych (powinny trafiać w Import) i widoków „dzisiaj/teraz” (kontrolowany udział DQ). Mierz czasy odpowiedzi przy typowych filtrach użytkowników.
• Testy obciążenia źródła DQ: ile zapytań generuje raport w scenariuszu wieloużytkownikowym (np. odświeżenie strony, cross-filtering). Weryfikuj, czy baza utrzymuje wymagane czasy przy równoległości.
• Testy regresji po zmianach: każda zmiana relacji, miar lub kolumn w faktach może niejawnie zwiększyć udział DQ w pozornie „historycznych” raportach.

Ten wzorzec daje dużą elastyczność, ale wymaga dyscypliny: jasnej granicy partycjonowania, spójnych wymiarów oraz stałego monitorowania, kiedy raporty uruchamiają zapytania DirectQuery i jak to wpływa na źródło.

Wzorzec 5: Kaskadowanie filtrów i propagacja kontekstu (Import ↔ DirectQuery) — kontrola zachowania, ryzyka i diagnostyka

W composite models (mieszanie Import i DirectQuery) filtry oraz kontekst zapytania potrafią „przechodzić” przez relacje między tabelami w różnych trybach magazynowania. To, co w czystym modelu Import bywa intuicyjne, w układzie Import ↔ DirectQuery może skutkować: niespodziewanym wykonywaniem zapytań do źródła, skokami czasu odpowiedzi, a czasem innymi wynikami niż oczekiwane (np. przez różnice w sposobie interpretacji filtrów po stronie silnika DAX vs silnika źródłowego).

Na czym polega wzorzec

Wzorzec polega na świadomym projektowaniu tego, jak filtry kaskadują w modelu:

• z warstwy raportu (slicery, filtry strony, filtry wizualizacji),
• przez relacje (kierunek i kardynalność),
• do miar (DAX) i ostatecznie do źródeł DirectQuery.

Celem jest utrzymanie kontroli nad tym, kiedy i dlaczego Power BI generuje zapytania do źródła DQ oraz jak duży zakres danych obejmują.

Typowe zastosowania

• Ograniczanie obciążenia DirectQuery przez wymuszanie selektywności filtrów (np. filtr daty, regionu, kanału) zanim nastąpi zejście do szczegółów.
• Stabilizacja wydajności w raportach, gdzie część modelu jest Import (np. słowniki, kalendarz, parametry), a fakty operacyjne są w DQ.
• Kontrola „ścieżek” filtracji w modelach z wieloma relacjami, aby uniknąć niezamierzonych propagacji do tabel DQ (np. niechciane filtrowanie faktu DQ przez dodatkowy wymiar Import).
• Projektowanie zachowania interakcji wizualizacji (cross-filtering) tak, aby wybór w jednej wizualizacji nie powodował kosztownych zapytań DQ w innych.

Pojęcia, które musisz rozróżniać

• Kontekst filtra (filter context): filtry wynikające z selekcji w raporcie, relacji i funkcji DAX.
• Propagacja filtra przez relacje: kierunek filtrowania (jedno- lub dwukierunkowy) i jego wpływ na tabele w innych trybach magazynowania.
• Rozwiązywanie zapytań: część obliczeń może zostać wykonana lokalnie (silnik analityczny), a część wypchnięta do źródła (folding / query pushdown) w DQ.
• Selektywność: jak bardzo filtr zawęża dane przed wykonaniem zapytania do DQ; kluczowy czynnik czasu odpowiedzi.

Jak kontrolować zachowanie (bez wchodzenia w specyficzne techniki z innych wzorców)

Kontrola kaskadowania filtrów opiera się głównie na decyzjach modelowych i zasadach projektowych:

• Projekt relacji: ustawiaj kierunek filtrowania tak, aby filtr „szedł” do tabel DQ tylko wtedy, gdy to ma sens biznesowo i wydajnościowo.
• Unikanie niepotrzebnej dwukierunkowości: relacje dwukierunkowe zwiększają ryzyko nieprzewidzianej propagacji i trudnych do wyjaśnienia zapytań do źródła.
• Projekt selektorów: kluczowe slicery (np. data, organizacja) powinny filtrować w sposób przewidywalny i możliwie wcześnie ograniczać zakres danych, zanim zapytanie trafi do DQ.
• Izolowanie ścieżek filtracji: gdy wymiary Import „dotykają” faktów DQ wieloma drogami, rośnie ryzyko złożonych zapytań oraz niejednoznacznego kontekstu.
• Świadome użycie miar: miary, które generują szerokie konteksty (np. iteracje po dużych tabelach) mogą wymuszać częste/ciężkie odpytywanie DQ.

Ryzyka charakterystyczne dla composite (Import ↔ DQ)

Diagnostyka: jak ustalić, czy filtr „wypycha” zapytania do DirectQuery

Wzorzec wymaga rutynowej diagnostyki na etapie budowy raportu i przy regresjach wydajności:

• Performance Analyzer w Power BI Desktop: sprawdzaj czas „DAX query” oraz „Visual display” i porównuj zachowanie przy różnych selekcjach filtrów.
• Podgląd zapytań DirectQuery: identyfikuj, które wizualizacje generują zapytania do źródła i jak zmienia się ich kształt przy zmianie filtrów.
• Testy selekcji skrajnych: wybór „All” vs wąski zakres (np. jeden miesiąc) — jeśli różnice są drastyczne, problemem zwykle jest selektywność i propagacja.
• Walidacja ścieżek relacji: sprawdź, czy filtr nie przechodzi „bokiem” przez dodatkowe relacje (często efekt uboczny relacji dwukierunkowych lub nieoczywistych połączeń wymiarów).

Pomocniczo można użyć prostych miar kontrolnych do obserwacji kontekstu (np. liczby zaznaczonych wartości), aby szybciej powiązać wybór w raporcie z zakresem danych, który finalnie trafia do tabel DQ.

-- Przykład miary diagnostycznej (pomocniczej)
Selected Customers = COUNTROWS(VALUES('Customer'[CustomerKey]))

Kiedy ten wzorzec jest szczególnie ważny

• Gdy DirectQuery obejmuje duże fakty, a model ma wiele wymiarów w Import.
• Gdy użytkownicy intensywnie korzystają z cross-highlighting i klikają elementy wizualizacji, „przepinając” kontekst.
• Gdy raport ma działać stabilnie dla różnych profili użytkowników (różne filtry, różna granulacja analiz), a źródło DQ ma ograniczoną przepustowość.

Wzorzec 6: Multi-source composite (wiele źródeł: SQL/Synapse/Dataverse/SSAS) — architektura, ograniczenia i testy end-to-end

Wzorzec multi-source composite polega na tym, że jeden semantyczny model Power BI łączy dane z kilku niezależnych źródeł, a każde z nich może pracować w innym trybie (Import, DirectQuery, a także połączenia „live” do modeli semantycznych). Celem nie jest „zmieszanie wszystkiego ze wszystkim”, tylko świadome rozdzielenie odpowiedzialności: które dane mają być ultraszybkie i stabilne (np. Import), które muszą być świeże (DirectQuery), a które już są dobrze ustandaryzowane i zarządzane poza Power BI (np. SSAS/Model semantyczny).

Typowy zestaw źródeł w tym wzorcu obejmuje:

• SQL Server / Azure SQL — relacyjne dane operacyjne i hurtowniane, często w DirectQuery dla świeżości lub Import dla przewidywalnej wydajności.
• Synapse — duże wolumeny i analityka na warstwie hurtowni/lakehouse; często jako główne źródło faktów lub agregacji.
• Dataverse — dane aplikacyjne (CRM/Power Platform), przydatne jako wymiary i kontekst biznesowy, ale z ograniczeniami wydajności i kształtu zapytań.
• SSAS / modele semantyczne — „golden source” miar i logiki biznesowej, który chcesz ponownie wykorzystać zamiast duplikować obliczenia.

Architektura: jak to spiąć, żeby nie stracić kontroli

Najbezpieczniejsze podejście to zbudowanie modelu wokół spójnego rdzenia (zwykle wspólnych wymiarów i kluczy) i dołączanie kolejnych źródeł tylko tam, gdzie istnieje jasna granica odpowiedzialności. W praktyce architektura jest „warstwowa”:

• Warstwa semantyczna: jeden model z jednolitymi definicjami relacji, kierunków filtrowania i miar, tak aby raportujący widzieli spójny obraz.
• Warstwa źródeł: każde źródło ma własne możliwości i ograniczenia — model powinien to odzwierciedlać, zamiast próbować je maskować.
• Warstwa integracji: integracja odbywa się głównie przez zgodne klucze, ujednolicone typy danych i stabilne ziarno tabel (grain). Jeśli ziarno jest niezgodne, pojawiają się kosztowne zapytania, duplikacje i niejednoznaczne relacje.

W tym wzorcu kluczowa jest decyzja, co jest systemem referencyjnym dla wymiarów i definicji (np. czy „Klient” pochodzi z Dataverse, czy z hurtowni w Synapse). Brak jednej „prawdy” skutkuje rozjechanymi filtrami, konfliktami kluczy i sytuacją, w której ta sama miara daje inne wyniki w zależności od ścieżki filtrowania.

Najczęstsze zastosowania (kiedy to ma sens)

• Raport 360°: łączenie danych operacyjnych (Dataverse) z hurtownią/analityką (Synapse/SQL) bez budowania pełnego ETL pod każdy temat.
• Stopniowa modernizacja: część organizacji jest na starszym SSAS lub istniejącym modelu semantycznym, a nowe obszary danych rozwijasz w Power BI, bez natychmiastowej migracji całości.
• Różne SLA świeżości: metryki strategiczne w Import (szybko), a wybrane dane „tu i teraz” w DirectQuery (świeżo), w obrębie jednego raportu.
• Federacja domen: poszczególne domeny danych mają własne systemy i właścicieli, ale użytkownik końcowy oczekuje jednego, spójnego widoku.

Ograniczenia i ryzyka specyficzne dla wielu źródeł

Multi-source composite jest atrakcyjny, ale trudny do „utrzymania w ryzach”. Najważniejsze ograniczenia i typowe pułapki to:

• Niejednorodność wydajności: najsłabsze źródło staje się wąskim gardłem. Raport może być szybki na danych z Import, ale jeden wizual z filtrem przechodzącym do wolnego DirectQuery „psuje” całość.
• Rozjechane znaczenia danych: te same atrybuty (np. status, etap, segment) mogą mieć różne słowniki wartości w różnych systemach. Model wtedy „technicznie działa”, ale biznesowo myli.
• Konflikty kluczy i ziaren: różne definicje klucza głównego, różne poziomy agregacji i brak jednoznacznych relacji prowadzą do nieoczekiwanej multiplikacji wierszy i błędnych sum.
• Ograniczenia pushdown: nie każde przekształcenie i nie każdy filtr da się skutecznie „zepchnąć” do każdego źródła. Efektem bywa pobieranie większej ilości danych niż oczekujesz albo złożone zapytania po stronie źródła.
• Bezpieczeństwo i zgodność: różne źródła mają różne mechanizmy autoryzacji, poziomy RLS i zasady dostępu. Złożenie ich w jeden model wymaga spójnej strategii, inaczej łatwo o luki lub nadmierne ograniczenia.
• Operacyjność: więcej źródeł to więcej zależności: awarie, limity API, okna serwisowe, zmiany schematu. Model staje się bardziej wrażliwy na zmiany poza zespołem BI.

Testy end-to-end: co trzeba sprawdzić, zanim dopuścisz to do produkcji

W multi-source composite testy muszą obejmować nie tylko „czy działa”, ale czy zachowuje się przewidywalnie w warunkach realnego użycia. Minimalny zestaw testów end-to-end powinien obejmować:

• Testy ścieżek krytycznych: zidentyfikuj 5–10 najważniejszych interakcji w raporcie (filtry, drill, przełączanie stron) i mierz opóźnienia osobno dla każdej ścieżki. Chodzi o wychwycenie momentów, w których kontekst filtrów przełącza zapytanie na wolniejsze źródło.
• Testy mieszanych filtrów: sprawdź scenariusze, gdzie filtr pochodzi z danych z jednego systemu, a mierzone wartości z innego. To najczęstsze miejsce problemów z propagacją kontekstu i zaskakującymi zapytaniami.
• Testy obciążeniowe: weryfikuj zachowanie przy równoległych użytkownikach, bo źródła (szczególnie API i systemy operacyjne) mogą znacząco degradować pod równoległym ruchem. Interesuje Cię nie tylko średni czas, ale też „ogon” opóźnień.
• Testy zgodności wyników: porównaj kluczowe miary i liczby z systemami źródłowymi oraz między ścieżkami nawigacji w raporcie. W modelach wieloźródłowych częstym problemem są subtelne rozbieżności wynikające z różnych definicji i ziaren.
• Testy odporności: symuluj częściową niedostępność jednego źródła (np. Dataverse limituje zapytania) i sprawdź, jak raport się zachowuje: czy degraduje się łagodnie, czy staje się bezużyteczny.
• Testy bezpieczeństwa: potwierdź, że polityki dostępu działają spójnie dla wszystkich źródeł i że użytkownik nie uzyskuje „bocznego” dostępu przez połączone tabele lub miary.

W praktyce sukces tego wzorca zależy od tego, czy potrafisz utrzymać jasne granice domen, spójność wymiarów oraz kontrolę nad zapytaniami generowanymi do każdego źródła. Jeśli te trzy elementy są dopięte, multi-source composite pozwala łączyć najlepsze cechy różnych platform bez zamiany raportu w nieprzewidywalny „federacyjny eksperyment”.

Wzorzec 7: Rozdzielenie warstwy semantycznej (thin report + shared dataset) z elementami DirectQuery — zarządzanie, ryzyka i testy w środowisku

Ten wzorzec polega na rozdzieleniu odpowiedzialności: współdzielony dataset (model semantyczny) jest utrzymywany centralnie, a użytkownicy i zespoły tworzą wiele thin reports (cienkich raportów) podpinanych do tego samego datasetu. W modelu semantycznym mogą współistnieć tabele w trybie Import i DirectQuery, dzięki czemu organizacja zyskuje jednocześnie reużywalność metryk oraz kontrolę nad tym, które obszary działają „na żywo”, a które są cache’owane.

W praktyce oznacza to, że logika biznesowa (miary, relacje, perspektywy, opis pól, zasady bezpieczeństwa) jest definiowana raz, a różne raporty różnicują się warstwą wizualną i zakresem odbiorców. Gdy w datasetcie występuje DirectQuery, thin reports dziedziczą jego konsekwencje: część interakcji będzie generowała zapytania do źródła, a część będzie obsługiwana lokalnie przez silnik analityczny.

Po co stosować ten wzorzec

• Standaryzacja metryk i definicji KPI w wielu raportach przy minimalizacji ryzyka rozjazdu definicji.
• Skalowanie developmentu: równoległa praca wielu zespołów nad raportami bez duplikowania modeli.
• Kontrola kosztu i wydajności: centralne zarządzanie tym, co jest Import, a co DirectQuery, oraz ograniczanie „samowolnych” zmian w modelu.
• Łatwiejsze wdrażanie governance (certyfikacja/promocja datasetów, kontrola uprawnień do budowy raportów).
• Szybsza iteracja wizualizacji: zmiany w raporcie nie wymagają przebudowy całego modelu, o ile nie dotykają datasetu.

Co jest tu kluczowe pojęciowo

• Shared dataset jako produkt: wersjonowany, testowany i publikowany w kontrolowanym cyklu.
• Thin report jako „klient” datasetu: przechowuje layout, filtry, zakładki i uprawnienia do treści raportowej, ale nie logikę modelu.
• Konsekwencje DirectQuery w warstwie semantycznej: interakcje użytkownika w raporcie mogą przekładać się na zapytania do źródła, a nie tylko na przeliczenia w pamięci.
• Kontrakty semantyczne: stabilność nazw pól/miar i zachowania filtrów jako warunek, by wiele raportów nie „pękało” po zmianach.

Główne ryzyka i pułapki

• Wąskie gardło w jednym datasetcie: centralizacja pomaga w zarządzaniu, ale zwiększa skutki błędów wydajnościowych — jeden problem może dotknąć wiele raportów.
• Nieprzewidywalna „kosztowność” interakcji w thin reports: różne układy wizualizacji mogą generować odmienne wzorce zapytań, szczególnie gdy w datasetcie są elementy DirectQuery.
• Ryzyko regresji: zmiana w modelu (np. relacje, miary, formatowanie, ukrywanie pól) może wpłynąć na zachowanie i wydajność wielu raportów jednocześnie.
• Złożone zarządzanie uprawnieniami: rozdzielenie dostępu do datasetu i do raportu wymaga spójnej polityki, by nie tworzyć luk lub blokad dla autorów.
• „Rozjechanie” odpowiedzialności: jeśli nie jest jasne, kto utrzymuje dataset, a kto raporty, rośnie liczba incydentów i obejść (np. kopiowanie datasetów).
• Utrudnione diagnozowanie: problem zgłaszany „w raporcie” może wynikać z datasetu, źródła danych, bramy, uprawnień lub samej konstrukcji wizualizacji.

Jak testować i weryfikować w środowisku (bez wchodzenia w detale)

• Testy regresji funkcjonalnej i wydajnościowej datasetu przed publikacją zmian: kluczowe scenariusze użytkownika powinny być odtwarzane w sposób powtarzalny.
• Testy obciążeniowe na poziomie datasetu: weryfikacja, jak model zachowuje się przy równoległych odpytywaniach z wielu thin reports.
• Monitorowanie end-to-end: od czasu odpowiedzi w raporcie, przez silnik semantyczny, po źródło DirectQuery i ewentualną bramę danych.
• Testy wpływu zmian semantycznych: sprawdzanie, czy zmiany w modelu nie zmieniają niejawnie filtracji, agregacji lub zachowania miar w istniejących raportach.
• Walidacja uprawnień: upewnienie się, że dostęp do datasetu, budowy raportów i widoczności danych jest spójny z założeniami governance.

Rozdzielenie warstwy semantycznej i raportowej to skuteczny sposób na uporządkowanie ekosystemu Power BI, ale w obecności DirectQuery wymaga szczególnej dyscypliny: projektowania datasetu jako współdzielonego produktu, świadomego zarządzania zmianą oraz testów, które obejmują zarówno wydajność, jak i stabilność kontraktów semantycznych.

Jeśli chcesz poznać więcej takich przykładów, zapraszamy na szkolenia Cognity, gdzie rozwijamy ten temat w praktyce.

Claude Code w dużych projektach: refaktoryzacja bez katastrofy i regresji w kodzie 07 czerwca 2026

Claude Code w DevOps: co psuje większość pipeline’ów CI/CD i jak AI pomaga to naprawić 05 czerwca 2026