L’évolution des architectures Data : Le Datawarehouse et le Datalake

L’architecture en Datawarehouse, le moyen de centraliser les données pour faciliter la prise de décisions

Commençons par l’architecture Datawarehouse qui est apparue dans les années 1980 pour répondre aux besoins des entreprises en matière de stockage et consolidation des données. Il s’agit d’une technologie qui permet de rassembler des données (qu’on ramène 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'apparition du modèle Datawarehouse, les données étaient stockées dans des systèmes opérationnels appelés silos. Ceci avait pour principal défaut de ne pas donner la possibilité de les consolider et agréger pour obtenir des indicateurs et une vue d’ensemble.

Le Datawarehouse se base sur un modèle relationnel de données sous la forme de tables qui sont reliées entre elles. Ce modèle est géré par ce qu’on appelle les systèmes de gestion de bases de données relationnelles (SGBDR) qui permettent de structurer et appeler les données de façon efficace.

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.

Le SQL est utilisé pour interroger les tables, extraire des données, les manipuler et produire des rapports. On peut également agréger, filtrer, et analyser les données à travers plusieurs tables en les croisant entre elles.

Pour vulgariser, un Datawarehouse est une sorte de bibliothèque où les livres (données) sont classés sur des étagères selon des catégories bien définies (la fiction, la science, l’histoire). Chaque livre a sa place spécifique, avec une étiquette claire indiquant son contenu (schéma structuré).
Pour ajouter un nouveau livre, il faut suivre des règles strictes afin de s'assurer qu'il est bien catégorisé (processus ETL : extraction, transformation, chargement). Les personnes qui visitent cette bibliothèque (utilisateurs de la data) peuvent facilement trouver ce qu’ils recherchent grâce à sa bonne organisation.
Cependant si jamais ils ont besoin de classer un livre correctement ils devront fournir plus d’efforts.

L’utilisation des Datawarehouse offre plusieurs avantages pour les organisations :

• Structure de données rigide (schema-on-write) : Les données sont structurées et modélisées avant leur ingestion, ce qui assure une organisation claire de la base de données.
• 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.

Ainsi le modèle Datawarehouse a été longtemps le modèle privilégié dans les organisations. Cependant, avec l’explosion des volumes de données et la diversité des sources, les Datawarehouses traditionnels ont montré leurs limites :

• Scalabilité : Difficilement extensible à des volumes de données massifs, 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.

L’évolution vers le Datalake afin de répondre aux nouvelles exigences des organisations

Pour répondre aux limites du Datawarehouse traditionnel, une nouvelle approche a vu le jour : le Datalake. Conçu pour gérer des volumes massifs de données provenant de sources variées, le Datalake offre une flexibilité et une évolutivité que le Datawarehouse traditionnel ne pouvait pas assurer. Là où le Datawarehouse exige une structuration rigide des données dès leur ingestion, 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 ce qui répond aux besoins modernes des entreprises confrontées à la diversité de données.

Le terme Datalake est introduit pour la première fois par James Dixon, CTO de Pentaho, en 2010. Il faut imaginer un Datalake comme un grand lac naturel.
L’eau représente les données, et elle peut provenir de différentes sources comme des rivières et des pluies (données structurées, semi-structurées, non structurées).
L’eau n’est ni triée ni purifiée avant d'arriver dans le lac, elle y est stockée telle quelle (aucun schéma préalable).
Quand on a besoin d’eau pour un usage spécifique, on doit la prélever et la traiter (appliquer un schéma à la lecture).
Ce lac peut contenir de grandes quantités d’eau à moindre coût mais trouver et préparer l’eau pour un usage particulier prend du temps et des efforts.

Ces espaces de stockage permettent de répondre aux nouveaux enjeux du big data. En effet, le volume de données est exponentiel, varié et également plus véloce grâce à de nouvelles technologies telles que des capteurs émettent des données en temps réel ce qui rend la structure des Datawarehouses inefficaces à l’heure du passage à l’échelle. Dans cette optique, Hadoop se présente comme une solution incontournable pour gérer l’infrastructure sous-jacente d’un Datalake.

La genèse du Datalake : Hadoop

Concrètement, Hadoop est une collection d’applications open sources permettant aux datasets volumineux d’être stockés via des clusters d’ordinateurs travaillant en parallèle. On parle ici de scaling horizontal. A contrario des data warehouses ayant une architecture de mise à l’échelle 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.

Dans Hadoop, 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). 

En plus du stockage, la force d’Hadoop réside dans sa capacité à réaliser des calculs dits distribués. 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 la solution de stockage horizontale définie, nous pouvons utiliser des solutions Not only SQL (NoSQL) afin de tirer pleinement profit de cette architecture. Les bases de données NoSQL sont définies comme étant des bases de données non relationnelles. En d’autres termes, ces dernières permettent de s’affranchir des contraintes techniques de l’indexation en tables des Datawarehouses. Dans Hadoop, la solution NoSQL par défaut est HBase.

D’autres solutions n’appartenant pas à Hadoop tels que MongoDB, Voldemort, CouchDB ou hypertables ont émergées 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 reposent sur la même distribution horizontale que HDFS.

L’architecture d’un Datalake offre plusieurs avantages aux organisations surtout grâce à l'utilisation de bases de données NoSQL qui permettent de tirer pleinement profit 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 couramment utilisé dans les environnements Big Data comme 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. Les différents types de stockage sont 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.

Utiliser des Datalakes n’est cependant pas sans risques. La complexité de ces solutions et du Big Data peuvent rendre ces solutions inefficaces si elles ne sont pas correctement exploitées ou administrées. Voici certaines limites de ce modèle :

• 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. Cela peut entraîner des inefficacités et des difficultés pour extraire des 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 : Le Datalake étant un référentiel de stockage massif de données brutes émanant de plusieurs sources, ces dernières ne respectent pas systématiquement l'anonymisation des données à caractère personnel. 

Aujourd'hui, les entreprises réalisent que le Datawarehouse et le Datalake ne sont pas mutuellement exclusifs. Au contraire, ils sont souvent utilisés ensemble dans des architectures hybrides connues sous le nom de Datalakehouse. Ces architectures combinent la rigueur des Datawarehouses pour l'analyse structurée avec la flexibilité et la scalabilité des Datalakes.

Le Datalakehouse : un mix 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 ingérées sous forme brute, comme dans un Datalake traditionnel. Ensuite, une couche de transformation permet de structurer les données selon les besoins, en appliquant des schémas et des modèles de données. C’est un modèle de gestion de données qui combine la flexibilité et l’évolutivité du Datalake avec la structure, la performance et la fiabilité 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.

Y’a-t-il une architecture qu’il faut absolument privilégier ?

Le data warehouse et le data lake sont deux paradigmes différents qui correspondent à des utilisations distinctes. Plutôt que de préférer une solution à une autre, la sélection de l’architecture se fera en fonction de paramètres tels que le volume de données en entrées, le type des données, la vélocité de collecte mais également de l'utilisation attendue de ces dernières.

Les data lake permettent de répondre à des enjeux analytiques plus importants et de tirer pleinement profit du big data. Cependant la complexité de ces dernières induit une spécialisation plus importante de la part des utilisateurs avec un coût de maintien de l'architecture assez conséquent. A contrario un data warehouse 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 à 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.

Ainsi le choix de l’architecture n’est donc pas anodin et aura un impact sur l’ensemble de la chaîne de valeur de la donnée. Il est crucial dans un projet SI d’avoir une vision claire sur la technologie à employer en connaissant les avantages et limitations de chacune de ces solutions afin d'exploiter au mieux les données à disposition.