Lorsque le Machine Learning permet d’identifier les sujets dit « tendance » de l’actualité - 6ème partie

En guise de 6^ème et dernière partie de cette série de billets – et oui tout a une fin ;) -, concentrons-nous sur l’automatisation des processus de partitionnement des données (clustering) sur les tags avec et sans prototypes et le processus de calculs des Tops et des Flops dans Azure.

Pour cela, nous vous proposons d’utiliser des tâches Web (WebJobs) avec le Kit de développement logiciel (SDK) Azure WebJobs.

Azure WebJobs permet d’exécuter facilement des scripts ou des programmes sous la forme de processus d’arrière-plan dans Azure App Service Web Apps. Dans la pratique, Azure WebJobs permet en effet de télécharger et d’exécuter un fichier exécutable comme un exécutable codé en C# avec le Framework .NET 4.5 mais aussi un cmd, bat, ps1, sh, php, py, js ou encore jar. Le SDK facilite l’utilisation d’Azure Storage. Il comporte pour cela un système de liaison (binding) et de déclencheur (trigger) qui fonctionne avec les objets blob Microsoft Azure Storage mais aussi les files d’attente, les tables ainsi que les files d’attente Service Bus.

Pour plus de détails sur les tâches Web au-delà de ce que nous allons couvrir dans ce billet, vous pouvez consulter l’article Ressources de documentation relatives à Azure WebJobs.

Les présentations rapides étant faites, rentrons dans le « vif » du sujet.

Le contexte

Afin de retrouver les résultats que sont les Tops et les Flops, 3 expérimentations Azure Machine Learning (Azure ML) sont nécessaires :

1. Clustering sur les tags avec calculs des prototypes.
2. Clustering sur les tags sans calculs des prototypes.
3. Calculs des Top et des Flops.

Autrement dit, chaque expérimentation nécessite sa propre tâche Web qui sera configurée pour s’exécuter automatiquement ou sur demande.

Qui dit 3 expérimentations, dit aussi développement d’une bibliothèque

Si nous jetons un coup d’œil à la solution finale telle que nous avons pu la mettre en œuvre, nous retrouvons une solution Visual Studio qui contient 5 projets :

1. Tâche Web pour le clustering avec calculs des prototypes : NRWebJobClusteringPrototypes.
2. Tâche Job pour le clustering sans calculs des prototypes : NRWebJobClusteringNoPrototypes.
3. Tâche Job pour les calculs des Tops et des Flops : NRWebJobTopFlop.
4. Bibliothèque avec le code métier : NRWebJobLib.
5. Bibliothèque de tests unitaires : NRWebJob.Tests.

Si nous considérons la première tâche Web de clustering avec calculs des prototypes, le code C# est équivalent à celui des 2 autres tâches Web mentionnées ci-avant :

Ces 3 tâches Web partagent en effet la même bibliothèque (ici NRWebJobLib) qui, après configuration (data dans l’exemple ci-dessous), créé une tâche d’exécution d'un batch, par appel à Batch.CreateBatchExecution, en invoquant le service Web déployé depuis Azure ML.

La bibliothèque NRWebJobLib contient deux classes : NRWebJob.Storage et NRWebJob.Batch.

La classe Storage contient un ensemble de fonctions qui permettent de manipuler un compte de stockage Azure, comme par exemple télécharger un fichier vers un blob Azure Storage.

La classe Batch, quant à elle, ne contient qu’une fonction CreateBatchExecution asynchrone qui prend en paramètre une structure de données contenant les informations de la requête illustré dans l’exemple ci-dessus.

Dans notre illustration, la classe Storage n’est utilisée que par la classe Batch en interne mais reste accessible de l’extérieur.

La structure de données BatchRequestParameter

Si nous décortiquons la structure de données BatchRequestParameter, nous trouvons 7 paramètres différents :

