Query Folding: 14 sygnałów, że Power Query przestał foldować (i jak to naprawić)

1. Czym jest query folding w Power Query i dlaczego ma kluczowe znaczenie dla wydajności

Query folding (składanie zapytania) to mechanizm, w którym Power Query stara się „przetłumaczyć” kroki transformacji danych na język zrozumiały dla źródła danych (np. zapytanie do bazy) i wykonać je po stronie źródła, zanim dane trafią do Power Query. W praktyce oznacza to, że zamiast pobierać pełny zestaw danych i obrabiać go lokalnie, Power Query próbuje zlecić jak najwięcej pracy silnikowi źródłowemu.

Najprościej: gdy folding działa, do Power Query trafia już wstępnie przefiltrowany, ograniczony i przygotowany wynik. Gdy folding nie działa, Power Query częściej musi pobrać więcej danych i wykonać transformacje samodzielnie, co zwykle jest wolniejsze i bardziej zasobożerne.

Dlaczego to ma kluczowe znaczenie dla wydajności

• Mniej danych do pobrania — jeśli filtrowanie, wybór kolumn czy agregacje dzieją się w źródle, przez sieć i konektor przechodzi mniejszy wolumen danych. To często największy pojedynczy zysk w czasie odświeżania.
• Lepsze wykorzystanie możliwości źródła — bazy danych i niektóre systemy analityczne są zoptymalizowane pod zapytania (indeksy, partycje, równoległość, cache). Gdy kroki składają się do zapytania, korzystasz z tych optymalizacji zamiast obciążać lokalny silnik Power Query.
• Mniejsze zużycie pamięci i CPU po stronie Power Query — brak foldingu częściej oznacza materializację większych zbiorów danych w trakcie przekształceń, co podnosi ryzyko długich odświeżeń, limitów zasobów lub niestabilności.
• Przewidywalny czas refresh — gdy logika jest wykonywana w źródle, wyniki są zwykle bardziej stabilne w czasie (zwłaszcza przy rosnących wolumenach). Gdy wszystko dzieje się lokalnie, czas odświeżania rośnie szybciej wraz z rozmiarem danych.
• Lepsza skalowalność rozwiązań — to, co działa „na małej próbce”, może przestać działać na produkcji. Folding jest jednym z kluczowych warunków, by rozwiązanie utrzymało wydajność przy milionach wierszy.

Co folding zmienia w praktyce dla autora zapytania

Query folding wpływa na to, jak projektujesz kolejność kroków i dobierasz transformacje. Wiele operacji ma „odpowiednik” możliwy do wykonania w źródle, a inne są trudniejsze do przetłumaczenia i mogą spowodować, że dalsza część zapytania zacznie wykonywać się lokalnie. Efekt jest często nieoczywisty: dwa zapytania dają ten sam wynik, ale jedno odświeża się w minutę, a drugie w kilkanaście.

Kiedy query folding jest najbardziej krytyczny

• Duże wolumeny danych oraz źródła z ograniczeniami transferu.
• Odświeżania cykliczne (np. wiele razy dziennie) i modele, które muszą zmieścić się w oknach czasowych.
• Współdzielone środowiska, gdzie obciążenie zasobów wpływa na innych użytkowników i procesy.
• Scenariusze z wieloma zapytaniami, gdzie każde dodatkowe „nieskładające się” przekształcenie kumuluje koszt w całym rozwiązaniu.

Warto traktować folding jako pierwszą linię optymalizacji: jeśli kroki mogą zostać wykonane w źródle, zwykle będzie to szybciej, taniej i stabilniej niż wykonywanie tej samej pracy lokalnie w Power Query.

2. Jak działa folding: źródła wspierające, granice foldingu i co decyduje o „złożeniu” kroków

Query folding polega na tym, że Power Query stara się „przepisać” kolejne kroki transformacji na język zapytań właściwy dla źródła danych (np. SQL) i wykonać je po stronie źródła, zamiast pobierać pełne dane i przetwarzać je lokalnie. W praktyce oznacza to zwykle mniej przesłanych danych, mniejsze obciążenie pamięci oraz szybsze odświeżanie.

Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity: jak rozpoznać moment, w którym folding się kończy, i co z tym zrobić w praktyce.

