Accueil › Glossaire › Data Lake

Data Lake

Un data lake est un système de stockage centralisé qui conserve de grandes quantités de données brutes dans leur format natif (structuré, semi-structuré ou non structuré) sur du stockage objet à faible coût, en attendant qu’elles soient traitées et analysées.

Contrairement à un data warehouse qui exige de structurer les données avant de les stocker (schema-on-write), un data lake adopte l’approche schema-on-read : vous stockez tout, dans n’importe quel format, et vous n’imposez un schéma qu’au moment de la lecture. Cette flexibilité a fait du data lake le socle de l’infrastructure data moderne. Mais sans gouvernance, un data lake devient vite un « data swamp » : un marécage de fichiers inutilisables dont personne ne connaît le contenu.

Pourquoi les data lakes existent

Les data lakes sont nés d’une limitation des data warehouses traditionnels. Un warehouse comme Oracle, Teradata ou même Redshift stocke des données structurées, dans un format propriétaire, à un coût élevé par Go. Quand les organisations ont voulu stocker des logs serveur, des images, des fichiers JSON d’APIs, des données IoT et des datasets ML de plusieurs téraoctets, le warehouse n’était plus une option économiquement viable.

Le data lake résout ce problème en utilisant du stockage objet cloud (S3, GCS, Azure Blob) qui coûte une fraction de centime par Go. Vous stockez tout, tel quel, sans transformation préalable. Les données restent disponibles indéfiniment pour des analyses futures que vous n’avez pas encore imaginées. C’est l’inverse du warehouse où vous devez définir votre schéma et vos cas d’usage avant de charger les données.

Cas d’usage principaux

Consolidation des données d’entreprise. Le data lake centralise les données de tous les systèmes (CRM, ERP, produit, marketing, IoT) dans un seul endroit. Fini les silos où chaque département a sa propre copie des données.

Machine learning et data science. Les data scientists ont besoin de données brutes, volumineuses et variées pour l’exploration, le feature engineering et l’entraînement de modèles. Le data lake fournit ces données dans des formats directement lisibles par pandas, Spark, PyTorch et TensorFlow.

Archivage et conformité. Les données brutes conservées dans le lake constituent une source de vérité immuable. Pour les exigences réglementaires (GDPR, SOX, audit financier), cette préservation des données originales est cruciale.

Analyse exploratoire. Avant de savoir quelles questions poser, vous devez avoir accès aux données. Un data lake permet aux analystes d’explorer librement les données brutes sans passer par un data engineer pour chaque nouvelle requête.

Architecture d’un data lake

Couche de stockage objet

Le socle d’un data lake est le stockage objet : Amazon S3, Google Cloud Storage, Azure Blob Storage, ou MinIO (open source, S3-compatible). Les données sont stockées comme des fichiers immuables organisés en préfixes (pseudo-dossiers). Le stockage objet est infiniment scalable, hautement durable (99.999999999% de durabilité pour S3) et extrêmement bon marché : quelques centimes par Go par mois.

Organisation en zones

Un data lake mature adopte une architecture en zones qui reflète le cycle de vie des données :

Zone Raw (Bronze) : les données sont ingérées telles quelles depuis les sources, sans aucune transformation. Cette zone est la source de vérité. Les données y sont immuables : on n’écrase jamais un fichier raw, on en ajoute de nouveaux. C’est essentiel pour l’auditabilité et le retraitement en cas de bug dans les transformations en aval.

Zone Processed (Silver) : les données raw sont nettoyées, standardisées et enrichies. Les doublons sont supprimés, les formats sont normalisés, les schémas sont appliqués. Cette zone contient des données utilisables mais pas encore optimisées pour un cas d’usage spécifique.

Zone Curated (Gold) : les données sont agrégées, jointes et modélisées pour la consommation finale. C’est la couche que les analystes, les dashboards BI et les modèles ML consomment directement. Les tables Gold sont souvent exposées via un lakehouse ou chargées dans un data warehouse pour les requêtes SQL rapides.

Formats de fichiers

Le choix du format de fichier impacte directement les performances de requête et les coûts de stockage :

Formats de tables ouvertes : Delta Lake, Iceberg, Hudi

Les formats de fichiers seuls ne suffisent pas. Une collection de fichiers Parquet sur S3 ne constitue pas une table au sens base de données : pas de transactions ACID, pas d’évolution de schéma, pas de time travel, pas de gestion de la concurrence. Les formats de tables ouvertes ajoutent cette couche de métadonnées par-dessus les fichiers Parquet.

