Découvrir Azure OpenAI et son studio

Lorsque votre souscription Azure aura été autorisée à déployer le service OpenAI (voir ce précédent article), vous pourrez accéder à l’écran ci-dessous.

Au cours de cet article, nous allons donner un premier aperçu des fonctionnalités disponibles et insister sur les différences entre le service OpenAI directement disponible et son intégration au sein du cloud Microsoft Azure.

Playground de OpenAI (hors Azure)

Afin d’expérimenter les différents modèles, nous allons tout d’abord nous connecter au studio Azure OpenAI sur l’URL https://oai.azure.com/

Studio Azure OpenAI

La page d’accueil fournit de nombreux liens d’exemples et de documentation.

Nous retrouvons le playground de OpenAI et la possibilité d’expérimenter des prompts dans différents scénarios :

  • résumé
  • classification
  • génération de code
  • etc.

Nous ne retrouvons toutefois pas, pour l’instant (février 2023), l’intégralité des exemples proposés dans le playground d’OpenAI.

Déployer un modèle

C’est la première opération à réaliser afin de pouvoir utiliser les différents services : déployer l’un des modèles disponibles. Par défaut, aucun modèle n’est déployé dans le studio.

Il faut tout d’abord sélectionner l’un des modèles de base.

Une description rapide des différents modèles est donnée, afin d’aider à la sélection. Les modèles dédiés au langage naturel, dérivant de GPT-3, sont décrits dans cette partie de la documentation officielle.

Il est alors possible de retourner dans le playground et de sélectionner le déploiement réalisé.

Complétion de texte

C’est ici que l’expérience avec un modèle GPT-3 peut s’avérer déstabilisante. En effet, nous sommes face à un outil destiné à traiter le langage naturel et également à interagir de la sorte. Nous n’avons donc d’un simple prompt pour exprimer notre demande. Attention à l’angoisse de la page blanche !

Le résultat généré est identifié par un surlignage vert. On remarquera l’indicateur du nombre de tokens, correspondant à la longueur du texte contenu dans le prompt.

Le paramètre de température permet de gérer l’aspect stochastique du modèle (comprendre que les prévisions peuvent changer même avec un prompt similaire). Dans l’exemple ci-dessous, le résultat est généré trois fois, avec une température de valeur 1.

Write a original prompt for image generation with DALL-E 2

What would DALL-E draw if you asked it to generate an image of a "perfect day"?

What if DALL-E was asked to generate an image of a world where everyone was happy and there was no conflict?

What if the world was made of candy?

Premiers scénarios d’utilisation

Approprions-nous maintenant le terrain de jeu !

Résumé

On soumet un texte long afin d’obtenir un résumé.

L’intention est ici exprimée par le terme “Tl;dr:” (“trop long; n’a pas lu) mais pourrait être formulée d’une autre façon, par exemple en précisant le public cible.

Les guillemets encadrent ici la partie de texte à résumer.

Classification

Nous donnons tout d’abord l’intention, celle d’établir un classifieur. La dizaine d’exemples ci-dessous est issue d’un jeu de données connu sur le sujet.

Il s’agit bien d’un spam !

Avec si peu de données d’entrainement, le résultat peut paraitre impressionnant mais n’oublions pas qu’il y a une chance sur deux de trouver la bonne réponse (pile ou face) ! Contrairement à un classifieur issu par exemple du framework Scikit-Learn, nous ne pouvons pas accéder à la probabilité d’appartenance à la classe.

Génération

Nous demandons une liste, donnons un exemple puis débutons la suite de la liste par le chiffre 2.

Attention, tous ces produits ne sont pas réellement Open Source !

Parsing de données non structurées

Peut-être l’illustration la plus surprenante, le moteur va réussir à mettre en tableau un texte donné en langage naturel.

Seul le premier exemple a été soumis.

Extraction d’information

A nouveau, nous donnons une description du document qui sera soumis entre guillemets.

Toutefois, en essayant le même prompt dans ChatGPT (basé sur GPT 3.5), nous obtenons une réponse tout à fait correcte !

Code view

Prenons maintenant l’exemple d’un résumé de texte, avec pour objectif d’utiliser cette fonctionnalité en dehors du studio Azure OpenAI.

Le code correspondant à cet appel dans le playground est disponible (en Python).

Ce code utilise la librairie Python openai (à installer avec la commande pip install) et nécessitera de connaître une des clés du service.

