Le Self-Service Big Data avec Dataiku

​Ce​tte chronique est un livre blanc qui présente notre retour d’expérience sur l’outil Dataiku que nous avons utilisé lors de la réalisation d’un Poc of Hypothesis (Preuve d’Hypothèse – qui est un projet dans lequel on souhaite infirmer ou confirmer la faisabilité technique d’un ensemble d’idées).  Il a pour ambition de présenter les opportunités et les challenges qui se présentent lors de l’utilisation d’un outil de Self-Service comme Dataiku dans un projet Big Data. Il sera particulièrement utile à tous les décideurs (métiers ou IT) qui s’interrogent sur l’intérêt d’adopter un outil de Self-Service tel que Dataiku dans un projet Data.

1) Définition et enjeux de la Self Service Analytics

Avant d’étudier l’outil Dataiku proprement dit, il est important de commencer par comprendre son positionnement. Dataiku fait partie de la catégories des outils de « Self-Service ».

La Self Service est un concept qui a été inventé par les éditeurs de logiciels de Data Science. Ce concept représente la démocratisation de la Data Science et sa mise en disposition entre les mains des utilisateurs métiers. Concrètement, il s’agit pour les éditeurs de proposer aux utilisateurs n’ayant pas de compétences Data des solutions user-friendly ou « clic-bouton » qui leur permettent de valoriser leurs données.

Actuellement, la Data Science fait référence à toutes les techniques qui permettent d’extraire de la valeur des données. Ces techniques proviennent pour l’essentiel des disciplines suivantes : le contrôle de gestion, les statistiques, l’économétrie, la recherche opérationnelle et l’intelligence artificielle.

Elle fait également référence aux méthodes et outils d’aide à la décision, notamment : des scores d’appétence, des graphiques, des indicateurs clés de performance (KPI) ou encore des tableaux croisés. En matière de méthode ou méthodologies, 2 process sont identifiés actuellement pour la valorisation des données : il s’agit de la méthodologie SEMMA de SAS Institute, et de la méthodologie CRISP DM d’IBM SPSS. Ainsi de façon globale, tout projet Data peut se décomposer en au moins cinq phases :

• Acquisition des données ;
• Exploration et Transformation des données ;
• Modélisation des données ;
• Restitution de données ;
• Mise de production des modèles développés

Cela veut dire que tout logiciel de Self-Service orienté Data doit fournir des outils réaliser ces 5 phases. Comme nous l’avons déjà mentionné dans notre chronique sur l’architecture SOA et les micro-services, le logiciel doit aussi pouvoir s’aligner au Système d’Information de l’entreprise pour servir ses objectifs business.

Cela signifie que lorsqu’un éditeur dit qu’il souhaite « mettre la Data à la portée de tous » (ce qui est l’ambition du Self-service), il est en train de dire :

• qu’il souhaite  masquer la complexité technique liée aux 5 phases générales d’un projet Data, plus précisément :
• permettre à l’utilisateur de pouvoir acquérir les données de toute source, de différents formats, de différente taille sans connaissance particulière des techniques de communication entre différents systèmes ;
•  permettre à l’utilisateur d’effectuer des opérations de transformation de données (par exemple jointure de tables, création de nouvelles colonnes, nettoyage des données) sans compétence particulière en techniques et langage de manipulation de données tels que le SQL, le XQuery, le SPARQL,…etc ;
•  permettre à l’utilisateur de pouvoir utiliser les algorithmes statistiques sans avoir un background important en statistiques ;
• assister l’utilisateur dans le développement de ses restitutions ;
• et assister l’utilisateur dans le déploiement de ses modèles ou les applications qu’il a développées dans le système informatique de l’entreprise sans intervention de l’équipe IT (ou avec une faible intervention de leur part). 

Voilà les challenges à surmonter pour démocratiser la data au sein de l’entreprise ! Maintenant intéressons-nous aux raisons de l’adoption d’une approche Self-Service pour un projet Data.

2) Intérêt d’une approche Self-Service dans un projet Big Data

Malgré les challenges évoqués plus haut, adopter une approche de Self Service pour son projet Data peut s’avérer utile. Elle aura comme principale impact un gain de temps pour la valorisation des données.

 L’approche Self Service pour des projets Data est né en réponse  à  2 facteurs :

• Le trop grand contrôle qu’exerce l’IT sur la donnée en entreprise (généralement pour des raisons de sécurité et de gouvernance). En effet, dans un souci de gouvernance des Systèmes d’Information, l’accès aux données est souvent très restreinte et soumise à des processus administratifs et technologiques très stricts qui sont généralement exclusivement de la responsabilité du département informatique. Ces processus administratif et technologique se traduisent par la mise en place en entreprise d’une chaîne de Business Intelligence composée d’un process Accès aux sources de données, d’un process OLAP et d’un process Restitution. Le Data Analyst, qui est la personne qui a le plus besoin de données dans l’entreprise, se situe à la fin de cette chaîne, et se retrouve généralement en train de travailler avec un échantillon de données pré-transformé par un ETL qui limite sa flexibilité dans les analyses et les études qu’il peut mener avec ses données. La figure suivante exprime bien ce cadre de gouvernance limitant pour les analystes de données.

