Noël est proche, alors parlons du serveur Web d'Airflow.

Ce que je veux dire

** Le chargement prend beaucoup de temps ** S'il y a un DAG
Le DAG peut ne pas être lu
Il se peut que vous ne puissiez pas accéder à l'écran de gestion du flux d'air
Ce n'est pas grave s'il n'y a que beaucoup de tâches
Puis-je en obtenir environ un millier avec les paramètres par défaut de Componser?
L'avenir est prometteur

Modules qui composent Airflow

Le principal serveur Web cette fois-ci est l'un des modules Airflow. Pour les autres modules,

scheduler
DAG / Planification des tâches et gestion des statuts
worker
Exécuter réellement l'instance de tâche
database
Tenir TaskInstance, DagRun, xcom, variable, etc.
executor
Attribuer des tâches planifiées aux travailleurs

Etc. Pour plus d'informations, l'article de l'astronome est facile à comprendre.

Qu'est-ce que le serveur Web

webserver est l'écran de gestion (illustré ci-dessous), commande CLI (partie), [API](https: //airflow.apache. org / docs / stable / api.html) etc.

Comprendre l'état du DAG / instance de tâche, etc.
Ré-exécutez l'instance de DAG / tâche et changez le statut

Nous acceptons les traitements tels que.

En interne, il a une configuration Flask + Gunicorn, et le point de terminaison de l'écran est [ici](https://github.com/apache/airflow/blob/1.10.2/airflow/www/views. Défini dans py).

Airflow UI (La figure provient d'Airflow page officielle)

Problème de DAG qui prend beaucoup de temps à charger

En plus d'accepter les demandes, le serveur Web ** lit régulièrement les fichiers DAG **.

En conséquence, s'il faut ** charger ** du fichier DAG,

Le DAG correspondant ne peut pas être lu
Accès lourd au serveur Web
Je ne peux même pas accéder (affichage de la page d'erreur)

quelquefois

Est-ce un avertissement? Ça a été.

Le chargement prend-il beaucoup de temps?

Il peut être déroutant que ** cela prenne beaucoup de temps pour charger le DAG ** et ** cela prenne beaucoup de temps pour exécuter DAG Run **, mais c'est une autre histoire, et le premier est le problème cette fois.

Pour donner un exemple, il s'agit d'un ** DAG qui prend beaucoup de temps à se charger **

    sleep(10000000)
    start = DummyOperator(task_id='start')

Il s'agit d'un ** DAG qui prend beaucoup de temps à exécuter ** DAG Run.

        def hoge():
            sleep(1000000)
        slow_task = PythonOperator(
            task_id='query_' + str(i),
            python_callable=hoge,
        )

Le chargement peut être lent s'il y a un grand nombre de tâches ou si vous accédez à l'extérieur ** en dehors de la tâche.

Flux d'analyse du serveur Web DAG

Pour ceux qui s'inquiètent du déroulement détaillé:

Périodiquement (*) [Redémarrer le processus enfant (gunicorn worker)] au démarrage du serveur Définir sur (https://github.com/apache/airflow/blob/4a344f13d26ecbb627bb9968895b290bfd86e4da/airflow/cli/commands/webserver_command.py#L146)
[L'objet DagBag est créé] lors du chargement du fichier de point final (https://github.com/apache/airflow/blob/cb8b2a1dc64c3ea6ba445893c65c6c953dfb476a/airflow/www/views.py#L92)
Lors de la création de l'objet DagBag, le fichier DAG est analysé (https://github.com/apache/airflow/blob/cb8b2a1dc64c3ea6ba445893c65c6c953dfb476a/airflow/models.py#L321)

Plus précisément, worker_refresh_interval secondes

Relation avec le nombre de tâches

Cloud Composer (Airflow 1.10.2) - Je l'ai essayé avec DAG uniquement pour BigQuery Operator:

Environ 1000 tâches par DAG peuvent être affichées même avec les paramètres par défaut
Lorsqu'il y a environ 3000 tâches par DAG, il ne peut pas être affiché avec les paramètres par défaut.
Scheduler et Worker fonctionneront même si le serveur Web est lourd (vérifiez avec Stackdriver)
Vous pouvez prolonger le délai (worker_refresh_interval) ou rendre le chargement asynchrone (async_dagbag_loader).

Si seule la vue graphique ou la vue arborescente est lourde, il semble bon de modifier default_dag_run_display_number.

Une histoire d'avenir radieuse

Certaines améliorations ont été proposées pour ce "DAG de chargement".

Cloud Composer implémente une option pour définir le chargement du DAG asynchrone sur le serveur Web (https://cloud.google.com/composer/docs/how-to/accessing/airflow-web-interface#asynchronous-load) Il a également été [porté] sur Airflow 1.10.4 (https://issues.apache.org/jira/browse/AIRFLOW-4924).

C'est toujours un brouillon, mais [AIP-24 DAG Persistence in DB using JSON for Airflow Webserver et (facultatif) Scheduler](https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-24+DAG+Persistence+in La proposition (+ DB + en utilisant + JSON + pour + Airflow + Webserver + et +% 28optional% 29 + Scheduler? FocusedCommentId = 123898950) est un changement plus important.

Arrêtez d'analyser DAG sur le serveur Web
le planificateur analyse le DAG et place le résultat de la sérialisation dans la base de données
le serveur Web utilise le résultat

Nous proposons des options. (Il semble qu'il ne soit pas bon que le serveur Web ait un état en premier lieu Il semble qu'il y ait une histoire))

Serveur Web Cloud Composer

Remarque sur le serveur Web Cloud Composer:

Projet locataire (projet non géré par le client), fonctionne avec GAE Flexible avec CPU2 core
Les spécifications ne peuvent pas être modifiées ...
Vous pouvez [pouvez] déplacer le serveur Web vers le cluster GKE (https://cloud.google.com/composer/docs/how-to/managing/deploy-webserver?hl=ja)
Si la modification des paramètres de flux d'air ne fonctionne pas, cela vaut peut-être la peine d'essayer

À propos, Astronomer.io peut changer la taille de vCPU / Memory.

[PYTHON] L'histoire du serveur Web et du DAG d'Airflow, dont le chargement prend beaucoup de temps