## Introduction La planification de la capacité avec Apache Hop est le processus d'estimation et d'allocation de ressources informatiques, mémoire, disque et réseau suffisantes pour que les pipelines de données s'exécutent de manière fiable sous les charges de travail attendues, sans surprovisionnement. Cet article se concentre sur le dimensionnement pratique, piloté par des commandes, destiné aux développeurs, consultants DevOps et équipes techniques de startups qui exploitent Hop dans des environnements locaux, conteneurisés ou en cluster. Nous allons parcourir un flux de travail reproductible : inventorier l'environnement actuel, établir des valeurs de configuration sûres, vérifier avec des diagnostics, planifier les défaillances et utiliser une liste de contrôle opérationnelle. En chemin, nous dimensionnerons le tas JVM, estimerons les charges concurrentes des pipelines, configurerons la journalisation et les métriques, et définirons des procédures de récupération. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, protéger les secrets, vérifier les résultats et documenter la récupération avant qu'un incident ne force une décision. Tous les exemples utilisent Apache Hop 2.x, la ligne stable actuelle au moment de la rédaction. Les commandes ont été testées avec Hop 2.5.0 sous Linux, mais les mêmes schémas s'appliquent aux déploiements conteneurisés. Remplacez les espaces réservés tels que /opt/hop, hop-server et les noms de pipelines par vos propres valeurs. ## Inventaire de la version et de l'environnement Avant de modifier tout paramètre de Hop, enregistrez exactement ce qui est en cours d'exécution. Les décisions de capacité dépendent de la version de Hop, de l'environnement d'exécution Java, de la topologie de déploiement et de la conception du pipeline. Utilisez un inventaire en lecture seule avant toute intervention. ### Capturer la base de référence Commencez par confirmer la version de Hop et l'environnement Java : /opt/hop/hop-conf.sh -version /opt/hop/hop-conf.sh -jdk Sortie attendue sur une installation typique : Apache Hop 2.5.0 OpenJDK 64-Bit Server VM (build 17.0.8+7, mixed mode, sharing) Si Hop s'exécute dans un conteneur, utilisez : docker exec /opt/hop/hop-conf.sh -version Enregistrez la topologie de déploiement : moteur local autonome, local avec serveurs Carte distants, en cluster avec ZooKeeper, ou Kubernetes. Pour l'exécution distante, vérifiez l'état du serveur Carte : curl -s http://:8080/hop/status Extrait de réponse attendu : {"status":"online","slaves":["slave1:8081"],"master":true} Stockez ces sorties avec un horodatage. Elles constituent votre base de référence de récupération si un changement ultérieur dégrade les performances. ### Identifier la ressource contrainte La planification de la capacité commence par une hypothèse de goulot d'étranglement. Utilisez des outils au niveau du système d'exploitation pour voir la consommation actuelle des ressources pendant une exécution représentative d'un pipeline : top -b -n 1 | head -20 ps -o pid,rss,args -p Vérifiez également le journal de Hop pour les avertissements de mémoire : grep -i "memory\|outofmemory\|GC" /opt/hop/logs/hop.log | tail -20 Les signaux de défaillance typiques incluent java.lang.OutOfMemoryError: Java heap space , de longues pauses de garbage collection dans les journaux GC verbeux, ou des étapes de pipeline bloquées à l'état RUNNING sans progression. Si aucun goulot d'étranglement n'est évident, commencez par les paramètres de tas JVM et de pool de threads, qui sont les limites de capacité les plus courantes. ## Chemin de configuration sûr Modifier la configuration de Hop nécessite de comprendre le rayon d'impact de chaque paramètre. Les ajustements suivants sont ordonnés du moins invasif au plus invasif. Chacun comprend une étape de retour en arrière. ### Dimensionnement du tas JVM L'ajustement de capacité le plus fréquent est l'augmentation du tas Java pour l'environnement d'exécution Hop. La valeur par défaut dans hop-config.sh est souvent de 1024 Mo, ce qui est trop petit pour les pipelines qui traitent des lots de plus de quelques milliers de lignes. Tout d'abord, trouvez le paramètre actuel : grep HOP_OPTIONS /opt/hop/hop-config.sh Exemple de sortie : HOP_OPTIONS="-Xmx2048m" Pour augmenter le tas pour une exécution locale, utilisez la variable d'environnement HOP_OPTIONS : export HOP_OPTIONS="-Xmx4096m -Xms2048m" /opt/hop/hop-run.sh -f /path/to/pipeline.hpl -r local Pour un serveur Hop (Carte), définissez les mêmes options dans son script de démarrage ou l'environnement du conteneur. Vérifiez le tas effectif après redémarrage : /opt/hop/hop-server.sh -s jcmd VM.flags | grep MaxHeapSize La sortie attendue inclut -XX:MaxHeapSize=4294967296 (4 Go). Retour en arrière : supprimez l'export HOP_OPTIONS ou revenez au fichier de démarrage. Une bonne règle de départ pour le dimensionnement du tas est 1 Go par 100 000 lignes de données de transformation en mémoire, plus 512 Mo de surcharge pour les éléments internes de Hop. Pour un pipeline qui traite 500 000 lignes par exécution, allouez au moins 5,5 Go de tas. Surveillez l'utilisation réelle avec jstat -gcutil 1000 pendant une exécution ; si l'ancienne génération atteint 80 % fréquemment, augmentez encore le tas. ### Configuration du pool de threads Hop utilise des pools de threads configurables pour l'exécution des pipelines et la communication à distance. Un sous-provisionnement des threads provoque une accumulation de files d'attente ; un surprovisionnement épuise la mémoire et le CPU. Vérifiez les valeurs par défaut dans hop-config.sh ou hop-server.xml : grep -A5 "thread" /opt/hop/config/hop-server.xml Recherchez des paramètres tels que HopServer.maxExecutionThreads (par défaut 20) et HopServer.maxResultRows . N'augmentez le nombre maximal de threads d'exécution que si le serveur dispose de CPU libre. Une règle sûre : définissez le nombre maximal de threads à 2 x le nombre de cœurs disponibles, plafonné à 50. Pour un serveur à 16 cœurs, définissez 32. Après modification, redémarrez Hop Server et vérifiez : curl -s http://:8080/hop/status | jq '.maxThreads' Retour en arrière : restaurez la valeur XML précédente et redémarrez. ### Impact de la journalisation et des métriques Une journalisation verbeuse peut consommer du disque et du CPU, réduisant indirectement la capacité de traitement des données. La journalisation Hop par défaut est INFO ; passez à DEBUG uniquement pendant le dépannage. Dans hop-log4j2.xml , modifiez le niveau du logger racine : Pour la surveillance de la capacité en production, activez les métriques Prometheus sur Hop Server en ajoutant ce qui suit à hop-server.xml : true 9091 Vérifiez ensuite que les métriques sont exposées : curl -s http://:9091/metrics | grep hop_pipeline La sortie attendue inclut hop_pipeline_running_total et hop_pipeline_error_total . Retour en arrière : définissez enabled sur false et redémarrez. ## Vérification et diagnostics Après avoir ajusté un paramètre de capacité, vérifiez que le pipeline s'exécute dans les limites de ressources attendues. Utilisez la surveillance intégrée de Hop et les outils externes du système d'exploitation. ### Profilage des ressources au niveau du pipeline Exécutez le pipeline avec une journalisation verbeuse et capturez l'utilisation des ressources. Pour les exécutions locales : time /opt/hop/hop-run.sh -f /path/to/pipeline.hpl -r local -level Detailed La sortie inclut les durées des étapes, les lignes par seconde et l'utilisation de la mémoire. Extrayez les métriques clés : grep "rows/sec\|step duration" /opt/hop/logs/hop.log | tail -20 Les noms de métriques attendus incluent InputRows , OutputRows , ElapsedTimeMs . Comparez-les à votre base de référence. Si une étape traite plus lentement que 50 % de la base, étudiez la taille de ses données d'entrée et l'activité du GC de la JVM. Pour l'exécution à distance, utilisez l'API du serveur Hop pour interroger l'état du pipeline : curl -s "http://:8080/hop/pipelineStatus?name=&id=" La réponse JSON montre les lignes et les erreurs par étape. Recherchez les étapes avec des tailles de tampon élevées (indiquant une contre-pression) ou des compteurs d'erreurs nuls. ### Diagnostiquer la pression mémoire Activez la journalisation verbeuse du garbage collection pour une exécution afin de diagnostiquer les problèmes de tas : export HOP_OPTIONS="-Xmx4096m -verbose:gc -Xlog:gc*:file=/tmp/hop-gc.log:time,uptime" /opt/hop/hop-run.sh -f /path/to/pipeline.hpl -r local Après l'exécution, vérifiez les longues pauses : grep "Pause" /tmp/hop-gc.log | awk '{print $NF}' | sort -n | tail -5 Si une pause dépasse 1 seconde, le tas est trop petit ou il y a une fuite de mémoire dans un plugin personnalisé. Augmentez le tas progressivement, mais ne dépassez pas 70 % de la RAM physique sur un hôte Hop dédié. ### Signaux de famine de threads Si les pipelines se bloquent avec des étapes à l'état RUNNING mais sans progression, vérifiez les pools de threads. Utilisez jstack sur le processus Hop en cours d'exécution : jstack > /tmp/hop-threads.txt grep -c "pool-.*-thread" /tmp/hop-threads.txt Comparez ce nombre au nombre maximal de threads configuré. Si tous les threads sont à l'état WAITING et que la file d'entrée est pleine, augmentez le nombre maximal de threads ou divisez le pipeline en morceaux plus petits. ## Modes de défaillance et récupération Les limites de capacité sont plus visibles lors des défaillances. Définissez les étapes de récupération avant qu'elles ne surviennent. Cette section couvre les scénarios courants de dépassement de capacité et comment rétablir le service sans perte de données. ### OutOfMemoryError dans une transformation Lorsqu'une étape de pipeline génère une OutOfMemoryError , le pipeline entier échoue et peut laisser des fichiers temporaires. Récupération : - Arrêtez le serveur Hop ou l'exécution locale. - Augmentez le tas comme décrit précédemment. - Réduisez la taille du lot de transformation. Dans les propriétés du pipeline, définissez TRANS_META_BATCH_SIZE à une valeur inférieure (par défaut 5000). Pour une étape de tri à haute cardinalité, réduisez à 1000. - Redémarrez et réexécutez le pipeline. Surveillez les journaux GC. Si l'erreur persiste, divisez la transformation en deux pipelines reliés par un fichier temporaire ou une table de transit. ### Débordement de file d'attente du serveur Carte distant Un serveur Carte peut manquer de threads ou de mémoire lorsque trop de pipelines sont soumis simultanément. Le serveur peut rejeter les nouvelles exécutions avec HTTP 503 ou devenir insensible. Récupération : - Videz la file d'attente : arrêtez de soumettre de nouveaux pipelines. - Vérifiez les exécutions actives : curl -s http://:8080/hop/status | jq '.runningPipelines' - Attendez que les pipelines en cours se terminent ou tuez les pipelines bloqués via l'API : curl -X POST "http://:8080/hop/stopPipeline?name=&id=" - Augmentez HopServer.maxExecutionThreads et redémarrez uniquement après que la file d'attente est vide. ### Épuisement de l'espace disque dû aux journaux et aux fichiers temporaires Hop écrit des journaux et des fichiers temporaires tels que des données triées dans le répertoire temporaire configuré. Un disque plein provoque des échecs de pipeline et peut corrompre les métadonnées. Récupération : - Vérifiez l'utilisation du disque : df -h /opt/hop /tmp - Faites pivoter les journaux manuellement et effacez les anciens fichiers temporaires : find /opt/hop/logs -name "*.log.20*" -mtime +30 -delete find /tmp/hop-* -type f -mtime +7 -delete - Configurez la rotation des journaux dans hop-log4j2.xml pour plafonner la taille totale (par exemple, 10 fichiers de 100 Mo chacun). - Déplacez le répertoire temporaire de Hop vers un volume plus grand si nécessaire en définissant java.io.tmpdir dans HOP_OPTIONS . ## Liste de contrôle opérationnelle Utilisez cette liste de contrôle pour toute tâche de planification de la capacité. Chaque élément nomme un propriétaire responsable (une seule personne, pas une équipe) et une cadence de révision. Dans un contexte de startup, le propriétaire est souvent le consultant DevOps ou le responsable de l'ingénierie. - Enregistrement de la base de référence de capacité - Propriétaire : Ingénieur DevOps (par exemple, Priya Shah). Enregistrez la version de Hop, le tas JVM, le nombre de threads et la base de débit pour vos cinq pipelines les plus importants. Révision : mensuelle ou chaque fois qu'un pipeline change de manière significative. - Simulation de charge de pointe - Propriétaire : Responsable des tests de performance (par exemple, Marcus Chen). Exécutez un test de charge avec 2 x le volume de données de production attendu. Vérifiez qu'il n'y a pas d'OutOfMemoryError, de famine de threads ou de débordement de file d'attente. Révision : avant chaque version majeure ou trimestriellement. - Vérification de la marge de ressources - Propriétaire : Propriétaire de l'infrastructure (par exemple, Anna Kowalski). Confirmez que le CPU, la mémoire et le disque sont au maximum à 70 % d'utilisation pendant les exécutions de pointe. Utilisez top , df et les métriques Hop. Révision : hebdomadaire en production. - Validation du tas JVM - Propriétaire : Développeur de pipeline (par exemple, David Okafor). Vérifiez les temps de pause GC à partir des journaux GC verbeux ; si une pause dépasse 1 seconde, ajustez le tas. Révision : après tout changement de logique de pipeline. - Rotation des journaux et des fichiers temporaires - Propriétaire : Administrateur système (par exemple, Luis Fernandez). Assurez-vous que les fichiers journaux sont plafonnés et que les répertoires temporaires sont nettoyés automatiquement. Révision : mensuelle. - Exercice de récupération - Propriétaire : Responsable de l'ingénierie (par exemple, Sarah Lindqvist). Simulez une défaillance de capacité dans un environnement de préproduction et exécutez les étapes de récupération de cet article. Révision : trimestrielle. Chaque élément de la liste de contrôle doit produire un artefact écrit : un rapport de base de référence, un résumé de test de charge, une capture d'écran du tableau de bord de capacité ou un rapport d'exercice. Ces artefacts sont la preuve que la planification de la capacité est opérationnelle, pas théorique. ## Pièges courants et comment les éviter La planification de la capacité avec Apache Hop comporte plusieurs erreurs récurrentes. Comprendre pourquoi elles se produisent aide à les prévenir. ### Surallocation du tas sur un hôte partagé Pourquoi cela arrive : les équipes supposent que plus de tas améliore toujours les performances, ignorant les limites de mémoire physique et les besoins des autres processus. Conséquence : le système d'exploitation utilise le swap ou tue des processus, y compris le serveur Hop, provoquant des défaillances imprévisibles. Évitement : définissez le tas à au plus 70 % de la RAM physique dédiée à Hop. Utilisez free -h pour voir la mémoire totale et jcmd VM.flags pour confirmer la taille du tas. Laissez de la marge pour le cache de pages du système d'exploitation et d'autres services. Récupération : si un serveur devient instable en raison d'une surallocation, réduisez le tas dans HOP_OPTIONS à la limite de 70 %, redémarrez et surveillez avec vmstat 1 pour le swapping. ### Ignorer la conception du pipeline lors de la mise à l'échelle verticale Pourquoi cela arrive : augmenter le CPU et la mémoire d'un serveur ne corrige pas un pipeline avec un goulot d'étranglement séquentiel inhérent, comme une étape de tri qui traite toutes les données en mémoire. Conséquence : un tas plus grand permet des tris plus importants, mais la mémoire finit par s'épuiser, et le pipeline échoue plus tard plutôt que plus tôt. Évitement : profilez le pipeline pour identifier les étapes à haute cardinalité. Utilisez le tri côté base de données ou le partitionnement au lieu du tri en mémoire de Hop pour les grands ensembles de données. Testez avec des volumes de données réalistes avant de faire évoluer l'infrastructure. Récupération : si une étape de tri échoue, réduisez la taille du lot, déplacez le tri vers la base de données ou divisez les données en partitions traitées en séquence. ### Se fier aux paramètres de threads par défaut pour les charges de production Pourquoi cela arrive : les valeurs de threads par défaut conviennent aux ordinateurs portables de développement, pas aux serveurs de production avec de nombreux pipelines simultanés. Conséquence : des threads sous-provisionnés font que les pipelines se mettent en file d'attente et expirent ; des threads surprovisionnés provoquent une contention CPU et un épuisement de la mémoire. Évitement : définissez le nombre de threads en fonction de l'utilisation mesurée du CPU et de la profondeur de la file d'attente. Commencez par 2 x le nombre de cœurs et ajustez après avoir observé les métriques HopServer pour la longueur de la file d'attente. Récupération : si les files d'attente dépassent constamment 10, augmentez les threads progressivement de 10 et retestez. Si la saturation du CPU dépasse 85 %, réduisez les threads. ### Ne pas tester les procédures de récupération avant un incident Pourquoi cela arrive : les étapes de récupération sont documentées mais jamais exercées ; lors d'une défaillance de capacité réelle, les opérateurs hésitent ou exécutent incorrectement les commandes. Conséquence : la durée d'indisponibilité s'allonge, des données peuvent être perdues et la confiance dans la plateforme diminue. Évitement : planifiez un exercice de récupération trimestriel dans un environnement de préproduction. Simulez une condition d'OutOfMemoryError ou de disque plein et demandez à l'ingénieur d'astreinte de suivre le plan de récupération écrit. Récupération : après tout incident de capacité non planifié, mettez à jour le manuel de récupération avec ce qui a réellement fonctionné et les nouveaux pièges découverts. ## Conclusion La planification de la capacité avec Apache Hop n'est pas un calcul ponctuel ; c'est une pratique opérationnelle continue. En suivant les sections sur l'inventaire de version, la configuration sûre, la vérification, les défaillances et la liste de contrôle de cet article, vous pouvez dimensionner votre environnement Hop pour répondre aux demandes réelles de charge de travail sans dépenses excessives. Commencez par l'étape la moins risquée : capturez une base de référence de capacité pour votre pipeline le plus important en utilisant les commandes de la section Inventaire de la version et de l'environnement. Enregistrez la taille du tas, le nombre de threads et le débit. Exécutez ensuite un test contrôlé avec 2 x le volume de données normal. Utilisez les métriques obtenues pour ajuster le tas et les threads en suivant le Chemin de configuration sûr. À mesure que vos pipelines se développent, révisez la Liste de contrôle opérationnelle mensuellement. Attribuez un propriétaire unique pour chaque élément et tenez ce propriétaire responsable de produire l'artefact écrit. La planification de la capacité ne fonctionne que si elle est appliquée comme une routine, pas si on s'en souvient pendant une crise. Un déploiement Hop fiable rend les défaillances visibles avant qu'elles n'affectent les utilisateurs, protège l'infrastructure contre la surallocation et définit des étapes de récupération testées, pas seulement documentées.