Dataflows Gen2 vs dataset transformations: gdzie trzymać logikę ETL, by nie dublować pracy

1. Wprowadzenie: gdzie wykonywać transformacje w Power BI/Fabric

W projektach Power BI i Microsoft Fabric niemal zawsze pojawia się to samo pytanie: na którym etapie umieścić logikę ETL — w warstwie przygotowania danych (Dataflows Gen2) czy dopiero w warstwie modelu (transformacje w dataset/semantic modelu). Oba podejścia potrafią doprowadzić do identycznego wyniku raportowego, ale różnią się tym, kto konsumuje przetworzone dane, jak są one reużywane i gdzie powstaje „źródło prawdy” dla transformacji.

Dataflows Gen2 to miejsce, w którym transformacje można wykonać przed załadowaniem danych do docelowych artefaktów analitycznych. W praktyce oznacza to budowę warstwy przygotowania danych, która może służyć jako wspólna, uporządkowana baza dla wielu odbiorców (np. różnych modeli semantycznych, raportów czy zespołów). Gdy logika oczyszczania i ujednolicania danych jest potrzebna w więcej niż jednym miejscu, naturalnie kusi, by umieścić ją możliwie „wcześniej”.

Transformacje w datasetach/semantic modelu (czyli w warstwie modelowania, już bliżej raportu) to podejście, w którym dane są kształtowane pod konkretny model analityczny. Taka logika często jest mocno związana z wymaganiami raportowymi, metrykami, relacjami i interpretacją biznesową. To opcja wygodna, gdy transformacje są specyficzne dla jednego modelu i nie ma potrzeby udostępniać ich szerzej jako współdzielonej warstwy przygotowania danych.

Wybór miejsca na ETL rzadko jest wyłącznie techniczny. To decyzja o tym, czy priorytetem jest:

• centralizacja i reużywalność przygotowanych danych (częściej Dataflows Gen2),
• szybkość dostarczenia modelu dopasowanego do jednego celu (częściej transformacje w semantic modelu),
• kontrola i odpowiedzialność: kto utrzymuje logikę, kto ją zmienia i kto ponosi konsekwencje błędów.

Największym ryzykiem w praktyce nie jest „zły wybór” jednej z opcji, tylko nieświadome dublowanie transformacji między warstwami: część reguł trafia do dataflow, część do modelu, a po kilku iteracjach nikt nie jest pewien, gdzie faktycznie odbywa się oczyszczanie, mapowania czy standaryzacja. Dlatego już na starcie warto ustalić, czy logika ma być wspólną usługą przygotowania danych, czy elementem konkretnego modelu analitycznego — i konsekwentnie tego pilnować.

2. Przegląd podejść: charakterystyka Dataflows Gen2 oraz transformacji w datasetach/semantic modelu

W Power BI i Microsoft Fabric logikę ETL można umieszczać w dwóch głównych miejscach: w warstwie przygotowania danych (Dataflows Gen2) albo bezpośrednio w warstwie modelu semantycznego (transformacje w datasetach/semantic modelu). Oba podejścia korzystają z podobnych mechanizmów transformacji, ale różnią się tym, gdzie powstaje „prawda” o danych, jak jest ona udostępniana oraz dla kogo jest najwygodniejsza w utrzymaniu. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity.

Dataflows Gen2: ETL jako współdzielona warstwa przygotowania danych

Dataflows Gen2 to podejście, w którym transformacje realizuje się przed modelem semantycznym, tworząc powtarzalny proces przygotowania danych. Ideą jest oddzielenie logiki pozyskania i oczyszczania danych od samego modelowania analitycznego, tak aby ten sam „przygotowany” zestaw danych mógł zasilać wiele modeli, raportów lub innych artefaktów w Fabric.

• Centralizacja przygotowania danych: logika czyszczenia, łączenia i ujednolicania danych może być utrzymywana w jednym miejscu i wykorzystywana dalej jako wspólne źródło.
• Warstwa pośrednia między źródłem a modelem: Dataflow staje się etapem „staging/curation”, który stabilizuje dane zanim trafią do modeli semantycznych.
• Nastawienie na reużywalność: to podejście jest naturalne, gdy te same transformacje mają zasilać wiele modeli albo wiele zespołów.
• Rozdzielenie odpowiedzialności: łatwiej rozdzielić pracę między osoby skupione na integracji danych a osoby projektujące model i miary.

