L’évolution des architectures Data : Le Datawarehouse et le Datalake
Les architectures de données ne cessent d’évoluer afin de répondre aux exigences des organisations.
Le passage du Datawarehouse au Datalake puis au Datalakehouse reflète bien cette transformation dans les modes de stockage et de traitement des données. Dans cet article nous examinerons ces différentes approches ainsi que les raisons qui ont poussé certaines organisations à adopter des architectures modernes tandis que d’autres préfèrent rester fidèles à des architectures plus traditionnelles.
L’architecture en Datawarehouse, le moyen de centraliser les données pour faciliter la prise de décisions
L’architecture Datawarehouse est apparue dans les années 1980 pour répondre aux besoins des organisations en matière de stockage et de consolidation des données. Il s’agit d’une technologie qui permet de rassembler des données (qu’on collecte de différentes sources de données) de façon structurée. Le but est de centraliser les données afin de pouvoir réaliser des analyses avancées. Avant l'émergence du modèle Datawarehouse, les données étaient stockées dans des systèmes opérationnels appelés silos. Le principal inconvénient de cette approche était l'incapacité de consolider et d'agréger les données pour obtenir des indicateurs et une vue d'ensemble.
Les données dans un Datawarehouse sont stockées sous forme de tables. Chaque table représente une entité spécifique (par exemple, les ventes, les clients, les produits) et est composée de lignes (enregistrements) et de colonnes (attributs). Les tables sont reliées entre elles par des clés (clés primaires et clés étrangères) qui définissent les relations entre les différentes entités. Par exemple, une table des ventes pourrait être liée à une table des clients via un ID client. Cette structure est gérée par des Systèmes de Gestion de Bases de Données Relationnelles (SGBDR), qui permettent d'organiser, structurer et récupérer efficacement les données.
Le SQL est utilisé pour interroger les tables, extraire des données, les manipuler et produire des rapports. Il permet également d'agréger, de filtrer et d'analyser les données à travers plusieurs tables en les croisant entre elles.
Pour illustrer, un Datawarehouse peut être comparé à une bibliothèque où les livres (données) sont rangés sur des étagères selon des catégories bien définies (comme la fiction, la science, l’histoire). Chaque livre a une place précise, avec une étiquette indiquant son contenu (schéma structuré). Pour ajouter un nouveau livre, il est nécessaire de suivre des règles strictes pour garantir qu’il soit correctement classé (processus ETL : extraction, transformation, chargement). Les visiteurs de la bibliothèque (utilisateurs des données) peuvent facilement trouver ce qu’ils cherchent grâce à cette organisation soignée. Cependant, ce système d'archivage impose un effort supplémentaire pour classer chaque nouveau livre.
L’utilisation des Datawarehouse offre plusieurs avantages pour les organisations :
- Structure de données rigide (schema-on-write) : Organisation claire de la base de données car les données sont structurées et modélisées avant leur ingestion.
- Qualité des données : Cette structuration préalable assure une haute qualité et cohérence des données facilitant leur analyse.
- Historisation : Les Datawarehouses permettent de stocker de grandes quantités de données historiques, offrant ainsi la possibilité d’analyser l’évolution des tendances et aussi conserver des archives.
- Performances optimisées : Conçus pour exécuter des requêtes complexes rapidement, ils utilisent des techniques comme l'indexation et les vues matérialisées.
- Fiabilité (ACID) : Les propriétés ACID garantissent des transactions fiables et cohérentes, essentielles pour maintenir l'intégrité des données
- Facilité d'utilisation : Le SQL est un langage standard et largement utilisé par les profils data, ce qui facilite l'interrogation et l'analyse des données.
Le modèle de Datawarehouse a longtemps été le modèle de référence dans les organisations. Cependant, face à l'explosion des volumes de données et à la diversité croissante des sources, les Datawarehouses traditionnels ont montré leurs limites :
- Scalabilité : Difficilement extensible à des quantités de données massives, surtout lorsque les données sont semi-structurées ou non structurées.
- Coût : Le stockage de grandes quantités de données dans un Datawarehouse est coûteux, particulièrement pour des données qui ne sont pas fréquemment interrogées.
- Flexibilité : La nécessité de définir des schémas à l'avance (schema-on-write) limite la capacité à intégrer rapidement de nouvelles sources de données.
Malgré ses nombreux atouts, cette architecture présente des limites techniques et n’est pas adaptée à tous les contextes, notamment en termes de scalabilité et de flexibilité. Elle reste néanmoins une solution robuste dans des environnements où ces contraintes sont moins critiques.
L’évolution vers le Datalake afin de répondre aux nouvelles exigences des organisations
Pour répondre aux limites du Datawarehouse, une nouvelle approche a vu le jour : le Datalake. Conçu pour gérer des volumes massifs de données provenant de diverses sources, il se démarque des modes stockages traditionnels par sa flexibilité et son évolutivité. Là où le Datawarehouse possède une structure rigide, le Datalake permet de stocker les données dans leur format brut, sans avoir à les transformer immédiatement. Cette approche permet d’ingérer rapidement des données de toutes natures, répondant ainsi aux nouveaux besoins des organisations en matière de collecte.
Un Datalake est comme un vaste lac naturel. L'eau représente les données, qui proviennent de diverses sources, telles que des rivières et des pluies (données structurées, semi-structurées et non structurées). L'eau n'est ni filtrée ni purifiée avant d'atteindre le lac ; elle y est simplement stockée dans son état brut, sans schéma prédéfini. Lorsqu'on a besoin d'eau pour un usage spécifique, il faut la prélever et la traiter (appliquer un schéma lors de la lecture). Ce lac peut contenir de grandes quantités d'eau à faible coût, mais l'extraction et la préparation de l'eau pour un usage particulier nécessitent du temps et des efforts.
Ces espaces de stockage répondent aux nouveaux défis du big data. Avec l’essor de technologies comme les capteurs générant des données en temps réel, le volume de données devient exponentiel, plus diversifié et rapide. Dans ce contexte, Hadoop s’impose comme une solution incontournable pour gérer l’infrastructure d’un Datalake.
La genèse du Datalake : Hadoop
Hadoop est une suite d’applications open source conçue pour traiter et stocker de grandes quantités de données via des clusters d’ordinateurs travaillant en parallèle. On parle ici de scaling horizontal. A contrario des Datawarehouses ayant une architecture de scaling verticale (centraliser dans un unique ordinateur tout le référentiel de données, impliquant qu’un nombre croissant d’espace occupé nécessitera l’ajout d’espace de stockage et de ram pour pouvoir fonctionner), Hadoop se base sur un processus permettant la parallélisation du stockage.
On définit un cluster comme étant un ensemble d’ordinateurs (appelés nœuds) mis en réseau pour accomplir des tâches en parallèle. Les clusters Hadoop ont été conçus pour permettre de réaliser des tâches liées au traitement, stockage et analyse de datasets dans un contexte de big data. Le fonctionnement de ces derniers repose sur le paradigme maître esclave. Les masters nodes sont les nœuds principaux qui gèrent et coordonnent les tâches et ressources dans un cluster Hadoop tandis que les nœuds esclaves exécutent les tâches assignées par les masters nodes et stockent les données.
Cette division, collecte et traitement dans Hadoop est rendue possible par les trois composants principaux de Hadoop : Hadoop Distributed File System (HDFS) (stockage des données), MapReduce Engine (permet la réalisation de calculs parallèles) et Yet Another Resource Negociator (YARN) (système de gestion des ressources).
La force d’Hadoop réside dans sa capacité à réaliser des calculs dits distribués en plus du stockage. Cette distribution des calculs permet d’avoir des gains de puissance considérables et de traiter des volumes de données pouvant dépasser les pétaoctets.
Une fois le stockage horizontal configuré, des solutions NoSQL (Not Only SQL) peuvent être déployées pour tirer pleinement parti de cette architecture. Les bases de données NoSQL sont définies comme non relationnelles. En d’autres termes, ces dernières permettent de s’affranchir des contraintes techniques liées à l'indexation sous forme de tables des Datawarehouses. Dans Hadoop, la solution NoSQL par défaut est HBase
D’autres solutions telles que MongoDB, Voldemort, CouchDB ou Hypertables ont émergé depuis le début des années 2000. Principalement développées par des applications telles que linkedin, facebook ou encore google, elles permettent de répondre à des exigences de big data associées à ces plateformes. Bien que chacune des solutions aient leurs spécificités, elles partagent un modèle de distribution horizontale similaire à celui de HDFS.
L'architecture d'un Datalake présente de nombreux avantages pour les organisations, notamment grâce à l'utilisation de bases de données NoSQL qui tirent pleinement parti du Big Data :
- Disponibilité continue et réplication des données : Dans une configuration de scaling horizontal, les données sont dupliquées entre les différents nœuds, rendant l’architecture moins propice à la perte de données.
- Schema-on-read : Le schema-on-read est une approche de gestion des données où le schéma est appliqué au moment de la lecture plutôt qu'au moment de l'écriture. Cela permet de stocker des données non structurées ou semi-structurées sans définition préalable du schéma, offrant plus de flexibilité pour l'analyse ultérieure. C’est ce schéma qui est appliqué dans les environnements Big Data tels que Hadoop.
- Différents types de stockages : Il existe plusieurs types de bases de données NoSQL. Les types de stockage sont choisis en fonction de cas spécifiques comme la gestion du big data en temps réel ou la gestion des sessions utilisateurs. Il existe le stockage clé-valeur, le stockage de documents, le stockage en colonnes larges ou le stockage en graphes.
- Adapté aux nouvelles technologies : En utilisant une base de données de big data, nous pouvons utiliser des technologies plus avancées notamment autour du machine learning ou du deep learning. Par exemple, OpenAI utilise des bases des volumes de données estimées à plusieurs pétaoctets afin de pouvoir développer des modèles d’IA génératives.
Leur utilisation présente cependant certains risques. La complexité de ces solutions, associée aux défis du Big Data, peut rendre ces systèmes inefficaces s'ils ne sont pas correctement exploités ou administrés :
- Data Swamp : dépôt de données où les informations sont stockées sans organisation ni gestion adéquate, rendant leur utilisation difficile. Contrairement à un data lake bien structuré, un data swamp contient des données non nettoyées et non cataloguées, ce qui engendre des inefficacités et complique l'extraction d'informations utiles.
- Performance des requêtes : Les performances des requêtes peuvent être impactées si le volume de données est trop important, si les données sont semi ou non structurées ou encore si l’indexation et l’optimisation ne sont pas correctement réalisées.
- Conformité RGPD : Étant donné que le Datalake est un réservoir de stockage massif de données brutes provenant de diverses sources, ces données ne respectent pas toujours l'anonymisation des informations personnelles.
Les organisations prennent conscience aujourd'hui que le Datawarehouse et le Datalake ne sont pas incompatibles. Ils sont en effet fréquemment combinés dans des architectures hybrides appelées Datalakehouse. Ces architectures associent la structure rigoureuse des Datawarehouses pour l'analyse des données structurées à la souplesse et la capacité d’évolution des Datalakes.
Le Datalakehouse : une combinaison des deux architectures
Le Datalakehouse fonctionne en superposant une couche de gestion des données structurées (caractéristique du Datawarehouse) sur un Datalake. Les données sont d'abord collectées sous leur forme brute, comme dans un Datalake classique. Une couche de transformation est ensuite appliquée pour structurer les données en fonction des besoins, en utilisant des schémas et des modèles de données. C’est un modèle de gestion des données qui combine la flexibilité du Datalake et la structure du Datawarehouse.
Il est caractérisé par :
- Schema-on-read et schema-on-write : Il combine la flexibilité du "schema-on-read" des Datalakes avec la rigueur du "schema-on-write" des Datawarehouses. Cela permet d'ingérer rapidement des données brutes tout en offrant la possibilité de structurer ces données pour des analyses plus formelles.
- Support pour les transactions ACID : Contrairement aux Datalakes, le Datalakehouse peut garantir des transactions fiables et cohérentes grâce au support des propriétés ACID, ce qui est essentiel pour maintenir l'intégrité des données.
- Performances optimisées : Le Datalakehouse utilise des techniques avancées comme le stockage en colonnes, l'indexation, et les formats de fichiers optimisés pour offrir des performances élevées, même pour des requêtes complexes sur des volumes massifs de données.
Bien que cette approche hybride combine les avantages des deux solutions, la gestion de la performance, des transactions ACID et de l'intégrité des données dans un environnement aussi dynamique peut également entraîner des coûts importants. Pour mettre en place et maintenir cette solution, l’organisation devra investir dans des équipements adéquats, des logiciels spécialisés et des compétences techniques.
Doit on privilégier une architecture ?
Le Datawarehouse et le Datalake représentent deux approches distinctes, chacune adaptée à des besoins spécifiques. Le choix de l'architecture ne devrait pas se limiter à privilégier l’une au détriment de l’autre, mais plutôt s'appuyer sur des critères comme le volume, le type de données, la vitesse de collecte, ainsi que l’usage qui en sera fait.
Les Datalakes répondent aux exigences analytiques plus complexes et permettent de tirer pleinement parti du Big Data. Cependant, leur complexité requiert une spécialisation accrue des utilisateurs et entraîne des coûts de maintenance élevés pour l'architecture. Un Datawarehouse permettra de répondre à des besoins analytiques plus simples pour des données structurées mais s'inscrit plus facilement dans un SI traditionnel. Il permettra également à un vaste public n’ayant pas de compétences en data de pouvoir manipuler les données en base. Des solutions hybrides permettant de combiner les avantages de la structure du Datawarehouse et des possibilités du Datalake ont vu le jour comme le Datalakehouse.
Le choix de l’architecture n’est donc pas anodin. Il influencera non seulement l’ensemble de la chaîne de valeur de la donnée mais aussi l’efficacité des systèmes d’informations qui en dépendent. Dans le cadre d'un projet SI, il est fondamental d'avoir une compréhension précise des technologies à utiliser, en tenant compte des avantages et des contraintes de chacune, afin de traiter de manière optimale les données à disposition. Cette qualité du traitement permettra par la suite de transformer ces données en un actif stratégique pour l’organisation, ouvrant ainsi de nouvelles opportunités pour la création de valeur.
Le sujet vous intéresse ? Nos experts vous répondent
Avec la création d’un pôle spécialisé en Data/IA, mc2i se positionne comme un partenaire de confiance en Data Transfo au service de la démocratisation de la donnée et d’un usage responsable.