Optimiser et fiabiliser les scénarios d'exécution

Sur une plateforme où plusieurs dizaines de scénarios se déclenchent chaque nuit, la durée totale de la fenêtre devient une contrainte réelle. Quand la chaîne déborde, les données ne sont pas prêtes à l'ouverture et tout le monde le voit.

Deux problèmes qu'on confond

On parle d'« optimisation » comme d'un sujet unique. En pratique j'ai rencontré deux problèmes distincts, qui appellent des réponses opposées.

Le premier est un problème de traitement : une recipe est lente parce qu'elle travaille sur trop de données ou recalcule ce qui pourrait être réutilisé. Le gain vient du filtrage précoce, du partitionnement, ou du fait de pousser une jointure en base.

Le second est un problème d'ordonnancement : le traitement est correct, mais il se lance alors que rien n'a changé en amont. Là, optimiser le code ne sert à rien. C'est le déclencheur qu'il faut revoir.

Ce sur quoi j'ai travaillé

• Repositionner les filtres en amont, pour ne pas faire travailler six étapes sur des données écartées à la septième.
• Conditionner certains scénarios à l'arrivée effective de nouvelles données plutôt qu'à un simple horaire.
• Découper les scénarios monolithiques, pour qu'un échec sur une branche ne condamne pas l'ensemble.
• Suivre les durées d'exécution dans le temps via l'API Dataiku, pour repérer les traitements qui se dégradent.

Ce dernier point rend le travail durable. Une optimisation ponctuelle se perd : les volumes augmentent, quelqu'un ajoute une étape, et six mois plus tard on est revenu au point de départ.

Avant d'optimiser une chaîne, il faut savoir où le volume est réduit. C'est presque toujours là que se trouve le vrai gain, et rarement là qu'on regarde en premier.