Apache Iceberg est le format qui s’impose comme standard en 2026. Conçu pour être agnostique vis-à-vis du moteur de requête, il est supporté par Snowflake, AWS, Google Cloud, Spark, Trino, DuckDB et Flink. Son système de métadonnées stocke le schéma, les statistiques et le lineage directement avec la table, ce qui permet le partition pruning efficace et le time travel.

Delta Lake, créé par Databricks, est profondément intégré à l’écosystème Databricks. Il offre les mêmes fonctionnalités (ACID, schema evolution, time travel) mais son adoption est plus forte dans les environnements Databricks. Delta Lake est open source (licence Apache 2.0).

Apache Hudi est spécialisé dans les scénarios d’upsert et de CDC à grande échelle. Il est populaire dans les architectures où les données doivent être mises à jour fréquemment (synchronisation de bases transactionnelles vers le lake).

Du Data Lake au Data Lakehouse

Le data lakehouse est l’évolution architecturale majeure de la décennie. Il combine le stockage flexible et peu coûteux du data lake avec les fonctionnalités de gestion et de requête du data warehouse : transactions ACID, enforcement de schéma, time travel, requêtes SQL rapides et gouvernance fine.

Le concept a été formalisé dans un article de recherche de UC Berkeley et Databricks en 2021. L’idée centrale : au lieu de maintenir un data lake ET un data warehouse séparés (architecture « two-tier » avec duplication de données, coûts supplémentaires et problèmes de synchronisation), unifiez tout dans un seul système basé sur le stockage objet avec une couche transactionnelle par-dessus.

Comment fonctionne un lakehouse

Un lakehouse se compose de trois couches :

Stockage objet (S3, GCS, Azure Blob) : stockage bon marché des données en format ouvert (Parquet).

Format de table ouvert (Iceberg, Delta Lake) : ajoute les métadonnées, les transactions ACID, le time travel et l’évolution de schéma. C’est cette couche qui transforme un data lake en lakehouse.

Moteur de requête (Spark, Trino, DuckDB, Snowflake) : exécute les requêtes SQL sur les tables du lakehouse. La séparation stockage/compute permet d’utiliser différents moteurs pour différents workloads et de scaler indépendamment.

Lakehouse vs Data Warehouse

Pour les workloads purement SQL/BI avec des données structurées, un data warehouse classique (Snowflake, BigQuery) reste souvent plus simple et plus performant. Le lakehouse se justifie quand vous avez besoin de supporter simultanément du SQL analytique, du ML et du streaming sur les mêmes données.

Les plateformes de data lake en 2026

Databricks Lakehouse Platform

Databricks est le pionnier du concept de lakehouse. Sa plateforme combine Delta Lake (format de table), Unity Catalog (gouvernance et lineage), Apache Spark (compute), MLflow (experiment tracking et model registry), et des SQL warehouses pour le BI. L’intégration verticale est le point fort : tout fonctionne ensemble nativement.

Snowflake avec Iceberg

Snowflake, historiquement un data warehouse, a ajouté le support natif d’Apache Iceberg, permettant aux clients de stocker leurs données en format ouvert sur leur propre stockage objet tout en bénéficiant du moteur de requête Snowflake. C’est un pont entre le modèle warehouse traditionnel et le lakehouse ouvert.

AWS Lake Formation + S3

AWS propose Lake Formation pour orchestrer la création et la gouvernance d’un data lake sur S3, avec support d’Iceberg et d’Athena (moteur de requête serverless). L’avantage est l’intégration avec l’écosystème AWS (Glue, SageMaker, Redshift). La complexité vient du nombre d’outils à assembler.

Google Cloud (BigLake)

BigLake de Google unifie l’accès aux données entre BigQuery et les données lake sur GCS, avec support d’Iceberg. BigQuery reste le moteur de requête principal, et BigLake étend sa portée aux données non structurées du lake.

Data Lake et machine learning

Le data lake est le réservoir naturel pour les workflows ML :

Datasets d’entraînement. Les données brutes du lake sont la matière première du ML. Les data scientists explorent les zones raw et processed pour identifier les features pertinentes, puis créent des datasets d’entraînement structurés dans la zone curated ou dans un feature store.

