Middlewares — {oa.tbx} et {oa-lake} |

Migration ETL - de l'ETL legacy vers un ETL SQL ouvert - {oa.tbx}

Thu, 02 Jul 2026 00:00:00 +0000

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.

Migration DataViz - une couche d’interopérabilité SQL amont-aval - {oa-lake}

Fri, 03 Jul 2026 00:00:00 +0000

Les plateformes décisionnelles reposent souvent sur plusieurs bases de données, plusieurs data warehouses / data lakes et plusieurs outils de restitution.

{oa-lake} introduit une couche SQL intermédiaire entre les sources de données et les outils de datavisualisation.

Les règles de gestion, objets métier, dimensions, mesures et calculs sont centralisés dans cette couche puis exposés aux outils consommateurs.

Point clé : les sources de données et les outils de restitution deviennent indépendants les uns des autres.

Architecture

{oa-lake} se connecte simultanément à plusieurs systèmes de données : bases relationnelles, data warehouses, lakehouses, fichiers ou APIs.

Les requêtes sont fédérées par un moteur SQL distribué qui exécute les jointures, calculs et transformations nécessaires.

Le SQL produit reste standard et exécutable sur différents moteurs, ce qui limite le lock-in technologique.

Les objets métier sont définis une seule fois puis exposés aux outils consommateurs.

Sources de données

Les données restent dans leurs systèmes d’origine.

Oracle, SQL Server, PostgreSQL, DB2, BigQuery, Snowflake, Redshift, Azure SQL (et autres) ou des fichiers peuvent être interrogés dans une même requête.

Le mécanisme de Push-Down SQL évite toute copie systématique des données : les requêtes s’exécutent directement sur les systèmes existants, dans le respect des architectures en place.

Usage typique : construire un dashboard à partir de données réparties sur plusieurs plateformes sans migration préalable.

Couche métier SQL

Les dimensions, mesures, hiérarchies et règles de calcul sont centralisées dans {oa-lake}.

Cette couche devient le point d’entrée unique pour les outils de restitution.

Les règles de gestion ne sont plus dupliquées dans chaque plateforme de datavisualisation.

Point clé : une seule définition des indicateurs pour l’ensemble du système décisionnel.

Cache Parquet

Les données peuvent être matérialisées au format Parquet.

Cette couche de cache réduit les temps de réponse et limite les sollicitations des systèmes sources. Elle est gérée automatiquement selon les usages observés, sans intervention manuelle.

Usage typique : accélérer les traitements analytiques les plus coûteux.

Data visualisation

Les outils de restitution se connectent au modèle exposé par {oa-lake}.

Power BI, Looker, Spotfire, Tableau, Qlik, SAP BusinessObjects ou tout outil compatible SQL peuvent exploiter les mêmes objets métier.

Les changements d’outils de data visualisation n’impliquent plus de reconstruire les dimensions, mesures et règles de calcul.

Migration progressive

Plusieurs outils peuvent coexister pendant une phase de transition.

Un même modèle métier peut être exposé simultanément vers plusieurs plateformes de restitution.

Résultat : migration progressive des usages sans modification des systèmes de données.

Data Lineage

Le data lineage reconstruit par {openAudit} reste disponible sur l’ensemble de la chaîne.

Les dépendances sont documentées depuis les systèmes sources jusqu’aux indicateurs exposés dans les dashboards.

Point clé : les transformations, calculs et usages restent traçables sur l’ensemble de l’architecture.

Migration DataViz - une couche sémantique interopérable - {oa-lake-ctx}

Thu, 02 Jul 2026 00:00:00 +0000

Les plateformes décisionnelles historiques reposaient généralement sur une couche sémantique permettant aux utilisateurs de manipuler des objets métier plutôt que des tables ou des requêtes SQL.

“Clients”, “contrats”, “produits” ou “chiffre d’affaires” étaient exposés sous une forme fonctionnelle indépendante des structures physiques de stockage.

Pour répondre à ce besoin, nous avons conçu {oa-lake-ctx}.

{oa-lake-ctx} constitue la couche sémantique de l’architecture {oa-lake}. Elle centralise les objets métier, les dimensions, les mesures, les KPIs, les règles de calcul et les mécanismes de sécurité.

