Entrepôts de données, data lakes et data lakehouses 

Les entrepôts de données, les data lakes et les data lakehouses sont différents types de solutions de gestion des données aux fonctions diverses :

• Les entrepôts de données agrègent, nettoient et préparent les données afin qu’elles puissent être utilisées dans le cadre de la business intelligence (BI) et de l’analyse de données. 

• Les data lakes permettent de stocker de grandes quantités de données brutes à faible coût. 

• Les data lakehouses réunissent en une seule solution le stockage flexible des données d’un lake et les capacités analytiques à haute performance d’un entrepôt.

Comme ces solutions ont des fonctionnalités et des objectifs différents, de nombreuses architectures de données d’entreprise en utilisent deux, parfois les trois, dans un data fabric holistique :

• Une organisation peut utiliser un data lake comme solution de stockage à usage général pour toutes les données entrantes, quel que soit leur format.

• Les données du lake peuvent être injectées dans des entrepôts de données adaptés à chaque unité commerciale, où elles peuvent éclairer la prise de décision.

• Une architecture de data lakehouse peut aider les data scientists et les ingénieurs de données à travailler plus facilement avec des données brutes dans un data lake pour le machine learning (ML), l’intelligence artificielle (AI) et les projets de science des données.

Les data lakehouses sont également populaires en tant que voie de modernisation pour les architectures de données existantes. Les organisations peuvent mettre en œuvre de nouveaux data lakehouses sans démanteler et remplacer leurs lakes et entrepôts actuels, ce qui simplifie la transition vers une solution unifiée de stockage et d’analyse des données.

Un entrepôt de données regroupe des données provenant de sources disparates (bases de données, applications d’entreprise et flux de réseaux sociaux) dans un seul et même entrepôt. La fonctionnalité principale d’un outil d’entreposage de données est qu’il nettoie et prépare les jeux de données ingérés. 

Les entrepôts de données appliquent une approche appelée « schéma à l’écriture », qui consiste à appliquer un schéma cohérent à toutes les données lorsqu’elles sont écrites sur le support de stockage. Cela permet d’optimiser les données pour la business intelligence et l’analytique.

Ainsi, un entrepôt de données sur les ventes au détail permet de s’assurer que les informations telles que la date, le montant et le numéro de la transaction sont correctement formatées et attribuées aux bonnes cellules d’une table relationnelle. 

Un datamart est un type d’entrepôt de données qui contient des données spécifiques à un secteur d’activité ou à un service particulier, plutôt qu’à l’ensemble de l’entreprise. Une équipe de marketing peut donc avoir son propre datamart, tout comme les ressources humaines, et ainsi de suite. 

Un entrepôt de données type comporte 3 couches :

• La couche inférieure, où les données sont introduites dans l’entrepôt à partir de diverses sources par le biais d’un processus d’extraction, de transformation et de chargement (ETL). Dans de nombreux entrepôts, les données sont stockées dans une base de données relationnelle ou un système similaire. 

• La couche intermédiaire s’articule autour d’un moteur analytique, tel qu’un système de traitement analytique en ligne (OLAP) ou un moteur SQL. Cette couche intermédiaire permet aux utilisateurs d’interroger des jeux de données et d’effectuer des analyses directement dans l’entrepôt. 

• La couche supérieure comprend les interfaces utilisateur et les outils de reporting, grâce auxquels les utilisateurs peuvent effectuer des analyses ad hoc de leurs données commerciales.  

Les premiers entrepôts de données étaient hébergés sur site, mais aujourd’hui, beaucoup sont hébergés dans le cloud ou fournis sous forme de services cloud. Les approches hybrides sont également courantes. 

Comme les entrepôts de données traditionnels reposent sur des systèmes de bases de données relationnelles et des schémas stricts, ils sont plus efficaces avec des données structurées. Certains entrepôts modernes ont évolué pour prendre en charge les données semi-structurées et non structurées, mais de nombreuses organisations préfèrent les data lakes et les lakehouses pour ces types de données.

