Apache Airflow: DAGs als Python-Code, verteilt vom Scheduler auf Worker

Was Airflow unter einem Dag versteht und wie der Scheduler arbeitet

Airflow beschreibt sich selbst als Plattform, um Workflows programmatisch zu erstellen, zu planen und zu überwachen. Diese Formulierung steht so in der Beschreibung des Repositories apache/airflow, und sie benennt bereits die Reihenfolge: Erst wird der Ablauf als Code geschrieben, danach übernimmt die Plattform das Planen und das Beobachten.

Das README begründet den Ansatz mit vier Eigenschaften, die Workflows als Code gewinnen: Sie werden wartbarer, versionierbar, testbar und besser für Zusammenarbeit geeignet. Die Arbeitseinheit heißt Dag, eine gerichtete Struktur aus Aufgaben. Der Scheduler führt diese Aufgaben auf einer Reihe von Workern aus und hält sich dabei an die angegebenen Abhängigkeiten. Für Eingriffe von außen stehen Kommandozeilenwerkzeuge bereit, für die Beobachtung eine Oberfläche, die laufende Pipelines visualisiert, Fortschritt zeigt und bei Störungen beim Eingrenzen hilft.

Das Repository führt Python als Hauptsprache, steht unter Apache-2.0 und nutzt main als Entwicklungsbranch. Der letzte aufgezeichnete Push stammt vom 12. August 2026, am selben Tag erschien das Release 3.3.1. Davor liegen 3.3.0 vom 6. Juli 2026 und java-sdk/1.0.0-beta1 vom 13. Juli 2026. Die Dokumentation liegt unter airflow.apache.org.

Statische Abläufe, XCom und die Abgrenzung zur Streaming-Verarbeitung

Der wichtigste Satz zum Einsatzbereich steht im Abschnitt Project Focus: Airflow funktioniert am besten mit Abläufen, die weitgehend statisch sind und sich langsam ändern. Bleibt die Struktur eines Dag von Lauf zu Lauf ähnlich, wird daraus eine klare Arbeitseinheit und eine nachvollziehbare Kontinuität. Das ist eine Einladung an klassische Datenpipelines und eine Absage an alles, was seine Form bei jedem Aufruf neu bestimmt.

Zwei Betriebsregeln folgen daraus. Aufgaben sollten idempotent sein, weil ein Lauf wiederholt werden kann, und sie sollten keine großen Datenmengen untereinander weiterreichen. Für Metadaten zwischen Aufgaben nennt das Material XCom als vorgesehenen Weg. Wer meint, Arbeitsdaten durch die Tasks schieben zu müssen, arbeitet gegen diese Regel.

Zur Abgrenzung gegen Streaming ist das README deutlich: Airflow ist keine Streaming-Lösung. Es wird gleichwohl häufig eingesetzt, um Echtzeitdaten zu verarbeiten, indem Daten in Batches aus Strömen geholt werden. Jenseits klassischer Pipelines nennt das Material Machine-Learning-Abläufe mit Training, Retraining, Evaluierung und Deployment sowie zunehmend agentische und LLM-basierte Arbeitslasten, bei denen Datenaufbereitung, Werkzeugaufrufe, Modellaufrufe und Evaluierung koordiniert werden, ohne dass Airflow selbst als Agent auftritt. Die drei Prinzipien des Projekts lauten dynamisch, erweiterbar und flexibel, wobei die Flexibilität an die Jinja-Template-Engine gebunden ist.

Python 3.10 bis 3.14, Kubernetes 1.30 bis 1.35 und die Datenbankfrage

Die Anforderungstabelle im README unterscheidet drei Stände: die Hauptentwicklungslinie, die stabile Version 3.3.0 und die als veraltet geführte Version 2.11.2. Für Haupt- und stabile Linie reicht die Python-Unterstützung von 3.10 bis 3.14, für die veraltete Linie von 3.10 bis 3.12. Als Plattformen sind AMD64 und ARM64 angegeben, wobei ARM64 für 2.11.2 als experimentell gilt. Kubernetes wird für Haupt- und stabile Linie mit 1.30 bis 1.35 genannt, für die alte Linie mit 1.26 bis 1.30.