W praktyce Dataflows Gen2 są wybierane, gdy organizacja chce budować spójne, współdzielone „produkty danych” i ograniczyć powielanie tych samych kroków transformacji w wielu datasetach.

Transformacje w datasetach/semantic modelu: ETL „blisko raportu”

Drugie podejście polega na tym, że transformacje wykonywane są w samym datasetcie/semantic modelu (czyli w warstwie, z której korzystają raporty). To typowy wariant, gdy model jest projektowany pod konkretne potrzeby analityczne, a kroki przygotowania danych są ściśle związane z logiką danego raportowania.

• Szybkie dopasowanie do konkretnego przypadku użycia: transformacje są częścią definicji modelu, więc łatwiej iterować, gdy wymagania analityczne często się zmieniają.
• Bliskość modelowania: te same osoby, które projektują tabele, relacje i miary, mogą też kontrolować sposób przygotowania danych bez dodatkowej warstwy pośredniej.
• Mniejsza „infrastruktura” na start: gdy celem jest pojedynczy model/raport, dokładanie osobnej warstwy ETL może być przerostem formy nad treścią.
• Logika lokalna dla modelu: transformacje mogą być mocno specyficzne dla sposobu liczenia miar lub struktury modelu, a wtedy ich wynoszenie do wspólnej warstwy nie zawsze ma sens.

To podejście sprawdza się szczególnie w mniejszych rozwiązaniach lub tam, gdzie model jest „produktem końcowym” i nie zakłada się jego szerokiej reużywalności przez inne zespoły.

Najważniejsze różnice w ujęciu koncepcyjnym

Różnica nie sprowadza się wyłącznie do narzędzia, ale do miejsca, w którym organizacja „kotwiczy” logikę danych:

• Dataflows Gen2 traktują ETL jako niezależną, współdzieloną warstwę przygotowania danych, często używaną wielokrotnie w różnych kontekstach.
• Transformacje w datasetach/semantic modelu traktują ETL jako element budowy konkretnego modelu analitycznego, silnie powiązany z jego strukturą i zastosowaniem.

Wybór między tymi podejściami zwykle nie jest „albo-albo” — często współistnieją, ale z inną rolą: część transformacji warto ustandaryzować i wynieść do warstwy przygotowania danych, a część pozostawić tam, gdzie powstaje i ewoluuje model semantyczny.

3. Kryteria porównania

Poniższe kryteria pomagają zdecydować, czy logikę ETL lepiej umieścić w Dataflows Gen2 (warstwa przygotowania danych), czy w transformacjach na poziomie datasetu/semantic modelu (warstwa modelowania i dopasowania pod analitykę). Każde z podejść jest „właściwe” w innych warunkach — kluczowe jest ograniczenie dublowania reguł biznesowych i pracy utrzymaniowej.

• Reużywalność vs zwinność: Dataflows Gen2 wygrywa, gdy ta sama logika ma obsłużyć wiele modeli; transformacje w modelu wygrywają, gdy liczy się szybka iteracja w jednym, konkretnym semantic modelu.
• Ryzyko dublowania: im więcej datasetów, tym większa presja, by wspólne reguły (np. standaryzacja dat, walut, kluczy, deduplikacja) wynieść do Dataflows Gen2.
• Granica odpowiedzialności: Dataflows Gen2 częściej przejmuje „przygotuj i uczyń dane spójne”, a semantic model „zorganizuj pod analitykę i semantykę” (nazewnictwo, hierarchie, relacje, miary).

Uwaga praktyczna: jeżeli ta sama transformacja ma być zastosowana w kilku miejscach, to jest to sygnał, że warto ją „ucentralizować” (najczęściej w Dataflows Gen2). Jeśli transformacja jest specyficzna dla jednego modelu i nie ma sensu jej utrzymywać globalnie, zwykle zostaje w semantic modelu.

4. Macierz decyzji: kiedy wybrać Dataflows Gen2, a kiedy transformacje w semantic modelu