Les entrepôts de données sont utilisés par les analystes métier, les data scientists et les ingénieurs en traitement de données pour l’analyse en libre-service.  

L’application d’un schéma défini à toutes les données favorise leur cohérence : elles sont plus fiables et plus faciles à utiliser. Les entrepôts de données stockent les données en utilisant un schéma relationnel structuré : ils prennent donc en charge les requêtes SQL hautes performances.

Les organisations peuvent utiliser des outils de BI et d’analyse de données intégrés ou connectés pour analyser les données transactionnelles et historiques, générer des visualisations et créer des tableaux de bord, ce afin de permettre une prise de décisions fondée sur les données.

La maintenance des entrepôts peut coûter cher. Les données doivent être converties avant d’être chargées dans un entrepôt, ce qui demande du temps et des ressources. Comme le stockage et le calcul sont étroitement liés dans les entrepôts traditionnels, la mise à l’échelle peut s’avérer coûteuse. Si les données ne sont pas correctement gérées, les performances des requêtes peuvent en pâtir. 

Les entrepôts de données ne sont pas bien adaptés aux workloads d’IA et de ML, car ils peuvent avoir des difficultés avec les jeux de données non structurées et semi-structurées.

Les data lakes sont des solutions de stockage de données peu coûteuses, conçues pour gérer des volumes massifs de données. Ils emploient une approche de type « schéma à la lecture », c’est-à-dire qu’ils n’appliquent pas de format standard aux données entrantes. Les schémas sont introduits lorsque les utilisateurs accèdent aux données par l’intermédiaire d’un outil d’analyse ou d’une autre interface.

Les data lakes stockent les données dans leur format natif. Ils peuvent ainsi stocker des données structurées, non structurées et semi-structurées sur la même plateforme.  

Les data lakes ont été créés pour aider les organisations à gérer le flot de données massives déclenché par le Web 2.0 et l’essor de l’informatique cloud et mobile à la fin des années 2000 et au début des années 2010. Les organisations ont dû faire face à un volume de données plus important que jamais, dont une grande partie dans des formats non structurés (tels que le texte libre et les images) que les entrepôts traditionnels ne peuvent pas facilement gérer.

Les premiers data lakes étaient souvent basés sur le système de fichiers distribué Apache Hadoop (HDFS). Les data lakes modernes emploient souvent un service de stockage d’objets dans le cloud, tel que Amazon Simple Storage Service (S3), Microsoft Azure Blob Storage ou IBM Cloud Object Storage.

Les data lakes séparent le stockage de données des ressources de calcul, ce qui les rend plus rentables et évolutifs que les entrepôts de données. Les organisations peuvent ajouter du stockage sans dimensionner les ressources de calcul en parallèle. Le stockage dans le cloud favorise encore davantage l’évolutivité, car les organisations peuvent ajouter du stockage sans augmenter les ressources sur site.

Les utilisateurs peuvent connecter des outils de traitement de données externes, tels qu’Apache Spark, pour traiter les données d’un data lake. Contrairement à un entrepôt de données, ces outils ne sont pas intégrés au data lake.

En raison de leur faible coût, de leur évolutivité et de leur capacité à stocker des données de n’importe quel format, les data lakes sont un choix populaire pour le stockage de données à usage général.

Les organisations les emploient souvent pour conserver des sauvegardes et pour archiver des données anciennes et inutilisées. Elles peuvent également utiliser les data lakes pour stocker toutes les nouvelles données entrantes, y compris celles qui n’ont pas d’objectif défini. Les données peuvent ainsi demeurer dans le data lake jusqu’à ce que l’organisation en ait l’utilité.

Les organisations utilisent également des data lakes pour stocker les jeux de données destinés aux workloads de ML, d’IA et d’analyse du big data, comme la découverte de données, l’entraînement des modèles et les projets d’analyse expérimentaux.  

