Data Lakehouse

Définition complète

Un data lakehouse est une architecture de plateforme de données qui combine deux approches historiquement séparées : le data lake, qui offre un stockage à faible coût dans des formats ouverts sur infrastructure objet (Amazon S3, Google Cloud Storage, Azure Data Lake Storage), et le data warehouse, qui offre des performances analytiques élevées, une application stricte de schémas et des garanties transactionnelles ACID. Le lakehouse réunit ces deux propriétés au sein d'une architecture unifiée.

Techniquement, le lakehouse stocke les données dans des formats de fichiers ouverts et columnarisés — principalement Parquet et ORC — sur un stockage objet standard. Une couche de format de table (Apache Iceberg, Delta Lake ou Apache Hudi) ajoute au-dessus de ces fichiers les propriétés transactionnelles et analytiques qui manquaient aux data lakes classiques : transactions ACID garantissant la cohérence des lectures et écritures concurrentes, évolution de schéma sans migration de données, indexation et partitionnement pour les performances de requête, et requêtes de voyage dans le temps (time travel) permettant d'interroger l'état des données à n'importe quel point dans le passé.

Le terme "lakehouse" a été popularisé par Databricks et formalisé dans un article de recherche de 2021. L'architecture est aujourd'hui supportée nativement par tous les principaux moteurs analytiques — Snowflake, BigQuery, Amazon Athena, Redshift, Spark, Trino, DuckDB, Flink — et est devenue le choix par défaut pour les nouvelles constructions analytiques dans les entreprises qui partent de zéro ou qui modernisent leur infrastructure de données.

Comment fonctionne l'architecture

L'architecture d'un data lakehouse se décompose en trois couches principales, chacune avec un rôle distinct dans la chaîne analytique.

Le choix du format de table est la décision architecturale la plus structurante dans un projet lakehouse. Apache Iceberg gagne en adoption comme standard inter-moteurs : il est supporté nativement par Snowflake, BigQuery, Redshift, Spark, Trino, Flink et DuckDB, ce qui permet de changer de moteur de requête sans migrer les données. Delta Lake reste le choix dominant dans les environnements Databricks. Apache Hudi est privilégié pour les cas d'usage d'ingestion incrémentale à très faible latence (sous la minute) grâce à ses optimisations pour les mises à jour fréquentes enregistrement par enregistrement.

Exemple concret

Une scale-up française du secteur du commerce en ligne traite 2 millions de transactions par mois et souhaite centraliser ses données opérationnelles pour l'analyse. Elle dispose de trois sources : son ERP (SAP), sa plateforme e-commerce (Shopify) et son outil CRM (HubSpot). Son volume de données brutes est de l'ordre de 800 Go par mois.

Avec une architecture lakehouse sur AWS, elle stocke ses données brutes dans Amazon S3 au format Parquet, avec Apache Iceberg comme format de table. Le pipeline d'ingestion (Fivetran) charge les données brutes depuis les trois sources vers S3, puis dbt transforme ces données en tables analytiques toujours au format Iceberg sur S3. Le moteur de requête (Amazon Athena) permet aux analystes d'interroger directement les tables Iceberg via SQL standard, sans charger les données dans un entrepôt propriétaire. Le coût de stockage est de l'ordre de 40 à 80 € par mois (800 Go × 0,05 à 0,10 €/Go), contre 400 à 800 € pour un entrepôt propriétaire de taille équivalente.

Le bénéfice du time travel s'avère immédiatement utile : lorsqu'une erreur de transformation dbt affecte les tables de marge par SKU, l'équipe peut interroger l'état des données tel qu'il était 48 heures avant l'erreur, identifier la source du problème et corriger le pipeline sans perte de données. Sur un entrepôt propriétaire sans time travel, la même situation aurait nécessité un rechargement complet depuis les sources.

Analyse approfondie

L'émergence du data lakehouse entre 2020 et 2022 répond à une double insatisfaction accumulée avec les deux architectures qu'il remplace. Les data lakes purs, adoptés massivement entre 2010 et 2020 sur la promesse d'un stockage universel et bon marché, se sont révélés difficiles à gouverner : sans discipline rigoureuse sur les métadonnées et les schémas, ils se dégradent en "marécages de données" (data swamps) en 12 à 18 mois — des dépôts de fichiers impossibles à interroger de manière fiable. Les data warehouses propriétaires (Snowflake, BigQuery, Redshift dans leur configuration initiale) résolvent le problème de gouvernance mais créent un verrouillage propriétaire coûteux : toutes les données doivent être chargées dans le format natif de l'entrepôt, ce qui engendre des coûts de stockage élevés et des difficultés à utiliser plusieurs moteurs analytiques sur les mêmes données.

