Was macht einen gut entworfenen Airflow-DAG aus, und auf welche Fehler achtest du im Review?

Ein guter DAG hat kleine idempotente Tasks mit klaren Abhängigkeiten, leitet sein Zeitfenster aus dem Data Interval statt aus der Uhr ab und hält schwere Logik aus der DAG-Datei heraus, denn diese Datei wird ständig geparst. Vermeide große Datenmengen über XCom, vermeide lange blockierende Sensoren, die Worker-Slots belegen, und setz sinnvolle Retries, Timeouts und Alerting auf den Tasks, auf die es ankommt.

Die zwei Dinge, die mir am wichtigsten sind, sind Task-Granularität und Idempotenz. Tasks sollten klein genug sein, dass ein Retry billig ist, und spezifisch genug, dass der Fehler dir sagt, was kaputt ist, und jeder einzelne sollte sicher erneut laufen können. Dann muss das Zeitfenster aus dem Data Interval kommen, das Airflow hereingibt, niemals aus datetime.now im Task, sonst verarbeitet ein Rerun von letztem Dienstag die heutigen Daten und du bekommst eine subtil falsche Antwort statt eines Fehlers. Im Review flagge ich am häufigsten teuren Code auf Top-Level der DAG-Datei. Diese Datei wird in kurzen Abständen geparst, also läuft ein API-Call oder eine Datenbankabfrage außerhalb der Task-Funktion permanent und degradiert den ganzen Scheduler; ich habe erlebt, dass allein das die Scheduling-Latenz über ein ganzes Deployment um Minuten erhöht hat. Ich schaue auch auf die XCom-Nutzung, denn das ist eine Metadatentabelle und kein Datentransport, also übergib einen S3-Pfad statt eines Dataframe.