Comme l’illustre ce schéma, un long processus est nécessaire pour que le Data Analyst ou les équipes métiers puissent exploiter les données. Ils doivent d’abord faire une requête (leurs exigences et spécifications) auprès du service informatique, qui extrait la donnée brute des sources de données, ensuite ces données sont stockées dans un Data Warehouse. Ce n’est qu’après que les données deviennent disponibles. Le temps nécessaire pour ce processus peut être très long et ainsi nuire au au travail des métiers ou analystes de données (décalage temporel, temps de mobilisation, …).

Au travers d’un accès plus direct aux données et de la capacité à transformer ces données pour les traiter, une approche Sef-Service peut être préconisée.

• L’exploitation et la valorisation des données demandent un mixte de 2 types de compétences : des compétences en méthodes d’exploitation de données (techniques de gestion de données et algorithmes statistiques) et des compétences Métier (par exemple : marketing, finances, …etc). En général, les métiers ne possèdent pas de compétences en méthodes d’exploitation de données, mais possèdent l’expérience et les compétences fonctionnelles nécessaires pour valoriser la donnée. La Self Service se propose de masquer la complexité de l’utilisation et de la programmation des algorithmes statistiques, et de permettre au Data Analyst de se concentrer sur la valorisation de ses données.

Maintenant que les enjeux, les challenges et les opportunités d’une approche Self Service ont été abordées, nous allons maintenant passer au coeur de notre chronique : Dataiku.

3) Présentation et positionnement de Dataiku

Dataiku est un éditeur français qui se positionne exclusivement sur une approche Self-service. La société a été fondée en 2013 par Marc BATTY, Thomas CABROL, Florian DOUETTEAU et Clément STENAC. Elle emploie aujourd’hui plus de 400 personnes dans le monde. Son siège social est basé à Paris et elle compte parmi ses clients AXA, Vente privée, L’Oréal, Chronopost, BlaBlaCar, …

Globalement, l’approche de Dataiku consiste à offrir une plateforme logicielle intégrée :

• aux écosystèmes Big Data (Hadoop et Spark),
• aux langages Open Sources les plus utilisés en Data Science (R et Python),
• aux bases de Données Relationnelles « Traditionnelles » de type HP Vertica ou MySQL,
• aux bases de données NoSQL tels que Cassandra, MongoDB ou encore ElasticSearch,
• aux outils de Data Visualisation tels que Tableau ou du sur-mesure avec la possibilité de créer ses propres tableaux de bord permettant la mise en production d’un workflow (mobilisation de données, transformation des données, modélisation, indicateurs de suivi).

De part son couplage à des technologies existantes (MySql, Hadoop, …), Dataiku offre la possibilité de valoriser au mieux les données. De même, la possibilité d’exploiter des logiciels libres comme Python et/ou R est un vrai avantage lorsqu’on fait de la Data Science. En effet, la plupart des librairies utilisées dans ce domaine sont codées dans ces langages (scikit-learn, sciPy, ..).

Grâce à son interfaçage avec Hadoop et la possibilité d’utiliser Spark, Dataiku permet de traiter des volumes importants de données. Cela positionne Dataiku comme un acteur du marché de la Big Data. Les calculs de grande d’échelle ne sont pas nécessairement effectués par Dataiku, ils peuvent être transférés vers les environnements de calcul massivement parallèles. De la même manière, si vous avez une jointure entre deux tables de gros volume à exécuter, vous avez la possibilité de transférer cette opération de jointure à Vertica HP ou MySQL (liste non-exhaustive) pour une plus grande rapidité dans le traitement.

Ainsi, l’intégration de Dataiku dans un système d’information est une intégration clairement horizontale. Cette stratégie optée par Dataiku permet aux Data Scientists, Data Engineers, Data Analysts d’avancer plus rapidement dans la réalisation de leurs projets. De plus, la présence des langages R, Python et SQL rajoutent la possibilité pour eux  de pouvoir faire du développement spécifique pour des besoins plus complexes. 

Toutes ces fonctionnalités font de Dataiku un outil complet dans le cadre d’un projet Data. Il répond pleinement aux 5 principes clés évoqués précédemment dans la première partie de la chronique.

Attention !!! Intégration Verticale vs intégration horizontale

A titre d’éclaircissement, dans le domaine logiciel, une stratégie d’intégration horizontale est une stratégie de développement logiciel qui consiste à s’appuyer à des environnements/logiciels existants. Un éditeur qui développe ses produits de façon horizontale développe des interfaces informatiques qui permettent à ses produits de s’intégrer avec des logiciels externes. Tandis qu’une stratégie d’intégration verticale consiste à développer et à embarquer dans son produit toutes les fonctionnalités offertes par d’autres solutions. Par exemple, dans lE Big Data, une stratégie d’intégration verticale revient à embarquer dans sa solution les outils de l’écosystème Hadoop, ou à les [re]développer soi-même, tandis qu’une stratégie d’intégration horizontale revient à développer des connecteurs qui permettent d’exploiter l’écosystème Hadoop. Nous développons ce point dans notre ouvrage « Maîtrisez l’utilisation des technologies Hadoop« .