Parce qu’ils n’appliquent aucun schéma strict et ne disposent pas d’outils de traitement intégrés, les data lakes peuvent être confrontés à des problèmes de gouvernance et de qualité des données. Ils sont également moins adaptés aux efforts quotidiens des utilisateurs professionnels en matière de BI et d’analyse des données.

Les organisations ont souvent besoin d’outils distincts, tels qu’un catalogue de données complet et un système de gestion des métadonnées, pour garantir l’exactitude et la qualité des données. Sans ces outils, les data lakes peuvent facilement devenir des marécages de données.

Un data lakehouse fusionne les fonctionnalités essentielles des data lakes et des entrepôts de données en une seule solution de gestion des données. 

Tout comme les data lakes, les data lakehouses peuvent stocker des données dans n’importe quel format (structuré, non structuré ou semi-structuré) à un coût peu élevé. 

De même, ils permettent d’effectuer des recherches rapides et des analyses optimisées, à l’instar des entrepôts de données.

Un data lakehouse allie des technologies et des outils auparavant disparates en une solution complète. L’architecture typique d’un lakehouse comprend les couches suivantes :

Comme dans un data lake, les ressources de calcul et de stockage sont séparées, favorisant ainsi l’évolutivité.

Les data lakes s’appuient fortement sur les technologies open source. Les formats de données comme Apache Parquet et Apache Iceberg permettent aux organisations de déplacer librement les workloads entre les environnements. Delta Lake, une couche de stockage open source, prend en charge des fonctionnalités qui permettent aux utilisateurs d’exécuter des analyses sur des jeux de données brutes, pour la gestion des versions et les transactions ACID par exemple. Les propriétés désignées par l’acronyme « ACID » sont l’atomicité, la cohérence, l’isolation et la durabilité : les propriétés clés qui permettent de garantir l’intégrité des transactions de données.

Les organisations peuvent concevoir leurs propres lakehouses à partir d’éléments constitutifs ou recourir à des solutions prédéfinies telles que Databricks, Snowflake ou IBM watsonx.data.

Les data lakehouses peuvent permettre aux organisations de surmonter certaines limites et complexités liées aux entrepôts de données et aux data lakes.  

Les entrepôts de données et les data lakes servant à des fins différentes, de nombreuses organisations mettent ces deux solutions en œuvre dans leurs piles de données. De ce fait, les utilisateurs doivent jongler entre deux systèmes de données disparates, en particulier dans le cadre de projets d’analyse plus avancés. Cela peut conduire à toutes sortes de problèmes : workflows inefficaces, données dupliquées, problèmes de gouvernance des données et autres.

Les lakehouses peuvent contribuer à rationaliser les efforts d’analyse en prenant en charge l’intégration des données. Toutes les données, quel que soit leur type, peuvent être stockées dans le même référentiel central, ce qui réduit le besoin de duplication. Tous les types d’utilisateurs professionnels peuvent employer les lakehouses pour leurs projets, notamment en matière de BI, d’analyse prédictive, d’IA et de ML.

Les data lakehouses peuvent également servir de voie de modernisation pour les architectures de données existantes. Étant donné que les architectures de lakehouse ouvertes s’intègrent facilement aux lakes et aux entrepôts existants, les organisations peuvent commencer à faire la transition vers de nouvelles solutions intégrées sans procéder à une désinstallation et une réinstallation perturbatrices.

Même si les data lakehouses permettent de rationaliser de nombreux workflows de données, leur mise en place peut être difficile. Il se peut également que les utilisateurs passent par une période d’apprentissage, car le fonctionnement d’un data lakehouse peut différer de celui des entrepôts auxquels ils sont habitués. En outre, la technologie utilisée dans les data lakehouses est relativement nouvelle, et leur cadre continue d’évoluer.

Les entrepôts de données, les data lakes et les data lakehouses répondent à différents besoins métier et différentes exigences en matière de données. De nombreuses organisations utilisent une combinaison de ces systèmes pour rationaliser les pipelines de données et soutenir les workloads d’IA, de ML et d’analytique.   

