Apache Airflow magyarázata: Kezdőknek szóló útmutató

Bevezetés

A modern, adatvezérelt vállalatok mind olyan adatcsővezetésekre támaszkodnak, amelyek adatokat gyűjtenek, átalakítanak, gazdagítanak, és mozgatnak egyik helyről a másikra. Ezek az adatcsővezetések sok lépést is magukban foglalhatnak (például a nyers adatok kinyerését, tisztítását, gépi tanulási modellek képzését, irányítópultok létrehozását stb.). Ezenkívül nagyon konkrét sorrendben kell, hogy fusson. Az olyan munkafolyamat-irányító eszközök, mint az Apache Airflow, segítenek biztosítani, hogy minden lépés a megfelelő időben és sorrendben fusson. Emellett megkönnyítik a csővezetések felügyeletét és kezelését is.

Az Airflow-t 2014-ben az Airbnb-nél fejlesztették ki, és azóta az egyik legnépszerűbb nyílt forráskódú munkafolyamat‑szervező platformmá vált. Ezer szervezet használja az automatizált és felügyelt batch folyamatok kezelésére. Ebben a cikkben az Apache Airflow-t az alapoktól magyarázzuk el. A témák, amelyeket tárgyalni fogunk, a következők:

• Mi az az Airflow, mit csinál, és miért használják az adatcsapatok.
• Az Airflow alapvető fogalmai és összetevői, és hogyan illeszkednek össze.
• Hogyan vannak a folyamatok irányított körmentes gráfokként (DAG) definiálva, és egy egyszerű DAG működésének bemutatása.
• Gyakori felhasználási esetek, például ETL/ELT, MLOps és még sok más.

Reméljük, hogy ez egy gyakorlati, példákon alapuló bevezetés lesz az Apache Airflow-ba mérnökök, diákok és csapatok számára, akik most kezdik el a munkafolyamat‑orchesztrációval való ismerkedést.

Főbb Tanulságok

• Az Apache Airflow egy Python alapú munkafolyamat-orchesztrációs platform, amely DAG-ok (irányított körmentes gráfok) segítségével kezeli, ütemezi és figyeli az összetett adatfolyamokat.
• A DAG-ok meghatározzák a feladatokat és azok függőségeit, lehetővé téve, hogy az Airflow a beépített újrapróbálkozásokkal, naplózással és megfigyelhetőséggel minden lépést a megfelelő sorrendben hajtson végre.
• Az Airflow architektúrája (Scheduler, Executor, Worker, Metadata DB, Web UI) lehetővé teszi a skálázható, elosztott végrehajtást és a folyamatok valós idejű nyomon követését.
• Az Airflow kiemelkedik a kötegelt munkafolyamatokban, mint az ETL/ELT feladatok, ML tanítási folyamatok, adatminőség-ellenőrzések és ütemezett elemzések — de nem ideális valós idejű vagy rendkívül nagy gyakoriságú terhelésekhez.
• Olyan alternatívák, mint a Prefect, Dagster, Luigi, Argo Workflows és Mage AI jobban megfelelhetnek az igényeknek, például eseményvezérelt munkafolyamatok, Kubernetes-natív végrehajtás vagy modern, fejlesztőbarát felületek esetén.

Mi az az Apache Airflow?

Az Apache Airflow egy nyílt forráskódú rendszer munkafolyamatok létrehozására, ütemezésére és figyelemmel kísérésére. Egy Airflow munkafolyamat egy DAG (irányított körmentes gráf), amely egy sor feladatból áll, világosan meghatározott kapcsolatokkal (függőségekkel), és ciklusokat nem tartalmaz (egy feladat nem ismételheti önmagát feljebb). Az Airflow alapfilozófiája a „konfiguráció mint kód”, így a felhasználói felület drag-and-drop funkciója helyett Python szkripteket készítesz a munkafolyamatok ábrázolására. Ez a megközelítés jelentős rugalmasságot biztosít a mérnökök számára: szinte bármilyen technológiát csatlakoztathatsz Airflow operátorai és Python könyvtárai segítségével. Emellett a szoftvermérnöki bevált gyakorlatokat (verziókezelés, tesztelés stb.) is alkalmazhatod a munkafolyamat-definícióidhoz.

