Migration ETL - de l'ETL legacy vers un ETL SQL ouvert - {oa.tbx}
Une fois les traitements ETL convertis en SQL par {openAudit}, ils peuvent être exécutés dans le conteneur {oa.tbx}.
{oa.tbx} fournit un environnement d’exécution pour des traitements SQL, Python ou Java, pilotés par des référentiels de configuration et d’orchestration.
Point clé : les traitements migrés deviennent des instructions SQL exécutables indépendamment de la plateforme ETL d’origine.
Principes
L’encapsulation du SQL se fait dans des conteneurs ouverts, en mode ETL.
- Des conteneurs : les transformations s’exécutent dans un conteneur externe, {oa.tbx}, détaché de la base de données cible. Les conteneurs temporaires servent de zones de stockage intermédiaires où les données sont chargées avant transformation. Les jobs sont testés pour vérifier leur fonctionnement, et possiblement les données, pour garantir leur intégrité.
- Orchestration avec Airflow : Airflow pilote l’exécution des conteneurs, étape par étape. Chaque transformation, au sein d’un conteneur, est définie comme un job.
Le scheduling d’un ETL migré vers Airflow reprend automatiquement l’ensemble des instructions et de l’ordonnancement d’origine.
Chaîne d’exécution
Les jobs ETL sont convertis en SQL par {openAudit}.
Les traitements produits sont intégrés dans un référentiel de configuration et un référentiel de pilotage utilisés par {oa.tbx}.
Les workflows sont ensuite orchestrés par des outils tels qu’Airflow ou Dagster.
Conteneur d’exécution
{oa.tbx} exécute les traitements décrits dans les workflows.
Les dataflows peuvent combiner :
- SQL ;
- Python ;
- Java ;
- autres.
Le moteur peut également s’appuyer sur des bases embarquées telles que DuckDB pour certains traitements intermédiaires.
Sources et cibles
Les données d’entrée peuvent provenir de n’importe quelle technologie accessible en SQL ou JDBC.
Les résultats peuvent être chargés vers tout système cible compatible avec les mécanismes d’écriture standards.
L’architecture reste indépendante des technologies source et cible.
Orchestration
L’orchestration reste séparée des traitements.
Les dépendances, paramètres d’exécution, planifications et déclenchements sont gérés par la couche workflow.
Les traitements métier restent contenus dans les scripts SQL et les dataflows exécutés par {oa.tbx}.
Bénéfices
{oa.tbx} exécute des pipelines SQL ouverts, orchestrés par Airflow et indépendants des runtimes propriétaires des plateformes Cloud.
Sur l’ensemble des jobs migrés — des volumes allant de quelques milliers à plus de 50 millions de lignes — les temps d’exécution se comptent souvent en quelques secondes seulement, avec un statut OK quasi systématique.
Gouvernance et data lineage
Une fois les traitements ETL convertis en SQL, {oa.tbx} conserve la trace complète entre la logique d’origine et le SQL exécuté. Ce data lineage est exposé à deux niveaux de lecture, adaptés à des besoins différents.
Point clé : une vue synthétique pour la gouvernance, un détail exhaustif pour la maintenance.
Vue high level du pipeline : seules les tables source et cible sont visibles ; les stages ETL intermédiaires sont regroupés en un bloc SQL unique. Une vue lisible, même sur des pipelines complexes.
Détail au clic sur une transformation : au clic sur un stage (par exemple un Transformer), son équivalent SQL généré s’affiche, avec ses inputs/outputs et ses métadonnées d’origine (type, stage ID). Le mapping est immédiat entre la logique ETL d’origine et le SQL exécuté.
Résultat : une gouvernance complète du pipeline migré, de la vue d’ensemble jusqu’au SQL exécuté, quelle que soit la plateforme ETL d’origine.
SQL comme format pivot
Le SQL produit par {openAudit} devient le support principal des transformations.
Les règles métier, jointures, agrégations et calculs sont exprimés dans un format ouvert, versionnable et indépendant des outils ETL historiques.
Résultat : une chaîne ETL/ELT basée sur SQL, orchestrée par workflows et exécutée dans un environnement ouvert.