Pourquoi ne pas demander au modèle de générer un code Python appelant cette API ? Voici le résultat obtenu.

Nous ne disposons pas ici d’un quota suffisant pour que le code s’écrive en entier. L’utilisation de GitHub Copilot sera plus adaptée dans ce cas de figure.

En résumé (et sans l’aide de GPT-3 !), nous pouvons successivement déployer un modèle, l’expérimenter à l’intérieur du terrain de jeu (playground) puis déployer une application qui s’appuiera sur l’API mise à disposition par Azure OpenAI.

Avantages d’Azure pour OpenAI

Utiliser OpenAI au travers d’Azure donne accès à trois pratiques d’entreprise :

  • la disponibilité régionale
  • la mise en réseau privé
  • le filtrage de contenu d’IA responsable

Une logique d’accès par RBAC (Role Based Access Control) pourra également être mise en place, tout comme l’authentification par identité managée (MSI).

Le portail Azure permet également une gestion des clés d’API par rotation.

Bien sûr, l’utilisation au travers d’Azure engendre une facturation dont les modalités sont détaillées sur cette page. Les coûts seront engendrés par l’inférence (utilisation prédictive) des modèles ainsi que par leur personnalisation (entrainement de type transfer learning).

Cette réponse n’est pas juste ! N’oubliez pas que GPT-3 ne scanne pas le web pour répondre.

Veuillez également prendre en compte les quotas et limites appliquées. Une demande au support permettra de lever certaines de ces limites.

Choix de la région

A ce jour (février 2023), seules trois régions Azure sont disponibles.

L’utilisation de deux régions différentes permet d’assurer une continuité d’activité. Ainsi, si un datacenter vient à être indisponible dans une région, il est possible de basculer (par modification du endpoint) vers une autre région Azure.

Utilisation dans un réseau privé

L’utilisation d’un réseau privé sécurise l’accès au studio Azure OpenAI, qui devra par exemple se faire au travers d’un VPN.

Il est également possible d’enclencher le pare-feu Azure (firewall) et de n’autoriser qu’une liste d’adresses IP à accéder au studio OpenAI.

IA responsable

Outre les engagements pris au travers du formulaire de demande du service, la documentation de Microsoft nous incite à respecter les points suivants lors d’une intégration des services Azure OpenAI :

  • Mettre en œuvre une surveillance humaine significative.
  • Mettre en place des limites techniques strictes sur les entrées et les sorties afin de réduire la probabilité d’une utilisation abusive au-delà de l’objectif prévu de l’application.
  • Tester les applications de manière approfondie afin de détecter et d’atténuer les comportements indésirables.
  • Établir des canaux de feedback.
  • Mettre en œuvre des mesures d’atténuation (bias mitigation) supplémentaires propres à chaque scénario.

A termes (ce n’est pas aujourd’hui le cas), un filtrage de contenu supplémentaire sera mis en place par Microsoft. Celui-ci est décrit dans la documentation. Concrètement, un utilisateur proposant un prompt avec un contenu inapproprié recevra, à l’appel de l’API, un code erreur HTTP 400 et une description “content_filter” dans le corps de la réponse. Une demande au support permet d’activer dès à présent ce filtrage.

EDIT : le filtrage de contenu sera activé le 13 février 2023.

With our latest update we’re providing content filters with significant quality and precision improvements. We have adjusted the system to filter at higher severity levels with each category (Hate and Fairness, Sexual, Violence, Self-harm) and expanded coverage across other languages. 

Once the filters are turned back on, the system will resume blocking harmful prompts and model generations.

email Azure OpenAI Support

S’inscrire au service OpenAI sous Azure

Est-il besoin de présenter la société Open AI dont le modèle GPT3 connaît une renommée planétaire, suite à la mise en service de ChatGPT ?

Au delà du buzz, des exemples humoristiques ou de la recherche des erreurs (souvent dans des cas d’utilisation pour lesquels il n’a pas été entrainé), nous disposons dorénavant d’un accès professionnel aux modèles d’Open AI sous Azure, et ce sous le statut de general availability (GA), c’est-à-dire avec tout le support et garantis de service (SLA) attendus.

Une recherche de “openAI” dans la barre du portail Azure nous donne accès à la création de notre première ressource Azure OpenAI. Il faut remarquer ici que ce service est catégorisé comme un service cognitif, services qui représentent l’intelligence artificielle “appliquée” au sein des services Azure.

Un descriptif du service est donné, citant ses principales fonctionnalités (résumé, génération de contenu ou de code) :

Enable new business solutions with OpenAI’s language generation capabilities powered by GPT-3 models. These models have been pretrained with trillions of words and can easily adapt to your scenario with a few short examples provided at inference. Apply them to numerous scenarios, from summarization to content and code generation.

Azure portal

A ce jour, le modèle GPT est disponible ainsi que CODEX qui s’exprime au travers de GitHub Copilot. La génération d’images grâce au modèle DALL-E est encore en préversion (preview) sous Azure.

Avant de pouvoir réellement accéder à la création du service, un avertissement est donné :

Azure OpenAI Service is currently available to customers via an application process. Request access to Azure OpenAI Service.

Un formulaire sera nécessaire pour obtenir le droit de créer une ressource Azure OpenAI. Au bout d’un délai de quelques jours, vous serez informés de l’approbation ou du rejet de votre demande. Nous allons ici détailler quelques-unes des 35 questions posées afin de bien comprendre les cas d’usage autorisés et les garde-fous posés par Microsoft.


Description des cas d’usage

Please explain how you will use Azure OpenAI Service in your application.

  • Please explain the data you will use,
  • how you plan to use the models,
  • how people will consume or interact with the outputs,
  • and more details about the domain or industry in which you will use the application.

PLEASE PROVIDE AT LEAST 5+ SENTENCES. IF YOUR USE CASE IS TOO SHORT OR TOO VAGUE, YOU WILL BE DENIED.

Il s’agit tout d’abord de décrire l’usage qui sera fait du service Azure OpenAI, sur un principe de “bout en bout” : données en entrée, modèle(s) utilisé(s) et interactions avec l’utilisateur. Le cas d’usage doit être suffisamment détaillé et il convient de préciser le domaine ou le secteur d’activités concerné, même si ce dernier point fera l’objet de la question suivante.

Ce paragraphe est particulièrement important et vous devez démontrer qu’une réflexion a déjà été élaborée autour de l’application que vous souhaitez développer. Lorsque vous achetez des outils dans un magasin de bricolage, vous avez sans doute déjà une idée de ce pour quoi vous allez les utiliser !

Domaine(s) d’utilisation

Applications in these domains may require additional mitigations and will be approved only if the customer demonstrates that the risks associated with the application are well-managed and outweighed by the beneficial uses.

Le terme à retenir ici est celui de mitigation (atténuation) que l’on emploie dans l’expression “bias mitigation” pour éviter la correction des biais possibles d’un modèle d’apprentissage. Outre la détection des biais, des actions devront être entreprises pour éviter l’effet néfaste qu’ils pourraient avoir sur les utilisateurs. Des librairies spécifiques existent pour cela comme le produit Open Source FairLearn, développé par Microsoft.

Les différents domaines “à risque” ou dits encore “à enjeux élevés” sont :

  • Law enforcement, legal, and criminal justice
  • Healthcare and medicine Government and civil services, such as essential private and public services Politics
  • Financial services and banking Social media
  • Management and operation of critical infrastructure
  • Pollution and emission management and control
  • Migration, asylum, and border control management
  • Education, vocational training, hiring, and employment, such as applications in consequential decision making that impacts one’s opportunities
  • Therapy, wellness, relationship coaching or forecasting, such as relationship advice or bots for companionship, emotional support, or romance
  • Military or intelligence
  • Other scenario that could have a consequential impact on legal position, life opportunities, or result in physical or psychological injury to an individual if misused
  • None of the above. The domain, industry, or scenario do not have the potential to have a consequential impact on legal position, life opportunities, or result in physical or psychological injury to an individual if misused

Il conviendra de cocher “None of the above” si aucun de ces domaines n’est concerné.

Fonctionnalités attendues

Il serait tentant de tout cocher dans cette question 26 ! En effet, vous avez sûrement beaucoup d’idées d’utilisation des services d’OpenAI mais il faut ici se limiter à ceux qui seront réellement utiles à votre cas d’usage décrit ci-dessus. Il est peu probable qu’un agent conversationnel (chatbot), dans un scénario d’entreprise, propose des images générées par DALL-E ! Soyez donc raisonnables sur les fonctionnalités demandées et si besoin, remplissez plusieurs formulaires, en isolant les applications.

Fonctionnalités spécifiques de l’agent conversationnel

Si vous avez coché la case “Conversational AI” à la question 26, vous devez préciser les fonctionnalités attendues pour l’agent conversationnel.

