Contrôler l’export des données sous Power BI

(Nous parlerons ici du service cloud Power BI, destiné au partage et à la collaboration. Si vous partagez vos fichiers .pbix, une autre réflexion sera nécessaire 😉 )

Mais tout d’abord, pourquoi bloquer l’export des données depuis les rapports Power BI ?

La méthode radicale : l’interdiction par l’utilisateur

La méthode douce : l’interdiction (ou la limitation) au dataset

La méthode (ultra) fine : le retrait de l’option au niveau du visuel

Enfin, rappelons que tout utilisateur ayant les droits nécessaires et une version d’Excel suffisamment récente peut installer l’extension “Power BI Publisher” qui, comme son nom ne l’indique pas, peut accéder aux datasets hébergés sur le service Power BI et pour lesquels ils disposent des droits suffisants.

Relancer un notebook Databricks en cas d’échec

Le code utilisé dans un notebook peut échouer pour une raison autre qu’un erreur de développement : fichier absent, API ne répondant pas, etc. Il peut donc être pertinent de relancer automatiquement un traitement en cas d’échec.

La documentation Databricks fournit un exemple de fonction, en Python ou en Scala, qui réalise ce mécanisme. Le code est bien sûr basé sur la fonction dbutils.notebook.run déjà présentée dans un précédent post.

Voici le code en Python, où un nombre d’essais maximum de 3 est paramétré par défaut :

 # Errors in workflows thrown a WorkflowException. 
def run_with_retry(notebook, timeout, args = {}, max_retries = 3):
   num_retries = 0
   while True:
     try:
       return dbutils.notebook.run(notebook, timeout, args)
     except Exception as e:
       if num_retries > max_retries:
         raise e
       else:
         print "Retrying error", e
         num_retries += 1

Et voici ce que l’on obtient à l’exécution. Attention à bien préciser le chemin relatif du notebook ainsi piloté, si celui-ci n’est pas situé au même niveau que le ce “master notebook”.

Attention à ne pas abuser de ce processus ! Il est essentiel de comprendre la nature des erreurs rencontrées et d’y apporter des réponses au travers du code.

Utiliser les variables d’environnement pour faciliter le déploiement continu des notebooks Databricks

Une fois l’infrastructure définie autour d’un cluster Databricks, les notebooks sont les éléments qui vont évoluer au gré des développements. Il faut bien sûr a minima définir deux environnements : l’un de développement, l’autre de production. Nous verrons ainsi plusieurs astuces et bonnes pratiques permettant de réaliser le processus du déploiement continu des notebooks.

Nous avons pu voir dans de précédents articles :

  • Comment définir un point de montage vers un compte de stockage Azure
  • Comment versionner les notebooks Databricks par exemple sous GitHub

Nous allons utiliser ici la notion de variable d’environnement, propre au cluster Spark.

Le schéma ci-dessous illustre le mécanisme DevOps qui sera mis en place.

Mais pour l’instant, focalisons-nous sur le chemin menant vers les données. Nous utilisons ici deux environnements identiques d’un point de vue de l’architecture, dont une vision simplifiée est donnée sur le schéma ci-dessous :

L’accès au point de montage défini sur le compte de stockage Azure se fait par exemple au moyen des commandes Databricks dbutils :

dbutils.fs.ls('/mnt/dev/mysfilesystem/')

Les variables d’environnement sont quant à elles définies au niveau d’un cluster. Elles seront donc accessibles de n’importe quel notebook attaché au cluster. Nous les trouvons en dépliant le menu des options avancées, onglet Spark.

Par convention, nous utilisons une casse majuscule pour le nom des variables.

Attention à ne pas mettre d’espace autour du signe « = ». Les guillemets ne sont en revanche pas indispensables autour de la valeur de la variable.

Un redémarrage du cluster sera alors nécessaire, suite à la modification des variables d’environnement.

Maintenant, différentes commandes, dans les langages supportés, vont nous permettre d’accéder aux variables définies. Pour la compatibilité dans un même notebook, les lignes de scripts seront ici précédées du langage dans lequel elles sont écrites, vous pourrez ainsi copier ce code tel quel dans n’importe quel notebook Databricks.

Liste des variables d’environnement :

%sh printenv

Valeur de la variable en Shell :

%sh echo $MOUNT_PATH

Valeur de la variable d’environnement en Python :

%python

import os

key = 'MOUNT_PATH'
value = os.getenv(key)

