Weihnachten steht vor der Tür, also sprechen wir über den Webserver von Airflow.

Was ich sagen will

** Das Laden dauert lange ** Wenn eine DAG vorhanden ist
Die DAG darf nicht gelesen werden
Möglicherweise können Sie nicht auf den Airflow-Verwaltungsbildschirm zugreifen
Es ist in Ordnung, wenn es nur viele Aufgaben gibt
Kann ich mit den Standardeinstellungen von Componser ungefähr tausend erreichen?
Die Zukunft ist hell

Module, aus denen der Luftstrom besteht

Der führende Webserver ist diesmal eines der Airflow-Module. Für andere Module

scheduler
DAG / Aufgabenplanung und Statusverwaltung
worker
Führen Sie die Taskinstanz tatsächlich aus
database
Halten von TaskInstance, DagRun, xcom, Variable usw.
executor
Ordnen Sie den Mitarbeitern geplante Aufgaben zu

Und so weiter. Weitere Informationen finden Sie in Astronomers Artikel.

Was ist Webserver?

Webserver ist der Verwaltungsbildschirm (siehe unten), CLI-Befehl (Teil), [API](https: //airflow.apache). org / docs / stabile / api.html) usw.

Den Status der DAG / Task-Instanz usw. verstehen.
Führen Sie die DAG / Task-Instanz erneut aus und ändern Sie den Status

Wir akzeptieren die Verarbeitung wie.

Intern hat es eine Flask + Gunicorn-Konfiguration und der Endpunkt auf dem Bildschirm ist hier. In py definiert).

Airflow UI (Die Abbildung stammt von Airflow offizielle Seite)

Das Laden des DAG-Problems dauert lange

Der Webserver ** akzeptiert nicht nur Anfragen, sondern liest auch regelmäßig DAG-Dateien **.

Wenn die DAG-Datei ** geladen ** werden muss,

Die entsprechende DAG kann nicht gelesen werden
Starker Zugriff auf den Webserver
Ich kann nicht einmal darauf zugreifen (Fehlerseitenanzeige)

Manchmal

Ist es eine Warnung? Es ist gewesen.

Das Laden dauert lange?

Es mag verwirrend sein, dass ** das Laden von DAG ** lange dauert ** und ** das Ausführen von DAG Run ** lange dauert **, aber es ist eine andere Geschichte, und erstere ist diesmal das Problem.

Dies ist beispielsweise eine ** DAG, deren Laden lange dauert **

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

Dies ist eine ** DAG, deren Ausführung ** lange dauert **.

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

Das Laden kann langsam sein, wenn eine große Anzahl von Aufgaben vorhanden ist oder wenn Sie außerhalb der Aufgabe auf die Außenseite ** zugreifen.

Fluss des Webservers, der DAG analysiert

Für diejenigen, die sich Sorgen um den detaillierten Ablauf machen:

Regelmäßig (*) [Untergeordneter Prozess neu starten (Gunicorn Worker)] beim Starten des Webservers Auf (https://github.com/apache/airflow/blob/4a344f13d26ecbb627bb9968895b290bfd86e4da/airflow/cli/commands/webserver_command.py#L146) einstellen.
[DagBag-Objekt wird erstellt] beim Laden der Endpunktdatei (https://github.com/apache/airflow/blob/cb8b2a1dc64c3ea6ba445893c65c6c953dfb476a/airflow/www/views.py#L92)
Während das DagBag-Objekt erstellt wird, wird die DAG-Datei analysiert (https://github.com/apache/airflow/blob/cb8b2a1dc64c3ea6ba445893c65c6c953dfb476a/airflow/models.py#L321).

Insbesondere worker_refresh_interval Sekunden

Beziehung zur Anzahl der Aufgaben

Cloud Composer (Airflow 1.10.2) ・ Ich habe es mit DAG nur für BigQuery Operator versucht:

Selbst mit den Standardeinstellungen können ca. 1000 Aufgaben pro DAG angezeigt werden
Wenn pro DAG ungefähr 3000 Aufgaben vorhanden sind, können diese nicht mit den Standardeinstellungen angezeigt werden.
Scheduler und Worker funktionieren auch dann, wenn der Webserver schwer ist (überprüfen Sie dies mit dem Stackdriver).
Sie können das Timeout verlängern (worker_refresh_interval) oder das Laden asynchron machen (async_dagbag_loader).

Wenn nur die Diagrammansicht oder die Baumansicht schwer ist, scheint es gut zu sein, die Standardnummer_dag_run_display_number zu ändern.

Eine glänzende Zukunftsgeschichte

Für diese "Lade-DAG" wurden einige Verbesserungen vorgeschlagen.

Cloud Composer implementiert eine Option zum Festlegen des asynchronen DAG-Ladens auf dem Webserver (https://cloud.google.com/composer/docs/how-to/accessing/airflow-web-interface#asynchronous-load). Es wurde auch auf Airflow 1.10.4 (https://issues.apache.org/jira/browse/AIRFLOW-4924) portiert.

Es ist noch ein Entwurf, aber [AIP-24 DAG-Persistenz in DB mit JSON für Airflow Webserver und (optionalem) Scheduler](https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-24+DAG+Persistence+in Der Vorschlag + DB + mit + JSON + für + Airflow + Webserver + und +% 28optional% 29 + Scheduler (FocusedCommentId = 123898950) ist eine bedeutendere Änderung.

Stoppen Sie das Parsen der DAG auf dem Webserver
Der Scheduler analysiert die DAG und legt das Serialisierungsergebnis in der Datenbank ab
Webserver verwendet das Ergebnis

Wir schlagen Optionen vor. (Es scheint nicht gut zu sein, dass der Webserver überhaupt einen Status hat Es scheint, dass es eine Geschichte gibt))

Cloud Composer-Webserver

Ein Hinweis zum Cloud Composer-Webserver:

Mandantenprojekt (Projekt nicht von Kunden verwaltet), läuft auf GAE Flexible mit CPU2-Kern
Technische Daten können nicht geändert werden ...
Sie können den Webserver in den GKE-Cluster verschieben (https://cloud.google.com/composer/docs/how-to/managing/deploy-webserver?hl=ja).
Wenn das Ändern der Luftstromeinstellungen nicht funktioniert, lohnt es sich möglicherweise, es zu versuchen

Astronomer.io kann übrigens die Größe von [vCPU / Memory] ändern (https://www.astronomer.io/docs/running-jobs-and-scaling/).

[PYTHON] Die Geschichte von Airflows Webserver und DAG, deren Laden lange dauert