Comparaison des architectures de base de données : data warehouse, data lake and data lakehouse
17 mai 2022
Ne ratez pas nos articles sur l'open source, le big data et les systèmes distribués, fréquence faible d’un email tous les deux mois.
Les architectures de base de données ont fait l’objet d’une innovation constante, évoluant avec l’apparition de nouveaux cas d’utilisation, de contraintes techniques et d’exigences. Parmi les trois structures de base de données que nous comparons, la première à apparaître a été les Data Warehouses, introduits dans les années 80 avec le support des systèmes de Online Analytical Processing (OLAP), aidant les organisations à faire face à l’augmentation des applications diverses dans les années 90 en centralisant et en soutenant les données historiques pour obtenir des analyses commerciales compétitives. Plus tard, au début des années 2000, les Data Lakes sont apparus, grâce aux innovations dans le domaine du cloud computing et du stockage, permettant de sauvegarder des quantités exorbitantes de données dans différents formats en vue d’une analyse future.
Aujourd’hui encore, les deux solutions restent populaires en fonction des différents besoins des entreprises. Par exemple, les data warehouses permettent des analyses d’entreprise très performantes et une gouvernance des données très fine. Cependant, ils manquent d’évolutivité à un prix abordable pour les pétaoctets de données. De l’autre côté, les data lakes permettent un débit élevé et une faible latence, mais ils posent des problèmes de gouvernance des données, ce qui conduit à des ” data swamps ” impossibles à gérer. En outre, les données sont considérées comme immuables, ce qui entraîne des efforts d’intégration supplémentaires.
C’est pourquoi nous pouvons constater que les écosystèmes modernes de data lake et de data warehouse convergent, chacun s’inspirant, empruntant des concepts et abordant des cas d’utilisation de l’autre. Dans ce paysage, nous voyons émerger une nouvelle architecture : le data lakehouse, qui tente de combiner les principaux avantages des deux architectures concurrentes, en offrant un stockage à faible coût accessible par plusieurs moteurs de traitement de données tels qu’Apache Spark, un accès brut aux données, une manipulation des données et une flexibilité supplémentaire. Passons en revue chacune d’entre elles en détail.
Méthodologie de la comparaison
Il existe de multiples indicateurs à prendre en compte lors du choix d’une architecture de base de données. Pour être plus complet, nous avons présélectionné un ensemble de préoccupations communes.
Voici la liste des métriques pour mesurer chaque architecture :
- Accessibilité
Capacité à démocratiser les données en permettant aux utilisateurs, qu’ils soient techniques ou non, d’accéder à des données cruciales si nécessaire. - Lineage
La connaissance de l’origine des données, de la façon dont elles sont modifiées et de leur évolution dans le temps permet de remonter à la source des erreurs. - Types de données
Types de données supportés. - Ingestion
Sources et méthodes d’ingestion de données. - Gouvernance & Sécurité
Capacité à établir des procédures garantissant que les données critiques sont gérées de manière formelle et sécurisée au sein de l’entreprise. - Scalabilité
Capacité à maintenir la disponibilité et le comportement lorsque des ressources supplémentaires sont demandées. - Upserts & purging
Possibilité de mettre à jour et de supprimer les données obsolètes. - Performance
Efficacité pour traiter plusieurs requêtes simultanément, tant en termes de débit que de latence. - Fiabilité
La cohérence et l’exactitude des données, nous tiendrons également compte de la disponibilité. - Applications
Les cas d’utilisation que l’architecture permet.
Qu’est-ce qu’un Data Warehouse (DW) ?
Un data warehouse est un système centralisé conçu pour stocker des données actuelles et historiques. Leur objectif est de fournir des données facilement accessibles pour des requêtes et des analyses avancées. La principale motivation de l’émergence des data warehouses reposait sur la résolution du problème des données incohérentes des SGBDR en transformant les données des systèmes opérationnels en systèmes d’aide au traitement analytique. Le data warehouse est considéré comme la principale source de vérité sur les opérations commerciales.
Une architecture de data warehouse classique (image ci-dessus) utilise l’extraction, la transformation et le chargement (ETL) pour le transit des données à travers trois couches différentes, à savoir le staging des données, le noyau de données et l’accès aux données. La première couche voit la transition du format des données brutes vers un ensemble entièrement transformé. Ensuite, le schéma en écriture (schema-on-write) des données est utilisé pour optimiser le modèle de données pour la consommation BI en amont. Enfin, la couche d’accès permet aux utilisateurs de récupérer les données traduites et organisées au moyen de requêtes SQL.
Les data warehouses alimentent les rapports, les tableaux de bord et les outils d’analyse en stockant les données de manière efficace. Ils minimisent les entrées et sorties (E/S), ce qui permet de fournir les résultats des requêtes plus rapidement et à plusieurs utilisateurs simultanément. En outre, des sous-ensembles du data warehouse, appelés data marts, peuvent être fournis pour répondre à des besoins analytiques spécialisés.
Passons en revue les entrepôts de données en fonction des indicateurs que nous avons sélectionnés :
- Accessibility
Permet aux utilisateurs finaux d’accéder facilement à toutes les données traitées dans une base de données centralisée via SQL. Le data warehouse fournit souvent des outils d’analyse et de visualisation des données avec de multiples fonctionnalités pour aider les utilisateurs non techniques à accéder facilement aux données. - Lineage
Accès uniquement aux données traitées. Il est difficile de remonter jusqu’à leur origine brute, car les utilisateurs finaux n’y ont pas accès. - Types de données
Support des données structurées, avec un support limité des données semi-structurées. - Ingestion
Exige des pipelines ETL pour transformer les données avant leur utilisation. Les data warehouses utilisent à la fois la couche de staging des données et la couche noyau pour le traitement par lots. La couche de staging stocke les données brutes provenant de différentes sources, telles que les systèmes transactionnels, les bases de données relationnelles et d’autres sources. La couche noyau intègre les données en les traduisant, en les normalisant, en les historicisant et en les déplaçant vers un stockage de données opérationnel. Ces données sont ensuite transférées dans le data warehouse, où elles sont organisées en groupes hiérarchiques appelés dimensions, facts et aggregate facts. Le processus schema-on-write est utilisé, optimisant les données pour des performances de requêtes rapides. Pour les données en continu (streaming), une solution alternative est la prise en charge du micro-batching pour collecter les données par petits incréments. - Governance & Security
Sécurité et gouvernance à granularité fine au niveau des lignes/colonnes pour les tables. - Scalability
Les data warehouses ont un couplage étroit entre le calcul et le stockage, ce qui rend la scalabilité verticale très coûteuse. De plus, les data warehouses on-premise obligent le client à payer pour la charge de pic des utilisateurs et des données sous gestion, puisqu’il doit acheter, déployer et maintenir tout le matériel et les logiciels. Il est important de noter que les nouveaux data warehouses virtualisés basés sur le cloud permettent le multi-clusters, le découplage du calcul et du stockage, ainsi que de meilleures options de mise à l’échelle. - Upserts & purging
Les data warehouses mettent en œuvre une politique de dimension à évolution lente (SDC). Les mises à jour ne se produisent qu’avec SCD1, sinon une nouvelle ligne est insérée avec les données de suivi. La purge est effectuée en manipulant la partition de la base de données. Les données valides sont migrées vers une nouvelle partition, puis la base de données bascule vers cette nouvelle partition. La purge est recommandée pour réduire le coût du stockage et améliorer les performances, sauf si des versions antérieures des données sont nécessaires à l’analyse. - Performance
Les data warehouses acceptent les requêtes SQL et sont capables d’optimiser tout ce qui se trouve sous le capot, y compris les formats de stockage propriétaires. - Reliability
Des données fiables et de haute qualité avec des transactions ACID. Les entrepôts de données sont conçus pour fonctionner avec les analyses SQL et la BI, avec des schémas, des indices et des capacités de mise en cache. En outre, ils permettent de remonter dans le temps et de créer des versions. - Applications
Applications BI et SQL facilement utilisables pour le support de l’analyse historique et des rapports automatisés afin d’éclairer la prise de décision dans tous les secteurs d’activité d’une organisation.
Par conséquent, les data warehouses excellent dans l’assurance de la qualité et de la cohérence des données ; ils permettent des analyses de données et une BI performantes grâce à leur conformité ACID.
Les limites des data warehouses commencent lorsqu’il est nécessaire d’utiliser des types de données variés comme le textuel, le streaming IoT ou le multimédia. De plus, l’essor du machine learning et de l’IA nécessite des calculs itératifs qui nécessitent un accès direct aux données brutes.
Qu’est-ce qu’un Data Lake (DL) ?
Les data lakes sont apparus grâce au lancement d’Hadoop, qui permet à plusieurs machines de travailler ensemble et de faire évoluer horizontalement les capacités de calcul et de stockage. En outre, Hadoop permet de “jeter” des données sans se soucier de leur structure. Cela fonctionne grâce à un processus de schéma en lecture (schema-on-read), dans lequel les données sont ingérées dans leur format brut et ne sont transformées que lorsqu’elles sont nécessaires à l’analyse, ce qui permet de prendre en charge les données semi-structurées et non structurées. Enfin, l’architecture des data lakes repose sur un catalogue de métadonnées (par exemple, Hive Metastore, Apache Glue). Sans le catalogue de métadonnées, les data lakes deviennent rapidement ingérables et dérivent en data swamps.
Plus tard, les services cloud, AWS étant le premier, ont introduit des capacités de découplage du calcul et du stockage, ce qui signifie qu’ils pouvaient évoluer indépendamment. En outre, de nombreuses mises à niveau ont été possibles grâce au fait que l’écosystème Hadoop est un logiciel libre. Cela inclut les cadres de big data (par exemple, Hortonworks, Cloudera, mapR) qui facilitent la gestion des composants Hadoop, ainsi que l’ajout de nouveaux outils open-source comme Apache Spark, qui a commencé à être utilisé comme moteur de traitement, permettant un ETL performant pour transformer les données brutes en données raffinées et structurées pour différents cas d’utilisation.
Néanmoins, les data lakes ont des difficultés à assurer la gestion des données, à garantir la qualité, la sécurité et la gouvernance des données. En outre, si vous avez besoin de requêtes SQL très performantes sur des pétaoctets de données et de renvoyer rapidement des résultats analytiques complexes, ou de l’utilisation d’outils de BI et de fonctionnalités telles que le renforcement des schémas de données et le versionnage, alors les data lakes ne suffisent pas. C’est pourquoi l’utilisation actuelle des data lakes a évolué vers une architecture à deux niveaux aux côtés des data warehouses.
Dans cette architecture à deux niveaux, les données structurées sont traditionnellement stockées au format brut dans le data lake, mais sont ensuite traitées et stockées au format tabulaire dans les data warehouses, comme nous pouvons le voir dans l’image ci-dessus. Les données stockées dans les data warehouses sont utilisées pour l’analyse de données et la Business Intelligence, tandis que les données semi-structurées et non structurées sont stockées dans le data lake et utilisées pour la Data Science et le Machine Learning.
Passons en revue l’architecture à deux niveaux avec les indicateurs présélectionnés :
- Accessibilité
Les analystes BI ont un accès limité aux data warehouses dans les architectures à deux niveaux, s’appuyant sur les data engineers pour structurer les données dans l’entrepôt. Enfin, les data lakes deviennent souvent des data swamps lorsque les métadonnées sont mal cataloguées, rendant ces données ingérables. - Lineage
Les données brutes sont accessibles par le biais des data lakes, mais souvent les analystes BI n’auront accès qu’au data warehouse où les ingénieurs chargent les données sélectionnées. - Ingestion
Les data lakes effectuent des ELT (Extract, Load, Transform), ce qui signifie qu’ils ne transforment pas les données avant de les charger, puisqu’ils ne définissent pas de schéma auquel les données doivent correspondre. Au lieu de cela, la transformation et le schéma sont vérifiés lorsqu’une requête est nécessaire. Il s’agit du processus mentionné précédemment comme une approche de schéma en lecture. - Gouvernance & Sécurité
Toutes les données sont stockées et gérées sous forme de fichiers. Cela ne permet pas un contrôle d’accès à granularité fine sur le contenu des fichiers, mais seulement un contrôle d’accès à granularité large. - Upserts & purging
Toute opération en langage de manipulation de données (DML) sur un data lake entraîne une modification du fichier. Un nouveau fichier est créé, et des opérations supplémentaires sur les métadonnées doivent être effectuées pour assurer le suivi des modifications. La gestion et la suppression des versions de fichiers est une tâche complexe dans un data lake. - Scalabilité
Grâce au découplage du calcul et du stockage, les data lakes peuvent évoluer de manière indépendante. Les data lakes basés sur le cloud offrent à la fois le stockage et le calcul, ce qui les rend très évolutifs par rapport aux data warehouses. En outre, les systèmes de fichiers distribués permettent d’augmenter la capacité de stockage. Du côté négatif, en raison de la nature de l’architecture à deux niveaux, les problèmes d’évolutivité des data warehouses se posent. En outre, les données sont constamment transformées et traitées vers les data warehouses, ce qui ajoute des coûts supplémentaires et la duplication des données à la fois dans les data lakes et les data warehouses. - Performance
Les data lakes ne peuvent pas égaler les performances des data warehouses, même avec des moteurs comme Spark. En outre, l’architecture à deux niveaux est très complexe pour les utilisateurs, car les données sont d’abord transférées dans des data lakes, puis dans des data warehouses, ce qui crée des complexités, des retards et de nouveaux modes de défaillance. Cela entraîne des problèmes de performance considérables par rapport aux data warehouses classiques. - Fiabilité
Les data lakes n’étant pas dotés d’une gouvernance fine et d’une conformité ACID, la cohérence des données peut poser problème. Ce problème se pose en particulier lorsqu’il y a plusieurs lecteurs et auteurs. Il y a aussi la complexité de l’inadéquation des schémas en raison de l’absence d’application des schémas dans un environnement qui repose sur des données par lots et en continu provenant de multiples sources hétérogènes. En outre, dans le cas d’une architecture à deux niveaux, une ingénierie continue est nécessaire pour ETL les données entre les data warehouses et les data lakes. Chaque transformation entraîne des risques de défaillance qui réduisent la qualité des données. Il en résulte également des données périmées dans le data warehouse, car le chargement des transformations depuis les data lakes peut prendre plusieurs jours. - Applications
Les applications ML & DS, grâce à des formats de données ouverts (tels que parquet et orc) et des moteurs comme Spark, sont directement accessibles à un large éventail d’autres moteurs d’analyse, tels que les systèmes de machine learning. Pour les applications de BI et les applications SQL à haute performance, il est nécessaire d’effectuer des pipelines ETL vers un data warehouse.
Par conséquent, les data lakes apportent des capacités efficaces en matière d’ouverture des données et de coût de stockage des données. En outre, ils conviennent aux algorithmes de machine learning et d’intelligence artificielle, grâce à leur support de divers cadres de traitement (permettant l’utilisation de bibliothèques python) et donnent accès à de grandes quantités de données brutes.
En revanche, l’architecture à deux niveaux entraîne des pipelines ETL complexes en raison du déplacement, du traitement et de la duplication importants des données vers les data warehouses. L’opérationnalisation et la gouvernance de cette architecture de données deviennent également un défi en raison du coût et de la complexité. Tout cela se traduit par des data swapms et des données périmées.
Qu’est-ce qu’un Data Lakehouse ?
En 2019, Databricks a publié le document Delta Lake : High-Performance ACID Table Storage over Cloud Object Stores, présentant le concept de data lakehouse et Delta Tables. Ils avaient l’intention d’ajouter une couche de stockage aux côtés d’Apache Spark, permettant les transactions et appliquant le schéma en écriture dans un stockage d’objets. De leur côté, Netflix et Uber avaient mis en place des capacités similaires par le biais d’Apache Iceberg et Apache Hudi, respectivement. L’utilisation d’entrepôts de données deviendrait ainsi superflue.
Dans son architecture, un data lakehouse vise à fournir des capacités de gouvernance des données à un data lake tout en réduisant les coûts opérationnels de l’architecture à deux niveaux susmentionnée. Pour y parvenir, deux caractéristiques sont essentielles. La première est l’utilisation de formats de fichiers ouverts, tels que Parquet et ORC, pour faciliter les statistiques essentielles et permettre des schémas de données prédéfinis. La seconde est le système de stockage de données à faible coût d’un data lake, car le découplage du calcul et du stockage permettra d’utiliser plusieurs moteurs de traitement.
Mais cela ne permet pas de disposer des capacités des data warahouses telles que la gestion approfondie des données, le versionnage ou l’application des schémas. Des transactions ACID sont nécessaires, ce qui était auparavant impossible dans un système distribué où tout se trouve sur un stockage objet.
L’architecture Lakehouse (image ci-dessus) adopte ce paradigme ACID en exploitant une couche de métadonnées (par exemple, le métastore Hive, HDFS) et, plus précisément, un cadre d’abstraction de stockage (Apache Iceberg, Apache Hudi, Delta Tables). Ces formats de table ouverts permettront à la couche de métadonnées d’enregistrer les changements comme des transactions tout en gérant la concurrence.
Plongeons dans chaque point de comparaison :
- Accessibilité
Permet d’accéder directement aux fichiers avec SQL, R, Python, Spark et d’autres langages. Avec les lakehouses basés sur Iceberg et Delta, vous pouvez facilement interroger tous les types de données par le biais de différentes plateformes, ou travailler sur les données brutes à l’aide d’un notebook. - Lineage
L’architecture permet d’utiliser une API ouverte afin d’offrir un accès direct aux données brutes sans avoir à recourir à des moteurs propriétaires et à un verrouillage des fournisseurs. - Types de données
Support des données structurées, semi-structurées et non structurées. - Ingestion
L’ingestion est gérée de manière similaire à un data lake via ELT, avec la complexité supplémentaire de la mise à jour de la couche de métadonnées via Spark ou Hive. Sur le plan positif, le data lakehouse permet d’unifier les lots et les capacités de traitement des données en continu. Par exemple, Delta Lake, avec le streaming structuré, permet d’analyser des données en continu et des données historiques, ou différentes sources de données ensemble à grande vitesse. - Gouvernance & Sécurité
Les propriétés ACID de Lakehouse permettent de faire respecter les schémas, de réaliser des audits et d’assurer une gouvernance fine des données, car elles fournissent un RBAC complet pour les clusters, les pools, les tâches et les tables. De plus, de nouveaux outils tels qu’Apache Nessie et Dremio Arctic (par le biais d’Apache Iceberg) offrent des fonctionnalités de gestion des données de type git sur un lakehouse. - Scalabilité
Ils sont assez évolutifs grâce au traitement et au stockage découplés, sans qu’il soit nécessaire de charger les données dans un warehouse pour des capacités supplémentaires de BI et de gouvernance. Ils offrent également une API de métadonnées évolutive. Par exemple, avec Iceberg, lors de la lecture à l’aide d’un snapshot, l’API Iceberg effectuera le filtrage et obtiendra les données nécessaires à l’analyse. Cela peut permettre de planifier l’effort de lecture sans affecter les données. - Upserts & purging
Un data lakehouse dispose d’un système intégré de suivi des transactions, stocké sous forme de métadonnées et de journal des transactions. Lors des opérations DML, un nouveau fichier est créé et suivi par le magasin de métadonnées. La purge peut être effectuée en analysant les métadonnées et en supprimant les versions inactives des fichiers. - Performance
Fournit des performances SQL élevées au-dessus d’un stockage d’objets. De plus, Data Lakehouse optimise la taille des objets sans affecter les requêtes en cours. - Fiabilité
Des données fiables et de haute qualité grâce aux transactions ACID et à la réduction des tâches ETL. Les propriétés ACID sont obtenues grâce au contrôle optimisé de la concurrence et les niveaux d’isolation sérialisables garantissent que les lecteurs ne travaillent pas avec des données incohérentes. - Applications
Il permet de réaliser des applications de BI, SQL, ainsi que des applications de Machine Learning et de Data Science. En outre, il permet d’accéder aux données brutes dans un stockage d’objets directement via l’API DataFrames (avec Delta Tables). Cette architecture fonctionne également bien avec les principaux systèmes de machine learning comme TensorFlow, PyTorch et XGBoost (avec Delta Tables, Iceberg travaille sur ces fonctionnalités).
Cette architecture permet aux capacités clés du data warehouse d’exister sur un data lake. En outre, les solutions de data lakehouse mettent en œuvre d’autres optimisations sur la couche moteur (par le biais de Spark ou de Flink) afin d’optimiser les performances des requêtes, telles que la mise en cache, les structures de données auxiliaires (indices et statistiques) et les optimisations de la disposition des données. Par rapport aux data lakes, elles réduisent la redondance et la stagnation des données grâce à un stockage de données unique et polyvalent, elles réduisent ce que l’on appelle les data swamps car les données sont désormais versionnées, et elles ajoutent des couches de gouvernance et de sécurité par-dessus le marché.
Du côté négatif, l’architecture des data lakehouse est relativement nouvelle et immature, et certaines fonctionnalités ajoutées sont encore sur une liste de choses à faire. Il y a également des plaintes sur différents sujets, comme la dépendance de Delta Lake sur l’interrogation uniquement par le biais de tables Delta Lake et non de tables externes ou les complexités de l’utilisation des notebooks par rapport à l’interface simple des entrepôts de données modernes.
Quelle architecture utiliser ?
La convergence des data warehouses et des lakes les uns vers les autres a donné naissance à la nouvelle architecture lakehouse, mais résumons comment chacun se positionne par rapport au data lakehouse :
- Si vous avez besoin d’une analyse d’entreprise très performante tout en ayant accès à une gouvernance des données très fine, les data warehouses sont votre choix. Les performances élevées d’un warehouse sont inégalées par les autres. Néanmoins, leur mise à l’échelle est difficile et coûteuse et ils n’ont pas la flexibilité nécessaire pour traiter efficacement tous les types de données. Si un débit élevé de transactions et différents types de données sont une exigence, l’architecture lakehouse peut être une solution. Le principal argument contre cette transition est la migration complexe de ces différentes architectures.
- Si vous souhaitez faire évoluer et traiter des pétaoctets de données à un prix abordable, disposer de stockage tout en préservant le calcul et fournir un débit élevé (par opposition à un accès à faible latence), les data lakes sont votre choix. En revanche, les lacs de données n’offrent pas de contrôle d’accès à granularité fine ni d’analyse d’entreprise à haute performance. Si vous en avez besoin, une transition vers les data lakehouse peut être possible et plus facile à réaliser, car ces architectures reposent sur une technologie distribuée similaire.
Nous souhaitons également mentionner brièvement les data warehouses modernes dans le cloud (tels que Snowflakes, Clickhouse, Azure Synapse), car ils offrent des solutions comparables aux lakehouses. Néanmoins, ils sont légèrement différents, car ils se comportent davantage comme un data warehouse essayant d’adopter les propriétés d’un data lake comme le calcul et le stockage découplés.
