Apache Airflow: Python-DAGs als Data-Engineering-Default seit 2014, Mai 2026 v3.x

Was ist Apache Airflow?

Apache Airflow ist die de-facto-Standard-Plattform für Daten-Pipelines und Workflow-Orchestrierung im Data-Engineering. 2014 bei Airbnb von Maxime Beauchemin gestartet, 2016 an die Apache Software Foundation übergeben, seit 2019 ein Top-Level-Apache-Projekt. Stand Mai 2026 ist Airflow 3.x produktiv – eine bedeutende Architektur-Überarbeitung (Task-Execution-Isolation, neue Scheduler-Engine, bessere UI), die Ende 2025 released wurde.

Das Kernkonzept heisst DAG (Directed Acyclic Graph): ein Python-Script definiert Aufgaben (Tasks) und ihre Abhängigkeiten. Beim Trigger (Cron oder ereignisbasiert) wird der DAG vom Scheduler instanziiert und die Tasks in der richtigen Reihenfolge ausgeführt. Jeder Task ist ein Operator – Python-Operator (eigener Code), Bash-Operator, SQL-Operator (Postgres, MySQL, Snowflake, BigQuery), Kubernetes-Pod-Operator (Container ausführen), Sensors (auf externe Ereignisse warten).

Die Architektur besteht aus mehreren Komponenten: Webserver (UI), Scheduler (entscheidet, welche Tasks ausgeführt werden), Executor (führt Tasks aus – verschiedene Implementierungen: Local, Celery, Kubernetes), Worker (bei Celery- oder Kubernetes-Executor), Metadata-Database (Postgres oder MySQL). Eine produktive Installation hat mindestens 3-4 Server-Komponenten.

Kommerziell ist Airflow Apache 2.0 – vollständig kostenlos, ohne Embedded-Restriktionen. Drei Cloud-Optionen: Astronomer (das Unternehmen hinter Airflow, ab USD 800/Monat für den kleinsten Tarif, Enterprise mit SLA), AWS Managed Workflows for Apache Airflow (MWAA, ab USD 0.40/Stunde für kleinste Environment, plus Compute), Google Cloud Composer (managed Airflow auf GCP, ab USD 350/Monat). Self-Host ist die üblichere Wahl für Teams mit DevOps-Erfahrung.

Für eine CH-Treuhand ist Airflow eher selten direkt einsetzbar – die Plattform ist auf Daten-Engineering optimiert, nicht auf Mandanten-Workflows. Sinnvoll wird Airflow bei Treuhand-Plattformen mit Daten-Warehouse-Anbindung, ELT-Pipelines aus Buchhaltungs-Systemen oder täglichen Reporting-Generierungen.

Warum es wichtig ist

Airflow ist die Plattform mit der grössten installierten Basis im Data-Engineering. Wer Daten-Pipelines baut, findet bei Airflow das grösste Ökosystem an Operators (1.000+ in der Community), die meisten Integrationen mit Data-Warehouses (Snowflake, BigQuery, Redshift, Databricks), die meisten Best-Practices und die grösste Talente-Pool für Hiring.

Für KMU mit Data-Anforderungen sind drei Fälle realistisch. Erstens – ELT aus Geschäfts-Systemen ins Data-Warehouse. Bexio, Abacus, HubSpot, Stripe, Google Analytics – jede dieser Quellen kann via Airflow-DAG täglich (oder stündlich) gezogen, transformiert und in ein Data-Warehouse (Postgres, BigQuery) geladen werden. Wer dort ein 20-50-DAG-Setup hat, ist mit Airflow gut bedient.

Zweitens – komplexe ML-Pipelines. Training-Daten vorbereiten, Modell trainieren, Validation, Deployment, Re-Training-Trigger – diese Schritte sind in Airflow als DAG ausdruckbar. Mit dem Kubernetes-Pod-Operator laufen die schweren Compute-Jobs in dedizierten Containern, die UI zeigt Erfolg/Fehler pro Schritt.

Drittens – tägliche Reporting-Generierung. PDF-Reports aus Daten-Warehouse, Mail-Versand an Mandanten, Slack-Updates an interne Teams. Jeder Schritt ist ein Task im DAG, Failure-Notifications laufen über das integrierte Alerting-System (Slack, Mail, PagerDuty).

