Récemment, j'ai tellement testé le débit d'air que l'un des problèmes rencontrés avec execution_date
lors de l'exécution de airflow trigger_dag <my-dag>
.
J'ai appris que execution_date
n'est pas ce que nous pensons à la première fois de ici :
Airflow a été développé pour répondre aux besoins ETL. Dans le monde ETL, vous résumez généralement les données. Donc, si je veux résumer les données pour 2016-02-19, je le ferais à 2016-02-20 à minuit GMT, ce qui serait exact une fois que toutes les données pour 2016-02-19 seraient disponibles.
start_date = datetime.combine(datetime.today(),
datetime.min.time())
args = {
"owner": "xigua",
"start_date": start_date
}
dag = DAG(dag_id="hadoopprojects", default_args=args,
schedule_interval=timedelta(days=1))
wait_5m = ops.TimeDeltaSensor(task_id="wait_5m",
dag=dag,
delta=timedelta(minutes=5))
Au-dessus de codes est la partie de départ de mon flux de travail quotidien, la première tâche est un TimeDeltaSensor qui attend encore 5 minutes avant le travail réel, cela signifie donc que mon dag sera déclenché à 2016-09-09T00:05:00
, 2016-09-10T00:05:00
... etc.
Dans l'interface utilisateur Web, je peux voir quelque chose comme scheduled__2016-09-20T00:00:00
, et la tâche est exécutée à 2016-09-21T00:00:00
, ce qui semble raisonnable selon le modèle ETL
.
Cependant, un jour, mon dag n'est pas déclenché pour une raison inconnue. Je le déclenche donc manuellement. Si je le déclenche à 2016-09-20T00:10:00
, alors le TimeDeltaSensor attendra le 2016-09-21T00:15:00
avant de l'exécuter.
Ce n'est pas ce que je veux, je veux que ça tourne à 2016-09-20T00:15:00
pas le lendemain, j'ai essayé de passer de execution_date
à --conf '{"execution_date": "2016-09-20"}'
, mais cela ne fonctionne pas.
Comment dois-je gérer ce problème?
$ airflow version
[2016-09-21 17:26:33,654] {__init__.py:36} INFO - Using executor LocalExecutor
____________ _____________
____ |__( )_________ __/__ /________ __
____ /| |_ /__ ___/_ /_ __ /_ __ \_ | /| / /
___ ___ | / _ / _ __/ _ / / /_/ /_ |/ |/ /
_/_/ |_/_/ /_/ /_/ /_/ \____/____/|__/
v1.7.1.3
Tout d'abord, je vous recommande d'utiliser des constantes pour start_date
, car les constantes dynamiques agiraient de manière imprévisible si votre pipeline de flux d'air était évalué par le planificateur.
Plus d’informations sur start_date
dans une entrée FAQ que j’ai écrite et pour trier tout cela: https://airflow.Apache.org/faq.html#what-s-the -deal-with-start-date
Maintenant, à propos de execution_date
et quand il est déclenché, c’est un piège commun pour les personnes qui s’intègrent sur Airflow. Airflow définit execution_date
en fonction de la limite gauche de la période de planification qu’elle couvre, et non en fonction du moment où elle est déclenchée (ce qui constituerait la limite droite de la période). Par exemple, lors de l'exécution d'une tâche schedule='@hourly'
, une tâche est déclenchée toutes les heures. La tâche qui est déclenchée à 14 heures aura un execution_date
de 13 heures, car elle suppose que vous traitez la fenêtre horaire de 13 heures à 14 heures à 14 heures. De même, si vous exécutez un travail quotidien, l’exécution d’un execution_date
de 2016-01-01
se déclencherait peu après minuit le 2016-01-02
.
Cet étiquetage à gauche est très utile pour penser en termes de charge ETL et de charges différentielles, mais devient confus pour un simple planificateur semblable à celui de Cron.
Airflow fournira l'heure en UTC. Je ne sais pas à quel fuseau horaire vous exécutez les tâches. Assurez-vous donc de penser au fuseau horaire UTC et planifiez ou déclenchez les tâches en conséquence.
Essayez de convertir l'heure que vous souhaitez déclencher en heure UTC et déclencher le DAG. Ça marche. Pour plus d'informations, vous pouvez lire le lien ci-dessous
https://cwiki.Apache.org/confluence/display/AIRFLOW/Common+Pitfalls