DataXDay 2019 - Le retour de l'équipe Univalence

jeudi 19 décembre 2019 • 23 minutes de lecture

Nous sommes seulement une semaine après le Process Mining Camp 2019 et déjà un autre événement se présente à nous, le DataXDay. Un événement organisé par l'entreprise Xebia et regroupant des dizaines et des dizaines de Data Engineers et Data Scientists tous ayant soif de connaissances et de partages.

Cette fois-ci tous les data ingénieurs d'Univalence ont ainsi pu y participer et l'un d'entre nous a même eu l'occasion de faire un talk, L'incroyable efficacité de l'unification des logs, qui aura très certainement un article qui lui est consacré dans le futur! Sur cette journée de conférence, il y a eu 22 talks centrés autour de la data ayant tous des sujets divers et variés parfois plus dédiés aux data scientists, parfois plus dédiés aux data engineers et parfois alliant les deux.

NB: Tous les talks sont d'ores et déjà présents gratuitement sur Xebia TV ou plus simplement dans la section vidéo du site DataXDay 🎉

Nous allons, dans cet article, vous partager notre expérience et les différents talks auxquels nous avons participé. La conférence ayant deux tracks se déroulant en parallèle, je ne ferais part que des talks auxquels j'ai participé. Ainsi voici la liste des talks que je ne traiterais pas lors de cet article accompagné d'un lien pour les visionner sur Youtube :

DataXDay - De Jupyter à Spark : les étapes de la mise en production du Machine Learning par Pauline Nicolas et Théo Bontempelli

Confident Data Migration: automatic regression testing par Thomas Franquelin

Keynote #1 : La confiance entre les humains et les données

La journée a commencé avec un talk de Caroline Goulard, anciennement journaliste de la donnée qui, maintenant, est CEO à Dataveyes, une entreprise qui, comme elle le dit si bien, tant à vouloir "rendre l'invisible visible".

Lien vers la vidéo: https://www.youtube.com/watch?v=HtYf2brLIXw

D'ailleurs son talk était justement basé sur ce postulat, aujourd'hui nous sommes dans l'air de la donnée et malgré ce fait nous sommes la plupart du temps incapables de voir ce qu'elle représente vraiment. La visualisation de la donnée donne un sens à cette dernière et la rend accessible au plus grand nombre. J'ai d'ailleurs particulièrement apprécié les travaux qu'ils ont effectués notamment en visualisant l'impact sonore des différentes lignes de métro sur Paris. Le résultat étant, de par sa qualité, très impactant pour l'utilisateur. Un autre exemple sur la gestion de l’énergie d'une maison m'a aussi énormément interpellé, notamment grâce à la mise en place de la gamification au sein même du système. Ce dernier aspect rend la présentation globale de notre data plus actifs que jamais. Une idée incroyable, participant à réduire la consommation des personnes de manière ludique.

Somme toute un très bon talk pour commencer la journée (un de mes préférés) même si je regrette un peu qu'il n'eût aucune technologie de cité, afin d'occuper mes dimanches à donner de la vie à de la donnée (Mon petit doigt me dit que l'utilisation de l'API WebGL et d3.js doit être de mise 😉).

Keynote #2 : Database Infrastructure at Instagram Scale

Lien vers la vidéo: https://www.youtube.com/watch?v=b74cU-afJHM

S'ensuit un talk très intéressant pour tout les data ingénieurs, un talk de Michaël Figuière travaillant anciennement chez Instagram et actuellement Data Infrastructure Engineer chez Facebook. Ce dernier a notamment attiré notre attention car Michaël nous partage certaines problématiques qu'une architecture d'une ampleur considérable peut créer. Instagram est très certainement l'application django la plus complexe et avec plusieurs millions de lectures et écritures par seconde elle se doit d'avoir une infrastructure particulièrement tenace.

