Comparaison de solutions de MLaaS

Machine Learning as a Service

Comparaison de solutions de MLaaS

Machine Learning as a Service

L’utilisation de techniques de machine learning (ML) est de plus en plus répandue dans divers secteurs d’activité. L’exploitation de ces techniques nécessite cependant une expertise rarement disponible dans les entreprises.

Récemment, des solutions de machine learning as a service (MLaaS) sont apparues. Ces services promettent une utilisation plus simple et plus rapide d’algorithmes de machine learning tout en débarrassant l’utilisateur de la nécessité de configurer et gérer l’environnement matériel et logiciel nécessaire à leur mise en œuvre.

Dans cet article, nous comparons plusieurs de ces offres de MLaaS, et les comparons avec une solution plus classique basée sur une pile d’outils Python.

Introduction

L’utilisation de techniques de machine learning (ML) est de plus en plus répandue dans divers secteurs d’activité. La promesse de telles techniques est, à partir des données fournies, de dégager des tendances et de prédire les caractéristiques d’éléments étudiés grâce à un apprentissage réalisé en analysant d’autres éléments similaires. Ces techniques font l’objet de recherche visant à les perfectionner, mais de nombreux outils existent depuis de nombreuses années pour les mettre en œuvre. Ces outils nécessitent cependant typiquement une expertise rarement disponible dans les entreprises pour préparer les données à analyser, réaliser les analyses proprement dites et interpréter correctement les résultats obtenus.

Récemment, différents outils sont apparus pour tenter de faciliter l’accès aux techniques avancées de machine learning. Il devient ainsi possible pour une entreprise de recourir à une solution de machine learning en tant que service (MLaaS), tout en limitant les compétences en statistiques nécessaires à son exploitation. Une approche selon laquelle il suffit de fournir des données pour obtenir une réponse claire et facilitant la prise de décision est en effet attrayante. La nécessité de connaître les subtilités du fonctionnement des algorithmes utilisés disparaissant, les implémentations réalisées s’en trouvent facilitées. Les services proposés sont éprouvés et basés sur des outils conçus par des experts en statistiques.

Cependant, si ces nouveaux services permettent de tirer profit des techniques de machine learning avec des compétences limitées dans ce domaine, il reste à déterminer dans quelle mesure ils peuvent être mis en œuvre pour répondre aux besoins et exigences propres aux secteurs d’activité dans lesquels ils peuvent s’appliquer. Ce document présente plusieurs solutions informatiques en ligne proposées par une entreprise sous la forme d’applications Web (MLaaS, Machine Learning as a Service) d’une part, et une solution pouvant être déployée sous la forme de packages sur une infrastructure pouvant être contrôlée par l’utilisateur d’autre part.

Le reste de ce document est structuré comme suit. Premièrement, les solutions étudiées sont brièvement présentées. Ensuite, les avantages et inconvénients de chaque solution sont discutés. Cette comparaison est structurée par phases généralement associées au machine learning, à savoir l’acquisition des données, leur prétraitement, leur analyse pour l’apprentissage d’un modèle et l’exploitation de ce modèle pour la prédiction. Enfin, la dernière partie de ce document est consacrée à la comparaison des solutions considérées selon des critères non fonctionnels tels que la sécurité et l’intégrité des données ou encore le coût d’utilisation.

Solutions étudiées

Il est important de remarquer que le secteur du MLaaS est en pleine évolution. Les solutions existantes sont de plus en plus nombreuses et s’étoffent progressivement pour couvrir toujours plus de cas d’utilisation et de besoins. Nous avons retenu les solutions suivantes qui sont, lors de la rédaction de ce document, les principales supportées par des entreprises ou des associations garantissant une bonne pérennité de leurs produits et offrant un panel de services suffisamment conséquent que pour couvrir des besoins variés dans le cadre du machine learning.

Azure Machine Learning est un service de MLaaS proposé par Microsoft et basé sur Azure, sa plateforme de cloud computing. Ce service propose un environnement, nommé Studio, permettant la définition du traitement que doivent subir les données qui lui sont soumises afin de les préparer et les analyser pour générer un modèle les représentant ou permettant la prédiction de certaines de leurs caractéristiques. Cet environnement est essentiellement visuel : les différentes étapes de préparation et de traitement sont représentées par des boîtes connectées entre elles par des flèches représentant l’ordre dans lequel les étapes doivent être réalisées. Cette offre est intégrée à l’environnement Azure, de sorte qu’il soit facile d’utiliser les autres services cloud de stockage de fichier, de bases de données, de ressources à la demande, etc., proposés par Microsoft.

Amazon Machine Learning est une autre solution MLaaS proposée par Amazon et basée sur sa propre infrastructure cloud. Il est donc possible d’utiliser les autres services proposés par Amazon, y compris les services de stockage et de bases de données.

Google Prediction API fait partie des API de services proposées par Google et fut l’une des premières solutions de MLaaS disponibles sur le marché. Elle propose un ensemble d’outils de machine learning basés sur son offre de cloud computing. L’utilisation de ce service est principalement réalisé par l’intermédiaire d’une API RESTfull, mais des bibliothèques et des scripts sont proposés en différents langages (y compris Java, Python et Ruby) afin de faciliter l’intégration du service dans les applications existantes de leurs utilisateurs.

BigML est une solution MLaaS qui propose une interface Web permettant la spécification des algorithmes à utiliser et la visualisation des résultats obtenus.

La dernière solution considérée, nommée Python Scientist Toolkit ou PST dans ce document, n’est pas une solution MLaaS. Il s’agit d’un ensemble d’outils implémentés en Python et offrant un environnement de machine learning. Plus spécifiquement, nous avons considéré l’utilisation conjointe de Jupyter, Pandas, Seaborn et Scikit Learn. Cette solution propose une approche moins intégrée que les précédentes, et nécessite généralement l’écriture de scripts afin de mener à bien les études de machine learning souhaitées. Il est possible de combiner PST avec Spark afin de proposer une solution de machine learning pouvant gérer de grandes quantité de données réparties sur plusieurs unités de calcul.

À titre indicatif, citons également Oracle Data mining qui se déploie sous la forme d’une image pour l’IaaS d’Amazon, ainsi que d’autres outils, aujourd’hui moins populaires et moins utilisés que ceux retenus, et conçus exclusivement pour le cloud computing, parmi lesquels Braincube, In2Cloud, Predixion et Cloud9Analytics. Ces solutions ne sont pas intégrées au présent comparatif.

Aspects fonctionnels

Acquisition des données

La première étape de tout travail de machine learning consiste en l’acquisition des données nécessaires à la création de modèles. Par acquisition, il ne faut pas ici comprendre la manière dont les données sont générées (par exemple, à partir de capteurs), mais la manière dont elles sont originellement présentées à la solution de machine learning. Afin de simplifier le processus global d’analyse des données, il est en effet nécessaire que celles-ci soient disponibles dans un format et depuis une source exploitables par la solution.

