Apprendre des données pour mieux anticiper [2/3]

Décrire, approfondir, prédire sont les trois étapes d’une analyse avancée de données, auxquelles il est possible d’ajouter « prévenir » ou « prescrire » qui sont l’aboutissement d’une stratégie pilotée par la data.

Nous avons vu dans un précédent billet comment l’approche statistique permettait d’identifier des facteurs explicatifs dans les données, en particulier quand une variable est centrale dans l’analyse et qu’elle joue le rôle de variable à expliquer. Il s’agit tout simplement de la donnée qui répond à la problématique principale : le chiffre d’affaires ou la marge pour une entreprise, le taux de conversion pour un site de e-commerce, la présence d’une pathologie ou dans l’exemple que nous reprenons ci-dessous, la gravité d’un accident pour la sécurité routière.

L’apprentissage automatique supervisé

Nous entrons ici dans la discipline dite du Machine Learning ou apprentissage automatique. Le Machine Learning se base sur des événements passés pour construire un modèle statistique qui sera ensuite appliqué à de nouvelles données (ici, les caractéristiques d’un accident de la route). En fonction de ces données et du modèle, une prévision du résultat (la variable à expliquer, ici la gravité de l’accident) sera rendue, accompagnée d’une probabilité exprimant la chance ou le risque qu’un tel résultat se produise.

Lorsque la variable prédite est catégorielle, voire au plus simple, binaire, on parle de techniques de classification. Certaines méthodes de classification ont fait leurs preuves depuis de nombreuses années : régression logistique, arbre de décisions, Naïve Bayes. Elles ont été, avec l’essor du Big Data, complétées par des algorithmes puissants mais gourmands en ressources de calcul comme les forêts aléatoires (random forest) ou le Gradient Boosting (XGBoost),

Une approche de développement : le langage Python

Les Data Scientists disposent aujourd’hui d’un grand panel d’outils pour travailler la donnée et entraîner des modèles de Machine Learning. Il existe ainsi des plateformes graphiques permettant de construire le pipeline de données (la Visual Interface d’Azure Machine Learning Service, Alteryx, Dataïku DSS, etc.). Une autre approche, souvent complémentaire, consiste à utiliser un langage de développement comme R, Python ou encore Scala, ce dernier pour une approche distribuée dans un environnement Spark.

Lorsque la volumétrie de données permet de travailler en plaçant le jeu de données (dataset) complet en mémoire, les langages R et Python sont tout à fait appropriés. Nous choisirons ici Python pour la simplicité d’usage et l’efficacité de sa librairie dédiée au Machine Learning : scikit-learn.

Les développeurs apprécieront d’utiliser un environnement de développement intégré (IDE) comme Visual Studio Code ou PyCharm. Pour donner plus de lisibilité à notre code, nous choisissons pour cet article de travailler dans un notebook Jupyter qui permet d’alterner dans une même page, code, sorties visuelles et commentaires.

Le service Azure Notebooks est accessible gratuitement sur cette URL : https://notebooks.azure.com/

Afin de maîtriser les ressources de calcul qui seront associées à l’exécution des traitements, il est également possible de souscrire à un espace de travail Azure Machine Learning Service. Celui-ci permet de lancer une machine virtuelle de son choix sur laquelle sont déjà configurés les notebooks Jupyter ainsi que l’environnement Jupyter Lab.

Dans la fenêtre Jupyter Lab ci-dessous, nous retrouvons le code à exécuter ainsi qu’un menu latéral permettant de naviguer dans les fichiers précédemment téléchargés dans l’environnement.

L’indispensable préparation des données

Avant de soumettre les données chargées à l’approche algorithmique, il est nécessaire d’effectuer quelques calculs préparatoires pour mettre en forme les données et les rendre utilisables par les différents algorithmes.

Ainsi, la date et l’heure de l’accident sont exploitées pour créer deux nouvelles variables : le jour de la semaine et la tranche horaire.

