Vous avez optimisé votre pipeline. Vous avez ajouté du partitionnement, augmenté le nombre de copies des transforms les plus coûteux, revu l’ordre des jointures. Le traitement est passé de six heures à deux heures. Puis le volume a doublé, et vous êtes revenus à quatre heures. La machine d’exécution sature : le processeur est à 100 %, la mémoire déborde, et ajouter des copies supplémentaires ne change plus rien.
À ce stade, le problème n’est plus la conception du pipeline mais la machine qui l’exécute. Il faut répartir le travail sur plusieurs noeuds. Apache Hop répond à ce besoin par une voie peu connue : au lieu d’exécuter le pipeline avec son propre moteur, il le traduit en programme Apache Beam et le confie à un moteur distribué — Apache Spark, Apache Flink ou Google Cloud Dataflow. Le pipeline reste le même fichier .hpl, conçu dans la même interface graphique. Seule la configuration d’exécution change.
Cet article décrit la mise en place complète, puis les contraintes réelles de cette approche — car elles existent, et mieux vaut les connaître avant d’engager une migration.
Prérequis
- Apache Hop 2.19.0 (publiée le 17 août 2026) ou une version proche. La page de téléchargement officielle indique explicitement que Hop requires Java 21 : un JDK plus ancien ne suffit pas.
- Un cluster Spark ou Flink accessible, ou un projet Google Cloud avec les API Dataflow activées.
- Un projet Hop fonctionnel. Si la notion de projet et d’environnement ne vous est pas familière, commencez par les projets et environnements dans Apache Hop.
- Une attention particulière aux versions : la documentation de Hop publie une matrice de compatibilité. Pour Hop 2.19.0, elle indique Apache Beam 2.74.0, Spark 3.5.x et Flink 1.19.x. Ne vous écartez pas de ces lignes sans l’avoir vérifiée.
1. Comprendre ce que fait réellement Hop
Hop ne « soumet » pas votre pipeline à Spark comme on soumettrait un script. Il le traduit. Chaque transform devient une transformation Beam, et c’est ce programme Beam que le runner exécute. Cette traduction a deux conséquences majeures.
Premièrement, le moteur d’exécution se choisit dans les métadonnées du projet, et non dans le code du pipeline. Hop fournit quatre configurations d’exécution Beam : Beam Direct, Beam Spark, Beam Flink et Beam Google DataFlow. La première exécute le programme Beam en local : c’est l’outil de mise au point, pas une cible de production.
Deuxièmement, tous les transforms ne survivent pas à la traduction. Certains n’ont pas d’équivalent distribué, d’autres sont réécrits par Hop vers une primitive Beam. Nous y revenons à la section 5 ; retenez dès maintenant qu’un pipeline ne bascule pas toujours tel quel.
2. Générer le fat jar
Les noeuds du cluster n’ont pas Apache Hop installé. Il faut donc leur fournir un fat jar : une archive contenant le moteur Hop, ses plugins et ses dépendances. Deux façons de l’obtenir.
Depuis l’interface graphique, par le menu Tools / Generate a Hop fat jar…. En ligne de commande, depuis le dossier d’installation de Hop :
sh hop-conf.sh -fj /opt/spark/hop-fat-jar.jarPoint de vigilance souvent sous-estimé : ce fichier est un instantané de votre installation. Chaque fois que vous installez, supprimez ou mettez à jour un plugin, ou que vous changez de version de Hop, le fat jar doit être régénéré et redéployé. Un job qui échoue sur « transform introuvable » après une montée de version a presque toujours cette cause.
3. Créer la configuration d’exécution
Dans la perspective Metadata, créez une nouvelle Pipeline Run Configuration et choisissez le moteur correspondant à votre cible. Les options diffèrent selon le runner. Les principales :
| Runner | Options structurantes |
| Beam Spark | The Spark master (local[x], spark://hôte:port, yarn), Bundle size, options de streaming |
| Beam Flink | The Flink master, Parallelism, intervalle et délai de checkpointing, Maximum bundle size |
| Beam Google DataFlow | Project ID, Staging location et Temp location (chemins gs://), Region, Worker machine type, nombre de workers |
Toutes ces configurations partagent un champ essentiel : Fat jar file location, qui pointe vers l’archive produite à l’étape précédente.
Un piège mérite d’être signalé. La documentation est claire sur ce point : les configurations de projet et d’environnement de Hop ne s’appliquent pas dans le runtime Spark ou Flink. Les variables que votre pipeline attend doivent donc être transmises autrement — par les options JVM du driver pour Spark, ou par l’onglet Variables de la configuration d’exécution. Évitez par ailleurs les chemins relatifs du type ${Internal.Entry.Current.Folder} et préférez une variable racine telle que PROJECT_HOME.
4. Soumettre le job au cluster
La soumission demande deux fichiers : le pipeline .hpl et un export JSON des métadonnées du projet (connexions, configurations d’exécution, etc.). C’est l’équivalent, côté cluster, de ce que hop-run reçoit par son option -m, --metadata-export en exécution classique.
Pour Spark, la classe principale à invoquer est org.apache.hop.beam.run.MainBeam :
bin/spark-submit \
--master spark://monserveur.local:7077 \
--class org.apache.hop.beam.run.MainBeam \
--driver-java-options '-DPROJECT_HOME=/opt/hop/projects/ventes' \
/opt/spark/hop-fat-jar.jar \
/opt/hop/projects/ventes/pipelines/consolidation.hpl \
/opt/spark/hop-metadata.json \
SparkLes trois arguments positionnels qui suivent le fat jar sont, dans cet ordre : le pipeline, l’export de métadonnées, et le nom de la configuration d’exécution définie à l’étape 3. Un quatrième argument optionnel permet de désigner un fichier d’environnement.
Pour Flink, la structure est identique, au lanceur près :
bin/flink run \
--class org.apache.hop.beam.run.MainBeam \
--parallelism 4 \
/opt/flink/hop-fat-jar.jar \
/opt/hop/projects/ventes/pipelines/consolidation.hpl \
/opt/flink/hop-metadata.json \
FlinkNotez la différence pratique entre les deux : Spark accepte des options JVM à la soumission via --driver-java-options, Flink non. Avec Flink, les variables passent par la configuration d’exécution ou par env.java.opts dans la configuration du cluster.
5. Les transforms à revoir avant la bascule
C’est la section à lire avant de promettre une date de mise en production. Certains transforms courants ne sont pas supportés sur Beam, parce qu’ils supposent un flux de lignes ordonné et unique — hypothèse qui disparaît dès que les données sont réparties en lots sur plusieurs noeuds.
| Transform | Situation sur Beam |
| Sort Rows | Non supporté |
| Unique Rows | Non supporté |
| Group By | Non supporté : utilisez Memory Group By |
| Memory Group By | Traduit vers la primitive Beam de regroupement par clé |
| Merge Join | Traduit vers la bibliothèque de jointure de Beam ; n’exige pas d’entrée triée |
Pour les sources et les cibles, Hop fournit des transforms dédiés : Beam file input et Beam file output, auxquels s’ajoutent Beam Kafka consume et Beam Kafka produce, Beam BigQuery Input et Beam BigQuery Output, Beam GCP Pub/Sub: publish et Beam GCP Pub/Sub: subscribe, Beam Kinesis consume et Beam Kinesis produce, ainsi que Beam timestamp et Beam window pour le traitement par fenêtres. Un pipeline destiné au cluster gagne à lire et écrire par ces transforms plutôt que par leurs équivalents classiques.
6. Ce que vous perdez en passant sur Beam
La contrepartie est réelle et il serait malhonnête de la passer sous silence. Sur un runner Beam, la prévisualisation des données n’est pas disponible. Le débogage pas à pas et la mise en pause d’un pipeline ne le sont pas non plus. Les tests unitaires de pipelines, eux non plus, ne fonctionnent pas dans ce mode.
La méthode de travail qui en découle est simple : concevez et validez en local, exécutez en distribué. Vous mettez au point le pipeline avec le moteur local, vous écrivez vos tests unitaires là, puis vous vérifiez la bascule en comparant la sortie du runner Beam à un jeu de données de référence produit par l’exécution locale. Le moteur Beam Direct est l’étape intermédiaire utile : il valide que la traduction Beam fonctionne, sans dépendre d’un cluster.
Ce que vous avez gagné
Vous savez désormais faire exécuter un pipeline Hop existant par Spark ou Flink : générer et maintenir le fat jar, déclarer une configuration d’exécution Beam, transmettre les variables malgré l’absence des environnements Hop côté cluster, et soumettre le job avec les bons arguments positionnels. Vous savez surtout quels transforms vérifier avant la bascule, et quelles pratiques de mise au point abandonner.
C’est un changement d’échelle, pas un changement d’outil. Le pipeline que vous avez modélisé dans Hop GUI reste le livrable ; le cluster n’est qu’une cible d’exécution de plus, déclarée à côté du moteur local. Et comme la configuration d’exécution se sélectionne au lancement avec l’option -r de hop-run, le même fichier peut tourner en local pour les tests et en distribué en production.
Pour aller plus loin
- Getting started with Apache Beam — matrice de compatibilité des versions et liste des limitations.
- Apache Beam Spark Pipeline Engine et Apache Beam Flink Pipeline Engine — détail de toutes les options.
- Apache Beam Google DataFlow Pipeline Engine — prérequis GCP et paramétrage des workers.
- hop-run — l’ensemble des options de ligne de commande.
- Parallélisme et partitionnement dans Apache Hop — l’étape à franchir avant d’envisager un cluster.