Passer de DataStage au SQL en mode ELT ou en mode ETL avec une base tampon conteneurisée

Passer de DataStage au SQL en mode ETL ou en mode ELT avec une base tampon conteneurisée

Certaines entreprises envisagent de quitter DataStage, le célèbre ETL d’IBM.

Les raisons sont parfois liées aux coûts de licence ou aux enjeux de maintenabilité des processus. Mais ce glissement répond surtout à un besoin de plus en plus pressant de performance et de scalabilité : les processus gérés par les ETL historiques (tels que DataStage) tendent à reculer au profit de traitements en simple SQL ou en quasi SQL dans des bases de données modernes (comme BigQuery, Snowflake, Redshift, etc.), ou via des processus ETL plus légers.

 

Il est possible d’automatiser la transition de DataStage vers du simple SQL ou du SQL enrichi, en mode ELT.

Cependant, des enjeux de lisibilité et d’efficacité de la base de données cible peuvent se poser. Ils peuvent être adressés par la parallélisation des processus sur un conteneur tiers, au sein de bases de données modernes, en mode ETL.

 

On vous explique ça. 

 

Étapes 1 :

Conversion des logiques de DataStage en SQL

{openAudit}, notre logiciel, va identifier les transformations, extractions et chargements utilisés dans les jobs DataStage en détectant les sources, les cibles, les filtres et les logiques de transformation.
{openAudit} convertira ensuite les transformations DataStage en requêtes SQL étape par étape ou en CTE (Common Table Expression).

Avoir une étape SQL par Stage permet d'avoir de vrais points de contrôle qui n'existent pas dans DataStage. 

L’ensemble du SQL sera ensuite adapté pour se conformer aux spécificités de la base de données cible.
Ces requêtes SQL simplifiées remplaceront les composants graphiques de DataStage. {openAudit} peut d'ailleurs présenter un graphe avec toutes les dépendances, Stage par Stage et / ou job par job. 

 

Étapes 2 : 

Conversion de l'ETL DataStage vers des logiques ETL en base tampon conteneurisée

Dans ce cadre là, {openAudit} va déporter les tâches de transformation vers un conteneur tiers, détaché de la base de données cible, selon les logiques ETL.

Cette approche permettra d’éviter une surcharge de la base de données cible afin de garantir une continuité de service, surtout lors de traitements lourds ou d’opérations en batch.

Des conteneurs tampons :

Les conteneurs temporaires serviront de zones de stockage intermédiaires où les données seront chargées avant transformation.

Cette méthode permettra de réduire les interactions avec la base de données cible et d'alléger les processus. Cette structure est modulable, ce qui offre une grande souplesse pour la maintenance, le déploiement et les mises à jour des jobs DataStage traduits en SQL.

Une parallélisation des tâches : 

Les jobs seront exécutés de manière parallèle avec une architecture « multi-threadée ».

Cette parallélisation permettra de réduire fortement les temps de traitement.

 

Autre option : 

Conversion des logiques ETL de DataStage vers des logiques ELT

Dans ce cadre là, l’approche utilisée par {openAudit} sera d'optimiser et de stabiliser les requêtes SQL qui effectueront les transformations au sein de la base de données cible.

Le premier intérêt sera de pouvoir exploiter les capacités de traitement parallèle et d’optimisation de la base de données cible.

Le deuxième intérêt sera que la centralisation des processus dans un environnement en SQL unifié permettra de faciliter la gestion des transformations.  

 

CONCLUSION 

La modernisation des processus ETL, en migrant de DataStage vers des traitements SQL en mode ELT ou ETL, apparaît comme opportune pour toute entreprise cherchant à optimiser ses performances et la scalabilité de son Système d'Information.

En adoptant une approche ELT ou en déportant les transformations sur des conteneurs tiers (ETL), il devient possible de tirer le meilleur parti des capacités de traitement avancées des bases de données modernes comme BigQuery ou Snowflake.

Grâce à des solutions comme {openAudit}, cette transition est non seulement automatisée, mais aussi lisible et efficace, tout en réduisant massivement les coûts liés à cette modernisation.

 

 

Commentaires

Posts les plus consultés de ce blog

Migrer de SAP BO vers Power BI, Automatiquement, Au forfait !

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque