Le salon Big Data Paris 2019 s’est tenu le 11-12 mars au Palais des Congrès. A cette occasion, j’ai eu la chance de participer à la seconde journée de cet événement qui a rassemblé plus de 180 exposants et 16 000 visiteurs.

Dans ce billet, je vous présente une sélection des 4 ateliers qui ont su attirer mon attention.  

Au programme :

• Databricks et son moteur de traitement parallèle Delta 
• Saagie et la mise en place d’une démarche DataOps soutenue par une Data Fabric 
• SAP et l’apport du Big Data aux projets de RPA – Robotic Process Automation
• Looker et son regard critique sur les vanity metrics

Databricks Delta – Décupler la puissance de Spark

L’éditeur Databricks, fondé par les créateurs d’Apache Spark, était présent sur le salon pour présenter Delta, son moteur de calcul parallèle. C’est ce moteur qui est mis en œuvre pour supporter leur plateforme d’analytics hébergée dans le Cloud. Delta tire profit de la puissance du moteur Spark en offrant la possibilité d’effectuer des traitements in-memory et l’exposition de multiples APIs dédiées aux traitements batch ou streaming, au calcul sur les graphes et à l’application de modèles de machine learning sur les données. 

Des améliorations ont été apportées pour en optimiser les performances et le confort d’utilisation.  

Pour cela, Delta ajoute une surcouche logique au moteur Spark matérialisée sous la forme d’une table, la Delta table, pour manipuler les données plus efficacement. La Delta table est gérée par le système de fichiers de Databricks, appelé DBFS – Databricks File System – et se compose des éléments suivants : 

• Des fichiers versionnés au format Apache Parquet : format populaire de stockage orienté colonne qui embarque directement le schéma de données associé au fichier
• Un index des enregistrements
• Des statistiques de requêtes
• Un fichier de log contenant les opérations effectuées sur la table 

Ces éléments permettent d’optimiser les requêtes effectuées sur les données stockées dans les bases de données relationnelles ou NoSQL : 

• Delta indexe les données insérées pour éviter d’avoir à parcourir l’ensemble des enregistrements, contrairement à Spark
• Les statistiques permettent de mettre en cache les données accédées fréquemment et de les récupérer plus rapidement
• Les multiples petits fichiers issus des enregistrements au fil de l’eau peuvent être agrégés et compressés en un seul fichier plus rapide à traiter  

Databricks annonce des performances 5 fois plus rapides, qu’une version classique de Spark, pour Delta.

Comparaison des performances runtime de Databricks Delta

Delta n’est pas en reste, non plus, du côté de la gestion des données :  

• Les transactions respectent les propriétés ACID 
• Les insertions dans une table sont validées grâce au schéma associé à la table ce qui évite la présence de données corrompues 
• Delta supporte les écritures concurrentes à la fois en mode batch et streaming sur une même table
• Delta prend en charge les commandes de type UPSERT et DELETE pour modifier les entrées des tables, alors que Spark les considère comme immutables
• Delta garde un historique des modifications des données et permet un rollback à un état précédent

Performances en utilisation concurrente de Databricks Delta

Databricks a illustré cette puissance au travers du cas d’Apple.

Apple possède un système de détection de menaces de sécurité devant supporter une charge de 100 To de données par jour répartie sur 300 milliards d’événements. Le moteur Delta a permis de pouvoir analyser ces données sur une fenêtre de 2 ans comparée à seulement 2 semaines auparavant, sans parler de la facilité d’implémentation de la solution.

Saagie – DataOps & Data Fabric

Saagie fait le constat suivant : les projets Big Data et d’Intelligence Artificielle peinent encore à rencontrer le succès espéré. Les obstacles qu’ils rencontrent s’opèrent à deux niveaux. 

• Au niveau technologique 

L’écosystème des technologies Big Data est à la hauteur du volume de données manipulé : gigantesque. Beaucoup de temps est accordé au choix des solutions à mettre en œuvre et à leur implémentation par les différentes équipes qui en ont la charge. En bref, il y a beaucoup de plomberie. Tellement que les entreprises peinent à se concentrer sur ce qui apporte de la valeur : la donnée qui sort au bout du tuyau. Celle qui a été collectée, stockée, agrégée, nettoyée, corrélée, analysée et utilisée par les modèles de machine learning pour finalement être communiquée, visualisée, être actionnable et exploitable.   

• Au niveau organisationnel 

Tous les projets visant à tirer de la valeur des données impliquent différents profils : développeur, data engineer, data scientist, data steward, business analyst, IT Ops, sécurité. Ces personnes peuvent cependant rencontrer des difficultés pour communiquer et collaborer ; l’une ne parle pas forcément le même langage que l’autre. 

Dans la lignée des méthodes Agile et DevOps, issues du développement logiciel, les projets data ont fait émerger le concept de DataOps. 

Le but est simple :  

• Développer les pipelines de traitements de données et entraîner les modèles de machine learning sur des cycles courts et itératifs 
• Passer rapidement en production en automatisant la chaîne de déploiement 
• Garder le contrôle sur la chaîne de traitements ainsi que sur les données manipulées  

Dans ce cadre-là, les équipes DataOps vont fortement s’appuyer sur une Data Fabric – ou Data Hub – comme celle présentée par Saagie.  

Voici quelques fonctionnalités que doit proposer une Data Fabric. 

La Data Fabric se présente comme une plateforme centrale de gestion des données. Tout d’abord, elle s’intègre avec l’ensemble des technologies inhérentes au Big Data : bases de données NoSQL et SQL, moteurs de recherche et de traitement, et bus de message. 

La plateforme supporte des langages dédiés au traitement de données et au machine learning (Scala, R et Python).  

Panorama des technologies supportées par la Data Fabric de Saagie

La plateforme doit faciliter le travail des personnes et non l’alourdir. C’est pourquoi, une Data Fabric s’interface avec les outils utilisés par les développeurs (Maven, SBT), data engineers et data scientists (R Studio, Jupyter Notebook) pour que ceux-ci restent dans un environnement familier et puissent ensuite pousser aisément leur travail sur la plateforme.

Elle héberge les pipelines de traitements développés par le data engineer ainsi que les modèles de machine learning du data scientist. La Data Fabric prend ensuite en charge l’orchestration des différents traitements ainsi que leur monitoring. La promotion des traitements entre les environnements jusqu’à leur mise en production est aussi assurée par la plateforme. 

La Data Fabric est également un environnement collaboratif. Il est possible d’y constituer des équipes projet, de définir pour chaque profil son niveau d’accès aux ressources, de disposer d’un environnement commun dans lequel partager les documents de travail et de diffuser à une plus grande échelle les résultats des traitements sous forme de visualisations.

Elle n’en oublie cependant pas la gouvernance et la sécurité des données. Elle règlemente les accès aux ressources en assurant un suivi de l’utilisation des données – il ne faut pas oublier que ce sont des données de production – après anonymisation et conformément à la RGPD – qui sont utilisées en environnement de développement pour entraîner les modèles de machine learning.

SAP – Quand la RPA tire parti du Big Data

L’atelier de SAP autour de la RPA – Robotic Process Automation – a permis de revenir sur ses apports et son lien avec le Big Data. 

Pour rappel, une application de RPA est une application installée sur une machine qui va simuler les actions d’un humain (clic de souris, remplissage de champ) sur un applicatif donné. Deux grandes catégories se distinguent : 

• Les robots autonomes : ces robots sont installés en salle serveur pour exécuter des tâches en continu et remplacer complètement l’humain.  

Exemple : un robot effectue des recherches sur des sites Internet (réseaux sociaux, annuaires, …) à partir d’un nom et d’un prénom pour récupérer le maximum d’informations sur une personne et enrichir une base de données client. Cela s’appelle du web scraping. 

• Les robots interactifs : ces robots sont installés sur les postes utilisateurs et les assistent dans leurs différentes tâches.  

Exemple : le robot guide un nouveau collaborateur dans la prise en main d’un ou plusieurs applicatifs pour réaliser un processus précis, comme l’inscription d’un nouveau client.    

Les gains apportés par la RPA sont clairs :  

• Réduction du temps d’exécution des processus 
• L’humain peut se concentrer sur des tâches qu’une simple machine ne saurait accomplir
• Amélioration de la qualité des processus liée à la réduction des erreurs humaines
• Meilleure expérience des utilisateurs qui sont accompagné dans l’usage de l’application
• Meilleur reporting des actions effectuées car fourni par un robot 

De plus, il n’est pas nécessaire d’apporter des modifications à l’applicatif pour que le robot puisse interagir avec lui. Le RPA peut même, au contraire, enrichir l’application en affichant, par-dessus l’interface graphique, des boutons de commande. L’utilisateur pourra les utiliser comme tous les autres, et ils déclencheront des actions du robot. 

Pour avoir un ordre d’idée du gain de temps espéré, la réconciliation de facture peut faire intervenir 5 applications, 20 écrans et nécessiter 150 clics. En temps normal, l’opération peut prendre de 6 à 7 minutes. Avec la RPA, le processus peut être ramené à 20 secondes. 

Mais alors qu’en est-il du Big Data ? Pour SAP, il intervient en deux temps : 

• Dans un premier temps le Big Data permet de déterminer ce qu’il faut automatiser 

La collecte des données d’utilisation d’une application révèle les problèmes que celle-ci peut poser en termes d’expérience utilisateur. Le temps passé par un collaborateur à cliquer sur des boutons ou attendre l’affichage des pages est autant de temps perdu à ne pas porter son attention sur le client qu’il a en face de lui ou au bout de son téléphone. 

• Dans un second temps le Big Data intervient dans l’entraînement de ces robots en fournissant les données qui vont alimenter les modèles d’Intelligence Artificielle 