print("Value of 'MOUNT_PATH' environment variable :", value)

A noter que la commande getenv() peut être remplacée par environ.get() issue également de la librairie os. Les différences entre les deux sont traitées dans cette question sur StackOverFlow.

Valeur de la variable d’environnement en Scala :

%scala
sys.env("MOUNT_PATH")

Il est donc maintenant possible d’utiliser ces variables dans les chaînes d’accès au système de fichier, avec un code qui réagira alors en fonction de l’environnement !

%python
dbutils.fs.ls(os.getenv('MOUNT_PATH') + '/mysfilesystem/')

La définition des variables d’environnement est également réalisable si vous utilisez un “automated cluster“, c’est-à-dire un cluster créé à la volée lors du lancement d’un job planifié.

La configuration du cluster est disponible en cliquant sur le bouton “edit”.

Intelligence artificielle : bénéficier de l’AI as a Service [3/3]

La donnée classique et structurée n’a plus de secret pour vous si vous avez lu les deux billets précédents (ici et ) traitant de l’analyse avancée et de la modélisation des données. Pour autant, ces méthodes sont valables, et performantes, lorsque la donnée est de type alphanumérique et organisée sous forme tabulaire. Pour les données dites non structurées comme les images, le son ou encore le texte rédigé, il faut faire appel à un tout autre arsenal d’outils.

Du temps, de la puissance et des données

Soyons pragmatiques, pour être ingérée par un algorithme, toute donnée devra devenir numérique mais le cheminement pour y arriver va être complexe. Des approches comme la métrique TF-IDF ont fait leurs preuves, pour le référencement de documents pertinents dans des corpus de textes. Cela reste vrai tant que la puissance de calcul disponible est suffisante, et donc le volume de données relativement raisonnable. Dans le domaine des images, on distinguera deux usages principaux : la classification (catégoriser une image parmi des labels existants) et la reconnaissance d’objets (présence et position sur l’image). Les progrès ont été remarquables avec l’arrivée (voire le retour…) des réseaux de neurones dits profonds, ce que l’on nomme le « Deep Learning ».

Les frameworks de Deep Learning sont aujourd’hui nombreux : Cognitive Toolkit créé par Microsoft, TensorFlow mis en place par Google ou encore PyTorch. Leur maîtrise implique une bonne connaissance du fonctionnement mathématique des réseaux de neurones et de l’état de l’art des différents types de couches de neurones pouvant être utilisées. Mais ensuite, il faudra beaucoup de données et beaucoup de puissance de calcul pour obtenir un modèle performant.

C’est ici que le mécanisme du Transfer Learning prend tout son intérêt. En effet, au fur et à mesure des couches du réseau de neurones profond, l’apprentissage va se spécifier. Pour donner une image didactique, on pourrait dire que l’algorithme commence par reconnaître des formes simples avant d’identifier des formes plus complexes. C’est d’une certaine manière ce que font nos yeux et notre cerveau lorsque nous découvrons un nouvel environnement. J’entre dans un nouveau bâtiment et je vois des bureaux, des écrans, des tasses à café, un babyfoot, je reconnais… l’open space d’une ESN parisienne !

Les services cognitifs

Imiter les capacités humaines de perception ou de cognition est depuis longtemps un défi pour le monde de l’informatique et la discipline de l’Intelligence Artificielle s’y emploie, présentant des succès majeurs depuis quelques années. Pensons ici à la qualité des outils de traduction automatique, à l’efficacité de la transcription orale en texte ou encore à la pertinence des moteurs de recommandation.

Les départements de Recherche et Développement des géants du numérique rivalisent de performances dans ces différents domaines et mettent à disposition leurs algorithmes, en les encapsulant dans des interfaces (web, API, SDK…) facilitant leur utilisation. En ce sens, nous pouvons parler d’Intelligence Artificielle as a Service !

Les services cognitifs de Microsoft se répartissent en cinq catégories présentées sur l’image suivante.

Documentation Microsoft

Plusieurs de ces services sont accessibles en démonstration ou test sur le site de Microsoft. Pour une utilisation plus régulière et dans un cadre professionnel, un abonnement Azure sera nécessaire.

Pour une entreprise est convaincue de la création de valeur potentielle au travers des données non structurées (texte, image, son, vidéo…), elle doit dorénavant s’interroger sur la faisabilité d’un développement équivalent : existe-t-il des ressources (personnes et machines) capables de produire le niveau de performance attendu des algorithmes ? A la négative, il pourra être très intéressant d’exploiter les services cognitifs.

