Débutez instantanément un projet avec la Data Science Virtual Machine

Le cloud Azure est un espace qui permet de créer des machines virtuelles (VM) pour tout besoin d’Infrastructure as as Service (IaaS). Il existe aujourd’hui une déclinaison spécifique d’une machine virtuelle dédiée aux Sciences de Données : la Data Science Virtual Machine (DSVM).

Sa création se fait en quelques minutes sous un compte Azure.

 

Une fois la VM déployée et démarrée, on utilise le principe de connexion de bureau à distance.

Une boîte à outils toute prête

Cette VM possède l’atout majeur d’être préconfigurée avec la plupart des applications de la boîte à outils des Data Scientists. Passons les principaux outils en revue :

  • SQL Server 2017 Developer Edition : le serveur de bases de données relationnelles est préconfiguré sur la VM et contient déjà une base de données de test (les fameux taxis new-yorkais). Il n’y a pas à se poser de question de licence ou de paramétrage. Depuis sa version 2017, SQL Server dispose d’un quatrième service nommé ML Services qui permet d’exécuter du code R ou Python encapsulé dans un script T-SQL.

  • Microsoft ML Server Developer Edition : il s’agit de la version autonome de ML Services, indépendante de l’installation de SQL Server. Il sera alors par exemple possible de travailler avec le format de fichier optimisé pour le travail par « chunck » et en mémoire : XDF.
  • Visual Studio Community Edition : l’interface préférée des développeurs qui baignent dans l’univers Microsoft
  • Jupyter notebook (avec noyaux R, Python, PySpark) : les notebooks sont des interfaces web qui permettent d’exécuter du code à la volée et de visualiser les résultats de manière intermédiaire entre les blocs d’instructions. En quelques années, les notebooks se sont imposés comme la présentation la plus claire d’un code et de ses résultats. Leur force réside également dans leur capacité à exécuter un grand nombre de langages.

A la première utilisation, il faut définir un nouveau mot de passe puis redémarrer le service.

Sur Windows, se connecter à la page https://localhost:9999

Sur Linux, se connecter à la page https://localhost:8000

Ajouter ensuite une exception de sécurité dans le navigateur.

Le notebook est alors accessible et présente de nombreux exemples de codes.

  • Power BI Desktop : on ne présente plus l’outil de BI Self Service de Microsoft qui permet de réaliser très rapidement des transformations puis une exploration des données. On ne l’utilisera toutefois pas ici pour sa capacité à diffuser et partager des tableaux de bord.
  • Azure Machine Learning Workbench : le nouvel outil dédié au Machine Learning de Microsoft est sorti en préversion depuis septembre 2017. Pour l’instant, il présente surtout une interface graphique très efficace pour la préparation des données. A termes, il servira de plateforme pour le déploiement et l’exécution de modèles sur un environnement Docker, éventuellement couplé à Spark. Nous traiterons de ce produit dans un prochain article.
  • Instance autonome Spark pour le développement local et le test

Citons également la distribution Anaconda de Python, JuliaPro et quantités de librairies R et Python dédiées au Machine Learning.

Bien sûr, il reste possible d’ajouter d’autres applications puisque nous travaillons ici avec une machine virtuelle.

Des configurations différentes à disposition

Le premier choix à effectuer face à l’offre des DSVM est celui du système d’exploitation : Windows 2012, Windows 2016 mais aussi Linux Ubuntu. Pour ce dernier, l’accès pourra se faire par connexion SSH mais aussi en lançant un bureau plus visuel au moyen du client X2Go.

Ensuite, se posera la question du dimensionnement de la VM. Les configurations varient légèrement selon le système d’exploitation. On jouera ici sur le type de disque pris en charge (SSD ou HDD), le nombre de processeurs virtuels (de 1 à 32) et la mémoire vive (jusqu’à 448 Go !)

La tarification évoluera en fonction de la configuration choisie et pour ces configurations comparables, il semble que la version Linux soit moins chère. Comme dans de nombreux services Azure, le coût s’évalue à l’heure d’utilisation. Il sera donc prudent d’enclencher l’arrêt automatique quotidien à une heure donnée. Le redémarrage reste quant à lui manuel.

