CloudWorld 2022 : Oracle se lance (lui aussi) dans la course au Lakehouse
Lors de son CloudWorld 2022, Oracle a présenté la bêta de MySQL HeatWave Lakehouse, une version de MySQL HeatWave qui met l’accent sur la performance à large échelle et la fédération de requêtes SQL dans les magasins d’objets stockés dans le cloud.
Après Snowflake, AWS, Microsoft, Google Cloud, Cloudera, Teradata, c’est au tour d'Oracle de lancer son offre « Lakehouse ».
Pour rappel, le terme a été inventé par Databricks pour décrire sa combinaison d’un lac de données et d’un data warehouse. Plus spécifiquement, Databrick a d’abord ajouté une couche ACID par-dessus son data lake, puis s’est appuyé sur les fonctions SQL d’Apache Spark et un ensemble d’outils pour supporter les charges de travail analytiques, de machine learning et de deep learning.
Oracle s’inscrit dans cette tendance, mais à sa manière. Jusqu’alors, il proposait un certain nombre de briques et de services, qui, une fois mis bout à bout, pouvaient former un data lakehouse. Désormais, un produit porte cette appellation marketing.
Ainsi, c’est MySQL HeatWave Lakehouse, accessible en bêta sur le cloud OCI (Oracle Cloud Infrastructure), qui doit concurrencer BigLake de GCP et le « data cloud » de Snowflake.
Requêter les objects stores, la nouvelle lubie des fournisseurs
Ici, Oracle s’appuie sur le moteur in-memory InnoDB pour accélérer les traitements OLAP et OLTP. Cela ne suffit plus. Le nerf de la guerre est la capacité de cibler des objects stores et de traiter les données stockées dans ces buckets, dans des formats divers et variés.
« Les données stockées en dehors des bases de données connaissent une croissance considérable et, avec MySQL HeatWave Lakehouse, les clients peuvent tirer parti de tous les avantages de HeatWave sur les données résidant dans les magasins d’objets », vante Edward Screven, chief corporate architect chez Oracle dans un communiqué de presse.
Pour cela, le fournisseur s’appuie depuis quelque temps sur son propre service de stockage objet, OCI Object Storage. Avec son offre Lakehouse, il ajoute la prise en charge des backups Amazon Aurora et RedShift. Il serait ainsi possible de combiner dans une seule requête des données en provenance d’un magasin d’objets et de MySQL. Pour rappel, MySQL HeatWave sur AWS, en disponibilité générale depuis un mois, permet en principe de cibler des données situées dans des buckets S3.
En matière de formats de données, Heatwave Lakehouse peut ingérer des fichiers Parquet, Avro et CSV via des tables externes. Les concurrents d’Oracle, dont Snowflake et Google Cloud, se mettent doucement, mais sûrement à prendre en charge les formats de table Apache Iceberg, Delta Lake et Hudi.
Est-ce une voie possible sur laquelle Oracle souhaite s’investir davantage ?
« Tout d’abord, nous devons apporter HeatWave Lakehouse en disponibilité générale », tempère Steve Zivanic, Vice-président monde base de données et services autonomes chez Oracle, auprès du MagIT.
« Nous avons dévoilé cette bêta sur OCI. Par la suite, nous proposons le service sur AWS. »
Steve ZivanicVice-président monde base de données et services autonomes, Oracle
« Ensuite, nous avons dévoilé cette bêta sur OCI. Par la suite, nous proposons le service sur AWS », poursuit-il.
Toutefois, il s’agit bien de supporter les services spécifiques des clouds sur lesquels Oracle pourra installer son « Lakehouse ». « Nous optimisons ce service pour différents clouds, mais nous souhaitons apporter la même expérience », affirme Steve Zivanic. « Tout ce que nous introduisons sur un cloud, nous souhaitons le répliquer sur les autres ».
Pour le moment, le lakehouse peut traiter des données structurées et semi-structurées.
Par exemple, pour traiter les fichiers CSV, Oracle assure que sa technologie peut améliorer les performances pour traiter des dizaines de téraoctets de données.
Dans les grandes lignes, InnoDB lit les données dans les tables de MySQL, puis les transforme afin de fournir une représentation optimisée pour les traitements en mémoire. Cette représentation repose en réalité sur un format colonne hybride propriétaire.
De la même manière, avec Heatwave Lakehouse, les données en provenance d’un service de stockage objet comme des fichiers CSV sont lues, puis transformées automatiquement en une représentation en mémoire.
Pour cela, Oracle s’appuie sur les fonctions de MySQL Autopilot. Cette technologie doit automatiser l’inférence des schémas des fichiers CSV.
« Autopilot déduit automatiquement le mappage de données du fichier aux types supportés par la base de données », selon la documentation du fournisseur. « Par conséquent, les clients n’ont pas besoin de spécifier manuellement le mappage pour chaque nouveau fichier à interroger par MySQL HeatWave Lakehouse, ce qui leur permet d’économiser du temps et des efforts ».
Autopilot est également utilisé pour échantillonner les données stockées dans les services de stockage objet pour optimiser les schémas et les requêtes.
La même technologie est utilisée afin de prédire le temps que prendra un chargement de données et en réponse générer des scripts de chargements, normalement plus performants qu’une manipulation manuelle.
Oracle joue (encore) sur la performance à large échelle
Sur un benchmark de type TPC-H (les parangonnages d’Oracle ne sont pas tous officiellement reconnus par TPC), Oracle affirme charger 400 téraoctets en 42 secondes. Pour cela, Oracle « aligne » 512 nœuds dans un seul cluster, et prétend que ce chargement aussi rapide depuis la base de données ou depuis les objects stores.
MySQL HeatWave est limité à 32 To de stockage et 64 nœuds, rappelle Ron Westfall, analyste chez Futurum Research. C’est un bond en avant, selon lui.
« Les concurrents fournisseurs de SGBD n’ont pas encore réagi à la convergence des bases de données et à la présence multicloud de MySQL HeatWave. Comment vont-ils faire face aux 400 To du MySQL HeatWave Lakehouse ? », s’interroge-t-il dans un document diffusé par Oracle.
En réalité, d’autres acteurs jouent le même jeu. En premier lieu, Teradata a testé VantageCloud Enterprise sur 1 000 nœuds sur AWS.
« À la disponibilité générale, le service [HeatWave Lakehouse] supportera jusqu’à 400 To de données. »
Steve ZivanicVice-président monde base de données et services autonomes, Oracle
À l’heure actuelle, HeatWave Lakehouse ne supporte que 50 To de données. « C’est une bêta. À la disponibilité générale, le service supportera jusqu’à 400 To de données », précise Steve Zivanic.
« Nous allons dépasser les capacités d’Aurora dont un cluster peut attendre la taille maximum de 128 To », vante-t-il. « Nous avons élargi le marché adressable. C’est une opportunité supplémentaire ».
Mais au-delà de la course à la performance, il faut bien délimiter les cas d’usage de tels Lakehouse s’appuyant sur des bases de données relationnelles ou des entrepôts de données.
Selon Steve Zivanic, de manière générale, les clients ont choisi en premier lieu HeatWave pour réaliser des analyses marketing.
« C’est un cas d’usage très populaire chez beaucoup d’entreprises de toute taille qui viennent nous voir pour explorer leurs données », affirme le VP. « Ces organisations cherchent à obtenir des indicateurs pertinents, à propulser leur force de vente, à améliorer leur marketing, et donc se mettent à l’analytique en temps réel ».
Ils choisiraient HeatWave pour ses capacités d’automatisation et « d’élimination de la couche ETL », vante le responsable.
HeatWave Lakehouse serait ainsi moins cher que RedShift ou BigQuery parce que les clients auraient beaucoup moins d’opérations à effectuer par eux-mêmes pour arriver au même résultat, selon Steve Zivanic. Toutefois, Autonomous Database répondrait davantage aux usages critiques des grands comptes, à en croire le vice-président.
En revanche, le responsable préfère botter en touche au moment de mentionner le support des données non structurées.
MySQL HeatWave et HeatWave Lakehouse ne les prennent pas nativement en charge. Tout comme Teradata ou Snowflake. De son côté, Google débute à peine dans BigLake via des tables externes. Pour l’instant, seuls les fournisseurs de bases de données NoSQL ou de data lake offrent ce support des données non structurées.
En outre, à la manière de Teradata, Oracle inclut dans MySQL HeatWave Lakehouse un ensemble de capacités de machine learning issues de la librairie OML4PY. Elle permet de « traduire » des modèles écrits en Python en requêtes SQL.
Cependant, ces fonctions également appuyées par des fonctionnalités d’AutoML sont plutôt pensées pour couvrir les cas d’usage les plus communs, comme la réalisation de prévision, mais pas de traitements d’images ou de vidéos.
« Le machine learning est très populaire chez les clients d’HeatWave. Les clients peuvent développer leurs propres modèles », défend Steve Zivanic.
Comme la plupart des modèles de traitements d’images, voire de textes, sont développés pour s’exécuter sur des GPU, HeatWave ne semble pas le meilleur candidat pour ce cas d’usage. « Concernant les capacités d’apprentissage automatique d’HeatWave, nous sommes très uniques en ce sens que nous obtenons de meilleures performances et de meilleurs prix en ne les exécutant que sur les CPU AMD ».
Pour les cas d’usage de deep learning, le fournisseur préfère proposer son service OCI Data Science, de la puissance de calcul (d’où un partenariat avec Nvidia lors de CloudWorld 2022), et ses services managés (OCI Vision, Language, Data Labeling).
Reste à savoir s’il faut désormais limiter le Lakehouse à la capacité de réaliser des tâches analytiques et certaines tâches de machine learning sur une base de données et quelques instances de stockage objet.
La disponibilité générale de MySQL HeatWave Lakehouse est prévue pour la première partie de l’année 2023. Avant cela, MySQL HeatWave sera disponible sur Azure en novembre 2022.