La limite de taille des données traitées peut être un facteur déterminant dans le choix de la solution retenue. Pour les MLaaS, cette limite est imposée par le prestataire de service. Elle peut être négociée pour Amazon ML. Certains algorithmes de machine learning peuvent entraîner un modèle de manière incrémentale afin d’éviter d’avoir à charger l’entièreté des données d’apprentissage en mémoire.

Toutes les solutions permettent l’acquisition de données grâce à la lecture de fichiers textuels. Amazon ML, Google Prediction et Azure ML permettent l’acquisition à partir de fichiers situés sur leurs plateformes de stockage respectives. BigML, qui ne dispose pas d’offre de stockage à proprement parler, permet la lecture de fichiers dans Amazon S3 et Azure Storage. PST ne permet pas directement l’accès à ces ressources, mais il existe des bibliothèques Python permettant le permettant.

Il est à noter que Google Prediction impose que la première colonne de données corresponde à la valeur cible, c’est-à-dire celle à prévoir. Il peut s’avérer nécessaire de réagencer les données afin de se conformer à cette contrainte.

Toutes les solutions considérées supportent des données de type booléen, catégoriel, temporel, numérique et textuel.

Grâce aux nombreuses bibliothèques Python existant pour manipuler des formats de fichiers et des sources de données, PST est certainement la solution la plus complète en termes d’acquisition de données. Contrairement aux MLaaS, les données utilisées pour entraîner un modèle avec PST ne sont pas soumises à d’autres limites que la capacité de la machine sur laquelle s’exécutent les tâches d’analyse.

Parmi les solutions MLaaS considérées, il n’y a pas de candidat se détachant nettement du lot, car chaque solution a ses avantages et inconvénients. On notera toutefois qu’Azure ML est actuellement la solution offrant la plus grande variété de formats et de sources de données.

Acquisition des données
Amazon ML  Google Prediction  Azure ML  BigML  PST
Sources de données  AWS RDS

AWS Redshift

AWS S3

 fichier texte dans Google Storage

Google Spreadsheet

HTTP(S) API

 fichier texte

Azure Storage

Azure Table

Azure SQL DB

Serveur SQL sur Azure VM

BDD SQL

HTTP(S)

Hadoop HiveQL

OData

 fichier texte

HTTP(S)

S3

Azure Storage

OData

Dropbox

 fichier texte

BDD SQL

Format des données CSV

Bucket S3

BDD Redshift

 .txt

spreadsheet

JSON

 .csv

fichier texte

.arff

tables Hive/SQL

odata

svmlight

 .csv

.arff

.zip

.gz

.bz2

 .csv

Excel

HDF5

SQL

JSON

msgpack

html

gbq

stata

sas

pickle

.zip

.gz

.bz2

Taille maximale des données pour l’apprentissage  1 To  Fichier texte : 2,5 Go

HTTP(S) : 2 Mo

231-1 colonnes, 231-1 lignes.

10 Go ou illimité, selon la formule choisie. 

S3 : 5 To

Autre : 64 Go

 Limitée par la RAM disponible.

Prétraitement des données

Les données obtenues sont rarement directement exploitables par des algorithmes de machine learning. Il est souvent nécessaire de les normaliser, de traiter les données manquantes ou aberrantes, etc. Ces tâches, si elles ne peuvent être réalisées au sein de la solution, devront l’être au moyen de scripts de prétraitement avant que les données ne soient communiquées à la solution.

Le tableau ci-dessous reprend les techniques de prétraitement les plus couramment mises en œuvre lorsque les données doivent être préparées pour être utilisées dans le cadre de machine learning.

Les solutions considérées proposent d’autres prétraitements complémentaires qui ne sont pas détaillés dans le présent document. De même, certaines transformations (telles que le tri) sont systématiquement appliquées aux données lors de l’exécution de certains algorithmes de machine learning. Il n’est ici question que des transformations devant être explicitement réalisées par l’opérateur, en fonction de la signification des différentes caractéristiques de la population considérée.

Prétraitements
Amazon ML  Google Prediction Azure ML  BigML  PST
Visualisation des données  tableau, histogramme, boxplot Aucune  tableau, histogramme, synthèses  tableau, histogramme, arbre, sunburst nombresues visualisations avec Seaborn
Séparation en apprentissage/test  Oui Non  Oui  Oui  Oui
Transformations mathématiques Non  Oui  Oui  Oui Oui
 Regroupement de données (binning) Oui  Non  Oui  Non  Oui
 Normalisation des caractéristiques  Oui Non Oui Oui Non [1]
Réduction des caractéristiques  Non ?  Non ?  PCA (via R), par filtrage, par hachage  Non  PCA, NMF, ICA, …
Traitement des caractéristiques textuelles  Oui Oui  Oui Oui Oui
Gestion des données manquantes  Oui [2] Oui : par une chaîne vide ou 0.   Oui : par une valeur arbitraire, moyenne, médiane, mode.  Oui : dernière prédiction, proportionnelle Oui : par une valeur arbitraire, moyenne, médiane, une fonction arbitraire
Autres Recettes   Peut exécuter des scripts Python et R.  Python 

La flexibilité de PST joue ici en sa faveur : cette solution propose un surensemble des approches de prétraitement proposées par les autres solutions. Cette flexibilité se fait au détriment augmentation de la complexité d’utilisation, puisqu’il est nécessaire d’écrire un script en Python pour en tirer profit. Un tel script se réduit cependant généralement à l’appel de fonctions définies dans une bibliothèque (très) riche dont il faut apprendre le contenu pour en exploiter toutes les possibilités. C’est particulièrement le cas avec Seaborn, qui propose un très grand nombre de visualisations personnalisables, mais qui constitue à elle seule une bibliothèque dont l’usage doit être appris.

Parmi les solution de MLaaS, Azure ML semble proposer le plus de fonctionnalités. L’environnement est de plus très visuel et relativement convivial : l’utilisateur indique son souhait d’utiliser une fonctionnalité en plaçant une boîte sur une « paillasse de traitement ». Les boîtes sont connectées entre elles au moyen de flèches. Le processus complet de transformation des données est alors défini par la séquence de transformations décrite par ces boîtes et ces flèches.

Azure ML possède en outre des boîtes « génériques » qui permettent de spécifier une transformation au moyen d’un script R ou Python. Il est donc possible d’enrichir les prétraitements préexistants en utilisant les transformations proposées dans les bibliothèques de ces langages.

Amazon ML permet la description des transformations à appliquer aux données au moyen de recettes (recipes en anglais). Ces recettes sont représentées par des documents textuels dont le format est inspiré de JSON. Cette approche ne permet cependant pas d’utiliser des transformations autres que celles proposées par Amazon.

