## Introduction Apache Hop est une plateforme d'orchestration de données et d'ETL qui permet de concevoir, exécuter et surveiller des pipelines de données. Comme tout outil d'intégration de données, ses performances dépendent de la configuration du moteur, de la conception du pipeline et de l'environnement d'exécution. Ce guide fournit des étapes pratiques pour identifier les goulots d'étranglement, dimensionner les ressources, réduire la latence et augmenter le débit dans Apache Hop. Vous apprendrez à inventorier votre environnement, à appliquer des modifications de configuration en toute sécurité, à vérifier les améliorations avec des commandes concrètes et à récupérer des défaillances courantes. Les conseils sont basés sur une expérience pratique et suivent un processus de réglage mesuré : commencez par un pilote restreint et mesurable, puis étendez. Cette approche réduit les retouches et vous aide à obtenir des pipelines de données fiables et rapides. ## Inventaire de la version et de l'environnement Avant tout réglage, vous devez savoir exactement ce que vous exécutez. Rassemblez la version d'Apache Hop, la version de Java, le système d'exploitation, les ressources matérielles et la topologie du pipeline. Utilisez les commandes suivantes pour collecter ces informations. ### Vérifier la version d'Apache Hop Apache Hop fournit une option en ligne de commande pour afficher sa version. Placez-vous dans le répertoire d'installation de Hop et exécutez : ./hop-run.sh --version Exemple de sortie : Apache Hop 2.0.0 Si vous êtes sous Windows, utilisez hop-run.bat --version . ### Vérifier la version de Java Apache Hop fonctionne sur Java. Vérifiez la version de Java avec : java -version Exemple de sortie : openjdk version "11.0.15" 2022-04-19 OpenJDK Runtime Environment (build 11.0.15+10) OpenJDK 64-Bit Server VM (build 11.0.15+10, mode mixte) Hop 2.0 nécessite Java 11 ou une version ultérieure. L'utilisation d'une version Java non prise en charge peut provoquer des plantages ou de mauvaises performances. ### Vérifier le système d'exploitation et le CPU/mémoire Sous Linux, utilisez : uname -a free -h lscpu Sous Windows, utilisez systeminfo ou le Gestionnaire des tâches. ### Topologie du pipeline Documentez les étapes du pipeline : systèmes sources, serveur(s) Hop et systèmes cibles. Notez si vous exécutez Hop localement (interface graphique Hop) ou sur un serveur Hop. Pour les déploiements sur serveur, vérifiez les fichiers de configuration Hop (par exemple, hop-config.json , hop-server.xml ) pour les paramètres tels que la mémoire, les pools de threads et la journalisation. ### Métriques de référence Établissez une référence de performance avant toute modification. Enregistrez les éléments suivants pour une exécution représentative du pipeline : - Durée totale d'exécution - Lignes traitées par seconde - Utilisation du CPU et de la mémoire pendant l'exécution - Erreurs ou avertissements dans les journaux Vous pouvez mesurer la durée d'exécution à l'aide de l'interface graphique Hop ou en ligne de commande. En ligne de commande, utilisez la commande time sous Linux : time ./hop-run.sh --file=/chemin/vers/pipeline.hpl --level=Basic Exemple de sortie : real 2m30.123s user 1m45.678s sys 0m12.345s Vous disposez maintenant des bases pour le réglage. ## Chemin de configuration sûr Le réglage d'Apache Hop implique l'ajustement de paramètres dans plusieurs domaines : allocation mémoire, exécution parallèle, mise en cache et journalisation. Effectuez les modifications de manière incrémentale et testez après chaque changement. Utilisez un système de contrôle de version pour les fichiers de configuration et les définitions de pipeline afin de pouvoir revenir en arrière facilement. ### 1. Paramètres de mémoire Apache Hop s'exécute sur la machine virtuelle Java (JVM). La taille de tas par défaut peut être trop petite pour de grands ensembles de données. Augmentez la taille maximale du tas dans le script de démarrage Hop ou les variables d'environnement. Localisez le script de démarrage : Dans le répertoire d'installation de Hop, modifiez hop-run.sh (Linux) ou hop-run.bat (Windows). Recherchez la variable JAVA_OPTS ou HOP_OPTS . Ajoutez ou modifiez le paramètre -Xmx : export HOP_OPTS="-Xmx2048m" Pour un système 64 bits avec beaucoup de RAM, vous pouvez définir -Xmx4096m ou plus. Veillez à ne pas dépasser la mémoire physique disponible ; laissez de la place pour le système d'exploitation et les autres processus. Résultat attendu : Un tas plus grand réduit les erreurs de mémoire insuffisante et permet de traiter de plus grands lots, mais un tas trop grand peut provoquer de longues pauses de garbage collection. Surveillez avec jstat (voir la section Vérification). ### 2. Exécution parallèle Apache Hop peut exécuter les étapes de transformation en parallèle. Par défaut, chaque étape s'exécute en une seule copie. Pour augmenter le débit, vous pouvez modifier le nombre de copies pour une étape. Dans l'interface graphique Hop : Faites un clic droit sur une étape, sélectionnez « Modifier le nombre de copies à démarrer... » et saisissez un nombre (par exemple, 4). Cela lance plusieurs instances de l'étape, chacune traitant une partie des données. Dans le XML du pipeline : Définissez l'attribut copies sur l'élément d'étape. Exemple : Entrée table TableInput 4 ... Attention : Augmenter les copies n'améliore pas toujours les performances si le goulot d'étranglement est ailleurs (par exemple, le pool de connexions de base de données). Testez d'abord avec un petit ensemble de données. ### 3. Mise en cache et recherches Pour les étapes de recherche (par exemple, « Recherche de flux », « Recherche de base de données »), la mise en cache peut améliorer considérablement les performances en évitant les requêtes répétées à la base de données. Activez la mise en cache dans la configuration de l'étape. Dans l'interface graphique Hop : Dans la boîte de dialogue de l'étape de recherche, cochez « Activer le cache ? » et définissez la taille du cache (par exemple, 5000 lignes). Résultat attendu : Les recherches ultérieures pour la même clé sont servies depuis la mémoire, réduisant les allers-retours avec la base de données. ### 4. Niveau de journalisation Une journalisation excessive peut ralentir les pipelines. Définissez le niveau de journalisation sur Basic ou Error pour les exécutions en production, et utilisez Debug uniquement pour le dépannage. Ligne de commande : Utilisez --level=Basic lors de l'exécution d'un pipeline : ./hop-run.sh --file=/chemin/vers/pipeline.hpl --level=Basic Dans l'interface graphique Hop : Allez dans Exécution -> Configurations d'exécution, et définissez le niveau de journalisation. ### 5. Taille de lot et taille de validation Pour les opérations de base de données, ajustez la taille de lot et la taille de validation. Des lots plus grands réduisent les frais de transaction mais peuvent augmenter la consommation de mémoire. Dans une étape « Sortie table », définissez « Taille de validation » (par exemple, 1000) et « Taille de lot » (par exemple, 1000) en conséquence. ### 6. Planification des ressources Si vous exécutez plusieurs pipelines simultanément, utilisez la planification intégrée de Hop ou un planificateur externe pour éviter les conflits de ressources. Échelonnez les travaux lourds ou allouez des ressources dédiées. ### Étapes de mise en œuvre sûres - Créez une sauvegarde de tous les fichiers de configuration et définitions de pipeline. - Effectuez une modification à la fois. - Exécutez un pipeline de test représentatif et comparez les métriques à la référence. - Si les performances s'améliorent et qu'aucune erreur ne se produit, passez à la modification suivante ; sinon, revenez en arrière. ## Vérification et diagnostic Après avoir appliqué les modifications, vérifiez que les performances se sont améliorées et que le système reste stable. Utilisez les commandes et outils suivants. ### Mesurer la durée d'exécution Utilisez time comme précédemment pour comparer avant et après. Par exemple : time ./hop-run.sh --file=/chemin/vers/pipeline.hpl --level=Basic Notez le temps real . Une amélioration significative devrait réduire le temps total d'au moins 10 à 20 % pour la même charge de travail. ### Surveiller la mémoire JVM et le garbage collection Utilisez jstat pour surveiller l'utilisation du tas et l'activité GC pendant l'exécution du pipeline. Tout d'abord, trouvez l'identifiant de processus Java (PID) de l'exécution Hop. Sous Linux, utilisez ps aux | grep hop ou jps . Ensuite, exécutez : jstat -gcutil 1000 10 Cela échantillonne toutes les 1000 ms, 10 fois. Exemple de sortie : S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 42.31 68.12 22.45 95.12 87.34 12 0.523 1 0.102 0.625 Surveillez les GC complets fréquents (FGC) ou un temps GC élevé (GCT) qui indiquent une pression mémoire. Si vous voyez de nombreux GC complets, envisagez d'augmenter la taille du tas ou de réduire l'utilisation de la mémoire dans les étapes. ### Vérifier les métriques du pipeline Les journaux Apache Hop fournissent des métriques au niveau des étapes telles que les lignes lues, écrites et les erreurs. Par défaut, les journaux vont à la console et à un fichier journal dans le répertoire Hop. Recherchez des lignes comme : 2025/03/01 10:15:30 - Entrée table.0 - Fin de la lecture de la requête, fermeture de la connexion. 2025/03/01 10:15:31 - Entrée table.0 - lignenr 10000 Pour obtenir un résumé, activez la journalisation « Métriques » dans les paramètres du pipeline. Dans l'interface graphique, allez dans Propriétés du pipeline -> Journalisation -> cochez « Activer la surveillance des performances des étapes ? ». Ensuite, après une exécution, vous pouvez afficher les graphiques de performance dans l'interface graphique Hop sous l'onglet « Métriques ». ### Valider les performances des requêtes de base de données Si le goulot d'étranglement est une requête de base de données, utilisez les outils de la base de données pour analyser les plans d'exécution des requêtes. Pour PostgreSQL, utilisez EXPLAIN ANALYZE : EXPLAIN ANALYZE SELECT * FROM grande_table WHERE condition; Recherchez les balayages séquentiels ou les index manquants. Ajoutez des index appropriés pour accélérer les recherches. ### E/S réseau et disque Pour les pipelines basés sur des fichiers, vérifiez le débit du disque avec iostat sous Linux : iostat -x 1 Un %util élevé proche de 100 % indique une saturation du disque. Envisagez d'utiliser un stockage plus rapide ou d'optimiser les modèles d'accès aux fichiers. ### Résumé des résultats attendus
MétriqueRéférenceAprès réglageNotes
Durée totale d'exécution2 min 30 s1 min 45 sAmélioration de 30 %
Lignes par seconde20003200Débit accru
Nombre de GC complets50Aucun GC complet pendant l'exécution
Copies d'étape14Traitement parallèle
## Pièges courants et comment les éviter ### 1. Définir un tas trop grand Pourquoi cela arrive : L'hypothèse selon laquelle plus de mémoire aide toujours. Mais un tas surdimensionné peut entraîner des pauses de garbage collection plus longues et même provoquer un swap du système d'exploitation, réduisant considérablement les performances. Comment éviter : Commencez avec une taille de tas raisonnable basée sur votre volume de données et la RAM disponible. Une bonne règle empirique consiste à définir le tas initial ( -Xms ) à la même valeur que le tas maximal ( -Xmx ) pour éviter les frais de redimensionnement. Testez avec des données réalistes et surveillez le comportement du GC. Si vous voyez des GC complets fréquents ou de longues pauses, réduisez le tas ou retravaillez les étapes gourmandes en mémoire. Comment récupérer : Réduisez la valeur -Xmx et redémarrez le pipeline. Si les erreurs de mémoire insuffisante persistent, optimisez le pipeline pour diffuser les données au lieu de tout charger en mémoire. ### 2. Sur-paralléliser les étapes Pourquoi cela arrive : Les utilisateurs augmentent le nombre de copies pour chaque étape, s'attendant à une amélioration linéaire. Cependant, si le goulot d'étranglement est une source monothread ou un pool de connexions de base de données, le parallélisme peut ne pas aider et peut même nuire en raison de la contention. Comment éviter : Identifiez le véritable goulot d'étranglement avant de passer à l'échelle. Utilisez la surveillance pour voir quelle étape est la plus lente. Augmentez les copies uniquement pour les étapes liées au CPU ou aux E/S qui peuvent bénéficier d'un travail parallèle, et soyez conscient des limites de ressources (par exemple, les connexions de base de données). Comment récupérer : Réduisez le nombre de copies à un niveau qui évite la contention. Pour les étapes gourmandes en base de données, assurez-vous que le pool de connexions est dimensionné de manière appropriée. ### 3. Ignorer les index de base de données Pourquoi cela arrive : Les pipelines peuvent être lents parce que les requêtes SQL sous-jacentes effectuent des balayages complets de table en raison d'index manquants. Cela est souvent négligé lors du réglage de la configuration Hop. Comment éviter : Utilisez EXPLAIN pour analyser les requêtes utilisées dans les étapes du pipeline. Ajoutez des index aux colonnes utilisées dans les clauses WHERE , JOIN et ORDER BY . Maintenez les statistiques à jour. Comment récupérer : Ajoutez les index nécessaires dans la base de données et réexécutez le pipeline. Surveillez le plan d'exécution pour confirmer que l'index est utilisé. ### 4. Journalisation excessive en production Pourquoi cela arrive : La journalisation de niveau Debug ou Row est laissée activée depuis le développement. Cela crée une surcharge massive d'E/S et de CPU, ralentissant considérablement le pipeline. Comment éviter : Définissez le niveau de journalisation par défaut sur Basic ou Error pour les exécutions en production. N'activez Debug que lors du dépannage actif d'un problème, puis désactivez-le. Comment récupérer : Modifiez le niveau de journalisation et redémarrez le pipeline. Vous devriez constater une amélioration immédiate du débit. ### 5. Ne pas versionner les configurations Pourquoi cela arrive : Dans la précipitation du réglage, les modifications sont apportées directement sur le serveur sans documentation ni sauvegardes, rendant impossible le retour en arrière en cas de problème. Comment éviter : Stockez tous les fichiers de configuration et définitions de pipeline dans un dépôt Git. Effectuez les modifications sur une branche, testez, puis fusionnez en production. Documentez chaque modification avec la justification et l'impact mesuré. Comment récupérer : Si une modification pose problème, revenez au commit précédent et redéployez. C'est beaucoup plus rapide et sûr que d'essayer de se souvenir de ce qui a été changé. ## Modes de défaillance et récupération Même avec un réglage soigné, des problèmes peuvent survenir. Reconnaissez les modes de défaillance courants et sachez comment récupérer. ### Erreurs de mémoire insuffisante Symptôme : Le pipeline échoue avec java.lang.OutOfMemoryError: Java heap space . Cause : Taille de tas trop petite ou volume de données trop important pour la mémoire. Récupération : Augmentez -Xmx dans le script de démarrage, ou réduisez l'utilisation de la mémoire en diminuant la taille des lots, en mettant moins en cache ou en diffusant les données en plus petits morceaux. Redémarrez le pipeline. Si l'erreur persiste, examinez la conception du pipeline pour les opérations gourmandes en mémoire comme le tri de grands ensembles de données en mémoire. Responsable : Le développeur du pipeline est responsable de la surveillance de l'utilisation de la mémoire et de l'ajustement des paramètres du tas. Révisez la configuration mensuellement ou chaque fois que le volume de données change de manière significative. ### Surcharge du garbage collection Symptôme : Le pipeline s'exécute lentement, l'utilisation du CPU est élevée, mais peu de données sont traitées. jstat montre des GC complets fréquents avec de longues pauses. Cause : Tas trop grand ou renouvellement d'objets. Récupération : Réduisez la taille du tas à un niveau qui évite le pagination, ou réglez l'algorithme GC (par exemple, utilisez G1GC). Ajoutez des options JVM : -XX:+UseG1GC -XX:MaxGCPauseMillis=200 . Responsable : L'administrateur système ou l'ingénieur performance doit surveiller les métriques GC chaque semaine et ajuster les paramètres si nécessaire. ### Épuisement du pool de connexions de base de données Symptôme : Erreurs comme « Impossible d'obtenir une connexion, erreur de pool Timeout waiting for idle object ». Cause : Trop de requêtes simultanées ou taille du pool de connexions trop petite. Récupération : Augmentez la taille du pool dans la configuration de connexion de base de données dans Hop, ou réduisez le nombre de copies parallèles qui utilisent la base de données. Vérifiez également les limites du serveur de base de données. Responsable : L'administrateur de base de données possède les paramètres du pool de connexions et doit les revoir mensuellement ou lorsque de nouveaux pipelines sont déployés. ### Blocage ou interblocage du pipeline Symptôme : Le pipeline cesse de traiter sans erreurs. Cause : Interblocage possible dû à la contention des ressources ou à des transformations bloquantes. Récupération : Arrêtez le pipeline, examinez les journaux pour la dernière activité, vérifiez les étapes en attente de ressources externes. Augmentez les délais d'attente ou reconcevez le pipeline pour éviter les dépendances circulaires. Responsable : Le développeur du pipeline enquête et résout les blocages. Révisez la conception trimestriellement pour éviter la récurrence. ### Plan de retour en arrière Avant d'apporter des modifications, assurez-vous de pouvoir revenir en arrière : - Conservez des sauvegardes des fichiers de configuration (par exemple, hop-config.json , hop-server.xml , fichiers .hpl du pipeline). - Utilisez le contrôle de version (Git) pour les définitions de pipeline. - Documentez les modifications exactes apportées afin de pouvoir les annuler. Pour revenir en arrière, restaurez les fichiers de sauvegarde ou annulez le commit Git et redémarrez les services Hop. ### Vérification après récupération Après la récupération, réexécutez le pipeline de référence pour confirmer la stabilité. Exécutez un petit test avant de reprendre les charges de travail de production. ## Liste de contrôle opérationnelle Utilisez cette liste de contrôle pour la gestion continue des performances d'Apache Hop. ### Configuration initiale - [ ] Documenter la version Hop, la version Java, le système d'exploitation et les spécifications matérielles. Responsable : Administrateur système - [ ] Établir des métriques de référence pour les pipelines clés (temps, lignes/sec, utilisation mémoire). Responsable : Développeur de pipeline - [ ] Mettre en place une surveillance de la mémoire JVM, du GC et des journaux de pipeline. Responsable : Équipe des opérations - [ ] Configurer des niveaux de journalisation appropriés pour la production. Responsable : Développeur de pipeline - [ ] Stocker les fichiers de configuration et les définitions de pipeline dans le contrôle de version. Responsable : Ingénieur DevOps Révisez cette configuration trimestriellement ou lorsque des changements d'environnement se produisent. ### Processus de réglage - [ ] Identifier le goulot d'étranglement : CPU, mémoire, E/S ou réseau à l'aide d'outils de surveillance système. Responsable : Ingénieur performance - [ ] Appliquer une modification à la fois (par exemple, augmenter le tas, augmenter les copies, activer le cache). Responsable : Développeur de pipeline - [ ] Exécuter un pipeline de test avec un volume de données représentatif. Responsable : Développeur de pipeline - [ ] Comparer les métriques de performance à la référence. Responsable : Ingénieur performance - [ ] Si l'amélioration est >= 10 % et sans erreur, conserver la modification ; sinon, revenir en arrière. Responsable : Ingénieur performance - [ ] Répéter pour le prochain goulot d'étranglement. Responsable : Ingénieur performance Ce processus est continu ; effectuez-le chaque fois qu'un pipeline est modifié ou que les volumes de données changent. ### Revue périodique - [ ] Revoir les temps d'exécution des pipelines mensuellement. Responsable : Développeur de pipeline - [ ] Vérifier les requêtes de base de données lentes à l'aide des journaux de base de données et EXPLAIN . Responsable : Administrateur de base de données - [ ] Surveiller la croissance de la mémoire JVM et la fréquence des GC. Responsable : Administrateur système - [ ] Évaluer l'utilisation du matériel ; passer à l'échelle si constamment > 80 %. Responsable : Gestionnaire d'infrastructure - [ ] Tester la reprise après sinistre : restaurer à partir des sauvegardes et exécuter un test de fumée. Responsable : Équipe des opérations Planifiez ces revues mensuellement ou trimestriellement selon la criticité. ### Contrôles de sécurité - [ ] Toujours sauvegarder avant de modifier les configurations. Responsable : Développeur de pipeline - [ ] Ne jamais appliquer plusieurs modifications de performance simultanément en production. Responsable : Ingénieur performance - [ ] Avoir un plan de retour en arrière prêt avant chaque modification. Responsable : Développeur de pipeline - [ ] Garder les modifications documentées avec la justification et l'impact mesuré. Responsable : Développeur de pipeline Ces contrôles ne sont pas négociables avant tout changement en production. ## Conclusion L'optimisation des performances d'Apache Hop est un processus systématique de mesure, de modification et de vérification. Commencez par un inventaire clair de votre environnement, établissez une référence, puis apportez des modifications incrémentales et réversibles. Concentrez-vous sur les paramètres de mémoire, l'exécution parallèle, la mise en cache et la journalisation comme domaines à fort impact. Utilisez les commandes et exemples de ce guide pour vérifier les améliorations et diagnostiquer les problèmes. En suivant la liste de contrôle opérationnelle, vous pouvez maintenir des pipelines de données fiables et efficaces. N'oubliez pas que les meilleurs résultats de réglage proviennent d'une approche pilote restreinte et mesurable, comme recommandé pour un travail de performance pratique. Continuez à surveiller et à ajuster à mesure que vos volumes de données et charges de travail évoluent.