Poniższa macierz ma pomóc szybko zdecydować, gdzie umieścić logikę ETL, aby nie dublować pracy. W skrócie: Dataflows Gen2 wybieraj, gdy transformacje mają być wspólne dla wielu modeli/raportów i mają żyć „przed” modelem. Transformacje w semantic modelu wybieraj, gdy logika jest ściśle raportowa/modelowa i dotyczy konkretnego zestawu miar, relacji i kolumn. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami—bo granica między „przygotowaniem danych” a „logiką modelu” bywa w praktyce mniej oczywista, niż wynika to z definicji.

Reguły kciuka (bez wchodzenia w szczegóły)

• Jeśli transformacje mają być współdzielone (wiele raportów/modeli) → trzymaj je w Dataflows Gen2.
• Jeśli transformacje są częścią semantyki (miary, logika biznesowa w modelu, relacje) → trzymaj je w semantic modelu.
• Jeśli to „przygotowanie danych” (czyszczenie, standaryzacja, wzbogacanie) → skłaniaj się do Dataflows Gen2.
• Jeśli to „przygotowanie pod raport” (pomocnicze kolumny, szybkie iteracje) → skłaniaj się do semantic modelu.

Najczęstsze granice podziału logiki

• Dataflows Gen2: standaryzacja schematu, czyszczenie danych, deduplikacja, joiny/uniony, mapowania słownikowe, wspólne kolumny techniczne (np. daty, klucze).
• Semantic model: miary i definicje KPI, relacje i kierunki filtrowania, role/RLS, logika analityczna zależna od kontekstu filtrowania, prezentacja i semantyka pól.

Cel macierzy jest prosty: umieść transformacje tam, gdzie będą najczęściej używane i najrzadziej dublowane—przy czym „dane wspólne” wygrywają w warstwie Dataflows, a „znaczenie i metryki” w warstwie semantic modelu.

5. Scenariusze praktyczne (3 przykłady)

5.1 Mała firma: jeden zespół, kilka raportów, szybkie iteracje

Kontekst: 1–3 osoby od BI, kilka źródeł (np. Excel/CSV, prosty system sprzedażowy, Google Analytics), raporty budowane „od razu pod użytkownika”. Liczy się czas dostarczenia i prostota utrzymania.

Gdzie trzymać transformacje najczęściej? Zwykle w dataset/semantic modelu, bo jest najmniej elementów do utrzymania i najszybciej można przejść od danych do raportu.

• Dataset/semantic model: czyszczenie typów danych, podstawowe joiny, proste miary i logika biznesowa „na potrzeby raportu”.
• Dataflows Gen2: gdy pojawia się realna potrzeba ponownego użycia tych samych przygotowanych tabel w wielu raportach lub gdy warto wydzielić „staging” poza plik PBIX.

Sygnały, że wystarcza dataset: jedna wersja prawdy per raport, niewiele reużycia, częste zmiany wymagań, brak formalnego procesu wdrożeń.

Sygnały, że warto dołożyć Dataflows Gen2: rośnie liczba raportów korzystających z tych samych tabel, pojawiają się konflikty definicji (np. „sprzedaż netto” liczona inaczej w każdym raporcie), a zespół chce mieć jedno miejsce przygotowania danych.

5.2 Średnia organizacja z kilkoma domenami: wspólne definicje i reużywalność

Kontekst: kilka zespołów raportowych (np. sprzedaż, finanse, logistyka), różne źródła, rośnie potrzeba spójnych definicji oraz współdzielenia danych między raportami.

Typowy podział odpowiedzialności: Dataflows Gen2 przejmuje przygotowanie danych „wspólnych” (powtarzalnych), a semantic model skupia się na warstwie semantycznej i dopasowaniu do konkretnego użycia.

• Dataflows Gen2: standardyzacja wymiarów (np. kalendarz, produkty, klienci), harmonizacja formatów, podstawowe reguły jakości danych, przygotowanie tabel faktów w układzie użytecznym dla wielu modeli.
• Dataset/semantic model: relacje, miary, definicje KPI, perspektywy „pod dział”, ewentualnie wąskie transformacje specyficzne dla jednego modelu (np. filtr domenowy, mapowanie unikalne dla danego raportu).

