MySQL HeatWave Lakehouse : Oracle joue (encore) la carte de la performance

Les bénéfices attendus d’une architecture Lakehouse

Un lakehouse, un terme marketing inventé par Databricks puis repris plus tard par différents fournisseurs, dont Snowflake et Google, désigne une architecture qui combine les capacités d’un lac et d’un entrepôt de données.

Son émergence est principalement due à la difficulté pour les entreprises d’associer les data warehouses, utilisés pour stocker et traiter des données structurées (financières ou transactionnelles), et les data lake, conçus pour accueillir des fichiers non structurés (audio, vidéo, texte), principalement dans des instances de stockage objet.

En raison de leur flexibilité, Matt Aslett, analyste chez Ventana Research, s’attend à ce que l’utilisation des lakehouses se généralise de manière significative au cours des deux prochaines années.

Il note que le stockage objet est devenu un moyen peu coûteux – et courant – pour les organisations de stocker des données. Mais sans structure, les données résidant dans les lacs de données sont difficiles à utiliser pour éclairer les décisions.

« Nous constatons un intérêt croissant pour l’approche lakehouse, en particulier parmi les organisations qui ont déjà investi dans des lacs de données », observe Matt Aslett. « J’affirme que d’ici à 2025, 8 utilisateurs actuels de data lake sur 10 investiront dans une architecture lakehouse pour améliorer la valeur commerciale générée à partir de leurs données accumulées ».

En plus de permettre aux utilisateurs de combiner facilement divers types de données, les lakehouses automatisent également une grande partie du travail à effectuer, ce qui est essentiel, selon Holger Mueller, analyste chez Constellation Research.

Autopilot, un atout clé, selon les analystes

Oracle a dévoilé la base de données MySQL HeatWave pour la première fois en 2020.

MySQL HeatWave est un service de base de données en mémoire (via le moteur de stockage InnoDB) qui s’appuie sur le SGBD open source MySQL, à laquelle Oracle ajoute ses propres fonctionnalités. MySQL HeatWave est disponible sur AWS et Microsoft Azure, en sus de l’être sur OCI.

Depuis son lancement il y a trois ans, Oracle a amélioré HeatWave avec MySQL Autopilot, une capacité d’automatisation propulsée par des algorithmes de machine learning conçus pour apprendre des requêtes passées, afin d’améliorer l’exécution des requêtes futures.

C’est ce même Autopilot qui serait l’avantage principal de MySQL HeatWave Lakehouse, selon Holger Mueller. « La réunion des données structurées et non structurées est fondamentale et représente un avantage du point de vue de la génération de KPI », déclare-t-il. « Autopilot rend cette tâche facile et rapide ».

Matt Aslett, lui, distingue deux approches dans la constitution d’une architecture lakehouse.

La première consiste à injecter les fonctionnalités d’un entrepôt de données dans l’environnement du lac de données. C’est celle choisie par Databricks, par exemple.

La seconde maintient les entrepôts de données et les lacs de données quelque peu séparés. Le lac de données sert au stockage à faible coût auquel l’on applique un schéma prédéterminé – donnant effectivement une structure aux données – à partir d’un data warehouse associé aux données précédemment non structurées.

Selon Oracle, MySQL HeatWave Lakehouse permet aux utilisateurs d’interroger les données présentes dans les instances de stockage objet, mais ne crée pas d’environnement unique. Le fournisseur adopte ainsi la deuxième approche décrite par Matt Aslett. 

L’un des avantages significatifs de cette approche est la réduction des coûts, puisque les données n’ont pas besoin d’être déplacées, selon l’analyste de Vantana Research. « MySQL HeatWave Lakehouse permet aux utilisateurs d’interroger des données hébergées dans des instances de stockage objet à partir de MySQL HeatWave, sans avoir à supporter le coût et la complexité d’un déplacement vers la base de données », explique-t-il. « L’avantage de cette approche est qu’elle facilite de manière relativement peu coûteuse l’analyse de grands volumes de données ».

Mais il y a un inconvénient, poursuit-il. En principe, la vitesse d’interrogation des données résidant dans les services de stockage objet est plus lente que celle placée dans la base de données. Oracle affirme cependant avoir éliminé ce problème grâce à Autopilot. « L’affirmation d’Oracle selon laquelle les clients peuvent interroger les données dans un [bucket] de stockage objet aussi rapidement que dans la base de données est significative », note Matt Aslett.

Ce point est important, selon l’analyste. Les fournisseurs cloud facturent leurs clients non seulement en fonction de la puissance de calcul qu’ils consomment, mais également au prorata du temps d’exécution d’un service. Chaque seconde compte. « Plus ils passent de temps dans le cloud, plus la facture est élevée », explique Steve Zivanic, vice-président d’Oracle chargé de la commercialisation des bases de données et des services Autonomous. « En fournissant ces services optimisés [les utilisateurs] recevront une facture moins élevée. Il s’agit d’un raisonnement purement économique ».

Dès l’annonce du lancement de HeatWave Lakehouse, Oracle avait publié des tests de performance. Il cherchait à prouver que son service était plus efficace que ceux de ses concurrents, en premier lieu Snowflake AWS (Aurora), et Google Cloud (BigQuery).