Folding nie jest cechą „włącz/wyłącz” dla całego zapytania. Najczęściej działa do pewnego miejsca w kolejce kroków: dopóki Power Query potrafi przetłumaczyć logikę na operacje obsługiwane przez źródło, dopóty kroki mogą się składać. Gdy pojawi się krok, którego nie da się wiarygodnie przenieść do źródła, dalsza część zapytania zwykle przechodzi na przetwarzanie lokalne.

Źródła wspierające folding (i co to realnie znaczy)

Folding jest możliwy wtedy, gdy łączysz się przez konektor, który potrafi generować „natywne” zapytania do danego systemu oraz gdy samo źródło jest w stanie wykonać daną klasę operacji. Najczęściej folding spotyka się przy źródłach relacyjnych i analitycznych, gdzie istnieje dojrzały język zapytań i optymalizator.

• Bazy relacyjne (np. SQL Server, PostgreSQL, MySQL): zwykle dobre wsparcie dla filtrowania, wyboru kolumn, agregacji, joinów i części operacji na datach/tekście.
• Silniki analityczne (np. źródła oparte o SQL/MDX/DAX w zależności od konektora): folding bywa możliwy, ale zależy od trybu połączenia i rodzaju modelu.
• Źródła plikowe (CSV, Excel, foldery): zazwyczaj nie ma gdzie „złożyć” zapytania, bo plik nie jest silnikiem zapytań. Część optymalizacji może dotyczyć tylko sposobu odczytu, ale to nie jest folding w sensie „przeniesienia logiki do źródła”.
• Usługi web/API: folding zwykle jest ograniczony do parametrów zapytania, które API wprost obsługuje (np. paging, filtrowanie po stronie endpointu). Jeśli API tego nie oferuje, Power Query musi przetwarzać lokalnie.

Wniosek praktyczny: to, czy folding jest możliwy, wynika z kombinacji konektora (czy umie tłumaczyć kroki) oraz silnika źródłowego (czy umie je wykonać efektywnie i deterministycznie).

Granice foldingu: dlaczego nie wszystko da się „złożyć”

Power Query może składać tylko takie operacje, które da się jednoznacznie i bezpiecznie odwzorować na operacje źródła. Ograniczenia wynikają zwykle z trzech powodów:

• Różnice semantyczne: ta sama funkcja w Power Query i w źródle może inaczej traktować wielkość liter, sortowanie, znaki diakrytyczne, strefy czasowe, wartości pustych pól czy zaokrąglenia. Jeśli wynik mógłby się różnić, folding może zostać przerwany.
• Brak odpowiednika w języku źródła: niektóre transformacje (zwłaszcza niestandardowe, iteracyjne lub zależne od kontekstu wiersza) nie mają prostego odpowiednika w SQL lub w danym dialekcie.
• Wymuszona materializacja: gdy Power Query musi „zobaczyć” wynik pośredni (np. aby obliczyć coś, co zależy od pełnego zbioru danych), często kończy się to pobraniem danych lokalnie i dalszym przetwarzaniem poza źródłem.

Co decyduje o tym, czy krok zostanie złożony

Decyzja o foldingu jest podejmowana dla łańcucha kroków, a nie w izolacji. Najczęściej wpływają na nią:

• Typ operacji: selekcja kolumn, proste filtry i agregacje mają zwykle największą szansę na folding; złożone operacje tekstowe, niestandardowe logiki i niektóre przekształcenia struktury danych mają mniejszą.
• Kolejność kroków: nawet „foldowalne” operacje mogą przestać się składać, jeśli pojawią się po kroku, który przerwał folding. To dlatego w praktyce tak istotne jest wykonywanie redukcji danych możliwie wcześnie.
• Parametry i zależności dynamiczne: gdy część logiki zależy od wartości obliczanych w trakcie (np. z innego zapytania, z aktualnego czasu, z zawartości całego zbioru), przeniesienie tego w całości do źródła może być niemożliwe lub nieopłacalne.
• Poziomy prywatności i sposób łączenia źródeł: przy mieszaniu różnych źródeł danych Power Query czasem stosuje dodatkowe zabezpieczenia i strategie łączenia, które mogą ograniczać możliwość składania kroków do jednego systemu.
• Możliwości konektora i dialektu: dwa różne źródła „SQL” nie muszą składać tych samych transformacji, bo różnią się funkcjami, typami danych i zachowaniem optymalizatora.