Convaincu.e.s par la simplicité de déploiement de la DSVM ? Quel sera votre prochain projet de Data Science qui trouvera là son parfait terrain de jeu ?

Une variante pour le Deep Learning

Le Deep Learning est une évolution des réseaux de neurones, au cœur des méthodes d’apprentissage automatique, qui fait grand bruit par ses succès actuels, particulièrement dans la reconnaissance d’images. De nombreux frameworks existent pour « l’apprentissage profond » qui nécessitera des ressources importantes pour le calcul : Microsoft Cognitive Toolkit, TensorFlow, Keras, Theano, Caffe2, Chainer, Deep Water (H2O), etc. Il sera donc nécessaire de faire appel à la puissance des GPU et ce sont donc des VM spécifiques (mais plus chères) qui sont associées à ce besoin.

Nous traiterons du Deep Learning et de la DLVM dans un prochain article.

Paul PETON – Lead Data Scientist

Réaliser un clustering des clients avec Azure Data Factory et Azure Machine Learning Studio

Contexte

Dans cet article, nous allons segmenter une base de données clients pour créer des sous-ensembles de clients difficiles à identifier à l’œil nu, en utilisant l’algorithme de clustering K-Means. Cela peut aider le service Marketing à cibler un groupe spécifique de clients.

Le clustering, est une méthode d’apprentissage automatique non supervisée, qui consiste à séparer des données, en constituant des groupes homogènes. Le but est de minimiser la distance entre les observations du même groupe et de maximiser la distance entre les groupes.

Pour réaliser ce clustering, nous allons utiliser le service Azure Data Factory et nous avons besoin de créer un service web sous Azure Machine Learning Studio.

Azure Data Factory

(voir présentation de l’outil)

Azure Data Factory est un service d’intégration de données dans le cloud Microsoft Azure, qui gère et automatise le déplacement et la transformation des données. Pour cet article, nous avons utilisé la version 1 de Azure Data Factory.

Une Azure Data Factory est composée de :

  • Services liés
  • Jeux de données
  • Pipeline
  • Activité

Azure Machine Learning Studio

(voir présentation de l’outil)

Azure Machine Learning Studio est un service qui permet de générer, tester et déployer des solutions d’analyses prédictives.

Pour mettre en place cette solution, il y a deux grandes étapes à réaliser :

  1. Azure Machine Learning: Déployer le modèle de clustering des clients
  2. Azure Data Factory: Consommer le Web Service Azure Machine Learning

Azure Machine Learning: Déployer le modèle de clustering des clients

Dans Machine Learning Studio, nous créons une expérience qui exécute un script R appelant la méthode de clustering K-Means.

Nous avons publié notre expérience comme un service web Azure. Nous pouvons dès à présent envoyer des données à notre modèle via les points de terminaison de service web et recevoir des prédictions de résultats pour le modèle.

Pic01

Voici le résultat du déploiement de l’expérience en tant que service web :

Pic02.png

On aura besoin de ces deux informations : API KEY et Batch URI dans l’étape suivante.

Pic03

Azure Data Factory: Consommer le Web Service Azure Machine Learning

Notre Azure Data Factory va :

  • obtenir le fichier CSV qui contient la liste des clients,
  • ensuite appeler l’API d’exécution par lot Azure Machine Learning
  • et enfin copier le résultat d’exécution dans le compte Azure Storage sous forme d’un fichier CSV.

Le diagramme suivant illustre les différents composants de notre Data Factory.

Pic04

C’est le pipeline PredictivePipeline qui invoquera le modèle Azure Machine Learning. Pour cet article, on utilise Azure Blob Storage pour stocker les données d’entrée et de sortie.

 La création de notre Azure Data Factory se résume en 5 étapes :

  • 1- Création du service liépour le compte Azure Storage. On va utiliser le même compte de stockage pour les données d’entrées et de sortie, pour cela on va créer un seul service lié en fournissant la chaine de connexion de notre compte de Stockage.

Pic05

  • 2- Création du jeu de données d’entrée : ClientClusteringInputBlob

Pic06

Le jeu de données est un fichier plat déposé sur le blob storage.

Pic07.png

  • 3- Création du jeu de données de sortie : ClientClusteringResultBlob

