Apache Airflow w praktyce: kiedy firma potrzebuje orkiestracji danych?

Najważniejsza odpowiedź

Apache Airflow jest platformą do definiowania, uruchamiania i nadzorowania procesów składających się z wielu zależnych od siebie zadań.

Najczęściej wykorzystuje się go do orkiestracji procesów danych: pobierania informacji z systemów źródłowych, ładowania ich do data lake lub hurtowni, uruchamiania transformacji, kontroli jakości oraz publikowania wyników do raportów i aplikacji.

Airflow nie jest jednak silnikiem przetwarzania danych. Nie zastępuje hurtowni, Apache Spark, dbt, systemu kolejkowego ani platformy streamingowej. Nie jest też magiczną skrzynką, do której wkłada się chaos, a wyjmuje dojrzałą platformę danych.

Jego rolą jest koordynowanie pracy wykonywanej przez inne systemy.

Wdrożenie Airflow ma sens, gdy firma potrzebuje:

• jawnych zależności pomiędzy procesami;
• kontrolowanych ponowień po awarii;
• odtwarzania danych historycznych;
• centralnego monitorowania wykonania;
• audytowalności procesów;
• koordynacji pracy wielu niezależnych systemów.

Jeżeli firma ma trzy proste skrypty uruchamiane raz dziennie, a największym incydentem ostatniego roku było wygaśnięcie hasła do FTP, Airflow może być niepotrzebnym narzutem.

Problem, który rozwiązuje, powinien być większy niż koszt utrzymania samej platformy. To zasada prosta, choć zaskakująco często odkrywana dopiero po wdrożeniu Kubernetes.

Airflow odpowiada na problem operacyjny, nie tylko techniczny

Firmy rzadko zaczynają od potrzeby wdrożenia orkiestratora. Zwykle zaczynają od kilku skryptów.

Pierwszy pobiera dane z API. Drugi ładuje pliki do storage. Trzeci wykonuje transformacje SQL. Czwarty aktualizuje raport. Piąty powstał „tymczasowo” trzy lata temu i nikt nie wie, kto jest jego właścicielem.

Każdy z nich może być uruchamiany przez cron lub harmonogram dostępny w usłudze chmurowej. Taki model działa, dopóki procesy są małe, stabilne i niezależne.

Później zazwyczaj dzieje się jedno z poniższych:

• transformacja uruchamia się, mimo że import danych nie został zakończony;
• awaria jednego systemu wymaga ręcznego wznowienia kilku kolejnych procesów;
• nie wiadomo, czy raport prezentuje kompletne dane;
• ponowne przetworzenie poprzedniego miesiąca wymaga stworzenia specjalnego skryptu;
• kilka zespołów jednocześnie przeciąża tę samą bazę;
• logi znajdują się w pięciu systemach, z czego dwa są „tymczasowe”;
• osoba, która znała kolejność uruchamiania zadań, jest akurat na urlopie.

W takim środowisku problemem nie jest brak kolejnego skryptu. Problemem jest brak centralnego modelu wykonania.

Airflow staje się wtedy warstwą sterującą, która odpowiada na pytania:

• Co powinno zostać uruchomione?
• W jakiej kolejności?
• Na podstawie jakich danych?
• Co zrobić po błędzie?
• Jak bezpiecznie powtórzyć proces?
• Jak sprawdzić, które dane zostały już przetworzone?
• Kogo obudzić o 03:17 i czy na pewno trzeba?

Airflow jako control plane dla procesów danych

Najlepiej myśleć o Airflow jak o control plane, czyli warstwie sterującej.

Platforma przechowuje definicje workflow, zależności, statusy wykonania i metadane operacyjne. Następnie zleca właściwym systemom wykonanie konkretnych operacji.

Przykładowy proces może wyglądać następująco:

Airflow pilnuje, aby transformacja nie rozpoczęła się przed załadowaniem danych, a publikacja tabel nie nastąpiła przed zakończeniem testów jakości.