Cette figure illustre l’intégration horizontale de Dataiku aux autres environnements de calculs disponibles dans un Système Informatique existant. La première couche représente le noyau de Dataiku, développé en Java. La deuxième couche du graphique représente les langages qui servent d’interface avec les autres environnements de calcul. La troisième couche représente les différentes plateformes externes qui peuvent servir de levier à Dataiku pour le traitement de données.

4) Concurrents de Dataiku

Cette partie a pour objectif de recenser les principaux concurrents de Dataiku en présentant les couvertures fonctionnelles respectives.

Dataiku identifie ses concurrents comme étant les solutions suivantes :

• Datameer ;
• Paxata ;
• Data Robot
• Alpine Labs

Pas perçu comme étant des concurrents directs de par leur taille, il semble important d’y rajouter les solutions des gros éditeurs :

• SPSS de IBM
• SAS
• RapidMiner
• Alteryx

Les gros éditeurs en terme commercial constituent des concurrents de Dataiku, puisqu’ils se positionnent comme acteurs historiques du marché de la Data et du Big Data, cependant en termes d’approche d’intégration, ils ne sont pas comparables. En effet, Dataiku est positionné horizontalement, tandis que les gros éditeurs sont pour la plupart intégrés verticalement. Le type d’intégration détermine les fonctionnalités et les limites qui seront rencontrées sur les outils en terme fonctionnel. Nous proposons ce tableau pour vous montrer le positionnement de Dataiku sur le marché par rapport à ses concurrents directs et les éditeurs historique.

Parallèlement à cela, tout au long du PoH sur lequel nous avons travaillé, nous avons effectués des travaux de benchmark de plusieurs autres solutions, notamment entre autre Dataiku et Data Robot. Nous avons effectués ce benchmark en nous appuyant sur les critères suivants :

• Connexion aux sources de données ;
• Préparation des données ;
• Data visualisation ;
• Modélisation/Apprentissage des modèles ;
• Monitoring de pertinence des modèles développés ;
• Intégration à Hadoop et l’écosystème Big Data ;
• Mise en production des modèles ;
• Monitoring des ressources système consommées par l’application et
• Utilisation dans le Cloud.

Nous avons par la suite attribué des scores estimatifs à ces outils sur la base des uses cases développés par nos soins. Cela nous a permis de positionner chaque solution selon ses points forts et ses points faibles. Le graphique suivant présente de façon visuelle le positionnement de Dataiku dans le secteur de la Self-Service Data ; nous avons choisi de rajouter dans le graphique la série de score correspondant à Data Robot pour montrer le contraste avec Dataiku.

5) Le Business Model et l’offre commerciale de Dataiku

Dataiku propose le logiciel Data Science Studio (DSS) découpé en trois « Nodes » ou 3 instances du même produit : le Studio Node, l’Automation Node et l’API Node. Le coût de la licence de DSS peut varier en fonction du nombre de Nodes qui sont intégrés dans votre offre.

Le Studio Node est la partie frontale de DSS, c’est le studio dans lequel les utilisateurs réalisent leurs travaux d’exploitation de données et construisent leurs modèles. L’Automation Node est l’instance de DSS qui fait office de « Task Scheduler » ou de planificateur de tâches. On peut y planifier l’exécution automatique d’une ou de plusieurs opérations que l’on a définies dans le Studio Node soit par un déclencheur (un Trigger) événementiel, soit à par un déclencheur temporel. Par exemple, on peut y planifier l’exécution du calcul des distances d’un modèle construit dans le Studio Node tous les jours à minuit. L’API Node ou Scoring Node est l’instance qui permet de mettre en environnement de production le modèle qui a été construit dans le Studio Node. Ce Node permet de faire tourner le modèle en temps réel.

6) Utilisation de Dataiku

Comme nous l’avons signalé plus haut, Dataiku propose DSS Studio, Automation and Scoring. Les premières phases d’un projet de data science étant l’exploration de données et la construction des modèles, c’est le DSS Studio qui est utilisé dans un premier temps. Le DSS Studio fournit un environnement interactif dans lequel les opérations de manipulation de données sont représentées par des icônes (des recettes). Vous réalisez vos travaux en reliant les recettes qui vous permettent d’atteindre l’objectif de votre étude. Cet ensemble de recettes forment dans DSS ce qui s’appelle un workflow (ou un flux de recette). Ces recettes sont des abstractions graphiques d’algorithmes qui effectuent les opérations ; ces abstractions permettent à l’analyste de gagner du temps dans la réalisation de ses travaux et de se concentrer sur le côté fonctionnel de son travail. La figure ci-après présente un exemple de workflow.