Efekt: mniej dublowania Power Query w wielu datasetach i łatwiejsze utrzymanie wspólnych definicji, przy zachowaniu elastyczności w modelach domenowych.

5.3 Enterprise z Fabric: warstwowa architektura i kontrola zmian

Kontekst: wiele zespołów, duża liczba raportów, formalne środowiska (dev/test/prod), wymagania audytowe i wydajnościowe. Dane są konsumowane nie tylko przez Power BI, ale też przez inne narzędzia analityczne.

Dominujące podejście: logika ETL/ELT jest w dużej mierze wynoszona poza modele do warstw przygotowania danych (często Dataflows Gen2 jako element pipeline’u), a semantic models mają możliwie stabilny, „czysty” kontrakt semantyczny.

• Dataflows Gen2: przygotowanie zestandaryzowanych tabel do wielokrotnego użytku, uruchamiane i nadzorowane jako część przepływów danych w Fabric; redukcja powielania transformacji w setkach modeli.
• Dataset/semantic model: modelowanie gwiazdy, miary, reguły biznesowe na poziomie semantyki, bezpieczeństwo i prezentacja danych dla użytkowników końcowych.

Praktyczna konsekwencja: zmiana w transformacji wspólnej (np. klasyfikacja produktu) jest wprowadzana raz w warstwie przygotowania danych i propaguje się do wielu modeli, zamiast być kopiowana w każdej definicji datasetu.

5.4 Szybkie porównanie scenariuszy

6. Rekomendacje wdrożeniowe: wzorce architektury, dobre praktyki i typowe pułapki

Najlepsze wdrożenia rzadko wybierają wyłącznie Dataflows Gen2 albo wyłącznie transformacje w datasetach/semantic modelu. Zwykle sprawdza się podejście warstwowe: Dataflows Gen2 dla przygotowania i standaryzacji danych (ETL/ELT „wspólne dla wielu odbiorców”), a semantic model dla logiki stricte analitycznej (miary, relacje, kalkulacje raportowe) oraz niewielkich, lokalnych dopasowań.

Wzorce architektury (sprawdzone układy)

• „Shared staging + thin semantic models”: Dataflows Gen2 budują ustandaryzowane tabele (np. w Lakehouse/Warehouse), a wiele cienkich modeli semantycznych konsumuje je bez powielania Power Query. Dobre, gdy jest wiele raportów i zespołów.
• „Domain data products”: każdy obszar biznesowy publikuje własne, kontraktowe zestawy danych (curated) przez Dataflows Gen2, a modele semantyczne łączą domeny tam, gdzie to potrzebne. Minimalizuje spory o definicje i ułatwia własność danych.
• „Model-centric (dataset-first)”: transformacje w semantic modelu tylko wtedy, gdy dotyczą konkretnego raportu/modelu i nie mają wartości reużywalnej. Prostsze w małych środowiskach, ale ryzykuje duplikację, gdy liczba modeli rośnie.
• „ETL w Dataflows, semantyka w modelu” (najczęstsze): Dataflows Gen2 robią czyszczenie, typy, klucze, podstawowe reguły biznesowe; model robi relacje, miary DAX, role bezpieczeństwa. Jasny podział odpowiedzialności.

Dobre praktyki (co ustalić i konsekwentnie stosować)

