ETL/ELT et architectures de stockage

Deux décisions structurent la donnée après sa génération : quand la transformer, et où la stocker.

  1. Quand transformer ? (ETL ou ELT)
  2. Où stocker ? (Data Lake, Data Warehouse, lakehouse)

ETL ou ELT : quand transformer ?

L’ETL (extract, transform, load) transforme la donnée avant de l’écrire dans la cible analytique. L’ELT (extract, load, transform) charge d’abord la donnée brute ou faiblement transformée, puis exploite la capacité de calcul de la destination.

ETL transforme avant le chargement ; ELT transforme après le chargement. Dans les plateformes cloud analytiques, l’ELT est fréquent, sans avoir supprimé l’ETL.

Figure 16. ETL : des sources aux usages analytiques.
La donnée est extraite, déposée en staging, transformée et contrôlée avant son chargement dans les tables du data warehouse.
Figure 17. ELT : charger le brut, transformer ensuite.
Le brut est d’abord chargé dans la cible, puis transformé dans BigQuery pour produire les tables analytiques.

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
Données brut, tout format structuré, nettoyé tout format
Schéma schema-on-read schema-on-write schéma + ACID
Coût stockage objet + compute stockage + compute SQL objet + couche table
Requêtes ad hoc, ML, variable SQL OLAP optimisé SQL et ML
Pour qui ingénieurs, data scientists analytics, BI BI et ML
GCP Cloud Storage BigQuery Lakehouse, Iceberg
Limite un désordre sans pilotage modèle à gouverner complexité supplémentaire

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

Data lake

  • Infrastructure de stockage centralisée et scalable, conçue pour ingérer, conserver et servir des données de toute nature : structurées, semi-structurées, non structurées, dans leur format natif.
  • Stockage objet. Modèle schema-on-read : la structure est appliquée à la lecture, pas à l’ingestion. Le Go est bon marché, mais le tarif n’est pas unique : il suit la température.
  • Les moteurs de calcul sont distincts du stockage objet. Sur GCP, Dataflow ou BigQuery peuvent lire Cloud Storage ; aucun de ces moteurs « n’est » le lake.
  • Sur GCP, Cloud Storage fournit le socle objet d’un data lake, pas à lui seul toutes ses fonctions de catalogue et de gouvernance.
  • Public typique : data engineers, data scientists, ML. Risque : désordre sans nommage ni catalogue.

On range les objets par fréquence de lecture attendue : chauds, tièdes, froids, archive. Plus on refroidit, moins le Go au repos coûte, plus la relecture et la durée minimale de conservation coûtent. Une règle de cycle de vie (lifecycle) peut déplacer les objets selon leur âge ; Autoclass peut le faire selon les accès observés.

Critère Chaud (hot) Tiède (warm) Froid (cold) Archive
Lecture souvent (jour, semaine) ~ 1 fois / mois ~ 1 fois / trimestre < 1 fois / an
Cloud Storage Standard Nearline Coldline Archive
Durée mini aucune 30 jours 90 jours 365 jours
Relecture incluse facturée facturée facturée
Coût relatif stockage élevé, accès inclus stockage plus bas, relecture payante stockage bas, relecture payante stockage minimal, relecture payante
Exemple plays du jour, Gold BI brut encore rejoué logs d’audit N-1 rétention légale

Température = fréquence d’accès. Médaillon = confiance. L’Archive GCS reste en ligne.

Data warehouse

  • Système de stockage et d’analyse pour structurer, agréger et interroger des volumes déjà nettoyés et modélisés, au service des décisions métier.
  • schema-on-write : tables, colonnes, types et contraintes sont définis avant ou pendant le chargement. Une ligne non conforme peut être rejetée, mise en quarantaine ou adaptée selon le système.
  • Le coût combine stockage et compute, ou volume interrogé selon le modèle de facturation. Les données viennent souvent du data lake, après nettoyage et transformation.
  • Optimisé OLAP. Public typique : analytics, BI.
  • Sur GCP : BigQuery, moteur analytique serverless. Le découplage stockage / calcul existe aussi ici : ce n’est pas un critère qui distingue le lake. Après 90 jours sans modification, le stockage logique actif devient du stockage longue durée selon le barème BigQuery : même idée de température, autre tarification (documentation de tarification).

Lakehouse

  • Même stockage objet que le lake, plus une couche table (Delta Lake, Apache Iceberg) : transactions ACID, évolution de schéma et accès par plusieurs moteurs. Cette architecture peut réduire certaines copies, sans garantir la disparition du warehouse.
  • Sur GCP, Lakehouse for Apache Iceberg, anciennement BigLake, illustre cette couche ouverte. Cloud Storage et BigQuery suffisent souvent ; le lakehouse ajoute une couche table, pas une obligation.
  • La technologie ne suffit pas à éviter le désordre : il faut aussi une discipline de nommage, de catalogue, de lignage et de droits d’accès.
NoteÀ retenir
  • ETL ou ELT ? ETL transforme les données avant de les charger. ELT les charge d’abord, puis les transforme. Le choix dépend des ressources, des contraintes et de la qualité attendue.
  • Data lake. Il stocke des données brutes de formats variés : CSV, Parquet, PDF, images ou logs. Le schéma est défini au moment de la lecture.
  • Data warehouse. Il stocke des données propres et organisées dans des tables. Le schéma est défini avant le chargement. BigQuery est un exemple.
  • Lakehouse. Il combine le stockage souple du data lake avec des tables mieux organisées.
  • Température et médaillon. La température indique la fréquence d’accès aux données. Le médaillon indique leur niveau de préparation. Ce sont deux notions différentes.