5 jóslat az Apache Airflow jövőjéről az adatok kezelésében, amik meglepnek majd

A Microsoft március végén egy csokor Fabric Data Factory-újdonságot tett közzé: az Apache Airflow jobok mostantól copy jobokat és dbt jobokat is futtatnak a notebookok, Spark job definíciók, pipeline-ok és semantic modelek mellett; megjelent egy új API-készlet, amellyel külső alkalmazások indíthatnak és monitorozhatnak DAG-futásokat; a pipeline-ok pedig preview-ban megkapták az intervallum-alapú ütemezést, az Azure Data Factory tumbling window triggerének mintájára. Önmagában mindegyik tétel egy korrekt release note-sor. Együtt olvasva viszont kirajzolódik belőlük, merre tart a Microsoft szerint az orkesztráció, és ennek nyomán előbb-utóbb mi is.

Hogy az alábbi öt jóslat tényleg meglep-e, az jó eséllyel azon múlik, hány hó végi zárást éltél már túl. Ezek jóslatok, nem bejelentések: a bizonyíték a kiadott feature-készlet, a következtetés az enyém.

1. A kódalapú orkesztráció lesz a governance-barát alapértelmezés

A bejelentés fő képessége, hogy a Fabric Data Factory Airflow jobjai natív operátorokkal futtatnak Fabric-elemeket: notebookot, Spark job definíciót, pipeline-t, semantic modelt és user data functiont, és a lista most bővült a copy és a dbt jobokkal. Még egy helyi menüs gyorsparancs is van, a Run Fabric Artifact, amely beilleszti a DAG-ba a Fabric-elem futtatásához szükséges kódot.

Nem a kényelem itt a lényeg. Amint az a dolog, ami eldönti, mi fusson, milyen sorrendben és milyen retry-szabályokkal, egy Python-fájl, akkor repóban él: diffelhető, review-zható és visszagörgethető, mint bármely más kód. A Syngentánál, ahol egy Fabric lakehouse-on és a BI-eszközök CI/CD-jén dolgozom, pontosan ez a különbség aközött, hogy „hisszük, hogy lefutott a frissítés”, és aközött, hogy meg tudom mutatni, melyik workflow melyik verziója állította elő a keddi számokat. Az első jóslatom: néhány éven belül a „mutasd a DAG-ot a gitben” váltja le a „mutasd az ütemező képernyőjét” szokásos audit-kérdést, és az szorul majd magyarázatra, ha egy orkesztráció csak kattintásokként létezik egy UI-ban.

2. Az ütemező többé nem óra lesz, hanem szolgáltatás

A bejelentés alsóbb felében bújik meg az a tétel, amit a legtöbbre tartok: az új Apache Airflow job API-k, amelyekkel saját alkalmazásból lehet DAG-futásokat kezelni, monitorozni és triggerelni.

Az ütemezők hagyományosan órák voltak. A job hajnali 6-kor fut, mert valaki valamikor úgy döntött, hogy a 6 óra valószínűleg biztonságos, és a teljes zárási naptár ezt a tippet örökli. Az API-k a triggert időről állapotra cserélik. Képzeljünk el egy kontrollert, akinek a checklistjén ma az áll: „várd meg az éjszakai frissítést”. API-triggerrel az egyeztetési workflow abban a pillanatban elindulhat, amikor az alfőkönyvi kivonat ténylegesen megérkezik, akár 4:40-kor, akár 7:15-kor. A második jóslat: a fix időpontos ütemezés tartalékmegoldássá válik azokra az esetekre, ahol az upstream eseményt nem lehet detektálni, nem pedig kiindulóponttá.

3. Az intervallum-szemantika megkerülhetetlen lesz az egyeztetésekben

A pipeline-ok preview-ban megkapták az intervallum-alapú ütemezést: szabályos, át nem fedő intervallumokon ismétlődő futásokat, az Azure Data Factory tumbling window triggerének szellemében.