C’est ce que SAP appelle la IRPA – Intelligent Robotic Process Automation. Nous avons simplement l’équation suivante : 

IRPA = RPA + Machine Learning + Conversation AI 

A l’origine, les actions des robots étaient scriptées. Avec le machine learning et la collecte de données, un robot est en mesure d’apprendre directement des actions des humains en s’appuyant sur leur utilisation des applications. Il sera ainsi en mesure de classifier les emails et générer des réponses automatiques en prenant les décisions les plus appropriées. 

Pour ce qui est du Conversational AI, il s’agit de faire intervenir un chatbot pour que celui-ci dialogue avec le client, recueille les informations dont il a besoin et réalise lui-même le processus métier complet. Par exemple, en combinant une technologie d’ICR – Intelligent Character Recognition – le robot récupère les informations à partir d’un scan, d’une image ou d’une écriture manuscrite.

SAP démontre comment un tel robot peut être utilisé pour effectuer le remplacement d’un équipement informatique en envoyant simplement son numéro de référence.  

Pour plus de détails, regardez la fin de cette vidéo

Looker – Oublions un peu nos vanity metrics

Pour se démarquer, Looker a fait le choix de ne pas centrer sa présentation sur le Big Data ni même sur sa propre plateforme. L’orateur nous a juste remis en tête une idée simple : méfions-nous des vanity metrics. 

Tout le monde apprécie les tableaux de bord : la donnée est visuelle et facile à comprendre. Par contre, il faut faire attention aux indicateurs insérés dans ces tableaux de bord et ne pas perdre de vue leur finalité. Ces indicateurs, que l’orateur appelle « vanity metrics », sont efficaces quand il s’agit de mesurer l’état de santé d’une entreprise, en revanche leur utilité se révèle très faible quand il s’agit d’améliorer l’efficacité opérationnelle. 

Les 3 limites identifiées par Looker sont les suivantes :  

• Ce sont des indicateurs de trop haut niveau pour pouvoir directement observer l’influence que nous pouvons avoir dessus 

Selon Looker, 90% des collaborateurs de l’entreprise n’ont aucun moyen d’agir directement sur le chiffre d’affaire. 

• Ils sont statiques c’est-à-dire que ce sont les mêmes indicateurs qui sont monitorés tout au long de l’année. 

Aux alentours de décembre et des fêtes de fin d’année, il est pertinent de se concentrer sur le nombre total de ventes. Pourtant après cette période, il serait plus judicieux surveiller le nombre de retours des produits. 

• Ces indicateurs peuvent paraître superficiels et ne sont peut-être utilisés finalement que dans un but d’autosatisfaction 

Le présentateur a repris l’analogie d’une note d’évaluation d’un élève. Une note renseigne le professeur, les parents, les services d’admission sur le niveau de l’élève. Elle n’indique en aucun cas à l’élève comment s’améliorer…  

En guise d’illustration, deux cas ont été présentés. 

Le premier cas concernait une application de gaming. Le modèle économique de ces applications requiert d’avoir un grand nombre d’utilisateurs pour leur proposer de la publicité ou bien leur faire acheter des bonus. Au lieu de ne s’attacher qu’au nombre d’utilisateurs quotidien, l’éditeur a décidé d’observer le taux de complétion de chaque niveau proposé. En constatant que certains niveaux étaient très peu complétés, ce qui entraînait la frustration des joueurs et la suppression de l’application, les développeurs ont pu rééquilibrer la difficulté de ces niveaux. 

Le second cas portait sur une application de paiement entre particuliers. A la suite d’une mise à jour, les indicateurs ont montré un nombre total de paiements multiplié par deux. Si la société s’était contentée de cette information, elle aurait pu le payer très cher. Ce qu’il fallait réellement voir était un défaut sur l’interface qui sélectionnait par défaut le bouton « payer ». L’augmentation fulgurante du nombre de paiements était en fait due à des paiements effectués par erreur et qu’il fallait corriger en effectuant un paiement dans le sens opposé. 

Cet atelier m’a fait prendre conscience qu’il faut voir au-delà des simples indicateurs banals, classiques, vus et revus, appliqués dans n’importe quelle entreprise lambda. Il convient de se poser les bonnes questions et de s’efforcer de définir des indicateurs qui font sens pour son secteur d’activité. 

Cela ne veut pas dire qu’il faut complètement oublier les vanity metrics. Mais comme les bonnes choses, il ne faut pas en abuser.

Pour faire un bilan de ce salon, nous retiendrons que la nécessité de mettre en place un datalake dans l’entreprise fait partie de la culture collective. L’accent est désormais mis sur la façon d’utiliser au mieux l’ensemble des données collectées. Quelle que soit leur finalité, il faut maintenant se doter des outils pour industrialiser les projets, faire collaborer les équipes sur ces sujets et investir sur la gouvernance et la sécurité des données.