kiss my frogs
Contribuer
Twitter Facebook LinkedIn RSS
[ Rechercher ]
Accueil Contribuer TwitterTwitter FacebookFacebook LinkedInLinkedIn RSSRSS

“IA”, “Machine Learning”, “Data Science”… : si la mode était au Big Data il y a quelques années, les buzzwords du moment démontrent qu’au delà de la collecte de données, l’enjeu majeur aujourd’hui c’est leur analyse et leur interprétation – bref, qu’elles servent à quelque chose ! Alors qu’une majorité d’entreprises, historiquement centrées sur leur référentiel métier, commencent tout juste à collecter les logs, les informations de contexte et autres signaux faibles, d’autres ont détecté ce nouveau besoin en amont et en ont fait un produit ! C’est ce que propose Dataiku avec sa solution DSS.

Voici l’entretien de Clément Stenac, CTO de cette startup exemplaire qui a su prédire où – et surtout comment – nous mène cette aventure du Big Data…

Par choix, les anglicismes, termes techniques et raccourcis de vocabulaire sont laissés tels quels – incontournables dans n’importe quelle discussion technique un peu réaliste 🙂

Clément, qui es-tu ? D’où viens-tu ?

Je suis Clément Stenac, co-fondateur et CTO de Dataiku (110 employés dont 75 en France).  Avant de fonder Dataiku j’ai travaillé pendant 6 ans chez Exalead qui édite un moteur de recherche. J’ai commencé en tant que dev, puis j’ai évolué : lead dev, architecte et finalement responsable du produit à la R&D. J’étais déjà très tourné backend sur des sujets data, big data et je me suis rapidement intéressé aux problématiques de scalabilité. A l’époque on parlait peu de l’interprétation des données et beaucoup plus des aspects stockage, accès, retrieval.

Sur quelles technos travaillais-tu et comment t’es-tu formé ?

J’ai fait une école d’ingénieur : Centrale avec l’option informatique. Dans les faits j’ai été plutôt autodidacte : je contribuais au projet opensource VLC media player : à l’origine c’est un projet issu de l’école Centrale. Chez Exalead j’ai fait du développement bas niveau en C, C++ ainsi qu’un langage propriétaire qui s’appelait ExaScript.  Quand Java a été prêt pour traiter du big data on a tout converti.

A l’été 2012 j’ai senti que c’était la fin d’un cycle : on venait de refactorer le produit et l’ambiance n’était plus vraiment celle d’une startup suite à notre rachat par Dassault Systèmes. J’ai repris contact avec Florian qui était directeur de la R&D chez Exalead : depuis plusieurs mois l’idée de Dataiku lui trottait dans la tête.

Quel était le produit, le concept, de Dataiku ?

Après Exalead, Florian travaillait chez Criteo et IsCool: son constat était que tous les outils pour faire de l’analyse de données existaient en open-source, mais les brancher tous ensemble c’est compliqué et cela nécessite beaucoup de travail de plomberie.

On dit que les étapes de préparation de données prennent 80% du temps alors que l’exploitation, l’analyse des choses « intelligentes » ne représentent que 10% à 20% du temps. Et puis toutes ces technos ne sont utilisables que par des sociétés très avancées techniquement. Pour des sociétés comme Criteo, la data est leur coeur de métier. Ils vont donc avoir des data engineers, des data scientists en nombre qui vont pouvoir monter ces pipelines de données de manière très réaliste. Mais une société dont ce n’est pas le métier premier : un retailer de taille moyenne, une utility ou un grand compte quel qu’il soit, ne pourra pas aussi facilement tout inventer et tout créer from scratch, il leur faudra des outils.

Peux-tu citer quelques technos dont Dataiku facilite l’intégration et l’usage ?

Déjà il y la connexion aux sources de données, bases de données SQL, noSQL. Ensuite les technologies de stockage et de calcul plus liées au big data : Hadoop puis Spark qui n’existait pas quand on a démarré. Et aussi les langages de programmation : python, R, Scala. La capacité de faire des applications web de visualisation sans avoir à monter des serveurs, des load balancers.

En bref : simplifier et pré-intégrer toutes les étapes d’un projet de traitement des données.

Aujourd’hui dans l’éco-système autour d’Hadoop et Spark il existe déjà beaucoup d’outils et de services pré-packagés : où mettez-vous le curseur ? Où se situe réellement votre valeur ajoutée ? Tu parles de la préparation des données ? Quel type d’outils proposez-vous ?

Les 3 valeurs fondamentales sont :

  • End-to-end : couvrir l’intégralité du cycle de développement de données : l’acquisition, la préparation, l’ETL (groupage, filtrage, jointures), les phases plus en aval comme le Machine Learning (ML) ou la data visualisation… Tout ce projet qui aura été développé avec Dataiku pourra être mis en production, on pourra y créer des chaînes de validation de données, avoir une logique d’intégration continue.
  • La collaboration : pouvoir travailler à plusieurs, simultanément, sur un projet. On adresse les problématiques de contrôle d’accès, de versionning, pouvoir revenir en arrière, éviter les conflits. On a aussi une API hautement disponible et scalable assez vaste qui permet de réaliser des tâches d’administration (création user, projet), et d’automatiser un certain nombre de choses comme démarrer des workflow automatiquement, surveiller des sources de données. Par exemple un référentiel renseigné et modifié par le marketing permettrait de déclencher tout le pipeline de traitement. Il peut également être contrôlé par le scheduler d’entreprise.
  • Code or Click : Hadoop permet effectivement d’intégrer les composants entre-eux, mais ça reste destiné aux développeurs. Pour un data analyst c’est quasi impossible d’utiliser Hadoop directement : il faut ajouter une couche d’abstraction et des outils au-dessus des briques techniques. Avec Dataiku on s’adresse à différents types de profils. Le dev pourra coder dans un environnement de très haute qualité (versionnement, traçabilité du code) : on voit souvent des projets où les data scientists ont des dizaines de scripts un peu dans tous les sens : dans notre solution tout est rationalisé. Les profils non-dev pourront travailler sans avoir à coder ou au moins sans avoir la complexité du setup pour faire tout cela. Cela leur libère du temps pour se consacrer au machine learning, au traitement avancé. On peut créer des briques réutilisables mises à disposition des data analysts qui ont la connaissance métier et qui sont souvent plus nombreux.

Quand tu parles de data analyst et data scientist, dans ta tête ça parait très clair ! Quelle est la différence ? Où commence et où s’arrête chacun des rôles ?

La distinction est spécifique à chaque client : c’est plutôt un spectre de rôles…

Le data scientist aura les aspects ML, algo, math, statistiques plus développés : c’est celui qui code.

Le data engineer va plutôt s’occuper de problématiques système et infrastructure : il va faire tourner les data pipelines.

Le data analyst détient la connaissance métier et préfèrera utiliser des outils visuels.

On a aussi le data team leader : c’est souvent lui qui achète notre solution. Il a une équipe dont il aimerait améliorer la productivité. Je pense notamment à la gouvernance et la traçabilité, s’assurer que les données sont bien sauvegardées et que les accès sont centralisés pour éviter la fuite des données : une problématique typiquement GDPR.

Les data scientists sont très courtisés : il y a pas mal de turn over chez eux. Notre solution repousse un peu la limite entre le data analyst et le data scientist en permettant au premier d’aller plus loin dans la chaine sans être obligé de coder.

Vous partez de l’acquisition de la donnée : proposez-vous des solutions simplifiées pour l’acquisition de celle-ci ?

On ne fait pas encore d’intégration de données en amont mais on y pense notamment sur le traitement de la donnée en temps-réel. A ce jour, on va plutôt se brancher sur un datalake.

Comment fonctionne votre solution concrètement ? Est-ce de la génération de code/script & co ? Est-ce que l’on peut « débrayer » l’usage de votre solution a posteriori ?

Dataiku c’est un runtime : notre moteur tourne en prod. On a un système de recalcul incrémental des données pour ne pas recalculer chaque jour les 3 ans de données historique mais si quelque part dans la chaîne il y a une source de données ou un traitement qui est modifié, on va calculer l’impact et ce qui doit être recalculé pour chaque jour. On a cet aspect data lineage qui donne une forte garantie aux utilisateurs que la donnée a été calculée selon le bon traitement et que ce n’est pas une donnée obsolète qui ne serait pas nettoyée de la bonne façon.

Les évolutions de schéma dans le big data, c’est très compliqué à gérer : comment vous en sortez-vous ?

L’évolution des formats de données c’est pas magique : les utilisateurs vont faire plusieurs branches dans un flux et les rejoindre avec des règles de dispatch : les données d’avant passent sur un chemin et les données d’après sur un autre par exemple. L’univers Hadoop est très schema-full : on va plutôt normaliser en amont du flux.

Si on veut faire du traitement efficace il faut être sur des formats de stockage binaires ou orientés colonne, donc avec un schéma.

Si on prend l’exemple de la détection de fraude : est-ce que votre solution sait automatiquement comparer différents modèles mathématiques pour conserver celui qui permet d’obtenir le meilleur résultat ? Ou c’est l’utilisateur qui va choisir telle forêt, telle régression…

On est sur du ML guidé plutôt qu’une boîte noire : notre solution va évaluer différents algos ou jeux de paramètres et va présenter des propositions à l’utilisateur. Pour cet algo de random forest, on conseille tels params p.ex.

La problématique est plutôt l’explicabilité que la performance brute : certains sont très performants mais on ne sait pas expliquer comment ils marchent.

Ca crée des problèmes de confiance dans l’algo lui-même et surtout ça commence à poser des problèmes légaux : la GDPR commence à approcher ces sujets.

Il faut pouvoir expliquer des décisions algorithmiques  et donc il y a un choix de certains clients de ne pas déployer le modèle le plus performant mais celui qui offre un bon compromis entre la performance et le niveau d’explicabilité.

C’est un sujet de recherche très intéressant : il y a des types d’algo qui sont en cours de recherche qui permettent d’expliquer des prédictions même sur des algos black box : ces recherches sont encore assez jeunes mais prometteuses. Les algorithmes performants sont souvent aussi de gros consommateurs de ressources au moment du scoring. Donc il y a une vraie décision métier pour le choix final de l’algo.

D’où proviennent les algos et modèles de machine learning que vous proposez ?

Notre moteur de ML s’appuie sur 5 librairies dont 4 sont open-source: scikit-learn (python), xgboost (python), MLlib (Spark), H2O (Spark), le ML intégré à Vertica. On travaille à ajouter d’autres moteurs intégrés à des bases de données. Certains algos comme le clustering  ont aussi été développés maison car on voulait proposer une expérience interactive très spécifique.

Tu parles de services scalables et hautement disponibles : avez-vous une solution SaaS ?

On est un éditeur un peu old-school par-rapport aux standards d’aujourd’hui : notre solution s’installe chez le client et peut donc être on-premises ou installée dans le cloud. C’est un logiciel que les utilisateurs téléchargent et installent dans leur infrastructure : pour beaucoup c’est le cloud mais pour une bonne majorité c’est encore leur datacenter : c’est presque du 50%-50%.

Dans quelle mesure peux-tu garantir une haute disponibilité dans ce contexte où vous n’avez pas le contrôle de l’infrastructure sous-jacente ?

C’est pas magique ! C’est au client de déployer plusieurs instances et c’est ce que permet notre solution qui supporte le scale-out et l’ajout de nouveaux nœuds. Nous sommes une startup et convaincre nos clients de nous confier l’hébergement de leurs données reste compliqué, surtout que notre stratégie commerciale est axée sur les grands comptes, y compris à l’international.

Il y a d’ailleurs des problématiques techniques sous-jacentes ! Par-exemple pour faire le traitement au plus près de la data le SaaS ne serait pas une bonne solution pour nous. Par contre dans le cloud ça marche totalement et on s’intègre d’ailleurs avec AWS, Microsoft Azure et GCP via leurs solutions Hadoop managées. Cela permet aux clients qui sont dans le Cloud de démarrer encore plus facilement.

Si je prends l’exemple de Microsoft d’Azure et sa solution Hadoop/Spark managée HDInsight : comment fait-on pour utiliser la solution Dataiku ?

C’est un cas unique : l’offre managée Hadoop sur Azure propose directement la solution Dataiku installée et prête à l’emploi dans le cluster. En fait c’est une simple option à cocher lorsque l’on provisionne le cluster HDInsight sur le portail. Dataiku est référencé et validé par Microsoft comme une solution compatible avec HDInsight et l’intégration se fait automatiquement.

Sur quels noeuds du cluster Hadoop/Spark la solution sera-t-elle déployée ?

La solution s’installe sur un edge node – donc pas un nœud de « travail » – et chaque job envoie le traitement à faire, sur le cluster et ses nœuds de calcul. On peut reprocher beaucoup de choses à Hadoop mais une des grandes forces du composant yarn c’est de pouvoir déployer du traitement sans rien avoir de spécifique à installer sur les nœuds eux-même.

Comment avez-vous architecturé et implémenté votre solution ?

Notre challenge principal est qu’on n’est pas en SaaS : ça entraîne beaucoup d’inconvénients : notamment l’évolutivité, le contrôle et la diversité.

La diversité c’est la plus grosse difficulté : on s’intègre avec 5 distributions hadoop différentes,  une quinzaine de bases de données et 4 distributions linux ! Il y a une grande variabilité au sein de tout cela. Hadoop évolue très vite et souvent la peinture n’est pas tout à fait sèche. Hadoop contient beaucoup de composants assez épars qui sont édités par des équipes différentes de sociétés différentes qui sont parfois en compétition entre elles. Chaque distri fait ses choix, patche différents bugs, … parfois les versions ne sont pas les mêmes suite à un repatch. Quand on arrive chez nos clients, Hadoop est un peu comme un gigantesque panneau de contrôle d’avion et on ne sait pas trop quels boutons ont été touchés.

Cela nécessite de travailler et tester sur un nombre impressionnant d’environnements de développement différents. Nos développeurs peuvent facilement provisionner à la demande un environnement tel ou tel, ce dont on est assez fiers. On est basé sur des conteneurs, des machines virtuelles et du cloud. On n’héberge pas de prod mais beaucoup d’infra de test qui se fait chez OVH et Online. Pour les workloads pour lesquels on a besoin de plus de flexibilité on est sur le cloud Microsoft Azure et AWS. Il n’y a pas de choix rationnel fort pour notre hébergement : historiquement on était surtout chez AWS mais on fait de plus en plus d’Azure, notamment pour nos besoins lors des formations. En effet les élèves lancent tous leurs exercices et leurs traitement au même moment ce qui entraîne des pics de consommation : il faut beaucoup plus d’élasticité que pour nos propres besoins !

Parmi vos clients, quelle proportion connait déjà Hadoop ?

Il y a une grande différence entre les marchés français et américains : aux Etats-Unis, 100% de nos clients connaissent Hadoop.

En France il y a 2 ou 3 ans, les gens découvraient à peine le big data et expérimentaient tout juste Hadoop : on faisait beaucoup de préconisation d’architecture. On est arrivé un peu plus tard aux Etats-Unis mais l’approche reste différente : là bas ils nous exposent leur existant et veulent savoir s’il est supporté ou non. En France on travaille encore beaucoup sur la donnée métier et comment la valoriser à partir de quelques use cases.

Quelles technologies utilisez-vous ?

On reste guidés par cette contrainte de déploiement chez le client : il faut que ce soit le plus simple possible et que le client puisse redémarrer la solution facilement en cas de problème.

Notre architecture est multi-process mais assez monolithique au sens « self-contained ». En effet la solution embarque tout ce dont elle a  besoin y compris les DB qui sont du Sqlite et H2. On code principalement en Java qui est un des langages phare du big data et que l’on considère être un bon compromis entre performance et productivité. On n’aurait jamais voulu avoir notre cœur écrit en python ou en ruby par exemple ! Dans le backend on va trouver un serveur web qui fait le scheduling des jobs, tout le stockage et la gestion des métadonnées et leur indexation pour le search. On a aussi quelques process python et R ainsi que les process Spark évidemment. Côté front on a une SPA : une grosse Single Page Web App en angular.js.

Comment faites-vous la communication inter-process ?

Pour l’instant c’est du synchrone avec des API http mais avec une sur-couche à base de polling qui permet de l’utiliser en asynchrone. On réfléchit à passer sur un bus de messages mais ça suppose de l’embarquer ce qui n’est pas simple car il faut gérer toute la chaîne autour et le sécuriser.

Pour nous, ajouter une techno dans la stack c’est toujours un trade-off entre ce que ça va nous faire gagner versus ce que cela risque d’engendrer comme problèmes.

Cela nous amène au 2è gros challenge lié à l’hébergement chez le client : que se passe-t-il quand ça ne fonctionne pas ?

On ne peut pas se connecter sur la machine pour aller voir les logs comme cela serait le cas dans une solution SaaS : donc on a développé beaucoup d’outils de diagnostic et de safety check. On a un gros bouton « generate report » dans l’UI qui permet de générer un  zip avec toutes les infos de contexte qui nous servent à comprendre ce qui s’est passé et quel bug ça a triggé ou quel bouton bizarre le client a touché dans son Hadoop !

Souvent le client qui a installé notre solution n’est pas celui qui utilise Hadoop donc ça peut être compliqué de faire le diagnostic.

Semi-automatiser le débug a été un gros investissement de développement de notre part.

Quels outils utilisez-vous pour l’industrialisation ?

Comme outil d’intégration on utilise Jenkins. Pour les tests (à part les tests unitaires spécifiques à chaque langage) on fait du python et aussi du  Selenium pour les tests UI. On utilise Sonar pour la qualité de code ainsi que Github pour le contrôleur de sources & les issues.

C’est assez classique en fait.

Quelle est la répartition des profils techniques parmi vos employés ?

