A tárolóstruktúra egy elsőre egyszerűnek tűnő, de mélyreható hatással bíró döntés bármilyen projektben. Érdemes alaposan átgondolni, hogy a csapatunk hogyan dolgozik jelenleg, milyen operációs mintákat szeretnénk támogatni, és hogyan fogunk együttműködni a különböző struktúrákkal, mielőtt végleges döntést hozunk. Ne felejtsük el, hogy a döntés bármikor módosítható!

Mono-repo

A mono-repo egy olyan tárolóstruktúra, amelyben az összes kód alapot egyetlen tárolóban helyezünk el, és egyetlen verziótörténet alatt követjük (és publikáljuk). Például lehet, hogy különböző mappák vannak, amelyek az Airflow rendszerépítő mechanizmusát, az egyedi operátorokat/pluginokat, valamint minden csapat DAG-jait tartalmazzák. A mono-repo mintázat különösen erős lehet, ha "mindig az aktuális verzióval dolgozunk" stratégiát alkalmazunk. Még több csapat esetén is egyszerűen biztosítható, hogy minden csapat közvetlenül hozzáférhessen az összes kódhoz, amely szükséges ahhoz, hogy a DAG-jaik megfelelően fussanak – fontos, hogy mindegyik csapat a verziófejlődés élén dolgozzon.

A mono-repo mintázat fő hátrányai közé tartozik a megnövekedett tárolóméret, ami hosszabb letöltési időket eredményezhet, a kiadások koordinálásával kapcsolatos nagyobb operációs terhek, valamint a mikro-szolgáltatás architektúrák bevezetése esetén bonyolultabb CI/CD pipeline-ok.

Multi-repo

A multi-repo egy olyan tárolóstruktúra, ahol az egész Airflow telepítést több tárolóra bontjuk. A szélsőséges esetben lehet egy tároló az Airflow magjához, külön tárolók minden egyes pluginhez, valamint külön tárolók minden csapat számára, akik a DAG-jaikat telepítik. Ez a mintázat remek lehetőséget biztosít arra, hogy a csapatok viszonylag egyszerű és elszigetelt munkafolyamatokat alkalmazzanak a rendszerük általuk kezelt részeinek fejlesztésére és telepítésére. Azonban ennek is megvan az ára: a különböző csapatok közötti változások szinkronizálása, amelyek a teljes rendszer működéséhez szükségesek. Ezt általában növelt integrációs teszteléssel lehet áthidalni a kiadás előtt.

A mono-repo és a multi-repo választása valójában egy hamis dichotómia. Ezek a lehetőségek egy spektrum szélsőségei, és valószínűleg végül néhány kisebb mono-repo használata mellett fogunk dönteni. A legjobb megoldás az, ha van egy mono-repo, amely az Airflow telepítését és az egyedi fejlesztésű operátorokat tartalmazza, és egy másik tároló a DAG-ok számára. Ezen kívül célszerű lehet több további tároló, amelyek lehetővé teszik a csapatok számára, hogy leírják és telepítsék a DAG-jaikat. Ezek a csapatok az Airflow legfrissebb verzióját húzhatják le, hogy lokálisan fejlesszenek és teszteljenek a kiadás előtt.

Miután a csapatod döntést hozott a tárolóstruktúráról, következhetnek a további fontos lépések a kapcsolat- és változó objektumok kezelésében.

Kapcsolatok és változók kezelése

Az Airflow-ban a kapcsolat- és változó objektumok minden operátor és DAG központi részét képezik. Ezek az objektumok határozzák meg, hogy az Airflow mely rendszerekkel lépjen kapcsolatba, valamint azt, hogy egy DAG hogyan viselkedjen egy változó értékének függvényében. A változókat a legtöbb más szoftverhez hasonlóan konfigurációként használjuk, és azok környezettől függően változhatnak. Gyakran titkos információkat is tartalmaznak, amelyek szükségesek a rendszerekhez való csatlakozáshoz.