Ez elsőre apró ütemezési opciónak tűnik, egészen addig, amíg a workload nem egyeztetés (rekonciliáció), mert az egyeztetés természeténél fogva ablakokra épül: az adott nap settlementjeit az adott nap számláival kell párosítani, és az a rekord, amelyik két ablak közé csúszik, vagy kétszer párosul, vagy soha. Az a Morgan Stanley-s egyeztetési platform, amelyen dolgoztam, napi 500K+ settlementet párosított agent- és CSD-számlákkal, és ennek a munkának a legkevésbé látványos magja épp az ablak-fegyelem volt: annak tisztázása, melyik intervallumhoz tartozik egy rekord, és mihez nyúlhat hozzá egy késve érkező tétel vagy egy backfill. Egy ütemezés, amely egyszerűen csak óránként elindul, ebből semmit nem tud kifejezni. Harmadik jóslat: az át nem fedő intervallum-szemantika csendben checkbox-követelménnyé válik a pénzügyi adatmunkára szánt eszközök kiválasztásánál, nagyjából úgy, ahogy a row-level security vált azzá a BI-platformoknál.

4. A dbt nem marad külön sziget

Az, hogy az Airflow jobok natívan futtatnak dbt jobokat, azt jelenti, hogy a transzformáció nem él tovább saját, külön ütemezőn. Ma lehangolóan gyakori az az architektúra, ahol az adatbetöltés az egyik eszközben fut, a dbt valahol máshol, a semantic model frissítése pedig egy harmadik időzítőn, a réseket pedig bőkezű időpufferek hidalják át. Aki publikált már dashboardot félig betöltött adatra, pontosan tudja, hogyan buknak el ezek a pufferek.

Amikor a dbt-futás és a semantic model frissítése ugyanabban a DAG-ban ül, mint a betöltési lépés, a frissítés függőségekre épülő lépés lesz, nem pedig fogadás arra, hogy az időzítés kijön. Negyedik jóslat: a konszolidált környezetekben lassan kihalnak „a frissítés megelőzte a betöltést” típusú incidensek, és aki továbbra is három ütemezőt üzemeltet, az olyan probléma debugolásával tölti majd az ügyeleti óráit, amelyet máshol már tervezési szinten megszüntettek.

5. A vizuális kontra kód vita nem meggyőződés lesz, hanem erőforrás-kérdés

Ugyanez a kiadás a vizuális oldalba is fektet: intuitívabb drag-and-drop pipeline designer érkezett, valamint fejlettebb paraméterezés, amellyel újrahasznosítható pipeline-sablonok építhetők. A Microsoft láthatóan nem arra fogad, hogy a kód kiszorítja a vásznat; mindkét felületet egyszerre finanszírozza.

Az utolsó jóslatom ebből következik. A „kattintás vagy kód” vita többé nem identitáskérdés lesz, hanem az, hogy ki tartja karban az adott workloadot:

A rendezett környezeteket nem az választja el a kuszáktól, hogy melyik felületet választották, hanem hogy a függőségek átívelnek-e mindkettőn. Egy Airflow DAG, amely egy paraméterezett pipeline-t indít, koherens terv; két ütemező, amelyik nem tud egymásról, a hajnali kettes riasztások receptje.

Mit kezdenék ezzel a gyakorlatban

Egy Fabricen dolgozó pénzügyi adatcsapatnak nem az a célszerű lépés, hogy mindent DAG-gá írjon át, hanem hogy kivegye azt az egy workflow-t, ahol az időzítési fegyelem hiánya a legjobban fáj (jellemzően a zárási időszak frissítési láncát), és újraépítse Airflow jobként, explicit függőségekkel, miközben az egyszerű betöltő folyamatok vizuális pipeline-ban maradnak, immár intervallum-ütemezéssel ott, ahol az ablakok számítanak. A teljes bejelentés, képernyőképekkel és dokumentációs linkekkel, a Fabric blogon olvasható: Announcing the latest innovations in Fabric Data Factory: Apache Airflow jobs and pipelines.

Az öt jóslat egyikéhez sem kell, hogy a Microsoft bármi újat szállítson. A darabok kint vannak; most az dől el, hogy a csapatok mit építenek belőlük, és szokás szerint ez a lassabbik rész.