Prefect 3, przepływy w Pythonie i model hybrydowy

Prefect 3, przepływy w Pythonie i model hybrydowy

Prefect to narzędzie do orkiestracji przepływów pracy: uruchamiania zadań w ustalonej kolejności, ponawiania ich przy błędzie, planowania w czasie i pokazywania, co się wydarzyło. Bieżące wydanie z końca lipca 2026 nosi numer 3.8, licencja to Apache 2.0, a wymagany Python mieści się w przedziale od 3.10 do 3.14.

Dwie rzeczy odróżniają je od narzędzi z tej kategorii na tyle, że warto zacząć od nich: sposób opisywania przepływu i sposób rozdzielenia sterowania od wykonania.

Przepływ to funkcja, nie graf

W klasycznym podejściu opisujesz graf zadań w osobnym pliku, zwykle w formacie narzuconym przez narzędzie, i dopiero ten graf wywołuje Twój kod. Tutaj nie ma osobnego pliku ani osobnego formatu.

from prefect import flow, task

@task(retries=3, retry_delay_seconds=30)
def pobierz_dane(zrodlo: str) -> list[dict]:
    return klient.pobierz(zrodlo)

@task
def przeksztalc(wiersze: list[dict]) -> list[dict]:
    return [normalizuj(w) for w in wiersze]

@flow(name="import-dzienny")
def importuj(zrodla: list[str]):
    for zrodlo in zrodla:
        dane = pobierz_dane(zrodlo)
        przeksztalc(dane)

Dekorator zamienia zwykłą funkcję w zadanie, a inny w przepływ. Struktura wynika z tego, jak funkcje się wywołują, więc pętla jest pętlą, warunek warunkiem, a wyjątek wyjątkiem.

Konsekwencja praktyczna jest większa, niż wygląda. Przepływ da się wywołać w teście jak zwykłą funkcję, bez uruchamiania planisty i bez środowiska. Zadanie da się przetestować osobno. Kod nadaje się do przeczytania przez osobę, która tego narzędzia nie zna.

Cena polega na tym, że struktura przepływu jest znana dopiero w trakcie wykonania. Przy grafie opisanym z góry wiadomo przed startem, co się wydarzy, a tutaj wiadomo po. Przy rozgałęzieniach zależnych od danych to jest zaleta, przy potrzebie pokazania planu przed uruchomieniem raczej wada.

Model hybrydowy

To jest druga rzecz warta zrozumienia i główny argument w rozmowie z działem bezpieczeństwa.

Warstwa sterująca, czyli planowanie, śledzenie stanu i interfejs, może działać w chmurze dostawcy. Wykonanie odbywa się na Twojej infrastrukturze: Twoim klastrze, Twojej maszynie, Twoim koncie chmurowym.

Znaczy to, że dane nie przechodzą przez dostawcę. Do warstwy sterującej trafiają metadane: nazwa zadania, czas trwania, stan, komunikat błędu. Sama zawartość przetwarzanych rekordów zostaje tam, gdzie była.

To jest różnica, która przesądza w sytuacjach, gdzie zewnętrzny orkiestrator normalnie by nie przeszedł. Zespół przetwarzający dane osobowe albo finansowe może korzystać z zarządzanej warstwy sterującej, bo ona tych danych nie widzi.

Warto natomiast wiedzieć, gdzie ta granica przebiega w praktyce. Komunikat błędu z wyjątkiem zawierającym fragment danych trafi do warstwy sterującej razem ze śladem stosu. Podobnie dziennik zapisany przez Twój kod. To jest miejsce, w którym trzeba uważać, bo domyślne zachowanie potrafi przenieść więcej, niż zakładasz.

Pule robocze i uruchamianie

Pula robocza to opis miejsca, w którym mają wykonywać się przepływy: klaster kontenerowy, usługa uruchamiająca kontenery w chmurze, środowisko bezserwerowe albo zwykły proces na maszynie.

Rozdzielenie definicji przepływu od miejsca wykonania jest tu praktyczne. Ten sam kod uruchamia się lokalnie przy pracy deweloperskiej i w klastrze na produkcji, bez zmiany czegokolwiek w samym przepływie. Zmienia się pula, a nie kod.

