Si vous avez provisionné un service Azure Machine Learning, vous vous êtes certainement aperçu que celui-ci ne venait pas seul au sein du resource group.
Il est en effet accompagné par un compte de stockage qui servira à enregistrer des éléments comme des datasets ou bien les artefacts liés aux modèles. Le container registry servira quant à lui à conserver les images Docker générées pour les services web prédictifs. Le Key Vault jouera son rôle de stockage des clés, secrets ou passphrases. Reste le service Application Insights.
Application Insights, pour quoi faire ?
Application Insights est une branche du service Azure Monitor qui permet de réaliser le monitoring d’applications comme des applications Web, côté front mais aussi back. De nombreux services Azure (Azure Function, Azure Databricks dans sa version enterprise, etc.) peuvent être surveiller grâce à Application Insights.
La manière la plus concrète d’obtenir un résultat avec ce service est sans doute d’utiliser l’interface Log Analytics. Celle-ci se lance en cliquant sur le bouton logs.
L’interface de Log Analytics nous invite à écrire une nouvelle requête dans le langage KustoQL, dont la syntaxe est disponible ici. Ce langage est aussi utilisé dans l’outil Azure Data Explorer.
Mais avant de pouvoir obtenir des résultats, nous devons déployer un service web prédictif sur lequel App Insights a été activé. Nous le faisons en ajoutant la propriété enable_app_insights=True dans la définition de la configuration d’inférence.
Il faut également que du texte soit “imprimé” au moment de l’exécution de la fonction run(), tout simplement à l’aide de la fonction print().
Quelques exemples de notebooks sont disponibles dans ce dépôt GitHub.
Après publication ou mise à jour du service web, une URL apparaît dans l’interface et donne accès au service App Insights correspondant.
Exploiter Log Analytics
Il est maintenant possible de lancer une première requête dans l’interface Log Analytics, avec la syntaxe suivante :
Le service Azure Machine Learning a créé une “custom dimension“, nouvel objet au format JSON, interrogeable par le langage KustoQL. Celui-ci contient des informations comme l’identifiant du container associé, le nom de l’espace de travail ainsi que du service déployé.
Afin de conserver les logs sur la durée, un mécanisme d’export continu pourra être mis en œuvre et stockera les informations sur un compte de stockage.
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.
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.
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.
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.]
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 :
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.
Soyons un peu plus précis que ce titre tautologique. Toute personne mettant aujourd’hui le doigt dans le cloud de Microsoft va se retrouver confrontée à une quantité de services disponibles mais surtout de problématiques associées à la bonne mise en œuvre au sein de son organisation : choix de la meilleure solution, coûts, sécurité, monitoring, optimisation,gouvernance, etc.
Définitivement, le mouton à 5, 6, 7… pattes n’existe pas
et il est impensable pour un seul être humain de maîtriser l’ensemble des pans
liés au déploiement de solutions cloud Azure. Pour autant, connaître certaines
notions s’avèrent bien utiles pour ne pas rater une étape cruciale lors d’un
projet nécessitant une architecture cloud.
Si vous souhaitez prendre le virage du Cloud et surtout de celui de Microsoft, je vous conseille fortement de vous attaquer à la certificationAZ-900.
Un contenu de formation est disponible sur la plateforme Microsoft
Learn. Vous préfèrerez peut-être le lire en français
mais je vous recommande de connaître les termes anglais relatifs aux
différentes notions ainsi qu’aux services Azure.
Enfin, bonne nouvelle, l’inscription (gratuite) à l’événement Microsoft Ignite The Tour Paris 2019 vous permettra de vous voir remettre sur place un voucher de passer cette certification !
Pour vous guider dans votre approche de la certification, voici les 12 chapitres du cours Microsoft Learn, pour lesquels je vous propose une sélection de mots-clés indispensables à connaître. Ces thèmes peuvent être vus selon l’arbre ci-dessous.
Thèmes de la formation Les fondamentaux d’Azure
# Concepts du cloud – Principes du cloud computing
Cloud
computing (public, privé, hybride)
Shift
& lift
Machine
virtuelle / conteneur / serverless
Scalabilité
horizontale / verticale
IaaS
/ PaaS / SaaS
# La base des services cloud – Introduction à Azure
Zones
géographiques, zones de disponibilité
Régions,
paires de régions
Centre
de données
Contrat
de niveau de service
# Services cloud de base – Architecture Azure et garanties
de service
Compte
Abonnement
Locataire
(Tenant ?)
Azure
Active Directory
Ressource
Plan
de support
# Créer un compte Azure
Portail
Azure
Tableau
de bord du portail
Place
de marché Azure
Azure
PowerShell / Azure CLI
Azure
Cloud Shell
Application
mobile Azure
# Services cloud de base – Gérer les services avec le portail
Azure
Outils
d’interaction et de gestion
Portail
Azure
Azure
PowerShell
Azure
CLI
Azure
Cloud Shell
Application
mobile Azure
Place
de marché Azure
Tableau
de bord
# Services cloud de base – Options de calcul Azure
Machines
virtuelles
Conteneurs
ACI
(Azure Container Instances)
Azure
Kubernetes Service (AKS)
Azure
Batch (AI)
Azure
App Service
Informatique
Serverless
Azure
Function (Application de fonction)
Azure
Logic Apps
# Services cloud de base – Options de stockage de données
Azure
Données
structurées / semi-structurées / non structurées
Azure
Blob Storage
Azure
Files
Azure
Data Lake Storage (gen2)
Azure
Queue (file d’attente)
Niveau
de stockage, chiffrement, réplication
Azure
Storage Service Encryption
# Services cloud de base – Options de réseau Azure
Architecture
multiniveau
Réseau
virtuelle
Sous-réseau
Adresse
IP publique / privée
Passerelle
VPN
Groupe
de sécurité réseau (trafic entrant)
Disponibilité,
haute disponibilité
Résilience
Equilibreur
de charge, pool
Azure
Load Balancer
Azure
Application Gateway
Réseau
de distribution continu
DNS
Latence
réseau / bande passante
Trafic
Manager
# Sécurité, responsabilité et approbation dans Azure
Depuis, la version Gen2 d’Azure Data Lake Storage est sortie (le logo a évolué). Azure Machine Learning Service est devenu un portail à part entière : ml.azure.com et depuis
Voici un aperçu des fonctionnalités en vidéo de ce qui s’appelle pour l’instant Azure Machine Learning Web Experience.