Le secret ? Ne pas brider les performances des services voisins, selon Oracle. Nipun Agarwal, vice-président senior de MySQL Database et HeatWave chez Oracle explique dans une vidéo que la vitesse d’exécution des requêtes ciblant les services de stockage objet repose indirectement sur la fonction « Adaptive data Flow » d’Autopilot.

 Quand des données résident dans un service de stockage objet, leur traitement dans MySQL HeatWave Lakehouse implique des transformations. Si les données ne sont pas déplacées manuellement, Autopilot en génère des « représentations » découpées en morceaux (chunks) pouvant être stockés et traités par le moteur in-memory InnoDB. Un seul moteur traite donc les données MySQL et celles présentes dans les instances de stockage objet.

Si Oracle avait déjà une batterie d’algorithmes pour optimiser et prédire les temps de traitements dans son moteur (peu importe si les données résident dans l’espace de stockage InnoDB ou dans un object store), Adaptive Data Workflow se concentre sur l’optimisation des chargements de données en fonction de la région cloud dans laquelle se situe le service d’object store dans OCI.

« Selon la région cloud, les performances du service de stockage objet en matière de requêtes par seconde ou de bandes passantes seront différentes », évoque-t-il. « Au niveau d’un cluster, Adaptive Data Workflow permet de faire correspondre le nombre de requêtes aux capacités des instances de stockage objet, pour ne pas impacter les performances des autres services disponibles dans la même région ».

Reste à voir si Oracle pourra ou voudra adapter cette fonctionnalité à des services de stockage objet tiers. Celle-ci a été développée en étroite collaboration avec l’équipe d’OCI Object Storage, indique Ninpun Argawal.

Les disparités subsistent au sein du catalogue DBaaS d’Oracle

Même si Oracle semble vouloir rattraper ses concurrents sur le marché du lakehouse, Ninpun Argawal assure que l’idée de développer MySQL HeatWave Lakehouse est née de la demande des clients.

Il note que lorsque Oracle a permis aux utilisateurs d’apporter le traitement analytique à MySQL, beaucoup avaient des données non structurées dans des fichiers qu’ils n’étaient pas en mesure d’utiliser dans le cadre de projets analytiques. « Il s’agissait d’un point sensible et nous avons pensé que nous pouvions étendre les capacités de HeatWave pour y remédier », avance-t-il. « Nous devions combiner le stockage objet avec les données MySQL ».

Cette priorité accordée aux demandes des clients est une bonne stratégie, selon Carl Olofson, analyste chez IDC. « Leur meilleur atout est de rester proches de leurs utilisateurs, d’écouter ce qu’ils ont à dire et d’observer comment les concurrents peuvent tenter de les éloigner », affirme-t-il.

En outre, M. Zivanic fait remarquer qu’Oracle prévoit d’intégrer l’IA générative à l’ensemble de son portefeuille de gestion des données et analytiques dans les mois à venir.

Holger Mueller, quant à lui, considère qu’Oracle est l’un des éditeurs de services DBaaS les plus complets, et que ses capacités dépassent souvent celles de ses concurrents. « Il s’agit de la base de données en cloud qui innove le plus rapidement, et il ne reste que très peu de choses à ajouter », considère l’analyste chez Constellation Research.

« Oracle Database correspond à l’offre haut de gamme en direction des entreprises, tandis que MySQL s’adresse à une variété d’utilisateurs à plus petit budget. »

Bien qu’il s’agisse d’un nouvel ajout au portefeuille MySQL HeatWave, MySQL HeatWave Lakehouse n’est pas le premier data lakehouse d’Oracle. L’éditeur-fournisseur propose également des fonctionnalités de lakehouse dans son Autonomous Data Warehouse – une version entièrement gérée d’Oracle Database –, qui s’adresse à une base d’utilisateurs différente de celle de la suite MySQL HeatWave.

« Oracle Database correspond à l’offre haut de gamme en direction des entreprises, tandis que MySQL s’adresse à une variété d’utilisateurs à plus petit budget qui exigent toujours un bon support de leur système de gestion de base de données », explique Carl Olofson.

Cette segmentation ne justifie pas forcément les écarts de fonctionnalités. Autonomous Data Warehouse (OADW) prend en charge davantage de formats de tables et de données que HeatWave Lakehouse, ainsi qu’un plus grand nombre de charges de travail.

Là où OADW peut accueillir ou traiter les formats Parquet, AVRO, CSV et Apache Iceberg, HeatWave Lakehouse ne supporte « que » CSV, Parquet, en sus des exports AWS Aurora, RedShift et MySQL. En clair, le service d’Oracle permet de traiter des données semi-structurées ou des représentations (par exemple vectorielles) des données non structurées et leurs métadonnées.

De plus, OADW est compatible avec Delta Sharing, le protocole d’échange de données open source imaginé par Databricks. Or MySQL et ses dérivés sont généralement utilisés pour propulser des applications Web et des architectures analytiques. Des environnements dans lesquels le partage de données est, a priori, essentiel.

Là où il pourrait y avoir une marge de croissance – au-delà de l’infusion de l’IA générative mentionnée par Steve Zivanic –, « c’est en allant au-delà du stockage des données », poursuit, pour sa part, Holger Mueller. « Ils [les dirigeants d’Oracle] pourraient s’orienter vers… plus d’opérations de données et de développement d’applications. Il ne reste plus rien à faire du côté des bases de données », estime-t-il.