Bár számos példában a szerzők a WebUI-ból történő kapcsolat- és változó objektumok létrehozását mutatják be, ez csupán egy klikk-alapú megoldás, amely nem biztosít egységes módszert az objektumok kezelésére több környezet között. Szerencsére az Airflow több módot kínál az objektumok provisioningjára, amelyek jól illeszkednek a modern DevOps gyakorlatokhoz.

A kapcsolat- és változó objektumok definícióját környezeti változóként is megadhatjuk az Airflow-ban:

bash
export AIRFLOW_VAR_NAME=1


export AIRFLOW_VAR_NAME_JSON='{"hello":"world"}'
export AIRFLOW_CONN_MY_DATABASE='conn-type://login:password@host:port/schema?param1=val1¶m2=val2'

Ezen változók természeténél fogva nem teljesen biztonságosak, ha nyers szövegként tároljuk őket, ezért érdemes őket titkosított formában tárolni egy külső titkosítási rendszerben.

Titkos adatkezelés háttérszolgáltatásokkal

Az Airflow lehetőséget kínál titkos adatok kezelésére egy titkos adatkezelő háttérszolgáltatás (Secrets Backend) használatával, amely támogatja a közönséges szolgáltatókat, mint az AWS Secrets Manager, Google Cloud Secret Manager, Hashicorp Vault és mások. A megfelelő titkos szolgáltató beállítása után bármikor, amikor változókat vagy kapcsolatokat próbálunk elérni, az Airflow ellenőrzi az értéket a háttérszolgáltatásban.

Mivel a titkos adatkezelés kulcsfontosságú biztonsági kérdés, érdemes előzetesen konzultálni a biztonsági és DevOps csapatokkal a rendelkezésre álló lehetőségekről.

Airflow telepítési módszerek

A telepítési módszer kiválasztása nagymértékben függ a szervezet infrastruktúrájának képességeitől és hátterétől. A leggyakrabban alkalmazott módszerek közé tartozik a Kubernetes és a virtuális gépek használata.

  • Kubernetes: A Kubernetes leegyszerűsíti a komplex alkalmazások (mint az Airflow) építését és futtatását, mivel deklaratív szintaxist biztosít az alkalmazás leírására, valamint biztosítja a különböző szolgáltatások közötti kommunikációhoz szükséges infrastruktúra menedzselését. Ha a csapatunk már ismeri a Kubernetes-t, vagy ha más csapatok biztosítják ezt a szolgáltatást, akkor célszerű ezt a telepítési módszert választani.

  • Virtuális gépek: Ha kényelmesebbek vagyunk a fizikai szerverekkel való munkában, akkor virtuális gépeken (vagy valódi hardveren) történő telepítést választhatunk. Ez azonban nem egyszerű feladat, ezért célszerű konfigurációs menedzsment eszközöket, mint például a Terraform, Ansible vagy Puppet használni az infrastruktúra és a szoftver kezelésére.

A legjobb telepítési módszer kiválasztása tehát a csapat technikai tudásától és a projekt igényeitől függ.

Milyen szerepe van a TimeDeltaTrigger-nek és más eseményalapú indítóknak az Apache Airflow-ban a feladatok ütemezésében?

Az Apache Airflow-ban az ütemezés egyik legfontosabb aspektusa a feladatok időzítése és az azok közötti kapcsolat meghatározása. A feladatok, amelyek egyirányú gráfokat alkotnak, az ún. DAG-ok (Directed Acyclic Graphs) segítségével egymásra építhetők és egyetlen folyamatként futtathatók. Az Airflow-ban az egyes feladatok közötti interakciókat különféle indítók szabályozzák, amelyek meghatározzák, hogy mikor és milyen feltételek mellett hajtódnak végre a műveletek.

A TimeDeltaTrigger egy alapvető példa arra, hogyan lehet a feladatokat időben eltolni más feladatok befejezéséhez képest. A TimeDeltaTrigger egy adott időintervallumot határoz meg, amely után a feladatok végrehajtása elindul. Például, ha azt szeretnénk, hogy egy adattranszformáló feladat 30 perccel egy másik adatkinyerő feladat befejezése után fusson le, akkor ezt a TimeDeltaTrigger segítségével könnyedén beállíthatjuk a következő módon: trigger=TimeDeltaTrigger(timedelta(minutes=30)). Ez lehetővé teszi, hogy a rendszer a feladatok közötti késéseket dinamikusan kezelje, és így rugalmasabban reagáljon a futás közbeni körülményekre.

