01 · Alten · banque
Industrialiser des pipelines à grande échelle
Faire passer des traitements PySpark d'un environnement de développement à une exécution quotidienne fiable sur Hadoop/Hive.
- Alignement des environnements entre instances de design et d'automation
- Structuration des flows PySpark pour tenir les volumes réels
- Séquence de déploiement écrite, avec retour arrière possible
À mon arrivée, une partie des traitements tournait correctement en développement mais n'avait jamais franchi l'étape de la production. Le code fonctionnait ; c'est le passage à l'échelle et le processus de déploiement qui bloquaient.
Ce qui coinçait
D'abord des volumes bien supérieurs en production, qui faisaient exploser des temps de traitement acceptables sur un échantillon. Ensuite un écart de configuration entre instances : des connexions nommées différemment, des environnements de code absents côté automation.
Ce second point est le plus sous-estimé. Un bundle Dataiku transporte la définition d'un projet, pas son environnement d'exécution. Un projet parfaitement fonctionnel en design échoue au premier run simplement parce qu'une connexion ne porte pas le même nom.
Ce que j'ai mis en place
J'ai commencé par aligner les environnements avant de toucher aux traitements : convention de nommage identique sur toutes les instances, environnements de code créés et validés en amont. Peu gratifiant, mais ça supprime la majorité des échecs de déploiement.
Côté traitements, le travail a porté sur la structuration des flows PySpark : réduire les volumes le plus tôt possible, éviter les recalculs, et déporter en SQL ce qui n'a pas besoin de remonter dans Spark.
- 1. Préparer
- connexions, environnements de code et plugins côté cible
- 2. Bundler
- version identifiable, contenu explicite
- 3. Importer
- sans activer les déclencheurs
- 4. Exécuter
- un run manuel complet, vérifié de bout en bout
- 5. Contrôler
- volumétrie et durée comparées à l'instance de design
- 6. Activer
- déclencheurs et supervision
- 7. Conserver
- la version précédente, pour revenir en arrière
L'étape 4 est celle qu'on saute quand on est pressé, et c'est précisément celle qui révèle les problèmes de configuration. Quelques minutes de run manuel évitent de découvrir l'incident à six heures du matin.
Ce que ça a changé
Les traitements tournent sur les volumes réels, avec un processus de déploiement écrit que l'équipe peut suivre. Et la question « comment revenir en arrière si ça se passe mal » a désormais une réponse.