Ces deux calculs illustrent le principe du feature engineering, c’est-à-dire du travail sur les variables en entrée du modèle pour proposer les plus pertinentes et les plus efficaces. Attention, il n’est parfois pas possible de le déterminer a priori. Au-delà de toute formule mathématique et en l’absence d’une quelconque baguette magique, des échanges avec les personnes ayant une connaissance métier forte seront très profitables aux Data Scientists et les orienteront vers une bonne préparation des données.

Modéliser, entraîner, évaluer

Nous comparons ici deux modèles, l’un étant un modèle « simple » : celui des K plus proches voisins, le second étant un modèle « ensembliste », c’est-à-dire combinant plusieurs modèles : une forêt aléatoire d’arbres de décisions.

Une fois l’entraînement réalisé, nous pouvons calculer différentes métriques évaluant la qualité des modèles.

Nous observons tout d’abord la matrice de confusion qui nous permet de comparer la valeur prédite (décès ou non) avec la valeur réelle qui a été « oubliée » le temps du calcul de la prévision.

Nous observons ici 6 449 « faux positifs », personnes réellement décédées suite à l’accident, pour lesquelles l’algorithme n’a pas été en mesure de prévoir ce niveau de gravité. Il sera possible de jouer sur le seuil de la probabilité de décès (par défaut à 50%) pour réduire ce nombre.

Une vision graphique de ces informations est possible au travers de la courbe ROC et du calcul de l’aire situé sous cette courbe : l’AUC. Cet indicateur prend une valeur en 0 et 1 et plus celle-ci s’approche de 1, meilleur est le modèle.

Nous retenons ici le modèle de la forêt aléatoire (AUC = 0.730 contre 0.597), tout en étant bien conscients que son coût de calcul est plus élevé que celui des K plus proches voisins. Une propriété de l’objet nous permet d’obtenir un coefficient d’importance des variables dans le modèle. Cette information est particulièrement appréciable pour prioriser par exemple une campagne d’actions contre la mortalité sur les routes. Nous remarquons dans le top 10 ci-dessous que l’année de naissance de la personne, et donc son âge au moment de l’accident, constitue le facteur le plus aggravant. Viennent ensuite des informations sur la temporalité de l’accident (tranche horaire, mois, etc.) puis enfin le motif de déplacement (trajet), la déclivité de la route (prof), le type de collision (col), le nombre de voies (nbv) et le tracé de la route (plan). Ces derniers facteurs sont toutefois 4 à 5 fois moins importants que l’âge de la personne impliquée.

Le meilleur modèle est enfin enregistré dans un format binaire sérialisé (package pickle) afin d’être exploité par la suite en production, comme le permet par exemple la ressource Azure Machine Learning Service.

Plus vite vers le meilleur modèle : l’Automated Machine Learning

Le travail de sélection du meilleur modèle (ainsi que de ces meilleurs hyper paramètres, c’est-à-dire le réglage fin de l’algorithme) peut s’avérer une tâche répétitive et fastidieuse car il n’existe pas réellement à l’heure actuelle de méthode ne nécessitant pas de réaliser toutes les évaluations. « No free lunch » !

Heureusement, l’investigation peut se faire de manière automatique, sorte de « force brute » du Machine Learning. Au travers d’Azure Machine Learning Service, nous soumettons le jeu de données à une batterie d’algorithmes qui seront comparés selon leur performance sur les différentes métriques d’évaluation.

Nous retenons ici l’approche XGBoostClassifier dont l’AUC atteint la valeur 0.867, soit 0.137 point supplémentaire, par rapport au modèle trouvé manuellement.

L’approche prédictive, au travers du Machine Learning, se révèle être incontournable pour quiconque souhaite aujourd’hui anticiper les valeurs de ses données et découvrir des leviers d’action qui permettront de mettre en place des actions concrètes pour par exemple, éviter l’attrition (churn) d’une clientèle, prévenir d’un défaut de paiement ou d’une tentative de fraude, élaborer un premier diagnostic ou encore anticiper des pannes.

