Lakehouse en pratique

L’architecture de données a longtemps été schizophrène : d’un côté le data lake, peu coûteux et flexible pour la data science, de l’autre le data warehouse, structuré et performant pour la BI. Cette dualité crée des silos, des copies de données coûteuses et une complexité inutile. Le lakehouse est une approche pragmatique qui cherche à unifier ces deux mondes : il apporte la fiabilité et les performances du warehouse directement sur le stockage ouvert et économique du data lake.

de la complexité à la simplicité

L’architecture lakehouse vise à éliminer la redondance en créant une source de vérité unique pour tous les cas d’usage.

prérequis

Un stockage objet fiable et peu coûteux (AWS S3, Google Cloud Storage, etc.).
Un moteur de tables ACID qui fonctionne sur ce stockage (Delta Lake, Apache Iceberg, Apache Hudi).
Un catalogue de données pour gérer les schémas et les permissions par rôle.

idées clefs

Le lakehouse repose sur une architecture en couches, souvent appelée “medallion architecture”, qui organise la donnée de la source brute à la consommation finale.

pas à pas

étape 1: structurer les zones

La première étape est de créer une structure de répertoires claire sur votre data lake pour matérialiser les zones.

/bronze/: Contient les données brutes, non modifiées, telles qu’elles arrivent des systèmes sources. C’est votre copie de sauvegarde immuable.
/silver/: Contient une version nettoyée, dédoublonnée et enrichie des données brutes. Les types de données sont corrigés et la structure est cohérente.
/gold/: Contient les tables agrégées, prêtes pour l’analyse. Ce sont des vues “business-ready” qui alimentent les dashboards et les modèles de ML.

étape 2: fiabiliser les tables avec des transactions acid

Les formats comme Delta Lake ou Iceberg apportent les transactions ACID au data lake. Vous pouvez maintenant faire des MERGE, UPDATE et DELETE de manière fiable, ce qui était impossible sur un data lake classique.

-- Exemple d'une opération MERGE pour mettre à jour la table silver des clients
-- C'est la même syntaxe que dans un data warehouse traditionnel.
MERGE INTO silver.customers AS target
USING staging.new_customers AS source
ON target.customer_id = source.customer_id
WHEN MATCHED THEN
  UPDATE SET
    target.last_updated = source.event_timestamp,
    target.email = source.email
WHEN NOT MATCHED THEN
  INSERT (customer_id, first_seen, email)
  VALUES (source.customer_id, source.event_timestamp, source.email);

étape 3: exposer des vues stables pour la consommation

La zone “gold” est la vitrine de votre lakehouse. Elle expose des vues stables et bien documentées aux utilisateurs finaux, qui n’ont pas à se soucier de la complexité des zones “bronze” et “silver”.

-- Création d'une vue gold pour le reporting des ventes
CREATE OR REPLACE VIEW gold.daily_sales_per_country_v AS
SELECT
    o.order_date,
    c.country,
    SUM(o.amount_eur) AS total_sales_eur
FROM
    silver.orders o
JOIN
    silver.customers c ON o.customer_id = c.customer_id
GROUP BY 1, 2;

pièges frequents

Symptôme: Les analystes créent des copies de données dans tous les sens car ils ne font pas confiance à la source principale.
- Cause: Pas de source de vérité unique et gouvernée.
- Correctif: La zone “gold” est la seule source de vérité pour la BI. Tout le reste est considéré comme du travail en cours.
Symptôme: Un changement de schéma dans une table source casse des dizaines de pipelines en aval.
- Cause: Schémas trop rigides et pas de gestion des évolutions.
- Correctif: Utiliser les fonctionnalités d’évolution de schéma des formats de table modernes (ex: schema evolution dans Delta Lake) pour permettre d’ajouter des colonnes sans casser les lectures existantes.
Symptôme: Les règles d’accès sont complexes à gérer et potentiellement sources de fuites.
- Cause: Pas de gestion centralisée des permissions.
- Correctif: Utiliser un catalogue central (ex: Unity Catalog, AWS Glue) pour définir les permissions par rôle (RBAC) et au niveau des lignes (RLS) directement sur les tables du lakehouse.

faq

Quelle est la différence entre un data lake et un lakehouse ? Un data lake est juste un système de stockage de fichiers. Un lakehouse y ajoute une couche de gestion transactionnelle (ACID) et de gouvernance (catalogue), ce qui lui donne les fonctionnalités d’un data warehouse tout en gardant la flexibilité et le faible coût du data lake.
Quels outils permettent de construire un lakehouse ? La stack la plus courante est l’utilisation de Spark ou d’un moteur de requêtes comme Trino, combiné à un format de table comme Delta Lake (promu par Databricks), Apache Iceberg (créé par Netflix) ou Apache Hudi (créé par Uber).

Menu