Retour sur la matinée Modern data-science avec Dataiku et Azure Databricks
Pour beaucoup d’organisations, la problématique du passage des algorithmes depuis le laptop du Data Scientist vers un environnement urbanisé, gouverné et de plus grande ampleur reste une difficulté prégnante : incompréhension sur les langages utilisés, manque de protocole de test ou de déploiement, architectures très jeunes, méfiance quant à la retombée certaine suite à la vague de « hype » de certains produits…
Dans cet article, nous aborderons les interactions entre les trois services que sont le cloud Azure (1), le service managé de clusters Databricks (2) et la plateforme de Data Science Dataïku DSS (3), présentés au cours d’une matinée de formation dans les locaux de Microsoft France le jeudi 4 juillet 2019.
Trois produits pour un traitement de la donnée de bout en bout
En mars 2019, Dataïku sort la version 5.1 de sa plateforme DSS et celle-ci propose un nouveau partenariat pour étendre la puissance de calcul et permettre de grimper enfin sereinement la grande échelle du volume de données. En effet, le serveur sur lequel est installé DSS joue surtout un rôle d’organisation des projets et de gestion de la collaboration entre les personnes y accédant. Dans un schéma d’architecture plus complet, on s’appuiera sur plusieurs technologies complémentaires pour répondre aux quatre phases d’un projet data.
Pour résoudre la problématique du calcul lorsque celui-ci est conséquent, les systèmes distribués basés sur Apache Spark se sont imposés par leur performance lié au fait de monter la donnée en mémoire. Spark est justement le cœur Open Source de la solution commerciale Databricks. En partenariat fort avec Microsoft, celle-ci est présente dans le portail Azure sous forme de service managé. Ainsi, créer un service Azure Databricks revient à déclarer un nom d’espace de travail qui sera localisé sur une des régions Azure. Il est dès lors possible de se connecter au portail Azure Databricks. Seul le temps d’utilisation d’un cluster est facturé. L’interface d’Azure Databricks est à la fois simple et relativement complète, car basée sur les notebooks Jupyter. On développera donc en Python, R ou SQL qui appelleront respectivement les API PySpark, SparkR et SparkSQL. Mais pour celles et ceux qui maîtrisent ce langage, il faudra privilégier Scala car c’est le langage natif de la plateforme. De nombreux connecteurs sont disponibles, en particulier pour Azure Blob Storage et Data Lake Storage Gen2 qu’on « mountera » pour plus de facilité d’utilisation. Le schéma du projet data s’adapte donc comme suit dans le cloud Azure.
Jusqu’à présent, Dataïku présentait sur la market place Azure une distribution utilisant le service Azure HDInsight, cluster Hadoop adapté à partir de la distribution Hortonworks. La simplicité de paramétrage et l’efficacité de Databricks vont très certainement rendre caduque cette option. Mais voyons tout d’abord quels sont les cas d’usage de cette alliance et qui en seront les principaux utilisateurs.
Qui monte à l’échelle et pourquoi ?
Paradoxalement (du point de vue des data scientists), la question des cas d’usage de la Data Science se pose toujours fréquemment dans les organisations. Si l’on sort des classiques détections de fraude, churn, maintenance prédictive ou analyse de sentiments sur des tweets (pitié, pas encore l’analyse de tweets…), on peut dire que l’analyse de la donnée répond à un grand nombre de questions du moment qu’on se les pose… et que la réponse peut être génératrice de valeur pour l’organisation ! Faîtes un test, votre entreprise peut-elle répondre rapidement aux trois questions suivantes :
• Quels sont mes clients qui ont le plus de valeur ?
• Quels sont mes produits les plus importants ?
• Quelles sont mes campagnes (marketing, de communication, de SAV, etc.) les plus réussies ?
Si ce n’est pas le cas, la Data Science peut certainement beaucoup vous apporter !
Avec l’essor du Deep Learning, DSS a aussi la capacité à traiter des problématiques autour de la donnée non structurée comme les images ou les corpus de texte, ce qui étend encore plus les cas d’usage, en sortant des données structurées des ERP, CRM ou autres bases relationnelles traditionnelles.
Si DSS se veut une plateforme regroupant tous les utilisateurs de la data, on dégagera néanmoins deux grands profils d’utilisateurs :
- Les personnes qui ne sont pas attirées par le code
- Les développeurs R / Python / Scala dont le terrain de jeu favori est le notebook
Ces deux populations trouveront les outils nécessaires à leur travail mais ce sont surtout les premiers qui disposeront au travers de l’interface visuelle de DSS d’un outil très pratique pour réaliser des opérations classiques de data preparation (cleaning, traitement des outliers, feature selection, feature engineering…) et de modélisation (Machine Learning supervisé ou non, automated ML). Si les Data Scientists dont le code reste l’approche privilégiée n’y trouveront que peu d’avantages, ce sont les Data Engineers qui tireront partie de l’approche unifiée au sein d’une même plateforme et de fonctionnalités comme le versionning des modèles.
Comment fonctionne l’interaction entre DSS et Databricks ?
L’interaction des deux solutions se définit au niveau de l’administration de Dataïku DSS (version 5.1 minimum).
On précisera l’URL du service managé Azure Databricks ainsi qu’un token qui peut être obtenu depuis le service Databricks.
Puis on indiquera le chemin du point de montage réalisé depuis Databricks vers une ressource de stockage comme Azure Blob Storage. (Nous n’avons pas testé le fait d’utiliser depuis DSS un point de montage sur Azure Data Lake Storage Gen2 mais ce dernier fait lui-même appel à la technologie du Blob Storage.)
Dataïku DSS propose de nombreuses fonctionnalités de data preparation, applicables sous forme d’étapes successives. Au moment de la création de ces étapes, on ne travaille que sur un échantillon de données pouvant résider localement. Une fois les étapes entièrement déclarées, il faut exécuter le traitement et c’est ici que l’on choisira le contexte de calcul. Si l’on choisit le contexte Spark, les actions sont exécutées en SparkSQL.
Attention, certaines actions ne peuvent pas être converties en SparkSQL et ne bénéficieront donc pas de la puissance du cluster.
Pour l’entrainement d’un modèle de Machine Learning défini à partir des interfaces graphiques de DSS, le choix du contexte de calcul se présentera de nouveau.
Le contexte In-memory revient à utiliser la librairie Python scikit-learn, dans l’environnement local. Si l’on choisit MLLib, c’est bien évident le contexte Spark qui est mis à contribution (et vraisemblablement l’API travaillant avec les DataFrames et non les RDD, ce mode de fonctionnement étant voué à disparaître à partir de Spark 3.0).
Le fonctionnement en flux (« Flow ») de DSS peut être vu comme un Spark Pipeline et il sera ainsi possible de convertir plusieurs étapes successives, par exemple de préparation qui deviendront une suite d’instructions SparkSQL et ne réaliseront pas de lectures / écritures intermédiaires sur le point de montage.
La conversion en recette Spark est irréversible, on l’effectuera donc une fois la phase de développement terminée.
Enfin, les notebooks pourront aussi bien sûr bénéficier du contexte Spark pour exécuter du code Scala ou en appelant les API PySpark et SparkR.
Nos impressions
Tout d‘abord, n’oublions pas qu’il s’agit de la première version de DSS intégrant Databricks et des améliorations sont sûrement à venir.
Une fois la configuration faite, DSS interagit de manière autonome avec Databricks et il sera préférable (au moins dans la version 5.1) de passer par le fichier JSON de configuration du cluster, lui-même obtenu depuis l’UI de Databricks. Ainsi seront disponibles des options comme l’auto-scaling (capacité à solliciter automatiquement plus de ressources lorsque cela est nécessaire et possible), ou encore la différenciation des machines virtuelles entre les worker nodes et le driver node. Rappelons ici que l’autotermination est une fonctionnalité particulièrement pertinente de Databricks : en l’absence d’utilisation durant un temps donné, le cluster se met automatiquement en pause, et n’est donc plus facturé.
Au lancement du premier job, il faudra quelques minutes pour que s’active le cluster Databricks. Cela correspond à la création ou au « réveil » de quelques VM Azure.
A ce jour, lorsqu’un job se lance sur un cluster déjà occupé par un précédent job, un nouveau cluster est lancé. En revanche, un cluster disponible peut être directement utilisé par d’autres utilisateurs, sauf à enclencher le mode « per user cluster » qui isole chaque utilisateur dans son propre cluster.
Il ne semble pas possible en l’état de solliciter un cluster créé directement sur l’interface Databricks, voire qui serait déjà actif au moment du lancement du premier job depuis DSS.
On imaginera ici facilement l’intérêt de pouvoir autoriser certains clusters à certaines typologies d’utilisateurs. C’est tout à fait possible en créant plusieurs services Azure Databricks, par exemple pour des environnements de développement, qualification et production, et ce sans coût autre que leur utilisation.
Sur Azure, deux modes de licence sont disponibles pour Databricks : standard et premium. La licence premium permet l’usage collaboratif de la plateforme et en particulier des notebooks. [EDIT : la licence standard est suffisante pour l’interaction avec DSS et c’est une bonne nouvelle !]
Si les Data Scientists sont férus de code, même pour les opérations rébarbatives de data preparation, l’ajout de la plateforme DSS se justifiera sans doute moins mais il faudra alors avoir recours à des Data Engineers ayant une bonne maîtrise d’Azure et des technologies Open Source (package Flask pour Python par exemple) pour développer toute la partie d’exposition des modèles prédictifs. Une évaluation de ces coûts doit être faite et mise en regard du coût d’une plateforme complète.
Le modèle est prêt, on l’expose !
Pourquoi ce modèle de détection de churn si efficace sur des données de test ne pourrait pas rendre service au quotidien à l’équipe marketing ? Bien souvent parce que les outils nécessaires ne sont pas encore très connus des DSI. Pourtant, il s’agit finalement d’une API que l’on exposera au travers d’un service Web. La chose se complique lorsqu’une préparation de données (parfois à base de packages Python assez « exotiques ») est nécessaire avant d’appliquer la fonction de scoring du modèle.
Dans le cadre d’un modèle Python relativement simple, Azure propose aujourd’hui de créer une image Docker contenant le modèle sérialisé, au format Pickle, ainsi que les dépendances (packages) nécessaires. Cette image est ensuite déployée au moyen d’un des deux services : Azure Container Instances ou Azure Kubernetes Service. On préférera le second pour un passage en production et c’est justement ce service sur lequel DSS peut s’appuyer. Mais ce sujet méritera bien un article à lui seul !
Notes : Voici en quelques mots et quelques liens une présentation des trois services utilisés si vous ne les connaissez pas jusqu’à présent.
(1) Microsoft Azure : cloud public mettant à disposition des services développés par Microsoft ainsi qu’une market place
https://azure.microsoft.com/fr-fr/
(2) Azure Databricks : portail lié au cloud Azure pour la création et l’utilisation de clusters Spark, principalement au travers de notebooks
https://azure.microsoft.com/fr-fr/services/databricks/
(3) Dataïku Data Science Studio : plateforme collaborative de Data Science mêlant une interface de développement à la possibilité d’utiliser les principaux langages d’exploration et d’analyse de données