En conclusion, nous avons vu ici que le cloud Azure se marie au meilleur de l’Open Source pour devenir une plateforme parfaite pour les Data Scientists et les Data Engineers.

Data Analytics, back to basics ! (*) [1/3]

(*) Revenir à l’essentiel : l’analyse des données !

Intelligence Artificielle, Machine Learning, RGPD… la donnée ne quitte plus le devant de la scène médiatique, qui attribue bien souvent à la data des pouvoirs thaumaturges. Le monde du recrutement s’emballe autour des profils « Data Scientists » tout en présentant des listes de compétences impossibles à maîtriser pour une seule et même personne, allant de l’architecture Big Data à la programmation de réseaux de neurones convolutifs (le fameux Deep Learning). A l’exception des entreprises dont la data constitue le cœur de métier comme Booking, AirBNB ou Uber, quelles sont celles qui ont réellement modifié et amélioré leur activité par une approche « data driven », c’est-à-dire pilotée par la donnée ? Ce phénomène de « hype » autour de la donnée peut poser question et générer une certaine méfiance.

Pourtant, une réaction inverse qui reviendrait à rejeter tout apport de la donnée serait aussi improductive. Et tant qu’à stocker la data, autant en tirer profit ! Dans une série de trois articles, nous nous arrêterons successivement sur l’intérêt, pour les entreprises, de l’analyse de données exploratoire, l’analyse prédictive grâce au Machine Learning et les promesses du Deep Learning sur les données non structurées.

Une même finalité, de nouveaux outils

Bien avant l’explosion de l’engouement pour la Data Science, certaines personnes dans l’entreprise pratiquaient déjà l’analyse de données sous des intitulés de poste tels que « chargé.e d’études statistiques », « statisticien.ne », « actuaire », « data miner », etc. Souvent éloignées du département IT et des architectures de production, ces personnes en charge de forer la donnée réalisent des extractions puis travaillent ces échantillons dans un classeur Excel ou un logiciel spécialisé. Une fois les conclusions obtenues, celles-ci figurent dans une présentation au format Word ou PowerPoint, c’est-à-dire sans possibilité simple de mise à jour ni d’extension à d’autres données. Nous allons voir ici que c’est aujourd’hui, non pas un bouleversement méthodologique, mais bien une simplification et une meilleure performance des outils qui changent ces métiers.

Notre approche méthodologique visera à répondre aux quatre temps de l’analyse de données.

*Les quatre temps de l’analyse de données*

Prenons un exemple concret : l’analyse des accidents corporels de la circulation pour laquelle les données sont disponibles en open data sur le portail data.gouv.fr.

Pour une première approche du jeu de données, nous travaillerons dans l’outil Microsoft Power BI Desktop qui, même s’il n’est pas un logiciel statistique à proprement parler, permet de nettoyer et visualiser les données très rapidement. Nous verrons même qu’il cache plusieurs fonctionnalités analytiques particulièrement intéressantes. Enfin, lorsque l’étude exploratoire sera terminée, il ne sera plus nécessaire de quitter l’outil pour présenter les résultats dans un logiciel bureautique figé. L’interface proposera une visualisation dynamique et adaptée à la restitution.

L’indispensable nettoyage des données

Observons tout d’abord le schéma des données collectées, dont la description précise des champs est disponible dans ce document. Nous travaillerons ici avec les notions de :

Caractéristiques de l’accident
Lieu de l’accident
Véhicules impliqués
Usagers des véhicules impliqués

Modélisation des données dans Power BI Desktop

La qualité des données en entrée déterminera la qualité des résultats qui seront obtenus (ou tout du moins, garbage in, garbage out !). Un travail d’inspection de chaque champ est nécessaire et celui-ci se fait rapidement grâce au profil de la colonne, comme par exemple ci-dessous, sur l’année de naissance de l’usager.