Warto rozumieć, jak to działa pod spodem, bo od tego zależy diagnozowanie problemów. Proces roboczy odpytuje warstwę sterującą o zadania do wykonania, pobiera je i uruchamia. Przepływ, który nie startuje, ma zwykle jedną z trzech przyczyn: nie ma działającego procesu roboczego, proces obsługuje inną pulę albo nie ma dostępu do kodu przepływu.

To ostatnie zaskakuje najczęściej. Warstwa sterująca wie, że przepływ ma się uruchomić, i nie ma jego kodu. Kod musi być dostępny dla procesu roboczego: w obrazie kontenera, w repozytorium pobieranym przy starcie albo w magazynie plików. Konfiguracja tego jest osobnym krokiem, o którym łatwo zapomnieć przy pierwszym wdrożeniu.

Ponawianie, stan i to, co daje orkiestrator

Warto nazwać, za co właściwie się tu płaci, bo pętla z zadaniami da się napisać samodzielnie w pół dnia.

Ponawianie z opóźnieniem jest deklaracją przy zadaniu, a nie kodem w środku. Zadanie sięgające po zewnętrzny interfejs, który bywa niedostępny, dostaje trzy próby z odstępem, i to jest jedna linia.

Buforowanie wyników pozwala pominąć zadanie, którego wynik już znamy. Przy przepływie, który przerwał się w połowie, ponowne uruchomienie nie powtarza kroków zakończonych powodzeniem, o ile ich wejście się nie zmieniło.

Współbieżność jest ograniczana deklaratywnie. Zadanie sięgające do bazy, która nie zniesie stu równoległych połączeń, dostaje limit, a orkiestrator pilnuje, żeby nie przekroczyć go niezależnie od tego, ile przepływów działa naraz.

Widoczność stanu jest tym, czego przy własnym rozwiązaniu brakuje najbardziej. Pytanie „czy nocny import przeszedł" ma tu odpowiedź na ekranie, a przy skrypcie w harmonogramie systemowym wymaga zaglądania do dzienników.

Ostatnia rzecz to powiadamianie. Reguła mówiąca, że nieudany przepływ ma wysłać wiadomość na wskazany kanał, jest konfiguracją, a nie kodem w bloku obsługi wyjątku.

Wdrożenia i harmonogramy

Przepływ napisany w edytorze to jeszcze nie jest coś, co uruchamia się samo. Trzeba go wdrożyć, czyli powiedzieć warstwie sterującej, gdzie leży kod, kiedy ma startować i w jakiej puli.

Wdrożenie opisuje się w pliku konfiguracyjnym trzymanym w repozytorium, obok kodu. To jest właściwe podejście, bo definicja przechodzi przegląd jak każda inna zmiana, a odtworzenie środowiska na nowym koncie sprowadza się do jednego polecenia.

Harmonogram może być wyrażeniem czasowym, odstępem albo regułą uwzględniającą strefę czasową i dni wolne. Ta ostatnia rzecz bywa niedoceniana, dopóki nie okaże się, że nocny import uruchamia się o godzinę wcześniej po zmianie czasu i wchodzi w okno serwisowe bazy.

Poza harmonogramem przepływ da się uruchomić zdarzeniem: pojawieniem się pliku, wywołaniem interfejsu albo zakończeniem innego przepływu. Ten ostatni wariant zastępuje sztuczne opóźnienia, którymi ludzie zwykle łączą zadania w harmonogramie systemowym, i jest jedną z rzeczy, dla których w ogóle sięga się po orkiestrator.

Warto też ustalić, co się dzieje przy nakładaniu przebiegów. Przepływ uruchamiany co pięć minut, który czasem trwa siedem, będzie miał dwa przebiegi naraz, a przy zapisie do tej samej tabeli to zwykle nie jest to, o co chodziło. Ograniczenie współbieżności na poziomie wdrożenia rozwiązuje to jedną deklaracją.

Obserwowalność i diagnozowanie

Sam zapis stanu to podstawa, a przy dłuższej pracy przydaje się kilka rzeczy więcej.

Znaczniki nadawane przepływom i zadaniom pozwalają filtrować przebiegi po obszarze, zespole albo środowisku. Bez nich lista przebiegów po miesiącu jest ścianą wpisów, po której nie da się nawigować.