Dataiku regroupe 110 employés dont 70 en France, le reste aux US et UK et 1 personne à Singapour. L’équipe tech comprend 20 personnes : 10 Dev, 2 QA, PM, UX/UI et devops. C’est une équipe plutôt restreinte ! Le gros des équipes de dataiku c’est les équipes commercial et delivery avec du pre-sales très technique. C’est notre dept data science qui s’en occupe et qui construit les contenus d’enboarding & enablement, ainsi que les training et le delivery chez le client.

On est dans une logique d’éditeur et pas de conseil mais on fait de l’enboarding & de l’expertise.

Qui décide de l’évolution du produit ?  La roadmap ?

On a une équipe Product Management et la décision se prend conjointement entre les PM et moi.

On est essentiellement drivé par les remontées clients. La solution se vend par abonnement et donc il faut assurer le renew.

On est en train de monter en puissance notre équipe Customer Success qui va chez le client pour avoir des retours qui seront aussi bien de l’ordre de la feature stratégique que des boutons mal placés car c’est parfois les petites frustrations qui peuvent bloquer l’adoption. Le cas idéal c’est ceux qui ont déjà essayé de faire eux-même sans succès et qui réalisent à quel point notre solution les aide.

Evidemment on fait aussi beaucoup de veille pour devancer l’adoption de nos clients. Je peux citer un exemple avec Apache Kudu qui est en train de monter en puissance et que l’on va intégrer bientôt.

La dernière techno que tu as kiffé ?

Je râle plutôt sur les technos en général ! Mais je dirais Spark quand même…ça montre encore sa jeunesse mais ça change la donne. Cela permet de faire des flows de données performants et versatiles de manière efficace. Au début on avait juste MapReduce : pas très performant, verbeux et difficile à écrire. Ensuite on a eu les technos de Sql over Hadoop : Hive, Impala, Pig qui apportaient la simplicité avec SQL mais la perf restait moyenne et surtout on reste cloisonné. Puis avec Tez et Impala on a amélioré les performances mais du coup plus c’était performant moins je pouvais faire de choses. Exemple : Hive versus Impala : avec Impala les performances sont excellentes mais on ne peut faire que des choses standard.

Avec Spark (notamment 1.4) ils ont bien compensé ce gap : je peux écrire du python, je peux brancher mes manipulations et ça reste performant car le calcul lui-même se fait en scala sur le cluster. Et pourtant je manipule toutes ces choses compliquées en python. Ce n’est plus du SQL, c’est un vrai langage et donc je peux faire des boucles, des if, … donc des pipelines très expressifs dans un langage très simple tout en ayant les meilleurs performances possibles.

La prochaine techno que tu voudrais essayer ?

Les conteneurs et notamment les managers et orchestrateurs comme Kubernetes : pour aller distribuer certains types de workload, notamment le code python. Avec Spark c’est déjà distribué évidemment mais il y a encore beaucoup de monde qui fait du python « classique » qui n’est pas distribuable facilement à cause de l’environnement, de la versatilité et des conflits de libs. Les conteneurs promettent de répondre à ce genre de problématiques.

Un fail à partager ?

On a trop tardé sur l’adoption de certaines nouvelles technos : ça nous a coûté des clients. Typiquement Spark : on a fait l’intégration avec 3 à 6 mois de retard. A bien y réfléchir, si on l’avait fait plus tôt, on aurait certainement dû tout refaire car ça ne marchait pas encore très bien et son principe de fonctionnement a changé complètement. C’est passé d’un truc ultra geek à un truc magique. C’est quand même un fail mais il ne faut pas tomber dans l’excès inverse qui serait de se jeter sur les technos au même rythme que nos prospects.

Le truc dont tu es le + fier ?

La qualité du support fourni à nos clients. Tout ne marche pas toujours mais on a un très bon niveau de support avec une excellente satisfaction.

Le plus compliqué à gérer pour toi ?

On commence à arriver à une taille d’équipe où les problèmes de management se posent de façon plus aigüe. Ce qui me stresse un peu en ce moment c’est la cohésion d’équipe.

Une bonne résolution ?

Suivre de plus près les gens de l’équipe et leur faire plus de feedback aussi bien positif que négatif, je sais que je dois m’améliorer sur ces points-là.

Peux-tu citer une startup dont tu souhaiterais découvrir l’architecture dans une prochaine interview ?

Algolia qui a monté une infrastructure de search distribuée de tout premier ordre, Aircall, un succès français dont on parle peu, ou bien Clustree, dont je suis curieux de découvrir comment elle fonctionne sous le capot !

Les commentaires sont fermés pour cet article