Versionnage des données. Les formats de tables ouvertes (Iceberg, Delta Lake) offrent le time travel : vous pouvez requêter une table telle qu’elle était à une date donnée. Combiné avec DVC ou lakeFS, cela garantit la reproductibilité des expériences ML. Chaque run d’experiment tracking peut référencer un snapshot précis du dataset.

Données non structurées. Les images, vidéos, fichiers audio et textes bruts utilisés pour entraîner des modèles de deep learning sont stockés dans le lake en format natif. Les embeddings générés par ces modèles peuvent ensuite être stockés dans un vector store pour la recherche sémantique.

Feature pipelines. Les data pipelines qui calculent des features ML puisent dans le lake (zone processed) et écrivent les résultats dans le feature store. Le lake est la source de vérité, le feature store est la couche de serving optimisée.

Bonnes pratiques

Organisez en zones dès le départ

Implémentez les zones Raw/Processed/Curated dès la création du lake. Définissez des conventions de nommage claires pour les préfixes S3 : s3://data-lake/raw/{source}/{date}/, s3://data-lake/processed/{domain}/, s3://data-lake/curated/{mart}/. Sans cette structure, le lake devient un dossier de fichiers non navigable en quelques mois.

Utilisez Parquet + Iceberg (ou Delta Lake)

Convertissez les données en Parquet dès l’ingestion dans la zone raw (sauf si le format source est déjà optimisé). Ajoutez un format de table ouvert (Iceberg ou Delta Lake) dès la zone processed pour bénéficier des transactions ACID, du time travel et de l’évolution de schéma. En 2026, un lake sans format de table est considéré comme une dette technique.

Implémentez un catalogue de données

Chaque dataset du lake doit être référencé dans un catalogue avec : nom, description, propriétaire, schéma, fréquence de mise à jour, date de dernière mise à jour, et tags métier. Databricks Unity Catalog, AWS Glue Data Catalog, ou des solutions open source comme DataHub ou Apache Atlas remplissent ce rôle. Un catalogue de données transforme un data swamp en data lake exploitable.

Sécurisez les accès

Implémentez un contrôle d’accès granulaire : qui peut lire quelles zones, quelles tables, quelles colonnes. Les données PII (informations personnellement identifiables) dans la zone raw doivent être protégées par chiffrement, masquage ou pseudonymisation. Unity Catalog (Databricks) et Lake Formation (AWS) fournissent ces contrôles nativement.

Gérez les petits fichiers

L’un des problèmes opérationnels les plus fréquents d’un data lake est l’accumulation de petits fichiers. Des milliers de fichiers de quelques Ko génèrent une surcharge de métadonnées et dégradent les performances de requête. Exécutez des jobs de compaction réguliers pour fusionner les petits fichiers en fichiers plus grands (idéalement 128 Mo à 1 Go). Iceberg et Delta Lake fournissent des commandes de compaction natives.

Définissez des politiques de rétention

Le stockage objet est bon marché, mais pas gratuit. Définissez des politiques de rétention par zone : les données raw peuvent être conservées indéfiniment (ou archivées en Glacier/Archive après un an), les données processed sont conservées selon les besoins d’analyse, et les données temporaires sont supprimées automatiquement. Utilisez les lifecycle policies de S3/GCS pour automatiser les transitions entre tiers de stockage.

Verdict

Le data lake reste le socle de toute infrastructure data moderne en 2026, mais il a évolué. Le lake « brut » (fichiers Parquet sur S3 sans gouvernance) est largement remplacé par le data lakehouse qui ajoute les transactions ACID, la gouvernance et les requêtes SQL performantes via Iceberg ou Delta Lake.

Pour un nouveau projet, la recommandation est claire : stockage objet (S3/GCS) + Apache Iceberg + un catalogue (Unity Catalog, Glue, ou DataHub) + un moteur de requête (Spark, Trino, ou DuckDB). Organisez en zones Bronze/Silver/Gold dès le départ. Si vos workloads sont principalement du SQL/BI, un data warehouse classique (Snowflake, BigQuery) est plus simple. Le lakehouse se justifie quand vous combinez analytique SQL, ML et streaming sur les mêmes données.

Le choix entre Iceberg et Delta Lake dépend de votre écosystème : Delta Lake si vous êtes sur Databricks, Iceberg pour tout le reste (multi-engine, multi-cloud). Les deux formats convergent en fonctionnalités, mais Iceberg gagne en adoption grâce à son approche agnostique.