Qu'est-ce qui fait un DAG Airflow bien conçu, et quelles erreurs cherchez-vous en revue ?

Un bon DAG a de petites tâches idempotentes avec des dépendances claires, dérive sa fenêtre temporelle de l'intervalle de données plutôt que de l'horloge, et garde la logique lourde hors du fichier de DAG, puisque ce fichier est parsé en permanence. Évitez de faire transiter de gros volumes par XCom, évitez les capteurs bloquants qui occupent longtemps des slots de worker, et réglez des reprises, des délais d'expiration et un alerting sensés sur les tâches qui comptent.

Les deux choses qui me tiennent le plus à coeur sont la granularité des tâches et l'idempotence. Les tâches doivent être assez petites pour qu'un échec soit peu coûteux à rejouer, et assez spécifiques pour que l'échec vous dise ce qui a cassé, et chacune doit être sûre à relancer. Ensuite, la fenêtre temporelle doit venir de l'intervalle de données que passe Airflow, jamais d'un datetime.now dans la tâche, sinon une relance de mardi dernier traite les données d'aujourd'hui et vous obtenez une réponse subtilement fausse au lieu d'une erreur. En revue, ce que je signale le plus souvent, c'est du code coûteux au premier niveau du fichier de DAG. Ce fichier est parsé à intervalle court, donc un appel d'API ou une requête de base hors de la fonction de tâche tourne en permanence et dégrade tout le scheduler ; j'ai vu cela seul ajouter des minutes de latence de planification sur un déploiement entier. Je vérifie aussi l'usage de XCom, puisque c'est une table de métadonnées et pas un transport de données : passez un chemin S3 plutôt qu'un dataframe.