Mounir Haddad, promotion 2016, a participé au Prix de la Fondation Mines-Télécom du meilleur stage de fin d’études avec son stage intitulé « LiveBox Foudroyée en Spark ». Mounir a effectué son stage chez Orange, à la DSI à Guyancourt d’avril à septembre 2015. Il nous livre ici son Executive Summary et sa vidéo.
De la preuve de concept du projet LiveBox Foudroyée à la mise en production
A partir de 2011, Orange a pressenti le potentiel des mégadonnées de ses bases de production. Le groupe a restructuré ses différents services, à différents niveaux, pour y intégrer le Big Data. Plusieurs projets de traitement de données massives ont déjà vu le jour et sont actuellement en production. Néanmoins, le Big Data est un domaine en essor et l’écosystème de Hadoop ne cesse d’évoluer. Les acteursdoivent agir en conséquence.
Dans ce cadre, la DSI d’Orange a lancé plusieurs Proof of Concept (POC), dont le projet LiveBox Foudroyée (LBF), répondant à des cas d’usage métiers, pour apprécier les avantages et les performances de Spark, un nouvel outil prometteur. Si ceux-là sont jugés concluants, un environnement de production
dédié sera mis en place et des projets Spark y seront déployés. Le sujet du stage s’est inscrit dans cette initiative, l’objectif étant l’étude de la faisabilité de LBF dans un environnement Spark.
Le dispositif LBF vise à détecter en proactif le foudroiement de LiveBox et à prévenir les risques d’endommagement d’équipements, en recoupant les données du réseau Orange avec les prévisions et rapports météorologiques fournis par météoFrance.
Le projet LBF est actuellement en production sur une application implémentée en Pig. Il a été remarqué et sélectionné pour le trophée de l’innovation du salon Big Data Paris, qui s’est tenu en mars 2015 au CNIT de Paris. Un article du Journal du Net est consacré à cette édition du trophée.
La mission du stage a consisté en la refonte de ce dispositif dans un framework Spark, en utilisant le langage Scala. Les prérequis et les performances du prototype conçu ont été identifiés, ainsi que les problèmes rencontrés et leurs gravités. Les résultats ont été remontés lors d’une réunion sur l’industrialisation de Spark, avec l’équipe du centre de compétences BI & Big Data de la DSI d’Orange.
Le projet LiveBox Foudroyée
Chaque année, à peu près 10 000 LiveBox sont foudroyées. Dans ce cadre, Orange souhaite déployer le dispositif LBF.
Orange incite ses clients à débrancher la prise électrique de leur LiveBox ainsi que le câble ADSL relié à la prise téléphonique pendant la durée des orages. Si certaines solutions comme les prises parafoudre peuvent p
réserver un équipement, il n’est pas plus efficace que le débranchement de la LiveBox.
En outre, Orange peut détecter les LiveBox foudroyées afin de proposer à ses clients un échange rapide en boutique Orange ou point relais. Le foudroiement des LiveBox peut coûter cher à un opérateur suivant sa politique : Orange remplace gratuitement les équipements endommagés.
Le projet LBF contient trois principaux modules
-
Référentiel : Il s’agit de transformer les données des terminaisons de lignes clients issues de différentes sources internes au réseau Orange afin de constituer des données facilement exploitables pour les traitements des deux autres modules. En l’occurrence, pour chaque LiveBox, on rassemble plusieurs informations (ligne, adresse, commutateur…) qui seront utiles pour les calculs suivants. Le référentiel est généré une fois par jour, les enregistrements de la veille sont écrasés puis remplacés.
-
Préventif : L’objectif est d’informer le client en cas d’alerte d’orage pour éviter le foudroiement de sa LiveBox, en lui préconisant de la débrancher. Ce module se base sur un algorithme recoupant les prévisions de météoFrance avec celles du référentiel. Le calcul préventif est lancé quotidiennement à deux reprises (ou campagnes).
-
Proactif : Il s’agit de dét
ecter en proactif le foudroiement des LiveBox et de proposer au client, après validation, un échange de son équipement. Ce module fonctionne grâce à un algorithme croisant les données de météoOrage avec celle des déconnexions de LiveBox. Le calcul proactif est lancé toutes les demi-heures, afin d’alerter les clients au plus tôt.
Le projet LBF vient en remplacement d’une ancienne application uniquement préventive.
Aussi, au vu des volumétries des sources de données, cette ancienne application devenait obsolète car elle s’exécutait sur un serveur unique : le traitement référentiel durait 10 h. Depuis début 2015, LBF est en production grâce à une application Pig sur un cluster distribué d’Orange. Le temps d’exécution du calcul référentiel est réduit à 23 min.
Aspects techniques
Le développement des modules de LBF est réalisé en local, dans un cluster pseudo-distribué. Cependant, un cluster simulé sur un ordinateur unique ne peut pas traiter de grandes quantités de données, à l’image de celle présentes en production. Un jeu de données réduit et anonymisé a donc été extrait des bases de production pour accompagner les phases de développement et de tests unitaires.
En outre, le test en local ne peut se substituer aux tests sur le cluster de tests d’Orange : les performances algorithmiques sont déterminées au cours de cette phase et certaines erreurs dans le code ne peuvent apparaître qu’en traitement distribué.
Les calculs réalisés lors des différents modules de LBF consistent essentiellement en un ensemble de filtres, de dédoublonnements et de jointures (fermées, ouvertes, élément le plus proche, jointures tridimensionnelles en temps et en surface). La difficulté réside dans les volumétries des tables sources.
Résultats
Quand on compare les performances de l’algorithme du calcul référentiel implémenté en Spark avec celles de l’application Pig en production, le constat est sans appel. Le temps d’exécution est divisé par 2 pour moins de ressources.
| Référentiel en Pig (MapReduce) | Référentiel en Spark | |
| Volumétrie en entrée | De l’ordre de 10 Go | |
| Temps d’exécution | 23 min | 10 min |
| Nombre de nœuds | 25 | 10 |
| Nombre de cœurs | 200 | 24 |
| Vitesse d’exécution | 0.43 Go/min | 1 Go/min |
| Vitesse d’exécution/nœuds | 17 Mo/min | 300 Mo/min |
Cela peut s’expliquer par le recours à la RAM plutôt qu’à HDFS pour le stockage des jeux de données intermédiaires à la sortie finale, voire à la mémoire cache pour les données amenées à être utilisées à plusieurs reprises, mais aussi par le fait qu’un job Spark n’est pas forcément une succession de paires map / reduce, contrairement à un job dans le paradigme Hadoop.
En outre, certaines techniques offertes par Spark ont aidé à atteindre ces performances. Entre autres, l’usage des variables partagées telles que le broadcast réduit significativement le temps d’exécution. Ce type d’objets a la particularité d’être connu de tous les nœuds impliqués dans le job courant et est donc idéal pour certaines opérations telles que la jointure de 2 jeux de données, dont un est à volumétrie limitée. Ce concept est très économe en bande passante.
Aussi, pour résoudre le problème de déséquilibre des volumétries à traiter en parallèle, il a fallu recourir à des fonctions de répartition, fonctions qui redistribuent un jeu de données de manière équilibrée sur les différents mappers en jeu.
Les différents résultats ont été présentés au chef de projets et aux autres membres de l’équipe. Une démonstration de LBF sur Spark a été organisée. Aussi, une présentation animée par un autre stagiaire et moi-même, portant sur Spark et son application en milieu industriel a été organisée. Les membres du centre de compétences BI & Big Data d’Orange s’y sont joints, ainsi que plusieurs personnes d’autres équipes de la DSI d’Orange, intéressées par la technologie Spark.
Suite à ce stage, la DSI d’Orange envisage de mettre en place une plateforme sur l’architecture Spark et d’y porter le dispositif LBF de même que d’autres projets en production.