Apache Airflow

Wat is Apache Airflow?

Apache Airflow is een open-source tool om datapijplijnen in te plannen, uit te voeren en te bewaken. Je schrijft je pijplijn uit als code in Python: welke taken er zijn, in welke volgorde ze moeten draaien en wanneer de keten start. Airflow doet de rest. Het plant de run in, voert elke taak op het juiste moment uit, probeert opnieuw bij een fout, houdt de taken tegen die van een gefaalde stap afhangen, en toont alles in een web-interface.

De taken en hun onderlinge volgorde beschrijf je als een DAG, een directed acyclic graph. Gericht betekent dat de pijlen tussen de taken één kant uitgaan, acyclisch dat je nooit in een cirkel belandt: taak A kan niet op B wachten terwijl B op A wacht. Die graaf is precies wat een orkestrator nodig heeft om te weten wat wanneer mag starten.

Airflow is gebouwd bij Airbnb in 2014, toen hun aantal datapijplijnen niet meer met losse scripts te overzien was. Het project werd het jaar daarop open source en is sinds 2019 een top-level project binnen de Apache Software Foundation. Vandaag draait het in veel datateams die hun data-orkestratie als code willen beheren. Airflow 3, de eerste grote nieuwe versie in jaren, verscheen in 2025.

Waarom niet gewoon een cron job per taak? Omdat cron alleen naar de klok kijkt. Plan je de transformatie om 3u omdat de extractie meestal om 2u klaar is, dan draait die transformatie ook op de dag dat de extractie uitloopt, en verwerkt ze halve data. Niemand krijgt een melding, want technisch is er niets gefaald. Airflow haalt die gok eruit: je zegt niet "draai om 3u" maar "draai zodra de extractie klaar is". De afhankelijkheid staat in de graaf, niet in een los tijdstip.

De onderdelen van Airflow

DAG en taak

Een DAG is één pijplijn: de verzameling taken plus de pijlen die zeggen welke taak op welke wacht. Een taak is één stap in die pijplijn, bijvoorbeeld een tabel ophalen, een SQL-transformatie draaien of een rapport verversen. Je legt de volgorde vast door taken aan elkaar te koppelen.

Operator

Een operator is een kant-en-klaar sjabloon voor een taak. Er bestaat een operator om een bash-commando te draaien, een Python-functie uit te voeren, een query op een database los te laten of een dienst in de cloud aan te spreken. In plaats van elke koppeling zelf te schrijven, kies je de operator die past en vult je de details in. De gemeenschap rond Airflow onderhoudt honderden operators voor zowat elke gangbare bron en cloud.

Scheduler en workers

De scheduler is het hart van Airflow. Die leest je DAG's, beslist welke taken klaar zijn om te draaien en deelt ze uit. Het echte werk gebeurt op de workers: de rekenkracht die de taken uitvoert. Bij weinig werk draait alles op één machine, bij veel werk verdeel je de taken over meerdere workers die parallel doorwerken.

De web-interface

Op één scherm zie je welke DAG's lopen, wat geslaagd is en wat faalde, met de logs per taak erbij. Vanuit datzelfde scherm start je een run handmatig of bekijk je waarom een taak drie keer opnieuw probeerde. Dat overzicht is vaak de reden waarom teams voor Airflow kiezen: als er 's nachts iets misgaat, zoek je 's ochtends op één plek in plaats van in vijf verschillende logbestanden.

Een nachtelijke pijplijn in de praktijk

Neem een groothandel met een webshop, een boekhoudpakket en een managementrapport in Microsoft Fabric. De nachtelijke DAG ziet er zo uit:

1. Twee extractie-taken halen parallel de bestellingen uit de webshop en de facturen uit de boekhouding op.

2. Een load-taak schrijft die ruwe data naar het warehouse. Ze start pas als beide extracties geslaagd zijn.

3. Een dbt-taak draait de transformaties: opkuisen, koppelen, marge per productgroep berekenen.

4. Een kwaliteitscheck telt de rijen en controleert of de datums van vannacht zijn.

5. Pas als die check groen is, trapt de laatste taak de refresh van het Power BI-rapport af.

Antwoordt de webshop-API even niet, dan probeert Airflow die ene extractie automatisch opnieuw, met een wachttijd ertussen. Blijft ze falen, dan stopt de keten daar en toont het rapport de cijfers van gisteren, niet de halve cijfers van vannacht. Precies dat wil je: liever een dag oud dan half fout.

