Cette année encore, nous étions présents à Breizhcamp. En tant que speakers mais aussi dans le public, voici pour vous les présentations qui nous ont le plus marqués.
Luigi : Le machine learning lui dit oui
Sandra Pietrowska et Antoine Michaud nous ont présenté Luigi et son petit frère sous stéroïdes Airflow. Après une introduction aux différentes étapes d’un projet de Machine Learning (récupération, nettoyage des données, feature engineering, entraînement, validation puis prédiction) appliquée à un exemple concret, ils nous ont démontrés comment l’utilisation d’un outil de workflow dédié pouvait nous venir en aide.
L’objectif d’un tel outil : fournir une description d’un pipeline de traitement sous forme d’un script Python. On retiendra que les deux outils adressent un besoin légèrement différent :
- Luigi est un outil simple à déployer et propose un nombre assez restreint de fonctionnalités. Il est très bien conçu pour des workflows classiques et conviendra dans de nombreux cas.
- Airflow est bien plus complexe. Il propose davantage de fonctionnalités mais est également plus compliqué à prendre en main et à déployer et superviser. Son plus gros avantage vis à vis de Luigi réside dans sa gestion du temps. Typiquement, pour rejouer un workflow sur une période de temps donné, Airflow est beaucoup mieux conçu.
Si vous avez loupé cette présentation, aucun souci. Une session de rattrapage est prévue lors du mois de la data.
Setup a kappa architecture
Chéné Youen et Aurélien Vandel nous ont présenté, lors de ce hand’s on, la mise en place d’un pipeline de traitement de données temps réel.
Les différentes étapes abordées étaient :
-
- L’ingestion de données d’une API Yahoo avec Akka vers une cluster Kafka
- Le traitement de ces données en Spark Structured Streaming avec stockage des résultats sur HDFS. Il s’agissait ici de calculer un agrégat simple sur une fenêtre de temps.
- La visualisation avec Impala
Une dernière partie qui n’a pas été réalisée par manque de temps : la visualisation à l’aide de Saagie present
Les slides de la présentation sont disponibles et fournissent les informations nécessaires pour commencer (liens vers les dépôts GitHub pour le collecteur Akka et l’injecteur en Spark Structured Streaming, …).
Cela nous a également rappelé la stack SMACK imaginée par Lightbend que nous mettrons en place lors de l’un de nos slots au mois de la data.
Dis… Dessine-moi une monade
Philippe Charrière et Quentin Adam ont expliqué le concept des monades. La version officielle de cette description est la suivante : « monoïde dans une catégorie d’endofoncteurs ». En partant du concept que cette description est totalement indigeste, ils ont expliqué de façon ludique et dans la bonne humeur ce que cela voulait dire. Si vous souhaitez enfin comprendre de quoi il s’agit, ce slot est parfait.
Mention spéciale aux guests ayant servit les huitres et le vin blanc jus de raisin.
Machine Learning at scale : Tensorflow in the cloud
Yufeng Guo, Google advocate, nous a préparé une présentation sur Tensorflow. Deux aspects ont été abordés :
- Une présentation de l’API Layers. Cette nouvelle API, disponible depuis la version 1.0, permet de simplifier l’écriture d’un réseau de neurones en proposant des fonctionnalités de haut niveau.
- Le déploiement d’un modèle sur Cloud ML et son interrogation via la CLI de Google Cloud. Cette fonctionnalité, disponible on premise via TensorFlow Serving, permet d’exposer un modèle entraîné sous forme d’API REST en JSON. Les appels peuvent être fait prédiction par prédiction ou bien en mode batch.
Tout le code présenté par Yufeng est disponible sur son dépôt Github. On y retrouve notamment le Notebook qui a servi pour la démonstration.
Ingest node : (ré)indexer et enrichir des documents dans Elasticsearch
David Pilato nous a parlé d’une nouveauté dans Elastic Search : l’Ingest Node. Il s’agit d’un rôle que l’on peut attribuer aux différents nœuds de notre cluster ES et qui pourra définir des pipelines de traitements qui seront exécutés lors de l’indexation, ou bien de la réindexation dans le cas d’un enrichissement d’une donnée déjà indexée.
A l’instar de Logstash qui permet déjà ce genre de manipulation, l’Ingest Node propose une fonctionnalité en plugin fournissant des transformations que l’on peut chaîner (géolocalisation d’adresse IP, suppression de champ, …). Cependant, il ne se substituera pas à Logstash dans le sens où ce dernier permet de définir plusieurs sorties à nos traitements (par exemple S3 et ES) là où l’Ingest Node ne fera « que » indexer les données dans ES.
David nous a alors fait une démonstration de l’Ingest Node avec un plugin qu’il est actuellement en train d’écrire (nommé « ingest-bano » et basé sur la base open data bano) et qui permet de trouver une adresse postale à un couple latitude/longitude. Ainsi, en chaînant le pugin GéoIP et ce plugin, on peut se retrouver avec des documents fournissant l’adresse postale de personne ayant produit un log dans un serveur Apache.
Lao-Tseu, Software Craftsman
Gautier Mechling nous a fait bénéficier d’un talk de haute qualité et très décalé sur le mouvement du Software Craftsmanship.
En se basant sur différentes traductions des écrits de Lao-Tseu, un philosophe chinois de 600 avant J-C, il nous a présenté différents préceptes du Software Craftsmanship de façon très ludique. Parmi les sujets évoqués : pair programming, tests de code, règle du boy-scout, principes SOLID et bien d’autres.
La data visualisation pour les nuls – Thomas Fournaise
Dans ce talk, Thomas Fournaise présente les bonnes pratiques de la data visualisation. Contrairement à ce que l’on peut croire, parfois les propriétés statistiques ne suffisent pas de comprendre la distribution des données. Pour prouver cela, Thomas montre un exemple d’un quartet d’Anscombe. On comprend que les 4 sous-ensembles de données ont exactement les mêmes propriétés statistiques (simples), mais c’est en les visualisant qu’on réalise que la distribution des points est complètement différente pour chacun des cas.
Selon lui, le but principal de la visualisation est de montrer des choses complexes avec l’économie de moyennes (« simple is not easy! »). Pour commencer, il faut se poser plusieurs questions: pour qui on prépare la visualisation, qu’est ce qu’on veut montrer et pourquoi. Les visualisations peuvent être informatives, mais aussi servir à analyser les données afin prendre la décision.
Cela nous amène à un autre aspect de la data visualisation, notamment les mauvaises pratiques dans la manipulation de graphes. L’interprétation des graphes peut changer selon plusieurs critères :
- zoom sur une partie des données temporelles (par exemple à partir de la date où on observe une augmentation)
- point de départ des axes
- échelle des axes
- …
Thomas découpe la data visualisation en 7 phases :
- Acquisition de données par exemple par la technique de scraping (import.io, visualscraper, grepsr, webscraper.io…). Les données acquises peuvent avoir différents types: binaire, qualitatif ordinal, catégoriel, quantitatif discret, continu.
- Transformation des données en unités communes, faire un lien entre les référentiels (cartographie pour les cordonnées)
- Filtrer les données : élimination des outliers, des données manquantes
- Exploration : indicateurs statistiques comme moyenne, médiane, écart type…
- Représentation : définir l’objectif de la visualisation (comparaison ? évolution ?), le nombre des composants, si la visualisation sera statique ou interactive. Il décrit des exemples de besoins et les graphes les plus adaptés (create.ly, datawrapper, cortoDB, d3.js, charts.livegap.com)
- Affiner la visualisation pour s’assurer qu’elle répond aux besoins et ne va pas au-delà
- Interagir : intégrer les interactions nécessaires
Les problèmes que l’on rencontre en microservice: configuration, authentification et autres joyeusetés – Quentin Adam
Avec le recul de plus de 5 ans de mise en place de microservices à Clever Cloud, Quentin Adam nous fait une synthèse des leçons apprises.
Tout d’abord il nous rappelle l’intérêt des microservices :
- utiliser pour chaque microservice la bonne techno/langage pour le problème à résoudre,
- la scalabilité se fait au cas par cas pour chaque microservice,
- l’évolution est isolée dans chaque microservice, rien n’empêche de re-développer un microservice entier, tant que l’on respecte le contrat exposé les autres services ne seront pas impactés,
- un développeur par microservice.
Coté sécurité il est primordial de logger et d’auditer la communication entre les microservices.
Idéalement pour faire communiquer nos microservices il faut privilégier des communications de type « loosely coupled » car les communications HTTP apportent trop d’inconvénients : synchrone et sensible au réseau. Il est préférable de privilégier une solution de type « boîte de messages » tel qu’un message broker. Pour cela RabbitMQ est le plus simple et efficace, si on a une volumétrie vraiment très importante il est possible d’utiliser Kafka, mais attention il n’y a pas d’acknowledgment. Une autre possibilité est d’utiliser zeroMQ mais ce dernier est plus à appréhender comme un kit pour faire son propre message broker.
Concernant le découpage des microservices, Quentin nous explique qu’ils ont dû regrouper après coup deux microservices : cela peut arriver et il faut l’accepter. Plus tard le microservice avait finalement été re-découpé mais d’une autre manière.
Des codes smells permettent de détecter que l’on aurait trop (ou mal) découpé nos microservices :
- des microservices partagent le même datastore
- le partage exagéré des lib entre microservices
Qui es-tu et qu’as-tu le droit de faire ?
Un élément important d’une architecture microservices est sa capacité à distribuer l’identité entre les services. Une première solution naïve consiste alors à utiliser un cache pour la session, le problème est que l’on créé une dépendance entres tous les microservices, de plus le cache devient le bottleneck.
Dans un second temps, l’utilisation d’un proxy qui vérifierait les autorisations semble mieux mais c’est en fait une très mauvaise idée d’intégrer les règles métiers dans le proxy, sans compter les appels base de données qui vont ralentir tous les appels (potentiel bottleneck).
Finalement l’utilisation d’une API centrale d’autorisation, pas idéale mais finalement la moins pire des « mauvaises » solutions car elle est facile à mocker.
Quentin nous explique finalement que la meilleure solution se trouve du coté de la cryptographie avec JWT ou encore mieux d’utiliser Macaroons permettant de mettre en place un véritable système d’autorisation dans un environnement distribué.
Retour sur les panama papers et les bases de données graphes – Benoit Simard
Dans ce talk, Benoit Simard présente des technologies utilisées par l’ICIJ (International Consortium Of Investigate Journalists) pour faire des recherches dans les données « panama papers ».
La stack technique a été assez complexe. Pour commencer, Apache Tika a été utilisé pour extraire l’ensemble des données et des metadonnées. L’outil permet de structurer le contenu textuel de différents types. Ensuite, avec l’aide de Python et des techniques de NLP (Natual Language Processing), il était possible de détecter des liens entre les contenus.
Au-dessus de cela, pour stocker et indexer les document, l’ICIJ ont utilisé Solr. Le contenu a été mis en 12 silos separés. Enfin, pour pouvoir parcourir des relations, il fallait une base de données graphes, et c’est Neo4j qui a été choisi. C’est une base de données NoSQL, native graphes et open source depuis 2010. Dans la base, des données sont représentées en tant que noeuds (dans ce cas là les noms, des emails avec les différents propriétés) et les relations qui ont leur type, directions et aussi les propriétés. Pour requêter les bases, l’ICIJ a utilisé une interface Linkurious développée par une entreprise française, qui permet l’exploration des données en utilisant le langage Cypher, le langage déclaratif de pattern matching. A la fin de la présentation, Benoit Simard nous a fait une démonstration en cherchant des cabinets d’avocats en France, les liens entre les différents pays, etc…
Si vous êtes intéressés voici le lien pour explorer Neo4j et les données « panama papers » vous même https://neo4j.com/sandbox-v2/ et https://offshoreleaks.icij.org/ .
Quand internet sera gouverné par les |chats> de Schrödinger – Nicolas de Loof
Nicolas De Loof nous fait un état de lieu de l’ordinateur quantique et l’intérêt de cette technologie.
Il commence par introduire les concepts de base et les différences avec l’ordinateur classique. L’unité fondamentale de ce dernier est le bit, que nous pouvons représenter par un interrupteur à deux états : 1 ou 0, soit l’un soit l’autre. En mécanique quantique, on parle plutôt d’un qubit ou bit probabiliste. En effet, l’état d’un qubit est une superposition (une combinaison linéaire) de deux états 0 et 1. Globalement, il faut s’imaginer une sphère de rayon unitaire qui représente l’état du qubit, mais nous ne pouvons pas connaître son état exact sans le perturber. Pour mieux comprendre, l’exemple du chat de Schrödinger vient à notre aide. Imaginons que l’on enferme un chat dans une boîte avec un dispositif qui tue l’animal dès qu’il détecte la désintégration d’un atome d’un corps radioactif. Sans ouvrir la boîte, on ne peut pas savoir si l’atome est intact ou désintégré, ni si le chat est mort ou vivant. Cela pour dire qu’en fait, tant qu’on n’ouvre pas la boîte, l’atome se trouve simultanément dans deux états, intact et désintégré, aussi bien que le chat est simultanément dans l’état mort et vivant.
Il a été démontré mathématiquement que la puissance de calcul théorique d’un ordinateur quantique est une fonction exponentielle du nombre de qubits, et c’est une conséquence de la propriété de superposition d’état propre au qubit. Si un ordinateur classique à n bits à l’instant t peut se trouver dans seulement un des 2^n états possibles, un ordinateur quantique peut se trouver dans une superposition arbitraire de ces 2^n états, ce qui équivaut à un calcul extrêmement parallélisé, d’où l’intérêt de développer cette technologie. Cela vient évidemment avec des difficultés de réalisation et des coûts très importants. La solution n’est pas encore prête, bien que les acteurs qui investissent dans la recherche soient multiples.
Une utilisation envisageable est la cryptographie quantique. Si on considère le principe du RSA, son pouvoir de confidentialité réside dans l’utilisation des nombres premiers “suffisamment grands”. Pour l’instant, cela suffit à garantir une communication protégée, mais elle est potentiellement hackable. En revanche, la cryptographie quantique permet l’échange de la clé sécrète entre Alice et Bob grâce aux fondamentaux de la mécanique quantique. De plus, s’il y a un espion entre Alice et Bob, il est possible de savoir si il a capté de l’information et en quelle mesure.
Vous l’avez compris désormais, l’ordinateur quantique n’est pas pour demain, mais il sera surement intéressant de suivre les développements futurs.