Pic08

  • 4- Création d’un service liéde type AzureMLLinkedService en fournissant la clé API et l’URL d’exécution par lots du modèle.

Pic09

On précise ici l’URL du point de terminaison (mlEnpoint ) et la clé de l’API.

Pic10.png

  • 5- La dernière étape est la créationdu pipeline contenant une activité de type AzureMLBatchExecution, qui va utiliser le Batch URI et l’API Key de notre Service Web. Un pipeline peut enchainer plusieurs activités.

Le mlEndpoint correspond à la méthode POST du batch.

Pic11.png

Récupérer le code sur la page :

https://docs.microsoft.com/en-us/azure/data-factory/v1/data-factory-azure-ml-batch-execution-activity

Modifier inputs, outputs et linkedservicename, web service input et output.

Voici notre pipeline PredictivePipeline :

Pic12.png

On a ici choisi que le pipeline s’exécute tous les 3 jours.

A travers la fonctionnalité Monitor & Manage, disponible sur le Portail Azure pour la version 1 d’Azure Data Factory, on peut visualiser l’historique d’exécution (Statut, Date de début, Date de fin, Durée d’exécution …) de tous nos pipelines.

Pic13.png

Les fichiers de résultats sont stockés sur le Blob Storage.

Pic14.png

Chaque fichier contient l’association de l’identifiant du client à son segment (« cluster »).

Pic15.png

Voilà, nous avons réalisé un clustering avec le langage R en utilisant Azure Data Factory et Azure Machine Learning.

Vous pouvez effectuer régulièrement une segmentation de vos clients juste en planifiant l’exécution de la Data Factory. Vous pouvez aussi visualiser les résultats dans un outil de reporting comme Microsoft Power BI (voir présentation de l’outil) pour comprendre les comportements des clients et décrire précisément les groupes obtenus.

L’exploitation de ces données et de cet algorithme au travers de Power BI fera l’objet d’un prochain article de ce blog.

 

Article rédigé par Wafa BEN AISSA

Architecture d’une application Angular 2+

L’une des nouveautés d’Angular 2 est de pouvoir organiser son application en modules. Cette nouvelle façon d’architecturer l’application est vraiment au cœur d’Angular et il est important de bien comprendre comment ça marche afin de ne pas être perdu !

La déclaration d’un module

Alors comment se déclare un module ?  Il y a de fortes chances que vous sachiez déjà comment en faire un, car une application Angular 2 est un module en soi. Voici un exemple tiré de la documentation officielle pour vous rafraîchir la mémoire :

import { NgModule }      from '@angular/core';

import { BrowserModule } from '@angular/platform-browser';

@NgModule({

imports:      [ BrowserModule ],

providers:    [ Logger ],

declarations: [ AppComponent ],

exports:      [ AppComponent ],

bootstrap:    [ AppComponent ]

})

export class AppModule { }

Cependant si votre application est un peu complexe il est conseillé de séparer votre application en plusieurs modules (« feature-module ») et de faire un module partagé par tous (« Shared Module »).

Définitions

Bootstrap : Définit les composants qui vont être chargés au lancement de l’application. Chaque application doit bootstrapper au moins un « component », en général on le nomme AppComponent. Le tableau « bootsrap » doit être utilisé uniquement dans l’AppModule.

Declarations : Contient les « component », « directive » et « pipe » utilisé dans ce module. Ne doit pas contenir de services, d’autres modules, etc. Ne doit pas contenir de composants déclarés dans un autre module !

Exports : Permet de partager des éléments du module (« component, « directive », « pipe »). On peut aussi réexporter des éléments importés d’autres modules. Un élément déclaré ne peut être qu’utilisé qu’au sein du module où il a été déclaré, sauf si ce module l’exporte.

Imports : Permet d’importer des modules et d’utiliser les éléments exportés par ces modules. Eviter des imports inutiles, c’est relativement couteux ! Et oui, pour utiliser les composants d’une librairie il faudra importer ce module de librairie dans chacun de vos modules qui en ont besoin !

Providers : Permet d’enregistrer des services. A noté que contrairement aux éléments (« component », « directive » et « pipe »), chaque service mis en tant que providers dans NgModule est enregistré à la racine de l’application, il n’est pas encapsulé dans le module où il est déclaré.