Waar Airflow past, en de managed opties

Airflow is op zijn plek bij ETL/ELT in batch: pakketten data die op vaste momenten van bron naar warehouse stromen. Het blinkt uit wanneer je veel taken hebt, veel maatwerk, of orkestratie over meerdere platformen heen. Voor drie losse taken die niets met elkaar te maken hebben is het te zwaar, daar volstaat een geplande refresh of een cron job.

De keerzijde van code-first is dat je Airflow ook moet draaien en onderhouden: de scheduler, de workers, de database eronder, de upgrades. Wie dat niet zelf wil beheren, neemt een managed versie:

• Astronomer (Astro) is het commerciële platform van het bedrijf achter veel Airflow-ontwikkeling. Zij hosten en schalen Airflow voor je.

• Amazon MWAA (Managed Workflows for Apache Airflow) draait Airflow binnen AWS, met workers die automatisch mee schalen en logs die naar CloudWatch stromen.

• Google Cloud Composer is de managed Airflow-dienst op Google Cloud.

In alle drie schrijf je dezelfde DAG's in Python. Je betaalt om het onderhoud van de infrastructuur niet zelf te doen.

Airflow versus Dagster en Fabric-pipelines

Tegenover Dagster. Airflow denkt in taken: doe dit, dan dat. Dagster, een nieuwere orkestrator, denkt in data-assets: dit zijn de tabellen die ik beheer en zo hangen ze samen. Dat asset-model geeft van nature meer zicht op lineage en maakt lokaal ontwikkelen en testen makkelijker. Airflow heeft dat idee intussen deels overgenomen, maar blijft in de kern taak-gericht. Waar Airflow wint, is volwassenheid: meer operators, een grotere gemeenschap en veel meer mensen op de arbeidsmarkt die het al kennen.

Tegenover Fabric-pipelines. Zit je platform volledig binnen Microsoft Fabric, dan heb je met de ingebouwde Data Pipelines vaak al een orkestrator bij de hand. Die bouw je visueel op een canvas in plaats van in code. Airflow loont wanneer je orkestratie over Fabric heen reikt, meer maatwerk vraagt, of je pijplijnen als code met versiebeheer en tests wil beheren. Fabric kan trouwens zelf Airflow-jobs draaien, dus het is geen harde of-of-keuze.

Waar moet je op letten bij het gebruik van Airflow

Retries vragen idempotente taken. Airflow probeert een gefaalde taak automatisch opnieuw. Dat is pas veilig als twee keer draaien hetzelfde resultaat geeft als één keer. Een taak die bij elke run rijen toevoegt, maakt van elke retry dubbele data. Maak de taak eerst herhaalbaar, zet de retries pas daarna aan.

Het is geen streaming-tool. Airflow plant runs in, het verwerkt geen continue stroom events per seconde. Moet er binnen enkele seconden op data gereageerd worden, dan zit je bij een streaming-oplossing, niet bij Airflow.

Het vraagt een technisch profiel. DAG's zijn Python, en de infrastructuur eronder wil onderhoud. Zonder iemand die Python en de werking van Airflow kent, wordt de tool zelf een last. Een managed versie neemt het infrastructuurwerk over, maar de DAG's blijf je in code schrijven.

Alert-moeheid. Als elke kleine hapering een melding stuurt, kijkt na twee weken niemand er nog naar. Stel alerts in op wat echt actie vraagt, en laat de rest in de logs staan.

FAQ over Apache Airflow

1. Is Airflow hetzelfde als ETL?
Nee. ETL is het werk zelf: data ophalen, transformeren en laden. Airflow beslist wanneer dat werk draait, in welke volgorde, en wat er gebeurt als een stap faalt. De transformatie zelf laat je vaak aan een tool als dbt over.

2. Moet ik kunnen programmeren om Airflow te gebruiken?
Ja. Je DAG's schrijf je in Python. Wil je liever visueel klikken, dan pas je beter bij Fabric Data Pipelines of Azure Data Factory.

3. Wat is een backfill?
Een backfill draait je pijplijn opnieuw voor het verleden. Vind je een fout in een transformatie, dan laat je Airflow de voorbije periode dag per dag opnieuw verwerken, in plaats van zelf scripts te knutselen.