Artefakty pozwalają dopisać do przebiegu tabelę, wykres albo notatkę widoczną w interfejsie. Przy przetwarzaniu danych to jest wygodne miejsce na raport: ile rekordów weszło, ile odrzucono i dlaczego. Osoba sprawdzająca, czy import przeszedł, dostaje odpowiedź bez zaglądania do dzienników.

Stany przejściowe warto rozumieć, bo diagnoza często sprowadza się do rozróżnienia dwóch podobnych sytuacji. Przepływ oczekujący na wolne miejsce w puli wygląda podobnie do przepływu, którego nikt nie podjął, a przyczyny są zupełnie inne i naprawia się je gdzie indziej.

Przy aplikacjach opartych o modele językowe warto połączyć ten zapis ze śledzeniem wywołań modelu, na przykład przez Arize Phoenix. Orkiestrator pokazuje, że zadanie się wykonało, a narzędzie śledzące pokazuje, co poszło do modelu i co wróciło. Jedno bez drugiego zostawia lukę.

Prefect kontra alternatywy

Ostatni wiersz warto rozważyć uczciwie, bo bywa pomijany z powodów, które nie są techniczne. Trzy zadania uruchamiane raz na dobę, z powiadomieniem na wypadek błędu, nie wymagają orkiestratora. Wprowadzenie go oznacza kolejną usługę do utrzymania i kolejne miejsce, w którym coś może paść.

Granica przebiega przy zależnościach między zadaniami i przy potrzebie wiedzy o tym, co się wydarzyło. Gdy zadanie B ma poczekać na A, a przy błędzie C trzeba wiedzieć, które rekordy przeszły, harmonogram systemowy przestaje wystarczać.

Trzeci wiersz rozwiązuje inny problem i mylenie ich jest częste. Tam chodzi o procesy trwające dniami, z gwarancją, że stan przetrwa awarię procesu. Tutaj o powtarzalne przetwarzanie danych z widocznością i ponawianiem.

Czwarty wiersz przesuwa się po tej samej osi co pierwszy, tylko w drugą stronę. Przepływ opisany w YAML przeczyta osoba, która w Pythonie nie pisze, a same zadania mogą być w dowolnym języku, więc przy zespole mieszanym bywa to ważniejsze niż wygoda testowania funkcji. Cena jest podwójna: rozbudowana logika sterująca w dokumencie robi się nieczytelna szybciej, niż wynikałoby z liczby linii, a garść wtyczek jest zastrzeżona dla edycji komercyjnej.

Cennik i uruchomienie u siebie

Licencja jest otwarta, więc pełne uruchomienie u siebie jest dostępne bez opłat. Potrzebujesz warstwy sterującej, bazy danych, na przykład PostgreSQL, oraz co najmniej jednego procesu roboczego.

Wariant zarządzany ma próg darmowy o nazwie Hobby, ograniczony do dwóch użytkowników i pięciu wdrożeń. Po dobiciu do piątego wdrożenia nie utworzysz kolejnego, dopóki nie skasujesz istniejącego albo nie przejdziesz na plan płatny, więc jest to twardy limit, a nie miękki próg z dopłatą.

Plany płatne mają dwa różne kształty stawki i to jest rzecz, którą łatwo przeoczyć przy szybkim spojrzeniu na cennik. Starter kosztuje 100 dolarów miesięcznie za całe konto z trzema użytkownikami i dwudziestoma wdrożeniami. Team to również 100 dolarów, ale za każdego użytkownika miesięcznie, z czterema w pakiecie wyjściowym, więc rachunek rośnie razem z zespołem, a nie stoi w miejscu. Plany Pro i Enterprise mają wycenę indywidualną i rozliczenie roczne. Warto sprawdzić aktualny cennik u dostawcy, bo progi i limity zmieniają się częściej niż sama architektura.

