Airflow "Ce DAG n'est pas disponible dans l'objet DagBag du serveur Web"
lorsque je mets un nouveau script DAG python dans le dossier dags, je peux afficher une nouvelle entrée de DAG dans l'interface utilisateur de DAG, mais elle n'a pas été activée automatiquement. En outre, il semble que non. Je ne peux que cliquer plusieurs fois sur le bouton Actualiser du côté droit de la liste et basculer le bouton activer/désactiver situé du côté gauche de la liste pour pouvoir planifier le DAG. besoin de déclencher quelque chose même si le script DAG a été placé dans le dossier dag.
Quelqu'un peut m'aider à ce sujet ? Ai-je raté quelque chose? Ou est-ce un comportement correct dans le flux d'air?
A propos, comme mentionné dans le titre de l'article, il y a un indicateur avec ce message "Ce DAG n'est pas disponible dans l'objet DagBag du serveur Web. Il apparaît dans cette liste car le planificateur l'a marqué comme étant actif dans la base de données de métadonnées" marqué avec le titre de DAG avant que je déclenche tout ce processus manuel.
Ce n'est pas vous ni c'est un comportement correct ou attendu. C'est un "bug" actuel avec Airflow. Le serveur Web met en cache le DagBag d'une manière que vous ne pouvez pas vraiment l'utiliser comme prévu.
"Attempt removing DagBag caching for the web server "reste sur l’officiel À FAIRE dans le cadre de la feuille de route, indiquant que ce bogue n’est peut-être pas encore totalement résolu, mais voici quelques suggestions sur la façon de procéder. procéder:
utiliser uniquement des constructeurs dans airflow v1.9 +
Avant Airflow v1.9, cela se produit lorsqu'un dag est instancié par une fonction importée dans le fichier où l'instanciation a lieu. C'est-à-dire: lorsqu'un motif constructeur ou sine est utilisé. Certains rapports de ce problème sur github 2 et JIRA ont conduit à n correctif publié avec in airflow v1.9.
Si vous utilisez une ancienne version de airflow, n'utilisez pas de fonctions de générateur.
airflow backfill pour recharger le cache
Comme le suggère Dmitri, courir airflow backfill '<dag_id>' -s '<date>' -e '<date>' pour les mêmes dates de début et de fin peut parfois aider. Par la suite, vous pouvez vous retrouver avec le (non-problème) indiqué par Priyank, mais il s’agit du comportement attendu (état: en pause ou non) en fonction de la configuration de votre installation.
Redémarrez le airflow webserver résout mon problème.
Le problème vient du fait que le DAG par défaut est placé dans le DagBag dans état de pause, de sorte que le planificateur ne soit pas submergé par une grande quantité d'activités de renvoi au démarrage/au redémarrage.
Pour contourner ce problème, modifiez le paramètre ci-dessous dans votre fichier airflow.cfg:
# Are DAGs paused by default at creation
dags_are_paused_at_creation = False
J'espère que cela t'aides. À votre santé!
J'ai une théorie sur la cause possible de ce problème dans Google Composer. Il y a une section sur les échecs de dag sur le serveur Web dans la documentation de dépannage de Composer , qui dit:
Évitez d'exécuter le calcul des poids lourds au moment de l'analyse DAG. Contrairement aux nœuds opérateur et ordonnanceur, dont les types d'ordinateur peuvent être personnalisés pour disposer d'une capacité de processeur et de mémoire supérieure, le serveur Web utilise un type d'ordinateur fixe, ce qui peut entraîner des échecs d'analyse DAG si le temps d'analyse est trop important.
Et j'essayais de charger la configuration depuis une source externe (ce qui prenait en réalité une quantité de temps négligeable par rapport à d'autres opérations pour créer un DAG, mais cassait toujours quelque chose, car le serveur Web d'Airflow dans composer s'exécute sur App Engine , qui a des comportements étranges).
J'ai trouvé la solution de contournement dans la discussion de ce problème de Google , et il consiste à créer un DAG distinct avec une tâche qui charge toutes les données nécessaires et les stocke dans une variable de flux d'air:
Variable.set("pipeline_config", config, serialize_json=True)
Alors je pourrais faire
Variable.get("pipeline_config", deserialize_json=True)
Et réussir à générer un pipeline à partir de cela. L'avantage supplémentaire est que je reçois des journaux de cette tâche, que je reçois du serveur Web, à cause de ce problème .