Dans DSS, plusieurs catégories de recettes sont disponibles. Des recettes pour la connexion aux sources de données (les icônes bleus), les recettes de préparation de données (les icônes jaunes), les recettes de code personnalisé (les icônes rouges) et les recettes de Data Science (les icônes vertes). A chaque recette est associée une interface qui permet à l’utilisateur de pouvoir la paramétrer. La figure ci-après montre l’interface d’une recette de préparation de données.

La figure suivante présente une interface de modélisation de données. A la différence des autres, l’interface de modélisation de données sert à la fois d’outil de monitoring des modèles et de personnalisation de ceux-ci. Cette interface présente les performances des différents modèles statistiques  qui ont été réalisés pendant le PoH.

7) Fonctionnalités de DSS

Le tableau ci-après récapitule l’ensemble des fonctionnalités majeures de DSS d’après notre expérience avec le produit (Attention !! Compte tenu des évolutions permanentes du logiciel, il est possible qu’après la publication de cette chronique, certaines fonctionnalités aient été soustraites ou de nouvelles rajoutées. Donc veuillez ultimement vous renseigner auprès de l’éditeur pour les dernières mises à jour sur ses produits :

8) Les algorithmes de Data Science nativement intégrés dans Dataiku

En fonction des problématiques : classification, régression, recommandation, clustering, …, il convient d’utiliser un algorithme plutôt qu’un autre. C’est le rôle du Data Scientist de faire ce choix en intégrant les composantes suivantes : pertinence des modèles, volumétrie des données, temps de calcul, parallélisation possible des algorithmes, …etc.

Parmi l’ensemble des algorithmes aujourd’hui utilisés pour la Data Science, la librairie Python Scikit-Learn fait référence. C’est pourquoi nous l’avons utilisée comme base de comparaison avec les algorithmes proposés nativement par Dataiku. En effet dès lors qu’il est possible de faire du code custom Python dans Dataiku, il est possible d’utiliser toute la librairie Scikit-Learn.

De plus nous avons souhaité présenter la librairie MLLib de Spark qui propose de paralléliser les calculs qui le sont sur Hadoop.

Le tableau ci-après récapitule les algorithmes disponibles actuellement en Open Source et ceux qui sont déjà intégrés dans Dataiku, que ce soit du côté distribué ou du côté Open Source (Ps : encore une fois, cette liste peut avoir évolué après la date de publication de cette chronique. Nous vous recommandons donc de vous rapprocher directement de l’éditeur pour les mises à jour).

9) Infrastructure de base de DSS

Comme dit précédemment, DSS se divise en 3 instances. Les utilisateurs accèdent au studio Node à l’aide d’un client léger (un navigateur Internet). DSS peut être installé sur un environnement dédié (machine virtuelle, dockers, …) pour éviter les interdépendances qu’il pourrait avoir entre les autres applications et les langages/outils auxquels Dataiku est intégré. Dataiku recommande comme configuration de serveur (pour l’exploration): OS version Linux de 64 bit, sur du 64 Go de RAM (facteur critique, 64 Go si Streaming ou moins si les opérations sont exécutés sur des environnements parallèles), processeur multicoeur de 3.0 GHz (facteur non critique). La figure suivant illustre l’infrastructure de DSS

Les ressources consommées lors de l’utilisation de Dataiku dépendent de la localisation des opérations. Dans le cadre du PoH, nous avons développé un tableau estimatif des ressources consommées selon les phases du projet et selon la localisation des opérations. Ce tableau estimatif donne à l’IT une indication sur l’infrastructure informatique à mettre en place lors de l’utilisation de Dataiku. C’est aussi une indication pour anticiper les éventuelles hausses de charge qui pourraient faire arrêter le système informatique lors de l’exécution de certains algorithmes de machine Learning  gourmands en ressources.

10) Installation et Configuration de Dataiku DSS dans le projet

Dans le cadre de la réalisation du PoH, nous avons installé chaque Node Dataiku sur un conteneur docker. Notons que plusieurs dockers peuvent être installés dans une même machine virtuelle, ce qui permet aux équipes IT de maîtriser les ressources et les montées en charge lors de l’utilisation de DSS. Les figures suivantes présentes respectivement l’infrastructure globale du PoH côté Analytics, les scripts de création des dockers, et le contenu détaillé de chaque docker.

Pour information, si l’entreprise dispose d’un cluster Hadoop, alors le Data scientist pourra choisir par DSS de transférer la charge de calcul de certaines opérations vers le cluster. Dans ce cas de figure, le cluster gérera la répartition des charges des opérations et la gestion des ressources via son NameNode. Cela peut être bénéfique pour l’entreprise, car elle pourra consacrer moins de ressources financières à l’acquisition du serveur sur lequel doit tourner DSS ; de plus, dans ce scénario, les données étant  nécessairement stockées sur du HDFS, les opérations d’I/O (input/Output) sur le réseau seront faibles, réduisant ainsi tout risque de goulot d’étranglement.