Bei den Datenbanken listet die Tabelle PostgreSQL, MySQL und SQLite, letzteres ab Version 3.15.0. Zwei Hinweise daran sind ernst zu nehmen. MariaDB wird als nicht getestet und nicht empfohlen geführt, und SQLite soll ausschließlich in Tests verwendet werden, nicht in Produktion. Wer eine bestehende MariaDB-Umgebung einbringen will, hat damit keine abgedeckte Konstellation.

Beim Betriebssystem nennt das README POSIX-konforme Systeme, getestet auf neueren Linux-Distributionen und aktuellen macOS-Versionen. Unter Windows läuft Airflow nur über WSL2 oder Linux-Container, für Produktion werden Linux-Distributionen empfohlen. Die Community-Docker-Images basieren auf Debian Bookworm.

pip install apache-airflow mit Constraint-Datei statt Poetry

Auf PyPI liegt Airflow als Paket apache-airflow. Das README warnt ausdrücklich davor, es einfach mit pip zu installieren: Eine solche Installation schlägt gelegentlich fehl oder ergibt ein unbrauchbares Ergebnis. Der Grund ist die Doppelrolle des Projekts, das gleichzeitig Bibliothek und Anwendung ist und deshalb mit einer festen Abhängigkeitsmenge zusammengebracht werden muss.

Der vorgesehene Weg führt über Constraint-Dateien. Das Projekt pflegt sie als bekannt funktionierende Sätze in eigenen, verwaisten Branches, getrennt nach Python-Haupt- und Nebenversion. Der Installationsbefehl verweist dann über --constraint auf die passende URL, im README gezeigt für Version 3.3.0, sowohl in der Grundform als auch mit Extras wie postgres und google. Wer Provider braucht, trägt sie als Extras nach.

Unterstützt wird ausschließlich dieser pip-Weg. Poetry und pip-tools teilen den pip-Arbeitsablauf bei Constraints und Requirements nicht und werden derzeit nicht unterstützt; wer eines dieser Werkzeuge nutzt, muss die Constraint-Dateien selbst in das eigene Format überführen. Das ist ein echter Betriebsnachteil für Teams mit bestehender Poetry-Pipeline.

Dags, Assets, Grid, Graph, Backfill: die Ansichten der Oberfläche

Zur Oberfläche listet das README mehrere Ansichten auf. Dags zeigt eine Übersicht aller DAGs der Umgebung. Assets stellt Assets samt ihren Abhängigkeiten dar. Grid legt einen Dag als Raster über die Zeit. Graph visualisiert die Abhängigkeiten eines Dag und ihren aktuellen Status für einen bestimmten Lauf. Home fasst Kennzahlen der Umgebung zusammen.

Dazu kommen zwei Ansichten, die den Alltag stärker prägen. Backfill dient dazu, einen Dag für einen Datumsbereich nachträglich abzuarbeiten, also genau den Fall zu bedienen, in dem eine Korrektur oder ein Nachlauf über vergangene Intervalle nötig wird. Code erlaubt den schnellen Zugriff auf den Quellcode eines Dag, was die Fehlersuche verkürzt, wenn die Ansicht etwas anderes zeigt als erwartet.

Zu jeder Ansicht enthält das README einen Bildschirmfoto im Dunkelmodus, Verhalten und Konfiguration werden hingegen nicht im Detail beschrieben. Wer wissen will, welche Rechte eine Ansicht voraussetzt oder wie sich Backfill gegen parallel laufende Tasks verhält, muss das in der offiziellen Dokumentation nachlesen; dazu steht im Material nichts.

Semantic Versioning ab 2.0.0 und das Ende der Linie 2

Seit Airflow 2.0.0 folgt das Projekt strengem Semantic Versioning, mit getrennten Regeln für Airflow Core, Provider, das Helm-Chart und API-Clients. Diese Trennung ist praktisch relevant, weil ein Sprung in einem Provider-Paket nicht dieselbe Aussage hat wie ein Sprung im Core.

