# Apache Airflow in 2026: Pipeline-Orchestrierung, DAGs und Interview-Fragen

> Umfassender Leitfaden zu Apache Airflow 3.2 in 2026: DAG-Erstellung mit dem Task SDK, Dynamic Task Mapping, Asset Partitions und die wichtigsten Interview-Fragen für Data Engineers.

- Published: 2026-06-13
- Updated: 2026-06-13
- Author: SharpSkill
- Tags: apache-airflow, data-engineering, pipeline-orchestration, dag, interview
- Reading time: 12 min

---

Apache Airflow hat sich als De-facto-Standard für die Orchestrierung von Datenpipelines etabliert. Mit der Version 3.2 erreicht das Open-Source-Projekt einen neuen Reifegrad, der moderne Anforderungen an Skalierbarkeit, Entwicklerproduktivität und Multi-Team-Kollaboration adressiert. Dieser Artikel beleuchtet die zentralen Konzepte von Airflow, demonstriert Best Practices anhand praktischer Codebeispiele und bereitet auf technische Interviews im Bereich Data Engineering vor.

> **Airflow 3.2 im Überblick**
>
> Die Version 3.2 bringt das neue Task SDK (`airflow.sdk`), native Async-Unterstützung, Asset Partitions für datengesteuerte Workflows und experimentelle Multi-Team-Isolation. Das Upgrade von 2.x erfordert Anpassungen bei Import-Pfaden und DAG-Definitionen, bietet jedoch erhebliche Verbesserungen bei Performance und Entwicklererfahrung.

## DAG-Erstellung mit dem Task SDK

Das Task SDK in Airflow 3.2 vereinfacht die DAG-Definition erheblich. Anstelle der traditionellen Operator-basierten Syntax ermöglichen Python-Decorators eine intuitive, funktionale Programmierung von Workflows. Der TaskFlow-API-Ansatz reduziert Boilerplate-Code und macht Datenabhängigkeiten zwischen Tasks explizit.

Ein typisches ETL-Pattern für die tägliche Umsatzaggregation demonstriert die Eleganz des neuen SDKs:

```python
# 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()
```

Die Struktur folgt dem klassischen Extract-Transform-Load-Muster. Der `@dag`-Decorator definiert Metadaten wie Schedule und Start-Datum, während `@task`-Decorators einzelne Verarbeitungsschritte markieren. Type Hints ermöglichen automatische Serialisierung der Daten zwischen Tasks via XCom. Das `multiple_outputs=True`-Flag erlaubt die Rückgabe mehrerer benannter Werte aus einem einzelnen Task.

## Dynamic Task Mapping

Statische DAGs stoßen bei variablen Datenmengen an ihre Grenzen. Dynamic Task Mapping, eingeführt in Airflow 2.3 und in 3.2 weiter optimiert, löst dieses Problem durch die dynamische Erzeugung von Task-Instanzen zur Laufzeit. Die `.expand()`-Methode mappt einen Task über eine Liste von Eingabewerten.

Das folgende Beispiel verarbeitet Daten aus mehreren Regionen parallel:

```python
# 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()
```

Der `get_regions`-Task liefert zur Laufzeit eine Liste aktiver Regionen. Die `.expand()`-Methode erstellt automatisch eine Task-Instanz pro Region. Der `merge_results`-Task erhält die aggregierte Liste aller Ergebnisse und kombiniert diese zu einem globalen Report.

> **Mapped Task Limits**
>
> Standardmäßig erlaubt Airflow maximal 1024 gemappte Task-Instanzen pro Task. Dieses Limit kann über die Konfiguration `max_map_length` angepasst werden. Bei sehr großen Mappings empfiehlt sich die Aufteilung in mehrere Batches oder die Verwendung von Untergruppen.

## Asset Partitions

Asset Partitions erweitern das datengesteuerte Scheduling um zeitliche Granularität. Anstatt einen DAG bei jeder Änderung eines Assets auszulösen, können Workflows auf spezifische Partitionen warten. Dies ermöglicht präzise Koordination zwischen mehreren Datenquellen mit unterschiedlichen Update-Zyklen.

Ein Anwendungsfall aus dem Sportdatenbereich illustriert das Konzept:

```python
# 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()
```

Die drei Assets repräsentieren stündliche Datenlieferungen verschiedener Sportligen. Der `&`-Operator im Schedule definiert eine logische UND-Verknüpfung: Der DAG startet erst, wenn alle drei Assets eine übereinstimmende Partition aufweisen. Der Kontext liefert die spezifische Partition für die Verarbeitung.