Microsoft Custom Vision

Le site customvision.ai de Microsoft vous permet de vous lancer rapidement dans l’évaluation de modèles de classification ou de reconnaissance d’objets, sans avoir à saisir une seule ligne de code !

Identifiez-vous sur le portail, avec votre compte Azure. Il sera possible de créer et conserver simultanément deux projets sur la plateforme, et ce, sans facturation. Dans l’exemple ci-dessous, nous choisissons un projet de type « Object detection ». Notre cas d’usage sera ici d’identifier l’existence d’un panneau de limitation de vitesse sur une photo.

Il sera alors nécessaire de créer ou d’associer un groupe de ressources Azure. Si cette notion ne vous parle pas, rapprochez-vous des administrateurs de votre souscription Azure.

Trois domaines sont proposés : il s’agit ici de spécifier le « début » du réseau de neurones profond qui sera employé dans notre démarche d’apprentissage par transfert. Nous restons ici sur le domaine général. L’utilisation du domaine « Logo » permettrait de bénéficier de couches de neurones déjà entrainées à la reconnaissance de logos de marques commerciales.

Chargement des images et ajout de tags

L’écran suivant correspond à l’interface de chargement des données et d’entrainement du modèle. Nous rentrons ici dans la logique dite supervisée de l’apprentissage automatique : il faut fournir des exemples que le réseau interprétera pour construire le modèle, qui lui permettra ensuite de réaliser des prévisions. En résumé, prédire le futur correspond à reproduire le passé, en le généralisant !

La première étape consiste à charger des images (« add images ») à partir de l’ordinateur que nous utilisons. Ces images peuvent être de format .jpg, .png, .bmp ou .gif et il n’y a pas d’exigence à ce qu’elles soient de la même résolution. Le poids de l’image utilisée en entrainement ne pourra pas dépasser 6Mo et 4Mo en prévision. Les images dont la largeur se situe en dessous de 256 pixels sont automatiquement remises à l’échelle par le service.

Un minimum de 15 images est requis pour débuter un modèle de détection d’un objet. Toutefois, il faudra viser une cinquantaine d’images pour une première expérience significative et s’en tenir à des cas d’usage relativement « visibles ». Même si la technologie s’en rapproche, ce n’est pas cet outil qui sert par exemple à détecter des pathologies dans des clichés médicaux.

Il est maintenant nécessaire de travailler chaque image en entourant la zone souhaitée (ici le panneau rond de limitation) et en y associant un « tag » (mot clé identifiant l’objet). C’est la partie manuelle et sans doute la plus rébarbative de l’entrainement du modèle.

Si l’on souhaite reconnaitre plusieurs objets, il sera nécessaire de compter au moins 15 images par objet.

Première itération du modèle

Lors de la phase d’entrainement, l’algorithme cherche à réduire l’erreur de prévision sur la base des images déjà taguées.

Deux types d’entrainement sont disponibles :

  • Fast training
  • Advanced training

Deux règles s’appliquent ici de manière assez générale :

  • Plus il y a beaucoup de données, plus le temps d’entrainement sera long et meilleur sera le modèle.
  • Plus l’entrainement est long ou sollicite de machines puissantes, plus celui-ci sera cher.

L’entrainement peut durer plusieurs minutes et s’étendre sur plusieurs heures en cas de volumétrie et de complexité importante. Nous privilégions ici dans un premier temps l’entrainement rapide.

Evaluer et tester le modèle

Le menu Performance permet de consulter les indicateurs de qualité du modèle.

La précision correspond, pour un tag donné, à la proportion d’images correctement classées ou avec une reconnaissance d’objets exacte sur l’ensemble des images.

Le rappel (Recall) correspond à la proportion d’images appartenant réellement à une classe parmi toutes les images prédites dans cette classe.

On définira le seuil de probabilité (Probability Threshold) pour savoir si la confiance dans une prévision est suffisante pour classer une image ou détecter un objet.

Le score mAP (mean Average Precision) est un calcul synthétisant les indicateurs de précision et de rappel, en moyenne pour l’ensemble des classes ou des objets à détecter.