11) Retour d’expérience sur l’utilisation de Dataiku

Dans cette partie, nous allons présenter les forces et les faiblesses que nous avons perçues de Dataiku lors de l’utilisation dans le projet.

Le schéma ci-dessous synthétise les différentes phases du projet en soulignant les gains apportés par Dataiku (dernière ligne). Avec Dataiku, le Data scientist peut se focaliser très rapidement sur les aspects fonctionnels du projet. La figure suivante montre le flux global de notre travail de développement de modèle de scoring de coupon.

Commentons ce schéma un instant. Au début du projet, nous avons commencé par une collecte de données de Twitter, DSS fournit une interface pour extraire les tweets en mode REST. Par la suite, nous avons utilisé Python pour faire du Web Scrapping des coupons de deux sites d’ecommerce. Les données de coupons ont été transférées dans une base MySQL, et par DSS nous avons pu les annoter, faire des transformations de données et développer des modèles statistiques de classification de ces coupons selon des centres d’intérêts fixés à l’avance.

Les opérations de jointure se sont effectués sur MySQL, le graphique exprime également le fait que les travaux de préparation de données peuvent être également transférées sur du Hadoop ou sur du Spark.  En ce qui concerne la modélisation statistique, DSS nous a permis par ses interfaces de développer des modèles statistiques sans une ligne de code. Cet avantage nous a fait gagner énormément de temps dans la phase de modélisation. Après le développement de ce modèle, nous avons utilisé du Python embarqué dans DSS pour développer le modèle de calcul des distances entre le modèle expert et celui des coupons.

C’est ce modèle qui sert plus tard de CPI et qui est déployé dans l’API Node. En termes de temps, 3 semaines nous ont été nécessaires pour la phase de collecte et de transformation de données, et le reste du temps du projet, nous l’avons consacré à l’élaboration du modèle de scoring des coupons. Nous n’aurions pas obtenu le modèle de scoring de coupons actuel si nous n’avions pas Dataiku, car nous aurions passé trop de temps dans les tâches de développement. Les interfaces graphiques fournies par DSS nous ont véritablement permis de nous concentrer sur l’essentiel.

11.1) Les avantages du logiciel dans le projet

Le retour d’expérience que nous avons sur Dataiku (en tant que Data Scientist et développeur) est globalement très positif. Les avantages de l’outil pour nous  ont été les suivants :

Interface propre et facile d’accès

DSS offre une interface graphique de travail très confortable. La visualisation à tout moment du workflow permet de toujours avoir une vision d’ensemble d’un projet. Les modules proposés (chargement des données, modélisation, export des données, …) sont très facilement mobilisables. Le coût d’entrée dans un projet est ainsi fortement réduit. La montée en compétence et la prise en main de DSS ne nécessite pas d’effort particulier.

La simplification des opérations de préparation de données

La phase de préparation des données est une phase souvent sous-estimée : elle nécessite beaucoup de temps et elle est difficilement valorisable. Il s’agit pourtant d’une étape indispensable à tout projet de Data Science. Certains logiciels comme Trifacta se sont spécialisés uniquement dans cette tâche. D’ailleurs, un article du Times estime que 50% à 80% du temps de travail d’un data scientist est dédié à cette phase. DSS offre un grand nombre d’opérations de gestion et de nettoyages de données. Leur mobilisation est très simple, tout passe par une interface graphique. Dans le cadre du Projet, nous avons passé deux semaines sur cette tâche contre 3 sans outil spécifique. Parmi les traitements que nous avons utilisés, on peut citer :

• la normalisation du texte : suppression des majuscules, des accents, passage en Unicode,
• la suppression des Stop-Words français : par exemple « un », « des », « la », …,
• la réalisation d’un TF-IDF pour faire ressortir les mots vraiment significatifs des coupons.

Intégration de l’open source

L’outil est bien intégré aux langages open-source (Python dans notre cas), ce qui nous a permis d’implémenter des modèles statistiques personnalisés. Le langage Python intégré est le langage original. Une compétence en Python est donc un avantage pour utiliser  toutes les fonctionnalités offertes par l’outil. De plus, on a accès à la librairie de machine Learning Scikit-Learn qui est aujourd’hui la référence dans les travaux de modélisation statistique. Dans le PoH, Python nous a servi pour :

• Importer/exporter des données au travers de DPI,
• créer des triggers custom. Par exemple, au bout de 20 nouveaux coupons annotés manuellement les modèles sont recalibrés.
• Créer le modèle expert permettant de convertir les adjectifs qualificatifs de l’artefact en centres d’intérêts. Par exemple la personne est décrite comme étant « Bouquineuse » alors elle aura note élevée en « Lecture ».
• Calculer la distance entre les coupons et les artefacts (clients)

Réversibilité (Reverse Engineering) du workflow au code

