Apache Airflow: l'exécuteur signale que l'instance de tâche est terminée (a échoué) bien que la tâche indique qu'elle est en file d'attente
Notre installation de flux d'air utilise CeleryExecutor. Les configurations simultanées étaient
# The amount of parallelism as a setting to the executor. This defines
# the max number of task instances that should run simultaneously
# on this airflow installation
parallelism = 16
# The number of task instances allowed to run concurrently by the scheduler
dag_concurrency = 16
# Are DAGs paused by default at creation
dags_are_paused_at_creation = True
# When not using pools, tasks are run in the "default pool",
# whose size is guided by this config element
non_pooled_task_slot_count = 64
# The maximum number of active DAG runs per DAG
max_active_runs_per_dag = 16
[celery]
# This section only applies if you are using the CeleryExecutor in
# [core] section above
# The app name that will be used by celery
celery_app_name = airflow.executors.celery_executor
# The concurrency that will be used when starting workers with the
# "airflow worker" command. This defines the number of task instances that
# a worker will take, so size up your workers based on the resources on
# your worker box and the nature of your tasks
celeryd_concurrency = 16
Nous avons un poignard qui s'exécute quotidiennement. Il a autour de certaines tâches en parallèle suivant un modèle qui détecte si les données existent dans hdfs, puis dort 10 minutes, et enfin télécharge sur s3.
Certaines tâches ont rencontré l'erreur suivante:
2019-05-12 00:00:46,212 ERROR - Executor reports task instance <TaskInstance: example_dag.task1 2019-05-11 04:00:00+00:00 [queued]> finished (failed) although the task says its queued. Was the task killed externally?
2019-05-12 00:00:46,558 INFO - Marking task as UP_FOR_RETRY
2019-05-12 00:00:46,561 WARNING - section/key [smtp/smtp_user] not found in config
Ce type d'erreur se produit de manière aléatoire dans ces tâches. Lorsque cette erreur se produit, l'état de l'instance de tâche est immédiatement défini sur up_for_retry et aucun journal dans les nœuds de travail. Après quelques tentatives, ils s'exécutent et finissent finalement.
Ce problème nous donne parfois un retard ETL important. Quelqu'un sait comment résoudre ce problème?
Nous avons déjà corrigé cela. Permettez-moi de me répondre à la question:
Nous avons 5 nœuds de travailleur de flux d'air. Après avoir installé flower pour surveiller les tâches réparties sur ces nœuds. Nous avons découvert que la tâche ayant échoué était toujours envoyée à un nœud spécifique. Nous avons essayé d'utiliser la commande de test de flux d'air pour exécuter la tâche dans d'autres nœuds et cela a fonctionné. Finalement, la raison était un mauvais paquet python dans ce nœud spécifique.
Nous étions confrontés à des problèmes similaires, qui ont été résolus par
"-x, --donot_pickle" option.
Pour plus d'informations: - https://airflow.Apache.org/cli.html#backfill
Je voyais des symptômes très similaires dans mes DagRuns. Je pensais que c'était à cause des problèmes de ExternalTaskSensor et de simultanéité étant donné le langage de mise en file d'attente et de tâche tuée qui ressemblait à ceci: Executor reports task instance <TaskInstance: dag1.data_table_temp_redshift_load 2019-05-20 08:00:00+00:00 [queued]> finished (failed) although the task says its queued. Was the task killed externally? Mais quand j'ai regardé les journaux de travail, j'ai vu qu'il y avait une erreur causée par la définition d'une variable avec Variable.set dans mon DAG. Le problème est décrit ici la valeur de clé en double viole la contrainte unique lors de l'ajout de la variable de chemin dans le flux d'air où le planificateur interroge le dagbag à intervalles réguliers pour actualiser dynamiquement les modifications. L'erreur à chaque battement de cœur entraînait des retards ETL importants.
Exécutez-vous une logique dans votre wh_hdfs_to_s3 DAG (ou autres) qui pourrait provoquer des erreurs ou des retards/ces symptômes?