La séparation du calcul et du stockage est le principe fondamental qui rend le lakehouse possible et économiquement attractif. Dans les architectures classiques, le moteur de requête et le stockage sont couplés dans le même système propriétaire. Dans un lakehouse, le stockage (S3/GCS/ADLS) est complètement séparé du ou des moteurs de requête (Spark, Trino, Athena, Snowflake external tables). Cette séparation permet de payer le stockage au coût du stockage objet — beaucoup plus bas que le stockage d'entrepôt — et de choisir le moteur de requête le mieux adapté à chaque cas d'usage : Spark pour les transformations à grande échelle, Athena pour les requêtes ad hoc à faible coût, DuckDB pour les analyses locales rapides.

Dans le contexte français et européen, le lakehouse présente un avantage supplémentaire pour les exigences de conformité RGPD. La gestion du droit à l'effacement (right to be forgotten) est nativement supportée par les formats de table modernes : avec Apache Iceberg, une suppression logique peut être réalisée via une opération MERGE sans réécrire l'ensemble de la table, et le time travel peut être limité à une fenêtre temporelle définie pour éviter la persistance de données personnelles au-delà de la durée de rétention légale. Ces capacités sont plus difficiles à implémenter proprement sur un data lake pur ou dans un entrepôt propriétaire sans accès direct aux fichiers sous-jacents.

La convergence vers Apache Iceberg comme format inter-moteurs dominant mérite une attention particulière pour les équipes qui font des choix d'infrastructure en 2025 et 2026. Snowflake a annoncé son support natif d'Iceberg en 2023, permettant aux tables Snowflake d'être stockées dans le format Iceberg sur S3 et donc d'être lues par d'autres moteurs. Google BigQuery supporte la lecture et l'écriture des tables Iceberg depuis 2023. Amazon Athena, Redshift, EMR et Glue supportent tous Iceberg nativement. Cette convergence signifie qu'investir dans Iceberg aujourd'hui réduit le risque de verrouillage à long terme — les données peuvent migrer d'un moteur à l'autre sans transformation.

La transition d'une architecture existante (data lake ou data warehouse) vers un lakehouse doit être planifiée de manière incrémentale. Pour les équipes qui ont un data lake existant sur S3 ou GCS, l'ajout d'Apache Iceberg peut se faire progressivement table par table sans migration complète : on commence par les tables les plus critiques pour les analyses opérationnelles, on valide les performances et la gouvernance, puis on étend à l'ensemble du catalogue. Pour les équipes sur data warehouse propriétaire, la migration est plus complexe mais peut également être progressivement — en déplaçant d'abord les tables à forte croissance de volume, dont le coût de stockage dans l'entrepôt devient prohibitif, vers le lakehouse.

Erreurs fréquentes

• ✗

  Confondre data lake et data lakehouse. Un data lake est simplement un dépôt de fichiers sur stockage objet, sans garanties transactionnelles ni application de schéma. Un data lakehouse ajoute une couche de format de table (Iceberg, Delta, Hudi) qui fournit précisément ces propriétés. Utiliser les termes de manière interchangeable conduit à des confusions sur les capacités réelles de l'infrastructure et sur les investissements nécessaires pour atteindre les propriétés analytiques souhaitées.

• ✗

  Choisir un format de table propriétaire sans évaluer l'interopérabilité. Delta Lake, dans sa version originale open-source, présente des limitations d'interopérabilité avec les moteurs hors de l'écosystème Databricks. Avant de choisir un format de table, il convient de lister tous les moteurs qui devront lire et écrire ces tables à court et moyen terme, et de vérifier la compatibilité native de chacun avec le format envisagé. Iceberg offre aujourd'hui la couverture d'interopérabilité la plus large.

• ✗

  Négliger la maintenance du catalogue de métadonnées. Les formats de table modernes génèrent des fichiers de métadonnées (snapshots, manifests) qui s'accumulent avec le temps et doivent être nettoyés régulièrement via des opérations de compaction et d'expiration de snapshots. Sans maintenance régulière, les performances de requête se dégradent à mesure que le nombre de fichiers de métadonnées augmente, et les coûts de stockage gonflent inutilement. Des jobs de maintenance hebdomadaires ou quotidiens sont non négociables en production.

Comment Fairview s'intègre avec un data lakehouse

Pour les équipes qui ont déjà un data lakehouse en production, Fairview peut se connecter directement aux principales plateformes compatibles — Databricks (Delta Lake), Snowflake (Iceberg ou natif), BigQuery, Amazon Athena — via des connecteurs natifs. Fairview lit les métriques opérationnelles définies dans les tables analytiques du lakehouse et les expose dans son tableau de bord de suivi en temps réel, sans dupliquer les données ni créer une couche de transformation redondante. Pour les équipes sans infrastructure analytique existante, Fairview intègre directement les sources opérationnelles (CRM, comptabilité, ERP) et gère la couche de transformation en interne. Dans les deux cas, l'objectif est identique : transformer des données fragmentées en indicateurs décisionnels actionnables — marge par produit, coût entièrement alloué par segment, pipeline de revenus par canal — disponibles sans extraction manuelle ni tableur intermédiaire.

Questions fréquentes