Dataiku donne la possibilité d’importer en local tout le workflow du projet en code Python. Ce code contient toutes les étapes qui ont été réalisées en code Python. Cet avantage permet d’une part de ne pas bloquer les projets dans l’application (faire dépendre les projets de Dataiku), et d’autre part de les exporter pour réutilisation. Dataiku utilise certaines librairies « propriétaires » mais très rapidement il est possible de revenir à une version 100% open-source. Nous avons entre autres utiliser cette fonctionnalité pour faire des tests de performances en local des différents modèles.

Connectivité et Scalabilité

Dataiku s’intègre avec les plateformes Hadoop, Spark, TEZ et IMPALA pour le traitement distribué. Cet avantage permet de transférer certaines opérations de préparation de données et certains algorithmes de Machine Learning de Dataiku vers des clusters. Par ailleurs, plusieurs langages sont fournis par Dataiku pour manipuler ces plateformes : PySPark, Spark R, Pig et Hive. Le tableau suivant présente l’ensemble des plateformes et de langages auxquels DSS s’intègre pour le traitement distribué. DSS est intégré avec quasiment l’intégralité des plateformes Open source du moment.

Mise en production des modèles

Il existe deux types de mises en production : celles de l’API Node (ou Scoring Node) et l’Automation Node. L’API Node permet de mettre un modèle en production en temps réel (en tout cas avec une latence inférieure à la seconde), tandis que l’Automation Node permet de mettre en production un modèle en mode batch, dans un intervalle de temps déterminé.  Dans le cadre du projet, nous utilisons d’une part l’Automation Node pour le scoring des coupons, c’est-à-dire pour la transformation du contenu textuel des coupons en centre d’intérêts ; ceci est fait automatiquement tout les jours à minuit. D’autre part, nous utilisons l’API Node pour renvoyer en temps réel les 3 meilleurs coupns à l’application mobile qui en fait la demande.

Pour mettre en production l’API Node, nous sommes passés par l’Exploration Node. Dans celui-ci il  est possible de tester le bon fonctionnement de notre code puis de créer un package (dossier zip) qu’il faut ensuite exporter sur le serveur. Des lignes de commande bash en Linux sont nécessaires pour cela, il n’y a pas d’interface graphique. Pour mettre en production l’Automation Node, il faut également passer par l’Exploration Node en créant un Bundle. Il s’agit d’un export global de tout le workFlow. Dès lors, depuis une interface graphique il est possible d’importer le projet pour le retravailler.

Pour résumer, le déploiement des modèles est plutôt simple relativement par rapport aux autres solutions. Un data scientist peut mettre en production son modèle sans intervention majeur du service informatique.

Environnement collaboratif

DSS permet à plusieurs utilisateurs de travailler simultanément sur le même projet. Cette fonctionnalité permet de travailler en parallèle sur des tâches différentes. Dès qu’une procédure est lancée, un pop-up alerte tous les utilisateurs connectés. Ainsi, il est possible de s’assurer que des travaux potentiellement impactant ne sont pas en cours.
Il est également possible d’avoir accès à tous les « jobs » réalisés ainsi que leur initiateur. Le collaboratif dans DSS accroît la productivité et l’efficacité de l’équipe des Data Scientists.

La réactivité et proximité du support

Dans le cadre du projet, Dataiku a tenu à nous faire bénéficier de leur dernière solution. Nous avons donc travaillé sur la version 3.0.1 de l’outil et avant cela avec une version Beta 3.0.

Nous avons par exemple rencontré un souci lors de la mise en production du CPI : le niveau de log était insuffisant pour identifier l’origine du problème. Le lendemain nous rencontrions l’équipe technique de Dataiku (Paris 9ieme) pour débloquer cette situation.

Par ailleurs, à chaque fois que nous avons eu une question, dans la journée nous avions une réponse avec un système de ticket. Les équipes de Dataiku ont été très réactives tout au long du projet.

!!! Mises en garde par rapport à l’utilisation de Dataiku

Malgré les nombreux avantages que présente DSS, Nous tenons à attirer votre attention sur certains points. Ces points ne sont pas des manquements dans DSS, mais plutôt des facteurs non-liés à l’outil qu’il vous faudra nécessairement prendre en compte lors de l’utilisation de l’outil dans un projet. Ces facteurs sont au nombre de 3:

•  Bien que DSS simplifie les opérations de construction de modèles et de modélisation statistique, des compétences multiples sont nécessaires pour l’exploiter au maximum de son potentiel (développement open source, développement en Python, R, Impala, architecture technique, mode de fonctionnement d’un cluster, Machine Learning). Plus précisément, des compétences sur le fonctionnement de l’écosystème Hadoop sont nécessaires pour savoir prendre des décisions lors du transfert du calcul de DSS à Hadoop ou à Spark. De même, des compétences poussées sont nécessaires pour pouvoir exploiter tous les outils Open Source (Python, R) auxquels sont intégrés DSS.