Najważniejsze jest zrozumienie mechanizmu: folding działa wtedy, gdy Power Query potrafi utrzymać ciągłość tłumaczenia kroków na zapytanie natywne, a źródło potrafi wykonać tę logikę bez utraty zgodności wyniku. Gdy ciągłość zostanie przerwana, dalsze kroki zwykle wykonują się lokalnie, co natychmiast zmienia profil wydajności odświeżania.

3. Szybka procedura diagnostyczna: jak sprawdzić, czy kroki się składają

Najprostsza diagnostyka query foldingu polega na odpowiedzi na dwa pytania: (1) czy źródło w ogóle wspiera folding oraz (2) do którego kroku folding „dochodzi”. Poniżej masz krótką procedurę, która pozwala to sprawdzić bez zgadywania i bez wchodzenia w szczegóły konkretnych „psujących” kroków (te będą dalej).

A. Test 1: View Native Query (najszybszy „check” na poziomie kroku)

Do czego służy: błyskawicznie pokazuje, czy dany krok (i wszystko przed nim) może zostać przetłumaczone na zapytanie natywne źródła (np. SQL).

• W edytorze Power Query kliknij krok w panelu Applied Steps.
• Kliknij prawym przyciskiem myszy na krok → View Native Query.

Interpretacja wyniku:

• Jeśli opcja jest aktywna i pokazuje zapytanie → folding działa do tego kroku.
• Jeśli opcja jest wyszarzona / niedostępna → folding nie dochodzi do tego kroku (albo źródło/tryb połączenia nie wspiera tej funkcji).

Szybka praktyka: przechodź krok po kroku od góry i sprawdź, w którym miejscu View Native Query przestaje być dostępne. Ten pierwszy „problemowy” krok jest zwykle granicą foldingu.

Uwaga: brak dostępności View Native Query nie zawsze oznacza, że nic się nie składa — czasem oznacza ograniczenie podglądu dla danego konektora. Wtedy przejdź do testu z Performance Analyzer lub diagnostyki.

B. Test 2: Performance Analyzer w Power BI (folding widziany przez pryzmat czasu i zapytań)

Do czego służy: pozwala powiązać objawy (długi refresh, duże transfery) z konkretnymi zapytaniami oraz podejrzeć, czy Power BI odpytuje źródło „mądrze” (z filtrami/kolumnami) czy pobiera „za dużo” i obrabia lokalnie.

• W Power BI Desktop: View → Performance analyzer.
• Uruchom rejestrowanie (Start recording).
• Wykonaj akcję, która wymusza odpytywanie danych (np. odśwież).
• Zatrzymaj rejestrowanie i przejrzyj czasy oraz szczegóły.

Na co patrzeć (bez „grzebania” w szczegółach):

• Nietypowo długi czas pobierania/transformacji w porównaniu do oczekiwań.
• Wskazówki, że zapytanie wykonuje się etapami lub wielokrotnie (często koreluje z brakiem foldingu lub nieoptymalnym planem).

Performance Analyzer nie jest „wprost” przełącznikiem folding on/off, ale jest świetny do potwierdzania skutków braku foldingu i do wyłapania, że problem dotyczy konkretnego zapytania lub kroku (zwłaszcza w większych modelach).

C. Test 3: Diagnostyka w Power Query (logi i porównanie „co idzie do źródła”)

Do czego służy: daje twardsze dowody: jakie zapytania są wysyłane do źródła, ile razy i jak długo to trwa. To przydatne, gdy View Native Query nie jest dostępne albo gdy podejrzewasz, że folding jest częściowy i powoduje „dodatkowe rundy” do źródła.

• W edytorze Power Query: Tools → Start Diagnostics.
• Wykonaj odświeżenie podglądu/odświeżenie zapytania albo przejdź przez kroki, które podejrzewasz.
• Stop Diagnostics, a następnie przejrzyj wygenerowane wyniki (zapytania diagnostyczne).

Co z tego wyciągnąć na szybko:

• Czy źródło jest odpytywane jednym większym zapytaniem (często oznaka foldingu), czy wieloma fragmentami.
• Czy pojawiają się długie czasy po stronie transformacji (często oznaka pracy lokalnej) vs po stronie źródła.

Mini-checklista: 5 minut do wskazania granicy foldingu

