web-dev-qa-db-fra.com

Comment accéder à la réponse de la requête GET Airflow SimpleHttpOperator

J'apprends Airflow et j'ai une question simple. Ci-dessous est mon DAG appelé dog_retriever

import airflow
from airflow import DAG
from airflow.operators.http_operator import SimpleHttpOperator
from airflow.operators.sensors import HttpSensor
from datetime import datetime, timedelta
import json



default_args = {
    'owner': 'Loftium',
    'depends_on_past': False,
    'start_date': datetime(2017, 10, 9),
    'email': '[email protected]',
    'email_on_failure': False,
    'email_on_retry': False,
    'retries': 3,
    'retry_delay': timedelta(minutes=3),
}

dag = DAG('dog_retriever',
    schedule_interval='@once',
    default_args=default_args)

t1 = SimpleHttpOperator(
    task_id='get_labrador',
    method='GET',
    http_conn_id='http_default',
    endpoint='api/breed/labrador/images',
    headers={"Content-Type": "application/json"},
    dag=dag)

t2 = SimpleHttpOperator(
    task_id='get_breeds',
    method='GET',
    http_conn_id='http_default',
    endpoint='api/breeds/list',
    headers={"Content-Type": "application/json"},
    dag=dag)

t2.set_upstream(t1)

Pour tester Airflow, je fais simplement deux requêtes GET à certains points de terminaison dans cette API très simple http://dog.ceo . L'objectif est d'apprendre à travailler avec certaines données récupérées via Airflow

L'exécution fonctionne - mon code appelle avec succès les points de connexion dans les tâches t1 et t2, je peux les voir enregistrés dans l'interface utilisateur Airflow, dans l'ordre correct en fonction du set_upstream règle que j'ai écrite.

Ce que je ne peux pas comprendre, c'est comment accéder à la réponse json de ces 2 tâches. Cela semble si simple, mais je ne peux pas le comprendre. Dans SimpleHtttpOperator, je vois un paramètre pour response_check, mais rien pour simplement imprimer, stocker ou afficher la réponse json.

Merci.

airflowapache-airflowdata-pipeline
8
Rachel Lanman

Donc, puisque c'est SimpleHttpOperator et le json réel est poussé vers XCOM et vous pouvez l'obtenir à partir de là. Voici la ligne de code pour cette action: https://github.com/Apache/incubator-airflow/blob/master/airflow/operators/http_operator.py#L87

Ce que vous devez faire est de définir xcom_Push=True, donc votre premier t1 sera le suivant:

t1 = SimpleHttpOperator(
    task_id='get_labrador',
    method='GET',
    http_conn_id='http_default',
    endpoint='api/breed/labrador/images',
    headers={"Content-Type": "application/json"},
    xcom_Push=True,
    dag=dag)

Vous devriez pouvoir trouver tous les JSON avec return value dans XCOM, plus de détails sur XCOM peuvent être trouvés sur: https://airflow.incubator.Apache.org/concepts.html#xcoms

13
Chengzhi

J'ajoute cette réponse principalement à toute personne qui essaie (ou qui veut) d'appeler un DAG de flux de travail Airflow à partir d'un processus et de reçoit toutes les données résultant de l'activité du DAG.

Il est important de comprendre qu'un HTTP POST est requis pour exécuter un DAG et que le réponse à ceci POST est codé en dur dans Airflow, c.-à-d. sans modification du code Airflow lui-même, Airflow ne renverra jamais rien d'autre qu'un code d'état et un message au processus demandeur.

Airflow semble être utilisé principalement pour créer des pipelines de données pour les workflows ETL (extraire, transformer, charger), les opérateurs de flux d'air existants , par exemple SimpleHttpOperator, peut obtenir des données des services Web RESTful , les traiter et les écrire dans des bases de données à l'aide d'autres opérateurs, mais ne le renvoyez pas dans la réponse au HTTP POST qui exécute le workflow DAG.

Même si les opérateurs ont renvoyé ces données dans la réponse, la lecture du code source d'Airflow confirme que la méthode trigger_dag () ne les vérifie pas ou ne les renvoie pas:

Apache_airflow_airflow_www_api_experimental_endpoints.py

Apache_airflow_airflow_api_client_json_client.py

Il ne fait que renvoyer ce message de confirmation:

Message Airflow DagRun reçu dans le service d'orchestration

Comme Airflow est OpenSource, je suppose que nous pourrions modifier la méthode trigger_dag () pour renvoyer les données, mais nous serions alors bloqués à maintenir la base de code fourchue, et nous ne serions pas en mesure d'utiliser des services hébergés dans le cloud, basés sur Airflow comme Cloud Composer sur Google Cloud Platform, car il n'inclurait pas notre modification.

Pire encore, Apache Airflow ne renvoie même pas correctement son message d'état codé en dur.

Lorsque nous [~ # ~] publions [~ # ~] avec succès dans le flux d'air /dags/{DAG-ID}/dag_runs endpoint, nous recevons une réponse "200 OK", pas une réponse "201 Créé" comme nous le devrions. Et Airflow "code en dur" le corps du contenu de la réponse avec son message d'état "Créé…". La norme , cependant consiste à renvoyer l'URI de la ressource nouvellement créée dans l'en-tête de la réponse , pas dans le corps… ce qui laisserait le corps libre de renvoyer toutes les données produites/agrégées pendant (ou résultant de) cette création.

J'attribue cette faille à l'approche "aveugle" (ou ce que j'appelle "naïf") pilotée par Agile/MVP, qui n'ajoute que les fonctionnalités demandées plutôt que de rester consciente et de laisser de la place à une utilité plus générale. Étant donné que Airflow est largement utilisé pour créer des pipelines de données pour (et par) les scientifiques des données (pas les ingénieurs logiciels), le Les opérateurs de flux d'air peuvent partager des données les uns avec les autres en utilisant sa fonction propriétaire XCom interne comme le souligne la réponse utile de @Chengzhi (merci!) mais ne peut pas sous toutes les circonstances retournent des données au demandeur qui a lancé le DAG, c'est-à-dire qu'un SimpleHttpOperator peut récupérer des données d'un service RESTful tiers et peut partager ces données avec un PythonOperator (via XCom) qui enrichit, l'agrège et/ou le transforme. Le PythonOperator peut ensuite partager ses données avec un PostgresOperator qui stocke le résultat directement dans une base de données. Mais le résultat ne peut jamais être retourné au processus qui a demandé que le travail soit fait , c'est-à-dire notre service d'orchestration, ce qui rend Airflow inutile pour tout autre cas d'utilisation que celui sous l'impulsion de ses utilisateurs actuels.

Les points à retenir ici (pour moi au moins) sont 1) de ne jamais attribuer trop d'expertise à quiconque ou à n'importe quelle organisation. Apache est une organisation importante avec des racines profondes et vitales dans le développement de logiciels… mais elles ne sont pas parfaites. Et 2) méfiez-vous toujours des solutions internes et propriétaires. Des solutions ouvertes et basées sur des normes ont été examinées et examinées sous de nombreux angles différents, et pas seulement un.

J'ai perdu près d'une semaine à chercher différentes façons de faire ce qui me semblait très simple et raisonnable. J'espère que cette réponse fera gagner du temps à quelqu'un d'autre.

3
Doug Wilson