Die Tabelle zum Versionslebenszyklus nennt Linie 3 als in Wartung, mit dem Stand 3.3.0 und der Erstveröffentlichung am 22. April 2025. Linie 2 ist als am Ende geführt: begrenzte Wartung bis 22. Oktober 2025, Abschluss am 22. April 2026. Wer heute noch auf 2.x steht, hat nach dieser Tabelle keine Wartungsperspektive mehr, und die Requirement-Tabelle führt 2.11.2 ausdrücklich als veraltet.

Beim Umgang mit Abhängigkeiten verfolgt das Projekt zwei Linien gleichzeitig. Constraints sorgen für reproduzierbare Installationen, während die meisten Abhängigkeiten im Normalfall keine Obergrenze tragen. Eine Ausnahme bilden SQLAlchemy, Alembic, Flask, werkzeug, celery und kubernetes, die mit angegebenen Gründen begrenzt sind. Wann eine solche Obergrenze wieder aufgehoben wird, sagt das README nicht; es spricht von einer Best-Effort-Regelung.

Zu unterscheiden sind außerdem zwei Arten von Artefakten. Offizielle Quellcode-Veröffentlichungen folgen der ASF-Release-Politik, liegen im ASF-Verteilverzeichnis, werden vom Release-Manager signiert und im Freigabeprozess von PMC-Mitgliedern abgestimmt. Die gängigen Bezugswege per pip, die Docker-Images aus dem Repository apache/airflow und die GitHub-Tags sind Bequemlichkeitspakete ohne diesen Status, werden aber aus offiziellen Quellen gebaut.

Luigi, Oozie und Azkaban: was das Material offenlässt

Im Abschnitt Project Focus nennt das README drei ähnliche Projekte: Luigi, Oozie und Azkaban. Eine Gegenüberstellung liefert es nicht, und aus dem Material lässt sich auch keine ableiten. Der benennbare Unterschied bleibt deshalb auf der Airflow-Seite: Abläufe werden als Python-Code geschrieben, der Scheduler folgt deklarierten Abhängigkeiten, und mit der Ansicht Backfill lässt sich ein Datumsbereich nachträglich abarbeiten. Wer zwischen diesen Werkzeugen wählen muss, findet hier keine Entscheidungsgrundlage und sollte die jeweiligen Dokumentationen selbst vergleichen.

Konkreter fällt der Unterschied zur schlichten Zeitsteuerung aus. Genügt ein Cron-Eintrag pro Skript, entfallen Scheduler, Metadatenbank und Worker vollständig. Airflow rechtfertigt seinen Betriebsaufwand dort, wo Abhängigkeiten zwischen Schritten existieren, wo ein Nachlauf über Intervalle gebraucht wird und wo mehrere Personen den Zustand sehen müssen. Fehlen diese drei Bedingungen, ist Cron das kleinere System.

Als falsches Werkzeug ist Airflow an zwei Stellen benennbar. Erstens bei echter Ereignisverarbeitung, weil das README die Streaming-Eignung selbst verneint. Zweitens bei Abläufen, deren Struktur sich bei jedem Lauf ändert, was der Empfehlung zu statischen, langsam veränderlichen Workflows widerspricht. Der Betriebsaufwand ist nicht zu unterschätzen: Scheduler, Worker und eine produktionsfähige Datenbank kommen zusammen, und die Installation verlangt die Constraint-Datei der eigenen Python-Version.

Redaktionelles Fazit

Airflow passt zu Teams, die überwiegend statische und langsam veränderliche Abläufe als Python-Code verwalten wollen und dafür Abhängigkeitsverfolgung, einen Nachlauf per Backfill und eine Oberfläche zum Nachsehen brauchen. Es passt nicht für ereignisgetriebene Verarbeitung, weil das README Airflow ausdrücklich als keine Streaming-Lösung bezeichnet, und es ist überdimensioniert, wenn wenige zeitgesteuerte Skripte ohne Abhängigkeiten genügen. Vor der Einführung sollte die Installation mit der Constraint-Datei der eigenen Python-Version erfolgen und nicht mit einem bloßen pip install apache-airflow; außerdem klärt ein Blick in die Lebenszyklus-Tabelle, ob die gewählte Linie noch gewartet wird, denn Linie 2 endete am 22. April 2026, während Linie 3 mit 3.3.1 in Wartung steht.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes