Czym różni się Power Query od Python ETL?

Power Query to narzędzie wbudowane w Power BI do prostych transformacji danych — działa graficznie, bez programowania, dobrze sprawdza się przy małych wolumenach i prostych źródłach. Python ETL to zewnętrzny proces działający niezależnie od Power BI — obsługuje błędy, ładuje dane przyrostowo i może obsługiwać wiele źródeł z różną częstotliwością.

Kiedy Power Query nie wystarczy do projektu BI z ERP?

Gdy dane pochodzą z systemu ERP z logiką biznesową (filtrowanie typów dokumentów, częściowe płatności, aging), gdy wolumen przekracza kilkaset tysięcy rekordów, gdy jest kilka źródeł danych lub gdy system musi działać niezawodnie z obsługą błędów i powiadomieniami.

ETL vs Power Query — kiedy Power Query wystarczy, a kiedy potrzebny jest kod

Q: Kiedy Power Query wystarczy?

Gdy źródłem danych jest Excel lub CSV, wolumen to kilkaset tysięcy wierszy lub mniej, logika transformacji jest prosta, a raport jest odświeżany raz dziennie lub rzadziej. Dla takich przypadków Power Query jest odpowiednim i wystarczającym rozwiązaniem.

Czym jest Power Query

Power Query to narzędzie wbudowane w Power BI (i w Excelu), służące do pobierania i przekształcania danych. Działa graficznie — można w nim zrobić całkiem sporo bez pisania jednej linii kodu. Podłączasz źródło, klikasz jakie kolumny zostawić, jakie typy danych ustawić, jak przefiltrować wiersze. Power BI zapamiętuje te kroki i wykonuje je przy każdym odświeżeniu raportu.

Power Query dobrze sprawdza się gdy: źródłem jest Excel, CSV lub prosta baza danych, wolumen to kilkaset tysięcy wierszy lub mniej, transformacje są proste i statyczne, a raport nie musi działać bez nadzoru w środku nocy. Dla takich przypadków Power Query jest właściwym narzędziem i dodawanie zewnętrznego procesu ETL byłoby niepotrzebną komplikacją.

Czym jest Python ETL

Python ETL to zewnętrzny skrypt lub proces, który działa niezależnie od Power BI — jako osobny proces uruchamiany automatycznie o konkretnej godzinie, codziennie lub częściej. Extrahuje dane ze źródła, przetwarza je według zdefiniowanej logiki i ładuje do bazy analitycznej. Power BI czyta potem z tej bazy — i nie wie nic o tym, skąd dane pochodzą i jak były przetwarzane.

Kilka rzeczy, które Python ETL robi inaczej niż Power Query:

Obsługa błędów. Jeśli system ERP jest niedostępny o 6:00, skrypt loguje błąd, wysyła powiadomienie i nie nadpisuje danych już załadowanych. Power Query po prostu zatrzymuje odświeżanie — bez powiadomienia, bez logu.
Ładowanie przyrostowe. ETL pobiera tylko nowe lub zmienione rekordy od ostatniego uruchomienia. Power Query ładuje całą tabelę od nowa przy każdym odświeżeniu — przy milionach rekordów to problematyczne.
Logika biznesowa możliwa do testowania. Kod ETL można wersjonować w git, testować niezależnie od raportu, audytować. Logika zapisana w Power Query żyje wewnątrz pliku Power BI — trudniej ją przenieść, sprawdzić i utrzymać.
Wiele źródeł z różną częstotliwością. System ERP raz dziennie, zewnętrzne API co godzinę, plik Excel aktualizowany ręcznie. ETL obsługuje każde z tych źródeł osobno, z własnym harmonogramem i własną logiką błędów.

Cztery pytania do dostawcy proponującego "tylko Power Query"

Jeśli dostajesz ofertę projektu z Optimą, enova365 lub innym systemem ERP, a dostawca proponuje samo Power Query — warto zapytać konkretnie. Poniższe pytania nie są naganiające — po prostu wymagają konkretnych odpowiedzi.

1. Jak odróżniacie faktury sprzedażowe od korekt, proform i dokumentów wewnętrznych?

System ERP przechowuje wiele typów dokumentów w tych samych tabelach. Bez właściwego filtrowania aging należności będzie błędny — korekty i dokumenty wewnętrzne zawyżą lub zaniżą kwoty. To wymaga logiki, której nie da się ustawić jednym kliknięciem w Power Query.

2. Co się stanie, jeśli system ERP jest niedostępny o 6:00 rano?

Czy odświeżenie zawiesi się po cichu? Czy jest powiadomienie? Kto dostanie alert? Bez obsługi błędów użytkownicy rano otworzą raport z danymi sprzed dwóch dni — i nie będą wiedzieć, że patrzą na nieaktualne dane.

3. Jak obsługujecie częściowe płatności?

W systemie ERP faktura może być zapłacona w kilku ratach, każda w osobnym rekordzie. Prawidłowe wyliczenie kwoty zaległej wymaga złączenia tych płatności z fakturą i odjęcia co już wpłynęło. To nie jest prosta kolumna — to logika, którą ktoś musi napisać i przetestować.

4. Co się stanie, gdy w systemie ERP będzie kilka milionów rekordów?

Power Query ładuje całą tabelę od nowa przy każdym odświeżeniu. Przy 5 latach faktur z dużej firmy to może oznaczać 45 minut ładowania lub timeout. A w czasie ładowania baza operacyjna jest obciążona — pracownicy mogą odczuć spowolnienie systemu ERP.

Kiedy co jest odpowiednie

Sytuacja	Power Query	Python ETL
Źródło: Excel / CSV	✓ wystarczy	overengineering
Źródło: system ERP (SQL)	⚠ ryzyko	✓ rekomendowany
Wolumen: do kilkuset tys. wierszy	✓ wystarczy	możliwy
Wolumen: miliony rekordów	✗ problematyczny	✓ wymagany
Kilka źródeł danych	⚠ trudne	✓ rekomendowany
Logika: aging, częściowe płatności	✗ nieodpowiedni	✓ wymagany
Obsługa błędów i powiadomienia	✗ brak	✓ wbudowana

Praktyczny skutek złego wyboru

Wybór między Power Query a Python ETL nie jest widoczny podczas korzystania z raportu. Jest widoczny dopiero gdy coś się zepsuje — i wtedy różnica jest ogromna.

"Raport zepsuł się o 6 rano, nikt nie wie dlaczego"

Klasyczny skutek Power Query bez obsługi błędów. System ERP był niedostępny przez 10 minut podczas okna odświeżania. Power BI pokazuje dane z poprzedniego dnia — bez wyraźnego ostrzeżenia. Użytkownicy pracują na nieaktualnych danych i nie wiedzą o tym, dopóki ktoś nie zauważy rozbieżności.

"Każde odświeżenie trwa 45 minut"

Power Query ładuje milion rekordów faktur od nowa przy każdym odświeżeniu, bo nie ma ładowania przyrostowego. W tym czasie baza operacyjna jest obciążona — pracownicy zgłaszają spowolnienie systemu ERP. Alternatywa: zmniejszyć zakres historii do 6 miesięcy. Klient, który chciał 3-letnią analizę, dostaje 6-miesięczną.

Python ETL jest droższy w budowie — to uczciwa informacja. Ale jego brak generuje koszty ukryte: czas na diagnozę i naprawę błędów, zaufanie do danych które były nieaktualne przez nieznany czas, ograniczenia w zakresie historii danych których nie dało się obejść.

Podsumowanie

Power Query to dobre narzędzie dla odpowiednich przypadków. Dla projektu z systemem ERP, złożoną logiką biznesową i wymaganiami niezawodności — Python ETL nie jest luksusem, jest architektoniczną koniecznością. Propozycja "tylko Power Query" w takim kontekście nie jest błędem per se — ale jest sygnałem, że dostawca nie przemyślał co się stanie gdy dane będą rosły, a system będzie działał bez nadzoru.

Najczęstsze pytania

Czy Power Query w ogóle nie nadaje się do projektów z ERP?

Nadaje się, jeśli projekt jest mały: mały wolumen, prosta logika, jedno źródło, odświeżanie raz dziennie lub rzadziej. Dla takich przypadków Python ETL byłby overengineering. Problem pojawia się gdy Power Query jest proponowany dla złożonego projektu z logiką biznesową i wymaganiami niezawodności.

Czy można zacząć od Power Query i przejść na ETL później?

Technicznie tak — ale w praktyce to bywa kosztowne. Logika zapisana w Power Query jest trudna do przeniesienia 1:1 do ETL. Zazwyczaj oznacza to przepisanie transformacji od nowa. Lepiej wybrać właściwą architekturę na początku niż przepisywać ją po roku.

Jak użytkownik rozpozna, że raport ma nieaktualne dane z powodu błędu odświeżania?

Przy Power Query bez obsługi błędów — często nie rozpozna. Power BI pokazuje ostatni dobry odczyt bez wyraźnego ostrzeżenia (chyba że skonfigurowano powiadomienia w Power BI Service, co wymaga odpowiedniej licencji). Przy Python ETL z obsługą błędów — alert trafia do wskazanej osoby zanim ktokolwiek otworzy raport.