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.

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}.

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.