Miért fontos a munkafolyamat-összehangolás?

A kulcspont az, hogy gyakran több lépés van bármely adatmunkafolyamatban, amelyeket sorrendben kell végrehajtani. Egy egyszerű példa az ETL (Extract/Transform/Load - Kinyerés/Átalakítás/Betöltés) folyamat. A folyamatok gyorsan összetettebbé válhatnak, ahogy több feladatot, függőséget, ágazást stb. adunk hozzá, és gyakran rendszeres időközönként kell futniuk. Manuális beavatkozás vagy egyszerű ütemező eszközök ezekben az esetekben gyakran elégtelenné válnak. Az Airflow ezt úgy oldja meg, hogy központi szervezőként működik. Van egy irányított aciklikus gráfja (DAG) a feladatokkal (csomópontok), amelyeknek vannak függőségei (élek). Tudja, mikor kell végrehajtani melyik feladatot (megvárva a felfelé irányuló függőségek befejezését a futtatás előtt), beleértve az ütemezést (időszakos végrehajtást), a hibakezelést (automatikus újrapróbálkozások, riasztások) és a naplózást.

Ha az egész adatfolyamot egy receptnek tekintjük, akkor az egyes feladatok olyan al-lépések, mint a vágás, főzés, tálalás stb. Az Airflow olyan, mint a konyhafőnök, aki ismeri a recepteket, és figyelemmel kíséri az összes különböző al-lépést, amelyek minden konyhában zajlanak, biztosítva, hogy minden a megfelelő sorrendben és időben történjen.

Workflow-orchestration nélkül lehet, hogy megvannak a séfek és az alapanyagok, de nincsenek összehangolva. Az Airflow biztosítja ezt az összehangolást, lehetővé téve a kívánt „fogás” (workflow futás) előállítását.

Miért használják az adatelemző csapatok az Airflow-t?

Az Airflow népszerűvé vált az adatmérnökök, gépi tanulás mérnökök és DevOps csapatok körében, mert sok komplex adatfolyam igényét képes kielégíteni. Íme néhány fő ok, amiért a csapatok az Airflow-t választják:

• Összetett munkafolyamatok és függőségek koordinálása: Az Airflow-t olyan munkafolyamatokra tervezték, amelyekben sok egymásra épülő lépés van. Az Airflow segítségével könnyen megadhatók a feladatok előfeltételei és utókövetelményei, biztosítva, hogy a feladatok megfelelő sorrendben hajtódjanak végre. Ha a C feladat az A és B feladattól függ, az Airflow ütemezője ismeri ezeket a kapcsolatokat, és gondoskodik róla, hogy az A és B feladatok (esetleg párhuzamosan) lefussanak, mielőtt a C-t végrehajtanák. Az Airflow képes kezelni összetett függőségeket, elágazási logikát stb.
• Központosított ütemezés (Cron a maximumon): Biztosít egy ütemezőt, amely lehetővé teszi, hogy feladatokat hajts végre egy meghatározott ütemterv szerint. Létrehozhatsz több tucat vagy akár több száz pipeline-t, amelyek különböző időpontokban (óránként, naponta, havonta) indítanak feladatokat az Airflow ütemezőjének használatával. Az Airflow érti a feladatok közötti kapcsolatokat. Intelligensen tudja ütemezni és elindítani a feladatokat. A központi ütemező megszabadít attól, hogy különböző szervereken különböző szkripteket kelljen írnunk.