• Krok 1: sprawdź na wczesnym kroku, czy View Native Query w ogóle działa (weryfikacja „czy jest co foldować”).
• Krok 2: idź krok po kroku, aż opcja przestanie być dostępna — zanotuj pierwszy taki krok.
• Krok 3: jeśli nie możesz użyć View Native Query, uruchom diagnostykę i sprawdź, czy zapytania są wypychane do źródła czy dane są masowo pobierane.
• Krok 4: potwierdź efekt w Performance Analyzer (czy problem ma realny wpływ na czas/ilość pracy).
• Krok 5: wróć do granicznego kroku i sprawdź, czy prosta zmiana kolejności (np. filtr wcześniej) przywraca możliwość podglądu natywnego zapytania.

Porównanie metod: kiedy której używać

Krótki przykład „granicy” foldingu (orientacyjnie)

W praktyce często diagnoza kończy się wskazaniem konkretnego kroku, po którym folding przestaje działać. Poniższy fragment M ma wyłącznie charakter pomocniczy: pokazuje typowy moment, w którym po serii kroków „bezpiecznych” pojawia się krok, który bywa wykonywany lokalnie.

let
    Source = Sql.Database("SERVER", "DB"),
    Data = Source{[Schema="dbo", Item="FactSales"]}[Data],
    Filtered = Table.SelectRows(Data, each [SaleDate] >= #date(2025,1,1)),
    Selected = Table.SelectColumns(Filtered, {"SaleDate","Amount","Country"}),
    // w tym miejscu najczęściej View Native Query nadal działa
    AddedCustom = Table.AddColumn(Selected, "Flag", each Text.Contains([Country], "PL"))
    // po tym kroku bywa, że View Native Query przestaje być dostępne
in
    AddedCustom

W diagnostyce chodzi nie o to, by zapamiętać „które funkcje psują”, tylko by pewnie ustalić, gdzie to się dzieje w Twoim zapytaniu. Dopiero potem ma sens dobierać naprawę.

4. 14 sygnałów, że query folding się zepsuł — lista kontrolna

Poniższa lista to kontrolka objawów: jeśli widzisz jeden lub kilka z nich, istnieje duża szansa, że część kroków przestała być „spychana” do źródła danych, a Power Query zaczyna wykonywać więcej pracy lokalnie. To zwykle oznacza dłuższy refresh, większe zużycie pamięci i większe obciążenie bramy (jeśli używasz gateway). Doświadczenie Cognity pokazuje, że rozwiązanie tego problemu przynosi szybkie i zauważalne efekty w codziennej pracy.

• 1) Opcja „View Native Query” znika lub jest wyszarzona dla kroku, który wcześniej ją miał.
• 2) Folding urywa się po jednym, konkretnym kroku — wcześniejsze kroki wyglądają „OK”, ale od tego miejsca dalej już nie.
• 3) Drastyczny wzrost czasu odświeżania po pozornie drobnej zmianie w transformacjach.
• 4) Nagły skok wolumenu pobieranych danych (np. zamiast kilku tysięcy rekordów pobiera się pełną tabelę), mimo że końcowy wynik jest mały.
• 5) Widoczne „mielenie” na etapie Preview/Apply Steps — podgląd danych zaczyna trwać zauważalnie dłużej niż wcześniej.
• 6) Duże zużycie RAM/CPU podczas odświeżania po stronie klienta Power BI Desktop/Excel (symptom przetwarzania lokalnego).
• 7) Query działa szybko w źródle (np. w SQL), ale wolno w Power Query przy podobnej logice filtrowania/joinów.
• 8) Filtrowanie lub ograniczanie kolumn „nie odchudza” danych tak jak powinno — refresh nadal wygląda jak pełny skan.
• 9) Sortowanie staje się wyjątkowo kosztowne albo powoduje, że dalsze kroki przestają się składać.
• 10) Łączenie tabel (Merge) nagle zwalnia albo zaczyna wyglądać jakby odbywało się po stronie Power Query, a nie źródła.
• 11) Dodanie kolumny niestandardowej (Custom Column) powoduje spadek wydajności i „ucina” możliwość foldingu w kolejnych krokach.
• 12) Zmiana typów danych (Changed Type) w nieoczekiwanym miejscu koreluje z utratą foldingu (szczególnie przy późniejszych filtrach/joinach).
• 13) Wykorzystanie kroków „wygodnych”, ale ciężkich (np. operacje tekstowe, daty, zaawansowane transformacje) powoduje, że zapytanie zaczyna działać jak ETL lokalny.
• 14) Niespójne zachowanie między środowiskami: w Desktop „jakoś działa”, ale w Service (lub przez gateway) refresh jest znacząco wolniejszy lub kończy się błędami zasobów — częsty sygnał, że folding nie zachodzi w praktyce.