Czyli robi dokładnie to, czego oczekiwalibyśmy od rozsądnego koordynatora projektu, tylko nie organizuje dodatkowych spotkań.

Ciężka praca wykonywana jest poza samym Airflow:

• zapytania SQL wykonuje hurtownia;
• modele dbt uruchamiają się na silniku bazy;
• duże obliczenia realizuje Spark;
• pliki przechowuje object storage;
• modele machine learning są trenowane na wyspecjalizowanej platformie;
• kontenery mogą działać na Kubernetesie.

Taki podział pozwala niezależnie skalować orkiestrację, storage i compute.

Jest to ważne również finansowo. Airflow nie powinien przenosić gigabajtów danych między taskami tylko dlatego, że technicznie ktoś znalazł sposób, aby to zrobić.

W inżynierii danych „da się” i „powinno się” to dwa osobne zbiory, które czasami nawet się przecinają.

Jak Airflow opisuje proces?

Podstawową jednostką organizacyjną Airflow jest DAG, czyli Directed Acyclic Graph.

DAG opisuje proces jako graf zadań oraz zależności pomiędzy nimi. Określa między innymi:

• zadania należące do procesu;
• kolejność wykonania;
• harmonogram lub warunek uruchomienia;
• liczbę ponowień;
• timeouty;
• reakcję na sukces albo awarię;
• ograniczenia współbieżności.

„Acyclic” oznacza, że zależności nie mogą tworzyć zamkniętej pętli.

Zadanie A może poprzedzać zadanie B, ale zadanie B nie może jednocześnie być warunkiem uruchomienia zadania A. Dzięki temu workflow pozostaje możliwy do wykonania, a nie staje się graficzną reprezentacją procesu akceptacji budżetu w dużej organizacji.

Kod DAG-a powinien opisywać sposób koordynacji. Nie powinien zawierać całej logiki biznesowej procesu.

Reguły transformacji, walidatory i integracje warto umieszczać w testowalnych modułach lub osobnych aplikacjach. Dzięki temu można rozwijać je bez konieczności traktowania każdego DAG-a jak monolitu napisanego przez pięć pokoleń zespołu danych.

Operator, task i task instance

Operator jest szablonem określonego rodzaju operacji. Może reprezentować wykonanie funkcji Pythona, zapytania SQL, polecenia systemowego albo zadania uruchamianego w kontenerze.

Task to operator skonfigurowany i umieszczony w konkretnym DAG-u.

Task instance oznacza pojedyncze wykonanie taska w ramach określonego uruchomienia procesu.

Definicja taska może być jedna, ale jego instancje będą wykonywane wielokrotnie: każdego dnia, dla każdego klienta, dla każdej partycji albo podczas ponownego przetwarzania historii.

To trochę jak z szablonem faktury i konkretną fakturą. Tylko w przypadku Airflow ponowne wystawienie tej samej faktury może być dokładnie tym problemem, którego próbujemy uniknąć.

Harmonogram nie zawsze oznacza konkretną godzinę

Airflow jest kojarzony głównie z harmonogramami czasowymi, ale współczesna platforma pozwala uruchamiać procesy także na podstawie danych i zdarzeń.

DAG może zostać uruchomiony:

• o określonej porze;
• po zakończeniu konkretnego przedziału danych;
• po aktualizacji wskazanego assetu;
• przez interfejs API;
• w wyniku zewnętrznego zdarzenia;
• ręcznie przez operatora.

Ostatnia możliwość jest szczególnie popularna chwilę po zdaniu: „Przecież niczego nie zmienialiśmy”.

Airflow może reagować na pojawienie się określonych danych albo sygnału z zewnętrznego systemu. Nie zmienia to jednak platformy w procesor strumieniowy.

Każde uruchomienie nadal reprezentuje ograniczony proces posiadający początek, koniec i stan wykonania.

Jeżeli firma musi reagować na każde zdarzenie w czasie liczonym w milisekundach lub sekundach, powinna użyć platformy streamingowej albo systemu kolejkowego.