• Les applications développées dans DSS dépendent étroitement des versions des outils de l’écosystème Hadoop installés dans votre SI. Si vous avez développé une application qui exploite du Spark V2.2 par exemple, et que vous veniez à mettre à jour votre Spark à V3.0, il se peut que vous soyez emmener à redévelopper votre application Dataiku. De même, certaines librairies Python évoluent. il y a donc des méthodes utilisées lors de l’écriture d’un code Python Custom qui deviendraient « Deprecated ». Ce problème de la dépendance à l’évolution de l’open source est propre à la stratégie de l’intégration horizontale à laquelle a optée Dataiku.

• Dans le cadre d’un projet Dataiku avec diverses sources d’informations par exemple et plusieurs applications (API Node, Automation Node, Exploratoire), l’intégration de plusieurs écosystèmes peut créer des risques d’incompatibilités. Pour remédier à ce souci, nous vous recommandons d’installer DSS dans un environnement dédié, cela peut être une machine virtuelle, un  serveur physique, une ou plusieurs images dockers, mais du moment où c’est dédié.

11.2) Les Faiblesses de Dataiku

Dataiku est un outil qui continue d’évoluer à mesure de l’accroissement de la demande des clients et des avancées technologiques. Vous trouverez ci-dessous une liste des principaux éléments qui nous ont manqués dans le cadre du projet. Encore une fois, l’outil évolue, donc il est possible qu’après la publication de cette chronique, que certaines limitations que nous avons citées aient été corrigées.

Manque du « Featuring Selection »

DSS ne fournit pas d’algorithmes et de méthodes de sélection automatique des variables pour la construction des modèles.  Dans le cas du projet, ce défaut n’a pas été gênant car nous n’avons travaillé qu’avec deux variables : titre et description des coupons. En revanche, s’il faut utiliser DSS dans d’autres chantiers de data science dans lesquels on est confronté à faire le choix entre des centaines, voir des milliers de variables, on devient très vite handicapé.  

A défaut de ce manque, DSS n’offre pas de méthodes d’exploration automatique qui fourniraient des indices quant aux variables qui pourraient être utilisés dans le modèle. Ceci est un véritable handicap dans le travail du Data scientist. Juste à titre de précision, le « featuring selection » en Data Science désigne le processus par lequel des variables sont sélectionnées dans un ensemble de variables pour être intégrées dans un modèle de Machine Learning sous la base de leur significativité. Ce processus est le plus souvent automatisé, ce qui permet aux data scientists de retenir et de focaliser leur attention sur quelques variables parmi une dizaine voir une centaine de variables. On distingue 3 techniques de sélection de variables : le Stepwise Elimination Process, le Backward Elimination Process et le Forward Elimination Process.  Aucune de ces 3 techniques n’est intégrée dans DSS.

Dans le même sens, une autre limite rencontrée avec DSS est le rejet par défaut des colonnes de type ‘Texte’ comme variable explicative. Il faut donc sélectionner manuellement les variables textuelles.

Monitoring des performances système

DSS ne fournit pas d’outils qui permettent de suivre ou de tracer les ressources informatiques utilisées par les travaux du workflow. En d’autres termes, on est incapable de savoir concrètement combien chaque opération du workflow, chaque modèle utilise de mémoire RAM, de fréquence de processeur, d’opération de disque I/O,….

Ces informations sont importantes pour le service informatique car ils fournissent une visibilité sur l’impact qu’ont les algorithmes de Data science sur le fonctionnement général du système informatique. Ils fournissent des pistes de calibrage des ressources à consacrer aux environnements informatiques de Data science.

Pour le Data Scientist, le monitoring de performance système lui permet d’optimiser/redévelopper son code de manière à minimiser l’utilisation des ressources, ou alors à abandonner l’approche/l’algorithme sélectionné au profit d’un(e) autre algorithme/approche.

Dans le projet, pour contourner cette difficulté nous avons utilisé des librairies psutil et Memory_profiler dans nos scripts personnalisés, mais ils sont loin d’être suffisants. D’autres  solutions de type NewRelic ou Ganglia seront également testées.

Absence de toutes les librairies de MLlib

Dataiku s’intègre à Spark, cependant, tous les algorithmes de Machine Learning disponible dans le framework de calcul MLLib ne sont pas présents. Uniquement 4 sont intégrés et pris en charge par Dataiku pour l’instant, dont 3 pour la classification supervisée et 1 pour la classification non-supervisée. Certes il s’agit des approches les plus communes mais ce manquement pourrait être limitant dans certains cas où ces algorithmes ne suffisent pas. Dans le cadre de projets plus vaste que celui dans lequel nous avons travaillé, on peut imaginer que les ressources informatiques (RAM, CPU et disque I/O) soient fortement sollicitées. L’intégration de ces algorithmes sur Spark via la librairie MLib permettrait de distribuer ces algorithmes sur le cluster et de profiter de leur scalabilité.

Versioning des modèles

