Apache Airflow ist ein quelloffener Taktgeber für Daten-Arbeitsabläufe. In der Programmiersprache Python wird beschrieben, welche Arbeitsschritte in welcher Reihenfolge laufen sollen (ein sogenannter DAG, gerichteter azyklischer Graph). Airflow startet diese Abläufe nach Zeitplan oder auf Signal, überwacht sie und meldet Fehler.
Was ist Apache Airflow?
Apache Airflow ist ein Dirigent für Datenpipelines, also für Abläufe, die Daten aus einer Quelle abholen, verarbeiten und in ein Zielsystem schreiben. Statt jeden Ablauf per Hand oder per Zeitschaltuhr zu starten, beschreiben Teams die einzelnen Arbeitsschritte (Tasks) und ihre Reihenfolge in Python-Code. Aus dieser Beschreibung entsteht ein DAG (gerichteter azyklischer Graph, ein Ablaufplan ohne Rückschleifen). Weil der Plan Code ist, lässt er sich versionieren, testen und im selben Review-Prozess pflegen wie normale Software.
Das Projekt entstand 2014 bei Airbnb und wurde 2016 in den Apache Incubator übergeben. Seit 2019 ist es ein [Apache Top-Level-Project](https://airflow.apache.org/) und gilt in der Data-Engineering-Community als Referenz für Workflow-Orchestrierung. Die aktuelle Hauptversion Airflow 3 (2025) bringt ein neues Task-SDK, DAG-Versionierung, entkoppelte Worker-Kommunikation und stabilere Backfill-Semantik.
Die Laufzeit besteht aus mehreren Komponenten: der Scheduler löst DAG-Läufe aus, wenn ihr Zeitplan oder ein externer Trigger es verlangt, der Executor bestimmt das Ausführungsmodell (Local, Celery, Kubernetes), Worker führen die einzelnen Tasks aus, eine Metadaten-Datenbank hält Zustand und Historie, und der Webserver liefert die Oberfläche für Monitoring, Log-Zugriff und manuelle Läufe.
Airflow selbst verarbeitet keine Nutzdaten. Der Orchestrator koordiniert Aufrufe an externe Systeme über Provider und Operatoren. Das offizielle Ökosystem umfasst über 1.500 Provider für AWS, Azure, GCP, Databricks, Snowflake, dbt, Kafka und viele weitere Ziele. Für die Ausführungsumgebung stehen Self-Hosted-Betrieb (Docker, Kubernetes, Helm) und Managed Services wie [Amazon MWAA](https://aws.amazon.com/managed-workflows-for-apache-airflow/) oder [Google Cloud Composer](https://cloud.google.com/composer) zur Verfügung.
Abgrenzung zu anderen Orchestratoren
Der Begriff „Orchestrierung" wird für unterschiedlich mächtige Werkzeuge verwendet. Die folgenden Vergleiche klären typische Verwechslungen.
| Werkzeug | Abgrenzung zu Apache Airflow |
|---|---|
| Databricks Lakeflow Jobs | In-Platform-Orchestrator für Databricks-native Workloads, tief in Unity Catalog und Notebooks integriert; Airflow bleibt plattformübergreifend und Python-code-zentriert |
| Prefect / Dagster | Modernere Python-Orchestratoren mit dynamischen Runs (Prefect) oder Software-defined Assets (Dagster); Airflow ist konzeptionell älter, aber verbreiteter und reifer |
| Cron / Kubernetes CronJobs | Reine Scheduler ohne Abhängigkeitsauflösung, Retry-Semantik oder UI; Airflow schließt die Lücke zwischen zeitgesteuertem Start und vollständiger Workflow-Logik |
| Structured Streaming, Flink | Engines für kontinuierliche Datenverarbeitung; Airflow orchestriert Batch- und Micro-Batch-Prozesse, keine Ereignisströme |
Beispiel: Databricks-Pipeline mit Airflow steuern
Eine typische Architekturposition ist die eines Klammer-Orchestrators über heterogene Systeme. Ein Nightly-DAG lädt Rohdaten aus einem S3-Bucket in ein Bronze-Delta-Layer, startet anschließend über den DatabricksRunNowOperator einen Databricks-Job für die Silber-Transformation, wartet auf dessen Abschluss, ruft danach eine dbt-Transformation für die Gold-Schicht auf und benachrichtigt bei Fehlern einen Slack-Kanal.
from airflow import DAG
from airflow.providers.databricks.operators.databricks import DatabricksRunNowOperator
from datetime import datetime
with DAG(
dag_id="daily_sales_pipeline",
start_date=datetime(2026, 1, 1),
schedule="0 3 * * *",
catchup=False,
) as dag:
silver_transform = DatabricksRunNowOperator(
task_id="silver_transform",
databricks_conn_id="databricks_default",
job_id=42,
)In dieser Rolle sitzt Airflow architektonisch über der Compute-Ebene und unter dem BI- oder Anwendungs-Layer. Der Orchestrator selbst hält keine großen Datenmengen im Speicher, sondern koordiniert die ausführenden Systeme und protokolliert Zustand, Dauer und Ergebnisse jedes Laufs.
Apache Airflow im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.