• Definicja granicy odpowiedzialności: spisz zasady typu „co jest transformacją wspólną” (Dataflows Gen2) vs „co jest logiką raportową” (semantic model). Bez tego ETL zacznie „przeciekać” między warstwami.
• Jedno źródło prawdy dla transformacji reużywalnych: jeśli dana reguła (np. mapowanie statusów, normalizacja kodów, oczyszczanie dat) jest używana w więcej niż jednym modelu/raporcie, przenieś ją do Dataflows Gen2 lub warstwy curated.
• Konwencje nazewnictwa i kontrakty danych: nazwy tabel/kolumn, typy, znaczenie pól, klucze biznesowe i techniczne. Minimalizuje „drobne różnice”, które generują dług techniczny.
• „Mało Power Query w modelu, dużo w warstwie danych” (gdy rośnie skala): ogranicz Power Query w semantic modelu do lekkich operacji i parametrów; cięższe przekształcenia zostaw upstream, gdzie łatwiej je współdzielić i monitorować.
• Wspólne artefakty pomocnicze: tabele kalendarza, mapowania, słowniki, lookupy – utrzymuj centralnie (dataflow/curated), a nie kopiuj w każdym modelu.
• Parametryzacja środowisk: projektuj ścieżki i połączenia tak, by Dev/Test/Prod różniły się konfiguracją, a nie logiką. Unikniesz „ręcznych poprawek” przed publikacją.
• Separacja uprawnień: ETL (Dataflows Gen2) często wymaga szerszego dostępu do źródeł; modele semantyczne – dostępu do danych już oczyszczonych. Rozdzielenie zmniejsza ryzyko i ułatwia audyt.
• Minimalizacja duplikacji obliczeń: jeśli ta sama kolumna wyliczana pojawia się w kilku modelach, przenieś ją upstream; jeśli to miara zależna od kontekstu raportu, trzymaj ją w modelu.
• Kontrola zmian: wprowadzaj zmiany w ETL z myślą o kompatybilności (np. nie zmieniaj typów i nazw „w locie” bez planu migracji). Drobne zmiany upstream potrafią „wysypać” wiele raportów.

Typowe pułapki (co najczęściej dubluje pracę)

• „Kopiuj-wklej” Power Query między modelami: na początku szybkie, później nie do utrzymania. Jedna poprawka wymaga wielu identycznych zmian.
• Transformacje mieszane bez zasad: część reguł w Dataflows, część w modelu, część w raporcie – i nikt nie wie, gdzie jest „prawdziwa” definicja. Skutek: rozjazdy KPI.
• Przepychanie semantyki do ETL: np. tworzenie wielu „wariantów” tych samych tabel tylko pod różne raporty. Lepiej budować stabilne dane bazowe i różnicować analizę w modelu.
• Za ciężkie modele przez ETL w datasetach: skomplikowane łączenia, rozbudowane kroki Power Query i logika przygotowania danych w każdym modelu osobno. Skutkuje długimi odświeżeniami i trudnym debugowaniem.
• Brak warstwy pośredniej: bez „staging/curated” często rośnie liczba ad-hoc transformacji w modelach, bo nie ma wygodnego miejsca na wspólne czyszczenie danych.
• Niejawne zależności: raporty zależne od kolumn „tymczasowych” lub przypadkowych formatów. Po optymalizacji ETL znikają pola i powstaje lawina poprawek.
• Ignorowanie kosztu zmian: zmiana w Dataflows Gen2 może dotknąć wielu odbiorców; zmiana w modelu dotyka zwykle mniej. Bez procesu komunikacji i wersjonowania łatwo o przestoje.

Szybkie wskazówki „gdzie umieszczać logikę” (praktyczna heurystyka)

Uzupełnienie: mały wzorzec „wspólnej funkcji” w Power Query

Jeśli tymczasowo musisz zostać przy transformacjach w modelu, ogranicz dublowanie przez wydzielenie funkcji i jej użycie w kilku zapytaniach (do czasu przeniesienia upstream).

// Funkcja do normalizacji kodu produktu
(normalize as text) as text =>
let
    t = Text.Upper(Text.Trim(normalize)),
    t2 = Text.Replace(t, " ", "")
in
    t2

Taki zabieg nie zastąpi warstwy wspólnego ETL, ale zmniejsza ryzyko rozjazdów w obrębie jednego modelu.

Podsumowanie: szybkie wskazówki wyboru i checklist do podjęcia decyzji

Najkrócej: Dataflows Gen2 to dobre miejsce na logikę ETL, gdy chcesz budować i utrzymywać wspólną warstwę przygotowania danych dla wielu modeli i raportów. Transformacje w datasetach/semantic modelu sprawdzają się, gdy logika ma być blisko analityki, jest specyficzna dla jednego modelu i ma służyć przede wszystkim spójnej semantyce (miary, relacje, perspektywy) oraz szybkiemu iterowaniu.

Kluczowa różnica praktyczna: umieszczenie transformacji w Dataflows Gen2 sprzyja re-używalności i standaryzacji, a w semantic modelu sprzyja zwinności i lokalnej kontroli w obrębie jednego zestawu danych. Tam, gdzie istnieje ryzyko dublowania tych samych kroków przygotowania danych w wielu modelach, Dataflows Gen2 zwykle ograniczają powtórzenia; tam, gdzie zmiany są częste i silnie zależne od konkretnego raportowania, semantic model bywa prostszy.

Szybkie wskazówki wyboru

• Wybierz Dataflows Gen2, gdy te same dane i transformacje mają zasilać wiele modeli lub zespołów, a celem jest jedna „wersja prawdy” na etapie przygotowania danych.
• Wybierz transformacje w semantic modelu, gdy to pojedynczy model jest produktem, a transformacje są wąskie, specyficzne dla kontekstu analitycznego i chcesz minimalizować liczbę zależności.
• Unikaj dublowania logiki: jeśli ten sam krok (np. czyszczenie, mapowania, standaryzacja) pojawia się w kilku miejscach, przenieś go wyżej do wspólnej warstwy albo ujednolić jego źródło.
• Oddziel ETL od semantyki: ETL koncentruje się na jakości i kształcie danych, a semantic model na znaczeniu biznesowym, relacjach i logice miar.
• Myśl o odpowiedzialnościach: jeżeli za przygotowanie danych odpowiada inna rola/zespoły niż za model, Dataflows Gen2 zwykle ułatwiają podział pracy.

Checklist: pytania, które warto sobie zadać przed decyzją

• Reużywalność: czy te transformacje mają być używane w więcej niż jednym modelu/raporcie?
• Ryzyko rozjazdu definicji: czy ta sama definicja (np. kategorie, flagi, mapowania) musi być identyczna w wielu miejscach?
• Częstotliwość zmian: czy logika będzie często modyfikowana przez analityków w cyklu raportowym, czy raczej jest stabilna i „inżynieryjna”?
• Granice odpowiedzialności: kto ma utrzymywać transformacje — zespół od danych czy zespół od modelu i raportów?
• Monitoring i utrzymanie: gdzie łatwiej będzie wykrywać awarie, regresje jakości i kontrolować wpływ zmian?
• Wydajność i koszty: czy bardziej opłaca się przetwarzać dane raz wspólnie, czy lokalnie w modelu (z uwzględnieniem liczby odbiorców i odświeżeń)?
• Uprawnienia i dostęp: czy przygotowanie danych wymaga szerszego/ciaśniejszego dostępu niż budowa modelu?
• Izolacja środowisk: czy potrzebujesz wyraźnego podziału na dev/test/prod i kontrolowanego promowania zmian?
• Kompetencje zespołu: gdzie zespół czuje się pewniej w utrzymaniu logiki — w warstwie przygotowania danych czy w modelu semantycznym?
• Minimalizacja długów technicznych: czy wybrane miejsce ograniczy liczbę „prawie takich samych” transformacji utrzymywanych równolegle?

Jeśli po przejściu checklisty najczęściej odpowiadasz „wiele modeli”, „jedna definicja”, „stabilna logika” — skłaniaj się ku Dataflows Gen2. Jeśli dominują odpowiedzi „jeden model”, „szybkie iteracje”, „logika specyficzna dla raportu” — wybór transformacji w semantic modelu będzie zwykle bardziej naturalny.

8. Przykład UDF end-to-end: implementacja, użycie w zapytaniu oraz refaktoryzacja pod czytelność i wydajność

UDF (user-defined function) w praktyce pomaga przenieść powtarzalną logikę transformacji do jednego, kontrolowanego miejsca. Dzięki temu zamiast kopiować te same kroki w wielu zapytaniach (czy to w Dataflows Gen2, czy w transformacjach modelu semantycznego), budujesz mały „klocek” ETL, który można wywołać tam, gdzie jest potrzebny. To nie rozstrzyga jeszcze, gdzie trzymać całą logikę (to temat porównania podejść), ale pokazuje mechanizm, który minimalizuje dublowanie pracy niezależnie od warstwy.

End-to-end w tym kontekście oznacza trzy kroki: implementacja UDF, użycie jej w zapytaniu oraz refaktoryzacja tak, aby była czytelna i nie degradowała wydajności. Najczęściej UDF przydaje się do:

• Standaryzacji wartości (np. czyszczenie tekstu, normalizacja formatów, mapowanie statusów).
• Walidacji i oznaczania rekordów (np. flagi błędów, reguły jakości danych, klasyfikacje).
• Wspólnej logiki biznesowej, która powinna być identyczna w wielu miejscach (np. klasy segmentów, kanałów, typów transakcji).

Implementacja: sensowny UDF jest możliwie mały, z jasno zdefiniowanym wejściem i wyjściem oraz przewidywalnym zachowaniem dla wartości brakujących. Kluczowe jest, by od razu ustalić „kontrakt”: jakie typy danych przyjmuje, co zwraca, i jak traktuje wartości null/puste/niepoprawne. Na tym etapie warto też zdecydować, czy funkcja ma być stricte „czyszcząca” (zwraca poprawioną wartość), czy „diagnostyczna” (zwraca wynik wraz z informacją o błędzie). Te decyzje wpływają na to, czy UDF będzie wygodna w raportowaniu oraz jak łatwo będzie ją utrzymać.

Użycie w zapytaniu: typowy wzorzec polega na zastosowaniu UDF do wybranych kolumn w trakcie transformacji tabeli. Z perspektywy użytkownika zapytania ważne jest, aby UDF była używana konsekwentnie: w tych samych miejscach przepływu danych (np. zawsze po zmianie typów, a przed łączeniami), tak aby ograniczyć sytuacje, w których ta sama reguła działa raz „przed”, a raz „po” innym kroku. To ogranicza rozjazdy wyników i ułatwia debugging.

Refaktoryzacja pod czytelność: największym wrogiem utrzymania jest „funkcja-śmietnik”, do której z czasem dopisywane są kolejne wyjątki. Czytelność poprawisz, gdy:

• Rozdzielisz odpowiedzialności: osobno funkcje do czyszczenia, osobno do klasyfikacji, osobno do walidacji.
• Nazwiesz funkcje i parametry zgodnie z domeną (co opisują), a nie techniką (jak są zrobione).
• Ustalisz spójne zachowanie dla błędów (np. zwracanie null vs zwracanie wartości domyślnej) i będziesz je konsekwentnie stosować.

Refaktoryzacja pod wydajność: UDF może być źródłem spowolnień, gdy jest wywoływana wiersz po wierszu bez kontroli nad kosztami lub gdy powoduje utratę optymalizacji zapytania. Żeby temu zapobiec, w praktyce stosuje się kilka zasad:

• Minimalizuj pracę w UDF: jeśli da się przenieść część logiki do prostych, jednorazowych kroków na całej kolumnie, często będzie to tańsze niż skomplikowane operacje per rekord.
• Unikaj efektów ubocznych i zależności od kontekstu: funkcja ma być deterministyczna, aby wyniki były stabilne i łatwe do cache’owania.
• Stosuj wczesne odfiltrowanie danych: jeżeli UDF ma sens tylko dla części rekordów (np. tylko dla konkretnego typu), ogranicz zakres zastosowania jak najwcześniej.
• Dbaj o typy i null-e: niejawne konwersje i „naprawy” typów w środku funkcji potrafią generować dodatkowe koszty i komplikować ścieżkę przetwarzania.

Najważniejsza wartość UDF w kontekście „Dataflows Gen2 vs transformacje w modelu” jest praktyczna: odseparowanie reguły od miejsca jej użycia. Dzięki temu decyzja o tym, czy dana transformacja ma żyć bliżej źródła (w przepływie danych), czy bliżej konsumpcji (w modelu semantycznym), nie musi oznaczać przepisywania całej logiki od zera — przenosisz i adaptujesz klocki, zamiast kopiować kroki. Jednocześnie warto pamiętać, że UDF nie jest „lekiem na wszystko”: jeśli funkcja staje się zbyt rozbudowana albo jest stosowana bez kontroli do bardzo dużych wolumenów, może utrudnić diagnostykę i obniżyć wydajność.

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

Claude Code w zespole: jak wdrożyć AI bez chaosu w repozytorium 29 maja 2026

Testy z Claude Code: jak przyspieszyć QA bez obniżania jakości 27 maja 2026