Les modèles statistiques qui sont développés à l’intérieur d’un projet DSS ne peuvent pas être enregistrés en plusieurs différentes versions. Ceci est un  problème dans un environnement collaboratif dans lequel plusieurs utilisateurs modifient le même modèle à la fois, comme ça a été le cas dans le projet. Par exemple, dans le projet, nous avons développé un modèle personnalisé en Python ; mais la collaboration sans capacité de créer des versions du projet a rendu le suivi du développement du modèle difficile. Sans versioning il était impossible de suivre l’évolution du code python du modèle. Pour contourner ce problème, nous avons du enregistrer plusieurs copies du même projet.

Non-agilité du Processus d’industrialisation des modèles

Bien que la mise en production du modèle soit relativement simple et puisse être prise en main directement par le Data scientist sans assistance du service informatique, il est important de mentionner que le processus reste très manuel. A chaque fois qu’il faut mettre en production un modèle, il faut le télécharger de l’Exploration Node, le charger en environnement de production et par des commandes bash saisies par l’utilisateur, et le déployer sur le serveur.

Sélection automatique de modèle sur la base des critères de performance

Un autre problème que nous avons rencontré avec Dataiku est la sélection de modèle. Nous souhaitions automatiser le choix des modèles parmi une liste définie par le Data Scientist en fonction d’une métrique également définie par le Data Scientist. Par exemple, lorsque nos modèles thématiques sont en production, le training est relancé tous les jours à minuit. Il est aujourd’hui très long et fastidieux de créer une procédure de sélection automatique des modèles avec les nouvelles données pour chacun des centres d’intérêt.

En conséquence, l’utilisateur est obligé de passer en revue tous les modèles proposés par DSS et les comparer lui-même selon le critère de performance qu’il a choisi. Nous nous doutons bien que ce choix est intentionnel de la part de Dataiku, mais le travail du Data scientist n’en n’ai pas moins facilité.

Pauvreté de la librairie de visualisation des données

Dataiku intègre dans DSS des graphiques plutôt basiques, plus destinés à une exploration statistique de données qu’à un reporting. Et encore, en matière de graphique d’exploration statistique de données, nous n’avons pas pu utiliser d’histogramme, qui est quand même l’un des graphiques de base en matière d’exploration statistique. Le produit a répondu à ce besoin de data visualisation en rajoutant des bibliothèques Java script D3J (Data Driven Document) qui permettent aux utilisateurs de développer eux-mêmes leurs propres graphiques sous forme de services. Cependant, l’utilisation de cette bibliothèque demande des compétences en développement Java Script et en D3J. Du coup, pour faire de la Data Visualisation, le Data Scientist doit utiliser un outil externe. A titre d’information, Dataiku fournit un connecteur qui permet de connecter DSS à Tableau.

Gestion des droits des utilisateurs (permissions d’accès à des modèles)

Nous avons constaté un problème avec les fonctionnalités collaboratives de Dataiku. En effet, les utilisateurs de Dataiku ont tous les droits sur les modèles qui sont développés. Dans le cadre du projet, nous aurions souhaité limiter la modification et même la visibilité d’une partie des modèles à certains utilisateurs, malheureusement, c’est chose impossible pour le moment.

Manque des outils de débogage du code Python

Afin de débugger le code Custom Python dans Dataiku, un mode spécifique aurait été apprécié. La possibilité de mettre des points d’arrêts ou des variables de transition permettraient de faciliter le développement des modèles personnalisés en Python. Aujourd’hui nous passons par des opérations  de « Print » qui ne sont pas satisfaisantes.

Promotion d’un seul output

Lors du développement du modèle de promotion de coupon dans le projet, nous avons rencontré une difficulté, celle de l’incapacité de pousser plusieurs coupons. En effet, Dataiku ne renvoie qu’un seul output dans l’API Node ; donc un coupon dans notre cas. Ceci est une limite, car nous renvoyons les 3 meilleurs coupons. Pour contourner ce problème, nous avons dû concaténer les résultats du modèle. Après, nous pensons que ce problème était spécifique à notre projet, et non pas une limite à proprement parlé de l’outil.

TABLEAU RECAPITULATIF DE L’ANALYSE DES FORCES/FAIBLESSES DE DATAIKU

Ce  tableau présente une évaluation synthétique des forces et faiblesses que nous avons rencontrées avec Dataiku lors De l’utilisation dans le projet.

Nous sommes arrivés au terme de ce livre Blanc sur le Self-Service Big Data avec Dataiku. En guise de conclusion, ous pouvons dire que Dataiku est un produit dont l’intégration Horizontale à l’écosystème des technologies Hadoop et à l’open source offre une grande flexibilité dans le travail du Data Scientist. De plus, l’approche Self-service sur laquelle il est basé rend le produit accessible aux Data Analysts. C’est cette flexibilité et ce  qui nous a permis de valider toutes les hypothèses que qui ont été posées au début du projet. Nous espérons que ce livre blanc vous aiguisera dans votre décision d’utiliser ou pas un outil de Self-Service dans votre projet Big Data.