Airflow może koordynować procesy wokół takiego systemu, ale nie powinien znajdować się bezpośrednio na ścieżce obsługi każdego kliknięcia użytkownika. Użytkownicy bywają niecierpliwi, a scheduler ma inne zainteresowania.

Dlaczego data intervals i backfille są istotne?

W procesach danych czas uruchomienia nie zawsze jest tym samym co okres, którego dotyczą dane.

Proces wykonywany 2 lipca o godzinie 01:00 może przetwarzać dane za cały 1 lipca. Airflow opisuje taki zakres jako data interval.

Dzięki temu można deterministycznie odpowiedzieć na pytanie:

Jaki zakres danych powinien zostać przetworzony przez to uruchomienie?

Ma to kluczowe znaczenie podczas backfillu, czyli odtwarzania brakujących lub historycznych przedziałów.

Przykładowo po naprawieniu błędu w logice finansowej firma może ponownie przetworzyć każdy dzień poprzedniego kwartału.

To dobry moment, aby przypomnieć sobie, że „mała korekta formuły” potrafi oznaczać ponowne przeliczenie kilku miliardów rekordów.

Airflow może utworzyć osobne uruchomienie dla każdego przedziału i ograniczyć liczbę aktywnych procesów. Sam mechanizm backfillu nie zapewnia jednak bezpieczeństwa. Zapewnia je dopiero odpowiednia konstrukcja tasków.

Najważniejsza właściwość produkcyjnego taska: idempotencja

Idempotentny task może zostać wykonany ponownie dla tego samego zakresu danych bez tworzenia duplikatów i bez uszkadzania wyniku.

To jedna z najważniejszych zasad projektowania procesów Airflow.

Załóżmy, że zadanie ma zapisać dane sprzedażowe za 1 lipca. Pierwsze wykonanie zapisuje połowę rekordów, po czym traci połączenie z bazą.

Jeżeli retry po prostu ponownie wykona operacje INSERT, część rekordów może zostać zapisana dwukrotnie.

W efekcie sprzedaż rośnie o 40 procent, zarząd jest zachwycony, a dział finansowy trochę mniej.

Bezpieczniejszy model może wykorzystywać:

• zapis do partycji przypisanej do konkretnego dnia;
• operację MERGE albo upsert;
• unikalne klucze biznesowe;
• zapis wyniku tymczasowego i atomową publikację;
• identyfikator uruchomienia;
• usuwanie niekompletnej partycji przed ponowieniem;
• kontrolę jakości przed udostępnieniem danych odbiorcom.

Retry jest mechanizmem odzyskiwania wykonania. Nie jest gwarancją poprawności danych.

Automatyczne powtórzenie błędnej operacji nie rozwiązuje problemu. Rozwiązuje jedynie problem braku konsekwencji.

Co powinno przechodzić pomiędzy taskami?

Taski Airflow mogą wykonywać się na różnych workerach, maszynach albo w osobnych kontenerach. Nie powinny zakładać dostępu do wspólnej pamięci lub lokalnego systemu plików.

Do wymiany niewielkich informacji Airflow udostępnia XCom.

Przez XCom można przekazać:

• identyfikator pliku;
• ścieżkę do obiektu w storage;
• nazwę utworzonej tabeli;
• numer przetworzonej partycji;
• status walidacji;
• identyfikator zewnętrznego joba.

Nie należy przekazywać przez XCom dużych DataFrame’ów, plików ani całych zbiorów danych.

XCom jest dobrym miejscem na informację:

Plik znajduje się tutaj.

Nie jest dobrym miejscem na:

Oto plik, jego kopia, DataFrame i trzy miliony rekordów na wszelki wypadek.

Większe wyniki powinny zostać zapisane w trwałym magazynie danych, natomiast XCom może zawierać ich adres albo identyfikator.

Dzięki temu dane biznesowe pozostają w systemie przeznaczonym do ich przechowywania, a Airflow nie zamienia swojej bazy metadanych w hurtownię, która nie wie, że jest hurtownią.

