Apache Airflow in 2026: Pipeline Orchestratie, DAGs en Sollicitatievragen

Apache Airflow blijft in 2026 de dominante keuze voor data pipeline orchestratie in enterprise-omgevingen. Met de release van versie 3.2 introduceert het platform fundamentele verbeteringen die de kloof met nieuwere alternatieven zoals Prefect en Dagster verkleinen. De nieuwe Task SDK vereenvoudigt DAG-authoring aanzienlijk, terwijl native async-ondersteuning en verbeterde asset-awareness moderne dataworkflows naar een hoger niveau tillen. Voor data engineers die hun carriere willen versterken, is een grondige kennis van Airflow essentieel geworden.

DAG Authoring met de Task SDK

De introductie van airflow.sdk transformeert de manier waarop data engineers DAGs bouwen. Het traditionele model met expliciete operator-instantiaties maakt plaats voor een declaratieve aanpak gebaseerd op Python decorators. Deze paradigmaverschuiving resulteert in code die leesbaarder, testbaarder en beter onderhoudbaar is.

Een typische ETL-pipeline voor dagelijkse omzetberekeningen demonstreert de kracht van de nieuwe SDK:

# etl_daily_revenue.py
import pendulum
from airflow.sdk import dag, task

@dag(
    schedule="@daily",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["finance", "etl"],
)
def etl_daily_revenue():
    @task()
    def extract_transactions() -> list[dict]:
        # Pulls raw transactions from the payments API
        import requests
        response = requests.get("https://api.internal/payments/daily")
        return response.json()["transactions"]

    @task(multiple_outputs=True)
    def transform(transactions: list[dict]) -> dict:
        # Aggregates by currency and computes totals
        totals = {}
        for tx in transactions:
            currency = tx["currency"]
            totals[currency] = totals.get(currency, 0) + tx["amount"]
        return {"totals": totals, "count": len(transactions)}

    @task()
    def load(totals: dict, count: int):
        # Inserts aggregated row into the warehouse
        from warehouse import insert_revenue_summary
        insert_revenue_summary(totals=totals, transaction_count=count)

    raw = extract_transactions()
    result = transform(raw)
    load(result["totals"], result["count"])

etl_daily_revenue()

De @dag decorator definieert metadata zoals scheduling en tags, terwijl @task individuele bewerkingen markeert. Type hints worden automatisch gevalideerd, wat runtime-fouten voorkomt. De multiple_outputs=True parameter maakt het mogelijk om meerdere waarden terug te geven die downstream tasks afzonderlijk kunnen consumeren.

Dynamic Task Mapping

Moderne datapipelines vereisen flexibiliteit bij het verwerken van variabele datasets. Dynamic Task Mapping lost dit probleem elegant op door task-instanties programmatisch te genereren op basis van runtime-data. In plaats van hardcoded loops of complexe templating biedt de .expand() methode een declaratieve manier om parallelle verwerking te implementeren.

# etl_multi_region.py
import pendulum
from airflow.sdk import dag, task

@dag(
    schedule="@hourly",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["regional", "etl"],
)
def etl_multi_region():
    @task()
    def get_regions() -> list[str]:
        # Returns the active regions from config
        return ["us-east-1", "eu-west-1", "ap-southeast-1"]

    @task()
    def process_region(region: str) -> dict:
        # Processes events for a single region
        from data_processor import aggregate_events
        return aggregate_events(region)

    @task()
    def merge_results(results: list[dict]):
        # Combines all regional outputs into a single report
        from reporter import publish_global_report
        publish_global_report(results)

    regions = get_regions()
    # .expand() creates one mapped task instance per region
    processed = process_region.expand(region=regions)
    merge_results(processed)

etl_multi_region()

Het aantal regio's is onbekend tijdens DAG-parsing maar wordt bepaald tijdens runtime. Airflow creert automatisch parallelle task instances voor elke regio, waarbij de scheduler zorgt voor optimale resource-allocatie. De downstream merge_results task wacht automatisch tot alle mapped instances voltooid zijn.

Asset Partities en Data-Aware Scheduling

Asset-aware scheduling vertegenwoordigt een fundamentele verschuiving van tijdgebaseerde naar datagedreven orchestratie. In plaats van pipelines te triggeren op vaste tijdstippen, reageert Airflow op de beschikbaarheid van upstream data-assets. Versie 3.2 breidt dit concept uit met partitie-awareness, waardoor pipelines kunnen wachten op specifieke tijdssegmenten van meerdere bronnen.

# downstream_analytics.py
import pendulum
from airflow.sdk import dag, task
from airflow.timetables.assets import CronPartitionTimetable