Cas concret

En suivant les conseils précédents, on obtient cette architecture :

© Deborah Kurata

 

On peut aussi rajouter un « core module » afin d’enregistrer les différents providers de votre application, ce qui permet de s’assurer qu’on ne « provide » pas plusieurs fois le même service.

Remarques sur les modules « mixtes »

Certains modules comme le RouterModule déclarent à la fois des composants et des services. Ces modules doivent donc être importés différemment dans l’AppModule et les feature-module.

Exemple pour le RouterModule :

AppModule

@NgModule({

imports: [RouterModule.forRoot(ROUTES)]

})

class AppModule{}
FeatureModule

@NgModule({

imports: [RouterModule.forChild(ROUTES)]

})

class FeatureModule{}

 

Lorsque votre application grossit, il est intéressant de ne pas charger tous les composants d’un seul coup mais de les charger à la volée selon la navigation de l’utilisateur ! C’est ce que l’on appelle les modules « lazy-load » que nous verrons plus en détails dans un prochain post 😉

En attendant, j’espère que cet article vous aura permis de mieux comprendre le fonctionnement des modules Angular et comment architecturer son application.

Migration VSTS vers TFS 2015

Récemment j’ai dû effectuer une migration d’un code source situé sur un VSTS vers le TFS 2015 On-Premise du client. C’est un scénario qui n’est pas officiellement supporté par l’outil TFS Integration Platform, mais je n’ai pas rencontré de soucis majeur (j’ai migré uniquement le code source et non les work items).

Pour rappel TFS Integration Platform est un outil développé par l’équipe ALM Rangers qui permet d’effectuer des migrations entre différentes versions de TFS. Les migrations peuvent être interrompues puis reprises. Cependant cet outil n’est plus mis à jour depuis 2012. A noter pour une migration dans le sens inverse, Microsoft a lancé un outil en preview : TFS Database Import Service for Visual Studio Team Services

Prérequis

  • un serveur SQL (SQL Express peut suffire) plus ancien que SQL Server 2014
  • le compte local qui fait tourner l’application doit pouvoir
    • Être administrateur du poste
    • Créer une base de donnée sur le serveur SQL
    • TFS Source : Être membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture sur le projet
  • Disposer d’un compte pour le VSTS étant membre du groupe « Project Collection Proxy Service Accounts » et avoir des droits de lecture/écriture sur le projet (il peut être différent du compte local)
  • Visual Studio 2012 Pro ou supérieur (Team Explorer 2012 n’est plus disponible en standalone)

Installation

Après avoir double-cliqué sur le .msi, l’écran ci-dessous apparaît. Ici rien de particulier, installer juste le « TFS Integration Tools ».

Vous arrivez ensuite à cet écran où on vous demande la chaîne de connexion SQL, n’oubliez pas qu’à l’installation l’outil va créer une BDD, votre compte doit donc avoir les droits suffisants sur le serveur.

Bravo l’outil est maintenant installé, passons à la création de la migration !

Migration pas à pas

Voici l’écran d’accueil de l’application. La première chose à faire est de cliquer sur « Create New » (colonne de droite).

Avec l’explorateur Windows allez dans le dossier « Team Foundation Server » si ce n’est pas le cas et choisissez « VersionControl.xml ».

Il faut maintenant configurer la migration, veuillez cliquer sur « Configure » et choisir « VC11 Adapter » :

Sélectionner ensuite votre Team Project de source/cible :

Il ne reste plus qu’à lancer la migration et à résoudre les conflits s’il y en a. A noter que vous pouvez très bien mettre en pause la migration ou la finir une première fois, effectuer quelques commits sur la branche source et la relancer. Cela permet une interruption de service plus courte si une équipe est en train de travailler sur le projet durant la migration.

Une dernière petite astuce pour la route, je conseille de faire la migration sur une nouvelle VM que vous « jetterez » après la migration. Cela évite ainsi de polluer son poste de travail avec une vieille version de VS et de se prémunir d’un éventuel redémarrage de son poste de travail alors que la migration est en cours.

La migration est assez longue car vous aurez surement des conflits à résoudre donc je vous conseille de ne pas l’effectuer si vous avez une quantité importante de données.