airflow trigger_dagecution_date es al día siguiente, ¿por qué?

Recientemente, he probado tanto el flujo de air que tiene un problema con la execution_date cuando se ejecuta el airflow trigger_dag .

He aprendido que la fecha de execution_date no es lo que pensamos la primera vez desde aquí :

El flujo de air fue desarrollado como una solución para las necesidades de ETL. En el mundo de ETL, normalmente se resumen los datos. Entonces, si quiero resumir los datos para el 2016-02-19, lo haría en el 2016-02-20 GMT de medianoche, lo que sería justo después de que todos los datos para el 2016-02-19 estén 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)) 

Los códigos anteriores son la parte inicial de mi flujo de trabajo diario, la primera tarea es un TimeDeltaSensor que espera otros 5 minutos antes del trabajo real, por lo que esto significa que mi dag se activará el 2016-09-09T00:05:00 , 2016-09-10T00:05:00 … etc.

En la interfaz de usuario web, puedo ver algo como scheduled__2016-09-20T00:00:00 , y la tarea se ejecuta en 2016-09-21T00:00:00 , lo que parece razonable según el modelo ETL .

Sin embargo, algún día, mi dag no se activa por una razón desconocida, por lo tanto, si lo hago a la 2016-09-20T00:10:00 , el TimeDeltaSensor esperará hasta el 2016-09-21T00:15:00 antes de la ejecución.

Esto no es lo que quiero, quiero que se ejecute en 2016-09-20T00:15:00 no al día siguiente, he intentado pasar la fecha de execution_date través de --conf '{"execution_date": "2016-09-20"}' , pero no funciona.

¿Cómo debo tratar este problema?

 $ airflow version [2016-09-21 17:26:33,654] {__init__.py:36} INFO - Using executor LocalExecutor ____________ _____________ ____ |__( )_________ __/__ /________ __ ____ /| |_ /__ ___/_ /_ __ /_ __ \_ | /| / / ___ ___ | / _ / _ __/ _ / / /_/ /_ |/ |/ / _/_/ |_/_/ /_/ /_/ /_/ \____/____/|__/ v1.7.1.3 

En primer lugar, le recomiendo que use constantes para la fecha de start_date , ya que las dinámicas actuarían de forma impredecible en función del flujo de air que evalúa el progtwigdor.

Más información sobre start_date aquí en una entrada de preguntas frecuentes que escribí y ordené todo esto: https://airflow.apache.org/faq.html#what-s-the-deal-with-start-date

Ahora, sobre la fecha de execution_date y cuando se activa, este es un problema común para las personas que se incorporan en Airflow. El flujo de air establece la fecha de execution_date función del límite izquierdo del período de progtwigción que cubre, no en función de cuándo se dispara (que sería el límite derecho del período). Cuando se ejecuta una tarea schedule='@hourly' , por ejemplo, una tarea se activará cada hora. La tarea que se inicia a las 2pm tendrá una fecha de execution_date de 1pm porque asume que estás procesando la ventana de tiempo de 1pm a 2pm a las 2pm. De manera similar, si ejecuta un trabajo diario, la ejecución con una fecha de execution_date de 2016-01-01 se activará poco después de la medianoche del 2016-01-02 .

Este etiquetado de la izquierda tiene mucho sentido cuando se piensa en términos de ETL y cargas diferenciales, pero se confunde cuando se piensa en términos de un planificador simple, parecido a un cron.

El flujo de air proporcionará el tiempo en UTC. No estoy seguro en qué zona horaria está ejecutando las tareas. Así que asegúrese de pensar en la zona horaria UTC y progtwigr o activar los trabajos en consecuencia.

Intente convertir el tiempo que desea activar a la hora UTC y active el DAG. funciona. Para más información, puedes leer el siguiente enlace.

https://cwiki.apache.org/confluence/display/AIRFLOW/Common+Pitfalls