Migration de jobs ETL legacy vers PySpark, assistée par un agent

Problème

Un outil ETL legacy et les flux d’un référentiel de données (MDM) doivent passer en PySpark dans le cloud. Personne n’avait de cartographie complète des jobs qui alimentent chaque table, et les rapports en aval ne doivent pas changer.

Données

Les définitions de jobs exportées, les vues et procédures de la base, le catalogue des tables, et des copies figées des entrées et sorties d’aujourd’hui. L’agent travaille uniquement sur ces copies, jamais sur les systèmes réels.

Approche

• Les jobs et les flux sont analysés pour reconstruire le lineage entre jobs et tables, qui donne le plan de migration et l’ordre d’exécution.
• Du code classique lit chaque composant d’un job et écrit un squelette PySpark dans le même ordre, avec les mêmes noms. Chaque partie qui demande une décision est marquée.
• Un agent ne remplit que ces parties. Il n’invente jamais de colonne ni de règle métier, garde le comportement actuel même quand il semble faux et le signale, et s’arrête pour demander à une personne quand une règle est ambiguë. Chaque décision est journalisée avec le job.
• La première phase est une reconstruction un pour un, pour pouvoir comparer chaque job à celui d’aujourd’hui. La simplification des jobs vient ensuite.

Évaluation

Chaque job migré tourne sur les mêmes entrées qu’aujourd’hui, et ses sorties sont comparées en trois temps : les colonnes, le nombre de lignes, puis les lignes entières, sans clé nécessaire. Une procédure qui réécrit sa propre table est vérifiée à partir d’un snapshot pris avant son exécution.

Résultat

Plus de mille jobs legacy ont été inventoriés et leur lineage reconstruit, ce qui donne au client une cartographie de ses jobs et de ses tables qui n’existait pas auparavant. La méthode se transpose à un autre outil source : seuls le lecteur de jobs et les skills de l’agent changent.

Mon rôle

Tech lead avec deux développeurs : roadmap, méthodes de lineage et d’acceptation, et règles de travail de l’agent.