Ainsi à titre d'exemple, Instagram shutdown très régulièrement des datacenters entiers pour tester l’adaptabilité de l'infrastructure en cas de crises majeures (spoil alert: tout se passe bien!). De plus chaque datacenter est configuré pour gérer un certain nombre de requêtes et pour trouver ce nombre, l’infrastructure surcharge un des datacenters afin de voir sa limite et ainsi de pouvoir quantifier la quantité d'informations qu'il peut traiter. Un autre fait intéressant, vos données Instagram vous suivent dans vos déplacements ainsi si vous décidez de partir en voyage aux États-Unis alors vos données actuellement concentrées dans le cluster Europe vont être déplacées dans le cluster Amérique du Nord pour réduire la latence.

Kafka Streams, profiling, framegraphs, Oh My!

Lien vers la vidéo: https://www.youtube.com/watch?v=DBfmKE42PiY

Nous avons continué notre matinée avec un talk de Xavier Léauté qui est actuellement software engineer chez Confluent. Le but de ce talk, partager certaines astuces pour optimiser et profiler un kafka streams. Ce talk bien qu'étant focus sur kafka est aussi très intéressant pour l'optimisation de n'importe qu'elle programme s’exécutant via la JVM.

Xavier rappelle que le profiling est important pour éviter de rencontrer des problèmes par la suite. Ce monitoring peut se faire via les metrics (Je vous recommande d'ailleurs cette trilogie d'articles sur le monitoring de kafka écrit par Evan Mouzakitis sur le site de DataDog). Cependant, Xavier nous met en garde. Les metrics sont adressés à des problèmes déjà rencontrés auparavant, mais il se peut que vos problèmes seront uniques à votre cas, de plus certains problèmes n’apparaîtrons qu'en production et pas en phase de test et dans ce cas la, il faut creuser plus bas pour détecter les bottlenecks.

L'outil de prédilection pour faire du profiling selon ses préférences est Async Profiler. Il le décrit comme étant l'outil le plus simple et le plus puissant pour faire faire du profilage d'application basé sur la JVM. Ses points positifs ? Il est très léger, s'attache directement à la JVM sans avoir besoin d'argument ou de restart cette dernière et est compatible avec les anciennes versions du JDK.

Deep learning en production vu par un Data Engineer

Lien vers la vidéo: https://www.youtube.com/watch?v=aLowsPZjVew

Rien de mieux qu'un talk sur le deep learning en production pour satisfaire à la fois les Data Scientists et à la fois les Data Engineers présents à l'événement. Cette idée, elle vient de Romain Sagean, un consultant chez Xebia.

Son objectif est très simple, faire part de son expérience personnelle de la mise en place d'un modèle de deep learning dans une chaîne de production et le tout vu par un data ingénieur. L'objectif du projet étant d'acheter des liens sponsorisés Google à moindre de coup pour un total de 10 millions de prédictions par jour et les faire en moins d'une heure.

Dans un tel contexte, il faut faire des choix. Quel modèle utilisé pour notre prédiction? quel framework utilisé pour créer le modèle et prédire?

Dans le cas de Romain et son équipe, ils ont d'abord testé différents modèles de machine learning et sont venu à la conclusion que XGBoost était un choix intéressant car donnant les meilleures prédictions. Mais finalement, ils vont se diriger vers du deep learning car plus de possibilités et de potentiels là où XGBoost atteignait déjà ses limites. Une fois le modèle prêt, il fallait choisir le framework à utiliser: TensorFlow et Kerasce sont immédiatement présenter à eux pour leurs communautés et leurs maturités respectives mais ils ne se sont pas arrêté à eux et ont aussi inclus dans leur choix DL4J et mxnet.

Basé sur des critères propres à leur architecture, TensorFlow l'a emporté, mais impossible de le faire fonctionner en production à cause d'une version de glibc trop vieille au niveau de la production. Plutôt que d'update toute la chaîne de production, le choix le plus raisonnable en matière de temps et de moyens était de sélectionner le deuxième sur la liste DL4J, un framework codé en Java. S’intégrant parfaitement en production, il ne manquait plus qu'à l'optimiser. L'optimisation a été faite de bien des manières et voici quelques-unes des pistes traitées lors du talk: preprocessing, mapper les values par partitions, créer un seul modèle lazy et non un modèle par ligne, set spark.yarn.executor.memoryOverhead, gérer les workspaces DL4J.

How to leverage the Apache Kafka Ecosystem to productionize Machine Learning

