MySQL HeatWave ML : Oracle chasse sur les terres d’AWS
Le fournisseur cloud met à jour son DbaaS MySQL HeatWave en intégrant des fonctionnalités natives de machine learning. La firme cible les data analysts et les clients d’AWS.
Oracle a annoncé aujourd’hui la disponibilité d’une nouvelle version de son service MySQL HeatWave capable de supporter nativement les charges de travail de machine learning.
Pour rappel, HeatWave est un accélérateur de requêtes analytiques in-memory associé au moteur InnoDB par-dessus la base de données MySQL. La promesse est de pouvoir assurer les traitements analytiques (OLAP) et transactionnels (OLTP) depuis une seule et même base de données.
Oracle martèle que les capacités d’Oracle Cloud Infrastructure (OCI) et l’architecture hautement parallèle mise en place la rendraient « performante et très scalable ».
Oracle avait déjà introduit une première couche de machine learning dans AutoPilot, un assistant pour provisionner les instances, gérer les charges de travail, la planification des changements, des requêtes et les erreurs de restauration.
Avec la nouvelle mouture, il s’agit de prendre en charge nativement les jobs de machine learning à même le SGBD.
« Le problème avec le machine learning, c’est que les clients doivent extraire leurs données depuis MySQL avant d’y appliquer des traitements », affirme Ninpun Argawal, Senior Vice President, MySQL DB et HeatWave, chez Oracle lors d’une conférence de presse.
« Le problème avec le machine learning, c’est que les clients doivent extraire leurs données depuis MySQL avant d’y appliquer des traitements. »
Ninpun ArgawalSenior VP, MySQL DB et Heatwave, Oracle
« Les clients faisaient face aux mêmes inconvénients par le passé avec l’analytique. Une fois les données sorties de la base, elles ne sont plus sécurisées. Cela introduit une forme de complexité dans l’application et vous devez stocker les données ailleurs et exécuter ces modèles de machine learning depuis d’autres services, ce qui coûte plus cher », argumente-t-il.
HeatWave ML doit permettre d’entraîner, d’inférer et d’expliquer les modèles de machine learning. Oracle évoque plusieurs brevets pour nettoyer et normaliser les features nécessaires à l’entraînement d’un modèle, la sélection automatique d’un algorithme, le choix du bon échantillon dans le jeu de données, l’identification des hyperparamètres optimaux (via la technique de réduction des espaces), puis la génération des explications et l’entraînement des modèles. HeatWave ML ferait tout cela en une seule passe, souligne Ninpun Argawal.
« L’explicabilité est une notion très importante pour les clients. Une banque veut à la fois comprendre le modèle déployé en production et pouvoir expliquer à ses clients l’attribution d’un prêt ou le refus d’une transaction », avance-t-il.
AutoML, mais sur MySQL HeatWave
Curieusement, les représentants d’Oracle ne s’étalent pas sur la provenance de ces capacités. À y regarder de plus près, elles émergent directement d’Oracle AutoML, un outil déjà disponible dans Autonomous Data Warehouse.
Cependant, là où il est possible d’appeler une soixantaine d’algorithmes et de pousser des modèles développés en Python (via OML4Py) dans le data warehouse, l’API d’HeatWave ML est d’abord calibrée pour le langage SQL.
En fait, Oracle a monté une interface SQL par-dessus AutoML, mais sous le capot, HeatWave ML s’appuie sur des packages de machine learning écrits en Python, selon la documentation du fournisseur. Sur le papier, la base de données supporte exactement les mêmes fonctionnalités qu’Autonomous Data Warehouse : il est même possible d’invoquer HeatWave ML depuis un notebook Jupyter.
Néanmoins, le fournisseur assure que cette fonction simplifie le travail pour les data analysts, qui n’ont pas à utiliser un ETL pour déplacer les données ou des notebooks Jupyter ou Apache Zeppelin afin de créer les modèles. En clair, Oracle s’adresse en premier lieu à ceux qui voudraient se lancer dans le machine learning sans avoir de connaissances en langage Python.
« Les clients utilisent principalement ce type de fonctionnalités pour des tâches de classification et de régression », ajoute Ninpun Argawal au MagIT.
Malgré l’explicabilité apportée, le fournisseur ne voit pas forcément la nécessité d’indiquer à quel modèle de régression ou de classification son module de type AutoML s’apparente. « Le client ne cherche pas à savoir exactement quel modèle a été sélectionné », affirme le responsable.
En sus d’HeatWave ML, Oracle a également mis en place une capacité d’autoscaling. Son nouveau système de compression de données permettrait de réduire le coût de stockage des données « de près de 50 % », ou plutôt de stocker deux fois plus de données par nœud. De plus, la fonction « Pause-and-resume » permet de mettre en pause les environnements HeatWave « pour réduire les coûts », puis de les relancer au moment voulu. Dans la pratique, le service stocke les données dans un object store, les ressources de calcul sont « préchauffées » au lancement, et les données restaurées au redémarrage.
Compétition commerciale : Larry Ellison remet le couvert
Commercialement parlant, Oracle maintient un discours agressif. Le fournisseur cloud tente en tout cas de prouver qu’il n’a rien à envier à ses compétiteurs, qu’il peut même les battre à leur propre jeu. Après s’être comparé à MongoDB il y a peu, Oracle revient à ses premières amours et s’en prend de nouveau à AWS RedShift, Snowflake, mais aussi Azure Synapse et Google BigQuery sur le segment du data warehouse. Moins cher, plus performant : voilà les deux arguments martelés par les responsables du groupe à propos de MySQL HeatWave, parangonnages (Benchmarks en VO) à l’appui.
« Nos nouveaux résultats de benchmark, totalement transparents (les données sont disponibles sur GitHub N.D.L.R.), démontrent une fois de plus que Snowflake, AWS, Microsoft et Google sont plus lents et plus chers que MSQL HeatWave », déclare Edward Screven, Chief Corporate Architect dans un communiqué de presse
Ainsi, selon des benchmarks « dérivés » du TPC-DS 10 To, Snowflake (14,4 fois) RedShift (4,8 fois) Azure Synapse (14,9 fois) et BigQuery (12,9 fois) seraient bien moins rapides et plus chers que MySQL HeatWave.
De même, HeatWave ML serait 25 fois plus véloce que RedShift ML pour entraîner des modèles à 1 % des coûts. De telles évaluations sont discutables tant il est difficile de savoir si elles correspondent à un véritable cas d’usage. D’autant que le fournisseur n’applique pas à la lettre la spécification TPC-DS.
Malgré tout, certains analystes approuvent l’éditeur dans son approche. Des rapports concoctés par Moor Insight, db Insight, et Constellation Research reconnaissent les capacités de ce SGBD traditionnel revu au goût du jour.
« Oracle intègre l’ensemble du traitement et des modèles d’apprentissage automatique dans la base de données […], gagnant ainsi en rapidité, en précision et en rentabilité. »
Carl OlofsonAnalyste chez IDC, communiqué de presse d’Oracle
« Aujourd’hui, Oracle va plus loin que l’unification originale de l’OLTP et de l’OLAP dans HeatWave, avec MySQL HeatWave ML », affirme Carl Olofson, analyste chez IDC, dans le communiqué de presse d’Oracle. « Oracle intègre l’ensemble du traitement et des modèles d’apprentissage automatique dans la base de données, de sorte que les clients évitent non seulement de gérer des bases de données distinctes pour le machine learning, mais éliminent également les problèmes d’ETL, gagnant ainsi en rapidité, en précision et en rentabilité ».
Mais les responsables d’Oracle poussent le bouchon et répètent que de « nombreux » clients ont migré leurs bases de données depuis SAP HANA, Teradata, BigQuery, Azure MySQL, RDS, RedShift et Aurora en direction de MySQL HeatWave. « Dans la majorité des cas, les clients migrent depuis RedShift ou Aurora vers notre service, que ce soit pour traiter des requêtes analytiques ou transactionnelles », assure Ninpun Argawal.
Oui, mais qui sont les clients prêts à effectuer ces transhumances ? Dans son communiqué de presse, Oracle cite principalement des startups et des petites structures comme l’edtech brésilienne Estuda.com, le studio japonais de jeux vidéo Genius Sonority (une des petites mains de Nintendo), ou encore le spécialiste en cybersécurité Neovera. Et les grands comptes dans tout ça ? « Un très gros opérateur de télécommunication basé au Japon a arrêté sa migration de Teradata vers BigQuery pour passer sur MySQL HeatWave », annonce le SVP.
De prime abord, la liste de clients semble contenue. Cela paraît normal, au vu de la jeunesse du produit lancé à la fin de l’année 2020, comme le signalait Holger Mueller, analyste chez Constellation Research, dans son rapport publié le 3 juin 2021.
Cependant, Larry Ellison lui-même a affirmé, lors de la conférence téléphonique consacrée aux résultats du troisième trimestre fiscal 2022 d’Oracle, qu’HeatWave pouvait à la fois remplacer Aurora, RedShift et Snowflake. Mieux, HeatWave sera à l’avenir multicloud pour faciliter la migration des solutions concurrentes vers ce produit. Larry Ellison s’est également attaqué à SAP en citant des clients qui auraient signé des contrats ERP et HCM avec Oracle, dont le Crédit Agricole et la Société Générale.
Interrogés par nos confrères de CRN à ce sujet, les porte-parole d’AWS et de SAP ne sont pas impressionnés. AWS évoque plus de 100 000 clients ayant déployé Aurora, tandis que plusieurs dizaines de milliers d’entre eux utiliseraient RedShift. Ces services souffriraient-ils de problèmes de performances ? Pas selon AWS, qui est « convaincu » de disposer d’un rapport prix-performance « à la pointe du secteur ». Au sujet de la liste de clients brandie par le patron d’Oracle, SAP rappelle ses propres résultats en hausse, portés par le programme RISE with SAP.