Jak wygląda architektura produkcyjnego Airflow?

Produkcyjne wdrożenie Airflow nie jest pojedynczą aplikacją. Składa się z kilku współpracujących komponentów.

API Server

API Server udostępnia interfejs użytkownika oraz API służące do zarządzania platformą.

To tutaj użytkownicy sprawdzają status procesów, uruchamiają DAG-i i analizują awarie.

W praktyce interfejs jest często otwierany w dwóch sytuacjach: podczas demonstracji dla zarządu oraz pięć sekund po otrzymaniu alertu.

Scheduler

Scheduler analizuje stan workflow i decyduje, które task instances spełniają warunki uruchomienia. Następnie przekazuje je do executora.

Scheduler nie powinien wykonywać logiki biznesowej pipeline’u.

Jego zadaniem jest podejmowanie decyzji o kolejności, a nie liczenie marży, generowanie PDF-ów i pobieranie całej bazy klientów podczas importu modułu.

DAG Processor

DAG Processor pobiera i parsuje definicje DAG-ów.

Kod DAG-a powinien być szybki i deterministyczny. Nie należy podczas jego importu:

• wykonywać zapytań do produkcyjnej bazy;
• pobierać plików z internetu;
• wywoływać zewnętrznych API;
• ładować dużych zbiorów danych;
• przeprowadzać półrocznego uzgodnienia finansowego.

Definicje DAG-ów są analizowane wielokrotnie. Każda kosztowna operacja wykonywana podczas parsowania może więc zostać pomnożona przez liczbę DAG-ów, procesów i kolejnych prób zrozumienia, dlaczego scheduler nie nadąża.

Metadata database

Baza metadanych przechowuje stan Airflow, w tym informacje o DAG-ach, uruchomieniach, task instances, konfiguracji i historii operacyjnej.

Nie powinna być traktowana jak hurtownia danych biznesowych.

W środowisku produkcyjnym musi być objęta:

• monitoringiem;
• backupem;
• kontrolą dostępu;
• planem odzyskiwania;
• regularnym utrzymaniem.

Baza metadanych jest jednym z tych komponentów, których znaczenie staje się oczywiste dokładnie w chwili, gdy przestają działać.

Executor i workers

Executor określa, w jaki sposób taski są przekazywane do wykonania.

Zadania mogą działać:

• lokalnie;
• na rozproszonych workerach;
• w osobnych podach Kubernetes;
• w środowisku zarządzanym przez dostawcę chmurowego.

Executor należy dobrać do wymagań dotyczących:

• skali;
• izolacji;
• kosztu;
• dostępnych kompetencji;
• charakteru workloadu.

KubernetesExecutor może zapewnić silną izolację i elastyczność. Nie oznacza to jednak, że każda firma powinna od razu budować platformę Kubernetes tylko po to, aby raz dziennie uruchomić pięć zapytań SQL.

Rozwiązanie problemu orchestration przez stworzenie większego problemu infrastructure nie zawsze jest oznaką dojrzałości architektonicznej.

Triggerer

Triggerer obsługuje zadania, które przez długi czas oczekują na zewnętrzny warunek.

Przykładem może być oczekiwanie na:

• zakończenie joba w usłudze chmurowej;
• pojawienie się pliku;
• ukończenie procesu w innym systemie;
• zmianę stanu zewnętrznego zasobu.

Klasyczny sensor może zajmować worker przez cały czas oczekiwania. Operator deferrable zwalnia worker i przekazuje oczekiwanie do triggerera.

To różnica podobna do delegowania pracownika do całodziennego patrzenia na skrzynkę pocztową oraz poproszenia go, aby wrócił, gdy przyjdzie wiadomość.

Oba modele działają. Jeden z nich jest tylko znacznie droższy.

Jak Airflow chroni systemy zależne?

Możliwość uruchomienia wielu procesów równolegle nie oznacza, że każdy system docelowy jest w stanie je obsłużyć.

