Un outil visuel, mais qui se traite comme du code
La plupart des ETL visuels finissent par poser le même problème : des flux qu’on ne peut ni relire, ni comparer, ni tester. Hop a été conçu pour l’inverse. Les pipelines sont des fichiers XML lisibles, les métadonnées sont en JSON, et tout tient dans un dossier de projet qu’on versionne avec Git. Une revue de code sur un pipeline Hop est possible ; un diff est compréhensible.
Des projets et des environnements, pas des chemins en dur
Un projet Hop regroupe pipelines, workflows et métadonnées. Un environnement fournit les variables qui changent d’un contexte à l’autre : chemins, connexions, identifiants. Le même pipeline s’exécute en développement, en recette et en production sans être copié. C’est la fin des versions « prod » et « test » qui divergent.
Un moteur local, puis un moteur distribué
Hop exécute en local par défaut. Le jour où le volume l’exige, la même définition de pipeline peut tourner sur Apache Beam, donc sur Spark, Flink ou Google Dataflow. Vous ne réécrivez pas, vous changez de configuration d’exécution.
Des tests intégrés
Hop permet de définir des tests unitaires de pipelines : un jeu de données en entrée, un résultat attendu en sortie. Ces tests s’exécutent en ligne de commande et s’intègrent dans une chaîne d’intégration continue. Une régression se détecte avant la mise en production.
Une licence sans surprise
Apache 2.0. Pas de fonctionnalités réservées à une édition entreprise, pas de limite de serveurs, pas de renégociation annuelle.
Et Kettle dans tout ça ?
Hop est né d’un fork de Kettle (Pentaho Data Integration) mené par une partie de ses concepteurs. Il en garde la logique et une large partie de l’écosystème de plugins, tout en corrigeant les limites structurelles de l’original. Un outil d’import convertit les jobs et transformations existants. C’est l’objet de notre module hop-03.