Apache Airflow Uitgelegd: Een Beginnersvriendelijke Gids

Inleiding

Moderne datagestuurde bedrijven vertrouwen allemaal op datastromen die informatie van de ene locatie naar de andere ophalen, transformeren, verrijken en verplaatsen. Deze datastromen kunnen veel stappen omvatten (het extraheren van ruwe data, het opschonen ervan, het trainen van machine learning-modellen, het bouwen van dashboards, enz.). Bovendien moeten ze in een zeer specifieke volgorde worden uitgevoerd. Workflow-orchestratiehulpmiddelen zoals Apache Airflow helpen ervoor te zorgen dat al deze stappen op het juiste moment en in de juiste volgorde worden uitgevoerd. Ze maken het ook gemakkelijk om de datastromen te monitoren en te beheren.

Airflow is in 2014 bij Airbnb ontwikkeld en is uitgegroeid tot een van de populairste open‑source platforms voor workflow‑orkestratie. Het wordt door duizenden organisaties gebruikt om batchpijplijnen te automatiseren en te monitoren. In dit artikel leggen we Apache Airflow van de basis tot het volledige overzicht uit. Onderwerpen die we zullen behandelen zijn:

• Wat Airflow is, wat het doet en waarom datateams het gebruiken.
• De kernconcepten en componenten van Airflow, en hoe ze op elkaar aansluiten.
• Hoe pijplijnen worden gedefinieerd als Gerichte Acyclische Grafen (DAG's) en een rondleiding door een eenvoudig DAG in actie.
• Veelvoorkomende gebruikssituaties zoals ETL/ELT, MLOps en meer.

We hopen dat dit een praktische, aan voorbeelden gerelateerde introductie tot Apache Airflow zal zijn voor ingenieurs, studenten en teams die net beginnen met workflow‑orkestratie.

Belangrijkste punten

• Apache Airflow is een op Python gebaseerd platform voor workfloworkestratie dat complexe datapijpleidingen beheert, plant en bewaakt met behulp van DAG's (Directed Acyclic Graphs).
• DAG's definiëren taken en hun afhankelijkheden, waardoor Airflow elke stap in de juiste volgorde kan uitvoeren met ingebouwde herhaalde pogingen, logging en observeerbaarheid.
• De architectuur van Airflow (Scheduler, Executor, Worker, Metadata DB, Web UI) maakt schaalbare, gedistribueerde uitvoering en realtime monitoring van pipelines mogelijk.
• Airflow blinkt uit in batchworkflows zoals ETL/ELT-taken, ML-trainingspijplijnen, kwaliteitscontroles van gegevens en geplande analyses — maar is niet ideaal voor real-time of extreem hoge-frequentieworkloads.
• Alternatieven zoals Prefect, Dagster, Luigi, Argo Workflows en Mage AI kunnen beter geschikt zijn, afhankelijk van behoeften zoals event-driven workflows, Kubernetes-native uitvoering of moderne, gebruiksvriendelijke interfaces voor ontwikkelaars.

Wat is Apache Airflow?

Apache Airflow is een open-source systeem voor het maken, plannen en monitoren van workflows. Een Airflow-workflow is een DAG (een gerichte acyclische graaf), wat een reeks taken is met duidelijk gedefinieerde relaties (afhankelijkheden) en zonder enige cycli (een taak kan zichzelf niet stroomopwaarts herhalen). De kernfilosofie van Airflow is "configuratie als code", dus in plaats van een gebruikersinterface met slepen-en-neerzetten te gebruiken, schrijf je Python-scripts om workflows weer te geven. Deze aanpak biedt aanzienlijke flexibiliteit voor ingenieurs: je kunt met bijna elke technologie verbinden via de operators van Airflow en Python-bibliotheken. Je kunt ook best practices uit de software engineering toepassen (versiebeheer, testen, enz.) op je pijplijndefinities.

Waarom is workfloworchestratie belangrijk?

Het belangrijkste punt is dat je vaak meerdere stappen in een gegevensworkflow hebt die in volgorde moeten worden uitgevoerd. Een eenvoudig voorbeeld is de ETL (Extract/Transform/Load) pipeline. Pipelines kunnen snel complexer worden naarmate je meer taken, afhankelijkheden, vertakkingen, enzovoort toevoegt, en ze moeten ook regelmatig worden uitgevoerd. Handmatige tussenkomst of eenvoudige planningshulpmiddelen blijken in deze gevallen vaak onvoldoende. Airflow lost dit op door te fungeren als een centrale orkestrator. Het heeft een gerichte acyclische graaf (DAG) van taken (knopen) met afhankelijkheden (kanten). Het weet wanneer welke taak moet worden uitgevoerd (wachtend op het voltooien van upstream-afhankelijkheden voordat het wordt uitgevoerd), inclusief planning (periodieke uitvoering), foutafhandeling (automatische herhalingen, meldingen) en logging.

Als we de hele datastroom als een recept beschouwen, dan is elke afzonderlijke taak een sub-stap (snijden, koken, opmaken, enz.). Airflow is als de keukenmanager die de recepten kent en een oogje houdt op alle verschillende sub-stappen die in elke keuken gebeuren, en ervoor zorgt dat alles in de juiste volgorde en op het juiste moment gebeurt.

Zonder workfloworkestratie kun je over alle chef-koks en ingrediënten beschikken, maar ze zijn niet op elkaar afgestemd. Airflow zorgt voor die coördinatie, waardoor de productie van het gewenste ‘gerecht’ (workflow uitvoering) mogelijk wordt.

Waarom gebruiken datateams Airflow?

Airflow is populair geworden onder data-engineers, ML-engineers en DevOps-teams omdat het veel behoeften van complexe datapijplijnen aanpakt. Hier zijn een paar belangrijke redenen waarom teams voor Airflow kiezen:

• Het orkestreren van complexe workflows en afhankelijkheden: Airflow is ontworpen voor workflows met een groot aantal onderling afhankelijke stappen. Airflow maakt het eenvoudig om upstream- en downstream-vereisten te declareren, zodat taken in de juiste volgorde worden uitgevoerd. Als taak C afhankelijk is van taken A en B, is de Airflow-planner zich bewust van deze relaties en zorgt ervoor dat A en B worden uitgevoerd (mogelijk parallel) voordat C wordt uitgevoerd. Airflow kan omgaan met complexe afhankelijkheden, vertakkingslogica, enz.
• Gecentraliseerde planning (Cron op steroïden): Het biedt een planner waarmee je taken op een bepaald schema kunt uitvoeren. Je kunt tientallen of honderden pipelines definiëren die taken op verschillende tijdstippen activeren (elk uur, dagelijks, maandelijks) met de scheduler van Airflow. Airflow begrijpt de relaties tussen taken. Het kan taken intelligent plannen en activeren om te worden uitgevoerd. De centrale planner bevrijdt je van het schrijven van verschillende scripts op verschillende servers.

• Schaalbaarheid en gedistribueerde uitvoering: Airflow kan ook meegroeien met je workflows. Het kan worden geconfigureerd om taken parallel uit te voeren over meerdere werkprocessen of machines. Het biedt ook meerdere uitvoerders (later in dit artikel besproken) die taken kunnen uitvoeren op gedistribueerde systemen zoals Celery of Kubernetes over een cluster van knooppunten. Dit betekent dat je zware taken (big data-verwerking) kunt paralleliseren en meerdere pipelines gelijktijdig kunt laten lopen.
• Monitoring, Logboeken en Waarschuwingen: Het wordt geleverd met een uitgebreide webinterface die realtime inzicht biedt in je workflows. Je kunt zien welke taken zijn geslaagd en welke zijn mislukt, en de loguitvoer voor elke taak bekijken. Je kunt taken zelfs handmatig activeren en/of opnieuw proberen via de webinterface.

Belangrijke Componenten van Luchtstroom

Hieronder vindt u een kort overzicht van de kerncomponenten van Apache Airflow. Gebruik deze tabel als een snelle referentie om te begrijpen wat elk onderdeel is en wat het doet.

Hoe Airflow Werkt (Architectuur)

Hier is een stapsgewijze overzicht van hoe Airflow een workflow (DAG) verwerkt:

• Het maken van de DAG: De auteur van de DAG schrijft een Python-script dat een DAG definieert. Dit script bevat zaken zoals het schema (bijv. “dagelijks om 9 uur”) of handmatige triggerinstellingen. Het bevat ook de definities van de taken (via operators of @task-functies), evenals de afhankelijkheden tussen taken (bijv. task1 >> task2 (task2 wacht tot task1 is voltooid)). Het Python-bestand wordt opgeslagen in de DAGs-map van Airflow zodat Airflow het kan vinden. Airflow zal dit bestand periodiek lezen (parsen) om de DAG-definitie te laden.
• Plannen en DAG-parsing: Airflow Scheduler is een proces dat continu op de achtergrond draait. Het controleert of elke DAG moet worden uitgevoerd op basis van het schema of de triggers. Bijvoorbeeld, een DAG met een schema van “dagelijks” kan door de scheduler worden opgepakt, en merkt op dat er een nieuwe uitvoering om middernacht moet worden gepland. Airflow Scheduler controleert ook of taken binnen DAG's klaar zijn om te worden uitgevoerd – wat betekent dat al hun upstream-afhankelijkheden zijn voltooid en dat hun geplande tijd (logische datum) is aangebroken.
• Uitvoeren van taken: Elke uit te voeren taak wordt overgedragen aan de Executor door de Scheduler. De executor beslist waar en hoe de taak wordt uitgevoerd. Het kan lokaal worden uitgevoerd of naar een werkerswachtrij worden gestuurd. Voor een gedistribueerde architectuur wordt de taak aan een wachtrij toegevoegd en vervolgens geselecteerd door Worker-processen die de taken uitvoeren.
• Status- en foutafhandeling bijwerken: Elke taakinstantie rapporteert zijn status (succes, mislukking, enz.) terug aan de scheduler zodra deze is voltooid, en de scheduler werkt zijn metadata-database bij met de taakstatus.
  Statustracking is wat de scheduler in staat stelt te weten wat hij vervolgens moet doen – bijvoorbeeld, als Taak A succesvol is afgerond, weet hij dat hij Taak B nu kan plannen, of als Taak A is mislukt met nog beschikbare pogingen, plant hij een herhaling, of als hij is mislukt zonder resterende pogingen, markeert hij de DAG-run als mislukt. Als een taak faalt, heeft Airflow een logica om de taak automatisch opnieuw te proberen als dit is geconfigureerd voor herhalingen. Als de taak blijft falen na herhaalde pogingen, kan Airflow een melding sturen bij fouten (bijvoorbeeld een e-mail of een Slack-bericht, enz.). Dit alles is configureerbaar als onderdeel van de DAG- of taakparameters (bijvoorbeeld het aantal herhalingen, wachttijd tussen herhalingen, e-mail om te verzenden bij een melding).
• Monitoring en interventie: Airflow Web UI biedt een live-interface van het bovenstaande proces. Je kunt een DAG-run zien verschijnen (bijvoorbeeld een nieuwe regel in de Tree-weergave voor een run van vandaag) en de taakstatussen volgen terwijl ze vorderen. De Graph-weergave visualiseert de taken van de DAG en toont welke voltooid zijn of een fout hebben gehad.
• Opschonen en Volgende Run: Wanneer een DAG-run is voltooid (alle taken zijn geslaagd of overgeslagen/mislukt), gaat Airflow verder met de volgende geplande run. Alle metadata over eerdere runs wordt nog steeds in de database bewaard, en je kunt de geschiedenis altijd controleren. De scheduler blijft nieuwe runs starten volgens het schema of handmatige activering. Dit proces wordt herhaald totdat het Airflow-proces wordt beëindigd.

Het begrijpen van DAG's in Airflow

Een DAG in Airflow definieert het schema, en de taken en afhankelijkheden die nodig zijn om een workflow uit te voeren. Een DAG hoeft niet te weten wat er in elke taak zit; het hoeft alleen te definiëren wanneer en in welke volgorde ze moeten worden uitgevoerd.

Taken, operators en sensoren

Taken zijn de basiswerkunits in Airflow. In Airflow zijn taken instanties van operators, die sjablonen zijn voor vooraf gedefinieerde acties. Airflow wordt geleverd met een verscheidenheid aan kernoperators. De BashOperator stelt je in staat shell-opdrachten uit te voeren, en de PythonOperator stelt je in staat Python-functies aan te roepen. Airflow biedt ook een @task decorator, waarmee je een gewone Python-functie kunt omzetten in een taak.

Naast operators biedt Airflow ook sensoren. Sensoren zijn taken die wachten tot aan een bepaalde voorwaarde of gebeurtenis is voldaan voordat ze slagen. Ze kunnen worden gebruikt voor zaken zoals wachten tot een bestand verschijnt of een tabel wordt gevuld.

Taakafhankelijkheden

Om afhankelijkheden tussen taken aan te geven, gebruik je de >> en << operatoren (aanbevolen) of methoden zoals set_upstream en set_downstream. Het is ook mogelijk om taken aan elkaar te koppelen, kruis‑downstream afhankelijkheden te creëren en zelfs dynamisch lijsten van taken op te bouwen. Een DAG zonder enige afhankelijkheden zou gewoon een onafhankelijke set taken zijn.

Beste praktijken voor DAG-ontwerp

De onderstaande tabel geeft een paar richtlijnen weer om in gedachten te houden bij het ontwerpen van DAG's.

Voorbeeld: Een eenvoudige Airflow DAG

Niets maakt concepten duidelijker dan een voorbeeld. Laten we een eenvoudige Airflow DAG-code doorlopen en de onderdelen uitleggen. Dit voorbeeld zal een kleine workflow maken met twee taken achter elkaar:

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

Laten we eens bekijken wat hier aan de hand is:

• importeer de vereiste klassen DAG (om de DAG te definiëren) en BashOperator (om shell/bash-commando's in taken uit te voeren). We importeren ook datetime om de startdatum van de DAG op te geven.
• We maken een DAG-object met een contextmanager (with DAG(…) as dag:). Geef de DAG een unieke ID “example_dag” (moet uniek zijn in een Airflow-omgeving), een beschrijving (optioneel, om het voor mensen leesbaar te maken), een start_date en een schedule_interval. Hier stellen we een ingebouwde schedule_interval preset (@daily) in en start_date=datetime(2025,1,1). We hebben ook catchup=False ingesteld om te voorkomen dat ontbrekende runs tussen de start_date en vandaag worden ingehaald (we willen dat het alleen vanaf nu dagelijks draait). Deze hele blok creëert een DAG waarvan Airflow op de hoogte zal worden gemaakt om dagelijks aan het begin van de dag te draaien.
• We definiëren vervolgens twee taken in de context van de DAG:
• task1 is gedefinieerd met behulp van BashOperator om een bash-opdracht uit te voeren (date). task_id is “print_date” en zal worden gebruikt om deze taak te identificeren in de gebruikersinterface en in de logs. Wanneer deze taak wordt uitgevoerd, zal het eenvoudig het huidige datum/tijd afdrukken (naar de log van de taak).
• task2 ook gebruikt een BashOperator met task_id=“echo_hello ”, en command=echo 'Hello, Airflow!'. Dit zal een leuk bericht printen. Deze taken zijn op dit moment alleen gedefinieerd, nog niet gekoppeld.
• De laatste regel (task1 >> task2) geeft een afhankelijkheid (stroom) aan: task1 stroomt naar task2. Dit betekent dat taak 1 zal worden uitgevoerd en succesvol wordt voltooid voordat taak 2 in overweging wordt genomen om gepland te worden. Grafisch, in de DAG-grafiek, zal er een pijl zijn die van task1 naar task2 wijst.

Enkele dingen om op te merken in dit voorbeeld:

• We hebben alleen BashOperator gebruikt om het simpel te houden, maar we hadden een DAG met gemengde soorten operators kunnen gebruiken. We hadden een PythonOperator kunnen hebben om een Python-functie aan te roepen, of een SimpleHttpOperator om een API te pingen, enzovoort.
• De met DAG(…) als dag: contextpatroon is een veelgebruikte uitdrukking om een DAG-instantie te maken. Alle taken die daarin worden gemaakt, worden automatisch aan die DAG gekoppeld.
• catchup=False is een parameter die in veel DAG's wordt gebruikt met een startdatum in het verleden, wanneer je niet wilt dat deze voor alle voorgaande datums wordt uitgevoerd. Als we catchup=True (de standaardwaarde) zouden laten staan en het vandaag 10 januari 2025 was, zou Airflow proberen de DAG uit te voeren voor 1, 2, 3 januari, … tot en met 10 januari, waardoor de gemiste dagen in een achterstand zouden worden ingehaald. Hier hebben we het uitgeschakeld voor de eenvoud.
• Dit voorbeeld gebruikt het relatieve importpad voor BashOperator. In Airflow 2 zijn veel van de operators verplaatst naar airflow.providers. Dit voorbeeld is geschreven onder de veronderstelling dat die providers zijn geïnstalleerd (BashOperator zit in de kern van Airflow zelf).

Dit eenvoudige voorbeeld kan gemakkelijk worden uitgebreid – je kunt extra taken toevoegen (misschien een API-aanroep doen, vervolgens de resultaten in een database laden en daarna een melding verzenden). Je kunt ook complexere logica toevoegen (zoals vertakkingen – Airflow ondersteunt if/else-achtige vertakkingen met de BranchOperator, bijvoorbeeld).

Naarmate je DAG's groter worden, worden de UI en logging van Airflow onmisbaar om te begrijpen wat er gaande is. In dit voorbeeld zou het logboek voor print_date de systeemdatum bevatten die werd weergegeven, en het logboek voor echo_hello zou "Hello, Airflow!" bevatten. Als print_date zou falen (misschien kon het de date-opdracht niet vinden, in een hypothetisch scenario), dan zou echo_hello nooit worden uitgevoerd (vanwege de afhankelijkheid), en zou de uitvoering van de DAG als mislukt worden gemarkeerd. Je zou dan het logboek kunnen inspecteren, het probleem kunnen oplossen en die taak of de hele DAG opnieuw kunnen uitvoeren.

Veelvoorkomende gebruikstoepassingen voor Airflow

Hieronder volgt een gestructureerde samenvatting van veelvoorkomende gebruiksscenario's van Apache Airflow. De tabel benadrukt wat elk gebruiksscenario inhoudt en hoe Airflow in die context waarde toevoegt.

Wanneer je Airflow NIET moet gebruiken

Hoewel Airflow krachtig is, is het niet het juiste hulpmiddel voor elke situatie. Het begrijpen van de beperkingen helpt je de juiste orkestratie-aanpak te kiezen:

• Realtime- of streamingwerklasten: Airflow is batchgericht met een duidelijk begin en einde. Het is niet bedoeld voor langlopende, gebeurtenisgestuurde of streamingwerklasten. Als je continue stromen van gebeurtenissen (gebruikersklikken, IoT-sensoren, enz.) binnenkrijgt en deze met zeer lage latentie in realtime moet verwerken, is Airflow niet de beste keuze.
• Hoge frequentie of veel korte taken: Dit is een ander geval waarin Airflow mogelijk niet werkt, of in ieder geval niet efficiënt. Airflow-taken hebben wat overhead (bij het bijhouden in de database, enz.), dus als je iets elke paar seconden moet uitvoeren of duizenden kleine taken hebt, kan Airflow mogelijk niet goed schalen.
• Zuiver op gebeurtenissen gebaseerde workflows: Dit is vergelijkbaar met het streaming-gebruiksscenario, maar dan voor iets dat door een gebeurtenis moet worden geactiveerd. „Telkens wanneer een gebeurtenis X plaatsvindt, doe Y” is een volwaardig gebruiksscenario voor Airflow, maar als het enige dat die gebeurtenis moet activeren een gebeurtenis is (bijvoorbeeld „telkens wanneer een bestand in een S3-bucket aankomt, doe X”), dan is Airflow hier niet de meest lichte oplossing. Airflow gebruikt doorgaans sensoren (bijvoorbeeld S3KeySensor) om de aanwezigheid van bestanden/gebeurtenissen te „detecteren”. Sensores hebben nadelen omdat ze afhankelijk zijn van polling. Problemen met sensoren zijn onder andere dat ze kunnen triggeren op bestaande bestanden en niet noodzakelijkerwijs responsief zijn op gebeurtenissen (bijvoorbeeld omdat ze op vaste intervallen polleren).

Kortom, Airflow is geschikt voor workflows die periodiek zijn, batchgericht, of complex om te definiëren en te beheren. Het is mogelijk niet geschikt als je gebruikssituatie real-time of continue verwerking vereist, extreem frequente taken, of zeer eenvoudige workflows die de overhead van Airflow niet nodig hebben. In dat geval wil je misschien andere opties onderzoeken of je oplossing vereenvoudigen.

Alternatieven voor Airflow

De ruimte voor workflow-orchestratie is de afgelopen jaren enorm gegroeid, en hoewel Airflow een leider is, zijn er verschillende alternatieve tools die het waard zijn om te kennen:

Airflow is niet de enige optie die beschikbaar is, en de beste keuze hangt af van je gebruikssituatie. Luigi, Prefect en Dagster worden vaak genoemd als de belangrijkste andere open-source opties in hetzelfde domein (Python-gebaseerde workflow-orchestrators). Als je Airflow’s verouderde gebruikersinterface of andere beperkingen omslachtig vindt, zou je deze moeten overwegen. Prefect probeert een “betere” of “eenvoudigere” versie van Airflow te zijn, Dagster probeert een meer “gestructureerde” orchestrator te zijn met de nadruk op data-assets, en Luigi is een eenvoudigere voorganger van Airflow. Aan de andere kant, als je gebruikssituatie sterk afwijkt (bijvoorbeeld real-time streaming of volledig cloud-native), gebruik je mogelijk helemaal geen Airflow en overweeg je direct streamingplatforms of beheerde orchestratieservices.

Laatste gedachten

Apache Airflow is een open-source platform om complexe computationele workflows en dataverwerkingspijplijnen te orkestreren. Oorspronkelijk ontwikkeld bij Airbnb, heeft het aanzienlijke populariteit verworven binnen de data-engineering en machine learning gemeenschappen. De componenten van Airflow omvatten een scheduler, een executor, workers, een metadatadatabase en een webgebaseerde UI. Dit stelt teams in staat om eenvoudig productieklare ETL-, MLOps- en infrastructuurpijplijnen uit te voeren en te onderhouden. De DAG (Directed Acyclic Graph) abstractie van Airflow maakt het mogelijk workflows expliciet, testbaar en onderhoudbaar te houden in de loop van de tijd. Het ecosysteem van door de community gebouwde operators en providers vereenvoudigt ook de workfloworkestratie die afhankelijk is van elke technologie of tool.

Het is echter geen oplossing die voor iedereen geschikt is. Het werkt het beste met batch- of micro-batchpijplijnen, en gebruikers moeten vertrouwd zijn met Python. Voor streaming- of hoge-frequentieworkflows zijn er andere oplossingen die geschikter zijn dan Airflow. Voor datawetenschappers of teams die de voorkeur geven aan het schrijven van declaratieve pijplijnen, kunnen alternatieve tools voor Airflow het overwegen waard zijn.

Airflow wordt nog steeds actief ontwikkeld, en er worden voortdurend nieuwe functies toegevoegd, zoals gebeurtenisgestuurde planning, datasets en assets. De concepten en best practices die in deze gids worden geïntroduceerd, zouden je, ongeacht je achtergrond, moeten helpen te begrijpen hoe workfloworchestratie werkt en wanneer Airflow gebruikt (of niet gebruikt) zou moeten worden. Hopelijk dient dit als een opstap om dit rijke universum verder te verkennen.

Referenties

• Apache Airflow
• Wat is Airflow?
• Apache Airflow: Gebruiksmogelijkheden, Architectuur en 6 Tips voor Succes
• Een beginnersintroductie tot Airflow met Docker — Datapijplijnen in de cloud (I)
• 8 Alternatieven voor Airflow - Gebruiksscenario's
• Architectuuroverzicht
• Planner

Bedankt dat je samen met de Linux-Console.net-community hebt geleerd.