## Native Async-Unterstützung

I/O-intensive Workloads profitieren erheblich von asynchroner Verarbeitung. Airflow 3.2 unterstützt nativ `async`/`await`-Syntax innerhalb von Tasks. Dies ermöglicht hochgradig parallele Operationen ohne die Komplexität separater Worker-Pools.

Das Herunterladen hunderter Dateien demonstriert den Performance-Gewinn:

```python
# 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()
```

Sequenzielle Downloads von 500 Dateien würden bei 200ms Latenz pro Request etwa 100 Sekunden benötigen. Die asynchrone Variante mit `asyncio.gather()` reduziert dies auf wenige Sekunden, limitiert primär durch Bandbreite und Server-Throttling.

## Architektur-Überblick

Die Airflow-Architektur besteht aus mehreren Kernkomponenten, die zusammenspielen, um zuverlässige Workflow-Orchestrierung zu gewährleisten.

Der **Scheduler** ist das Herzstück des Systems. Er parst DAG-Dateien, ermittelt ausführungsbereite Tasks und übergibt diese an den Executor. In produktiven Umgebungen laufen typischerweise mehrere Scheduler-Instanzen für Hochverfügbarkeit.

Der **Executor** bestimmt, wie und wo Tasks ausgeführt werden. Airflow bietet verschiedene Executor-Typen für unterschiedliche Skalierungsanforderungen. Der LocalExecutor eignet sich für Entwicklung und kleine Deployments. Der CeleryExecutor verteilt Tasks auf einen Pool von Worker-Nodes. Der KubernetesExecutor startet jeden Task in einem separaten Pod, was maximale Isolation und Skalierbarkeit bietet.

> **Executor-Wahl für Produktion**
>
> Der SequentialExecutor ist ausschließlich für Entwicklungszwecke gedacht. Produktive Deployments erfordern CeleryExecutor oder KubernetesExecutor. Bei Kubernetes-basierten Infrastrukturen bietet der KubernetesExecutor Vorteile bei Ressourcenisolation und dynamischer Skalierung, erfordert jedoch sorgfältige Konfiguration von Pod-Templates und Resource-Requests.

Die **Metadata Database** speichert den Zustand aller DAGs, Task-Instanzen und XCom-Daten. PostgreSQL oder MySQL sind die empfohlenen Backends für Produktion. Die Datenbank ist der kritischste Single Point of Failure und erfordert entsprechende Backup- und Recovery-Strategien.

Der **Webserver** stellt die Benutzeroberfläche bereit. Hier lassen sich DAG-Läufe überwachen, Logs einsehen und manuelle Trigger auslösen. Die UI wurde in Version 3.x grundlegend modernisiert und bietet verbesserte Performance bei großen DAG-Mengen.

## Airflow vs. Prefect vs. Dagster

Die Wahl des richtigen Orchestrierungs-Tools hängt von Teamgröße, Infrastruktur und spezifischen Anforderungen ab. Der folgende Vergleich fasst die wesentlichen Unterschiede zusammen:

| 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 eignet sich besonders für Organisationen mit komplexen, etablierten Data-Engineering-Infrastrukturen und mehreren Teams. Die große Community und das umfangreiche Provider-Ökosystem erleichtern die Integration mit praktisch jeder Datenquelle. Prefect punktet bei kleineren Teams, die schnelle Iteration und einfaches Deployment priorisieren. Dagster überzeugt bei asset-zentrierten Workflows, wo Daten-Lineage und Qualitätsprüfungen im Vordergrund stehen.

## Interview-Fragen zu Apache Airflow

Technische Interviews im Bereich Data Engineering umfassen häufig Fragen zu Airflow-Konzepten. Die folgenden Themen gehören zum Standardrepertoire:

**Was unterscheidet einen DAG von einem Task?** Ein DAG (Directed Acyclic Graph) definiert den Workflow als Ganzes, inklusive Abhängigkeiten und Scheduling. Tasks sind die einzelnen Arbeitseinheiten innerhalb eines DAGs. Jeder Task wird unabhängig geplant und ausgeführt, wobei die DAG-Struktur die Ausführungsreihenfolge bestimmt.