Jeśli chcesz szybko odhaczać symptomy w pracy, traktuj listę jak regułę: każdy krok, który przenosi obliczenia z serwera do Power Query, mnoży koszt — szczególnie przy dużych tabelach i odświeżaniu w chmurze.

5. Dla każdego sygnału: możliwa przyczyna oraz konkretne kroki naprawy

Poniżej znajdziesz praktyczną mapę: sygnał → typowa przyczyna → co zrobić, żeby folding wrócił. Kluczowa zasada w większości napraw jest prosta: przenieś selekcję, filtrowanie i projekcję (wybór kolumn) jak najbliżej źródła, a „ciężkie” transformacje zostaw na koniec.

Mini-wzorzec naprawczy (kolejność transformacji): w praktyce najczęściej odzyskasz folding, gdy przesuniesz kroki „redukujące” dane na początek, a „wzbogacające” na koniec.

// Schematycznie (niezależnie od źródła)
let
  Source = ...,
  KeepCols = Table.SelectColumns(Source, {"..."}),
  Filtered = Table.SelectRows(KeepCols, each ...),
  JoinedOrGrouped = ...,
  Added = Table.AddColumn(JoinedOrGrouped, "...", each ...),
  Typed = Table.TransformColumnTypes(Added, {{"...", type ...}})
in
  Typed

6. Najczęstsze „fold-breaking” kroki i wzorce oraz ich bezpieczne odpowiedniki

Query folding najczęściej „psuje się” nie przez pojedynczy błąd, tylko przez konkretne kroki lub wzorce transformacji, które wymuszają pobranie danych do silnika Power Query i dopiero potem wykonanie logiki lokalnie. Poniżej znajdziesz najczęstsze przypadki oraz bezpieczniejsze odpowiedniki, które zwykle pozwalają utrzymać składanie zapytania (o ile źródło je wspiera).

Wzorce szczególnie ryzykowne (i jak o nich myśleć)

• „Najpierw wszystko pobiorę, potem przefiltruję” — to typowy antywzorzec. Bezpieczniejsza idea: filtruj i wybieraj kolumny jak najwcześniej, zanim pojawią się trudniejsze transformacje.

• „Dodam kolumnę z logiką biznesową w M” — proste warunki często się składają, ale złożone reguły, lookupi i custom functions zwykle nie. Bezpieczniejsza idea: utrzymać obliczenia w granicach funkcji wspieranych przez źródło albo przenieść reguły do widoku/SQL.

• „Muszę mieć stabilną kolejność, więc sortuję w środku” — sortowanie w połowie procesu często jest zbędne, a bywa kosztowne. Bezpieczniejsza idea: sortuj na końcu (lub tylko w połączeniu z ograniczeniem wyniku).

• „Zbufferuję tabelę, żeby było szybciej” — Table.Buffer bywa kuszący, ale często jest „punktem bez powrotu” dla foldingu. Bezpieczniejsza idea: traktuj buffer jako ostateczność po maksymalnej redukcji danych.

Mini-przykład: Table.Buffer jako typowy „fold breaker”

Poniżej widać samą ideę: buforowanie wymusza pobranie danych lokalnie, więc kolejne kroki zwykle nie trafią już do źródła.

// Antywzorzec (często kończy folding)
let
  Source = ...,
  Buffered = Table.Buffer(Source),
  Filtered = Table.SelectRows(Buffered, each [Status] = "Active")
in
  Filtered

Bezpieczniejsza kolejność myślenia: najpierw redukcja wierszy/kolumn, potem ewentualne działania lokalne, jeśli są naprawdę potrzebne.

7. Praktyczne rekomendacje i checklisty: jak projektować zapytania, by utrzymać folding i skrócić refresh

Query folding najłatwiej utrzymać nie wtedy, gdy „naprawiasz” jedno miejsce w zapytaniu, ale gdy od początku projektujesz transformacje tak, by jak najwięcej pracy wykonywało źródło danych (np. baza). Poniżej znajdziesz zestaw praktyk i krótkich checklist, które pomagają ograniczyć liczbę przetwarzanych wierszy, zmniejszyć transfer oraz skrócić czas odświeżania.

Projektuj z myślą o „pushdown” — filtruj i zawężaj jak najwcześniej

