Suite à la parution du quadrant Gartner de 2019, je vous propose de rentrer dans le détail de l’offre Microsoft pour la Data Science.
Précisons d’emblée que les éléments évoqués ci-dessous ne rentrent pas tous dans les critères de Gartner. Néanmoins, ce sont des outils à disposition pour les équipes de Data Scientists / Data Engineers.
Voici ce que Gartner déclare à propos de Microsoft :
Microsoft is based in Redmond, Washington, U.S. It provides a number of software products for data science and ML. In the cloud, it offers Azure Machine Learning (including Azure Machine Learning Studio), Azure Data Factory, Azure HDInsight, Azure Databricks and Power BI. For on-premises workloads, Microsoft offers Machine Learning Server. Only Azure Machine Learning met the inclusion criteria for this Magic Quadrant, although Microsoft’s broader offerings did influence our assessments of Azure Machine Learning’s extended capabilities and Microsoft’s Completeness of Vision.
Microsoft remains a Visionary, having maintained a strong commitment to breadth and ease of open-source technology integration and excellence in relation to deep learning. Azure Machine Learning is not an option for the many data science teams and use cases that require a strictly on-premises product.
Dont nous retiendrons en particulier le passage suivant :
Seul Azure Machine Learning répondait aux critères d’inclusion de ce Magic Quadrant, bien que les offres plus larges de Microsoft aient influencé nos évaluations des capacités étendues d’Azure Machine Learning et de la vision intégrale de Microsoft.
Il faut ici préciser qu’il n’existe plus officiellement de produit nommé Azure Machine Learning, puisque celui-ci a été renommé Azure Machine Learning Studio. Une autre brique se nomme Azure Machine Learning Service mais n’interagit en aucune façon avec la précédente. Cet article décrira ces différentes solutions.
Pour un usage local
Pour comprendre la stratégie de Microsoft, il faut revenir tout d’abord sur l’annonce faite début 2015 du rachat de Revolution Analytics par Microsoft. La librairie d’algorithmes distribués RevoScaleR intègre ainsi la base de données SQL Server comme un quatrième service (« R Services ») permettant de traiter les données en encapsulant du code R dans des scripts T-SQL. C’est l’approche nommée In DataBase Analytics.
Avec un regard critique, on peut s’interroger sur le mélange des genres dans un même serveur : stockage et code pour le traitement pouvant demander ponctuellement des pics de ressources importants. Il est ici difficile de trouver le bon choix d’architecture.
Une alternative consiste à utiliser uniquement le moteur d’exécution du code au moyen de la déclinaison R Server. Celui-ci exploite les machines virtuelles d’une grappe (cluster) et l’on exécute le code depuis RStudio à l’aide d’une remote connection disponible au travers du package mrsdeploy.
En 2017, Microsoft ajoute Python dans les langages externes disponibles pour l’exécution du code et rebaptise les deux outils « ML Services » (dans SQL Server) et ML Server (autonome). L’apparition de Python, avec le développement conjoint du package revoscalepy, marque chez Microsoft une ouverture complète aux deux langages phares de la Data Science.
Au travers du cloud Azure
Dans le monde du cloud public Microsoft, il existe une foultitude de services utiles pour la Data Science, nécessitant des compétences plus ou moins poussées en développement.
Azure Machine Learning Studio, le précurseur « user friendly »
Le service historique de Microsoft en matière de Machine Learning a été renommé Azure Machine Learning Studio et c’est principalement celui-ci qui est évalué dans les cadrans Gartner depuis son apparition. Il s’agit d’une interface web où l’utilisateur déplace les briques d’un pipeline de Data Science allant de la connexion aux données sources jusqu’à la création d’un service web prédictif. En quelques heures, des néophytes peuvent prendre en main cette interface et avec quelques notions sur l’entrainement, le test et l’évaluation, mettre en place une expérience complète. Mais les Data Scientists savent qu’une grande partie de l’efficacité d’un algorithme dépend des données choisies, nettoyées voire transformées (« feature selection and engineering »). Peu de composants natifs répondent correctement à ces besoins et il sera rapidement nécessaire de coder en R ou en Python.
Une limite à cet outil réside dans la difficulté à maîtriser les ressources de calcul de la plateforme. Notons également son absence de portabilité : il vous sera impossible d’exporter les pipelines pour les exécuter localement ou dans un autre environnement.
A mon sens, cet outil reste un excellent vecteur de formation au Machine Learning et permet en quelques heures de déployer une preuve de concept de A (chargement des données) à Z (déploiement d’un service web).
Autour du lac de données
Aux origines du bouleversement de la Big Data, nous trouvions un système de fichiers distribué : HDFS. S’il s’est appuyé sur la technologie WebHDFS pour son premier Data Lake, Microsoft oriente maintenant la 2e génération de Azure Data Lake Storage autour de la notion de compte de stockage et de blob. Principale différence avec le compte de stockage basique : l’acceptation d’une organisation hiérarchique des fichiers.
Un client local, Azure Storage Explorer, permet de visualiser et piloter le contenu du Data Lake même si l’on préférera utiliser des solutions plus automatiques pour l’entrée des données dans le lac comme par exemple Azure Data Factory et son interface graphique en version 2.
L’exploitation des données situées sur le lac peut se faire avec une solution managée Azure Data Lake Analytics, offrant un nouveau langage, le U-SQL, hybride entre le T-SQL et le .NET, pouvant intégrer des portions de scripts R ou Python. Mais l’on pourra également interagir avec les données du lac au travers d’un framework proche du monde Apache : Azure Databricks.
Dans un environnement Spark
Databricks est une société fondée par les créateurs du produit Open Source Apache Spark, framework pour le calcul distribué, travaillant principalement en mémoire, et ayant supplanté l’approche MapReduce des débuts de l’ère Big Data. Un partenariat lancé en 2017 avec Microsoft a permis de rendre accessible la solution Azure Databricks sur le portail cloud.
Là encore, il s’agit d’un service managé, même si l’utilisateur définira à la création du cluster, le nombre et le type de machines virtuelles Azure qui constitueront les différents nœuds. Notons une fonctionnalité tout-à-fait pertinente qu’est l’auto-scalabilité du nombre de nœuds sollicités. Le cluster se met également en pause (et la facturation des VM s’arrête) au bout d’un temps défini par l’utilisateur.
Concrètement, nous travaillerons dans l’environnement Databricks au moyen de notebooks de type Jupyter, autorisés aux langages Scala (natif de Spark), Python ou R. Les « commandes magiques » des notebooks autorisent l’emploi de syntaxes SQL. Une utilisation pratique consistera à monter (« mount ») le Data Lake Azure et ainsi à en bénéficier comme d’un lecteur propre au cluster, simplifiant les syntaxes de lecture et d’écriture des données.
Azure Function Apps, la solution Python « serverless »
Encore en préversion, il s’agit toutefois de la solution la plus simple pour lancer du code Python lorsque les sources de données sont des fichiers présents sur un stockage Azure comme Blob Storage.
Le fait le plus notable de cette approche est de ne payer qu’à l’exécution du code, que l’on aura pris soin de tester en local au préalable. L’ajout de librairies supplémentaires se fait relativement facilement à l’aide d’une connexion à distance.
Peu d’espoir toutefois de voir le langage R rejoindre les différents langages proposés dans Azure Function Apps.
L’intelligence Artificielle « as a service »
Si la Data Science aime travailler les données numériques, les données non structurées que sont le texte, les images, le son, la vidéo doivent être prétraitées pour revenir sous la forme de matrices numériques. Et ces matrices demanderont sans doute des algorithmes comme les réseaux de neurones profonds (Deep Learning) pour révéler toute leur intelligence.
Mais entraîner des modèles de Deep Learning demande à la fois des quantités de données d’entrainement conséquentes et une puissance de calcul, souvent réservée aux processeurs graphiques (GPU). Les acteurs du GAFAMI disposent de ces éléments et les acteurs du cloud public mettent à disposition des services web dits « cognitifs » réalisant des opérations de vision, text to speech, speech to text, Q&A, recommandation, etc. Ces services sont souvent facturés à l’interrogation mais le coût reste faible au regard de la somme de travail qui permettrait d’obtenir un résultat équivalent. Microsoft décline ainsi de nombreux « Cognitive Services ». Une évolution récente permet de ne prendre qu’une seule souscription Azure et d’accéder à toute la variété de services grâce à une clé unique. Ici encore, le langage Python s’imposera aux Data Scientists pour exploiter ces API.
Et autour des données relationnelles ?
En début d’article, j’évoquais ML Services qui est bien sûr disponible si l’on utiliser SQL Server au travers d’une machine virtuelle Azure. La solution la plus simple, car déjà configurée, réside dans la Data Science Virtual Machine.
Malgré une première tentative, ML Service n’est pas encore disponible pour Azure SQL DB, c’est-à-dire dans un mode de fonctionnement PaaS (Platform as a Service).
La solution ML Server est quant à elle disponible dans une version prête au déploiement, facilitant grandement la configuration du cluster, pour une première preuve de concept : Machine Learning Server Operationalization One-box.
Pour la mise en production
Posons tout d’abord les conditions propices à une mise en production du Machine Learning, dans son cadre supervisé. Il sera indispensable de préparer la donnée pour qu’elle corresponde aux entrées du modèle de régression ou de classification. Nous embarquerons le code nécessaire dans un environnement d’exécution capable de tenir la charge de la volumétrie ou de la vélocité des données (souvenez-vous, deux des trois V de la Big Data). Ensuite, nous attendrons le résultat de la prévision calculée par le modèle en lui-même, que l’on peut voir finalement comme une série de poids des variables d’entrée. Ici, le fonctionnement au travers d’un API sera apprécié, le service donnant simplement la réponse (estimation du label) à la question qui lui est posée (features en entrée).
Outre l’adaptation à la charge (scalabilité), un environnement de production de Machine Learning devra permettre l’archivage et l’évolution des algorithmes. Dans une stratégie d’AB testing, une nouvelle version de l’algorithme, suite à un nouvel entrainement, dépassera peut-être les performances de la précédente version, sur la foi des métriques d’évaluation. Mais il sera indispensable de conserver la formule qui a réalisé une prévision dans le passé car la suite de la chaîne d’actions sur la donnée a certainement pris des décisions. N’oublions pas que si celles-ci concernent des personnes physiques, le nouveau cadre législatif européen (GDPR) autorise les autorise à demander une explication des prises de décision réalisées au moyen de la donnée (pensons par exemple à un refus de crédit bancaire ou d’assurance). Pour répondre à ces besoins, nous trouvons ici la solution Azure Machine Learning Service qui permettra de stocker un python (par exemple au format pickle pour Python), sous différentes versions, d’y associer une ressource de calcul (compute) puis de créer et déployer une image Docker qui contiendra le nécessaire au bon fonctionnement d’un service web réalisant les prévisions à la réception de nouvelles données.
Sous forme de conclusion, voici un autre « cadran » réalisé en notant, de manière très personnelle et subjective, les différents produits présentés dans cet article, sur deux axes :
- La difficulté / facilité de mise en œuvre
- L’efficacité selon le volume de données, de faible (échelle du gigaoctet) à fort (échelle du téraoctet ou plus).
Paul PETON – Microsoft AI MVP
Partager cet article