A különböző típusú indítók közül kiemelhetők a következők: időalapú, függőség-alapú és eseményalapú indítók. Az időalapú indítók közé tartoznak a CRON-kifejezések, amelyek segítségével a feladatokat rendszeres időközönként ütemezhetjük. A CRON szintaxis (például: 0 0 * * *) lehetővé teszi a napi futtatást, míg az intervallum-alapú ütemezés fix időközönként történő futtatást jelent, például óránként vagy naponta.

A függőség-alapú indítók azok, amelyek egy másik feladat sikeres befejezésére építenek. Az ilyen típusú indítók különösen fontosak, amikor egy feladat csak egy másik feladat kimenete alapján futtatható. Az ilyen típusú indítók közé tartozik az "upstream task completion", amely lehetővé teszi, hogy egy feladat csak akkor fusson, ha az összes neki előzőleg függő feladat sikeresen befejeződött.

Az eseményalapú indítók, mint a Webhookok és érzékelők, külső rendszerekből érkező jelekre reagálnak, például egy e-mail vagy más értesítések érkezésére. Az e-mail érzékelő például képes elindítani egy feladatot, amint egy e-mail megérkezik, amely megfelel a meghatározott kritériumoknak. Az eseményalapú indítók különösen akkor hasznosak, amikor a munkafolyamatokat külső események váltják ki, például egy felhasználó által végzett művelet vagy egy másik rendszerből érkező értesítés.

A külső rendszerből érkező eseményekre reagáló trigger-eket például Webhookok révén valósíthatunk meg. A Webhook trigger-ek lehetővé teszik, hogy egy külső alkalmazás értesítése elindítson egy Airflow feladatot. Az ilyen típusú indítók elősegítik, hogy az Airflow munkafolyamatok összekapcsolódjanak más rendszerek műveleteivel, így az automatizálás szélesebb körben alkalmazható.

A manuális indítók szintén fontos szerepet játszanak a rendszer működésében. Ezeket a felhasználók közvetlenül indíthatják el, amikor a környezet vagy a feladatok sajátos igényeknek megfelelően kívánják elindítani a munkafolyamatokat. Az ilyen típusú trigger-ek különösen akkor hasznosak, amikor a rendszer bizonyos állapotokban vagy események alapján várakozik, és a felhasználó beavatkozására van szükség.

A megfelelő indítók és ütemezési mechanizmusok használata alapvetően befolyásolja a munkafolyamatok hatékonyságát és rugalmasságát. Az Airflow lehetőséget ad arra, hogy különböző típusú trigger-eket kombináljunk, ezáltal bonyolultabb és dinamikusabb munkafolyamatokat építhessünk. Az alapvető indítók megértése és gyakorlati alkalmazása nélkülözhetetlen, ha nagyobb méretű ETL rendszereket, adatfeldolgozó pipeline-okat vagy ML/AI folyamatokat kívánunk létrehozni. A TimeDeltaTrigger és más típusú indítók alapos ismerete biztosítja, hogy a rendszer a futás közbeni változásokra megfelelően reagáljon, és a feladatok optimális időzítése biztosított legyen.

A rendszeres gyakorlás és az alapok megértése kulcsfontosságú ahhoz, hogy később bonyolultabb rendszereket építhessünk. A gyakorlatban való alkalmazás segít abban, hogy az Airflow és annak trigger-jeinek működését maximálisan kihasználjuk, így biztosítva az adatfeldolgozás hatékonyságát és pontosságát. A következő lépések során érdemes részletesebben ismerkedni az Airflow egyéb összetevőivel és azok alkalmazásával a különféle adatkezelési és feldolgozási igényekhez.

Hogyan kezeljük az infinite halmazokat és a kardinalitás aritmetikáját?
Hogyan válhat az idő rugalmasabbá: A cél és a személyes szükségletek szerepe
Hogyan kezeljük az infrastruktúra definíciókat és az automatizálást a Terraform segítségével?