• Skálázhatóság és elosztott végrehajtás: Az Airflow képes a munkafolyamataidhoz igazodva skálázódni. Konfigurálható úgy, hogy több munkafolyamatot vagy gépet felhasználva párhuzamosan hajtsa végre a feladatokat. Több végrehajtót is biztosít (erről később az írásban részletesen szó lesz), amelyek képesek feladatokat futtatni elosztott rendszereken, például Celery vagy Kubernetes segítségével egy csomópontokból álló klaszteren. Ez azt jelenti, hogy párhuzamosíthatod a nagyobb feladatokat (például nagy adatmennyiség feldolgozását), és egyszerre több pipeline-t is futtathatsz.
• Monitoring, naplózás és riasztás: Gazdag webes felülettel rendelkezik, amely valós idejű áttekintést nyújt a munkafolyamataidról. Láthatod, mely feladatok sikeresen teljesültek, és melyek sikertelenek, valamint megtekintheted az egyes feladatok napló kimenetét. Még manuálisan is elindíthatod és/vagy újraindíthatod a feladatokat a webes felületen keresztül.

Az Airflow főbb elemei

Az alábbiakban rövid áttekintést találhat az Apache Airflow alapvető építőelemeiről. Használja ezt a táblázatot gyors hivatkozásként, hogy megértse, mi az egyes összetevők szerepe és funkciója.

Hogyan működik az Airflow (Architektúra)

Íme egy lépésről lépésre áttekintés arról, hogyan dolgozza fel az Airflow a munkafolyamatot (DAG):

• A DAG elkészítése: A DAG szerzője ír egy Python szkriptet, amely definiálja a DAG-t. Ez a szkript tartalmazza például az ütemezést (pl. „futtatás naponta 9 órakor”) vagy a kézi indítási beállításokat. Tartalmazza továbbá a feladatok definícióit (operátorok vagy @task függvények segítségével), valamint a feladatok közötti függőségeket (pl. task1 >> task2 (task2 vár, amíg task1 befejeződik)). A Python fájlt el kell menteni az Airflow DAG mappájába, hogy az Airflow megtalálja. Az Airflow időszakosan olvassa (parszolja) ezt a fájlt a DAG definíció betöltéséhez.
• Ütemezés és DAG elemzés: Az Airflow Scheduler egy olyan folyamat, amely folyamatosan fut a háttérben. Ellenőrzi, hogy minden DAG-nak futnia kell-e az ütemezése vagy a triggerjei alapján. Például egy „naponta“ ütemezésű DAG-ot a scheduler felvehet, és észreveheti, hogy egy új futtatást éjfélkor kell ütemezni. Az Airflow Scheduler azt is ellenőrzi, hogy a DAG-okon belüli feladatok készen állnak-e a futtatásra – ez azt jelenti, hogy minden előzőleg függő feladatuk befejeződött, és az ütemezett idejük (logikai dátum) elérkezett.
• Feladatok végrehajtása: Minden végrehajtandó feladatot az Ütemezőtől a Végrehajtóhoz adnak. A végrehajtó dönt arról, hogy hol és hogyan hajtsa végre a feladatot. A feladatot helyben lehet végrehajtani, vagy egy munkás sorba küldeni. Egy elosztott architektúrában a feladatot egy sorba helyezik, majd a Végrehajtó folyamatok választják ki, amelyek végrehajtják a feladatokat.
• Állapot- és hibakezelés frissítése: Minden feladatpéldány visszajelzi az állapotát (siker, hiba stb.) az ütemezőnek a befejezés után, és az ütemező frissíti a metaadatbázisát a feladat állapotával.
  Az állapotkövetés teszi lehetővé, hogy az ütemező tudja, mi következik – például ha az A feladat sikeresen teljesült, tudja, hogy most ütemezheti a B feladatot, vagy ha az A feladat sikertelen volt, de még vannak újrapróbálkozások, újrapróbálkozást ütemez, vagy ha sikertelen volt és nem maradt több próba, a DAG futást hibásként jelöli. Ha egy feladat hibát jelez, az Airflow logikája automatikusan újrapróbálja a feladatot, ha be van állítva újrapróbálkozásra. Ha továbbra is hibás marad az újrapróbálkozások után, az Airflow képes jelzést küldeni a hibákról (például e-mailt vagy Slack üzenetet). Mindezek konfigurálhatók a DAG vagy a feladat paramétereiben (például újrapróbálkozások száma, újrapróbálkozás késleltetése, jelzés küldése e-mailben stb.).
• Figyelés és beavatkozás: Az Airflow Web UI élő felületet biztosít a fenti folyamat számára. Láthatod, amikor egy DAG futása megjelenik (például egy új sor a Tree nézetben a mai futáshoz), és nyomon követheted a feladatok állapotának változását, ahogy haladnak. A Graph nézet vizualizálja a DAG feladatait, és megmutatja, melyek fejeződtek be, illetve melyek hibásak.
• Tisztítás és következő futtatás: Ha egy DAG futtatás befejeződött (minden feladat sikeresen lefutott, vagy kihagyásra/sikertelenségre került), az Airflow továbblép a következő ütemezett futtatásra. Az összes múltbeli futtatásra vonatkozó metaadat továbbra is megmarad az adatbázisban, és mindig ellenőrizheted a történelmet. Az ütemező továbbra is új futtatásokat indít az ütemterv vagy a manuális indítás szerint. Ezt a folyamatot addig ismétlik, amíg az Airflow folyamatot le nem állítják.

A DAG-ek megértése az Airflow-ban

Az Airflow-ban a DAG meghatározza az ütemezést, valamint a munkafolyamat végrehajtásához szükséges feladatokat és függőségeket. Egy DAG-nak nem kell tudnia, mi van az egyes feladatok belsejében; csak azt kell meghatároznia, mikor és milyen sorrendben kell futniuk.

Feladatok, operátorok és érzékelők

A feladatok az Airflow-ban a munka alapegységei. Az Airflow-ban a feladatok operátorok példányai, amelyek előre meghatározott műveletek sablonjai. Az Airflow számos alap operátort kínál. A BashOperator lehetővé teszi shell parancsok futtatását, míg a PythonOperator segítségével Python függvényeket hívhatunk meg. Az Airflow emellett biztosít egy @task dekorátort is, amely lehetővé teszi, hogy egy normál Python függvényt feladattá alakítsunk.

Az operátorokon kívül az Airflow érzékelőket is biztosít. Az érzékelők olyan feladatok, amelyek addig várakoznak, amíg egy feltétel vagy esemény teljesül, mielőtt sikeresnek minősülnek. Használhatók például arra, hogy várjanak egy fájl megjelenésére vagy egy tábla feltöltődésére.

Feladatfüggőségek

A feladatok közötti függőségek deklarálásához a >> és << operátorokat (ajánlott) vagy olyan metódusokat használhat, mint a set_upstream és set_downstream. Lehetséges továbbá feladatok láncolása, kereszt-függőségek létrehozása, sőt dinamikusan feladatlisták építése is. Egy függőségek nélküli DAG csak egy független feladathalmaz lenne.

Legjobb gyakorlatok a DAG tervezéséhez

Az alábbi táblázat néhány irányelvet mutat be, amelyeket érdemes szem előtt tartani a DAG-ok tervezésekor.

Példa: Egy egyszerű Airflow DAG

Semmi sem erősíti meg jobban a fogalmakat, mint egy példa. Nézzük át egy egyszerű Airflow DAG kódot, és magyarázzuk el a részeit. Ez a példa egy kis munkafolyamatot hoz létre két egymást követő feladattal:

from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

# Define the DAG and its schedule
with DAG(
    dag_id="example_dag",
    description="A simple example DAG",
    start_date=datetime(2025, 1, 1),
    schedule_interval="@daily",  # runs daily
    catchup=False
) as dag:
    # Task 1: Print current date
    task1 = BashOperator(
        task_id="print_date",
        bash_command="date"
    )
    # Task 2: Echo a message
    task2 = BashOperator(
        task_id="echo_hello",
        bash_command="echo 'Hello, Airflow!'"
    )
    # Define dependency: task1 must run before task2
    task1 >> task2