**Wie funktioniert XCom?** XCom (Cross-Communication) ermöglicht den Datenaustausch zwischen Tasks. Tasks können Werte mit `xcom_push` veröffentlichen und mit `xcom_pull` abrufen. Bei Verwendung des TaskFlow-API erfolgt dies automatisch über Return-Werte. XCom ist für kleine Datenmengen konzipiert; für größere Datasets empfiehlt sich die Verwendung externer Speicher wie S3.

**Wann ist Catchup sinnvoll?** Das `catchup`-Flag steuert, ob fehlende DAG-Runs nachgeholt werden. Bei `catchup=True` führt Airflow alle Runs zwischen `start_date` und aktuellem Datum aus. Dies ist sinnvoll für historische Datenverarbeitung, kann aber bei inkrementellen Loads oder API-Calls zu Problemen führen.

**Was ist der Unterschied zwischen Sensoren und Operatoren?** Operatoren führen eine Aktion aus und beenden sich dann. Sensoren warten auf eine Bedingung und blockieren dabei einen Worker-Slot. In modernen Airflow-Versionen sollten Sensoren im `reschedule`-Modus laufen, um Worker-Ressourcen freizugeben.

**Wie skaliert Airflow horizontal?** Horizontale Skalierung erfolgt primär über den Worker-Pool. Mit CeleryExecutor können beliebig viele Worker hinzugefügt werden. Der Scheduler skaliert über mehrere Instanzen mit Datenbank-Locking. Für extreme Skalierung bietet der KubernetesExecutor unbegrenzte elastische Kapazität.

Für eine umfassende Vorbereitung auf Airflow-Interviews bietet SharpSkill spezialisierte Übungsfragen unter [Airflow Fundamentals](/technologies/data-engineering/interview-questions/airflow-fundamentals). Die interaktiven Fragen decken sowohl konzeptuelle als auch praktische Aspekte ab.

## Best Practices für Produktion

Produktive Airflow-Deployments erfordern sorgfältige Planung in mehreren Bereichen:

**Idempotenz gewährleisten**: Jeder Task sollte bei mehrfacher Ausführung das gleiche Ergebnis liefern. Dies ermöglicht sicheres Retry bei Fehlern und vereinfacht Debugging. Anstatt Daten anzuhängen, sollten Tasks Partitionen überschreiben oder Upserts verwenden.

**Kleine, fokussierte DAGs**: Monolithische DAGs mit hunderten Tasks sind schwer zu warten und zu debuggen. Die Aufteilung in kleinere, fachlich kohärente DAGs verbessert Übersichtlichkeit und ermöglicht unabhängige Deployments.

**Secrets Management**: Zugangsdaten gehören in Airflows Connection- und Variable-Store oder externe Systeme wie HashiCorp Vault. Niemals Credentials in DAG-Code oder Umgebungsvariablen hardcoden.

**Monitoring und Alerting**: SLAs definieren maximale Laufzeiten für kritische DAGs. Airflow integriert mit gängigen Monitoring-Tools wie Prometheus und Datadog. E-Mail- oder Slack-Benachrichtigungen bei Failures sind essentiell.

**Testing**: DAG-Validierung sollte Teil der CI/CD-Pipeline sein. Unit-Tests für Task-Logik, Integrationstests für Datenflüsse und DAG-Parsing-Tests verhindern Produktionsprobleme.

## Fazit

Apache Airflow 3.2 etabliert neue Standards für Pipeline-Orchestrierung im Data-Engineering-Umfeld:

- Das **Task SDK** vereinfacht DAG-Definition durch intuitive Python-Decorators und automatisches Dependency-Management
- **Dynamic Task Mapping** ermöglicht flexible, datengesteuerte Workflows ohne DAG-Modifikation
- **Asset Partitions** koordinieren komplexe Multi-Source-Pipelines mit zeitlicher Präzision
- **Native Async-Unterstützung** beschleunigt I/O-intensive Workloads erheblich
- Die **Multi-Team-Isolation** adressiert Enterprise-Anforderungen an Governance und Zugriffskontrolle
- Im Vergleich zu Prefect und Dagster punktet Airflow bei **Skalierbarkeit** und **Community-Support**

Die Kombination aus ausgereifter Architektur, aktivem Ökosystem und kontinuierlicher Innovation macht Airflow zur ersten Wahl für anspruchsvolle Data-Engineering-Teams.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/de/blog/data-engineering/apache-airflow-pipeline-orchestration-dags-interview-2026