Lien vers la vidéo: https://www.youtube.com/watch?v=I4eDowjTZLk

Un talk imaginé par Kai Waehner qui est Technology Evangelist à Confluent qui, dans la même veine que le dernier talk, s'adresse à la fois aux Data Scientist et au Data Engineer. Cependant celui-ci s’intéresse beaucoup plus à la place du machine learning autour d'une architecture Big Data plutôt qu'à la sélection d'un modèle et de son implémentation en production.

Avec la présence de très bon framework de machine learning tels que Keras ou TensorFlow, il est très facile aujourd'hui de faire du machine learning. Mais une tâche beaucoup plus complexe est d'adapter ces frameworks à des cas où des millions d'informations arrivent en temps réel. Dans un cas comme celui-ci, on peut se demander comment entraîner le modèle en continue tout en appliquant le modèle en cours pour prédire des informations. Fortes heureusement pour nous, de grandes entreprises sont déjà passé par là et proposent des solutions pour nous aider dans notre tâche. Kai prend l'exemple de Michelangelo, un framework made in Uber pour mettre en place du Machine Learning "at uber's scale".

La plupart des solutions fonctionnent avec Kafka et Kai nous donne les différentes raisons qui font que Kafka est la solution pour du machine learning en production. Il insiste d'ailleurs sur un point très important, Kafka n'est pas seulement un mécanisme de publication de message mais aussi un lieu de storage scalable et un lieu où on a le pouvoir de prétraiter notre data. De plus il tient aussi à nous rappeler que kafka ne se résume pas au broker que l'ont chéri tant mais fait partie d'un écosystème où l'on retrouve Kafka Streams, Kafka Connect ou encore KSQL (un outil développé pour prétraiter de la data en SQL en production permettant ainsi de réconcilier Data Scientists et Data Engineers). Le fait est qu'aujourd'hui il existe en plus une solution pour faire ingérer un flux de données venant de Kafka directement à TensorFlow ce qui nous permet d’entraîner notre modèle en temps réel. Toutes ses caractéristiques pour ne citer qu'eux rendent Kafka très attrayant justifiant ainsi sa popularité.

Traitement automatique du langage pour le routage d'emails

Lien vers la vidéo: https://www.youtube.com/watch?v=ANrdU6UgtZU

Il y a eu beaucoup de data engineering dans ces derniers talks, il était temps de prendre un peu l'air et rien de mieux que ce talk pour se détacher des technologies du big data afin de s'adonner à un peu de text mining avec l'incroyable librairie Melusine codée en python.

Ce talk nous a été fournis par deux Data Scientists travaillant à Quantmetry, Tom Stringer et Antoine Isnardy. La librairie a pour but de fournir tout les outils nécessaires afin de faire du traitement automatique de mail de A à Z. Elle se décompose en plusieurs modules dont trois principaux :

Un module de preprocessing et de cleaning de mail afin de diviser les différentes parties de ce dernier.
Un module qui résume un mail en extrayant les différents mots jugés importants.
Un module de classification qui utilise les réseaux de neurones récurrents et/ou les réseaux neuronales convolutifs pour classifier les mails vis-à-vis des catégories définies au préalable

Ce talk a notamment été intéressant, car il a soulevé certaines problématiques telles que la transformation d'un produit (Melusine était destinée à être utilisé à la Maif) en un outil open source qui, de ce fait, requiert d'avoir une documentation claire et précise ainsi qu'un code modulable et adaptable pour tous.

L'incroyable efficacité de l'unification des logs !

Lien vers la vidéo: https://www.youtube.com/watch?v=ryFAZZEZbyw

Le talk tant attendu par les univaliens puisque le talker n'est personne d'autre que Jonathan Winandy, le fondateur d'Univalence 😎. Dans ce talk, Jon a décidé de parler de log et de tracing à travers un talk assez déjanté et très bien structuré. D'ailleurs, Jon écrira très certainement un article qui rentrera plus en détail que cette petite introduction.