Point clé : les outils consommateurs manipulent des objets métier. Les structures physiques restent masquées.

Architecture

{oa-lake-ctx} centralise les dimensions, mesures, hiérarchies, KPI et règles de calcul.

Ces composants sont définis une seule fois puis exposés aux outils consommateurs.

Contrairement à certaines couches sémantiques du marché, {oa-lake-ctx} ne nécessite ni modèle physique spécifique, ni table pivot, ni chemin de navigation imposé.

Les relations sont calculées dynamiquement à partir du modèle existant.

Point clé : un modèle métier unique pour toutes les données et tous les outils consommateurs.

Sources de données

{oa-lake-ctx} peut exploiter simultanément plusieurs systèmes de données.

Les données peuvent provenir de bases Oracle, SQL Server, PostgreSQL, DB2, Snowflake, BigQuery, Redshift, fichiers ou autres sources compatibles SQL.

Les objets métier peuvent combiner plusieurs sources dans une même définition fonctionnelle.

Usage typique : construire un KPI à partir de données réparties sur plusieurs plateformes.

Objets métier

Les catalogues exposés par {oa-lake-ctx} regroupent les dimensions, mesures, KPI, hiérarchies et nomenclatures métier.

Les relations entre objets sont définies dans la couche sémantique et non dans les outils de restitution.

Les catalogues peuvent être organisés indépendamment des structures physiques des bases de données.

Génération SQL

Les requêtes SQL sont générées dynamiquement à partir des objets métier, dimensions, mesures et filtres sélectionnés.

Les jointures, agrégations et règles de calcul sont appliquées par le moteur.

Les filtres utilisateurs sont propagés jusqu’aux systèmes sources via le mécanisme de Push-Down SQL : pas de copie systématique des données, les requêtes sont exécutées sur les systèmes existants, dans le respect des architectures en place.

Le SQL généré peut être exécuté par {oa-lake} ou par tout moteur SQL compatible.

Point clé : les utilisateurs manipulent des objets métier ; le SQL est généré automatiquement.

Smart Cache

Les données restent dans les systèmes sources lorsque cela est possible.

Les jeux de données les plus sollicités peuvent être matérialisés au format Parquet.

Le cache est piloté par le Cache Manager de {oa-lake}, géré automatiquement selon les usages observés.

La gestion du cache reste indépendante des outils consommateurs.

Point clé : les requêtes les plus coûteuses peuvent être accélérées sans modifier les systèmes sources.

SQL Engine

{oa-lake} s’appuie sur un moteur SQL columnar et in-memory.

Les requêtes générées par {oa-lake-ctx} sont exécutées par ce moteur ou propagées vers les systèmes sources selon le contexte.

Le SQL reste portable, standard et exécutable sur différents moteurs, indépendant des technologies de stockage utilisées — ce qui limite le lock-in technologique.

Point clé : le moteur SQL constitue la couche d’exécution de l’architecture.

Sécurité

La sécurité est gérée au niveau de la couche sémantique.

Les restrictions d’accès, profils utilisateurs, catalogues métier et filtres de sécurité sont appliqués avant génération des requêtes.

Cette approche permet de reproduire les mécanismes de sécurité rencontrés dans des plateformes telles que SAP BusinessObjects ou IBM Cognos.

Point clé : les règles de sécurité sont définies une seule fois puis appliquées à tous les outils connectés.

Restitution

Les catalogues exposés par {oa-lake-ctx} peuvent être consommés par tout outil capable d’interroger une source PostgreSQL.

Power BI, Looker, Spotfire, Tableau, Qlik ou d’autres plateformes accèdent aux mêmes objets métier, dimensions, mesures et KPI.

Les définitions fonctionnelles restent identiques quel que soit l’outil utilisé.

Résultat : plusieurs plateformes peuvent partager le même catalogue métier sans duplication des règles de calcul.

Gouvernance

Les objets métier, KPI, dimensions, mesures et règles de calcul sont centralisés dans un référentiel unique.

Les évolutions fonctionnelles sont réalisées dans {oa-lake-ctx} puis immédiatement disponibles pour les outils connectés.

Point clé : {oa-lake-ctx} constitue le point central de définition des objets métier et des KPI.