• Najpierw redukuj wolumen: stosuj filtry, wybór kolumn i ograniczenia zakresu danych możliwie na początku zapytania.
• Minimalizuj szerokość danych: usuwaj nieużywane kolumny zanim zaczniesz kosztowne operacje (łączenia, grupowania, pivoty).
• Unikaj „pobierania na zapas”: jeśli potrzebujesz tylko wycinka danych do modelu/raportu, nie importuj pełnej tabeli „bo może się przyda”.

Trzymaj transformacje w bezpiecznej kolejności

Kolejność kroków często decyduje o tym, czy folding przetrwa. W praktyce najlepiej działają zapytania, które najpierw ograniczają dane, a dopiero potem je wzbogacają.

• Preferuj prostą ścieżkę: filtrowanie → wybór kolumn → proste przekształcenia → dopiero potem bardziej złożone operacje.
• Przenoś obliczenia „później”, jeśli to możliwe: obliczenia zależne od wielu kroków lub wymagające niestandardowej logiki wykonuj dopiero, gdy masz mniej danych.
• Ostrożnie z sortowaniem: sortuj tylko wtedy, gdy jest to rzeczywiście potrzebne (np. do deduplikacji według ostatniej daty) i najlepiej jak najpóźniej.

Ujednolicaj typy danych, ale nie „na siłę”

• Spójność typów: pilnuj, by kolumny używane w filtrach, joinach i relacjach miały zgodne typy po obu stronach.
• Nie przesadzaj z masową zmianą typów: jeśli nie jest to potrzebne do modelu lub logiki, ogranicz automatyczne/masowe konwersje do minimum.
• Waliduj daty i liczby u źródła: jeśli dane wejściowe bywają „brudne”, lepiej korygować je możliwie blisko źródła (albo w warstwie przygotowania danych), niż wymuszać skomplikowane naprawy w Power Query.

Utrzymuj „prostą” logikę w Power Query, a złożoną lokuj tam, gdzie jest najszybsza

• Preferuj logikę, którą źródło rozumie: proste filtry, selekcje, projekcje i łączenia zwykle składają się lepiej niż rozbudowane reguły biznesowe.
• Reguły biznesowe przenoś do źródła, gdy rosną: gdy logika staje się wieloetapowa, rozważ widok, zapytanie w źródle lub warstwę przygotowania danych, zamiast komplikować M.
• Unikaj „kaskady wyjątków”: wiele wyjątków w logice (np. liczne warunki) zwiększa ryzyko utraty foldingu; staraj się je upraszczać lub normalizować dane wcześniej.

Dbaj o stabilność zapytania i przewidywalność wyników

• Parametry zamiast ręcznych zmian: zakres dat, środowisko (DEV/PROD) czy progi filtrów ustawiaj parametrami, aby ograniczyć ryzyko przypadkowych zmian kroków.
• Unikaj elementów zależnych od czasu/losowości w warstwie przygotowania danych, jeśli wpływają na deterministyczność i utrudniają optymalizację.
• Ogranicz liczbę zależności: mniej odwołań do innych zapytań i mniej rozgałęzień zwykle oznacza prostszy plan odświeżania.

Kontroluj łączenia i modeluj wejście pod join/merge

• Joinuj na dobrze przygotowanych kluczach: spójne typy, brak zbędnych spacji i dopasowana kardynalność to mniej pracy i mniejsze ryzyko kosztownych operacji.
• Wybieraj minimalny zestaw kolumn przed łączeniem: dołączaj tylko te kolumny, które są potrzebne po merge.
• Ogranicz liczbę merge’ów w łańcuchu: wiele kolejnych łączeń potrafi skomplikować plan zapytania; jeśli to możliwe, konsoliduj je w źródle lub upraszczaj przepływ.

Checklisty do codziennej pracy

Checklist „przed publikacją” — szybka kontrola jakości zapytania:

• Czy na początku zapytania ograniczam liczbę wierszy (filtry) i kolumn (select)?
• Czy kluczowe kroki (filtry, joiny, grupowania) są możliwie proste i nie są poprzedzone kosztownymi transformacjami?
• Czy typy danych są spójne w miejscach, gdzie łączę i filtruję?
• Czy unikam nadmiarowych kroków porządkowania i kosmetyki (np. sortowanie, zmiany nazw) przed redukcją danych?
• Czy logika biznesowa, która rośnie w złożoność, nie powinna być przeniesiona bliżej źródła?
• Czy zapytanie jest parametryzowane tam, gdzie to ma sens (daty, środowiska, progi)?