1. ApiKey : la clé API pour identifier notre programme auprès du service Web.
2. BaseURL : l’URL du service Web à appeler pour démarrer le job.
3. storageAccountKey : la clé de stockage pour accéder au compte de stockage Azure.
4. inputFileLocation: le fichier (en local) contenant les paramètres en entrée de la tâche sous forme de fichier .CSV.
5. inputBlobName: le blob dans le compte de stockage où se trouve le fichier qui contient les paramètres en entrée du job. Lorsque ce dernier est spécifié, il n’est pas nécessaire de télécharger le fichier local dans le compte de stockage.
6. localFileName: le nom du fichier (en local) qui contiendra les résultats en sortie de la tâche (sortie de l’expérimentation Azure ML).
7. outputBlobName: le nom du fichier dans le compte de stockage qui contiendra les résultats en sortie de la tâche (sortie de l’expérimentation Azure ML).

Les paramètres inputFileLocation et localFileName sont optionnels si les paramètres inputBlobName et outputBlobName sont définis dans la structure de données. Ces deux paramètres optionnels ont été ajoutés pour permettre d’avoir plus facilement une vue sur les paramètres en entrée et en sortie de la tâche.

Utiliser un fichier de configuration

Pour éviter de recompiler les tâches Web si une modification des services Web intervenait, chaque WebJob repose sur un fichier de configuration qui contient les paramètres liés aux expérimentations, à savoir :

1. Le nom de l’entrée de l’expérimentation Azure ML : ClusterExperimentInputName.
2. La clé API du service Web : ClusterExperimentApiKey.
3. L’URL du service Web : ClusterExperimentUrl.

Il s’agit du fichier App.config (XML) facilement accessible avec .NET et l’API ConfigurationManager (Cf. capture d’écran ci-dessus).

Exemple de App.config :

  <appSettings>

    <!-- Web Services Parameters -->

    <add key="ClusterExperimentInputName" value="input1" />

    <add key="ClusterExperimentApiKey" value="Experiment Api Key" />

    <add key="ClusterExperimentUrl" value="Experiment URL" />

  </appSettings>

Ainsi, si l’on veut tester des variantes des expérimentations, il n’est pas nécessaire de recompiler les tâches Web mais simplement modifier le fichier de configuration App.config.

Déploiement dans une Azure WebApp

Une fois nos tâches Web ainsi configurées et testées en local, il ne reste dès lors plus qu’à les déployer dans Azure. Pour ce faire, le portail Azure propose tous les outils nécessaires à l’utilisation des tâches Web.

Une fois la WebApp créée, nous pouvons ajouter des tâches Web configurables depuis le tableau de bord de la WebApp.

En cliquant sur AJOUTER UNE Tâche, une boîte de dialogue apparaît :

Il s’agit de spécifier :

1. Le nom de la tâche Web
2. Le fichier .ZIP contenant l’exécutable .NET 4.5de notre tâche Web (en mode Release) avec le fichier de configuration App.config associé.
3. Le mode d’exécution : Ici nous voulons planifier l’exécution pour démarrer tous les matins de la semaine à 9h00

La deuxième partie de la boîte de dialogue s’intéresse à la planification de la tâche Web :

Par exemple, nous voulons une tâche ponctuelle qui va s’exécuter tous les jours de la semaine à 9h00 à partir d’aujourd’hui. Une fois la tâche Web ajoutée, il apparaît dans la liste des tâches Web et sera automatiquement exécuté en suivant la planification.

Pour les « Trending Topics », la tâche Web était exécutée toutes les heures.

En guise de conclusion

Azure permet une mise en production simple et efficace des tâches Web et nous a ainsi permis de mettre rapidement en place l’automatisation des différents processus dans notre cas d’usage des « Trending Topics ».

Comme indiqué en début de ce billet, nous arrivons à la fin de notre série de billets sur le cas d’usage des « Trending Topics ».

Nous remercions News Republic pour nous avoir permis de mener en partenariat cette étude et espérons que cette série de billets aura permis de partager un cas d’utilisation concret du #MachineLearning en plus de comparer la solution ML avec la solution sans ML.