Data Lakehouse : les subtiles nuances qui divisent les éditeurs
Si le principe de faire converger un lac et un entrepôt de données a séduit les éditeurs et les fournisseurs de cloud, les interprétations du concept de Data Lakehouse sont désormais plus nombreuses qu’il n’y paraît.
Databricks l’avoue : le concept de Data Lakehouse formulé en 2020 résulte en premier lieu d’un positionnement marketing.
« Au lancement de Databricks, nous appelions cela l’architecture analytique unifiée », rappelle Nicolas Maillard, AVP Field Engineering, Solution Architect chez Databricks. « Le mot Lakehouse sonnait bien et résumait notre pensée. C’est du marketing, mais du marketing qui a bien accroché ».
Le néologisme n’est toutefois pas vide de sens. Cette contraction de Data Lake et de Data Warehouse intime que la plateforme de traitement de données de Databricks est un lac de données capable de supporter des traitements ACID, donc d’assurer l’atomicité, la cohérence, l’isolation et la durabilité des données.
Dit autrement, un data lake est historiquement un dépôt de données (data store) NoSQL. Avec un Lakehouse, il s’agit alors de pouvoir interroger des données structurées et non structurées hébergées à l’aide d’une technologie par essence NoSQL. Mais l’histoire ne s’arrête pas là. Pour Databricks, un Data Lakehouse doit surtout prendre en charge simultanément l’ensemble des cas d’usage des deux paradigmes qu’il concatène tout en minimisant les déplacements de données.
« Notre vision était relativement simple, et c’est un peu de la même manière que les fondateurs de Databricks ont imaginé Apache Spark », indique Nicolas Maillard. « Il fallait fournir un système informatique complet capable de prendre en charge l’ensemble des traitements qui servent à définir une application data ».
À l’origine, Apache Spark a été ainsi pensé pour permettre aux ingénieurs et aux data scientists effectuer différentes transformations de données en Scala ou en Python (et maintenant SQL) dans un seul environnement.
Par essence, le Lakehouse étend ce concept à l’ensemble des types de traitements (IA et machine learning, BI, analytique, etc.) des modèles de données et des techniques analytiques tout en conservant les garanties ACID apportées historiquement par un entrepôt de données. En conséquence, Nicolas Maillard estime qu’un Lakehouse doit favoriser la collaboration entre les experts de la donnée et les métiers.
« Il faut que le Lakehouse soit ouvert à différentes couches et standards et qu’il soit multicloud ».
Nicolas MaillardAVP Field Engineering, Solution Architect, Databricks
Databricks ajoute deux autres critères. « Il y a deux autres fondamentaux du Lakehouse selon nous », avance le responsable. « Il faut que le Lakehouse soit ouvert à différentes couches et standards et qu’il soit multicloud. J’ai besoin que les différentes instances soient les mêmes à isopérimètre dans les différents clouds, qu’elles soient aussi rapides et qu’elles puissent se rencontrer ».
Ainsi, le Data Lakehouse de Databricks supportent différents formats de données et formats de table open source.
Le succès évident d’un concept marketing
Le concept s’est imposé sur le marché en 2022. « Databricks est le principal promoteur du concept de Lakehouse », confirme Gartner dans son Magic Quadrant 2022, consacré aux systèmes de gestion de base de données en cloud, publié le 13 décembre 2022. Mais l’éditeur n’est plus le seul à utiliser l’appellation. « Comme le concept de Lakehouse a gagné en popularité, d’autres fournisseurs se sont empressés de développer leurs propres versions de cette architecture », signalent les analystes. AWS, Google Cloud, Teradata, Oracle, Dremio, Snowflake ou encore Cloudera se sont emparés de la terminologie. Certains, tels Teradata, Oracle, GCP et Cloudera ont créé de nouvelles offres. D’autres considèrent comme Snowflake que leur produit répond d’ores et déjà à la plupart des critères formulés par Databricks.
Ce n’est pas forcément de gaité de cœur : devoir utiliser la terminologie du concurrent est sûrement vexant.
« Même si je n’aime pas le terme, le concept de Lakehouse est important ».
Stephen BrobstCTO, Teradata
Preuve en est, Stephan Brobst, CTO de Teradata n’aime pas le terme Lakehouse. Il s’est fait une raison. « Même si je n’aime pas le terme, le concept de Lakehouse est important », avance-t-il auprès du MagIT. « Il devrait y avoir peu de friction en passant du lac de données au produit de données ».
Selon Cécil Bove, Directeur Sales Engineering chez Snowflake, il s’agit là d’une évolution naturelle.
« Le Data Warehouse d’entreprise, historiquement déployé sur site, évoluait tous les trois à cinq ans en fonction des besoins estimés de stockage et de calcul. Les données stockées étaient maîtrisées : les entreprises connaissaient la volumétrie et savaient ce qu’elles voulaient en faire », résume-t-il.
« Puis sont apparus les data lake. Comme les entreprises généraient de plus en plus de données, mais qu’elles ne savaient pas ce qu’elles voulaient en faire immédiatement, car les données n’étaient pas structurées de la même manière, elles les ont mis de côté dans ces lacs », poursuit-il. « Ensuite est arrivé le cloud public qui offre véritablement cette capacité à stocker les données de manière élastique pour les exploiter plus tard ».
« La notion de Lakehouse vise à gommer les différences entre le data warehouse d’entreprise et le data lake. L’on va pouvoir stocker au même endroit et exploiter de la même manière des données structurées, semi-structurées et non structurées », confirme le responsable chez Snowflake.
Deux grandes familles de Data Lakehouse
Mais Stephan Brobst indique qu’il existe des différences clés entre les différents produits disponibles sur le marché.
« Cette notion d’architecture unifiée est importante, et pourtant nous devons reconnaître qu’il y a différentes technologies, différents déploiements ».
Un observateur taquin pourrait ainsi dire qu’il y a d’un côté des Lakehouse et de l’autre des « Houselake », en fonction de la nature relationnelle ou non du système de gestion de données sous-jacent.
Bien que les éditeurs vantent leurs capacités à traiter pratiquement tous les types de données, ces origines technologiques se font encore sentir, observe Gartner.
« Les Data Lakehouse des éditeurs sont émergents ».
Gartner
« Les Data Lakehouse des éditeurs sont émergents », indique le cabinet d’analystes dans son Hype Cycle 2022 consacré à la gestion de données, publié à la fin du mois de juin 2022. « Certaines plateformes sont performantes pour les cas d’usage liés aux lacs de données, mais ne prennent pas en charge l’ensemble des fonctions de cohérence des transactions ou de gestion robuste des charges de travail que les responsables des données et de l’analyse attendent de leurs entrepôts de données », signalent les analystes. « D’autres plateformes de type “lakehouse” sont performantes en matière de datawarehousing, mais ne prennent pas en charge les modèles de données étendus et les fonctions de data science ou de data engineering d’un data lake ».
Stephen Brosbt pense de son côté que le modèle de traitement de Databricks reposant sur le raffinage des données en trois stades (bronze, la donnée brute, argent, correspondant aux données filtrées et augmentées, puis or pour les données de référence) « n’est pas efficient ». Certains ajoutent un quatrième niveau pour évoquer la couche sémantique. « Je ne pense pas que vous avez besoin de quatre copies des données. Les données brutes et les données de référence devraient être conservées précieusement. La couche “silver” devrait être non persistante, mais la couche sémantique peut être physique ou virtualisée suivant les besoins », explique-t-il.
Différentes modalités des approches multicloud et hybrides
Au-delà des différences en matière de fonctionnalités analytiques et de stockage, il faut également distinguer les approches technico-commerciales. De manière générale, des acteurs tels que Databricks, Snowflake ou encore Google Cloud ont encouragé leurs clients à « centraliser » leurs données dans le cloud. C’est la position défendue depuis trois ans par Ali Ghodsi, CEO de Databricks, auprès du MagIT. Benoît Dageville, PDG de Snowflake tient peu ou prou le même discours considérant que même s’il faut séparer le stockage du calcul, idéalement tout cela doit se produire dans le cloud pour des raisons de performance et de coût. Derrière cette position, il faut comprendre que ces éditeurs préfèrent des clients « captifs » de leurs solutions et du cloud sans toutefois faire une croix sur les pistes de portabilité pour ceux qui voudraient un jour les quitter. D’ailleurs, les éditeurs vantent régulièrement leurs capacités à supporter un grand nombre de formats de tables et de données open source (Apache Iceberg, Hudi, Delta Lake, Parquet, Avro, ORC).
Ce n’est pas forcément la position des éditeurs traditionnels tels Teradata et Cloudera qui tentent de convaincre que leurs produits ne sont plus (forcément) verrouillés et chers. Leurs clients maintiennent des architectures de traitement de données hybrides, ce qui oblige ces fournisseurs à penser des solutions adaptées à cette réalité.
« Nous sommes en train de changer notre positionnement », affirme Steve McMillan, CEO de Teradata. « Nous voulons proposer une plateforme analytique ouverte et multicloud. Notre force, c’est notre moteur de requêtes et nous pouvons rapprocher ce moteur des données, peu importe où elles sont stockées au lieu de les envoyer [systématiquement] dans le cloud », ajoute-t-il.
Ironiquement, les deux approches s’appuient sur la même technologie : le stockage objet. C’est plus particulièrement le protocole S3 qui permet non seulement de réduire les coûts de stockage, mais également de favoriser l’analyse de données enregistrées dans différents formats. Ces récipients peuvent être hébergés dans le cloud, et sur site, dans les instances compatibles S3. De son côté, Snowflake a mis en place des partenariats avec les fournisseurs de solutions de stockage on premise afin d’extraire les données placées dans des tables externes et les traiter dans le cloud. Databricks étudie une solution similaire, mais Nicolas Maillard considère que les cas d’usage d’une telle fonction sont peu matures.
Data Lakehouse vs Logical Data Warehouse
De fait, peu d’entreprises disposent d’une seule plateforme qui couvre tous leurs besoins analytiques. La très grande majorité des grands groupes ont bâti et bâtissent une architecture constituée de plusieurs produits en plaçant au centre leurs entrepôts et leurs lacs de données.
La plupart d’entre elles se retrouvent à gérer des sources de données disparates. Toutefois, elles veulent pouvoir corréler ou analyser les données à la manière d’un Lakehouse. Dans le monde du datawarehousing, cette pratique est identifiée sous le nom de Logical Data Warehouse (LDW).
Le concept d’entrepôt de données logique a été défini en 2009 par Mark Beyer, analyste chez Gartner. Un LDW est « une architecture de gestion des données dédiée à l’analytique qui combine les points forts des entrepôts traditionnels avec des stratégies alternatives de gestion et d’accès aux données ». En clair, un data warehouse logique est une « une architecture de consolidation et de virtualisation des données de plusieurs systèmes analytiques ». Elle permet d’intégrer les données en provenance de différentes sources de manière centralisée dans un référentiel logique plutôt qu’un emplacement physique à des fins analytiques. Les outils de virtualisation tels ceux de Denodo ou de TIBCO, peuvent soutenir cette approche.
Dans son Hype Cycle 2022, Gartner considère qu’un Lakehouse est un « sous-ensemble du LDW construit de manière opportuniste ». Un entrepôt de données logique servirait un plus grand nombre de cas d’usage analytique, jusqu’à preuve du contraire. « Le LDW reste une pratique mature et optimale », conseillent les analystes. D’ailleurs, le concept de Logical Data Warehouse a été exclu du Hype Cycle 2022 tout simplement parce qu’il n’a plus à faire ses preuves. Comme le lac de données n’a pas remplacé l’entrepôt de données, le Lakehouse risque de cohabiter pendant longtemps avec le LDW.