Le talk part d'une tendance concrète, aujourd'hui nos applications sont de plus en plus complexes et il est de plus en plus dur de créer une histoire retraçant les actions de notre système lui-même composé d'une multitude de micro services. L'histoire est, concrètement, un ou plusieurs fichiers où sont stockés des événements émis par l'application. On peut par exemple, en Java, utiliser l'Apache Logging Services (Log4j 2) pour créer ce système de log.

Malheureusement, les applications sont devenues trop complexes pour que le logging soit efficace, une application a une multitude de micros services et chacun d'entre eux racontent sa propre histoire. Jon nous parle alors du descendant du logging, le tracing et d'une technologie qui met tout le monde d'accord : OpenTelemetry. Le tracing, comparer au logging, a un contexte causal créant une dépendance entre les logs.

Mais encore une fois, ce n'est pas assez. Jon propose d'aller encore plus loin dans le tracing avec un projet : Zoom. Son but étant d'utiliser les outils de monitoring distribué, d'unifier les logs avec la donnée sous forme d'événement, et d'améliorer la prise en compte des lieux de calculs en accentuant sur les lignes de codes utilisés, les commits effectués, la machine qui calcule, etc. Afin d'avoir l'histoire la plus claire possible.

Incremental Data Architecture

Lien vers la vidéo: https://www.youtube.com/watch?v=sew2i7G96a8

On change de salle et on rejoint un talk sur l'incremental data architecture, un talk vraiment très intéressant et très dynamique donné par Walid HAOUARI, Big Data Engineer à Xebia.

Ce talk était bien, vraiment bien. Le sujet abordé était très universel et le choix de passer par un cas concret permet d'associer ce talk aux problématiques que l'on rencontre dans nos différents métiers. Walid a pris le cas d'une stratup fournissant un système d'analyse médicale à un petit village d'Afrique ayant pour but de s’accroître pour obtenir une architecture capable de gérer plusieurs villages entiers. Il explique comment et pourquoi il est préférable d'établir une architecture cible dès le commencement puis de la déstructurer afin d'obtenir des architectures réalisables d'un point de vue économique, temporelles et technologiques. Pour, par la suite, incrémenter cette architecture et tendre vers l'architecture cible.

Il nous met en garde sur le choix que font certaines entreprises de changer complètement d'infrastructure, un choix qui se trouve être la plupart du temps inefficace et périlleux car vous risquer d'écœurer votre équipe qui ne retrouve plus ses marques et qui doit, si cela n'a pas été fait auparavant, monter en compétences pour maîtriser tout les nouveaux outils.

Harnessing the power of Generative Adversarial Networks (GANS) for supervised learning

Lien vers la vidéo: https://www.youtube.com/watch?v=aL7rhJz8mAI

S'en est suit un talk d'Olga Petrova, une Machine Learning DevOps Engineer à Scaleway. Elle a fait le choix de nous parler des Generative Adversarial Networks plus communément appelé GAN notamment très utilisé pour générer des images très réaliste dans le cas d'un face swaping par exemple.

Après une courte introduction sur la différence entre supervised et unsupervised learning. Olga nous a montré des exemples d'applications des GAN. GAN est notamment utilisé pour générer la tête de personne n'existant pas alors que tout porte à croire l'inverse tant le réalisme est au rendez-vous. C'est comme ça que https://thispersondoesnotexist.com/ existe, un projet créé par Nvidia. D'autres projets tout autant ambitieux nous ont été présenté tels que la face frontalization qui consiste à prendre une photo d'une personne ayant un angle de tête quelconque en entrée et de renvoyer sa tête de face en sortie ou encore la super résolution (Un exemple de projet ici) visant à augmenter la résolution d'une image.

Elle nous a aussi fait part de sa libraire de machine learning en python préféré. Alors que tout le monde ne jure que par Tensorflow ou Keras, Olga, quant à elle, ne jure que par PyTorch et était étonnée qu'il ne soit pas mentionner dans les autres talks ce qui à attiser ma curiosité. Fun fact intéressant, ces librairies en accord avec cet article atteignent les limites du langage, à voir ce que le futur nous réserve !

Give meaning to 100 billion analytics events a day, analytics at Teads

Lien vers la vidéo: https://www.youtube.com/watch?v=Up3iaK5fdjw

