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.
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.
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.
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.
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 |
fichier texte
HTTP(S) S3 Azure Storage 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. |
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.
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.
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.
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 |
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
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.
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.
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.
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.
Le coût financier d’une solution de machine learning dépend principalement des facteurs suivants :
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.
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 |
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 |
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.
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.
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.
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.
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 |
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 |
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 |
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 |
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 |
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.
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.
Amazon | 99,95 % | S3 Standard : 99,9 % |
S3 Infrequent Access : 99,0 % | ||
99,9 % | DRA : 99,0 % | |
Standard : 99,9 % | ||
Azure ML | 99,9 % — 99,95 % | 99,9 % |
BigML | Sur demande | NA |
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 :
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
[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