Podczas backfillu Airflow może wygenerować dziesiątki albo setki uruchomień. Bez kontroli współbieżności mogą one jednocześnie:

• wysyłać zapytania do tego samego API;
• wykonywać kosztowne operacje w hurtowni;
• zapisywać do jednej tabeli;
• uruchamiać zbyt wiele klastrów;
• przekroczyć limit zewnętrznego dostawcy;
• sprawdzić, jak szybko dział bezpieczeństwa potrafi zadzwonić do CTO.

Do ograniczania takich sytuacji Airflow wykorzystuje pools.

Pool reprezentuje ograniczoną pulę slotów przypisaną do określonego zasobu. Task korzystający z obciążonego API może zajmować jeden slot, a ciężka operacja bazodanowa kilka slotów.

Gdy pojemność zostanie wykorzystana, kolejne taski pozostają w kolejce.

Pools należy łączyć z:

• limitami aktywnych uruchomień DAG-a;
• limitami równoległych tasków;
• limitami konkretnego backfillu;
• timeoutami;
• ograniczoną liczbą retry;
• exponential backoff;
• limitami po stronie systemu docelowego.

Celem nie jest maksymalne wykorzystanie Airflow.

Celem jest niedoprowadzenie do sytuacji, w której proces naprawczy generuje większą awarię niż problem, który miał naprawić.

Obserwowalność: sukces taska nie oznacza sukcesu biznesowego

Interfejs Airflow pokazuje stan DAG-ów, tasków, zależności i ponowień. Pozwala także analizować logi pojedynczych wykonań.

To jednak nie wystarcza do oceny jakości procesu danych.

Monitoring powinien obejmować trzy poziomy.

Stan platformy

Należy monitorować:

• scheduler;
• DAG Processor;
• triggerer;
• API Server;
• bazę metadanych;
• długość kolejek;
• dostępność workerów;
• czas parsowania DAG-ów.

Informacja, że „Airflow działa”, jest mniej użyteczna, jeżeli każdy task od dwóch godzin czeka w kolejce.

Stan wykonania

Na tym poziomie istotne są:

• liczba błędów i retry;
• czas oczekiwania w kolejce;
• długość wykonania tasków;
• liczba przekroczonych deadline’ów;
• czas trwania backfillu;
• zadania pozostające zbyt długo w stanie running.

Stan danych i biznesu

Najważniejsze pytania brzmią:

• Czy pojawiła się oczekiwana partycja?
• Czy wolumen danych mieści się w normalnym zakresie?
• Czy schema nie zmieniła się bez uzgodnienia?
• Czy dane są kompletne?
• Czy raport został opublikowany na czas?
• Czy wynik uzgadnia się z systemem finansowym?

Airflow może poprawnie wykonać wszystkie taski, a mimo to opublikować pustą tabelę.

Z punktu widzenia platformy jest to zielony sukces. Z punktu widzenia CFO jest to raczej temat na spotkanie.

Dlatego alert „task failed” powinien być uzupełniony alertami dotyczącymi świeżości, kompletności i jakości danych.

Bezpieczeństwo jest częścią wyboru executora

Kod DAG-ów i tasków jest kodem wykonywalnym.

Osoba posiadająca możliwość publikowania DAG-ów może potencjalnie uruchomić kod w środowisku Airflow.

Dlatego decyzja o architekturze nie powinna ograniczać się do pytania:

Ile tasków chcemy uruchamiać równolegle?

Należy również ustalić:

• kto może publikować DAG-i;
• gdzie wykonywany jest kod zespołów;
• jakie credentials są dostępne dla workera;
• czy taski różnych zespołów współdzielą środowisko;
• czy wymagane są osobne obrazy kontenerowe;
• kto może odczytywać Connections, Variables i Secrets;
• czy jedna instalacja zapewnia wystarczającą izolację.

Współdzielenie jednej platformy przez wiele zespołów nie oznacza automatycznie pełnej izolacji.