La lecture des indicateurs de synthèse (moyenne, médiane, écart-type, etc.) nous permet de débusquer des valeurs aberrantes (un conducteur né en 1924, cela reste plausible) et de comptabiliser des valeurs manquantes qui nécessiterait un traitement spécifique (ici, toutes les lignes sont renseignées.)

L’interaction pour une meilleure exploration des données

L’une des grandes forces de Power BI réside dans son haut niveau d’interaction avec la donnée, au moyen de filtres visuels ou en sélectionnant un élément graphique pour obtenir instantanément la mise à jour des autres visuels.

L’analyse descriptive est ainsi rapidement obtenue. A vous de jouer, ce rapport est totalement interactif !

Bien sûr, il ne faudra pas tomber dans le travers de chercher à filtrer sur toutes les dimensions possibles ! L’être humain n’est pas en capacité d’appréhender un trop grand nombre d’informations mais les méthodes d’analyse avancée sont là pour nous aider.

Des fonctionnalités pour l’analyse explicative

Observons l’évolution du nombre d’accidents dans le temps, au niveau annuel. On constate une hausse en 2016 avec un recul des accidents sur les années précédentes.

Power BI va rechercher les facteurs explicatifs de la hausse de l’indicateur en testant tous les champs du modèle et nous fera plusieurs propositions. Nous retenons ici celle du département de l’accident qui met en évidence une hausse significative sur les départements d’Ile-de-France 75 et 93, contre une baisse dans les Alpes-Maritimes. Cette piste nous mettrait sur la voie de données décrivant ces départements (population, infrastructures routières, etc.).

Visuels générés automatiquement par Power BI : l’utilisateur choisit le plus parlant.

L’analyse faite jusqu’ici nous permet de comprendre les données dans leur ensemble mais il est fondamental de répondre à une problématique levée par le sujet, ici l’accidentologie, et nous allons donc rechercher des explications à la mortalité routière.

Nous disposons pour cela d’une information sur la gravité de l’accident qui permet de déterminer si l’usager est décédé.

Influenceurs clés : une régression logistique visuelle !

L’analyseur d’influenceurs clés (key influencers, basé sur une approche de modélisation par régression logistique) identifie la non utilisation d’un équipement de sécurité (ceinture, casque, etc) comme le facteur le plus fort dans un décès lié à un accident : la probabilité est presque multipliée par 6. L’âge est également un facteur très important. Si celle-ci est inférieure à 1932, le risque de décès est ici multiplié par 4.

Nous obtenons ici, grâce à l’analyse, des leviers d’actions concrets pour la sécurité routière, ce qui constitue une première forme d’analyse prescriptive

… et une première analyse prédictive !

Reprenons l’évolution du nombre d’accidents dans le temps mais cette fois-ci, au niveau mensuel. La courbe traduit clairement une notion de saisonnalité : il y a beaucoup (trop) d’accidents lors des périodes de vacances scolaires par exemple. Si l’on ajoute une droite de tendance, on voit que celle-ci est légèrement à la hausse. Prolonger cette droite ne donnerait pas une bonne prévision au détail mensuel puisqu’il faut tenir compte de cette saisonnalité.

Nous utilisons ici la fonctionnalité de « forecast » de Power BI basée sur la méthode statistique du lissage exponentiel. N’allons pas trop loin, il est conseillé de ne pas dépasser une prévision au tiers de l’historique disponible. Cette prévision est encadrée par un intervalle de prévision, donnant les bornes entre lesquelles on espère voir apparaître la « vraie » valeur, avec un niveau de confiance de 95%.

On obtient alors la prévision sur le graphique et l’infobulle donne les valeurs chiffrées.

Une présentation dynamique sans changer d’outil

