Sortir d'Oracle Data Integrator (ou autre ELT), Migrer et casser durablement la complexité des flux.

 

Sortir d'Oracle Data Integrator (ou autre ELT),   Migrer et casser durablement la complexité des flux.   ODI (Oracle Data Integrator), et autres solutions ELT "legacy" génèrent automatiquement des requêtes SQL qui s'exécutent directement dans la base de données. On ne vous apprendra rien . Le moteur ELT génère de nouvelles subqueries imbriquées et des jointures au fur et à mesure que le système évolue. Les transformations finissent par être noyées au sein de blocs SQL gigantesques. Et les équipes n’y comprennent parfois plus grand-chose.   Par ailleurs, les anciens ELT sont fortement challengés par des projets de modernisation du SI dont la pierre angulaire est souvent un "move to Cloud". Les ELT Cloud-native qui utilisent les mêmes logiques que leurs "ancêtres" sont en pleine expansion : Matillion, DBT, Dataflow (Google) ou Glue (Amazon).... Ils sont associés à des bases de données Cloud surpuissantes comme Redshift, BigQuery ou encore Snowflake. Le combo est impressionnant d’efficacité !    Dans un contexte de migration, il s’agira de déplacer les transformations de la source vers la cible, en mettant en place en amont des mécaniques créant de la simplicité et de l’observabilité. Puis, deux logiques s'affronteront sur le mode d’exécution des flux dans la cible : Continuer à appuyer les transformations sur la base de données (mode ELT), pour mettre à profit la puissance du Data Warehouse cible. Ou externaliser l’exécution des jobs dans des conteneurs, pour un maximum de contrôle.   On vous explique ça. Essentialiser, migrer, décomplexifier les data pipelines   Uniquement les transformations essentielles   Les jobs et sous-jobs issus d’ODI (ou autre ELT legacy) seront analysés pour permettre d’identifier les sources, les cibles, les filtres et les différentes logiques de transformation. Le croisement des usages réels de l'information et du data lineage technique permettra d'écarter les transformations inutiles en amont de la migration (parfois plus de 50 % de l’ensemble). Ainsi, seules les transformations réellement utiles seront portées vers la cible.    Conversion en SQL   Une fois les transformations clés isolées, elles seront converties en requêtes SQL, étape par étape. Chaque requête correspondra à une phase distincte du traitement en source.   Casser la complexité   Cette approche en SQL étape par étape permettra de structurer les traitements en plusieurs niveaux pour éviter de générer des requêtes monolithiques complexes (comme dans la source). Le SQL imbriqué sera remis à plat, ce qui est capital pour la maintenabilité des flux. On pourra également utiliser des tables matérialisées ou des tables volatiles pour stocker des résultats intermédiaires. Cela permettra de mieux comprendre le parcours de la donnée. Nous créerons des points de contrôle explicites à chaque étape de transformation SQL (ce qui n’existe pas dans les ELT "legacy", comme ODI par exemple). Option #1 : Exécuter les transformations dans la DB cible, en mode ELT   Adaptation à la cible   Les transformations SQL seront directement intégrées dans des jobs de l’ELT Cloud-native. Le SQL généré pourra être ajusté pour s'adapter à la syntaxe cible. Option : ajout des jobs dans la configuration des projets, définition des dépendances entre jobs, etc. Tests des jobs pour vérifier leur fonctionnement et éventuellement tests des données pour garantir leur intégrité.   Avantages   Réduction de la latence grâce aux transformations au sein de la base de données.. Exploitation native des capacités de calcul du Data Warehouse cible. Option #2 : Exécuter les transformations dans des conteneurs, en mode ETL   Des conteneurs   On exécutera les transformations dans un conteneur externe, détaché de la base de données cible et de l’ELT cible.  Il servira de passerelle applicative préconfigurée, simple à monter, facilement duplicable, pour paralléliser certains pipelines si nécessaire. Des conteneurs temporaires serviront de zones de stockage intermédiaires où les données seront chargées avant transformation. Le volume du conteneur contenant la base de données tampon sera externalisé pour que les développeurs puissent y avoir accès.  Les jobs seront testés pour vérifier leur fonctionnement (et possiblement les données, pour garantir leur intégrité).   Avantages   Réduction de la charge sur la base de données cible : les jobs seront exécutés de manière parallèle avec une architecture "multi-threadée". Continuité de service assurée même en cas de traitements intensifs (traitements lourds ou opérations en batch). Flexibilité accrue pour l’exécution et l’orchestration des workflows. CONCLUSION   Dans un projet de migration vers le Cloud de pipelines gérés par des ELT legacy, l’optimisation et l’amélioration des transformations SQL est un enjeu clé pour garantir la performance et la maintenabilité du système cible. Ensuite, entre une exécution dans la base cible (ELT) et une externalisation dans des conteneurs (ETL), le choix dépendra des objectifs métier et des ambitions en matière de gouvernance. {openAudit}, notre logiciel, permettra d’automatiser l’ensemble de ces étapes pour maîtriser la migration (timing, prix) et exploiter pleinement les nouvelles capacités de solutions Cloud-native cible.