# Define partitioned assets with hourly granularity
nba_stats = Asset("s3://datalake/nba/hourly/", partitions=CronPartitionTimetable("0 * * * *"))
epl_stats = Asset("s3://datalake/epl/hourly/", partitions=CronPartitionTimetable("0 * * * *"))
nfl_stats = Asset("s3://datalake/nfl/hourly/", partitions=CronPartitionTimetable("0 * * * *"))

@dag(
    # Triggers only when all three assets have matching partition
    schedule=(nba_stats & epl_stats & nfl_stats),
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
)
def unified_sports_analytics():
    @task()
    def aggregate_all_leagues(**context):
        partition = context["partition"]
        # Process only the specific hourly slice across all leagues
        from analytics import build_cross_league_report
        build_cross_league_report(partition=partition)

    aggregate_all_leagues()

unified_sports_analytics()

De CronPartitionTimetable definieert de verwachte partitiegranulariteit voor elk asset. De boolean expressie nba_stats & epl_stats & nfl_stats specificeert dat de DAG alleen triggert wanneer alle drie assets dezelfde partitie beschikbaar hebben. Dit elimineert de noodzaak voor handmatige synchronisatielogica en voorkomt incomplete aggregaties.

Native Async Task Support

I/O-gebonden workloads profiteren enorm van asynchrone uitvoering. Voorheen vereiste dit complexe workarounds met threading of multiprocessing. Airflow 3.2 introduceert native async/await ondersteuning, waardoor tasks direct asyncio-coroutines kunnen uitvoeren zonder externe dependencies of executor-modificaties.

# async_file_download.py
import asyncio
import aiohttp
from airflow.sdk import dag, task
import pendulum

@dag(
    schedule="@daily",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["async", "download"],
)
def async_file_download():
    @task()
    async def download_files():
        urls = [f"https://data.source/files/{i}.csv" for i in range(500)]
        async with aiohttp.ClientSession() as session:
            # Downloads 500 files concurrently instead of sequentially
            tasks = [fetch_and_save(session, url) for url in urls]
            results = await asyncio.gather(*tasks)
        return {"downloaded": len(results)}

    download_files()

async def fetch_and_save(session: aiohttp.ClientSession, url: str):
    async with session.get(url) as resp:
        content = await resp.read()
        filename = url.split("/")[-1]
        with open(f"/data/downloads/{filename}", "wb") as f:
            f.write(content)
        return filename

async_file_download()

Het downloaden van 500 bestanden sequentieel zou minuten duren; met async I/O wordt dit gereduceerd tot seconden. De aiohttp library handelt concurrent HTTP-requests af binnen een enkele Python-thread. Airflow's worker detecteert automatisch async functions en voert deze uit in de juiste event loop context.

Architectuuroverzicht

De Airflow-architectuur bestaat uit vijf kerncomponenten die samenwerken voor betrouwbare pipeline-uitvoering. De Scheduler parseert DAG-bestanden, bepaalt taakafhankelijkheden en plaatst uitvoerbare taken in een queue. De Metadata Database (PostgreSQL of MySQL in productie) slaat DAG-definities, taakstatus, variabelen en connecties op.

Workers halen taken uit de queue en voeren deze uit in geisoleerde processen. De Webserver biedt een UI voor monitoring, log-inspectie en handmatige DAG-triggers. Tot slot beheert de Executor de distributie van taken naar workers, waarbij CeleryExecutor en KubernetesExecutor de standaardkeuzes zijn voor productie.

Airflow vs Prefect vs Dagster: Vergelijking 2026

De keuze voor een orchestratieplatform hangt af van teamgrootte, bestaande infrastructuur en specifieke use cases. Onderstaande vergelijking belicht de belangrijkste verschillen tussen de drie toonaangevende platforms in 2026.

| Feature | Airflow 3.2 | Prefect 3.x | Dagster 1.9 | |---|---|---|---| | DAG definition | Python decorators (airflow.sdk) | Python decorators (@flow, @task) | Python decorators (@asset, @op) | | Scheduling | Cron, asset-aware, partition-aware | Cron, event-driven | Cron, sensor-based, asset-aware | | Execution model | Centralized scheduler + distributed workers | Hybrid (server + work pools) | Centralized dagster-daemon | | Dynamic tasks | .expand() mapped tasks | Native Python loops | Dynamic partitions | | Async support | Native in 3.2 | Native since 2.0 | Async I/O ops | | Multi-team isolation | Built-in (3.2 experimental) | Workspace-based (Cloud) | Branch deployments | | Community size | Largest (35k+ GitHub stars) | Growing (18k+ stars) | Growing (12k+ stars) | | Best fit | Complex, multi-team pipelines with established infrastructure | Smaller teams wanting fast iteration | Data asset-centric organizations |