La journée continue et touche presque à sa fin. Notre avant-dernier talk est produit par Alban Perillat-Merceroz, Software Engineering Master pour Teads. Cette société ne vous dit peut-être rien au premier abord et pourtant, tout le monde a déjà vu leur travail à l'oeuvre. La pub qui s'affiche lorsque vous lisiez vos news le matin pendant le trajet jusqu'au travail, ce sont eux! Et pour pouvoir proposer les meilleures pubs aux différents utilisateurs, Teads est confrontée à plus de 100 milliards d'événements par jour.

Autant d'événements supposent une architecture Big Data solide pouvant engranger un aussi grand nombre de données. Pour résumer très succinctement, voici comment leur architecture se construit. Le browser envoi des événements à savoir : si la personne à cliquer sur la pub, quand la pub à commencer, quand la pub à stopper. Ces événements transitent dans Kafka, sont traités via DataFlow pour ensuite être écrits directement dans BigQuery. Il reste à récupérer les données qui sont encore à ce stade des raw data pour les fournir en tant qu'outils d'analyse et ainsi apporter de la valeur. À ce stade, l'entreprise est passée par plusieurs types d'architecture (Infobright Enterprise Edition) pour finalement entièrement se tourner sur RedShift en tant que datamart.

Cette technologie est assez atypique car jouant sur deux types de services de cloud computing différents créant ainsi une latence lors des transitions entre deux types de technologies. Une question très intéressante a d'ailleurs été posée à la fin de ce talk ouvrant la porte à une solution permettant d'accumuler la totalité de la data, passé de Kafka à Cloud Pub/Sub pour garder une cohérence technologique et rendre le système beaucoup plus pratique. On a tendance à oublier que des "équivalents" Kafka existent tant ce dernier est chéri par tous et il est intéressant de songer aux alternatives qui dans des cas comme celui-ci ou on a une architecture très orienté gcp pourrait être une bonne idée.

The internals of stateful stream processing in Spark Structured Streaming

Lien vers la vidéo: https://www.youtube.com/watch?v=yhSwQ-GqAoA

De par son côté très technique, finir avec un talk de Jacek Laskowski, un grand nom de la communauté Spark, n'est pas gagné. Cependant son côté très enjoué et plein de vie a complètement inversé la tendance et ce qui devait être un talk assez lourd c'est transformé en quelque chose de très plaisant à regarder et à écouter. Ce talk se base sur spark 2.4.3 et se base sur la partie structured streaming.

En réalité, spark ne fait pas exactement du temps réel. Comme l'explique Jacek, spark exécute des minis batchs très très rapidement à la place donnant cette impression de temps réel. Sachant cela, il est facile de comprendre que tout ce qui est faisable avec sparkSQL est faisable en streaming avec le structured streaming. Mais pas que, vous pouvez aussi très bien utiliser la DataSet API et vous ne serez donc pas perdu avec le côté streaming que fournis Spark.

Spark streaming peut être vue comme un équivalent à Kafka Streams ou encore Flink mais Jacek insiste quand même sur une différence majeure. Spark streaming a la possibilité de traiter une centaine de lignes en même temps quand les deux autres solutions ne peuvent en traiter qu'une à chaque fois.

DataXDay pour l'équipe

DataXDay ne se résume pas qu'à de très bons talks, mais aussi et surtout à une organisation faite aux petits oignons. En plus des talks, la qualité des différents repas (le saucisson et la fontaine de chocolat 😵), la bonne humeur de l'équipe de Xebia qui a organisé l'événement (Giulia Bianchi, Loïc Divad, Souhaib Guitoni, Anne Beauchart, Sandra Pietrowska, Sameh Ben Fredj et Elhadi Cherifi) et la qualité des animations (le data lake était génial encore merci pour les tableaux 😉) ont fait de cet événement un événement mémorable pour l'équipe Univalence. Cet événement nous a permis de tous nous retrouver dans la joie et la bonne humeur et il m'a aussi permis de découvrir et/ou me forger un avis sur énormément de différentes technologies du Big Data.

Hâte de vous retrouvez au DataXDay 2020 🚀