Peu de transformations sont proposées par Google Prediction, qui limite pratiquement son API à l’utilisation d’algorithmes de machine learning proprement dits. Son usage nécessitera donc presque systématiquement la préparation préalable des données avant leur soumission à cette solution. Le fait qu’elle ne propose aucune visualisation empêche également l’utilisateur de se faire une première idée des données manipulées.

Apprentissage des modèles

Une fois les données prétraitées, des algorithmes de machine learning peuvent être utilisés pour y découvrir des tendances intéressantes pour l’utilisateur. Grâce à cet apprentissage, un modèle est créé, qui peut être par la suite interrogé afin de déterminer les spécificités d’un nouveau jeu de données. Un modèle pourra ainsi, par exemple, déterminer la valeur probable d’une caractéristique d’un individu donné, sur base de la connaissance des caractéristiques de la population à laquelle il appartient.

Nous ne présentons la disponibilité que de certaines familles d’algorithmes parmi les plus couramment utilisées.

Familles d’algorithmes disponibles 
Amazon ML  Google Prediction Azure ML BigML PST
Régression logistique  binomiale, polynomiale  Oui ? Oui Oui Oui
Arbre de décision Non   Non ? Oui Oui Oui
Forêt aléatoire  Non  Non ? Oui  Oui  Oui
MVS  Non  Oui ? Oui Non  Oui
K plus proches voisins Non   Non ?   Oui (via R)  Non   Oui
Réseau de neurones  Non  Non ? Oui  Non  Oui
Règles d’association  Non  Non  Oui  Oui  Oui (via module tiers)
Descente de gradient  Oui ? Non ? Oui Non Oui
Classification naïve bayésienne  Non  Oui ?  Oui  Non  Oui
Méthodes disponibles
 Amazon ML  Google Prediction  Azure ML  BigML  PST
Classification  binomiale, multinomiale binomiale, multinomiale binomiale, multinomiale  binomiale  binomiale, multinomiale
Régression  Oui Oui Oui Oui Oui
Détection d’anomalies  Non  Non  Oui  Oui  Oui
Clustering   Non   Non  Oui (K-Means)  Non  Oui
Apprentissage par lot  Oui  Oui  Oui Oui  Oui
 Réapprentissage  Non  Non  Oui  Oui Non
Apprentissage incrémental  Non  Oui  Non [3]  Non  Oui

Les trois approches proposées par Amazon ML sont la régression logistique binomiale et multinomiale, ainsi qu’une méthode de régression linéaire (probablement par descente de gradient). Les régressions logistiques permettent de prédire l’appartenance d’un individu à une classe (parmi un ensemble de classes prédéfinies) sur base de la valeur d’une caractéristique. Cette valeur doit être continue dans le cas de Amazon ML. La régression linéaire permet d’établir une relation linéaire entre les valeurs de deux caractéristiques de la population considérées. Ces approches peuvent s’avérer concluantes s’il existe une relation directe entre les caractéristiques considérées. Dans le cas contraire (par exemple, si la prédiction ne peut être réalisée que sur base des valeurs d’une combinaison non linéaire de caractéristiques), une prédiction correcte ne pourra être obtenue.

Google Prediction propose une approche « boîte noire », avec laquelle il n’est pas possible de déterminer l’algorithme réellement utilisé pour traiter les données. La documentation officielle reste très évasive en ce qui concerne les algorithmes utilisés, et la manière dont ils le sont. Lors de la configuration des outils, il est uniquement possible de préciser si la solution doit procéder à une classification (binaire ou non) ou à une régression. Lors d’un apprentissage, Google Prediction essaie plusieurs algorithmes et utilise ceux qui lui semblent être les plus appropriés étant donnés le volume des données, leur nature et leurs caractéristiques. Cette solution est donc surtout conçue pour un utilisateur qui a très peu, voir pas de connaissance en machine learning. Elle est adaptée aux problèmes simples, pour lesquels une sélection automatique des algorithmes appropriés est suffisante et un prétraitement inutile.

BigML favorise une approche « boîte blanche » en utilisant principalement des arbres de décisions. Ceux-ci sont suffisamment simples pour qu’un humain puisse les étudier et comprendre les structures sous-jacentes au jeu de données. Cependant, cela limite son utilisation à l’apprentissage supervisé. Il n’est de plus pas possible de réaliser une cross-validation pour déterminer à quel point le modèle produit est spécifique aux données d’apprentissage. Cette solution propose cependant d’autres approches, qui la rendent très polyvalente, mais une partie de ces approches n’est accessible qu’au travers de BigML.io, une API bas niveau, ou BigMLer, un outil en ligne de commande.

Azure ML permet, grâce à son mécanisme d’extension en R et en Python, le recours à n’importe quel algorithme de machine learning. Cependant, de nombreux algorithmes sont proposés sous la forme de boîtes spécifiques, de sorte que l’approche visuelle proposée par cette solution couvre la plupart des besoins courants.

PST propose également, grâce à Scikit Learn, une grande variété d’algorithmes. La plupart des algorithmes possèdent eux-mêmes de plusieurs variantes, de sorte que cette solution est celle qui couvre le plus de besoins. Cependant, cela se fait au détriment d’une configuration plus complexe, et d’une mise en œuvre nécessitant l’écriture de scripts en Python.

Toutes les solutions permettent un apprentissage par lot. Avec cette approche, un jeu de données, qui peut être conséquent, est fourni afin créer un modèle. Azure ML et BigML proposent de plus un mécanisme de réapprentissage, qui permet de fournir régulièrement de nouvelles données au système afin qu’un nouveau modèle soit créé régulièrement. Avec les autres solutions, il sera nécessaire de demander un nouvel apprentissage, par exemple grâce à une tâche CRON ou une intervention manuelle.

Google Prediction et PST permettent également un apprentissage incrémental. Avec cette approche, il est possible de mettre à jour des modèles existants en apportant de nouvelles données d’apprentissage. Cela permet d’éviter de procéder à un réapprentissage complet à partir d’un volume de données de plus en plus conséquent. Tous les algorithmes de machine learning ne se prêtent cependant pas à un tel apprentissage. De plus, les données d’apprentissage ne pouvant être utilisées qu’une seule fois, certaines optimisations utilisées lors de l’apprentissage par lot ne sont plus disponibles

Prédiction

Toutes les solutions étudiées bénéficient d’une grande maturité et ont été grandement éprouvées. Si l’exactitude d’une implémentation logicielle peut toujours être contestée, il est donc cependant raisonnable de supposer que ces solutions produisent des modèles corrects. La manière d’obtenir des prédictions à partir de ces modèles peut toutefois s’avérer être un facteur de sélection lors de l’adoption d’une solution.

Caractéristiques de la prédiction
 Amazon ML  Google Prediction  Azure ML  BigML PST
Par lot  Oui Oui Oui Oui Oui [4]
Individuellement  Oui Oui Oui Oui Oui
Paramètres du modèle connus  Non  Non  Non  Oui  Oui
Export de modèle  Non  Non  Non  PMML, Python, Ruby, R, etc. PMML (via un package tiers), Pickle
Import de modèle  Non  PMML  Non  Non  PMML (via un package tiers), Pickle
Partage de modèle Via export et import de recettes  limité à l’import de fichiers PMML tiers  Intégré : copie d’expériences  Intégré : URL  Via export, puis import
Visualisation  Oui  Non  Oui  Oui  Oui (via Seaborn)

La prédiction par lot consiste à soumettre une liste d’individus au modèle, puis de générer les prédictions attendues pour ces individus et de retourner tous les résultats en une fois. Cette approche permet de minimiser le nombre de messages échangés entre l’utilisateur et le modèle, mais elle peut introduire une latence importante, puisque la prédiction doit être réalisée pour chaque individu soumis avant que les résultats ne soient retournés.

Alors que la prédiction par lot peut s’avérer être une tâche nécessitant une grande durée de traitement, et est donc typiquement proposée sous la forme d’un service asynchrone, la prédiction par individu permet de soumettre au modèle un unique individu et d’obtenir en retour la prédiction qui lui est associée. Cette approche diminue les temps de latence et permet d’établir des prédictions en temps réel.

Amazon ML, Google Prediction et Azure ML ne permettent pas de connaître les valeurs des paramètres caractérisant les modèles créés et, a fortiori, d’exporter ces modèles hors de leur environnement de création et d’utilisation. Cela est conforme à la stratégie financière de ces solutions (cf. Section Coût), qui consiste à forcer l’utilisateur à louer les services de la plateforme sous-jacente pour exploiter les modèles générés.

Amazon ML propose un export des paramètres ayant été utilisés lors de l’apprentissage, ce qui ne permet pas d’utiliser le modèle hors de Amazon ML, mais de sauver et communiquer une représentation de la procédure ayant abouti au modèle généré. BigML propose une solution plus intégrée qui consiste à partager une URL privée donnant accès au processus d’analyse complet. Azure ML propose à ses utilisateurs de structurer les expériences d’analyse en workspaces. Il est possible de copier une expérience d’un workspace à un autre, et ainsi de les partager.

BigML et PST permettent l’export au format PMML, le standard de facto de représentation d’un modèle statistique. PST propose également l’export des modèles par l’intermédiaire de la bibliothèque généraliste de sérialisation Pickle, ce qui permet la consultation des modèles dans n’importe quel environnement disposant d’un interpréteur Python. BigML favorise également l’intégration de ses modèles dans un logiciel externe grâce à ses API pour divers langages de programmation, y compris R, Python, Java et Ruby.

À l’exception de Google Prediction, toutes les solutions de MLaaS, ainsi que PST proposent une représentation visuelle des modèles produits. Il est possible de paramétrer un seuil d’acceptation des modèles prédictifs binomiaux, et diverses métriques de qualité sont présentées.

API

Amazon ML, Azure ML et BigML proposent une offre principalement basée sur une application Web pour toutes les étapes liées au machine learning. Cependant, il peut s’avérer intéressant de recourir aux services proposés depuis un logiciel tiers ou un outil ne nécessitant pas d’intervention manuelle.

API disponibles
Amazon ML  Google Prediction  Azure ML  BigML PST
API apprentissage  Oui  Oui  Oui  Oui : BigML.io  Non
API prédiction  Oui  Oui  Oui Oui  Non
Outil en ligne de commande  Non  gsutil (stockage uniquement)  PowerShell, Windows, Mac, Linux  BigMLer Python
SDK  Python, Ruby, Java, .Net, PHP, Node.js  Python, Ruby, Java, .Net, PHP, Node.js, Objective C, Javascript Python, Ruby, Java, .Net, PHP, Node.js, iOS, Android Python, Java, Ruby, C#, … Python (natif)

PST ne propose ni API ni SDK, car il s’agit d’un ensemble de bibliothèques implémentées en Python. Afin de l’utiliser en tant que service distant, il sera donc nécessaire de créer les API et bindings appropriés.

Toutes les solutions MLaaS proposent des API d’apprentissage et de prédiction.

Si toutes les solutions MLaaS proposent également des SDK permettant d’intégrer leurs services au sein de logiciels écrits dans divers langages de programmation, BigML et Azure ML proposent en outre des outils en ligne de commande afin de faciliter l’utilisation de leurs services de manière automatisée, sans devoir créer de programmes spécifiques.

Spécifications non fonctionnelles

Coût

Le coût financier d’une solution de machine learning dépend principalement des facteurs suivants :

  • Stockage des données : Les données utilisées afin d’entraîner un modèle sont souvent volumineuses. En conséquence, il est généralement préférable de stocker ces données sur un support proposant une bande passante en lecture importante, plutôt que d’uploader systématiquement les données grâce à une connexion à Internet offrant une bande passante plus limitée. Le stockage distant des données est un service dont le coût doit être pris en compte. Il est à noter qu’il est parfois intéressant de ne stocker un grand volume de données que le temps nécessaire à la préparation et à l’apprentissage des modèles devant être utilisés par la suite. Dans ce cas, la durée de rétention des données peut être réduite à quelques heures ou quelques jours.
  • Production des modèles : Le choix des algorithmes d’apprentissage et de leurs paramètres est généralement un processus itératif, les résultats produits par le modèle permettant d’affiner les règles de production de nouveaux modèles plus adaptés. Le temps consacré à la conception de modèles et à leur apprentissage peut engendrer un coût pour l’utilisateur de la solution de machine learning utilisée qui dépend typiquement du nombre de modèles entraînés, de leur complexité, et du temps nécessaire à leur préparation.
  • Exploitation des modèles : Une fois un modèle entraîné, il pourra être utilisé afin de prédire les propriétés de nouveaux individus. Ce service d’exploitation des modèles sur la plateforme de machine learning peut représenter une charge financière, qui dépend typiquement du nombre de prédictions réalisées.
  • Autres : Les solutions de MLaaS prennent en charge, par définition, tous les coûts liés à l’achat et à la maintenance de l’infrastructure informatique nécessaire au bon fonctionnement de la solution. Lorsque la solution PST est choisie, en revanche, il est nécessaire d’investir les ressources nécessaires à la création et à la maintenance d’une telle infrastructure ou de recourir à une solution IaaS.

Coûts d’utilisation

Les coûts liés à l’utilisation des solutions MLaaS sont définis par une offre commerciale. Ce secteur d’activité étant en forte expansion, une concurrence s’installe entre les entreprises proposant ces services. En conséquence, les données reprises dans le présent document sont susceptibles de varier rapidement au cours du temps.

Lorsque les coûts dépendent de l’emplacement des ressources mises à la disposition des utilisateurs, nous avons supposé que celles-ci se trouvent au plus proche de Paris, France. Tous les tarifs s’entendent hors TVA. Le symbole « $ » représente le dollar américain.