Nézzük meg, mi történik itt:

• Importáljuk a szükséges osztályokat: DAG (a DAG definiálásához), és BashOperator (a feladatokban shell/bash parancsok futtatásához). Emellett importáljuk a datetime-et a DAG kezdő dátumának megadásához.
• Egy DAG objektumot hozunk létre egy kontextuskezelővel (with DAG(…) as dag:). Adjuk a DAG-nak az egyedi azonosítót “example_dag” (amely egy Airflow környezetben egyedinek kell lennie), egy leírást (opcionális, az emberi olvasás megkönnyítésére), egy start_date-t és egy schedule_interval-t. Itt egy beépített schedule_interval preset (@daily)-t állítunk be, valamint start_date=datetime(2025,1,1)-t. A catchup=False beállítást is megadtuk, hogy megakadályozzuk a hiányzó futások visszamenőleges pótolását a start_date és a mai nap között (csak a jövőben, napi rendszerességgel szeretnénk futtatni). Ez az egész blokk létrehoz egy DAG-ot, amelyet az Airflow érzékelni fog, hogy napi szinten a nap elején fusson.
• Ezután két feladatot definiálunk a DAG kontextusában:
• task1 a BashOperator segítségével van definiálva, hogy egy bash parancsot (date) hajtson végre. task_id “print_date”, és ezt fogják használni a feladat azonosítására a felhasználói felületen és a naplókban. Amikor fut, ez a feladat egyszerűen kiírja a jelenlegi dátumot/időt (a feladat naplójába).
• task2 szintén egy BashOperátort használ task_id=“echo_hello”, és parancs=echo ‘Hello, Airflow!’. Ehhez egy szép üzenetet fog kiírni. Ezek a feladatok jelenleg csak definiálva vannak, még nincsenek összekapcsolva.
• Az utolsó sor (task1 >> task2) egy függőséget (folyamatot) határoz meg: a task1 áramlik a task2-be. Ez azt jelenti, hogy a task1 lefut és sikeresen befejeződik, mielőtt a task2 ütemezésre kerülhetne. Grafikus formában, a DAG gráfon, egy nyíl mutat majd a task1-ből a task2-be.

Néhány dolog, amit érdemes megjegyezni ebben a példában:

• A BashOperátort csak az egyszerűség kedvéért használtuk, de használhattunk volna egy különböző típusú operátorokat vegyítő DAG-ot is. Lehetett volna egy PythonOperátor, amely egy Python függvényt hív meg, vagy egy SimpleHttpOperátor, amely egy API-t pingel, és így tovább.
• A with DAG(…) as dag: kontextus-minta egy gyakori kifejezés egy DAG példány létrehozására. Minden feladat, amelyet ezen belül hoznak létre, automatikusan ehhez a DAG-hoz kerül társításra.
• A catchup=False egy olyan paraméter, amelyet sok DAG-ban használnak, amikor a start_date a múltban van, és nem akarjuk, hogy minden múltbeli dátumra lefusson. Ha a catchup=True (alapértelmezett) maradt volna, és ma 2025. január 10-e van, az Airflow megpróbálná futtatni a DAG-ot január 1., 2., 3., … egészen január 10-ig, behozva a lemaradt napokat. Itt egyszerűség kedvéért kikapcsoltuk.
• Ez a példa a relatív import útvonalat használja a BashOperator számára. Az Airflow 2-ben sok operátort áthelyeztek az airflow.providers alá. Ez a példa azon feltételezésre íródott, hogy azok a szolgáltatók telepítve vannak (a BashOperator magában az Airflow-ban található).