Checklist „gdy refresh zwalnia” — praktyki, które zwykle najszybciej przynoszą efekt:

• Sprawdź, czy w zapytaniu nie pojawił się krok, po którym dalsze transformacje zaczęły działać „lokalnie”.
• Przenieś filtry i wybór kolumn wyżej w kolejności kroków.
• Usuń lub odsuń w dół kroki porządkujące (sortowanie, zmiany nazw, formatowanie), jeśli nie są niezbędne do logiki.
• Uprość miejsca, gdzie dane są „tworzone od zera” (np. rozbudowane kolumny warunkowe) i rozważ ich realizację bliżej źródła.
• Oceń, czy łączenia nie zaciągają zbyt wielu kolumn i czy klucze są czyste oraz zgodne typami.

Zasady „na skróty” (do zapamiętania)

• Mniej danych wcześniej — najpierw tnij wiersze i kolumny, potem przetwarzaj.
• Prościej znaczy szybciej — im bardziej standardowe operacje, tym większa szansa na folding.
• Źródło ma robić ciężką robotę — Power Query ma orkiestruje przepływ, a nie zastępuje silnik bazy.
• Świadoma kolejność kroków — to często różnica między sekundami a minutami odświeżania.

8. Checklist wdrożeniowy oraz „najczęstsze symptomy i naprawy”

Poniższa lista to szybki, praktyczny zestaw kroków do wdrożenia w projekcie Power Query, gdy zależy Ci na utrzymaniu query folding i przewidywalnym czasie odświeżania. Nie zastępuje analizy pojedynczych transformacji, ale pozwala szybko wychwycić miejsca, w których folding najczęściej „odpada” i wskazuje bezpieczne kierunki naprawy.

W Cognity łączymy teorię z praktyką – dlatego ten temat rozwijamy także w formie ćwiczeń na szkoleniach.

Checklist wdrożeniowy (przed publikacją i przed każdą większą zmianą)

• Ustal docelowe źródło prawdy: gdzie ma zostać wykonana większość pracy — w źródle (SQL/warehouse) czy w Power Query. Jeśli źródło wspiera folding, preferuj wykonywanie filtrów i redukcji danych jak najbliżej źródła.
• Zacznij od minimalizacji danych: najpierw ogranicz zakres (filtry, wybór kolumn), dopiero potem „upiększaj” dane (formatowanie, teksty, logika biznesowa).
• Trzymaj się prostych, foldowalnych operacji: podstawowe filtry, selekcja kolumn, typy, grupowania i łączenia wykonywane w standardowy sposób są zwykle bezpieczniejsze niż złożone, niestandardowe konstrukcje.
• Kontroluj kolejność kroków: przyjmij zasadę „redukcja → relacje/łączenia → obliczenia → kosmetyka”. Zmiana kolejności często przywraca folding bez przebudowy logiki.
• Unikaj kroków, które wymuszają materializację danych: wszystko, co „zmusza” Power Query do pobrania pełnego zestawu wierszy do pamięci, zwykle przerywa folding. Stosuj takie kroki wyłącznie świadomie i jak najpóźniej.
• Traktuj typy danych jako element kontraktu: typy ustawiaj w sposób spójny i możliwie wcześnie, ale uważaj na konwersje, które źródło może interpretować inaczej (szczególnie daty/czas i liczby dziesiętne).
• Standaryzuj parametry i filtry: preferuj parametry (zakres dat, statusy, regiony) zamiast „ręcznych” wartości w wielu miejscach — ułatwia to utrzymanie i ogranicza ryzyko przypadkowego złamania foldingu.
• Weryfikuj folding po każdej istotnej zmianie: dodanie jednego kroku potrafi „odciąć” folding dla wszystkich kolejnych. Traktuj to jako test regresji wydajności.
• Rozdziel logikę na warstwy: osobno etap pozyskania i redukcji danych, osobno etap modelowania/semantyki. Zmniejsza to ryzyko, że zmiana w logice biznesowej popsuje folding w krytycznych miejscach.
• Kontroluj łączenia (merge) i dopasowanie kluczy: upewnij się, że typy i formaty kluczy są zgodne, a warunki łączenia proste. To jedne z najczęstszych punktów utraty foldingu.
• Dbaj o powtarzalność środowiska: różnice w konektorach, ustawieniach prywatności i bramie danych potrafią zmienić zachowanie zapytania. Dokumentuj konfigurację i trzymaj ją stałą.
• Ustal kryteria „gotowości do produkcji”: np. maksymalny czas odświeżania, brak niepotrzebnych kroków wymuszających pobranie pełnych danych, stabilny wynik przy kilku odświeżeniach pod rząd.

