ETL/ELT et architectures de stockage

Après avoir suivi le cycle de vie des données, nous examinons les architectures qui permettent de les stocker et de les préparer pour l’analyse : les pipelines ETL/ELT, le data lake, le data warehouse et le lakehouse.

ETL ou ELT : quand transformer ?

Les données nécessaires à une analyse proviennent souvent de plusieurs systèmes : une base de commandes, des fichiers clients, une API ou des journaux d’activité. Ces sources utilisent des formats et des conventions différents. Pour les exploiter ensemble, il faut les extraire, les transformer et les charger dans un environnement d’analyse. ETL et ELT organisent ces opérations dans un ordre différent. Cet ordre détermine aussi où les traitements sont exécutés.

Les trois opérations remplissent des fonctions distinctes :

  • Extraire consiste à récupérer les données depuis leurs sources, par exemple en interrogeant une base ou en lisant un fichier.
  • Transformer consiste à les préparer : convertir des dates, harmoniser des unités, supprimer des doublons, rapprocher plusieurs sources ou calculer des indicateurs.
  • Charger consiste à écrire les données dans la destination retenue, par exemple les tables d’un entrepôt de données.

Avec l’ETL (extract, transform, load), les transformations précèdent le chargement dans la cible analytique. Les données extraites peuvent passer par une zone temporaire, appelée staging, où elles sont préparées avant leur transfert. L’entrepôt reçoit ainsi des données déjà adaptées au modèle attendu. Cette organisation permet notamment de filtrer des informations inutiles ou de masquer des données sensibles avant leur arrivée dans la destination. En revanche, la mise à disposition des résultats dépend de l’achèvement des traitements en amont.

ETL : Transformer avant de charger Les données sont extraites des sources vers un staging temporaire, transformées hors de l’entrepôt, puis chargées sous forme de tables analytiques pour la BI et le machine learning. ETL Transformer avant de charger ENTREPÔT DE DONNÉES Sources Bases, API, fichiers E Extraire Copier le brut Staging Copie temporaire HORS DE L’ENTREPÔT T Transformer Nettoyer, joindre, contrôler L Charger Données préparées Tables analytiques Données préparées Usages BI, indicateurs, ML
Figure 15. ETL : des sources aux usages analytiques.
La donnée est extraite vers un staging temporaire, puis transformée et contrôlée avant son chargement dans l’entrepôt.

Avec l’ELT (extract, load, transform), les données sont d’abord chargées dans la destination, sous une forme brute ou peu modifiée. Les transformations utilisent ensuite les ressources de calcul de cette plateforme, souvent au moyen de requêtes SQL. Cette approche s’appuie sur la capacité des plateformes cloud à stocker et à traiter de grands volumes. Charger plus tôt ne signifie toutefois pas que les données sont immédiatement prêtes pour l’analyse : les contrôles, les rapprochements et les calculs restent nécessaires.

ELT : Charger le brut, transformer ensuite Les données sont extraites des sources et chargées brutes dans l’entrepôt. La zone brute y est conservée ; les transformations SQL y produisent des tables analytiques pour la BI et le machine learning. ELT Charger le brut, transformer ensuite ENTREPÔT DE DONNÉES Sources Bases, API, fichiers E Extraire Copier le brut L Charger Données brutes Zone brute Brut conservé DANS L’ENTREPÔT T Transformer SQL : nettoyer, joindre, agréger Tables analytiques Données préparées Usages BI, indicateurs, ML
Figure 16. ELT : charger le brut, transformer ensuite.
Le brut est d’abord chargé et conservé dans l’entrepôt. Les transformations SQL y produisent ensuite les tables analytiques, par exemple dans BigQuery.

La conservation du brut permet de reprendre une transformation lorsqu’une règle change ou qu’une erreur est découverte, sans réextraire les données concernées si elles sont toujours disponibles. Plusieurs analyses peuvent également partir de la même copie. Cette souplesse demande une gestion des droits d’accès au brut et une surveillance des coûts de stockage et de calcul.

Prenons un exemple pédagogique : une enseigne souhaite calculer son chiffre d’affaires quotidien à partir des ventes de plusieurs magasins. Les fichiers contiennent des dates écrites différemment et certaines transactions apparaissent deux fois.

  • En ETL, un traitement harmonise les dates, élimine les doublons et calcule les totaux avant de charger le résultat dans l’entrepôt.
  • En ELT, les fichiers sont d’abord chargés dans des tables brutes. Des requêtes exécutées dans l’entrepôt effectuent ensuite le nettoyage et produisent les mêmes totaux.

Le choix dépend donc des contraintes du projet : transformations à effectuer avant l’arrivée dans la cible, ressources de calcul disponibles, besoin de conserver le brut et évolution des analyses. Une architecture peut combiner les deux approches, par exemple en retirant certaines informations avant le chargement, puis en réalisant les calculs métier dans l’entrepôt.

Data Lake, Data Warehouse ou lakehouse ?

Le choix porte sur la forme des données, les usages et les responsabilités ; de nombreuses équipes utilisent un lake et un warehouse ensemble.