Résumons maintenant toutes les informations découvertes au travers de cette première analyse. Pour communiquer ces résultats, nous pourrions utiliser un support externe comme PowerPoint ou un fichier PDF mais nous perdrions toute interaction. Les bookmarks (ou signets) de Power BI sont ici un outil extrêmement pratique pour garder en mémoire une sélection personnalisée de filtres et enchainer la lecture de plusieurs pages de rapport comme l’on enchainerait des diapositives.

Signets dans Power BI : un outil de story telling

Certification DP-100 Designing and Implementing a Data Science Solution on Azure (1/4)

Cette certification Microsoft a vu son contenu complètement remis à jour au 22 janvier 2020. Le contenu tourne maintenant exclusivement autour de Azure Machine Learning Service. Mais ce service Azure et son portail d’accès (dit le « studio ») regorgent d’outils aussi bien graphiques (Designer, Automated ML) que destinés au code (SDK et la librairie azureml.core). Dans cet article, je vous propose mes notes préparatoires à cette certification, en conservant la terminologie d’origine et non la traduction française car la certification se passe en anglais.

A la question qui m’est fréquemment posée sur les conseils pour réussir les certifications Microsoft, je réponds toujours : de la pratique, de la pratique et encore de la pratique. Prenez également soin de noter les noms des différents services ainsi qu’une courte définition de leurs rôles respectifs.

Page d’accueil de la certification DP-100

Si vous n’avez jamais passé de certifications Microsoft, sachez qu’il s’agit essentiellement de QCM et que vous pourrez revenir en arrière sur la plupart des questions, à l’exception des « Yes/No questions ».

La formulation « May include but is not limited to» qui revient tout au long du programme de la certification met en garde sur le fait que certaines questions pourront sortir de cette liste.

Set up an Azure Machine Learning workspace (30-35%)

Create an Azure Machine Learning workspace

May include but is not limited to:

create an Azure Machine Learning workspace

Le workspace (ou espace de travail) désigne la ressource Azure qu’il est nécessaire de créer afin d’accéder aux fonctionnalités d’Azure ML Service et en particulier au portail encore appelé « studio ». Ce dernier est aussi accessible depuis l’URL https://ml.azure.com/ et attend votre identifiant et mot de passe reconnu par Azure Active Directory.

Le terme « studio » peut porter à confusion car la première ébauche du Designer s’est appelée Azure Machine Learning à sa création, puis Azure Machine Learning Studio. Il est encore possible de s’inscrire sur cette ressource renommée « classic » et accessible sur l’URL https://studio.azureml.net/ sans inscription préalable sur le portail Azure. Cette interface correspond aujourd’hui au Designer (Concepteur en français) qui s’est lui-même rapidement appelé « Visual interface ».

Depuis la Marketplace Azure, dans la catégorie AI + Machine Learning, rechercher le service « Machine Learning ».

Aucun paramétrage particulier si ce n’est le choix de la licence entre Basic et Enterprise. Nous indiquerons plus tard les fonctionnalités uniquement disponibles en version Enterprise.

A noter que la création de cette ressource engendrera la création simultanée :

d’un compte de stockage (Azure Storage)
d’un coffre fort (Azure Key Vault)
d’un outil de monitoring (Azure Application Insights)

Par la suite, de nouveaux services pourront être ajoutés, pour l’exposition des services prédictifs :

Azure Container Instance
Azure Kubernetes Service

configure workspace settings

Le menu latéral de l’interface Azure donne les entrées classiques d’une ressource. Le groupe de fonctionnalités Assets correspond à l’ensemble des manipulations qui pourront être faites depuis le portail dédié.

On définira en particulier l’accès des autres personnes à la ressource en configurant l’Access Control (IAM).

Il est également possible de télécharger un fichier de configuration JSON dont nous comprendrons l’intérêt lorsque nous réaliserons des interactions avec les fonctionnalités depuis un script.