Tak samo jak wspólna kuchnia biurowa nie oznacza, że każdy będzie miał własną półkę, mimo że początkowo wszyscy tak deklarowali.

Sekrety nie powinny znajdować się w kodzie DAG-ów. Dostęp do systemów zewnętrznych powinien wykorzystywać kontrolowane mechanizmy zarządzania tożsamością i credentials.

Zasada najmniejszych uprawnień jest mniej widowiskowa niż rozbudowany diagram architektury, ale zazwyczaj znacznie bardziej przydatna podczas audytu.

Managed Airflow czy własna instalacja?

Managed Airflow zmniejsza część obowiązków infrastrukturalnych, ale nie usuwa odpowiedzialności za procesy danych.

Dostawca może utrzymywać część komponentów platformy, natomiast zespół klienta nadal odpowiada za:

• jakość DAG-ów;
• zależności Python;
• kompatybilność providerów;
• bezpieczeństwo integracji;
• role i uprawnienia;
• limity współbieżności;
• koszty wykonywanych workloadów;
• procedury backfillu;
• jakość danych;
• reakcję na awarie procesów.

„Managed” nie oznacza „nikt po naszej stronie nie musi już nic wiedzieć”.

Oznacza raczej, że część problemów infrastrukturalnych ma teraz numer zgłoszenia u dostawcy.

Własna instalacja zapewnia większą kontrolę nad konfiguracją, siecią i środowiskiem wykonywania tasków. W zamian organizacja przejmuje odpowiedzialność za:

• aktualizacje;
• bazę metadanych;
• skalowanie;
• dostępność;
• backupy;
• monitoring;
• obsługę incydentów.

Decyzję należy podejmować na podstawie modelu operacyjnego, a nie wyłącznie ceny infrastruktury.

Najtańsza maszyna w kalkulatorze chmurowym może stać się bardzo drogim rozwiązaniem, gdy doliczymy dyżury, aktualizacje i trzy tygodnie diagnozowania konfliktu zależności Pythona.

Kiedy Airflow jest właściwym wyborem?

Airflow jest dobrym kandydatem, gdy większość poniższych stwierdzeń jest prawdziwa:

Kryterium	Znaczenie
Proces obejmuje kilka systemów	Potrzebna jest centralna koordynacja zależności
Dane są przetwarzane w partiach	Każde uruchomienie ma określony zakres i wynik
Wymagane są retry i backfille	Proces musi umożliwiać kontrolowane odtwarzanie
Kolejność zadań ma znaczenie	Poszczególne etapy zależą od poprzednich
Potrzebny jest audyt wykonania	Należy odtworzyć historię procesu
Pipeline’y są rozwijane jak oprogramowanie	Definicje podlegają review, testom i CI/CD
Istnieją ograniczenia systemów docelowych	Potrzebne są pools i limity
Wiele zespołów korzysta z platformy danych	Potrzebne są standardy i ownership

Typowe zastosowania to:

• procesy ELT do data lake i hurtowni;
• transformacje dbt;
• raportowanie finansowe;
• uzgodnienia pomiędzy systemami;
• publikacja danych regulacyjnych;
• budowanie cech dla modeli machine learning;
• cykliczne treningi modeli;
• przetwarzanie dokumentów;
• kontrolowane migracje danych.

Airflow ma szczególną wartość tam, gdzie pytanie „czy proces się wykonał?” wymaga bardziej precyzyjnej odpowiedzi niż „chyba tak, bo plik jest na serwerze”.

Kiedy Airflow nie jest najlepszym wyborem?

Proste, niezależne zadania

Jeżeli firma ma trzy niewielkie skrypty, które nie zależą od siebie i prawie nigdy nie wymagają ponownego wykonania, cron albo natywny scheduler może być wystarczający.

Nie każda śrubka wymaga cyfrowego bliźniaka.

Zadania wywoływane przez request użytkownika