Die Reife der Plattform ist ihre Stärke und Schwäche. 10 Jahre Production-Use bedeuten sehr viele dokumentierte Patterns, Stack-Overflow-Antworten und Community-Plugins. Aber auch: viele Legacy-Patterns (z.B. XCom für Daten-Übergabe zwischen Tasks ist limitiert), eine Architektur, die ohne DevOps-Knowhow schnell unhandhabbar wird, und eine UI, die nicht so modern ist wie bei jüngeren Tools (Dagster, Prefect).

Für eine CH-Treuhand sehen wir Airflow am realistischsten als Backend-Komponente in einer Daten-Plattform. Direkt für Mandanten-Workflows ist n8n, Windmill oder Activepieces praktikabler.

Wie es funktioniert

Ein Airflow-DAG ist eine Python-Datei. Der DAG-Objekt wird mit Schedule-Intervall (Cron-Expression oder Preset wie @daily) erzeugt, die Tasks werden mit Operatoren instanziiert, die Abhängigkeiten über Bitshift-Operatoren (a >> b >> c) definiert. Beim Trigger erzeugt der Scheduler einen DAG-Run; die Tasks werden in der definierten Reihenfolge ausgeführt, parallel wenn möglich, sequentiell wenn Abhängigkeit besteht.

Die wichtigsten Operator-Typen: PythonOperator (eigener Python-Code), BashOperator (Shell-Command), SQL-Operatoren (Postgres, Snowflake, BigQuery – sehr ausgereift), KubernetesPodOperator (Container in einem K8s-Cluster), HttpOperator (REST-Calls), Sensor (auf externes Ereignis warten, z.B. „Datei in S3 erscheint"). Seit Airflow 2.x gibt es TaskFlow-API: ein @task-Decorator macht jede Python-Funktion zu einem Task, Datenfluss über reguläre Python-Returns statt XCom-Push/Pull.

Ein typischer ELT-DAG für Treuhand: Schedule @daily, Task 1 „extract_bexio" (PythonOperator, ruft Bexio-API, schreibt JSON nach S3), Task 2 „extract_stripe" (PythonOperator, parallel zu Task 1), Task 3 „transform" (PythonOperator, liest S3, normalisiert mit Pandas, schreibt zurück), Task 4 „load_warehouse" (PostgresOperator, INSERT INTO ...), Task 5 „generate_report" (PythonOperator, baut PDF), Task 6 „send_report" (EmailOperator, sendet PDF an Mandanten-Verteiler). Abhängigkeiten: 1+2 >> 3 >> 4 >> 5 >> 6. Bei Failure von Task 3 werden 4-6 nicht ausgeführt, ein Slack-Alert wird via on_failure_callback gefeuert.

Die Architektur der Plattform ist verteilt: der Scheduler entscheidet permanent, welche Tasks ausgeführt werden dürfen. Der Executor verteilt die Tasks an Workers. Bei kleinen Setups läuft alles auf einem Server (LocalExecutor). Bei grösseren Setups (>50 DAGs, >1.000 Task-Runs/Tag) wird der CeleryExecutor oder KubernetesExecutor nötig – mehrere Worker-Container ziehen Tasks aus einer Redis- oder K8s-Queue.

Versioning ist ein Schwachpunkt. DAGs sind Python-Dateien im Filesystem; der Scheduler scannt das Filesystem in regelmässigen Abständen. Änderungen werden „live" wirksam, ohne Migration-Logik. Best-Practice: DAGs in Git versionieren und mittels CI/CD in das Airflow-Filesystem deployen. Die jüngere Konkurrenz (Dagster, Prefect) hat hier modernere Patterns (Asset-orientiertes Modell, native Versioning).

Monitoring läuft über die Airflow-UI plus Prometheus-Metriken plus Slack/Mail/PagerDuty-Alerts. Die UI zeigt DAG-Runs in einer Grid- und Tree-Ansicht – sehr durchdacht für Debugging, einer der historischen Stärken von Airflow.

Airflow Self-Hosted in 5 Schritten

1. 01Docker-Compose-Stack vorbereiten: Airflow-Webserver, Scheduler, Worker (Celery-Executor), Postgres als Metadata-DB, Redis als Queue, dags-Volume.
2. 02Reverse-Proxy konfigurieren: Nginx oder Caddy mit TLS, HTTP-Basic-Auth oder OAuth für den Webserver, Rate-Limit auf /api/*.
3. 03Erste DAGs schreiben: Python-Datei im dags/-Volume, TaskFlow-API mit @dag- und @task-Decorators, Test mit airflow dags test.
4. 04Connections und Variables setzen: API-Keys, DB-Connections, Cloud-Credentials in Airflow-Connection-Store (verschlüsselt), nicht in DAG-Code.
5. 05Monitoring einrichten: Prometheus-Scraper auf den Statsd-Exporter, Slack/Mail-Alerts bei DAG-Failures via on_failure_callback, Grafana-Dashboard.

Wann Airflow einsetzen

Airflow ist die richtige Wahl, wenn (a) das Hauptproblem Daten-Pipelines ist (ELT, Reporting, ML-Training), (b) Python die Default-Sprache des Daten-Teams ist, (c) Integration mit Data-Warehouses (Snowflake, BigQuery, Redshift) gebraucht wird und (d) DevOps-Knowhow für das Setup verfügbar ist.

Konkrete Fälle: tagliche ELT aus Geschäfts-Systemen ins Data-Warehouse, ML-Training-Pipelines mit GPU-Containern, Reporting-Generierung (PDF, Excel, Mail-Versand), Daten-Quality-Checks mit Slack-Alerts, Backup-Orchestrierung mit Multi-Step-Logik, komplexe Cron-Jobs mit Abhängigkeiten.

Für Treuhand-Plattformen mit Daten-Warehouse-Anbindung ist Airflow eine valide Wahl. Wer hunderte Mandanten betreut und täglich Datenkonsolidierung, Liquiditäts-Monitoring oder Reporting für Mandanten generiert, profitiert von der Reife der Plattform.

Für Engineering-Teams mit bestehendem Python-Stack ist Airflow oft der schnellere Einstieg in Daten-Pipelines als die jüngeren Alternativen (Dagster, Prefect) – die Community-Resources sind grösser, die Hiring-Realität ist klarer (mehr Airflow-Engineers im Markt), die Integrationen sind ausgereifter.

Wann NICHT

Airflow ist die falsche Wahl für Marketing- oder Sales-Workflows. Eingehende Mail klassifizieren, ins CRM eintragen, Slack benachrichtigen – das ist kein Airflow-Problem. n8n, Make, Zapier oder Activepieces sind dort produktiver. Airflow ist auf Daten-Pipelines mit klarer DAG-Struktur und Scheduled-Execution optimiert.

Ungeeignet ist Airflow für Real-Time-Verarbeitung. Der Scheduler hat einen Tick-Intervall (typisch 5 Sekunden), DAG-Triggers laufen scheduled, nicht event-getriggert. Wer Events in Echtzeit verarbeiten muss (eingehende Webhooks, Streaming-Daten), nutzt Kafka, Apache Flink oder dedizierte Streaming-Tools.

Nicht passend ist Airflow bei kleinen Setups ohne DevOps-Knowhow. Eine produktive Installation braucht mindestens 3-4 Server-Komponenten, Postgres, Reverse-Proxy und Monitoring. Wer nur 5-10 DAGs braucht und kein DevOps-Team hat, ist mit n8n, Cron-Jobs oder Windmill schneller produktiv.

Für interaktive Workflows mit User-Approvals ist Airflow ungeeignet. Es gibt zwar ein „Sensor"-Konzept, das auf externe Ereignisse wartet, aber die UI für User-Approvals fehlt. Temporal oder Windmill sind dort die richtigen Tools.

Für Sprach-Vielfalt (Workflows in TypeScript, Go, oder anderen Sprachen) ist Airflow Python-only. Wer ein Multi-Sprach-Team hat, ist mit Temporal (7 SDKs) oder Windmill (TS/Python/Go/Bash) flexibler.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Apache Airflow documentation – DAGs, operators, executors · 2026-05
2. Airflow 3.x release notes and migration guide · 2026-05
3. Astronomer pricing – managed Airflow · 2026-04
4. AWS Managed Workflows for Apache Airflow (MWAA) · 2026-04