Airflow excelleert in enterprise-omgevingen met complexe afhankelijkheden en strikte governance-eisen. Prefect biedt een lagere instapdrempel en snellere iteratiecycli voor kleinere teams. Dagster onderscheidt zich door zijn asset-centric model dat naadloos integreert met moderne data mesh-architecturen.

Veelgestelde Sollicitatievragen

Data engineering sollicitatiegesprekken bevatten vrijwel altijd vragen over workflow orchestratie. De volgende vragen komen regelmatig voor en testen zowel conceptuele kennis als praktische ervaring.

Wat is het verschil tussen een Sensor en een Operator? Een Operator voert een actie uit (data verplaatsen, query uitvoeren), terwijl een Sensor wacht tot een externe conditie waar wordt. Sensors implementeren een poke-methode die periodiek controleert of aan de triggervoorwaarde is voldaan.

Hoe werkt XCom en wat zijn de beperkingen? XCom (Cross-Communication) maakt dataoverdracht tussen tasks mogelijk via de metadata database. De belangrijkste beperking is de maximale grootte (standaard 48KB in MySQL, configureerbaar in PostgreSQL). Voor grote datasets wordt aanbevolen om referenties naar externe storage (S3, GCS) door te geven in plaats van de data zelf.

Wanneer gebruik je SubDAGs versus TaskGroups? SubDAGs zijn deprecated sinds Airflow 2.0. TaskGroups bieden dezelfde visuele groepering zonder de performance-overhead en deadlock-risico's van SubDAGs. TaskGroups zijn puur een UI-constructie en beinvloeden de execution niet.

Hoe implementeer je idempotentie in Airflow? Idempotentie vereist dat herhaalde uitvoering van dezelfde task met dezelfde parameters identieke resultaten oplevert. Dit wordt bereikt door: unieke identifiers te gebruiken voor geschreven data, UPSERT-operaties in plaats van INSERT, en execution_date als partitie-sleutel.

Wat zijn de voor- en nadelen van catchup=True? Met catchup=True voert Airflow automatisch alle gemiste runs uit sinds start_date. Dit is essentieel voor historische backfills maar kan overweldigend zijn bij lange periodes. Best practice is catchup=False voor operationele DAGs en een aparte backfill-DAG met expliciete datumbereiken.

Voor uitgebreide interviewvoorbereiding biedt SharpSkill een complete module met Airflow-specifieke vraagstellingen en antwoordstrategieen op /technologies/data-engineering/interview-questions/airflow-fundamentals.

Best Practices voor Productie

Succesvolle Airflow-implementaties volgen bewezen patronen die stabiliteit en schaalbaarheid garanderen. Atomic tasks vormen de basis: elke task voert exact een operatie uit en is onafhankelijk herstartbaar. Dit vereenvoudigt debugging en maakt gedeeltelijke reruns mogelijk zonder side effects.

Configuratiebeheer via Airflow Variables en Connections centraliseert credentials en environment-specifieke waarden. Hardcoded waarden in DAG-bestanden zijn een anti-pattern dat deployments bemoeilijkt. De Secrets Backend integratie met HashiCorp Vault of AWS Secrets Manager biedt enterprise-grade secret management.

Monitoring en alerting zijn essentieel voor operationele pipelines. SLAs definieer verwachte voltooiingstijden; bij overschrijding triggert Airflow automatisch notificaties. Custom metrics via StatsD integreren met bestaande observability-stacks zoals Grafana of Datadog.

Testing van DAGs vereist een gelaagde aanpak. Unit tests valideren individuele task-functies, integratietests verifieren de volledige DAG-structuur, en end-to-end tests met een lokale Airflow-instantie simuleren productie-executie. De dag.test() methode in Airflow 3.2 vereenvoudigt lokale debugging significant.

Conclusie

Apache Airflow 3.2 consolideert zijn positie als de industriestandaard voor pipeline orchestratie met substantiele verbeteringen die moderne data engineering patterns ondersteunen:

• Task SDK vereenvoudigt DAG-authoring met Python decorators en elimineert boilerplate
• Dynamic Task Mapping via .expand() maakt runtime-parallellisatie declaratief en testbaar
• Asset Partities introduceren datagedreven scheduling met tijdgebonden granulariteit
• Native Async ondersteuning versnelt I/O-intensieve workloads zonder externe dependencies
• Multi-team isolatie (experimenteel) bereidt het platform voor op enterprise data mesh-architecturen
• De vergelijking met Prefect en Dagster toont aan dat platformkeuze afhangt van teamgrootte, governance-eisen en asset-centric vs pipeline-centric denken
• Grondige kennis van Airflow-concepten blijft een differentieator in data engineering sollicitaties