Celui-ci contient les informations suivantes :

{
  "subscription_id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX", 
  "resource_group": "YYYYYYYYY",
  "workspace_name": "ZZZZZZZZZ" 
}

Enfin, La page de la ressource Azure donne le lien vers le studio et lancera le portail dédié dans un nouvel onglet du navigateur.

Connexion au portail Azure Machine Learning studio

manage a workspace by using Azure Machine Learning Studio

A partir de cet item du programme, nous passons sur le portail (dit « studio »), à ce jour (février 2020) toujours en préversion. La barre latérale permet de naviguer dans les différentes parties du studio dont deux uniquement sont exclusives à la licence Enterprise : Automated ML et Designer.

Les seuls paramètres disponibles concernent la langue d’affichage et les formats régionaux. Pour préparer la certification, nous recommandons d’utiliser l’anglais pour l’interface.

Si l’on dispose de plusieurs ressources Azure ML Service, sur une ou plusieurs souscriptions, il sera possible de passer de l’une à l’autre sans quitter le portail.

Manage data objects in an Azure Machine Learning workspace

May include but is not limited to:

register and maintain data stores

Les data stores sont des sources de données répertoriées dans le but de mettre ensuite à disposition des datasets.

La création d’un nouveau datastore se fait à partir de l’écran ci-dessous, pour l’instant uniquement à partir de ressources Azure de type compte de stockage (Blob, file share ou Data Lake) ou service managé de bases de données (SQL DB, PostgreSQL ou MySQL).

Les informations habituelles d’authentification seront attendues. Il n’est pas possible à ce jour de pointer vers un coffre-fort de type Azure Key Vault déjà paramétré.

Pour le paramétrage d’un compte de stockage, il faudra descendre du niveau du container, c’est-à-dire le premier niveau d’organisation des données.

L’étape suivante de création d’un jeu de données sera indispensable pour donner réellement accès aux données depuis les interfaces de traitement.

create and manage datasets

Les datasets (jeux de données) sont également créés depuis le menu latéral.

Cliquer ici sur le bouton « Create dataset ».

Les datasets sont issus des data sources définis préalablement (« from datastore ») mais peuvent aussi venir d’autres sources :

Fichiers locaux
Fichiers disponibles au travers d’une URL Web
Jeux de données issus d’Azure Open Datasets

Cette initiative de Microsoft met à disposition des jeux de données Open Data, très utiles pour tester rapidement un algorithme et prendre en main l’interface. J’utilise dans les exemples ci-dessous le jeu de données « diabetes ».

Une fois le jeu de données chargé, de nombreuses fonctionnalités sont disponibles.

Les datasets sont tout d’abord versionnés, il est donc possible de revenir à une version précédemment chargée.

Le bouton Refresh réalise l’actualisation du jeu de données.

La génération du profil (« Generate profile ») demande une ressource de calcul de type « training cluster » (voir ci-après).

La génération du profil est considérée comme « le run d’une experiment », notion qui sera revue plus tard.

Une fois la préparation terminée, le menu Explore donne les informations suivantes par variables :

Distribution
Type (string, integer, etc.)
Min, Max
Count, Missing count, Empty count, Error count

La fonctionnalité Unregister supprime simplement le jeu de données de l’interface, mais le datastore correspond est conservé.

Le menu Consume est particulièrement pratique puisqu’il donne les lignes de script Python permettant de charger le jeu de données sous forme de pandas dataframe.

Le menu Explore donne également un aperçu des lignes du jeu de données.

Le menu Models ne sera renseigné que lorsqu’un premier modèle aura été entrainé à partir du jeu de données.

Enfin, il reste une fonctionnalité très prometteuse : Datasets monitor. Si j’interprète bien la documentation, il s’agira de détecter l’éventuelle dérive prédictive d’un modèle de Machine Learning (ce que l’on nomme parfois silent failure).