Lorsque les coûts unitaires sont fonction du volume de données, nous avons indiqué les coûts relatifs à un stockage de 10 To et un transfert de 1 To par mois.

 Coût d’apprentissage et d’exploitation des modèles (tarifs et offres en avril 2016)
Amazon ML  Google Prediction  Azure ML
Apprentissage des modèles  $0,42 / h  Par batch : $0,002 / Mo

Mise à jour en streaming : $0,05 / 1.000 màj, passées les 10.000 premières.

$1 / heure
Exploitation des modèles Par lot : $0,10 / 1.000 prédictions

Temps réel : $0,0001 / prédiction + $0,001 / h / 10 Mo

$0,50 / 1.000 prédictions, passées les 10.000 premières $2 / heure de calcul + $0,50 / 1.000 prédictions
Autres NA Tarif de base : $10 / mois / projet  $9,99 / mois / siège
Limites  Maximum 5 tâches simultanées, maximum 7 jours d’exécution, autres.  2.000.000 prédictions / jour / projet

Apprentissage : maximum 2,5 Go

NA
Coûts et limites des offres BigML « Subscription » (tarifs et offres en avril 2016)
Standard Boosted  Pro
Taille d’une tâche  64 Mo 1 Go  4 Go
Nombre de tâches parallèles  2  4  8
Coût annuel  $240  $1.200  $2.400
Coût de l’offre BigML « Pay as you go » (tarifs et offres en avril 2016)
Dimension Coût
Taille des données  $0,05 / Mo
Taille des modèles  $0,20 / Mo
Nombre de prédictions  $5 / 10.000 prédictions

Amazon ML facture deux activités : le temps de calcul utilisé lors de la conception de modèles (facturé à l’unité de temps) et le nombre de prédictions réalisées (facturées à l’unité). Lorsque la prédiction est réalisée en temps réel (plutôt que par lot), un surcoût horaire s’applique en fonction de la quantité de mémoire nécessaire à l’exploitation des modèles. La quantité de mémoire doit être précisée par l’utilisateur lorsqu’il réserve ses ressources, et n’est facturée qu’à partir du moment où le modèle peut être interrogé.

Google Prediction propose une période d’essai gratuite de six mois (avec une volumétrie limitée). Passé ce délai, un abonnement mensuel est demandé pour chaque projet hébergé. Les 10 000 premières mises à jour du modèle en streaming et les 10 000 premières prédictions mensuelles sont offertes.
Azure ML propose une offre gratuite qui limite les ressources mises à disposition de l’utilisateur pour concevoir ses modèles, ainsi qu’une offre « illimitée » payante. L’offre gratuite ne permet pas l’utilisation de l’API Web pour l’exploitation des modèles entraînés. Dans le reste de ce document, seule l’offre payante est présentée.

BigML propose trois formules tarifaires, chacune très différente de celles des autres solutions de MLaaS étudiées. La première consiste en un abonnement mensuel, trimestriel ou annuel. Nous n’avons retenu dans ce comparatif que les abonnements annuels. Le coût de l’abonnement détermine les limites d’utilisation. La seconde formule permet d’utiliser les services proposés en échange de « crédits » qu’il est possible d’acheter. Cette formule est adaptée à une utilisation irrégulière des services. Elle permet également d’obtenir davantage de ressources que la précédente. Enfin, la troisième formule propose la location d’un Virtual Private Cloud : il s’agit d’une instance de BigML qui tourne sur une ou plusieurs instance(s) hébergée(s) par la plateforme Amazon Web Services à laquelle il est possible d’accéder grâce à un VPN. Aucun tarif n’est communiqué pour cette dernière formule.

Coûts de stockage

Les techniques de machine learning consistant en l’analyse de données afin d’y découvrir des tendances, le stockage de ces données d’apprentissage peut, en soi, représenter un coût non négligeable. Cela est d’autant plus vrai que les outils de machine learning sont de plus en plus souvent utilisés dans un contexte de Big Data, où la quantité de données traitées devient tellement importante qu’il n’est plus envisageable de les transmettre directement du poste de l’utilisateur à l’environnement de machine learning : une solution de stockage intermédiaire doit alors être considérée.

Sans surprise, Amazon, Google et Microsoft mettent en avant leurs propres solutions de stockage, à savoir respectivement Amazon S3, RDS et Redshift, Google Cloud Storage et Azure Cloud Storage. Ces solutions ne sont pas spécifiquement conçues pour le dépôt de données destinées à entraîner des modèles de machine learning. Cependant, pour autant que les données soient utilisées par les autres services des entreprises propriétaires des services de stockages (dans la même région du monde), le transfert de données depuis un dépôt vers la solution de machine learning n’est pas facturé. Si l’on ajoute à cela le fait qu’aucun frais d’upload n’est comptabilisé et que les frais mensuels de stockages sont relativement peu élevés, l’utilisation conjointe des services de stockage et de machine learning d’une même entreprise peut s’avérer intéressante.

Les offres proposées par ces trois entreprises présentent une grande complexité, au point que celles-ci proposent des simulateurs de coûts. Dans ce document, seules sont présentées les solutions qui semblent intéressantes, tant techniquement qu’économiquement, dans le cadre d’une exploitation des données afin de mettre en œuvre des solutions de machine learning.

Coûts de gestion des données (tarifs et offres en avril 2016)
Stockage Upload Transfort vers la même plateforme   Transfert vers Internet
Amazon S3 Standard  $0,0319 / Go / mois [5]  $0,0054 / 1.000 demandes  $0,0043 / 10.000 demandes  $0,0043 / 10.000 demandes + $0,090 / Go [6]
Accès peu fréquent $0,018 / Go / mois $0,01 / 1.000 demandes $0,01 / 10.000 demandes  $0,01 / 10.000 demandes + $0,090 / Go [7]
Amazon RDS $0,018 - $3,864 / heure [8]

+ $0,11 / Go / mois

+ $0,11 / 1.000.000 de demandes

$0,11 / 1.000.000 de demandes Gratuit  $0,09 / Go
Amazon RedShift $4.495 / To / an Gratuit Gratuit  $0,12 / Go
Google Cloud Storage Standard $0,026 / Go / mois Gratuit Gratuit $0,12 / Go
DRA [9] $0.02 / Go / mois
Nearline  $0,01 / Go / mois  $0,13 / Go
Azure Cloud Storage LRS $0,0236 - $0,0599 / mois Gratuit Gratuit  $0,087 / Go, passés les 5 premiers Go / mois

Amazon propose plusieurs variantes de son offre S3. Seules les offres « Standard » et « Standard Accès peu fréquent » s’avèrent pertinentes pour une application de machine learning. L’offre « Standard Accès peu fréquent » présente un coût de stockage moins élevé que l’offre « Standard », mais les opérations réalisées sur les données y sont plus onéreuses.

Amazon RDS est une solution de service de base de données qui se décline en plusieurs types d’instances. Chaque type répond à un besoin particulier en termes de puissance de calcul, de mémoire vive et de bande passante disponibles. La multitude des options disponibles rend difficile toute comparaison objective. Il est possible de réserver des instances, ce qui permet d’en réduire le coût d’utilisation.

Amazon Redshift est un service de stockage de données en colonne et adapté aux volumes de données conséquents (jusqu’à plusieurs Po). Comme pour Amazon RDS, il est possible de réserver des instances afin d’en réduire le coût d’utilisation.

Google Cloud Storage se décline en trois variantes qui se distinguent par la disponibilité garantie des données. On s’intéressera principalement aux variantes « Standard » et « DRA ». Cette dernière garantit la persistance des données, mais pas leur disponibilité immédiate.

Azure Cloud Storage propose diverses variantes qui proposent plusieurs types de distribution des données (au sein du même data center, à travers plusieurs continents, etc.) et plusieurs techniques de stockage et de transmission (par bloc, par fichier, etc.). Seule la solution la moins onéreuse (qui semble adaptée à une utilisation par des algorithmes de machine learning) a été retenue, à savoir un stockage par bloc et avec redondance locale.

BigML ne propose pas de solution de stockage.

Simulation

Nous proposons la simulation de cinq scénarios d’utilisation des solutions de MLaaS présentées dans ce document, afin de percevoir le coût qu’elles peuvent représenter. Ces scénarios envisagent différents volumes de données à utiliser afin d’entraîner les modèles, ainsi qu’un nombre variable de prédictions à réaliser mensuellement.

La simulation porte également sur l’utilisation de PST au sein des solutions d’infrastructure en tant que service (IaaS) d’Amazon, Google et Microsoft, à savoir Amazon EC2, Google Compute Engine et Azure Virtual Machine (respectivement). Les solutions de stockage de ces trois compagnies sont également utilisées.

Chaque scénario suppose qu’on souhaite classer automatiquement des produits sur base d’un catalogue de produits déjà classés. Ce catalogue est originellement représenté par un fichier unique dont la taille est précisée. Ce fichier sera stocké pendant un mois afin de pouvoir concevoir plus rapidement de nouveaux modèles si les premiers ne fournissent pas les résultats escomptés. À la fin de la phase d’apprentissage, un modèle d’une certaine taille est créé. Par la suite, un certain nombre de produits doivent être classés chaque mois.

Scénarios d’utilisation
Volume des données, en Go Temps d’apprentissage, en heures  Volume des modèles, en Mo Nombre de prédictions mensuelles  Temps de prédiction, en heures
Scénario 1  10 1  5  30.000 1,62
Scénario 2 10 1  5 890.000 48,00
Scénario 3  200  20  100 30.000  1,62
Scénario 4 200  20  100 890.000  48,00 
Scénario 5  0,1   0,1  5  10.000  0,54
Scénario 1
Coûts fixes  Stockage  Apprentissage  Prédiction  Premier moi  Mois suivants
 Amazon ML + S3 standard, traitement par lot 0  0,32  0,42  3,00  3,74  3,00
Amazon ML + S3 standard, traitement en temps réel  0  0,32   0,42  3,00  3,74  3,00
 Google Prediction + Google Cloud Storage Standard 10  0,26  20,48 10,00   40,74  20,00
Azure ML + Azure Cloud Storage 9,99  0,24  1,00  18,24  29,46  28,23
BigML « Pay as you go » + Amazon S3 standard 0,00 10.241,22  1,00  15,00  10.257,22  15,00
BigML « Pay as you go » + Azure Cloud Storage 0,00 10.240,67  1,00  15,00  10.256,67  15,00
BigML « Pay as you go » + Google Cloud Storage Standard 0,00 10.241,16  1,00 15,00  10.257,16  15,00
BigML « Subscription » + Direct Upload NA NA NA NA NA NA
PST + Amazon EC2 [10] + S3 standard  0  0,32 0,74 1,15 2,21 1,15
PST + Google Compute Engine [11] + Cloud Storage Standard 0  0,26 0,42  0,69  1,37  0,69
PST + Azure Virtual Machine [12] + Cloud Storage  0 0,24 0,85  1,38  2,47  1,38
Scénario 2
Coûts fixes Stockage Apprentissage Prédiction Premier moi Mois suivants
Amazon ML + S3 standard, traitement par lot 0 0,32 0,42 89,00 89,74 89,00
Amazon ML + S3 standard, traitement en temps réel 0 0,32 0,42 89,02 89,76 89,02
Google Prediction + Google Cloud Storage Standard 10 0,26 20,48 440,00 470,74 450,00
Azure ML + Azure Cloud Storage 9,99 0,24 1,00 541,00 552,23 550,99
BigML « Pay as you go » + Amazon S3 standard 0,00 10.241,22 1,00 445,00 10.687,22 445,00
BigML « Pay as you go » + Azure Cloud Storage 0,00 10.240,67 1,00 445,00 10.686,67 445,00
BigML « Pay as you go » + Google Cloud Storage Standard 0,00 10.241,16 1,00 445,00 10.687,16 445,00
BigML « Subscription » + Direct Upload NA NA NA NA NA NA
PST + Amazon EC2 [13] + S3 standard 0 0,32 0,74 34,08 35,14 34,08
PST + Google Compute Engine [14] + Cloud Storage Standard 0 0,26 0,42 20,35 21,04 20,35
PST + Azure Virtual Machine [15] + Cloud Storage 0 0,24 0,85 40,90 41,98  40,90
Scénario 3
Coûts fixes Stockage Apprentissage Prédiction Premier moi Mois suivants
Amazon ML + S3 standard, traitement par lot 0 6,38 8,40 3,00 17,78 3,00
Amazon ML + S3 standard, traitement en temps réel 0 6,38 8,40 3,02 17,80 3,02
Google Prediction + Google Cloud Storage Standard 10 5,20 409,60 10,00 434,80 20,00
Azure ML + Azure Cloud Storage 9,99 4,72 20,00 18,24 52,95 28,23
BigML « Pay as you go » + Amazon S3 standard 0,00 204.824,38 20,00 15 204.859,38 15,00
BigML « Pay as you go » + Azure Cloud Storage 0,00 204.821,69 20,00 15,00 204.856,69 15,00
BigML « Pay as you go » + Google Cloud Storage Standard 0,00 204.823,20 20,00 15,00 204.858,20 15,00
BigML « Subscription » + Direct Upload NA NA NA NA NA NA
PST + Amazon EC2 [16] + S3 standard 0 6,38 14,82 1,15 22,35 1,15
PST + Google Compute Engine [17] + Google Cloud Storage Standard 0 5,20 8,48 0,69 14,37 0,69
PST + Azure Virtual Machine [18] + Azure Cloud Storage 0 4,72 17,04 1,38 23,14 1,38
Scénario 4
Coûts fixes Stockage Apprentissage Prédiction Premier moi Mois suivants
Amazon ML + S3 standard, traitement par lot 0 6,38 8,40 89,00 103,78 89,00
Amazon ML + S3 standard, traitement en temps réel 0 6,38 8,40 89,48 104,26 89,48
Google Prediction + Google Cloud Storage Standard 10 5,20 409,60 440,00 864,80 450,00
Azure ML + Azure Cloud Storage 9,99 4,72 20,00 541,00 575,71 550,99
BigML « Pay as you go » + Amazon S3 standard 0,00 204.824,38 20,00 445,00 205.289,38 445,00
BigML « Pay as you go » + Azure Cloud Storage 0,00 204.821,69 20,00 445,00 205.286,69 445,00
BigML « Pay as you go » + Google Cloud Storage Standard 0,00 204.823,20 20,00 445,00 205.288,20 445,00
BigML « Subscription » + Direct Upload NA NA NA NA NA NA
PST + Amazon EC2 [19] + S3 standard 0 6,38 14,82 34,08 55,28 34,08
PST + Google Compute Engine [20] + Cloud Storage Standard 0 5,20 8,48 20,35 34,03 20,35
PST + Azure Virtual Machine [21] + Cloud Storage 0 4,72 17,04 40,90 62,66 40,90
Scénario 5
Coûts fixes Stockage Apprentissage Prédiction Premier moi Mois suivants
Amazon ML + S3 standard, traitement par lot 0 0,00 0,04 1,00 1,05 1,00
Amazon ML + S3 standard, traitement en temps réel 0 0,00 0,04 1,00 1,05 1,00
Google Prediction + Google Cloud Storage Standard 10 0,00 0,20 0,00 10,21 10,00
Azure ML + Azure Cloud Storage 9,99 0,00 0,10 6,08 16,17 16,07
BigML « Pay as you go » + Amazon S3 standard 0,00 102,41 1,00 5,00 108,41 5,00
BigML « Pay as you go » + Azure Cloud Storage 0,00 102,40 1,00 5,00 108,40 5,00
BigML « Pay as you go » + Google Cloud Storage Standard 0,00 102,41 1,00 5,00 108,41 5,00
BigML « Subscription » + Direct Upload 100,00 0,00 0,00 0,00 100,00 100,00
PST + Amazon EC2 [22] + S3 standard 0 < 0,01 0,07 0,38 0,46 0,38
PST + Google Compute Engine [23] + Cloud Storage Standard 0 < 0,01 0,04 0,23 0,27 0,23
PST + Azure Virtual Machine [24] + Cloud Storage 0 < 0,01 0,09 0,46 0,55 0,46

Les tarifs de stockage et d’utilisation des outils de machine learning étant complexes, un décompte exact du coût des différentes solutions proposées ne peut être établi. En conséquence, les coûts indiqués pour chaque scénario sont basés sur une tarification simplifiée des offres disponibles.

Nous avons également supposé constants d’une offre à l’autre les temps nécessaires à l’apprentissage et aux prédictions. En pratique, ces temps sont fonction des approches de machine learning et des ressources mises à disposition de l’utilisateur. Une étude mettant en œuvre un cas d’utilisation plus précis et basée sur un test réel des solutions devra être menée afin de déterminer dans quelle mesure notre supposition reste fondée.

L’offre « Subscription » de BigML n’a de sens que pour le cinquième scénario, car les autres supposent un volume de données que cette offre ne peut gérer.
Les offres de stockages, qu’elles soient utilisées par la solution de machine learning de la même entreprise ou par une solution tierce, proposent des tarifs similaires. Cependant, il semble que l’offre de Microsoft soit légèrement moins onéreuse que celle de Google, qui semble elle-même légèrement moins coûteuse que celle d’Amazon.

Lorsque le volume de données à analyser dépasse quelques dizaines de méga-octets, le coût de l’offre de BigML devient prohibitif, du fait du nombre de crédits devant être dépensés pour gérer ce volume. Les offres « Subscription » de BigML permettent une bonne maîtrise du coût, mais ne permettent l’analyse que 4 Go de données, au plus. Ces offres ont également un coût significativement supérieur à celui des offres concurrentes.

Dans tous les scénarios que nous avons testés, les solutions de Google et de Microsoft ont des coûts d’utilisation similaires, bien que Azure ML soit systématiquement plus onéreux que Google Prediction. Les tarifs pratiqués par Amazon ML sont, eux, sont très nettement inférieurs à ceux des autres solutions de MLaaS.

Google Prediction semble donc être une solution moins intéressante que les autres : elle ne compense pas l’absence d’interface graphique permettant de piloter l’apprentissage des modèles et leur utilisation pour réaliser des prédictions, ni le peu de techniques de machine learning proposées (techniques qui, de plus, ne sont pas connues de l’utilisateur) par une formule tarifaire plus attractive.

PST permet, par nature, un contrôle beaucoup plus aisé du coût d’utilisation d’une solution de machine learning que les MLaaS, au détriment toutefois de la nécessité d’avoir à acheter et entretenir (ou louer) un parc de machines et de mettre en œuvre une politique de gestion des pannes et incidents. Il est aussi important de constater que les solutions de MLaaS permettent une réponse rapide à une variation des besoins, là où un parc de machines risquera d’être sous-exploité ou insuffisant.

L’utilisation de PST sur une solution IaaS semble économiquement intéressante. Cependant, il est supposé dans le cadre de cette simulation qu’une machine virtuelle n’est louée que pour le temps nécessaire à la réalisation de prédiction. Si les prédictions peuvent être réalisées en même temps (par exemple, au début du mois), alors la solution est effectivement intéressante. Si par contre le système de machine learning doit pouvoir être sollicité à tout moment, il est nécessaire de louer constamment la machine virtuelle sur laquelle il fonctionne, ce qui augmente significativement les coûts liés à la prédiction : jusqu’à plus de 1300 fois dans le scénario 5 !

Une solution intermédiaire pourrait venir de l’utilisation d’une suite logicielle (idéalement gratuite) facilement déployable sur un parc de machine (localement, ou en recourant à une solution d’IaaS). À notre connaissance, il n’existe cependant pas de telles suites suffisamment matures pour considérer leur utilisation dans un environnement de production. À titre informatif, le projet open source Cognitive a cet objectif, mais il semble abandonné depuis mai 2015.

Sécurité et confidentialité

Les données utilisées à des fins d’apprentissage peuvent revêtir un aspect crucial pour l’utilisateur d’une solution de machine learning. Comme dans tout contexte de traitement de l’information, la perte et le vol de ces données sont des éventualités qu’il est nécessaire de prendre en compte.

