Migration ETL - de l'ETL legacy vers le SQL
Les plateformes ETL historiques implémentent principalement des filtres, jointures, agrégations, mappings et transformations qui peuvent être exprimés en SQL.
{openAudit} analyse les jobs ETL, reconstruit les flux et génère un équivalent SQL indépendant de la technologie source.
Point clé : les traitements sont reconstruits sous forme de SQL documenté et versionnable.
Analyse des traitements
Les référentiels ETL sont analysés pour reconstruire les sources, les cibles, les transformations, les paramètres et les dépendances entre traitements.
Les métadonnées collectées permettent de reconstituer le fonctionnement réel des flux.
Les composants inutilisés ou non consommés peuvent être identifiés avant migration.
Résultat : un périmètre de migration réduit aux traitements réellement utilisés.
Reconstruction des flux
Les chaînes de traitement sont reconstruites à partir des jobs ETL.
Les dépendances entre traitements, les flux intermédiaires, les variables et les paramètres sont intégrés dans le modèle cible.
Cette cartographie constitue le point d’entrée de la conversion.
Rationalisation
Le croisement du data lineage (jusqu’au champ) avec les usages réellement observés permet d’identifier les données effectivement consommées et d’écarter celles qui ne le sont pas.
Chaque job est également analysé pour en évaluer la complexité : nombre d’étapes, profondeur des sous-traitements, types de transformations et dépendances externes. Ces métriques sont agrégées en un score de complexité, utilisé pour prioriser et planifier la migration.
Résultat : un périmètre de migration réduit aux traitements réellement utilisés, priorisé selon leur complexité réelle.
Génération SQL
Les transformations détectées sont converties en SQL.
Filtres, jointures, agrégations, lookups, mappings et calculs sont traduits en instructions SQL successives, à plat.
Le SQL produit conserve le découpage logique des traitements d’origine.
Point clé : chaque étape du traitement reste identifiable dans le SQL généré.
Exemple : jobs IBM DataStage
Sur un patrimoine DataStage, chaque type de stage est traduit selon sa logique propre :
- Runtime Column Propagation (RCP) : la liste des colonnes n’est pas figée dans le job ; elle est générée dynamiquement dans le SQL, pilotée par les variables passées au job.
- Connecteurs Oracle (lecture / écriture) : SELECT, UPDATE, MERGE ou INSERT générés à partir des options du stage.
- Change Capture (CDC) : comparaison Before/After sur clés primaires, détection des lignes nouvelles, modifiées et supprimées.
- Transformer CDC : routage conditionnel vers un flux dédié selon le code de changement détecté.
- Shared Container : bloc logique factorisé, rendu comme un bloc SQL standardisé et réutilisé dans plusieurs jobs.
- Column Generator : colonnes calculées traduites en expressions SQL typées.
- Modify : conversions de types traduites en CAST SQL (ex. string vers timestamp).
- Funnel : fusion de plusieurs flux via UNION SQL, avec homogénéisation du schéma de sortie.
Résultat observé : sur un patrimoine de plusieurs centaines de jobs DataStage, plus de 95 % des traductions SQL aboutissent dès la première exécution.
Adaptation aux plateformes cibles
Le SQL généré peut être adapté aux dialectes des plateformes cibles.
Les fonctions, types de données et mécanismes spécifiques sont pris en compte lors de la génération.
Les mêmes traitements peuvent être produits pour Snowflake, BigQuery, Databricks SQL, Redshift, PostgreSQL, SQL Server ou d’autres moteurs compatibles SQL.
Orchestration
Les dépendances et l’ordonnancement des traitements sont conservés.
Les traitements générés peuvent être intégrés dans les outils d’orchestration déjà présents dans le Système d’Information.
Usage typique : intégration dans Airflow, Control-M ou tout autre ordonnanceur existant.
SQL comme format pivot
Le SQL devient la représentation commune des traitements.
Les transformations ne dépendent plus des composants propriétaires de la plateforme ETL d’origine.
Les traitements peuvent être versionnés, relus, testés et déployés indépendamment de la technologie source.
Point clé : la logique de transformation reste maîtrisée par l’entreprise et ne dépend plus d’un moteur ETL spécifique.