Ważniejsza od stawki jest zasada rozliczania. Płacisz za miejsca w zespole i przestrzenie robocze, a nie za wykonania zadań ani za zużytą moc obliczeniową, co przy przepływach uruchamianych często zmienia rachunek zasadniczo wobec narzędzi naliczających za przebieg. Aplikacja wykonująca dziesiątki tysięcy zadań dziennie nie kosztuje tu więcej niż wykonująca setki. Sufit jest gdzie indziej: w liczbie użytkowników i wdrożeń przypisanej do planu, od pięciu wdrożeń na progu darmowym, przez dwadzieścia i sto, po tysiąc na planie Pro. Osobno warto spojrzeć na okres przechowywania przebiegów, bo na dwóch najniższych planach historia znika po siedmiu dniach.

Przy wyborze między wariantem własnym a zarządzanym policz pracę operacyjną. Warstwa sterująca to usługa, która musi działać, mieć kopie zapasowe i być aktualizowana, a jej awaria zatrzymuje planowanie wszystkich przepływów. Przy zespole bez osoby zajmującej się infrastrukturą wariant zarządzany zwykle wychodzi taniej niż wynikałoby z porównania stawek.

Typowe błędy

Pierwszy to brak dostępu procesu roboczego do kodu przepływu. Warstwa sterująca wie, że przepływ ma wystartować, i nie ma czego uruchomić, a objaw wygląda jak zadanie wiszące w kolejce.

Drugi to proces roboczy obsługujący inną pulę niż ta, do której trafiło zadanie. Wszystko jest skonfigurowane poprawnie i nic się nie dzieje.

Trzeci to przenoszenie danych do warstwy sterującej przez dzienniki i komunikaty błędów. Model hybrydowy chroni dane przetwarzane, a nie te, które sam wpiszesz do dziennika.

Czwarty to brak ograniczenia współbieżności przy zadaniach sięgających do wspólnego zasobu. Sto równoległych zadań uderzających w jedną bazę potrafi ją położyć, a orkiestrator z przyjemnością je uruchomi.

Piąty to buforowanie wyników bez przemyślenia klucza. Zadanie uznane za wykonane, bo wejście wygląda tak samo, pomija przetwarzanie danych, które w międzyczasie się zmieniły.

Szósty to wprowadzanie orkiestratora do trzech zadań uruchamianych raz na dobę. Dochodzi usługa do utrzymania, a zyskuje się widoczność, której przy tej skali nikt nie potrzebuje.

FAQ

Czym Prefect różni się od Airflow?

Sposobem opisania przepływu. Tutaj przepływ jest zwykłą funkcją z dekoratorem, więc pętle i warunki są pętlami i warunkami, a testowanie sprowadza się do wywołania funkcji. Airflow opisuje graf osobno, co daje znajomość struktury przed uruchomieniem kosztem większej ilości rzeczy do nauczenia.

Czym jest model hybrydowy?

Rozdzieleniem sterowania od wykonania. Planowanie, śledzenie stanu i interfejs mogą działać w chmurze dostawcy, a zadania wykonują się na Twojej infrastrukturze, więc dane nie przechodzą przez dostawcę. Do warstwy sterującej trafiają metadane, a nie zawartość przetwarzanych rekordów.

Czy da się uruchomić to u siebie w całości?

Tak, licencja jest otwarta i pełne wdrożenie własne jest dostępne bez opłat. Potrzebujesz warstwy sterującej, bazy danych i co najmniej jednego procesu roboczego, a w zamian bierzesz na siebie kopie zapasowe i aktualizacje tej usługi.

Dlaczego mój przepływ wisi w kolejce?

Najczęściej z jednego z trzech powodów: nie działa żaden proces roboczy, działający obsługuje inną pulę, albo nie ma dostępu do kodu przepływu. To ostatnie zaskakuje najczęściej, bo warstwa sterująca zna harmonogram, a kodu nie przechowuje.

Jak liczony jest koszt wariantu zarządzanego?

Za miejsca w zespole i przestrzenie robocze, a nie za wykonania zadań, więc liczba przebiegów przestaje wpływać na cenę. Zwróć uwagę na kształt stawki: plan Starter to 100 dolarów miesięcznie za całe konto, a plan Team to 100 dolarów miesięcznie za każdego użytkownika. Każdy plan ma też własny limit liczby wdrożeń, od pięciu na progu darmowym po tysiąc na planie Pro.

Dokumentacja stoi na stronie projektu, a kod i wydania w repozytorium na GitHubie.