On cherchera à maximiser ces trois indicateurs mais attention, ce n’est pas forcément souhaitable que de disposer d’un modèle « parfait » comme sur l’illustration ci-dessus. La perfection en apprentissage automatique est nommée surapprentissage (« overfitting ») et peut se traduire par un manque de capacité de généralisation. Concrètement, le modèle a de forts risques d’échec dès que de nouvelles images dévieront des images d’entrainement.

Une solution consiste ici à augmenter le nombre d’images utilisées pour l’apprentissage, en prenant soin de varier les contextes d’images (routes de jour / de nuit, panneaux étrangers, etc.).

L’interface de Custom Vision nous propose maintenant de tester le modèle établi.

Nous utilisons bien sûr ici une image qui n’a pas servi à l’entrainement du modèle. Il est possible d’utiliser une image de l’ordinateur local ou bien une URL web d’image.

Il sera également possible de comparer les résultats du test sur les différentes itérations d’entrainement.

Sur cette première image, le panneau est bien identifié avec une probabilité de plus de 98% mais nous observons également que l’arrière du camion a été analysé comme un panneau. Pour autant, la probabilité est très faible (< 25%) et nous pourrons rejeter cette hypothèse en définissant un seuil d’acceptation.

Le panneau de limitation est bien identifié, avec un score de confiance dépassant 82%

Sur ce second test, deux panneaux sont identifiés avec une probabilité forte (> 80%) d’être une limitation de vitesse. Ce n’est pourtant le cas que sur le panneau de bas. Nous devons à nouveau grossir le jeu d’entrainement, en incluant plus de diversité de panneaux et relancer une itération !

Microsoft donne plusieurs conseils pour améliorer un classifieur sur cette page. Un principe générique consistera à ajouter des images variées selon l’arrière-plan, l’éclairage, les tailles d’objet, les angles de vue…

Exploiter le modèle depuis une application tierce

Bien sûr, un usage professionnel du modèle obtenu ne pourra se faire au niveau du portail. On utilisera une application tierce qui appellera le modèle au travers d’une API.

Le modèle obtenu au travers de la meilleure itération doit tout d’abord être publié (bouton « Publish ») et associé au groupe de ressources préalablement défini sur le portail Azure.

En cliquant ensuite sur « Prediction URL », on obtiendra l’URL et la clé de prévision (prediction URL & prediction-key). L’URL de prévision est aussi appelée endpoint.

La prediction key est aussi visible depuis le portail Azure, au niveau de la ressource créée pour l’utilisation du service Custom Vision.

Deux kits de développement (SDK) existent également et permettent de réaliser l’ensemble des étapes en programmation .NET (téléchargeables pour l’entrainement et la prévision) ou en Python à l’aide de la commande suivante :

pip install azure-cognitiveservices-vision-customvision

La documentation Microsoft vous guidera sur le reste du code à écrire pour appeler le modèle.

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.

Expliquer (automatiquement) la hausse

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%.

Paramètres de la prévision

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 ».

Azure Machine Learning Studio (classic)

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

Ressource Azure 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.

Création de la ressource

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
Lien vers le portail

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).

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 4e 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 !

Global AI Bootcamp Paris ’19

Un post rapide pour vous donner le programme de cet événement que j’ai le plaisir de co-organiser.

Un triple merci à l’attention :

  • de l’ESGI qui nous accueille dans ses locaux
  • des communautés GUSS et AZUGfr dont les membres participent à l’organisation
  • des entreprises Cellenza et Azeo qui sponsorisent l’événement et plus directement l’accueil petit déjeuner

A ce jour (12/12/2019), l’événement est “sold out” depuis plus d’une semaine, ce qui nous conforte dans l’idée que parler d’IA est aujourd’hui une priorité à la fois professionnelle et sociétale.

N’oublions pas enfin que Global AI Bootcamp est un événement mondial, porté par la Global AI Community et Microsoft.

Voici le lien vers la carte des 130 villes organisatrices dans le monde :

https://globalai.community/global-ai-bootcamp/

Pérenniser une table Azure Databricks dans SQL DWH

Le proverbe bien connu “diviser pour mieux régner” a sa déclinaison dans le monde de la Data et des services managés : “séparer le traitement du stockage”. Par cela, il faut comprendre que l’utilisation de deux services différents pour ces deux tâches est particulièrement intéressant.