Najczęstsze symptomy, że folding nie działa (i typowe kierunki naprawy)

• Odświeżanie nagle trwa wielokrotnie dłużej
  Typowy kierunek naprawy: przenieś filtry i selekcję kolumn wcześniej; sprawdź, czy ostatnio dodany krok nie wymusza pobrania danych lokalnie; uprość kroki „po drodze”.
• Wzrost zużycia pamięci lub obciążenia CPU podczas odświeżania
  Typowy kierunek naprawy: usuń lub przesuń na koniec operacje wymagające pełnego przetworzenia tabeli; ogranicz liczbę wierszy przed kosztownymi transformacjami.
• Dużo danych „ściąga się” mimo wąskiego filtra w raporcie
  Typowy kierunek naprawy: zapewnij filtr na etapie zapytania (w Power Query), a nie dopiero w modelu; parametryzuj zakres; pilnuj, by filtr był na kolumnie, którą źródło potrafi efektywnie przefiltrować.
• Nie da się potwierdzić natywnego zapytania dla kolejnych kroków
  Typowy kierunek naprawy: cofnij się do ostatniego „dobrego” kroku i identyfikuj pierwszy krok, po którym folding znika; zastąp go prostszą transformacją lub zmień kolejność działań.
• Merge/Append działa, ale refresh jest nieproporcjonalnie wolny
  Typowy kierunek naprawy: dopasuj typy kluczy po obu stronach; ogranicz kolumny przed scaleniem; rozważ wykonanie łączenia w źródle lub w warstwie pośredniej (np. widok), jeśli to krytyczne.
• Sortowanie „dla wygody” powoduje wyraźne spowolnienie
  Typowy kierunek naprawy: sortuj tylko tam, gdzie to konieczne (i możliwie późno); jeśli sort ma znaczenie biznesowe, spróbuj przenieść go do źródła lub zastąpić podejściem, które nie wymaga globalnego sortowania na etapie pobierania.
• Niestabilne wyniki lub różnice między Desktop a Service
  Typowy kierunek naprawy: ogranicz zależność od lokalnych ustawień i konwersji; ujednolić typy; zweryfikuj ustawienia prywatności, bramę oraz wersje konektorów.
• „Drobna” kolumna obliczana powoduje lawinowy spadek wydajności
  Typowy kierunek naprawy: sprawdź, czy użyta logika nie jest wykonywana wiersz po wierszu lokalnie; uprość wyrażenie; przesuń obliczenia po redukcji danych albo wykonaj je w źródle.
• Zmiana typów lub formatów dat/czasu psuje wydajność
  Typowy kierunek naprawy: trzymaj spójny typ w całym potoku; unikaj wielokrotnych konwersji; preferuj filtrowanie na typie natywnym źródła, a dopiero potem konwersje do potrzeb modelu.
• Odświeżenie kończy się timeoutem lub błędem bramy
  Typowy kierunek naprawy: zmniejsz wolumen danych na wejściu (filtry/kolumny); ogranicz kosztowne kroki przed pobraniem; w razie potrzeby przenieś ciężką logikę do źródła lub zastosuj podejście etapowe.

Minimalny zestaw zasad „na stałe”

• Redukuj dane jak najwcześniej (wiersze i kolumny) i nie rezygnuj z tego nawet w prototypie.
• Każdy nowy krok traktuj jak potencjalny „fold-breaker” i weryfikuj wpływ na wydajność.
• Najpierw prosto, potem sprytnie: jeśli da się osiągnąć ten sam efekt prostszą transformacją, zwykle będzie ona bardziej foldowalna i stabilna.
• Łączenia i typy danych to miejsca największego ryzyka — standaryzuj je i dokumentuj.

Claude Code vs ChatGPT i GitHub Copilot: co naprawdę wybrać do programowania 24 maja 2026

Power Query i incremental refresh: jak zaprojektować parametry, żeby odświeżanie nie mieliło danych 22 maja 2026