Université Pierre et Marie Curie (Paris VI)
Master de Sciences, Technologies, Santé mention Informatique
Spécialité Scienc...
Remerciements
Je tiens tout d’abord à remercier Monsieur Éric MARUENDA, le directeur de l’équipe DOT (Déve-
loppement d’Ou...
Résumé
Nous vivons dans un monde où l’utilisation des objets connectés a connu une croissance expo-
nentielle dans l’espac...
Abstract
We live in a world where the use of connected objects has grown exponentially in only a few years.
In fact, the r...
TABLE DES MATIÈRES
Table des matières
Page
Remerciements ii
Résumé iii
Abstract iv
Table des matières vi
Table des figures ...
TABLE DES MATIÈRES
3.2 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
...
TABLE DES FIGURES
Table des figures
Page
2.1 Organigramme du groupe Bouygues . . . . . . . . . . . . . . . . . . . . . . . ...
LISTE DES TABLEAUX
Liste des tableaux
Page
2.1 Quelques chiffres de Bouygues Telecom à Juin 2016 . . . . . . . . . . . . . ...
Chapitre 1: Introduction générale
1. Introduction générale
1.1 Contexte du projet de fin d’études
Le présent rapport consti...
Chapitre 1: Introduction générale
Bouygues Telecom se base sur des outils de qualité de service qui permettent de contourn...
Chapitre 1: Introduction générale
dépendante et monter une architecture Big Data de bout en bout respectant les développem...
Chapitre 2: Présentation de l’entreprise
2. Présentation de l’entreprise
J’ai effectué cette année d’alternance au sein de ...
Chapitre 2: Présentation de l’entreprise
2.2 Bouygues Telecom
2.2.1 Un peu d’histoire
— Créée en Octobre 1994, Bouygues Te...
Chapitre 2: Présentation de l’entreprise
Proportionnellement à son parc de clients, Bouygues Telecom bénéficie d’un spectre...
Chapitre 2: Présentation de l’entreprise
Avec l’arrivée du nouvel entrant, les résultats financiers de Bouygues Telecom ont...
Chapitre 2: Présentation de l’entreprise
2.2.7 Organigramme
Figure 2.5 – Organigramme simplifié
2.2.8 Développement Projet ...
Chapitre 3: Le projet LoRa
3. Le projet LoRa
3.1 Présentation du projet LoRa
LoRa signifie (Long Range), ou Longue portée e...
Chapitre 3: Le projet LoRa
Le schéma ci-dessous modélise le réseau LoRa partant des objets connectés jusqu’aux application...
Chapitre 3: Le projet LoRa
3.2 Mission
Bouygues Telecom utilise actuellement environ 2000 antennes (ou Gateway) dans le ca...
Chapitre 3: Le projet LoRa
Par ailleurs, ma mission inclut les réunions avec la MOA (maîtrise d’ouvrage) afin d’identifier l...
Chapitre 3: Le projet LoRa
3.3.2 Hadoop
Hadoop est un framework Open Source qui permet de développer des applications dist...
Chapitre 3: Le projet LoRa
sur les différents noeuds du Cluster.
Figure 3.6 – Exemple de réplication de données sur HDFS, (...
Chapitre 3: Le projet LoRa
3.3.2.4 Apache Oozie
Oozie est un outil utilisé pour gérer et coordonner les tâches de traiteme...
Chapitre 4: Travail réalisé
4. Travail réalisé
4.1 Analyse des besoins
Dans le cadre de ce projet, notre client final est l...
Chapitre 4: Travail réalisé
4.1.1 Solution proposée
Dans un premier temps, et après avoir étudié les détails techniques, j...
Chapitre 4: Travail réalisé
4.2.1 La collecte et la transformation
Pour la collecte et l’enrichissement, une application «...
Chapitre 4: Travail réalisé
4.2.3 Restitution
À ce stade, le client peut interroger la base de données via l’interface Web...
Chapitre 4: Travail réalisé
4.3.2 Application Kafka2Hdfs
J’ai développé l’application «Kafka2Hdfs» qui permet de récupérer...
Chapitre 4: Travail réalisé
4.3.3.2 Import des tables référentielles
Le deuxième Workflow exécute des commandes Sqoop perme...
Chapitre 4: Travail réalisé
Figure 4.6 – Commandes pour afficher le nombre de messages sur les topics Kafka
D’après la figure...
Chapitre 4: Travail réalisé
4.4.2 Chargement des messages dans la base de données
Dans cette deuxième partie, il faut s’as...
Chapitre 4: Travail réalisé
À la fin d’exécution de tous les jobs, on peut voir que tous les messages sont bien chargés dan...
Chapitre 4: Travail réalisé
Figure 4.13 – Exemple de requête HiveQL lancé via «HUE»
4.4.3 Import des tables référentielles...
Chapitre 4: Travail réalisé
À la fin de l’exécution, toutes les tables ont été importées avec succès et les données sont bi...
Chapitre 4: Travail réalisé
Une fois que toutes les données sont collectées, enrichies, et stockées dans les tables de don...
Chapitre 5: Conclusion générale
5. Conclusion générale
5.1 Bilan et perspectives du projet
Dans le cadre de mon projet de ...
Acronymes
ADSL Asynchronous Digital Subscriber Line. 6
API Application Programming Interface. 3, 15, 18–20
BO Business Obj...
Acronyme
NRA Nœud de Raccordement Abonnées. 6
ODBC Open Database Connectivity. 14
POC Proof Of Concept. 2, 11
SGBDR Systèm...
Glossaire
Big Data Le Big Data regroupe des méthodes et des technologies appliquées à des environnements
évolutifs, pour l...
Bibliographie
Formations
[1] Cloudera data analyst training : Using pig, hive, and impala with hadoop. http://www.cloudera...
Annexes
1 {
2 "LNS_UplinkData" : {
3 "LNS_FormatVersion" : 1,
4 "LNS_AppEUI" : "AQIDBAUGBwg=",
5 "LNS_DevEUI" : "AQIDBAUGB...
1 {
2 "LNS-UplinkLog" : {
3 "LNS-FormatVersion" : 1,
4 "LNS-AppEUI" : "AQIDBAUGBwg=",
5 "LNS-DevEUI" : "AQIDBAUGBwg="
6 "L...
1 {
2 "LNS_DownlinkLog" : {
3 "LNS_FormatVersion" : 1,
4 "LNS_AppEUI" : "AQIDBAUGBwg=",
5 "LNS_DevEUI" : "AQIDBAUGBwg=",
6...
1 /** @author wzeghdao <wzeghdao@bouyguestelecom.fr> */
2 public class Application {
3 public static void main (String... ...
Mise en place d'une architecture Big Data pour la collecte et l'analyse de gros volumes de données.
Prochain SlideShare
Chargement dans…5
×

Mise en place d'une architecture Big Data pour la collecte et l'analyse de gros volumes de données.

145 vues

Publié le

Rapport de projet de fin d'études

Publié dans : Données & analyses
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
145
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
7
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mise en place d'une architecture Big Data pour la collecte et l'analyse de gros volumes de données.

  1. 1. Université Pierre et Marie Curie (Paris VI) Master de Sciences, Technologies, Santé mention Informatique Spécialité Sciences et Technologies du Logiciel Rapport de projet de fin d’études Mise en place d’une architecture Big Data pour la collecte et l’analyse de données afin d’optimiser les performances du nouveau réseau LoRa dédié aux objets connectés Walid ZEGHDAOUI, 2016 Encadré par Adriano SA NASCIMENTO Mention de confidentialité : Le présent rapport contient des informations confidentielles ou privilégiées et ne doivent en aucun cas être diffusées, exploitées, ou copiées sans autorisation préalable.
  2. 2. Remerciements Je tiens tout d’abord à remercier Monsieur Éric MARUENDA, le directeur de l’équipe DOT (Déve- loppement d’Outils Télécoms), grâce à qui j’ai pu effectuer une mission passionnante, pour sa confiance, son accueil chaleureux au sein de l’équipe ainsi que son suivi administratif. Je remercie particulièrement mon tuteur entreprise, Monsieur Adriano SA NASCIMENTO pour son écoute ainsi que le partage de son expertise au quotidien. Ses connaissances techniques furent essentielles lorsque des choix devaient être faits. J’adresse aussi mes remerciements à Monsieur Mohamed Amine ABDESSEMED dont l’aide fut précieuse, pour sa force de proposition et sa réactivité. Il m’a prodigué de nombreux conseils et avis techniques au cours de ma mission, ainsi qu’à Monsieur Matthieu SALAS pour sa disponibilité, son écoute et ses conseils avisés et à toutes les autres personnes de l’équipe DOT pour leur esprit d’équipe ainsi que la bonne ambiance de travail qui régnait tout au long de cette année. Mes remerciements vont également à Monsieur Emmanuel CHAILLOUX, responsable du Master Science et Technologie du Logiciel (STL) à l’Université de Pierre et Marie Curie (UPMC), ainsi qu’à tous les enseignants du Master. C’est en effet en grande partie grâce à leurs enseignements que j’ai su mener à bien mon projet de fin d’études. Enfin, je tiens à remercier mes parents, ma fratrie et tous mes proches et amis, qui m’ont encouragé, aidé et soutenu durant cette année. ii
  3. 3. Résumé Nous vivons dans un monde où l’utilisation des objets connectés a connu une croissance expo- nentielle dans l’espace de quelques années. En effet, le cabinet d’études Gartner a évalué à 4,9 milliards le nombre d’appareils communicants en 2015, et estime que ce nombre pourrait atteindre les 25 milliards d’ici 2020. C’est ce qu’on appelle la révolution numérique de l’Internet des Objets, où la plupart des objets de notre quotidien sont équipés de capteurs leur permettant d’échanger des informations sur leur environnement et leur état. Bouygues Telecom a vite compris les enjeux de cette révolution et a lancé le déploiement du premier réseau français LoRa dédié aux objets connectés, et qui devrait couvrir l’ensemble du territoire français d’ici fin 2016. Ce réseau a donné naissance à de nouveaux services tels que la gestion intelligente des ressources, la localisation des objets ou encore le suivi médical des personnes. C’est dans ce contexte que s’inscrit mon projet de fin d’études qui porte sur les tendances et concepts technologiques du Big Data. L’objectif de ce projet est de concevoir une solution logicielle et de mettre en place une architecture Big Data permettant de collecter, d’enrichir et de stocker des messages échangés entre des appareils connectés afin d’optimiser les performances du réseau LoRa en utilisant des composants de l’écosystème Hadoop ainsi que d’autres technologies. Mots clés : Big Data, Écosystème Hadoop, Internet des objets, LoRa. iii
  4. 4. Abstract We live in a world where the use of connected objects has grown exponentially in only a few years. In fact, the research firm Gartner counted up to 4.9 billion communicating devices in 2015, and estimates that this number could reach 25 billion in 2020. This is called the digital revolution of the Internet of Things. Bouygues Telecom has soon realized the stakes of this revolution and has launched the deployment of the first french LoRa network dedicated to connected objects that should cover all of the french territory by the end of 2016. This network gave rise to new services such as intelligent resources management, location of objects and medical monitoring for people. It is in this context that my project is set up. The goal is to design and implement a Big Data software solution allowing the collection, the enrichment and the storage of exchanged messages between devices in order to optimize LoRa network’s performance using the Hadoop Ecosystem’s components as well as other technologies. Keywords : Big Data, Hadoop Ecosystem, Internet of Things, LoRa. iv
  5. 5. TABLE DES MATIÈRES Table des matières Page Remerciements ii Résumé iii Abstract iv Table des matières vi Table des figures vii Table des tableaux viii 1 Introduction générale 1 1.1 Contexte du projet de fin d’études . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Motivation pour le Big Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Problématique et Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3.1 Enjeux du Big Data pour Bouygues Telecom . . . . . . . . . . . . . . . . . . . 1 1.3.2 Bouygues Telecom et le réseau LoRa . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Organisation du travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.5 Organisation du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Présentation de l’entreprise 4 2.1 Le groupe Bouygues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Bouygues Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 Un peu d’histoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 Quelques chiffres (à Juin 2016) . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 Réseau Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4 Réseau Fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.5 Bouygues Telecom dans un marché bouleversé . . . . . . . . . . . . . . . . . . . 6 2.2.6 Priorités stratégiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.7 Organigramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.8 Développement Projet SI - DPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 Le projet LoRa 9 3.1 Présentation du projet LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 Le Réseau LoRa et Bouygues Telecom . . . . . . . . . . . . . . . . . . . . . . . 10 Walid Zeghdaoui v Septembre 2016
  6. 6. TABLE DES MATIÈRES 3.2 Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Technologies utilisées pour la réalisation du projet . . . . . . . . . . . . . . . . . . . . 12 3.3.1 Apache Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.2 Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2.1 HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2.2 Apache Hive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2.3 Apache Sqoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2.4 Apache Oozie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.3 Apache Flink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4 Travail réalisé 16 4.1 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.1 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2.1 La collecte et la transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.2 Stockage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.3 Restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1 Application Kafka2Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1.1 La consommation des messages . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1.2 L’enrichissement des messages . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2 Application Kafka2Hdfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.3 Workflow Oozie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.3.1 Chargement des messages dans la base de données . . . . . . . . . . . 20 4.3.3.2 Import des tables référentielles . . . . . . . . . . . . . . . . . . . . . . 21 4.3.3.3 Suppression des données . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 Tests de fiabilité et de maintenabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.1 Stockage de données enrichies sur Hdfs . . . . . . . . . . . . . . . . . . . . . . . 21 4.4.2 Chargement des messages dans la base de données . . . . . . . . . . . . . . . . 23 4.4.3 Import des tables référentielles et suppression de données . . . . . . . . . . . . 25 4.4.3.1 MySQL2HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4.3.2 Purge Enriched Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5 Conclusion générale 28 5.1 Bilan et perspectives du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2 Bilan et perspectives personnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Acronyme ix Glossaire xi Annexes xiii Walid Zeghdaoui vi Septembre 2016
  7. 7. TABLE DES FIGURES Table des figures Page 2.1 Organigramme du groupe Bouygues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Dates clés de Bouygues Telecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Répartition des fréquences des principaux opérateurs en Juin 2016 . . . . . . . . . . . 6 2.4 Performances financières de l’entreprise durant les 4 dernières années . . . . . . . . . . 7 2.5 Organigramme simplifié . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Composantes essentielles d’un objet connecté Lora . . . . . . . . . . . . . . . . . . . . 9 3.2 Schéma du réseau LoRa des objets connectés aux applications métier . . . . . . . . . . 10 3.3 Schéma du réseau LoRa au sein de Bouygues Telecom . . . . . . . . . . . . . . . . . . 11 3.4 L’architecture interne de Kafka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Composantes de l’écosystème Hadoop en fonction du type d’opération . . . . . . . . . 13 3.6 Exemple de réplication de données sur HDFS, (facteur de réplication = 2) . . . . . . . 14 3.7 Transfert de données via Sqoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.8 Cas d’utilisation de Flink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Les étapes de la solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Schéma d’architecture globale de la solution proposée . . . . . . . . . . . . . . . . . . . 17 4.3 L’hiérarchie utilisée pour le stockage de données . . . . . . . . . . . . . . . . . . . . . . 18 4.4 Les étapes du Workflow Hdfs2Parquet . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.5 Schéma d’import des tables référentielles . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.6 Commandes pour afficher le nombre de messages sur les topics Kafka . . . . . . . . . . 22 4.7 Exemple de stockage de données sur HDFS . . . . . . . . . . . . . . . . . . . . . . . . 22 4.8 Commande pour calculer le nombre total de lignes dans les fichiers d’un répertoire . . 22 4.9 Workflow Hdfs2Parquet en cours d’exécution . . . . . . . . . . . . . . . . . . . . . . . 23 4.10 Jobs MapReduce générés par Hdfs2Parquet . . . . . . . . . . . . . . . . . . . . . . . . 23 4.11 Tables de la base de données «loradb» . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.12 Résultat de l’exécution du script : «script_count.sh» . . . . . . . . . . . . . . . . . . . 24 4.13 Exemple de requête HiveQL lancé via «HUE» . . . . . . . . . . . . . . . . . . . . . . . 25 4.14 Trace d’exécution du Workflow «MySQL to HDFS» . . . . . . . . . . . . . . . . . . . 25 4.15 Informations de la table «loradb.tbl_lora_ref_ep» . . . . . . . . . . . . . . . . . . . . 26 4.16 Script du Workflow «Purge_Enriched_Data» . . . . . . . . . . . . . . . . . . . . . . . 26 4.17 Exemple de requêtes permettant d’afficher des indicateurs de performances . . . . . . . 27 Walid Zeghdaoui vii Septembre 2016
  8. 8. LISTE DES TABLEAUX Liste des tableaux Page 2.1 Quelques chiffres de Bouygues Telecom à Juin 2016 . . . . . . . . . . . . . . . . . . . . 5 3.1 Technologies utilisées pour la réalisation du projet . . . . . . . . . . . . . . . . . . . . 12 3.2 Détails des technologies utilisées pour la réalisation du projet . . . . . . . . . . . . . . 15 4.1 Catégories, types et délais de rétention des messages traités . . . . . . . . . . . . . . . 16 Walid Zeghdaoui viii Septembre 2016
  9. 9. Chapitre 1: Introduction générale 1. Introduction générale 1.1 Contexte du projet de fin d’études Le présent rapport constitue une synthèse sur le travail que j’ai réalisé durant mon projet de fin d’études chez Bouygues Telecom, et dans le cadre de validation de mon Master informatique, spécialité Science et Technologie du Logiciel (STL) à l’université de Pierre et Marie Curie (UPMC - Paris VI). J’ai choisi la voie de l’alternance pour finir ma dernière année de Master durant laquelle les en- seignements sont organisés en deux vagues de deux mois chacune, et le projet de fin d’études effectué en entreprise s’est déroulé en deux périodes avec une durée totale de huit mois. Le choix de l’alter- nance est motivé par plusieurs raisons telles que la combinaison entre l’aspect pratique de la formation au sein de l’entreprise et les connaissances acquises à l’université, ou encore l’acquisition d’une réelle expérience professionnelle et d’une approche véritable du métier d’ingénieur. Mais par dessus tout, l’alternance correspond parfaitement à mes futures aspirations professionnelles, puisque j’envisage de faire une thèse CIFRE à la suite de mon Master. En effet, l’alternance m’a donné un petit aperçu sur ce qu’est le travail dans une entreprise tout en étant rattaché à l’université, et s’inscrit donc dans la continuité de mes futurs projets. 1.2 Motivation pour le Big Data Suivant un Master en développement logiciel axé sur les langages de programmation et les méthodes algorithmiques, j’ai intégré Bouygues Telecom en tant qu’apprenti Big Data dans le cadre de mon projet de fin d’études. En effet, étant beaucoup intéressé par les enjeux et les problématiques liés au traitement de données à grande échelle, et les technologies utilisées pour la conception et la réalisation de solutions innovantes et intelligentes dans le domaine du Big Data et des Sciences de Données, l’orientation vers ce domaine me semblait évidente. J’ai donc décidé de me concentrer sur la mise en place d’une architecture Big Data permettant la collecte et l’analyse de gros volumes de données. Cela m’a permis d’acquérir une double compétence à la fois en génie logiciel et en Big Data. 1.3 Problématique et Objectifs 1.3.1 Enjeux du Big Data pour Bouygues Telecom Bouygues Telecom, un acteur majeur de la 4G en France, veille à offrir une meilleure expérience à ses utilisateurs sur l’ensemble de ses réseaux mobiles. Ainsi l’opérateur a fait de l’analyse de fichiers de Log, processus permettant de comprendre à chaud les incidents réseaux, une priorité stratégique. Walid Zeghdaoui 1 Septembre 2016
  10. 10. Chapitre 1: Introduction générale Bouygues Telecom se base sur des outils de qualité de service qui permettent de contourner les incidents sur le réseau et donc de mieux véhiculer les informations. Cependant, détecter ces incidents de manière suffisamment rapide et les comprendre est un autre problème. L’opérateur, n’étant pas satisfait des résultats, commence à explorer d’autres éventualités. En effet, d’après Monsieur Stéphane GOYAT, responsable SI du réseau chez Bouygues Telecom, l’opérateur vise l’excellence du service et pour y parvenir, il faut se rapprocher au maximum du ressenti des utilisateurs. Il rajoute, «Nous utilisions déjà des bases NoSQL pour faire des requêtes à posteriori sur les fichiers de Log. C’est la même technique qui sert à Hadoop pour traiter en temps réel ces données». C’est donc naturellement qu’il se tourne vers les solutions apportées par le Big Data. Suite à une étude réalisée au sein de l’équipe réseau de Bouygues Telecom sur les différentes implémentations d’Hadoop, la distribution de Cloudera a été la solution retenue, ayant le plus grand nombre d’utilisateurs sur le marché. Après avoir déployé et testé cette solution par les membres de l’équipe, Stéphane GOYAT en tire un bilan positif, et déclare «Le bénéfice le plus flagrant aujourd’hui est la rapidité de réponse aux incidents réseaux». 1.3.2 Bouygues Telecom et le réseau LoRa Bouygues Telecom s’intéresse à l’Internet des Objets et a lancé en 2016 la création d’Objenious, une filiale dédiée à ce domaine. Afin d’optimiser les performances de ce réseau, le besoin de créer un outil de supervision est naturellement né. C’est dans ce contexte que s’inscrit ma mission. Celle-ci a pour but de mettre en place une architecture Big Data permettant de collecter, d’enrichir, de stocker et enfin d’analyser les données échangées entre divers appareils connectés. 1.4 Organisation du travail réalisé Durant la première période effectuée en entreprise, j’ai suivi une formation de l’université de San Diego (USD) sur la plateforme Coursera, intitulée «Unlock Value in Massive Datasets», une spéciali- sation en Big Data. Cela m’a permis d’approfondir mes connaissances dans le domaine du Big Data et de m’initier à quelques frameworks et technologies tels que : Hadoop, MapReduce, Hive, Hbase ou encore des méthodes d’apprentissage supervisé ou non supervisé utilisées dans le Machine Learning. J’ai pu concrétiser cela en réalisant le développement du composant «Kafka to Parquet». Il s’agit d’un dispositif qui : — Collecte des messages générés par un simulateur de netflow à partir d’un bus Kafka. — Stocke les messages avec Flink sur HDFS, le système de fichiers distribué d’Hadoop. — Charge ces données dans des tables Hive sous format Parquet. La réalisation de ce composant avait pour but la mise en place d’un POC (Proof-of-Concept) dans le projet «Netflow» sur lequel je devais initialement travailler. Quelques semaines après le début de ma mission, ce projet a été attribué à une autre équipe suite à un changement de priorité. C’est finalement le projet «LoRa» que l’on m’a assigné. Néanmoins, les deux projets abordent la même problématique : la collecte et l’analyse de gros volumes de données techniques. La deuxième période était consacrée principalement au projet LoRa. Je devais analyser et com- prendre les besoins du client afin de mettre en place les différentes briques pressenties de façon in- Walid Zeghdaoui 2 Septembre 2016
  11. 11. Chapitre 1: Introduction générale dépendante et monter une architecture Big Data de bout en bout respectant les développements en vigueur. J’ai développé donc deux applications Java en utilisant l’API de Flink. La première dédiée à l’enrichissement des données reçues à travers un bus Kafka, qui seront repoussées ensuite dans un second Topic au sein du même bus. La deuxième application a pour but le stockage de ces données en- richies sur HDFS. Durant l’implémentation de cette application, j’ai rajouté une fonctionnalité à l’API de Flink permettant de créer un répertoire par type de messages reçus sur HDFS. Parallèlement, j’ai mis en place des Workflow Oozie pour orchestrer les jobs Sqoop, Hive et Shell permettant de charger les données enrichies dans des tables Hive sous format Parquet à partir desquelles des indicateurs clés de performance (KPIs) sont calculés et stockés dans des tables dédiées. 1.5 Organisation du rapport Ce rapport est organisé en trois grandes parties, et résume le travail que j’ai réalisé durant mon projet de fin d’études. Dans la première partie je présenterai brièvement le groupe Bouygues, puis je ferai un focus sur l’entreprise Bouygues Telecom. Dans la seconde, j’aborderai les détails liés au projet LoRa, je détaillerai ensuite la mission qui m’a été assignée, et je terminerai cette partie par une description des différentes technologies utilisées dans ce projet. Pour la troisième partie, je me focaliserai sur le travail que j’ai réalisé, où je détaillerai les développements de chaque brique, les difficultés rencontrées et les choix techniques effectués pour les contourner. Enfin, je terminerai ce rapport par une conclusion regroupant un bilan de ces huit mois passés en entreprise, les bénéfices de cette expérience, pour moi d’une part, et pour l’entreprise d’autre part. Walid Zeghdaoui 3 Septembre 2016
  12. 12. Chapitre 2: Présentation de l’entreprise 2. Présentation de l’entreprise J’ai effectué cette année d’alternance au sein de l’entreprise Bouygues Telecom qui fait partie du groupe Bouygues. Ce dernier est axé sur trois branches : la construction, les télécommunications et les médias. 2.1 Le groupe Bouygues Bouygues est un groupe industriel français créé en 1952 par Francis Bouygues et dirigé à l’heure actuelle par Martin Bouygues, Président Directeur Général depuis 1989. D’abord centrées sur le bâtiment en Ile-de-France, les activités de Bouygues se sont rapidement étendues à l’immobilier et la préfabrication industrielle, et grâce à ses filiales régionales à l’ensemble de la France puis à l’international dans plus de 80 pays. Au début des années 1980, Bouygues s’est engagé dans une politique ambitieuse de diversification qui lui a permis de devenir un groupe industriel structuré par une forte culture d’entreprise et dont les métiers s’organisent autour de trois activités : la Construction avec Bouygues Construction (BTP et Energies & Services), Bouygues Immobilier et Colas (Routes), les Télécoms avec Bouygues Telecom et les Médias avec TF1. Figure 2.1 – Organigramme du groupe Bouygues Walid Zeghdaoui 4 Septembre 2016
  13. 13. Chapitre 2: Présentation de l’entreprise 2.2 Bouygues Telecom 2.2.1 Un peu d’histoire — Créée en Octobre 1994, Bouygues Telecom était alors la troisième entreprise à entrer dans le marché des Télécoms en France après Orange et SFR. — Mai 1996 : L’opérateur lance l’ouverture commerciale du réseau Mobile et le premier forfait Mobile, puis lance les premières offres illimitées avec Millennium en 1999 et Neo en 2006. — En Octobre 2008, l’opérateur acquiert son propre réseau Fixe et devient fournisseur d’accès Internet (FAI) avec la Bbox. — Novembre 2010 : ouverture commerciale du réseau Fixe Très Haut Débit. Bouygues Telecom lance Bbox fibre, son offre Très Haut Débit et décide d’investir dans la fibre en zones très denses. — Le 1er Octobre 2013, Bouygues ouvre le plus grand réseau national de 4G dans plus de 2000 villes 4G, et lance une année plus tard la 4G+. — En Mars 2015, Bouygues Telecom a lancé la Bbox Miami, la première Box qui fonctionne sous Android en partenariat avec Google, ainsi que le réseau LoRa dédié aux objets connectés. 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 C réation de Bouygues Telecom Prem iers forfaits m obiles Forfait illim ité M illennium Forfait illim ité N eo Bbox Bbox Fibre 4G 4G + Bbox M iam i& R éseau Lora Figure 2.2 – Dates clés de Bouygues Telecom 2.2.2 Quelques chiffres (à Juin 2016) Effectif Bouygues Telecom compte plus de 7500 collaborateurs Moyenne d’âge 35 ans Clients 12,1 millions de clients Mobile 2,9 millions de clients Haut Débit Fixe Actionnariat Bouygues 90,5% du capital JC Decaux : 9,5% du capital Chiffre d’affaires 4,505 milliards d’euros (2015) Résultat net -65 millions d’euros (2015) Antennes relais Plus de 15000 sites Table 2.1 – Quelques chiffres de Bouygues Telecom à Juin 2016 Walid Zeghdaoui 5 Septembre 2016
  14. 14. Chapitre 2: Présentation de l’entreprise Proportionnellement à son parc de clients, Bouygues Telecom bénéficie d’un spectre de fréquences très important en prévision d’une explosion des usages data de ses clients. Figure 2.3 – Répartition des fréquences des principaux opérateurs en Juin 2016 2.2.3 Réseau Mobile Bouygues Telecom dispose d’un réseau couvrant 99% de la population en 2G, 97% en 3G+ et 75% en 4G. De plus, depuis 2014, l’opérateur a lancé la commercialisation de la 4G+ dans les grandes villes de France, soit un réseau avec un débit deux fois plus rapide que la 4G, permettant d’atteindre 220 Mbit/s. Le 31 Janvier 2014, Bouygues Telecom a signé avec SFR un accord de partage d’antennes afin d’améliorer la couverture et la qualité de l’expérience utilisateur sur le Mobile. La mise en œuvre de ce projet est opérationnelle depuis Janvier 2015, pour un réseau cible opérationnel fin 2018. En 2015, l’opérateur a lancé l’UHDM (Ultra Haut Débit Mobile) qui permet d’atteindre des débits proches de 300 Mbit/s dans quelques grandes villes dont Lyon et Chartres, ainsi que le réseau LoRa dédié au objets connectés. 2.2.4 Réseau Fixe Pour accroître son empreinte fixe, Bouygues Telecom déploie son propre réseau Fixe en dégroupant des NRA (Nœuds de Raccordement Abonnés), ce qui lui permet déjà de proposer son offre ADSL et VDSL à 19e99/mois à plus de 16,1 millions de foyers. Concernant le très haut débit pouvant atteindre 1 Gbit/s, l’opérateur déploie un réseau FTTH (Fibre To The Home) en propre de 6,5 millions de prises sur 750 villes à terme, grâce à des accords établis avec Orange et SFR. De plus, il a commercialisé 1,6 millions de prises FTTH à la fin du premier trimestre de 2016. 2.2.5 Bouygues Telecom dans un marché bouleversé L’industrie des Télécoms était autrefois très profitable à Bouygues Telecom, Orange et SFR qui généraient des revenus et des marges confortables. Mais en 2012, l’entrée de Free Mobile sur le marché a changé la donne, plongeant l’industrie dans une guerre des prix sans précédent. Walid Zeghdaoui 6 Septembre 2016
  15. 15. Chapitre 2: Présentation de l’entreprise Avec l’arrivée du nouvel entrant, les résultats financiers de Bouygues Telecom ont pris un coup sur l’ensemble : Chiffre d’affaires, EBITDA, Résultat net et Investissement d’exploitation nets. Figure 2.4 – Performances financières de l’entreprise durant les 4 dernières années 2.2.6 Priorités stratégiques Trois priorités stratégiques soutiennent les ambitions de Bouygues Telecom. — Créer de la valeur en dynamisant les usages data mobile. — Poursuivre la croissance dans le fixe en rendant les services et le Très Haut Débit accessibles à plus de monde. — Accélérer la transformation de l’entreprise tout en réaffirmant son positionnement. La mise en œuvre de ces transformations permettra un fonctionnement plus dynamique et plus agile de l’entreprise. Walid Zeghdaoui 7 Septembre 2016
  16. 16. Chapitre 2: Présentation de l’entreprise 2.2.7 Organigramme Figure 2.5 – Organigramme simplifié 2.2.8 Développement Projet SI - DPS Au sein de la Direction Réseau dirigée par Jean-Paul ARZEL se trouve la Direction des Programmes dirigée par Bruno CADU. C’est sous la hiérarchie de ces directions que se trouve le département DPS (Développement Projet SI) dirigé par Georgina LOPEZ. Les membres de DPS gèrent les services chargés des différents Systèmes d’Informations Réseau (SIR) de Bouygues Telecom. En ce qui me concerne, je suis rattaché au service DOT dirigé par Éric MARUENDA qui est en charge de piloter les systèmes techniques. Walid Zeghdaoui 8 Septembre 2016
  17. 17. Chapitre 3: Le projet LoRa 3. Le projet LoRa 3.1 Présentation du projet LoRa LoRa signifie (Long Range), ou Longue portée en français. Il s’agit d’une technologie qui permet aux objets connectés équipés d’une puce LoRa d’échanger des informations sous forme de messages de faible taille en utilisant un bas débit. Cela permet donc de réduire la consommation énergétique de ces appareils, en leur conférant jusqu’à 10 ans d’autonomie. Un appareil connecté équipé d’une puce LoRa comporte les composantes présentées dans la figure ci-dessous. Figure 3.1 – Composantes essentielles d’un objet connecté Lora Cette technologie utilise à la fois les fréquences radio libre 868 MHz et Internet, et présente une excellente capacité de pénétration des bâtiments, caves et sous-sols. En fait, la technologie LoRa utilise le protocole LoRaWAN (Long Range Wide-Area), traduit en fran- çais par réseau étendu de longue portée, contrairement aux réseaux de type 3G ou 4G qui se basent sur un protocole IP. Ce réseau a un débit compris entre 0,3 et 50 Kbps soit un débit plus faible que la 2G. L’objectif de la mise en place de cette technologie est de veiller à ce que les objets connectés, les applications M2M (Machine To Machine) dédiées à la communication entre ces objets et les infrastruc- tures Internet comme les smartphones, les serveurs ou encore les data-centers, puissent fonctionner en parfaite harmonie au sein de la future ville connectée. Walid Zeghdaoui 9 Septembre 2016
  18. 18. Chapitre 3: Le projet LoRa Le schéma ci-dessous modélise le réseau LoRa partant des objets connectés jusqu’aux applications métier. Figure 3.2 – Schéma du réseau LoRa des objets connectés aux applications métier 3.1.1 Le Réseau LoRa et Bouygues Telecom Membre fondateur de l’Alliance LoRa, Bouygues Telecom est le premier opérateur français à dé- ployer commercialement cette technologie, en permettant ainsi à plusieurs entreprises d’utiliser son réseau à des fins diverses. C’est déjà le cas de Colas, la filiale BTP de Bouygues spécialisée dans l’aménagement routier, qui utilise LoRa pour la gestion des places de parking à l’aide de capteurs installés sur la chaussée. Bouygues Telecom détient aujourd’hui plus de 15 000 sites avec lesquels on prévoit d’élargir d’une manière stratégique le déploiement rapide du réseau LoRa. Ce réseau permet l’émergence de nouveaux services qui rendent réelle la notion de : — «Smart City» avec notamment une gestion rationalisée des déchets, ou encore une meilleure maintenance et sécurité des infrastructures. — «Smart industry» qui permet un meilleur suivi des flux de transports ou de logistique. — «Smart farm» qui révolutionnera le monde agricole. La technologie LoRa dispose de fonctionnalités sans équivalent : une réduction de la consommation énergétique grâce à son réseau LoRaWAN et une géolocalisation facile et précise (comparée à celle de son concurrent direct SigFox), qui en font la technologie la plus aboutie dans le domaine de l’Internet des Objets reconnue mondialement. Walid Zeghdaoui 10 Septembre 2016
  19. 19. Chapitre 3: Le projet LoRa 3.2 Mission Bouygues Telecom utilise actuellement environ 2000 antennes (ou Gateway) dans le cadre du dé- ploiement du réseau LoRa et prévoit d’augmenter le nombre à 4000 Gateway d’ici fin 2016. Ces Gateway permettent de véhiculer les messages des objets connectés et de les pousser vers le cœur du réseau LNS (LoRa Network Server) afin de les publier sur un bus de messagerie. Figure 3.3 – Schéma du réseau LoRa au sein de Bouygues Telecom Le cœur du réseau LNS s’occupe de transmettre ces messages au Système d’Informations d’EDISON pour des besoins métier tels que l’utilisation des clients ou encore la facturation de ces derniers. En parallèle, ces messages seront émis au Système d’Informations (SI) Réseau de Bouygues Telecom afin de pouvoir suivre les performances du réseau LoRa et seront mis à disposition du Puits Perf qui fait partie des systèmes techniques du service DOT. Bouygues Telecom prévoit actuellement environ 2.000.000 d’abonnés répartis selon 3 types de contrats par rapport au nombre de messages générés par appareil connecté par jour. — 1 message par jour. — Entre 2 et 50 messages par jour. — Plus de 50 messages par jour. Selon les estimations faites au début du projet, plus de 20 Go de données par jour transitent via les Gateway utilisées actuellement pour le déploiement du réseau LoRa, et qui correspondent à plus de 65.000.000 de messages. Remarque : Ces chiffres sont calculés à base d’un seul appareil connecté par abonné, alors qu’on prévoit 100.000.000 d’appareils d’ici fin 2017. Dans ce contexte, ma mission a pour objectif de réaliser une architecture permettant de : — S’abonner au bus de messagerie afin de recevoir les messages publiés. — Enrichir et regrouper ces données suivant des règles de rétention. — Calculer des KPIs à partir de ces données. Cette architecture doit donc permettre de collecter, enrichir et stocker ces messages suivant des règles de rétention et éventuellement les restituer. Ma mission consiste alors à comprendre la nature de ces messages, monter de bout en bout l’architecture afin d’avoir un POC, et enfin industrialiser cette solution. Walid Zeghdaoui 11 Septembre 2016
  20. 20. Chapitre 3: Le projet LoRa Par ailleurs, ma mission inclut les réunions avec la MOA (maîtrise d’ouvrage) afin d’identifier les nouveaux besoins métier, valider les développements déjà réalisés et prendre connaissances des mises à jour concernant le projet, mais aussi la rédaction des documentations afin de faciliter le partage et le travail en équipe. 3.3 Technologies utilisées pour la réalisation du projet Afin de réaliser ce projet, plusieurs choix au niveau des technologies s’offraient à nous. Cependant, il a été décidé d’utiliser les technologies suivantes, lors de plusieurs réunions entre les différentes équipes du département. Collecte Apache Kafka, Java. Transformation Apache Kafka, Java, Apache Flink. Stockage Apache Kafka, Java, Apache Flink, Hadoop. Table 3.1 – Technologies utilisées pour la réalisation du projet 3.3.1 Apache Kafka — Kafka est un système de messagerie distribué en mode publish-subscribe persistant les données qu’il reçoit, conçu pour supporter des débits de données très importants. — Kafka conserve les données qu’il reçoit des Producteurs dans des Topics, correspondant à des catégories de données, auxquels des Consommateurs peuvent s’abonner pour les réceptionner. — Les messages ne sont pas détruits une fois consommés. Leur durée de vie est configurable. Les producteurs écrivent les données dans les Brokers ou nœuds d’un Cluster Kafka à partir desquels les consommateurs lisent ces données. Ces dernières sont stockées dans des topics qui sont séparés en partitions répliquées. Figure 3.4 – L’architecture interne de Kafka Walid Zeghdaoui 12 Septembre 2016
  21. 21. Chapitre 3: Le projet LoRa 3.3.2 Hadoop Hadoop est un framework Open Source qui permet de développer des applications distribuées et scalables pour traiter des données massives sur un Cluster de plusieurs machines. C’est le framework le plus utilisé actuellement pour réaliser des solutions Big Data. Hadoop est un socle d’un vaste écosystème constitué d’autres projets spécialisés dans le suivi applicatif (monitoring), les entrepôts de données ou la persistance de données. Figure 3.5 – Composantes de l’écosystème Hadoop en fonction du type d’opération Dans ce rapport, j’aborderai les composantes d’Hadoop que j’ai utilisées lors de la réalisation de ce projet et qui me semblent pertinentes pour la compréhension de la solution implémentée. 3.3.2.1 HDFS — HDFS pour (Hadoop Distributed File System) est un système de fichiers utilisé pour stocker des données avec réplication sur un ensemble de serveurs distribués. — L’architecture de HDFS est de type maître/esclave : parmi les noeuds du cluster, un seul d’entre- eux peut être le maître (NameNode) même s’il peut changer au cours de la vie du Cluster. Ce dernier est responsable des méta-informations (nom de fichiers, localisation des données, etc. . .) ainsi que de la réplication des données. Les autres nœuds (DataNode) contiennent les données. — Dans les versions d’Hadoop 0.x et 1.x, le NameNode dispose d’une instance secondaire qui contient les informations nécessaires permettant à l’administrateur de restaurer manuellement les données du Cluster en cas de panne du NameNode d’origine. Dans la version 2.0, un mode HA (High Availability) a été introduit pour gérer le Failover de manière automatique. — Ces données sont découpées et distribuées en blocs suivant la taille d’un bloc (taille unitaire de stockage), et le facteur de réplication qui représente le nombre de copies d’une donnée réparties Walid Zeghdaoui 13 Septembre 2016
  22. 22. Chapitre 3: Le projet LoRa sur les différents noeuds du Cluster. Figure 3.6 – Exemple de réplication de données sur HDFS, (facteur de réplication = 2) — La caractéristique principale de HDFS est que les fichiers sont de type «write-once», c’est-à-dire qu’on ne modifie pas les données déjà présentes. De plus, si un fichier est ouvert en écriture, il reste verrouillé pendant toute la durée du traitement. Cependant une fois l’écriture terminée, on peut y accéder en lecture plusieurs fois. 3.3.2.2 Apache Hive — Hive est un système d’entrepôt de données (Data Warehouse), permettant l’exécution de re- quêtes HiveQL (langage similaire à SQL) en les transformant en jobs MapReduce sur un cluster Hadoop en vue d’analyser et d’agréger ces données chargées physiquement dans des tables. — Hive propose un accès SQL aux données stockées sur Hadoop à nos outils classiques d’analyse de données comme BO(Business Object) via un driver ODBC. — Hive organise les tables en partitions qui se font à base de valeur de colonne de partitionnement. Cela permet un accès plus rapide aux données. Donc chaque table peut avoir une ou plusieurs partitions qui déterminent la distribution des données dans des répertoires. — Hive permet de stocker les données sous plusieurs formats. J’ai utilisé le format parquet dans le projet, étant le plus adapté en performance : jusqu’à 70% de compression et baisse significative de l’exécution du démarrage. 3.3.2.3 Apache Sqoop Sqoop est un outil qui permet le transfert des données entre le système de fichiers distribué d’Hadoop et un système de gestion de bases de données relationnelles (SGBDR) comme MySQL. Figure 3.7 – Transfert de données via Sqoop Walid Zeghdaoui 14 Septembre 2016
  23. 23. Chapitre 3: Le projet LoRa 3.3.2.4 Apache Oozie Oozie est un outil utilisé pour gérer et coordonner les tâches de traitement de données à destination de Hadoop. Il supporte des jobs MapReduce, Pig, Hive, Sqoop, etc. 3.3.3 Apache Flink — Flink est un moteur de gestion de flux de données qui fonctionne en batch et en streaming, et doté de nombreuses APIs pour la distribution de données ou le calcul distribué. — Flink est compatible avec l’écosystème Hadoop. De plus, il affirme être 2,5 fois plus rapide que son concurrent direct Spark sur un cas de grep de 1 To de Logs. — Flink peut consommer des messages depuis Kafka afin de les traiter. Ces traitements peuvent être des transformations simples : (importation ou exportation de données) ou des applications plus complexes utilisant la technique du fenêtrage par exemple. — Les résultats de ces traitements peuvent être renvoyés à Kafka pour la consommation par d’autres services, ou stockés dans HDFS ou d’autres systèmes comme ElasticSearch. Figure 3.8 – Cas d’utilisation de Flink Le tableau ci-dessous résume les détails des technologies utilisées pour la réalisation du projet. Technologie Version utilisée Implémentation Licence Kafka 0.8.2.0 Java Apache 2.0 Hadoop 2.6.0-cdh5.7.0 Java Apache Hive 1.1.0-cdh5.7.0 Java Apache 2.0 Sqoop 1.4.6-cdh5.7.0 Java Apache 2.0 Oozie 4.1.0-cdh5.7.0 Java Apache 2.0 Flink 0.10.0 Java & Scala Apache 2.0 Table 3.2 – Détails des technologies utilisées pour la réalisation du projet Le fait que ces outils soient Open Source est un gros avantage pour Bouygues Telecom qui souhaite réduire ses coûts sans pour autant perdre en performance. D’autant plus qu’il existe une communauté toujours plus grandissante derrière ces outils. Nous avons eu recours à d’autres outils tels que SVN pour la gestion des sources, GEX NG pour la gestion des exigences et ActivCollab pour la gestion du projet. Walid Zeghdaoui 15 Septembre 2016
  24. 24. Chapitre 4: Travail réalisé 4. Travail réalisé 4.1 Analyse des besoins Dans le cadre de ce projet, notre client final est le département Ingénierie Accès Radio de Bouygues Telecom en charge de concevoir et faire évoluer l’accès radio du réseau Mobile, il s’agit donc d’un client interne. Afin de fournir une solution qui respecte les contraintes et répond à toutes ses attentes, il est important dans un premier temps d’identifier et de bien comprendre chaque détail de ses besoins. À l’issue de ce projet, notre client souhaite disposer d’un environnement lui permettant de : — Regrouper les messages échangés entre des appareils connectés via le réseau LoRa dans un puits (une base de données) en respectant les délais de rétention. — Calculer des KPIs à partir de ces données. — Importer les données référentielles depuis une base de données MySQL d’un autre système référentiel du SIR. — Pouvoir effectuer des requêtes croisées sur ces données. Il existe une interface entre le cœur du réseau LNS et le Puits Perf qui permet la transmission des messages suivant deux mécanismes (Uplink, Downlink) afin de dissocier les messages reçus et les messages émis. Tous ces messages sont sous le format JSON et contiennent une liste de paramètres de types différents et leurs valeurs associées (cf. Exemples en annexe). Présentement, deux catégories de messages sont publiés sur le Topic Kafka (LNS_OUTPUT) : — DATA : Données destinées à être utilisées par l’application de l’utilisateur. — LOG : Données destinés à être utilisées par un système de supervision. Ces catégories correspondent à cinq types de messages : Catégorie Type de message Délai de rétention LOG UplinkLog 1 mois UplinkLogForeign 1 semaine DownlinkLog 1 mois DATA UplinkData 1 mois DownlinkReport 1 mois Table 4.1 – Catégories, types et délais de rétention des messages traités Walid Zeghdaoui 16 Septembre 2016
  25. 25. Chapitre 4: Travail réalisé 4.1.1 Solution proposée Dans un premier temps, et après avoir étudié les détails techniques, j’ai structuré le travail sur plusieurs étapes : Collecte • S’abonner au bus kafka et récupérer les messages publiés dans le Topic LNS_OUTPUT. Outils pressentis : Apache Kafka, Java, Apache Flink. Transformation • Selon le type de message, effectuer les éventuels enrichissements: la conversion de type et/ou le calculs de KPIs. Outils pressentis : Apache Kafka, Java, Apache Flink. Stockage • Stocker les messages dans une base de données en respectant les règles de rétention pour chaque type de message. Outils pressentis : Apache Kafka, Java, Apache Flink, Hadoop. Restitution • Le client peut interroger la base de données pour calculer ses KPIs en effectuant des requêtes croisées. Outils pressentis : Hue, BO, Tableau Software. Figure 4.1 – Les étapes de la solution proposée 4.2 Conception Dans cette section, je vais présenter l’architecture globale de la solution que j’ai proposée basée sur des outils Open Source tels que : Kafka, Flink et Hadoop : Figure 4.2 – Schéma d’architecture globale de la solution proposée Walid Zeghdaoui 17 Septembre 2016
  26. 26. Chapitre 4: Travail réalisé 4.2.1 La collecte et la transformation Pour la collecte et l’enrichissement, une application «Kafka2Kafka» qui permet de : — S’abonner au bus Kafka, plus particulièrement au topic LNS_OUTPUT via le connecteur «FlinkKafkaConsumer» qui nous est fournie par l’API Java de Flink. — Consommer les messages bruts sous format JSON au fil de l’eau. — Effectuer les transformations nécessaires sur ces flux de données en utilisant l’API Java de Flink, et qui consistent à rajouter des KPIs calculés à partir des données brutes et/ou à changer l’encodage de certains champs. Les paradigmes du MapReduce seront utilisés afin de réaliser ces transformations, ainsi pour chaque message reçu en entrée, un message enrichi est produit. — Enfin, repousser les messages enrichis au sein du même bus Kafka, dans un nouveau topic LNS_OUTPUT_ENRICHED. 4.2.2 Stockage Concernant le stockage, l’application «Kafka2Hdfs» permet de récupérer les messages enrichis de- puis le bus Kafka, puis de les stocker sur le système de fichiers d’Hadoop en utilisant le connecteur «Flink Hdfs Connector» fournit par l’API Java de Flink. L’application crée un répertoire par heure dans lequel un sous-répertoire est créé par type de messages. Les données doivent être stockées dans des fichiers de taille maximale 128 Mo qui correspond à la taille d’un bloc dans notre environnement Hadoop, afin d’optimiser la gestion de la mémoire et donc d’occuper l’espace mémoire nécessaire pour le stockage des messages. Figure 4.3 – L’hiérarchie utilisée pour le stockage de données En parallèle, les Workflow Oozie «Hdfs2Parquet» et «MySQL2HDFS» permettent respectivement de charger les messages enrichis depuis HDFS dans des tables de données Hive sous format Parquet et récupérer les tables de données MySQL via Sqoop, en utilisant la plateforme «HUE» (Hadoop User Experience) qui permet de créer et de paramétrer les Workflow (Date d’exécution, Intervalle de temps entre chaque exécution, etc...). Le Workflow «Hdfs2Parquet» sera lancé automatiquement chaque début d’heure afin de charger les données de l’heure précédente, et donc permet une mise à disposition rapide des données à notre client. Walid Zeghdaoui 18 Septembre 2016
  27. 27. Chapitre 4: Travail réalisé 4.2.3 Restitution À ce stade, le client peut interroger la base de données via l’interface Web «HUE» ou en y accé- dant via BO. Cela lui permettra éventuellement de détecter et corriger les incidents et optimiser en conséquence les performances du réseau LoRa. 4.3 Réalisation Dans cette section, je vais aborder les détails techniques des applications et des différents Workflow que j’ai mis en place. De plus, je vais insister sur les difficultés que j’ai rencontrées et les solutions élaborées pour les contourner. 4.3.1 Application Kafka2Kafka La première application que j’ai développée a pour but l’enrichissement des données brutes reçues en entrée en format String structuré en JSON depuis le bus Kafka. Dans un premier temps, il est nécessaire de configurer l’environnement de l’application avec les paramètres suivants, afin de se connecter au bus : — Le nom du Topic au sein du bus Kafka, topic=LNS_OUTPUT. — Le «group id» du consommateur, group.id=SIR2_LNSOUT. — Nom du serveur Zookeeper et son port, zookeeper.connect=localhost :2184. — Le nom du serveur Kafka et son port, bootstrap.servers=localhost :9092 Le corps de cette application est composé de deux parties essentielles : 4.3.1.1 La consommation des messages J’ai utilisé le connecteur «FlinkKafkaConsumer» de l’API de Flink, qui permet de lire les données à partir du topic LNS_OUTPUT. Ces données sont ensuite transformées en DataStream Flink en utilisant un schéma de désérialisation. 4.3.1.2 L’enrichissement des messages J’ai utilisé la fonction «flatMap» pour associer à chaque message brut en entrée, un message enrichi en sortie. Cependant, les 5 types de messages sont reçus via le même topic Kafka. Afin d’associer la bonne valeur en sortie pour chaque message, j’ai utilisé le Design Pattern (DP) Factory pour créer un objet JsonNode selon le type du message. Ce passage en objet Java permet de rendre ses champs accessibles, et facilite donc le processus de l’enrichissement qui consiste à calculer des KPIs en se basant sur les données du message et/ou de changer l’encodage de certains types. Une fois les messages enrichis, ils seront publiés sur le même bus Kafka, mais dans un autre topic en utilisant L’API Java de Kafka. Il suffit alors de renseigner les paramètres suivants : — Le nom du nouveau topic, topic=LNS_OUTPUT_ENRICHED. — Le «group id» du consommateur, group.id=SIR2_LNSOUT. — Nom du serveur Zookeeper et son port, zookeeper.connect=localhost :2184. — Le nom du serveur kafka et son port, metadata.broker.list=localhost :9092 Walid Zeghdaoui 19 Septembre 2016
  28. 28. Chapitre 4: Travail réalisé 4.3.2 Application Kafka2Hdfs J’ai développé l’application «Kafka2Hdfs» qui permet de récupérer les messages enrichis afin de les stocker sur Hdfs, le système de fichiers d’Hadoop. Puisque les 5 types de messages sont reçus via le même Topic (LNS_OUTPUT_ENRICHED), il m’a fallu mettre en place une logique permettant de stocker ces données dans des répertoires différents, ainsi créer un répertoire par type de message. Cela simplifie la tâche du Workflow «Hdfs2Parquet» permettant de charger ces données dans des tables. L’API de Flink permet d’indiquer le répertoire dans lequel les fichiers contenant les données seront stockés. En effet, le connecteur «Flink Hdfs Connector» fournit un «Sink» qui permet d’écrire des fichiers sur Hdfs. De plus, il est possible de configurer le Sink de manière à créer un répertoire pour une certaine période définie (Exemple : Un répertoire par jour). Cependant, l’API ne permet pas de créer des répertoires différents avec un même «Sink» pour une même période définie. Afin de contourner cette restriction, la première réflexion était de créer autant de «Sink» que de types de message. Mais cela s’est avéré très lourd et consomme beaucoup de ressources. Alors il m’a fallu trouver une autre alternative. La solution adoptée était alors de définir mon propre «Sink» incluant cette nouvelle fonctionnalité, ce qui n’était pas évident au départ. Ce découpage en deux applications me permet de séparer les responsabilités fonctionnelles, et donc les parties critiques de chaque application. De plus, cela permet de les réutiliser de façon indépendante et facilite leur maintenance. 4.3.3 Workflow Oozie 4.3.3.1 Chargement des messages dans la base de données Ce premier Workflow exécute des scripts HiveQL permettant de charger les messages enrichis stockés sur HDFS dans des tables Hive finales sous format Parquet. Pour cela, j’ai défini trois scripts : — Créer des tables Hive temporaires sous format TEXT. — Charger les fichiers contenant les messages enrichis dans ces tables en utilisant un «JsonSerDe» (Sérialisateur/Désérialisateur) pour décortiquer le corps du message et associer à chaque champ la valeur correspondante dans la table. — Enfin, insérer le contenu des tables temporaires dans les tables Hive finales sous format Parquet. Figure 4.4 – Les étapes du Workflow Hdfs2Parquet Ce passage par des tables temporaires me permet de contourner les restrictions du format Parquet. En effet, les fichiers du type «ParquetFile» ont une structure particulière et ne supportent pas les fichiers TEXT. En revanche, le Parquet fournit une compression de données significative et réduit ainsi l’espace mémoire alloué pour stocker les messages. Note : la base de données «loradb» contenant les tables finales est créée indépendamment des Workflow par un script HiveQL. Walid Zeghdaoui 20 Septembre 2016
  29. 29. Chapitre 4: Travail réalisé 4.3.3.2 Import des tables référentielles Le deuxième Workflow exécute des commandes Sqoop permettant d’importer les tables référentielles depuis une base de données MySQL mise à notre disposition par un autre système référentiel. Figure 4.5 – Schéma d’import des tables référentielles 4.3.3.3 Suppression des données Ce Workflow permet de lancer des scripts Shell afin de supprimer les données des tables tout en respectant les délais de rétention. Puisque ces tables sont partitionnées, cette tâche devient rapidement facile, il suffit donc de supprimer les répertoires ayant été créés depuis plus d’une semaine pour les messages de type UplinkLogForeign, et plus de 30 jours pour les autres. La suppression de ces répertoires provoque la suppression de leurs données des tables sans pour autant impacter les autres données. 4.4 Tests de fiabilité et de maintenabilité Dans cette section, je vais présenter des exemples de tests effectués sur les différentes briques que j’ai développées lors de la réalisation de ce projet. Pour ce faire, j’ai organisé le travail sur trois parties : 4.4.1 Stockage de données enrichies sur Hdfs Cette première partie nous permet de s’assurer que tous les messages sont bien collectés, enrichis et stockés sur HDFS. Afin de tester l’architecture mise en place et valider les développements réalisés, une application «LoRaProducer» produisant des messages LoRa sur le Topic LNS_OUTPUT m’a été fournie. Dans le but de détailler toute la chaîne de traitement, je vais m’appuyer dans cette section sur un exemple de tests générant 1.000.000 messages sur le bus Kafka, parmi une centaine de tests que j’ai effectués. Tout d’abord, j’ai lancé les deux applications «Kafka2Kafka» et «Kafka2Hdfs» ainsi que le pro- ducteur de messages LoRa. Une fois l’exécution de l’application «LoRaProducer» terminée, et à l’aide des commandes suivantes, j’ai affiché le nombre de messages présents sur les deux topics de Kafka «LNS_OUTPUT» et «LNS_OUTPUT_ENRICHED» : Walid Zeghdaoui 21 Septembre 2016
  30. 30. Chapitre 4: Travail réalisé Figure 4.6 – Commandes pour afficher le nombre de messages sur les topics Kafka D’après la figure ci-dessus, on peut voir que les deux topics contiennent exactement le même nombre de messages. On constate donc qu’il n’y a pas eu de perte de données durant la phase de l’enrichissement (Application «Kafka2Kafka»). Parallèlement, on peut voir qu’un répertoire par type de messages a été créé sur HDFS en utilisant l’interface «HUE» (Navigateur de fichiers). Figure 4.7 – Exemple de stockage de données sur HDFS Les messages sont stockés dans le répertoire «Hour=2016082003» et correspondent aux données reçues le 20 Août 2016 entre 03H00 et 03H59. En effet, l’application crée un répertoire par heure afin de faciliter le fonctionnement du Workflow responsable de charger ces données dans des tables Hive. Une fois que le stockage est terminé, on peut afficher le nombre de messages stockés sur HDFS, sachant que chaque message reçu en entrée correspond à une seule ligne dans le fichier où il est stocké : Figure 4.8 – Commande pour calculer le nombre total de lignes dans les fichiers d’un répertoire Donc, tous les messages ont été bien collectés, enrichis et stockés sur HDFS, sans perte de données. Walid Zeghdaoui 22 Septembre 2016
  31. 31. Chapitre 4: Travail réalisé 4.4.2 Chargement des messages dans la base de données Dans cette deuxième partie, il faut s’assurer que les messages sont proprement insérés dans la base de données «loradb». Pour cela, j’ai lancé le Workflow «Hdfs2Parquet» définit à partir de trois scripts : Figure 4.9 – Workflow Hdfs2Parquet en cours d’exécution Les instructions de chaque script sont transformées en job MapReduce. On peut donc accéder à tous les détails concernant l’exécution du workflow avec le «Job Brower» fourni par l’interface «HUE». Figure 4.10 – Jobs MapReduce générés par Hdfs2Parquet Walid Zeghdaoui 23 Septembre 2016
  32. 32. Chapitre 4: Travail réalisé À la fin d’exécution de tous les jobs, on peut voir que tous les messages sont bien chargés dans la base de données «loradb». On peut donc y accéder via le «Gestionnaire de Metastore» de «HUE» comme le montre la figure ci-dessous. Figure 4.11 – Tables de la base de données «loradb» J’ai mis en place un script Shell (cf. Annexe) pour parcourir toutes les tables de la base de données, et afficher pour chacune le nombre de lignes insérées. Cela nous permet de vérifier si la totalité des messages a été bien insérée. Figure 4.12 – Résultat de l’exécution du script : «script_count.sh» Après avoir effectué une centaine de tests, on peut prétendre que la solution mise en place est fiable : les données sont bien collectées, enrichies et stockées dans la base de données. Le client peut désormais effectuer différentes requêtes pour interroger la base de données en utilisant le «Query Editor» de «HUE». Walid Zeghdaoui 24 Septembre 2016
  33. 33. Chapitre 4: Travail réalisé Figure 4.13 – Exemple de requête HiveQL lancé via «HUE» 4.4.3 Import des tables référentielles et suppression de données Dans cette dernière partie, je vais détailler les tests des deux Workflow restants. 4.4.3.1 MySQL2HDFS Le Workflow «MySQL2HDFS» a pour but d’importer les tables référentielles depuis une base de données MySQL et les stocker dans «loradb». Lors de son exécution, on peut voir le statut des différentes actions qu’il génère. Figure 4.14 – Trace d’exécution du Workflow «MySQL to HDFS» Walid Zeghdaoui 25 Septembre 2016
  34. 34. Chapitre 4: Travail réalisé À la fin de l’exécution, toutes les tables ont été importées avec succès et les données sont bien insérées dans la base de données. Figure 4.15 – Informations de la table «loradb.tbl_lora_ref_ep» 4.4.3.2 Purge Enriched Data Le dernier Workflow lance un script Shell pour supprimer les messages de la base de données tout en respectant les délais de rétention. Il suffit juste de supprimer les répertoires contenant les anciens messages comme le montre la figure ci-dessus. Les données ayant été chargées dans la base de données «loradb», les fichiers concernés se trouvent dans le chemin indiqué dans le script. Figure 4.16 – Script du Workflow «Purge_Enriched_Data» Walid Zeghdaoui 26 Septembre 2016
  35. 35. Chapitre 4: Travail réalisé Une fois que toutes les données sont collectées, enrichies, et stockées dans les tables de données correspondantes, le client peut effectuer des requêtes croisées sur ces données en utilisant Hue, Bo ou Tableau afin de trouver des informations lui permettant d’optimiser le réseau LoRa. Par exemple, on peut lister le nombre de messages qui transitent par chaque Gateway afin de chercher celles les plus chargées. Figure 4.17 – Exemple de requêtes permettant d’afficher des indicateurs de performances Walid Zeghdaoui 27 Septembre 2016
  36. 36. Chapitre 5: Conclusion générale 5. Conclusion générale 5.1 Bilan et perspectives du projet Dans le cadre de mon projet de fin d’études, ma mission était de monter de bout en bout une architecture Big Data permettant à la fois la collecte, l’enrichissement et le stockage des messages échangés entre des appareils connectés afin de suivre les performances du réseau LoRa. Pour cela j’ai découpé le travail en deux parties : 1. La collecte et l’enrichissement de données : Cela consiste en la récupération des messages bruts publiés dans un bus Kafka et leur appliquer les différentes transformations possibles grâce à l’application «Kafka2Kafka». 2. Le stockage de données : Stocker les messages enrichis dans une base de données permettant au client d’effectuer ces requêtes. Tout d’abord, les données sont stockées sur HDFS avec l’appli- cation «Kafka2Hdfs», ensuite chargées dans des tables de données via des Workflow Oozie. Au sein d’un tel projet, chaque tâche est cruciale et demande beaucoup de rigueur, d’autonomie et d’organisation. Un oubli ou un élément non maîtrisé peut engendrer des erreurs ou des difficultés importantes plus tard dans le projet. Je n’ai finalement pas eu la possibilité d’industrialiser la solution implémentée puisque l’arrivée des machines de production est prévue pour la fin de l’année en cours. Néanmoins, j’ai organisé des séances de formation avec l’ensemble de l’équipe durant lesquelles j’ai transmis tous les détails pertinents sur les développements mis en place. L’équipe pourra donc mener le projet à son terme. 5.2 Bilan et perspectives personnels D’un point de vue personnel, ce projet de fin d’études constitue un tremplin idéal pour une carrière dans le Big Data. En effet, c’était ma première expérience professionnelle dans ce domaine où j’ai pu aborder l’une des principales problématiques liées à ce phénomène : la collecte et l’analyse de gros volumes de données. Ainsi, ce projet m’a permis de mettre en application mes compétences acquises durant mes années d’études, mais aussi de prendre en main plusieurs outils tels que Kafka, Flink, l’écosystème Hadoop (HDFS, Hive, Sqoop) et d’autres technologies dont j’ai moins parlées tout au long de ce rapport comme Hbase, Pig, ElasticSearch, Logstash et Kibana lors des interventions que j’ai effectuées sur d’autres projets. À terme, je souhaite faire une thèse CIFRE qui me permettrait de conjuguer Big Data et Machine Learning en appliquant des méthodes d’apprentissage automatique et des algorithmes de statistiques sur de gros volumes de données afin d’en tirer un bénéfice commercial. Walid Zeghdaoui 28 Septembre 2016
  37. 37. Acronymes ADSL Asynchronous Digital Subscriber Line. 6 API Application Programming Interface. 3, 15, 18–20 BO Business Object. 14, 19 CIFRE Conventions Industrielles de Formation par la Recherche. 1, 28 DOT Développement d’Outils Télécoms. ii, 8 DP Design Pattern. 19 DPS Développement Projet SI. 8 FAI Fournisseur d’Accès Internet. 5 FTTH Fiber To The Home. 6 HA High Availability. 13 HDFS Hadoop Distributed File System. 2, 3, 13–15, 18, 20–22, 28 HiveQL Hive Query Language. 14, 20 HUE Hadoop User Experience. 18, 19, 22–24 IP Internet Protocol. 9 JSON JavaScript Object Notation. 16, 18, 19 Kbps Kilobits par seconde. 9 KPI Key Performance Indicator. 3, 11, 16–18 LNS LoRa Network Server. 16 LoRa Long Range. iii, iv, 2, 3, 5, 6, 9, 10, 16, 19, 21, 28 LoRaWAN Long Range Wide-Area. 9 M2M Machine To Machine. 9 Mbit Mégabit. 6 MHz Mégahertz. 9 MOA Maîtrise d’OUvrage. 12 NoSQL Not Only SQL. 2 ix
  38. 38. Acronyme NRA Nœud de Raccordement Abonnées. 6 ODBC Open Database Connectivity. 14 POC Proof Of Concept. 2, 11 SGBDR Système de gestion de Bases de données relationnelles. 14 SIR Systèmes d’Informations Réseau. 8, 16 STL Science et Technologie du Logiciel. ii, 1 SVN Subversion. 15 UHDM Ultra Haut Débit Mobile. 6 UPMC Université de Pierre et Marie Curie. ii, 1 USD University of San Diego. 2 VDSL Very high bit-rate Digital Subscriber Line. 6 Walid Zeghdaoui x Septembre 2016
  39. 39. Glossaire Big Data Le Big Data regroupe des méthodes et des technologies appliquées à des environnements évolutifs, pour l’intégration, le stockage et l’analyse de gros volumes de données hétérogènes avec un certain niveau de Vélocité à atteindre. Ces technologies permettent donc de répondre à la problématique dite règle des 3V (Volume, Variété et Vélocité). iii, iv, 1–3, 13, 28 Broker Noeud d’un cluster Kafka. 12 Cluster Ferme ou grappe de serveurs. 12–14 DataStream Flux de données. 19 EBITDA Earnings Before Interests, Taxes, Depreciation and Amortization. Désigne communé- ment les revenus d’une entreprise avant soustraction des intérêts, impôts, dotations aux amor- tissements et provisions sur immobilisations. 7 Failover La capacité d’un équipement à basculer automatiquement vers un réseau alternatif ou en veille. 13 Gateway Une passerelle permettant de relier deux réseaux distincts présentant une topologie différente. 11 Internet des Objets Infrastructure dédiée à la société de l’information, qui permet de disposer de services évolués en interconnectant des objets grâce aux technologies la communication. iii, 2, 10 Log Un fichier permettant de stocker un historique des événements attachés à un processus. 1, 2, 15 MapReduce Un patron d’architecture de développement informatique permettant d’effectuer des calculs parallèles et distribués sur des données potentiellement très volumineuses. 15, 18, 23 Topic Sujet Kafka, composé de partitions répliquées dans lesquelles des messages sont stockés. 3, 12, 16, 17, 19–21 Workflow Une suite de tâches ou opérations effectuées pour la réalisation d’un processus métier. vii, 3, 18–23, 25, 26, 28 Zookeeper Coordinateur d’applications, très utile pour les systèmes distribués. 19 xi
  40. 40. Bibliographie Formations [1] Cloudera data analyst training : Using pig, hive, and impala with hadoop. http://www.cloudera. com/training/courses/data-analyst-training.html. [2] Unlock value in massive datasets. https://www.coursera.org/specializations/big-data. Livres [3] Jonathan Seidman Gwen Shapira Mark Grover, Ted Malaska. Hadoop Application Architectures Designing Real-World Big Data Applications. O’Reilly Media, Juin 2015. [4] Tom White. Hadoop : The Definitive Guide 4th Edition - Storage and Analysis at Internet Scale. O’Reilly Media, Mars 2015. Sites Internet [5] Documentation officielle d’apache flink. http://flink.apache.org/. [6] Documentation officielle d’apache kafka. http://kafka.apache.org/documentation.html. [7] Emmanuelle Boudgourd. Lancement du 1er réseau lora. https://www.corporate.bouyguestelecom. fr/press-room/lancement-du-1er-reseau-lora-dedie-a-linternet-des-objets/, 2015. [8] Mohamed Amine Abdessemed. Stream processing at bouygues telecom with apache flink. http: //data-artisans.com/flink-at-bouygues.html, 2015. [9] Robert Metzger et Kostas Tzoumas. Kafka + flink : A practical, how-to guide. http://data-artisans. com/kafka-flink-a-practical-how-to/, 2015. Documents [10] Présentations institutionnelles de bouygues telecom, (document interne), 2016. xii
  41. 41. Annexes 1 { 2 "LNS_UplinkData" : { 3 "LNS_FormatVersion" : 1, 4 "LNS_AppEUI" : "AQIDBAUGBwg=", 5 "LNS_DevEUI" : "AQIDBAUGBwg=", 6 "LNS_ExpirationDate" : 1433169218776, 7 "APP_CommandID" : 1234567890, 8 "LORA_DevAddr" : "AQIDB=", 9 "LORA_FCntDown" : 123, 10 "LORA_FPort" : 1, 11 "LORA_FRMPayload" : "AQIDBAUGBwgJCgsMDQ4PEBESExQ=" 12 } 13 } Listing 1 – Exemple de message UplinkData 1 { 2 "LNS_DownlinkReport" : { 3 "LNS_FormatVersion" : 1, 4 "LNS_AppEUI" : "AQIDBAUGBwg=", 5 "LNS_DevEUI" : "AQIDBAUGBwg=", 6 "LNS_DeliveryErrorCode" : "NoError", 7 "APP_CommandID" : 1234567890, 8 "CRM_ClientID" : "ClientIDValue", 9 "CRM_DeviceID" : "DeviceIDValue", 10 "CRM_KeyManagerID" : "LNSInternalKMS", 11 "CRM_Custom1" : "Custom1Value", 12 "CRM_Custom2" : "Custom2Value", 13 "CRM_Custom3" : null, 14 "CRM_Custom4" : null, 15 "CRM_Custom5" : null, 16 "GTW_Timestamp" : 1433170088112, 17 "LORA_FCntDown" : 123 18 } 19 } Listing 2 – Exemple de message DownlinkReport xiii
  42. 42. 1 { 2 "LNS-UplinkLog" : { 3 "LNS-FormatVersion" : 1, 4 "LNS-AppEUI" : "AQIDBAUGBwg=", 5 "LNS-DevEUI" : "AQIDBAUGBwg=" 6 "LNS-AppNonce" : "AQID", 7 "LNS-DevNonce" : "AQI=", 8 "LNS-NetID" : "AQID", 9 "LNS-ServerID" : "LORADATA_FE_SERVER", 10 "LNS-RemoteIPAddress" : "192.168.0.1", 11 "LNS-ServerTimestamp" : 1433170088112, 12 "LNS-FrameErrorCode" : "NoError", 13 "LNS-RequestedDataRate" : "SF12_BW_125", 14 "LNS-RequestedTxPower" : "DBM_20", 15 "LNS-RequestedNbRep" : 1, 16 "CRM-ClientID" : "ClientIDValue", 17 "CRM-DeviceID" : "DeviceIDValue", 18 "GTW-Frequency" : 868.5, 19 "GTW-Channel" : 2, 20 "GTW-Modulation" : "LORA", 21 "GTW-DataRate" : "SF12_BW_125", 22 "GTW-CodingRate" : "CR_4_5", 23 "GTW-RSSI" : -80.0, 24 "GTW-LoRaSNR" : 1.2, 25 "GTW-TimestampISO" : "2015-03-09T11:10:17.123456789Z", 26 "GTW-TimePrecision" : 1, 27 "GTW-GatewayType" : "GatewayTypeValue", 28 "GTW-GatewayID" : "LORA_GTW_06201500002", 29 "GTW-GatewayModemID" : "1", 30 "GTW-Antenna1Longitude" : 0.0, 31 "GTW-Antenna1Latitude" : 0.0, 32 "GTW-Antenna1Altitude" : 0.0, 33 "GTW-Antenna2Longitude" : 0.0, 34 "GTW-Antenna2Latitude" : 0.0, 35 "GTW-Antenna2Altitude" : 0.0, 36 "LORA-PHYPayloadSize" : 16, 37 "LORA-MType" : "UNCONFIRMED_DATA_UP", 38 "LORA-MajorVersion" : 0, 39 "LORA-DevAddr" : "AQIDB=", 40 "LORA-ADR" : false, 41 "LORA-ADRACKReq" : false, 42 "LORA-ACK" : false, 43 "LORA-FCntUp" : 4, 44 "LORA-FPort" : 11, 45 "LORA-FRMPayloadSize" : 3 46 } 47 } Listing 3 – Exemple de message UplinkLog et UplinkLogForeign xiv
  43. 43. 1 { 2 "LNS_DownlinkLog" : { 3 "LNS_FormatVersion" : 1, 4 "LNS_AppEUI" : "AQIDBAUGBwg=", 5 "LNS_DevEUI" : "AQIDBAUGBwg=", 6 "LNS_AppNonce" : "AQID", 7 "LNS_DevNonce" : "AQI=", 8 "LNS_NetID" : "AQID", 9 "LNS_ServerID" : "LORADATA_FE_SERVER", 10 "LNS_RemoteIPAddress" : "192.168.0.1", 11 "LNS_ServerTimestamp" : 1433169218778, 12 "LNS_FrameErrorCode" : "NoError", 13 "CRM_ClientID" : "ClientIDValue", 14 "CRM_DeviceID" : "DeviceIDValue", 15 "GTW_Frequency" : 0.0, 16 "GTW_Modulation" : "LORA", 17 "GTW_DataRate" : "SF12_BW_125", 18 "GTW_CodingRate" : "CR_4_5", 19 "GTW_TxPower" : 0, 20 "GTW_Timestamp" : 1433169218776, 21 "GTW_GatewayID" : "LORA_GTW_06201500002", 22 "GTW_GatewayModemID" : "1", 23 "LORA_PHYPayloadSize" : 16, 24 "LORA_MType" : "UNCONFIRMED_DATA_DOWN", 25 "LORA_MajorVersion" : 0, 26 "LORA_DevAddr" : "AQIDB=", 27 "LORA_ADR" : false, 28 "LORA_ADRACKReq" : false, 29 "LORA_ACK" : false, 30 "LORA_Fpending" : false, 31 "LORA_FCntDown" : 4, 32 "LORA_FPort" : 11, 33 "LORA_RMPayloadSize" : 3 34 } 35 } Listing 4 – Exemple de message DownlinkLog 1 #!/bin/bash 2 while read line 3 do 4 echo "Table: $line" 5 eval "hive -e -S ’use loradb; select count(*) from $line’" 6 done Listing 5 – script_count.sh xv
  44. 44. 1 /** @author wzeghdao <wzeghdao@bouyguestelecom.fr> */ 2 public class Application { 3 public static void main (String... args){ 4 5 // La collecte des messages bruts (LNS_OUTPUT) 6 FlinkKafkaConsumer081<String> kafkaSource = new FlinkKafkaConsumer081( 7 sourceProps.getProperty(Constants.PROP_INPUT_TOPIC), 8 new SimpleStringSchema(), sourceProps); 9 10 // L’enrichissement des messages 11 environment.addSource(kafkaSource).flatMap(new LoraEnrichment 12 (jobConfig)).addSink(new LoraKafkaSink (sinkProps, jobConfig)); 13 } 14 } Listing 6 – Corps de l’application «Kafka2Kafka» 1 /** @author wzeghdao <wzeghdao@bouyguestelecom.fr> */ 2 public class Application { 3 public static void main (String... args){ 4 // La collecte des messages enrichis (LNS_OUTPUT_ENRICHED) 5 FlinkKafkaConsumer081<String> kafkaSource = new FlinkKafkaConsumer081( 6 sourceProps.getProperty(Constants.PROP_INPUT_TOPIC), 7 new SimpleStringSchema(), sourceProps); 8 9 // Le stockage des messages enrichis sur HDFS 10 Bucketer bucketer = new LoraBucketer(); 11 RollingSink myHDFS = new RollingSink<>(sinkProps. 12 getProperty( Constants.PROP_SINK_BASE_PATH, 13 "hdfs://localhost:8020/user/wzeghdao/lora/Enriched"), 14 bucketer); 15 source.addSink(myHDFS); 16 } 17 } Listing 7 – Corps de l’application «Kafka2Hdfs» xvi

×