En effet, le stockage se doit d’être permanent et toujours accessible, en tenant compte de différents degrés de “chaleur”. En revanche, la puissance de calcul n’est nécessaire que pendant les traitements et il faudra pouvoir faire évoluer cette puissance selon le besoin. Par exemple, un entrainement de modèle prédictif, opération qui peut être très coûteuse, bénéficiera de l’élasticité d’un service managé comme Azure Databricks mais ne sera peut-être pas réalisé quotidiennement.

Nous allons détailler ici comment pérenniser les données issues d’un traitement de préparation réalisé sur le cluster managé Spark. La solution de stockage choisie ici est Azure SQL Data Warehouse.

Créer une ressource Azure SQL DWH

Il est tout d’abord nécessaire de disposer d’une ressource Azure de serveur de bases de données.

La documentation officielle d’Azure Databricks recommande de cocher la case “Allow Azure services to access server”.

Nous sélectionnons maintenant la ressource Azure SQL Data Warehouse dans la catégorie Databases.

Le Data Warehouse est associé à un groupe de ressources et à un serveur de base de données (ici, créé simultanément). Le niveau de performance choisi va déterminer le coût associé à une heure de service de l’entrepôt.

Cette ressource se montra particulièrement efficace dans le cadre d’une connexion vers un outil de dashboarding comme Power BI et autorise le mode direct query, qui pourra se révéler pertinent dans des modèles de données composites, mêlant import et connexion directe.

Une clé de chiffrement pour la base étant obligatoire, il sera nécessaire de créer une database master key au travers d’une nouvelle requête sur la base de données. Cela peut se faire par exemple dans le client SQL Server Management Studio ou sur le portail Azure par le query editor actuellement en préversion.

--Creates the database master key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = "yourStr0ngPa$$W0rd"

Faire communiquer Azure Databricks et SQL DWH

Afin de bien paramétrer la communication, il faut tout d’abord comprendre comment fonctionne le mécanisme. La subtilité à bien saisir est l’importance d’un troisième élément qui est le compte de stockage Azure utilisé comme zone temporaire et sollicité par le composant PolyBase.

Schéma extrait de la documentation officielle Databricks
Source : https://docs.databricks.com/data/data-sources/azure/sql-data-warehouse.html

Vérifions tout d’abord que le connecteur SQL DWH est présent sur le runtime Databricks associé au cluster Spark au moyen de la commande Scala ci-dessous.

La commande ne doit pas renvoyer d’erreur “ClassNotFoundException”.

Dans une cellule d’un notebook, nous déclarons toutes les variables nécessaires à la bonne communication entre les différentes briques, en particulier le compte de stockage Azure (Blob Storage ou Data Lake Storage gen2).

Le code ci-dessous est donné pour un notebook Python mais sa variante en Scala s’obtiendra facilement en ajoutant le mot-clé var au devant de chaque déclaration de variable.

storage_account_name = "nomDuBlobStorage"
blobStorage = storage_account_name+".blob.core.windows.net" blobContainer = "nomDuConteneur"
blobAccessKey =  "MauvaiseIdéeDeCopierIciUneClé000PensezAuSecretScope!"

tempDir = "wasbs://" + blobContainer + "@" + blobStorage +"/tempDirs"
 acntInfo = "fs.azure.account.key."+ blobStorage

dwServer = "nomDuServeur"+".database.windows.net"
dwDatabase = "nomDuDWH" 
dwUser = "nomDeLUtilisateur"
dwPass = "ToujoursUneMauvaiseIdéePensezVraimentAuSecretScope"
dwJdbcPort =  "1433"

dwJdbcExtraOptions = "encrypt=true;trustServerCertificate=true;hostNameInCertificate=*.database.windows.net;loginTimeout=30;"

sqlDwUrl = "jdbc:sqlserver://" + dwServer + ":" + dwJdbcPort + ";database=" + dwDatabase + ";user=" + dwUser+";password=" + dwPass + ";$dwJdbcExtraOptions"

sqlDwUrlSmall = "jdbc:sqlserver://" + dwServer + ":" + dwJdbcPort + ";database=" + dwDatabase + ";user=" + dwUser+";password=" + dwPass

Attention à faire cette étape proprement au moyen d’un secret scope !

Des travaux de data preparation nous ont permis de réaliser un DataFrame propre contenant des données plus exploitables. Une sauvegarde du DataFrame est réalisée sous forme de table sur le cluster mais celle-ci ne sera accessible que lorsque le service Azure Databricks est démarré (et donc facturé).

Nous allons donc réaliser une copie des données sur Azure SQL Data Warehouse.