Attention à nouveau si vous prévoyez de déployer ce bot dans un domaine “à enjeux élevés”.

Acceptation des conditions d’utilisation

Enfin, il sera nécessaire d’approuver explicitement les conditions d’utilisation (“Yes, I agree“) énoncées dans les questions 29 à 35. C’est tout particulièrement sur l’usage en production que vous allez devoir vous engager.

Question 29

29. I understand that mitigations should be considered early in development and must be implemented prior to production.

N’attendez pas d’être en production pour atténuer les biais !

Question 30

30.My application will ensure human oversight prior to production.

This includes never automatically posting generated outputs and never automatically executing generated code. This may also include clearly disclosing AI’s role, communicating relevant limitations to stakeholders (including developers and end users), making sure people (e.g., end users) have a role in decision-making, highlighting inaccuracies in generated outputs, and letting people edit generated outputs.

Ce point nous alerte sur des chaines de CI/CD trop automatisées : un contrôle humain est nécessaire. (Si vous me connaissez bien, vous m’avez déjà entendu pester contre le Continuous Training :))

Question 31

31.My application will implement strong technical limits on inputs from end users and outputs from the system prior to production.

This increases the likelihood your application will perform as expected and decreases the likelihood it can be misused beyond its intended purpose. This may include limiting the length of inputs and outputs, exposing the service to end users through a front end, requiring that inputs and outputs follow a specific structure, returning outputs only from validated source materials, implementing blocklists or content filtering, and implementing rate limits.

En production, un contrôle fort sur les entrées et les sorties sera essentiel. Il s’agit par exemple d’éviter tout détournement de l’usage intial prévu. Ainsi, au démarrage de ChatGPT, il était possible de contourner certaines de ses limites en lui demandant de jouer un rôle.

Question 32

32.I will test my application thoroughly prior to production to ensure it responds in a way that is fit for the application’s purpose.

This includes conducting adversarial testing where trusted testers attempt to find system failures, undesirable behaviors such as producing offensive content, and ways that application can be misused by malicious actors beyond its intended purpose.

Non, tester n’est pas douter ! Ici, il s’agira même d’essayer de “hacker” votre propre application.

Question 33

33.My application will establish feedback channels for users and impacted groups prior to production.

This includes providing ways to report problematic content and misuse such as building feedback features into the user experience and providing an easy to remember email address for feedback submission. 

A minima, votre application devra donner un contact simple, par exemple par email, aux utilisateurs qui souhaiteraient faire part de leur réaction. Au mieux, vous pourrez penser une vraie boucle de feedback (human feedback loop), qui vous servira à termes à améliorer le modèle et l’expérience utilisateur.

Question 34

34.My application will follow the Microsoft guidelines for responsible development of conversational AI systems prior to production.

Prenez connaissance des principes pour une IA responsable, donnés par Microsoft.

Question 35

35.I will resubmit this form for a production review before going into production.

Avant le passage en production, et surtout si des changements sont apparus par rapport à l’expression du cas d’usage intial, il sera nécessaire de soumettre à nouveau le formulaire.

Maintenant que vous connaissez les conditions à remplir, vous voilà prêts à décider si l’expérience Azure OpenAI est une opportunité pour vous et votre organisation !

Utiliser Dataïku DSS sur Azure (sandbox)

En France, le milieu de la Data Science connaît bien, de réputation au moins, la société Dataïku et son Data Science Studio qui s’est imposé comme l’une des plateformes SaaS les plus performantes du marché. Le cadran Gartner a reconnu la société qui est aujourd’hui implantée à New-York.

Si la plateforme peut être installée sur les serveurs de l’entreprise, il est également possible de l’utiliser, supportée par les ressources du Cloud, en particulier, le cloud Azure de Microsoft.

Utiliser Dataïku DSS au sein d’Azure

Nous allons commencer par créer un groupe de ressources Azure dédié à Dataïku DSS.

Dans la Market Place Azure, nous trouvons deux entrées :

  • Dataïku Enterprise Ready AI
  • Dataïku Trial (sandbox)

Nous allons commencer par la version “bac à sable” et de prochains articles traiteront de la version Enterprise.

La tarification se fait sur le temps où la machine virtuelle Linux est allumée, et en fonction du type de machine choisie.

Le choix de la configuration d’installation se fait entre deux modes :

  • Dev/Test
  • Production