Gdy aplikacja przyjmuje żądanie HTTP i musi natychmiast zlecić pracę w tle, lepszym rozwiązaniem jest task queue lub system komunikatów.

Airflow nie powinien być elementem krytycznej ścieżki obsługi requestu.

Przetwarzanie strumieniowe

Gdy system musi stale przetwarzać zdarzenia i reagować z niskim opóźnieniem, potrzebny jest silnik streamingowy.

Uruchamianie DAG-a dla każdego zdarzenia z Kafki byłoby technicznie kreatywne. Kreatywność nie zawsze jest jednak cechą pożądaną w systemie produkcyjnym.

Orkiestracja procesów aplikacyjnych

Procesy mikroserwisowe oparte na krótkich krokach, kompensacjach i natychmiastowej reakcji mogą lepiej pasować do systemu state machine lub dedykowanego orchestratora aplikacyjnego.

Brak zespołu utrzymującego platformę

Airflow nie jest narzędziem typu „zainstaluj i zapomnij”.

Bez właściciela z czasem pojawią się:

• niekontrolowane zależności;
• nieaktualne providery;
• niestabilne DAG-i;
• nieczytelne alerty;
• kosztowne backfille;
• problemy z pojemnością;
• niejasna odpowiedzialność za incydenty.

Wtedy zamiast orkiestratora procesów firma otrzymuje orkiestrator problemów.

Co CTO powinien ustalić przed wdrożeniem?

Granica odpowiedzialności

Airflow powinien sterować wykonaniem, ale nie być miejscem przechowywania dużych danych i ciężkiej logiki obliczeniowej.

Model ownershipu

Każdy produkcyjny DAG powinien mieć:

• właściciela technicznego;
• właściciela danych lub procesu biznesowego;
• oczekiwany czas ukończenia;
• procedurę obsługi awarii;
• zasady wykonywania backfillu;
• kanał eskalacji.

Pole owner ustawione na data-team nie jest modelem odpowiedzialności. Jest administracyjnym odpowiednikiem napisania „ktoś się tym zajmie”.

Strategia bezpieczeństwa

Należy określić, kto może wdrażać kod, kto zarządza sekretami oraz czy zespoły mogą współdzielić workery i środowiska wykonawcze.

Strategia executorów

Executor powinien odpowiadać rzeczywistym wymaganiom dotyczącym skali i izolacji.

Nie należy wybierać najbardziej złożonego wariantu wyłącznie dlatego, że dobrze wygląda na diagramie.

Cykl aktualizacji

Należy zaplanować aktualizacje Airflow, providerów i środowiska Python.

Zmiany powinny być testowane na reprezentatywnych DAG-ach przed wdrożeniem produkcyjnym.

Sformułowanie „zaktualizujmy w piątek po południu, powinno być dobrze” nie jest formalną strategią upgrade’u.

Obserwowalność

Sukces wdrożenia powinien być mierzony jakością i terminowością danych, a nie tylko dostępnością interfejsu Airflow.

Minimalny standard produkcyjnego DAG-a

Przed dopuszczeniem procesu do produkcji warto zastosować jednoznaczną bramkę jakości.

Pytanie kontrolne	Wymaganie
Czy taski są idempotentne?	Ponowienie nie tworzy duplikatów
Czy zakres danych jest jawny?	Każdy run ma określony przedział
Czy duże dane omijają XCom?	XCom zawiera wyłącznie metadane
Czy określono timeouty?	Task nie może działać bez końca
Czy retry są ograniczone?	Awaria nie tworzy nieskończonej pętli kosztów
Czy istnieją limity współbieżności?	Backfill nie przeciąża systemów
Czy DAG ma ownera i runbook?	Wiadomo, kto reaguje
Czy monitorowana jest jakość danych?	Sukces techniczny nie wystarcza
Czy DAG jest testowany w CI?	Błędy są wykrywane przed wdrożeniem
Czy kod nie wykonuje I/O podczas parsowania?	Platforma pozostaje stabilna
Czy sekrety są poza kodem?	Credentials pochodzą z kontrolowanego źródła
Czy backfill został przetestowany?	Zespół zna jego koszt i wpływ