Ezt az egyszerű példát könnyen bővíthetjük – hozzáadhatsz további feladatokat (például egy API hívást, majd az eredmények betöltését egy adatbázisba, majd értesítés küldését). Emellett bonyolultabb logikát is beilleszthetsz (például elágazás – az Airflow támogatja az if/else stílusú elágazást a BranchOperator segítségével).

Ahogy a DAG-jaid egyre nagyobbak lesznek, az Airflow felhasználói felülete és naplózása felbecsülhetetlenné válik annak kiderítésében, mi történik. Ebben a példában a print_date naplója tartalmazná a kiírt rendszeridőt, az echo_hello naplója pedig a „Hello, Airflow!” üzenetet. Ha a print_date meghiúsulna (például nem találja a date parancsot egy hipotetikus helyzetben), akkor az echo_hello soha nem kerülne végrehajtásra (a függőség miatt), és a DAG futása sikertelenként lenne jelölve. Ezután megvizsgálhatnád a naplót, javíthatnád a problémát, és újra lefuttathatnád a feladatot vagy az egész DAG-ot.

Gyakori felhasználási esetek az Airflow számára

Az alábbiakban egy strukturált összefoglalót találhat a gyakori Apache Airflow használati esetekről. A táblázat kiemeli, hogy melyik használati eset mit foglal magában, és hogyan ad értéket az Airflow ebben a kontextusban.

Mikor NE Használjuk az Airflow-t

Bár az Airflow hatékony, nem minden helyzetben a megfelelő eszköz. A korlátainak megértése segít a megfelelő szervezési megközelítés kiválasztásában:

• Valós idejű vagy streaming terhelések: Az Airflow batch-alapú, jól meghatározott kezdettel és véggel rendelkezik. Nem alkalmas hosszú futású, esemény-vezérelt vagy streaming terhelésekhez. Ha folyamatos eseménysorokat (felhasználói kattintások, IoT szenzorok stb.) kell feldolgoznod nagyon alacsony késleltetéssel valós időben, az Airflow nem a legjobb választás.
• Magas gyakoriságú vagy sok rövid feladat: Ez egy másik eset, amikor az Airflow esetleg nem működik, vagy legalábbis nem hatékonyan. Az Airflow feladatoknak van némi többletterhelése (az adatbázis követése stb. miatt), így ha minden pár másodpercben indítani kell valamit, vagy ha több ezer apró feladat van, az Airflow lehet, hogy nem skálázódik jól.
• Teljesen eseményvezérelt munkafolyamatok: Ez hasonló a streaming használati esetre, de olyasmire vonatkozik, amit egy eseménynek kell indítania. „Amikor X esemény történik, hajtsd végre Y” tökéletesen érvényes használati eset az Airflow számára, de ha az egyetlen dolog, ami ezt el kell indítsa, egy esemény (például „amikor egy fájl megérkezik egy S3 vödörbe, hajtsd végre X”), akkor az Airflow itt nem a legkönnyebb súlyú megoldás. Az Airflow általában érzékelőket használ (például S3KeySensor) a fájlok/események „észlelésére”. Az érzékelőknek vannak hátrányai, mivel lekérdezésre támaszkodnak. Az érzékelőkkel kapcsolatos problémák közé tartozik a meglévő fájlok indítása, és az, hogy nem feltétlenül reagálnak az eseményekre (például intervallumonként ellenőriznek).

Röviden, az Airflow alkalmas olyan munkafolyamatokhoz, amelyek periódikusak, kötegelt feldolgozásra épülnek, vagy összetettek a meghatározás és kezelés szempontjából. Nem biztos, hogy jó választás, ha az eseted valós idejű vagy folyamatos feldolgozást, ultragyakori feladatokat, vagy nagyon egyszerű munkafolyamatokat igényel, amelyekhez nincs szükség az Airflow fölösleges bonyolultságára. Ilyen esetben érdemes lehet más lehetőségeket is megvizsgálni, vagy egyszerűsíteni a megoldásodat.

Alternatívák az Airflow-hoz