Le monitoring peut être défini à des fréquentes quotidienne, hebdomadaire ou mensuelle.

Les alertes sont envoyées à une adresse email en cas de dépassement d’un seuil défini arbitrairement.

Manage experiment compute contexts

May include but is not limited to:

create a compute instance

Les cibles de calcul sont indispensables pour le lancement de tout traitement, quelque-soit l’outil mis en œuvre (notebook, pipeline, endpoint…). C’est aussi ce qui induit sur la facturation du service Azure. Tant que le service Azure Machine Learning est en préversion, il n’existe pas de coefficient multiplicateur sur le montant associé à la ressource de calcul.

Les compute instances (instance de calcul) remplacent dorénavant les « notebooks VM » comme annoncé ici.

Une instance de calcul se paramètre de la manière suivante :

Les instances de calcul disposent d’environnements et d’outils déjà installés pour R et Python, et en particulier le SDK Python d’Azure Machine Learning. Nous évoquerons ce SDK au cours des prochains points de cette préparation. Nous trouvons ainsi un raccourci pour lancer RStudio et deux autres pour Jupyter et JupyterLab sur lesquelles le kernel Python 3 sera disponible.

Pensez à arrêter vos instances de calcul une fois que vous ne les utilisez plus, afin d’arrêter la facturation (hormis celle associée au disque).

determine appropriate compute specifications for a training workload

Le tableau suivant, issu de la documentation officielle Microsoft, donne les correspondances entre les cibles de calcul et les différentes approches permettant de réaliser du Machine Learning.

Nous reviendrons plus tard sur la notion de pipeline. Celle-ci peut être comprise comme la succession d’étapes nécessaires dans un projet de Machine Learning : préparation des données (sélection des variables, normalisation…), entrainement du modèle, calcul des métriques d’évaluation, etc.

Les cibles de calcul doivent être différenciées des cibles de déploiement dont le rôle sera de porter le modèle prédictif une fois que celui-ci aura été entrainé et validé.

create compute targets for experiments and training

Un training cluster est un environnement managé constitué d’un ou plusieurs nœuds, qui ne sont autres que des machines virtuelles, dont les caractéristiques seront choisies lors de la création du training cluster. La documentation complète est disponible ici.

Le nouveau cluster apparaît alors dans la liste des ressources de calcul disponibles.

A l’inverse d’une instance de calcul, le training cluster ne peut être éteint mais il passera par différents états. En cliquant sur le nom du cluster, nous accédons aux compute details qui donnent en particulier l’état du cluster :

Idle
Leaving
Preparing
Running
Preempted
Unsuable

L’état Idle (inactif) correspond à l’état lorsque le cluster est arrêté.

Enfin, le menu attached compute permet d’associer une ressource Azure déjà créée et de l’utiliser ainsi pour des tâches réalisées dans Azure Machine Learning. Seules les machines virtuelles Linux Ubuntu sont supportées. Il est ainsi possible d’exploiter l’image Data Science Virtual Machine, préconfigurée avec les principaux packages utilisés en Data Science, et récemment mise à jour (fin 2019).

Afin de terminer le tour de ce menu, nous évoquons les cibles de déploiement que sont les inference clusters. Ceux-ci servirontpour supporter les Web services Web prédictifs, une fois qu’un modèle aura été entrainé et déployé. Ces clusters sont basés sur le service managé Kubernetes d’Azure et créeront une ressource correspondante dans le groupe de ressources contenant l’espace de travail Azure Machine Learning. Nous aborderons ce point dans le 4^e chapitre de la préparation à cette certification.

En version Dev-test, un seul nœud est proposé contre 3 minimum pour un cluster de production.

Nous terminons ici le premier chapitre du programme de la certification DP-100, nouvelle version. Celui-ci a permis de découvrir l’environnement de travail, les principales configurations et la mise à disposition des données, accompagnées par des ressources de calcul. Maintenant, il va être temps de coder !