Critère Data Lake Data Warehouse Lakehouse
Rôle Conserver des données variées Organiser l’analyse métier Partager les données entre SQL et ML
Organisation Fichiers et objets Tables et vues analytiques Fichiers gérés comme des tables
Données Brutes ou préparées, formats variés Principalement tabulaires Formats variés et tables analytiques
Schéma Souvent interprété à la lecture Défini pour les tables Contrôlé et évolutif pour les tables
Transactions Non fournies par les fichiers seuls Gérées par le moteur Apportées par la couche de tables
Usages Exploration, préparation, ML SQL, reporting, tableaux de bord SQL, traitements distribués, ML
Travail à prévoir Cataloguer et organiser les données Maintenir les modèles et indicateurs Gérer les tables, fichiers et moteurs

Lake et warehouse se complètent souvent : brut d’un côté, SQL analytique de l’autre.

Data lake

Un data lake centralise de grands volumes de données dans leur format d’origine afin de pouvoir les conserver et les réutiliser pour différents besoins.

  • Il accueille des données structurées, semi-structurées et non structurées : tables, CSV, JSON, journaux, documents, images ou vidéos.
  • Il repose généralement sur un stockage objet. La structure des données est souvent appliquée au moment de leur lecture (schema-on-read).
  • Le stockage et le calcul sont séparés : plusieurs moteurs peuvent traiter les mêmes fichiers selon les besoins.
  • Sur GCP, Cloud Storage fournit le stockage, tandis que BigQuery, Dataflow ou Dataproc peuvent assurer les traitements.
  • Il convient à l’exploration, au traitement de grands volumes et au machine learning. Sans catalogue, métadonnées et règles de gouvernance, il peut devenir difficile à exploiter.

Dans Cloud Storage, la température représente la fréquence à laquelle les données devraient être consultées. Plus les accès sont rares, plus le stockage est économique, mais des frais de lecture et une durée minimale de facturation peuvent s’appliquer.

Température Classe Cloud Storage Accès conseillé Durée minimale Exemple
Chaud Standard Fréquent Aucune Données récentes, tableaux de bord
Tiède Nearline Une fois par mois ou moins 30 jours Sauvegardes, données peu consultées
Froid Coldline Une fois par trimestre ou moins 90 jours Historique, journaux anciens
Archive Archive Moins d’une fois par an 365 jours Conservation légale, reprise après sinistre

Nearline, Coldline et Archive appliquent des frais de récupération. Une règle de cycle de vie peut changer automatiquement la classe selon l’âge des objets. Autoclass adapte la classe selon les accès observés.

La température décrit la fréquence d’accès et le modèle de coût. Toutes les classes, y compris Archive, restent accessibles en ligne sans restauration préalable.

Data warehouse

Un data warehouse centralise des données issues de plusieurs systèmes afin de fournir une vision cohérente et historique de l’activité.

  • Les données sont nettoyées, rapprochées et organisées en tables selon les besoins métier.
  • Le schéma est défini et contrôlé lors de l’écriture (schema-on-write), ce qui stabilise les types, les règles et les indicateurs.
  • Il est optimisé pour les traitements OLAP : agrégations, analyses historiques, reporting et tableaux de bord.
  • Il est alimenté par des pipelines ETL ou ELT et évite d’exécuter les analyses lourdes sur les bases transactionnelles.
  • Ses principaux utilisateurs sont les analystes, les équipes BI et les décideurs.

Sur GCP, BigQuery est un entrepôt analytique entièrement géré et serverless. Son stockage en colonnes est optimisé pour les requêtes analytiques, et ses ressources de stockage et de calcul évoluent séparément. Une table ou une partition non modifiée pendant 90 jours passe automatiquement au tarif de stockage longue durée, sans perte de performance.

Lakehouse

Un lakehouse conserve les données dans un stockage objet tout en les gérant comme des tables analytiques fiables.

  • Les données restent dans des formats de fichiers ouverts, comme Parquet, sur un stockage objet.
  • Un format de table comme Apache Iceberg ou Delta Lake ajoute les métadonnées nécessaires pour suivre le schéma, les fichiers et les différentes versions d’une table.
  • Cette couche peut apporter des transactions ACID, l’évolution du schéma, le time travel et l’optimisation des fichiers.
  • Plusieurs moteurs SQL, outils de traitement distribué et applications de machine learning peuvent exploiter les mêmes tables, selon les possibilités de la plateforme.
  • Cette architecture limite certaines copies entre lake et warehouse, mais elle exige toujours des pipelines, un catalogue, des contrôles de qualité et une gestion des droits.

Sur GCP, Lakehouse for Apache Iceberg, anciennement BigLake, associe Cloud Storage, le format de table Apache Iceberg et des moteurs comme BigQuery. Les données restent dans des buckets contrôlés par l’organisation et peuvent être interrogées sans être systématiquement déplacées.

NoteÀ retenir
  1. ETL = extraire, transformer, puis charger les données dans la cible, pour y faire entrer des données déjà contrôlées.
  2. ELT = extraire, charger, puis transformer les données dans la cible, en utilisant sa puissance de calcul.
  3. Data lake = stockage de données de formats variés, brutes ou préparées, généralement sur stockage objet, permettant notamment de conserver le brut pour le retraiter. Schema-on-read : structure appliquée à la lecture.
  4. Data warehouse = entrepôt de données organisées en tables, optimisé pour l’analyse métier et les tableaux de bord. Schema-on-write : structure définie avant ou pendant l’écriture.
  5. Lakehouse = architecture associant le stockage objet du lake à une gestion des tables avec transactions ACID et gestion du schéma, pour exploiter les mêmes données en SQL et en machine learning.