Toutes les solutions de MLaaS proposent l’upload de fichiers en utilisant le protocole HTTPS, ce qui offre de bonnes garanties contre la compréhension ou l’altération des données échangées entre le poste de l’utilisateur et la solution de machine learning. La récupération de ces données par la solution elle-même ne peut être évitée, de sorte qu’il sera nécessaire d’accorder sa confiance envers le fournisseur de la solution.

Les solutions de stockage de données proposent également l’utilisation de protocole offrant de bonnes garantie d’intégrité et de confidentialité des données. Elles se prémunissent de leur perte par différentes techniques de redondance. Les données stockées peuvent ainsi être répliquées sur plusieurs machines. Certaines solutions, comme Azure Cloud Storage, permettent à l’utilisateur de choisir la disparité des data center dans lesquelles les données seront placées : même data center, dans plusieurs data center, dans plusieurs data center répartis sur plusieurs continents, etc.

Il est à noter que, dans le cadre d’une utilisation de techniques de machine learning, les données utilisées pour l’apprentissage ne sont pas modifiées (même si elles peuvent subir diverses transformations en mémoire vive lors de leur préparation), de sorte qu’une réplication ne pénalise pas les performances des algorithmes de machine learning. Au contraire : la réplication et la distribution des données facilitent le parallélisme et donc, potentiellement, la réduction du temps de calcul nécessaire à l’entraînement de modèles et l’obtention de prédictions. L’utilisateur ne peut cependant que faiblement influencer la manière dont ses données sont répliquées.

Amazon, Google et Azure ML s’engagent à offrir une qualité de service au travers d’un SLA (Service-Level Agreement). Amazon prévoit un remboursement partiel des frais d’utilisation si le SLA venait à ne pas être respecté. BigML ne propose pas de SLA par défaut, mais permet son obtention en souscrivant à un abonnement « premium ». Même si cette information ne peut être formellement vérifiée, il est probable que BigML utilise des instances de AWS et bénéficie en conséquence du SLA d’Amazon.

PST se démarque nettement des autres solutions envisagées, puisque la qualité de service et la confidentialité des données dépendra de l’environnement dans lequel cette solution sera mise en œuvre. Moyennant la mise en œuvre de certaines mesures de protection de cet environnement, la confidentialité des données devrait être assurée. Leur protection, en particulier afin d’éviter leur perte, demandera cependant un investissement qui peut s’avérer conséquent si l’utilisateur ne dispose pas au préalable d’une infrastructure proposant les services la garantissant. Lorsque PST est utilisé conjointement à Spark, une solution telle que HDFS peut être utilisées afin de répliquer automatiquement les données analysées.

SLA des fournisseurs de services SLA du service de prédiction
Amazon 99,95 %  S3 Standard : 99,9 %
S3 Infrequent Access : 99,0 %
Google 99,9 %  DRA : 99,0 %
Standard : 99,9 %
 Azure ML  99,9 % — 99,95 % 99,9 %
BigML Sur demande  NA

Conclusion

Un premier choix doit s’opérer entre, d’une part, une solution de machine learning « packageable » (telle que PST) et une solution de MLaaS. La première apporte une simplicité du modèle économique, un contrôle total des tâches réalisées et une grande diversité d’algorithmes disponibles, tandis que la seconde permet de se dispenser de la gestion d’une infrastructure matérielle et logicielle pour se concentrer sur ce qui produit de la valeur, à savoir l’analyse de données pour prédire des résultats.

La faiblesse de l’offre de Google en termes d’algorithmes disponibles pourrait limiter son usage à un sous-ensemble des besoins rencontrés par une entreprise. Il est nécessaire de se demander si ces besoins finiront par ne plus être satisfaits par l’offre de Google Prediction. En cas de réponse négative, Google Prediction peut s’avérer être une solution simple et rapide à mettre en œuvre. Cette solution peut également présenter de l’intérêt lorsque l’utilisateur dispose de modèles dont il peut tirer profit : il est alors possible d’exploiter à grande échelle et très simplement les modèles créés au préalable.

Amazon propose une solution relativement peu onéreuse, mais complexe dans ses options. Amazon ML permet l’utilisation des algorithmes les plus souvent utilisés en machine learning ainsi que l’utilisation de « recettes » qui permettent leur configuration de manière relativement simple et complète.

Azure ML est certainement la solution la plus aboutie en ce qui concerne les services offerts. Son Studio, qui permet une préparation visuelle et simple des algorithmes utilisés, peut être un atout décisif auprès des utilisateurs souhaitant s’impliquer modérément dans les arcanes du machine learning, tout en offrant la possibilité de recourir à des algorithmes très spécifiques et très variés, grâce à son ouverture aux langages Python et R.

Lorsqu’il est utilisé avec de gros volumes de données d’entraînement, BigML présente un coût de mise en œuvre prohibitif. Cette solution n’est donc, en l’état, pas adaptée à un usage de type Big Data. Si les données d’apprentissage ont un volume se limitant à quelques dizaines de Mo, BigML pourrait cependant s’avérer intéressant de part à ses fonctionnalités simples et pratiques, ainsi que son système de tarification au mois, ce que ne proposent pas ses concurrents. Cette solution propose également la collecte de données depuis des sources qui, bien que non traditionnelles, peuvent faire partie intégrante de l’infrastructure informatique de l’utilisateur. L’intégration de BigML dans cette infrastructure en sera alors facilitée.

Dans la plupart des situations, le déploiement de PST sur une solution IaaS n’est intéressant que si au moins une des conditions suivantes est vérifiée :

  • L’utilisation d’un algorithme précis, ou la connaissance de sa configuration exacte, est nécessaire.
  • Le système ne doit pas être constamment disponible pour réaliser les prédictions. Au contraire, toutes les prédictions peuvent être réalisées en une période de temps restreinte (par exemple, le premier jour du mois).
  • L’importation et/ou l’exportation des modèles prédictifs est nécessaire.

Notes
[1] nécessite 1 ligne de Python
[2] indirectement : intégré au modèle prédictif.
[3] Prévu dans « un futur proche » depuis mars 2015. Réalisable indirectement via des scripts Python/R.
[4] Mais, en soi, synchrone.
[5] Le coût exact dépend du volume stocké.
[6] Le coût exact dépend du volume stocké.
[7] idem
[8] Tarifs minimum et maximum de location d’instances pour MySQL.
[9] Durable Reduced Availability : La disponibilité des données n’est pas garantie. Cela est approprié notamment pour les opérations en batch, pour lesquelles une reprise partielle après indisponibilité est possible.
[10] r3.2xlarge
[11] n1-highmem-8
[12] D13 v2
[13] r3.2xlarge
[14] n1-highmem-8
[15] D13 v2
[16] r3.2xlarge
[17] n1-highmem-8
[18] D13 v2
[19] r3.2xlarge
[20] n1-highmem-8
[21] D13 v2
[22] r3.2xlarge
[23] n1-highmem-8
[24] D13 v2