Grâce aux actions préalables, il est maintenant possible de lancer les commandes load ou write pour communiquer avec Azure SQL Data Warehouse. Dans la commande ci-dessous, nous créons une nouvelle table dans la base de données à partir d’un DataFrame en mémoire du cluster.

dwTable = "nomDeLaNouvelleTableDuDWH"

df.write.format("com.databricks.spark.sqldw") \
    .option("url", sqlDwUrlSmall) \
    .option("forwardSparkAzureStorageCredentials", "true") \
    .option("dbTable",dwTable) \
    .option("tempDir",tempDir) \
    .save()
Les logs du cluster montrent que la communication s’effectue bien avec le Data Warehouse.

Automatiser les traitements

Nous avons donc réalisé ici la partie cruciale de la chaîne de la data, en séparant traitement et stockage des résultats. Pour rendre cette architecture encore plus efficace, il sera nécessaire de planifier le traitement de préparation des données . Plusieurs solutions sont ici disponibles :

  • l’ordonnanceur d’Azure Databricks, couplé à une logique d’enchaînement de notebooks
  • l’utilisation d’un pipeline Azure Data Factory et d’une activité Databricks

Ces deux approches sont décrites dans cet article.

Dupliquer les données, bonne idée ?

A cette question, nous pourrons formuler la traditionnelle réponse du consultant : “ça dépend”.

Rappelons qu’il faut bien évaluer les usages et les coûts d’une telle architecture. Quel est le public qui a besoin de cette donnée préparée ? Plutôt des data analysts au sein de Power BI ? Plutôt des data scientists dans un cluster “bac à sable” ?

Azure SQL Data Warehouse offre une puissance d’accès pour des usages analytique mais il faut mesurer son coût si la base reste accessible en continu. A l’inverse, les tables matérialisées sur le cluster retirent une brique de l’architecture (et de la facture !) mais les performances du connecteur Spark pour Power BI ne me semblent pas aujourd’hui suffisantes pour des volumes de données importants.

Une fois de plus, la bonne architecture cloud Data sera celle qui répondra le mieux aux besoins, dans un cadre gouverné et dont le coût et la performance seront supervisés de près.

[EDIT 13 novembre 2019 : Microsoft a annoncé lors de l’Ignite d’Orlando qu’Azure SQL Data Warehouse évoluait et devenait au passage Azure Synapse Analytics. Nous suivrons de près cette évolution.]

D’Azure Databricks à Power BI : quel(s) chemin(s) ?

Si vous avez suivi mes derniers articles sur ce blog, vous aurez deviné que je suis plus que convaincu de l’intérêt de mettre le service de clusters managés Databricks au sein d’une architecture cloud data.

Si l’on met de côté l’exploitation des données par des algorithmes de Data Science, il sera toujours très intéressant de visualiser et d’explorer la donnée dans un outil d’analyse dynamique comme Power BI. Et cela tombe bien, il existe un connecteur (générique) Spark !

Connecter Power BI Desktop à une table du cluster Databricks

Voici comment procéder pour charger les données d’un cluster dans un modèle Power BI.

Tout d’abord, il faudra installer sur le poste exécutant Power BI Desktop le driver Spark ODBC. Celui-ci peut être téléchargé au travers d’un lien reçu par mail suite à l’inscription sur ce formulaire. L’installation ne révèle aucune difficulté : next, next, next…

Passons ensuite sur l’interface de notre espace de travail Azure Databricks. Nous démarrons le cluster et il sera possible d’y trouver une information importante qu’est l’URL JDBC.

Cette URL va permettre de construire le chemin du serveur attendu dans la boîte de dialogue sous la forme générique suivante :

  https://<region>.azuredatabricks.net:443/sql/protocolv1/o/0123456789012345/01234-012345-xxxxxxx 

Il faut donc ici remplacer <region> par le nom de la région Azure où se trouve la ressource Databricks, par exemple : westus. A la suite du port 443, on copiera la partie de l’URL JDBC allant de sql au point-virgule suivant.

