Hop sait exécuter des workflows, mais dès qu’il faut des dépendances entre systèmes, des reprises fines et une vue d’ensemble des traitements, un ordonnanceur dédié s’impose. Apache Airflow est le choix le plus courant. Voici comment les combiner proprement.
Le principe
Chaque tâche Airflow lance un pipeline ou un workflow Hop via Hop Run. Airflow gère l’ordre, les reprises, les alertes et l’historique ; Hop fait le travail sur les données. On ne duplique pas l’orchestration dans les deux outils : les workflows Hop restent courts, Airflow porte les dépendances métier.
Deux façons de déclencher
1. BashOperator ou DockerOperator
from airflow.providers.docker.operators.docker import DockerOperator
load_orders = DockerOperator(
task_id="load_orders",
image="apache/hop:latest",
environment={
"HOP_PROJECT_FOLDER": "/project",
"HOP_PROJECT_NAME": "orders",
"HOP_ENVIRONMENT_NAME": "prod",
"HOP_FILE_PATH": "load-orders.hpl",
"HOP_RUN_CONFIG": "local",
},
mounts=[...],
auto_remove=True,
)Simple, isolé, reproductible. Le code de retour de Hop Run fait échouer la tâche Airflow en cas d’erreur.
2. L’API REST de Hop Server
Si vous exploitez déjà Hop Server, un SimpleHttpOperator peut appeler son API pour lancer un pipeline et un capteur interroge son statut. Utile quand plusieurs outils partagent le même serveur d’exécution.
Logs et diagnostics
Configurez Hop pour écrire ses journaux sur la sortie standard (niveau Basic en prod, Detailed pour investiguer) : Airflow les capture dans les logs de la tâche. Pour l’audit, activez en plus les tables de log de pipeline dans Hop.
Ce qu’il ne faut pas faire
- Lancer Hop GUI ou des scripts non versionnés depuis Airflow.
- Coder les dépendances métier deux fois, dans un workflow Hop et dans un DAG.
- Oublier
auto_remove: les conteneurs s’accumulent.
Ordonnancement, conteneurs et CI sont au programme du module hop-02.