La configuration de la machine virtuelle se termine en choisissant une image contenant l’installation de Dataïku DSS.

Nous disposerons ainsi de la version 9 de Dataïku DSS, dont le descriptif est disponible sur cette page.

Il sera sûrement nécessaire de se connecter directement à cette machine et nous choisissons le mode SSH, qui demandera la création d’un clé privée, à télécharger sur le poste depuis lequel nous accèderons à la machine. Pensez à utiliser WSL pour faciliter toutes les opérations en lien avec les machines virtuelles Linux ! Mais attention, en version sandbox, les répertoires d’installation de Dataïku ne seront pas accessibles. Cela nous empêchera en particulier d’installer un driver JDBC nécessaire pour communiquer avec une ressource Azure Synapse Analytics mais nous y reviendrons dans un prochain article.

Il ne sera enfin pas possible de se connecter avec une identité présente dans l’annuaire Azure AD.

Nous terminons le processus de création sur un récapitulatif tarifaire, indiquant bien que nous ne serons facturés que sur l’utilisation de la machine virtuelle.

Il suffit maintenant de saisir l’IP publique de la machine virtuelle Linux dans un navigateur (connexion http non sécurisée pouvant lever une alerte dans votre navigateur).

Sans licence, nous cliquons sur “NO” afin d’entamer la phase d’évaluation du produit ou son utilisation gratuite (Free Edition).

Le Studio est maintenant prêt et nous disposons d’un login / password (admin /admin par défaut) pour nous reconnecter ultérieurement.

Nous voici dans le Data Science Studio.

Si vous utilisez à plusieurs cette ressource, il est recommandé de créer d’autres comptes utilisateurs.

De prochains articles viendront présenter les interactions de Dataïku DSS avec différentes ressources Azure :

  • Azure Storage Account (blob ou Data Lake gen2) pour le stockage de données
  • Azure Synapse Analytics – SQL pool (anciennement DataWarehouse) comme source de données ou cible d’écriture
  • Azure Synapse Analytics – Spark pool comme ressource de calcul, en particulier pour les entrainements
  • Azure Kubernetes Services en particulier pour le serving de modèles

Suivre l’utilisation d’un modèle de ML grâce à Azure Log Analytics

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.

Le détail des éléments supervisés est disponible dans la documentation officielle.

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 :

traces
|where message == "STDOUT"
   and customDimensions.["Service Name"] == "diabetes-custom-service1"
|project timestamp, customDimensions.Content

Nous obtenons le résultat ci-dessous.

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.

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.

Azure Fundamentals, c’est… fondamental !

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 certification AZ-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

  • Sécurité en couches
    • Azure Security Center
  • Authentification (AuthN) unique – multifacteur, autorisation (AuthZ)
    • Azure Active Directory
  • Distribution d’identités aux services
    • Service principal
    • Identité managée
  • Contrôle d’accès en fonction du rôle (RBAC ?)
    • Azure Resource Manager
    • Azure AD Privileged Identity Management (PIM)
  • Chiffrement
    • symétrique / asymétrique
    • au repos / en transit
  • Azure Storage Service Encryption
  • Transparent Data Encryption
  • Azure Disk Encryption
  • Azure Key Vault
  • Azure DDoS Protection
  • Groupe de sécurité réseau
  • Réseau privé virtuel (VPN)
    • Azure ExpressRoute
  • Microsoft Azure Information Protection (MSIP / AIP)
  • Azure Advanced Threat Protection (ATP)

# Appliquer et superviser les standards d’infrastructure avec Azure Policy

  • Azure Policy
  • Groupe de gouvernance
  • Azure Blueprint
  • Déclaration de confidentialité Microsoft
  • Centre de gestion de la confidentialité Microsoft
  • Portail d’approbation de services
  • Gestionnaire de conformité
  • Azure Monitor
  • Azure Health Service

# Contrôler et organiser les ressources Azure avec Azure Resource Manager

  • Groupe de ressources
  • RBAC
  • Etiquettes
  • Stratégies
  • Verrous

# Prévoir les coûts et optimiser les dépenses pour Azure

  • Zone de facturation
  • Azure Advisor
  • Azure Cost Management
  • Azure Hybrid Benefit

Que propose Microsoft pour la Data Science ?

En mars 2019, je publiais sur un blog ami cet état des lieux de l’offre Microsoft pour la Data Science : https://www.stat4decision.com/fr/microsoft-pour-la-data-science/

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.