Data Lake
Aussi : Data Lake, Enterprise Data Lake
Un data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.
Ce que c'est
Un data lake est un référentiel de stockage centralisé qui conserve de très grands volumes de données dans leur format brut d'origine. Contrairement à une base de données ou à un data warehouse classique, il n'exige pas de définir un schéma avant de charger les données. C'est le principe du schema-on-read : la structure est appliquée au moment de la requête, pas au moment du stockage.
Un data lake peut contenir :
- des données structurées (tables relationnelles, fichiers CSV)
- des données semi-structurées (JSON, XML, fichiers de logs, Parquet)
- des données non structurées (images, vidéo, audio, texte libre, PDF)
Pourquoi c'est important
Les organisations produisent des données plus vite qu'elles ne peuvent les modéliser. Un data lake permet aux équipes de tout capter à faible coût maintenant et de décider plus tard de l'usage. Cette flexibilité soutient l'analytics avancé et le machine learning, qui ont souvent besoin de signaux bruts qu'un warehouse pré-agrégé aurait éliminés.
Principaux bénéfices :
- Stockage à faible coût via des object stores (cloud ou on-premises)
- Découplage du stockage et du compute, chacun se scalant indépendamment
- Source unique pour les analystes, les data scientists et les outils de reporting
Le risque principal est le data swamp : sans gouvernance, catalogage ni contrôles qualité, un lake devient un dépotoir dans lequel on ne trouve plus rien. Des métadonnées solides, des politiques d'accès et un data catalog sont indispensables.
Comment on l'utilise en pratique
Les données arrivent dans le lake par chargements batch ou ingestion en streaming. L'organisation se fait généralement en zones : une raw zone (données source intactes), une cleansed zone (validées et dédoublonnées) et une curated zone (jeux de données prêts pour le métier). Des moteurs comme les services de requêtage SQL, les notebooks et les outils de BI lisent directement dans le lake.
Beaucoup d'équipes adoptent aujourd'hui le pattern lakehouse, qui ajoute des formats de tables et des transactions par-dessus le lake pour combiner la flexibilité du lake et la fiabilité du warehouse.
Exemple concret
Un distributeur envoie en streaming ses logs de clickstream, stocke ses tables de ventes chaque nuit et dépose ses images produits dans un même lake. Le marketing requête les clics pour l'attribution des campagnes, la finance lit les ventes pour le reporting, et une équipe data science entraîne un modèle de recommandation sur les clics et les images, le tout depuis le même référentiel.
Voir aussi
Questions fréquentes
Quelle différence entre un data lake et un data warehouse ?
Un data warehouse exige de définir le schéma avant de charger les données ; un data lake stocke les données dans leur format brut d'origine et n'applique une structure qu'au moment de la requête, ce qu'on appelle le schema-on-read. Le warehouse convient mieux au reporting gouverné sur des données modélisées, le lake à la conservation des signaux bruts pour l'exploration et le machine learning. Les coûts diffèrent aussi : le lake repose sur du stockage objet peu cher, avec stockage et compute dimensionnés séparément.
Quels types de données peut-on réellement mettre dans un data lake ?
Les trois familles. Les données structurées comme les tables relationnelles et les fichiers CSV, les données semi-structurées comme JSON, XML, fichiers de logs et Parquet, et les données non structurées comme les images, la vidéo, l'audio, le texte libre et les PDF. C'est tout l'intérêt : vous captez tout à faible coût maintenant et vous décidez plus tard de la modélisation, au lieu de perdre des signaux qu'un warehouse pré-agrégé aurait écartés.
Qu'est-ce qui transforme un data lake en data swamp, et comment l'éviter ?
Un lake devient un data swamp quand les données s'accumulent sans gouvernance, sans catalogage ni contrôle qualité : il ne reste qu'un dépotoir inexploitable auquel personne ne fait confiance. Les garde-fous sont des métadonnées solides, des politiques d'accès explicites et un data catalog pour retrouver un jeu de données et connaître son origine. Sans cela, le stockage bon marché ne fait qu'agrandir le problème.
Comment organise-t-on les données à l'intérieur d'un data lake ?
La plupart des implémentations utilisent des zones. Une zone brute conserve les données source intactes, une zone nettoyée les données validées et dédoublonnées, une zone curated les jeux de données prêts pour le métier. Les données arrivent par chargements batch ou par ingestion en streaming, et les services de requêtage SQL, les notebooks et les outils de BI lisent directement dans ces zones.
Qu'apporte le pattern lakehouse par-dessus un data lake ?
Le lakehouse ajoute des formats de table et des transactions au-dessus du lake : vous gardez la souplesse du stockage brut tout en obtenant la fiabilité habituellement associée au warehouse. Beaucoup d'équipes l'adoptent justement pour ne plus avoir à choisir entre les deux architectures. Le stockage sous-jacent reste le même stockage objet ; ce qui change, ce sont les garanties sur les lectures et les écritures.