Seconde étape à l’intérieur de l’interface Databricks, nous créons maintenant un jeton d’accès pour l’application Power BI à partir des Users settings.

  Attention à bien copier la valeur affichée, il ne sera plus possible de la revoir !

 Revenons à Power BI. Dans la boîte de dialogue de connexion, coller l’URL construite dans la case Server, choisir le Protocol HTTP.

 En mode import, l’avantage sera de pouvoir continuer à travailler sans que le cluster soit démarré. Mais il faudra attendre un bon moment pour que le chargement de données se fasse dans Power BI. En effet, si l’on utilise un cluster Spark, c’est que bien souvent les volumes de données sont importants…

 En mode direct query, chaque évaluation de visuel dans la page de rapport établira une requête vers le cluster, qui bien évidemment devra être actif.

 Le user name est tout simplement le mot token. Coller ici le jeton généré depuis Azure Databricks.

 Nous accédons maintenant à toutes les tables ou vues du cluster ! N’insistez pas trop pour obtenir un aperçu, cette fonctionnalité semble peiner à répondre mais l’important est bien d’obtenir les données dans l’éditeur de requêtes.

Voici le code obtenu dans l’éditeur avancé. Nous retrouvons une logique classique de source et de navigation dans un élément de la source, ici une table. Le schéma de la table est respecté, il n’est pas nécessaire de typer à nouveau les champs dans Power Query.

Connecter un Dataflow à Azure Databricks

Les Dataflows de Power BI (à ne surtout pas confondre avec les data flows de Azure Data Factory !) sont une nouveauté du service Power BI qui vient de connaître beaucoup d’évolutions.

Pour l’expliquer simplement, on peut dire que Dataflow correspond à la version en ligne de Power Query, avec donc une capacité de traitement issue du cloud (partagée ou dédié dans le cadre d’une licence Premium) et la possibilité de partager le résultat des requêtes (appelées entités) à des créateurs de nouveaux rapports. Contrairement à un jeu de données partagé (shared dataset), il est possible de croiser plusieurs entités dataflows au sein d’un même modèle.

Les dataflows sont enfin le support des techniques de Machine Learning dans Power BI mais nous parlerons de tout cela une prochaine fois !

Début novembre 2019, de nouvelles sources de données sont disponibles dont la source Spark. Nous allons donc tenter de reproduire la démarche réalisée dans Power BI Desktop.

Nous retrouvons les mêmes paramètres de connexion, à savoir :

  • Server
  • Protocol (http)
  • Pas besoin de Gateway, les données sont déjà dans Azure
  • Username : token
  • Password : le jeton généré (on vous avait prévenu de conserver sa valeur 😊)

Il faut ensuite choisir la table ou la vue souhaitée.

Petite différence, les types de données ne sont pas conservés, il faut donc exécuter une commande « Detect data type » sur toutes les colonnes.

Rappelons enfin qu’un dataflow n’est pas chargé tant qu’il n’est pas rafraîchi une premier fois. Cliquer ici sur Refresh now.

Un rafraichissement pour aussi être planifié mais il faudra bien s’assurer que le cluster Databricks soit démarré pour que la connexion puisse se faire.

Une fois le dataflow créé, il est accessible de manière pérenne aux développeurs qui travaillent dans Power BI Desktop et qui ont accès à l’espace de travail Power BI où a été créé le dataflow.

Nous vérifions ici dans l’aperçu que les champs sont maintenant bien typés.

En conclusion

Nous avons ici utilisé le connecteur Spark et celui-ci a nous permis, à partir de Power BI ou des dataflows du service Power BI, de nous connecter aux tables vues au travers du cluster Databricks.

Il s’agit là d’un connecteur générique et celui-ci n’est sans doute pas optimisé pour travailler la source Azure Databricks mais notons que le mode direct query est tout de même disponible.

Cette approche montrera rapidement ces limites quand les volumétries de données exploseront. Il sera alors nécessaire de réfléchir à une solution de stockage des données entre le cluster et Power BI comme Azure SQL DB ou Azure SQL DWH (bientôt Azure Synapse Analytics ?), portées ensuite éventuellement par un cube Azure Analysis Services qui exécutera les calculs nécessaires aux indicateurs présentés dans Power BI.

Toutefois, la faisabilité de cette connexion permettra de mener rapidement une preuve de concept jusqu’à la représentation visuelle des données. A la contrainte d’avoir le cluster démarré pour charger les données, on répondra par leur écriture au sein d’un dataflow (qui est techniquement un stockage parquet dans un Azure Data Lake Storage gen2 !). Attention, les dataflows ont leurs limites : ils ne peuvent être utilisés qu’au sein d’un seul espace de travail Power BI, sauf à disposer d’une licence Premium qui permettra de lier ce dataflow à cinq espaces de travail.