Jeudi 10 octobre à 18h30
Découvrez les métiers de la data et comment vous y former

Depuis plus de trois ans, notre objectif est de permettre au plus grand nombre de se former aux métiers de la data, quelque soit votre profil. Cet évènement vous permettra de découvrir nos programmes de formation conçus pour vous permettre de vous reconvertir vers la data ou de monter en compétences !

Je m'inscris
Découvrez les métiers de la data et comment vous y former. Le jeudi 10 octobre à 18h30
Découvrez les métiers de la data et comment vous y former. Le jeudi 10 octobre à 18h30
Découvrez les métiers de la data et comment vous y former. Le jeudi 10 octobre à 18h30
Je m'inscris

Data lake vs Data Warehouse : comprendre les différences fondamentales entre ces deux modes de stockage de données

À l'ère du Big Data, le choix de la technique de stockage est stratégique. Que choisir entre Data Lake et Data Warehouse ?

Antoine Grignola
Co-fondateur de DataBird
Mis à jour le
4/9/2024

Découvrez nos formations dédiées à la Data Engineering.

Découvrir

Si l’on s’intéresse au stockage de données, il est difficile de passer à côté des Data Lake et Data Warehouse. Souvent confondus et employés de façon interchangeable, il s’agit pourtant de deux concepts bien distincts, destinés à des usages également très différents. Non, le Data Lake (ou lac de données) n’est pas un nouveau terme à la mode pour désigner un Data Warehouse (ou entrepôt de données). Certes, ces deux concepts désignent des référentiels de stockages de données appliqués au Big Data, mais au-delà de cette similitude, ils diffèrent sur la quasi-totalité de leurs caractéristiques. De nombreuses entreprises utilisent à la fois des Data Lakes et des Data Warehouse, pour des objectifs différents. Avec l’explosion du Deep Learning, quel référentiel privilégier ? Quelles sont les véritables différences entre ces deux référentiels  ?

Une brève histoire des bases de données et leur stockage

L’émergence des données relationnelles

Chaque référentiel de stockage vise à répondre aux besoins de l’époque dans lequel il est développé. Un référentiel est donc marqué par l’histoire. C’est pourquoi il importe de s’y pencher pour bien les comprendre.

Les bases de données relationnelles se sont popularisées au cours des années 80. Beaucoup plus simples à utiliser que leurs prédécesseurs, on communique principalement avec elles grâce au SQL (Structured Query Language).

Le traitement transactionnel des données relationnelles

Ces bases de données relationnelles étaient principalement dédiées au traitement transactionnel.

On parlait alors des opérations « CRUD : create, read, update and delete », des propriétés « ACID : atomicity, consistency, isolation and durability », pour les transactions informatiques. Cela passait notamment par le protocole two-phase commit, un ensemble de règles visant à assurer l’intégrité des données.

Pour mieux comprendre ces concepts, vous pouvez vous former gratuitement à l’analyse de données avec Data Bird, ou approfondir ces connaissances dans une formation certifiante sur 8 ou 12 semaines.

Ces bases de données relationnelles étaient utilisées pour produire des rapports quotidiens, à des fins opérationnelles. Pour effectuer ces rapports analytiques, il est nécessaire d’avoir des données historiques pour dessiner des tendances.

Progressivement, le développement de réels entrepôts de données s’est avéré indispensable pour stocker ces données historiques en grande quantité.

Un stockage efficient des bases données relationnelles

stockage des données

Pour le Deep Learning, cette exigence de données historiques en gros volume persiste. Ces données historiques sont statiques, par définition, il n’est donc pas nécessaire de mettre en place un système de stockage permettant de traitement transactionnel, car ce traitement est lourd et coûteux.

Au contraire, construire un référentiel de stockage mettant l’accent sur les opérations d’ajout et de lecture est plus pertinent et efficient. Les entrepôts de données et des lacs de données sont nés sur ce principe. Ils n’ont pas pour vocation la mise à jour et la suppression de données.

Un stockage caché?

Notons qu’à l’origine, toute base de données relationnelle est équipée d’un stockage optimisé pour les opérations d’ajout et de lecture des bases. Le « redo log » stocke les modifications apportées au fur et à mesure, pour les récupérer en cas de défaillance. Cependant, ce stockage était profondément caché.

La révolution actuelle des bases de données ramène ce système de stockage à la surface. Plutôt qu’un système caché, il devient le stockage primaire des données. Une base de données moderne s'apparente donc à un lac de données.

Le Data Warehouse, ou entrepôt de données

Qu’est-ce que c’est  ?

data warehouse

Le Data Warehouse est une vaste base de données, organisée et structurée. Elle n’est pas une simple copie des données collectées par l’entreprise, mais est intrinsèquement organisée pour assurer la stabilité contextuelle des données. Les données historiques y sont stockées par thème ou sujets pertinents pour l’entreprise.

Bill Inmon est à l’origine du concept, et le définit comme une collecte de données à l'appui des décisions de management :

  • Orientée sujet : les données sont organisées par thème et collectées depuis des bases OLTP de production pour les regrouper.
  • Intégrée : les données proviennent de diverses sources aux formats de données hétérogènes, qui sont intégrés avant l’utilisation.
  • Non volatile : les données initiales ne disparaissent pas au fil des traitements.
  • Historisé : on peut visualiser l’évolution d’une variable au cours du temps, si la variable mérite d’être archivée.

Un complément aux bases de données relationnelles

Au moment de leur création, les Data Warehouses étaient perçus comme un complément aux bases de données relationnelles transactionnelles. En effet, les Data Warehouses intègrent des fonctionnalités supplémentaires, qui s’ajoutent aux capacités OLTP :

  • le processus ETL (extract, transform, load) qui transfère en continu les données vers l'entrepôt de données ;
  • l’outil de traitement analytique en ligne OLAP ;
  • et d’autres applications pour le traitement des données collectées.

Initialement perçu comme un simple complément, il porte donc l’héritage des bases de données relationnelles : un modèle de données rigide, des colonnes et les types de données.

Il est très facile de faire des requêtes et construire des rapports à partir des données du Data Warehouse, et ce, même pour les utilisateurs finaux.

 {{banniere-article}}

Quelles sont ses limites  ?

Les Data Warehouses ont de très nombreux atouts, mais font pourtant l’objet de critiques. Quels sont les problèmes soulevés ?

On pense souvent que les Data Warehouse ne permettent pas de stocker les données non structurées. En réalité, les bases de données relationnelles disposaient de types de données permettant de stocker ces informations et pouvaient également être transférées dans un entrepôt de données.

En revanche, les Data Warehouses ont généralement une architecture monolithique, similaire à celle des bases de données, ce qui complique le passage au Big Data. Ils ne sont pas idéaux pour les très grandes tailles de données.

Les entrepôts de données manquent également d’agilité. En ajoutant de nouvelles sources de données, de nouveaux consommateurs de données ajoutent de nouvelles exigences. Les applications alimentant l'entrepôt de données évoluent pour s’y adapter, mais il est difficile pour l'équipe gérant l'entrepôt de données de suivre tous ces changements.

Un dernier écueil concerne les pertes de données lors du stockage. Certaines informations sont perdues dans les ETL et ne peuvent pas être rendues disponibles facilement, si une nouvelle application en a besoin.



Le Data Lake, des solutions et de nouveaux problèmes

Une solution aux limites des Data Warehouses…

Pour sa part, un Data Lake conserve des données brutes, et potentiellement non structurées, en vue d’une utilisation future. Concept assez récent, il vise à résoudre certaines limites du Data Warehouse.

Il apporte premièrement une réponse au problème d’agilité. On parle souvent d’une démarche ELT (extract, load, transform) plutôt qu’ETL : chaque consommateur de données peut extraire les données puis les combiner et les transformer, là où les données prenaient un chemin relativement fixe dans les Data Warehouse.

On passe donc d’un schéma on write (créer un schéma pour la donnée avant de l'écrire sur la base de données) à un schéma on read (on crée le schéma d’écriture seulement en lisant la donnée). Le schéma on read est basé sur le NoSQL.

Il apporte également une réponse au problème des données perdues. Le Data Lake est extrêmement fiable et stocke absolument tout. Un Data Lake simple est, par exemple, un Cloud Bucket (un conteneur de base contenant les données, associé à un projet).

En bonus, le Data Lake permet un stockage facile de différents formats de données : des données structurées, semi-structurées et non structurées. Différents formats de données permettent de lire rapidement les fichiers : CSV, Avro, Parquet… On peut aussi souligner un autre avantage : un coût plus faible.

… Qui apporte son lot de difficultés

Si le Data Lake n’a rien à envier au Data Warehouse en termes de coûts, il est cependant moins performant : d’un stockage prenant quelques millisecondes, on passe à plusieurs minutes ou heures.

De plus, si l’on contrôle mal l’agilité procurée par ce mode de stockage, le Data Lake peut rapidement devenir un réel chaos. À vouloir tout stocker sans stratégie, on noie les données dans un vaste marécage de données.

Le Data Lake fait émerger de nouveaux défis, et en particulier sur les sujets de gouvernance de la donnée. Cette gouvernance est primordiale pour ce paradigme de stockage.

Il faut redoubler d’exigence quant au contrôle d’accès des données (notamment pour respecter les réglementations), au lignage des données (pour suivre les transformations effectuées et les utilisations des données), à la qualité des données, et au contrôle du changement.

Conclusion

En définitive, de quel référentiel avez-vous besoin pour vos projets de machine learning ? Et bien, vous avez besoin des deux : Data Lake et Data Warehouse.

Stockez vos données brutes avec une grande fiabilité dans un Data Lake, exécutez-y des pipelines d’extractions et stockez les features extraites dans un Data Warehouse (feature store).

Puisque ces pipelines prennent un certain temps, il est important de les lancer dès l’obtention des données. Faire tourner les projets sur ces feature stores permet une haute performance et un contrôle robuste des changements.

Les Data Lake et Data Warehouse sont des incontournables des métiers de la Data. Si vous souhaitez vous initier à ces métiers, DataBird vous propose la formation Data analyst à Paris (8 semaines à temps plein) et la formation Data analyst à distance (12 semaines à temps partiel), qui s’adressent à tous les profils.

Faites un premier pas dans la data avec nos cours gratuits
Démarrer
Difficulté :
Facile