Az munkafolyamat-orkesztrációs terület az utóbbi években robbanásszerűen bővült, és bár az Airflow élen jár, több alternatív eszköz is van, amit érdemes ismerni:

Az Airflow nem az egyetlen lehetőség, és a legjobb választás a felhasználási esettől függ. A Luigi, Prefect és Dagster gyakran szerepelnek azonos területen a főbb nyílt forráskódú alternatívák között (Python-alapú munkafolyamat-orkesztátorok). Ha az Airflow elavult felhasználói felülete vagy egyéb korlátai problémásak, érdemes mérlegelni ezek kiértékelését. A Prefect arra törekszik, hogy egy „jobb” vagy „egyszerűbb” Airflow legyen, a Dagster egy strukturáltabb orkesztátort próbál nyújtani az adatáruvagokra való fókuszálással, míg a Luigi az Airflow egyszerűbb elődje. Másrészt, ha a felhasználási eset jelentősen eltér (például valós idejű streamelés vagy teljesen felhőalapú), előfordulhat, hogy egyáltalán nem használod az Airflow-t, és közvetlenül streamelési platformokat vagy menedzselt orkesztációs szolgáltatásokat vesznek figyelembe.

Végső gondolatok

Az Apache Airflow egy nyílt forráskódú platform összetett számítási munkafolyamatok és adatfeldolgozási csővezetékek irányítására. Eredetileg az Airbnb-nél fejlesztették ki, és jelentős népszerűségre tett szert az adatfeldolgozási és gépi tanulási közösségek körében. Az Airflow komponensei közé tartozik egy ütemező, egy végrehajtó, dolgozók, egy metaadat-adatbázis és egy webalapú felhasználói felület. Ez lehetővé teszi a csapatok számára, hogy könnyen futtassák és karbantartsák a produkcióra kész ETL, MLOps és infrastruktúra csővezetékeket. Az Airflow DAG (irányított aciklikus gráf) absztrakciója lehetővé teszi, hogy a munkafolyamatok kifejezőek, tesztelhetők és hosszú távon is karbantarthatók legyenek. A platform közösség által épített operátorok és szolgáltatók ökoszisztémája szintén leegyszerűsíti az olyan munkafolyamat-irányítást, amely bármilyen technológiától vagy eszköztől függ.

Ez azonban nem egy mindenki számára megfelelő megoldás. Legjobban tömeges vagy mikro-tömeges feldolgozási folyamatoknál működik, és a felhasználóknak kényelmesen kell mozogniuk a Python nyelvben. Streaming vagy nagy gyakoriságú munkafolyamatok esetén más, az Airflownál alkalmasabb megoldások állnak rendelkezésre. Az adatos tudósoknak vagy azoknak a csapatoknak, akik deklaratív folyamatokat szeretnének írni, érdemes lehet fontolóra venni az Airflow alternatív eszközeit.

Az Airflow továbbra is aktívan fejlesztés alatt áll, és időről időre új funkciók kerülnek hozzáadásra, például eseményvezérelt ütemezés, adatállományok és erőforrások. A jelen útmutatóban bemutatott fogalmak és bevált gyakorlatok segítenek megérteni a munkafolyamat-orchesztráció működését és azt, hogy mikor érdemes (vagy nem érdemes) az Airflow-t használni, függetlenül a háttértudásodtól. Remélhetőleg ez egy ugródeszkaként szolgál majd ahhoz, hogy tovább fedezd fel ezt a gazdag univerzumot.

Források

• Apache Airflow
• Mi az az Airflow?
• Apache Airflow: Felhasználási esetek, architektúra és 6 tipp a sikerhez
• Kezdő útmutató az Airflow-hoz Dockerrel — Adatcsővezetékek a felhőben (I)
• 8 alternatíva az Airflow-ra – Felhasználási esetek
• Architektúra áttekintés
• Ütemező

Köszönjük, hogy a Linux-Console.net közösséggel tanultál.