Prenons l’exemple d’une cuisine commerciale. Chaque jour, cette cuisine reçoit des livraisons d’ingrédients (données) arrivant par camion (bases de données transactionnelles, applications métier, etc.).  

Tous les ingrédients, quel que soit leur type, arrivent sur le quai de chargement (le data lake). Les ingrédients sont traités et triés dans des réfrigérateurs, des garde-manger et d’autres zones d’entreposage (entrepôts de données). Là, les ingrédients sont prêts à être utilisés par les chefs sans aucun traitement supplémentaire.  

Ce processus est assez efficace, mais il met en lumière certains des défis posés par les data lakes et les entrepôts de données traditionnels. Comme les ingrédients sur un quai de chargement, les données d’un data lake ne peuvent pas être utilisées sans traitement supplémentaire. Comme les ingrédients dans une cuisine, les données d’un entrepôt de données doivent être correctement préparées et distribuées au bon endroit avant de pouvoir être utilisées.

Un data lakehouse, c’est un peu comme regrouper un quai de chargement, un garde-manger et un réfrigérateur au même endroit. Bien entendu, cette combinaison peut paraître irréaliste dans le domaine des cuisines commerciales. Cependant, dans le monde des données d’entreprise, elle permet aux organisations de tirer la même valeur des données tout en réduisant les coûts de traitement, les redondances et les silos de données.

• Les entrepôts de données stockent des données nettoyées et traitées, tandis que les data lakes hébergent des données brutes dans leur format d’origine. 

• Les entrepôts de données disposent de moteurs analytiques et d’outils de reporting intégrés, tandis que les data lakes font appel à des outils externes pour le traitement.

• Les data lakes offrent un stockage plus économique, flexible et évolutif. Les entrepôts de données optimisent les performances des requêtes.

• Les entrepôts sont les mieux adaptés pour soutenir les efforts de business intelligence et d’analyse des données des utilisateurs professionnels. Les data lakes conviennent mieux aux opérations qui exigent de grands volumes de données dans différents formats, comme l’intelligence artificielle, le machine learning et la science des données. 

• Les entrepôts de données prennent en charge les transactions ACID, contrairement aux data lakes.

• Les data lakehouses et les entrepôts de données offrent des capacités d’analyse et d’interrogation similaires, mais les lakehouses offrent une meilleure prise en charge que les entrepôts des workloads d’IA et de ML complexes.

• Les lakehouses offrent un stockage moins coûteux, flexible et évolutif pour tous les types de données. Les entrepôts prennent principalement en charge les données structurées.

• Les entrepôts ont recours à l’ETL, tandis que les lakehouses peuvent employer l’ETL ou l’ELT.

• Ces derniers peuvent traiter des données par lots et en continu, tandis que les entrepôts travaillent par lots.  

• Les data lakes et les lakehouses peuvent prendre en charge d’importants volumes de données et diverses structures de données. Ils utilisent tous deux des systèmes de stockage de données similaires, généralement des systèmes de stockage d’objets dans le cloud. 

• Les data lakes n’appliquent pas de schémas aux données ingérées, alors que les data lakehouses ont la possibilité de le faire.

• Les data lakes et les data lakehouses peuvent prendre en charge les workloads d’IA et de ML, mais les lakehouses offrent une meilleure prise en charge de la BI et des analyses que les data lakes.

• Les lakehouses disposent d’outils d’analyse intégrés ou sont étroitement intégrés à des cadres analytiques. Les data lakes requièrent des outils externes pour le traitement des données.  

• Les lakehouses disposent de contrôles de gouvernance, d’intégrité et de qualité des données plus solides que les data lakes.  

• Les data lakehouses prennent en charge les transactions ACID ; contrairement aux data lakes.

• Ces derniers sont souvent conçus pour le traitement par lots et peuvent ne pas prendre en charge les données en continu. Les lakehouses peuvent prendre en charge les données par lot et en continu.