Jeżeli połowa odpowiedzi brzmi „zrobimy później”, warto założyć, że „później” pojawi się podczas pierwszego incydentu.

Jak podejść do wdrożenia Airflow?

Najbezpieczniej nie zaczynać od migracji wszystkich procesów.

Etap 1: wybór dwóch pipeline’ów

Pierwszy powinien być stosunkowo prosty, ale reprezentatywny. Drugi powinien zawierać realne zależności, retry i potrzebę odtwarzania danych historycznych.

Nie należy zaczynać od najważniejszego procesu finansowego tylko dlatego, że dzięki temu projekt „będzie miał widoczność zarządu”. Widoczność pojawi się również podczas awarii.

Etap 2: określenie kryteriów sukcesu

Warto mierzyć:

• czas diagnozy;
• czas odtworzenia danych;
• liczbę ręcznych interwencji;
• terminowość publikacji;
• liczbę fałszywych alertów;
• koszt infrastruktury;
• czas wdrożenia zmiany.

Etap 3: test scenariuszy awarii

PoC powinien obejmować nie tylko scenariusz sukcesu.

Należy sprawdzić:

• niedostępność źródła;
• częściowy zapis wyniku;
• timeout zewnętrznego joba;
• ponowienie taska;
• backfill wielu przedziałów;
• przekroczenie limitu API;
• wdrożenie nowej wersji DAG-a podczas aktywnych uruchomień.

Demo, w którym wszystko działa, pokazuje głównie to, że przygotowujący demo zna kolejność kliknięć.

Wartość platformy ujawnia się dopiero wtedy, gdy coś przestaje działać.

Etap 4: decyzja o modelu operacyjnym

Dopiero po poznaniu profilu workloadu należy wybrać:

• usługę zarządzaną lub self-hosted;
• executor;
• model izolacji;
• sposób dystrybucji DAG-ów;
• strategię logowania;
• monitoring;
• proces aktualizacji.

Etap 5: utworzenie standardu platformowego

Przed rozszerzeniem adopcji potrzebne są wspólne wzorce:

• szablon repozytorium;
• zasady nazewnictwa;
• wymagane tagi;
• biblioteka wspólnych integracji;
• polityka retry;
• standard alertowania;
• procedura backfillu;
• checklista produkcyjna.

Bez tych zasad Airflow może jedynie przenieść chaos ze skryptów do jednego, bardzo estetycznego interfejsu.

Wnioski

Apache Airflow ma największą wartość tam, gdzie proces danych musi być powtarzalny, obserwowalny i możliwy do bezpiecznego odtworzenia.

Nie jest silnikiem obliczeniowym, magazynem danych ani narzędziem do przetwarzania każdego zdarzenia w czasie rzeczywistym.

Jest warstwą sterującą, która koordynuje pracę innych systemów.

Dla CTO decyzja o wdrożeniu Airflow nie powinna zaczynać się od pytania:

Czy potrzebujemy nowoczesnego orchestratora?

Lepsze pytanie brzmi:

Czy koszt ręcznego zarządzania zależnościami, awariami, backfillami i audytem jest już wyższy niż koszt utrzymania platformy orkiestracyjnej?

Jeżeli odpowiedź jest twierdząca, Airflow może stać się ważnym elementem platformy danych.

Warunkiem sukcesu nie jest jednak samo uruchomienie oprogramowania. Potrzebne są:

• idempotentne taski;
• kontrola współbieżności;
• jawny ownership;
• bezpieczne środowiska wykonawcze;
• obserwowalność danych;
• proces aktualizacji;
• zespół odpowiedzialny za platformę.

Dopiero wtedy Airflow staje się control plane’em dla danych.

W przeciwnym razie pozostaje bardzo zaawansowanym sposobem na dowiedzenie się, że skrypt znowu nie zadziałał.