DML - Based - Map Reduce20190911 74762 1m5fgig With Cover Page v2

Accelerat ing t he world's research.
DML based Map-reduce

ahmed boughedda
Related papers Download a PDF Pack of t he best relat ed papers 
Accès sécurisé avec VPN à des services de Syst èmes dist ribués par Clust er Comput ing
Franckie RAJAONARISON
RAPPORT DE STAGE Modélisat ion et int égrat ion de données de capt eurs/compt eurs du SGE par Ines …
bouchra acht oui
Courses big dat a

Laila Najah
Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
Université Hassiba Benbouali de Chlef
Faculté des Sciences Exactes & Informatique
Département de Mathématique et Informatique
Mémoire
Présenté pour l’obtention du diplôme de
MASTER EN INFORMATIQUE
Spécialité : ISIA
Par
AIDOUN Houcine
YACHI Rabia
Thème :
une approche rapide pour la réalisation des opérations des Bases de données
dans les environnements Big DATA
Soutenue le 16/07/2019 devant le jury composé de :
Mme. BELKADHI Khadija Enseignante / UHB-Chlef Président
KELLA Abdelaziz Enseignant / UHB-Chlef Examinateur
HADJ HENNI M’hammed Enseignant/ UHB-Chlef Examinateur
ARRIDJ Mohammed Enseignant/ UHB-Chlef Encadreur
Année Universitaire 2018-2019

Remerciement :
Nous remercions en premier notre
Dieu pour nous avoir donné le courage et la volonté
durant les moments difficiles.
Nous exprimons nos grandes
reconnaissances et vifs remerciements à notre
encadreur le Docteur ARRIDJ Mohammed pour le
temps et l'attention qu'il a bien voulu consacrer au
bon déroulement de ce projet.
Nous exprimons notre profonde
gratitude au Mr. BOUGEDDA Ahmed chef service
chargé du projet Décisionnel au niveau de l’ANEM ,
pour sa disponibilité, ses conseils, ses orientations et
ses encouragements tout au long de ce travail.
Nous remercions également les
membres du jury pour avoir accepté d’évaluer et de
juger ce modeste travail.
Enfin, nous remercions tous ceux qui
de près ou de loin ont bien contribué par leurs
conseils et voulu nous encourager pour que ce travail
puisse être achevé avec succès.
Dédicace :
Je dédie ce travail à mes chers parents que
dieu les garde et les protège, à ma grande famille :
frères et sœurs et leurs enfants. surtout à mes
chers enfants et que je leur souhaite de dieu de
réussir leurs études et leur vie.

Table des matières :
Résumé
Introduction Générale ...............................................................................;……............................................................1
Problématique .......................................................................................;……......................................................2
Organisation du Mémoire...........................................................;…….................................................................4
Chapitre 1: Big Data
1.1 Introduction .....................................................................................................................................................5
1.2 Big Data ...........................................................................................................................................................5
1.2.1 Caractéristiques du BigData ..................................................................................................................... 7
1.2.2 Différence entre BI (Business intelligence) et Big Data…………….………..………………………….8
1.2.3 Architecture Big Data……………..……………………………….……………..…………….………...8

1.2.4 Avantages de l’architecture Big Data………………….…………………….………….………………..9
1.2.5 Big Data et Datawarehouse ………………….…………………………………………….…………….9
1.2.6 Big Data et les ETL (extraction, transformation et chargement)………………………………………..11
1.2.7 Les principales technologies de Big Data …………..……………………………..…….…..………….11

1.2.8 Les Système de Gestion de Bases de Données NoSQL ………………………………….……….….….11
1.2.8.1 Les types des bases NoSQL ……………………….………………………………………………..12

1.2.8.2 Les principales bases de données NoSQL……………………………………………………………14
1.3 Conclusion ...…………………………………………………………………………………………..….…..15
Chapitre 2 : La Plate-forme Hadoop

2.1. Introduction ....................................................................................................................................................16
2.2 Présentation d’Hadoop.....................................................................................................................................16
2.2.1 Le système de fichier distribué d’Hadoop HDFS......................................................... ………………….17
2.2.1.1 Les composantes d’HDFS ........................................................................................................... 18

2.2.1.2 HDFS et tolérance aux fautes ............................................................................................................. 20
2.2.1.3 Lecture et écriture d’un fichier dans HDFS……………………………………..…………………….20
2.2.1.4 Ecriture dans un fichier ou volume HDFS …………………….……………………..…………….21
2.2.2 Le paradigme MapReduce …………………………………………………..…..…………..………....22
2.2.2.1 MapReduce dans Hadoop ……………………………….……………………………………….....23
2.2.2.2 Architecture du Framework MapReduce (purement maître-esclave) ……………………................23

2.2.2.3 Fonctionnement du Framework MapReduce ……………………………….……………………….24
2.2.2.4 Hadoop MapReduce 2.x: YARN…………………….……………………………..…….….………27
2.3 Les outils de Requêtage et de Scripting des données dans Hadoop ...…………………………………..29
2.4 les outils de gestion et de supervision du cluster hadoop……………………………………………..…..30
2.5 Conclusion ……………………………………………………………………………………………….....30
Chapitre 3 : Conception et l’environnement des données
3.1 Introduction ...................................................................................................................................................31
3.2 Les Opérations sur BIGDATA............................................................................................................. ……31
3.2.1 La jointure ……………………………………………………………………….…….........................31
3.2.1.1 Calcul de la jointure par MapReduce........................................................................................... 31
3.2.1.2 Stratégie de jointure........................................................................................................................... 34
3.2.1.3 Synthèse ………………………………………………..…………….……………….…………….35
3.2.2 La sélection ………………………………………..……………………………………..…….……...36

3.2.3 La projection …………..………………………………...…………………………………………... ..37
3.3 Modalisation du system ……………………………………………..…..……………………………….. .38
3.3.1 Jointure de trois relations………………………………………………..…..………………………….. 38
3.3.1.1 Requête SQL Correspond en Map/Reduce ………………………….………....……………………39
3.3.1.2 Cycle des opérations qui réalise la jointure entre Trois table …………………………..………........39
3.3.2 Implémentation de la jointure multi-way ………………………………………………..……….……..41
3.4 Conclusion ……….…………………………………………………………………………..….…...……..41
Chapitre 4 : Mise en œuvre, Test et Evaluation
4.1 Introduction ...................................................................................................................................................42
4.2 L’environnement de travail.......................................................................................................................... 42
4.3 L’environnement de travail........................................................................................................................ 42
4.3.1 Architecture physique.………………………………………..............................................................42
4.3.2 Architecture virtuelle.................................................................................................................. 42

4.3.3 Linux Centos 7............................................................................................................................ 43
4.3.4 Hortonworks HDP...................................................................................................................... .44
4.4 Installation hybride d’Hadoop................................................................................................................... 44
4.4.1 Le mode Fully-Distributed Operation (Multi Node Cluster) ..............................................................44
4.4.2 Le mode Pseudo-Distributed Operation (Multi Node Cluster) ........................................................45
4.5 Plan d’exécution .…………………………….……………….………………………………….….…….47

4.5.1 Lancez les services du cluster en utilisant l’espace Web Ambari…..……………………………….47
4.5.2 Copier les données vers une machine locale …………………….………..……………………….. 48
4.5.3 Transférer ces données vers le cluster HADOOP par le client HDFS……........................................48
4.5.4 Environnement de développement des programmes MapReduce…….…………………………….49
4.5.5 Création des fichiers JAR……………………..……………..…………………………………….. 52
4.6 Test et Evaluation ..…………………………………………………………………………………….….53
4.6.1 La jointure……………………………….…………………………………………………….…......53
4.6.1.1 Explication du schéma d’exécution d’un job MapReduce ………………………………..…...54
4.6.1.2 Affichage du résultat……………………………………….…………………………………..55
4.6.1.3 Interprétation des résultats de jointure …………………………………………………………56
4.6.2 La sélection ...……………………………….……………………………………………….……....57
4.6.3 La projection .……………………………….……………………………………………………….59
4.7 La tolérance de panne ..…………….……………………………………………………………………. 61

4.8 La Haute disponibilité (Hight vailabilty).…………………………………………….………….….........62
4.9 Conclusion ..…………………………………….………….….....................................................................63
Conclusion Génrale ..…………………………...………….…..........................................................................64
Liste des Annexes :
Annexes 1 : Installation de l’Ambari…………………………….….....................................................……65
Annexe 2 : Installation de Cluster HADOOP ……………….….................................................…………78
Annexe 3 : Les classes MapReduce du jointure ……………….…......................................................……83
Annexe 4: Les classes MapReduce du selection ……………….….........................................…………….88
Annexe 5 : Les classes MapReduce du projection……………….…......................................…………….91
Annexe 6 : Configuration VM Linux Centos 7……….………….…......................................…………….94
Références bibliographiques……………………………………………………..……………..…….......…102
Liste des figures :
Figure 1.1: Accroissement du stockage de données entre 2009 et 2020 Digital Universel……................................ 6
Figure 1.2 : Le Big Data, les 3 V………………………………………………………………………......................7
Figure 1.3: Architecture Lambda de Big Data ............................................................................................................ 9
Figure 1.4 : Lien entre Big Data et DW...................................................................................................................... 10
Figure 1.5 : Utilisation d’ETL Informatica pour Big Data. ....................................................................................... 11
Figure 1.6: Paradigme clé / valeur. ............................................................................................................................ 12
Figure 1.7 : Bases documentaires................................................................................................................................13
Figure 1.8 : Bases orientées colonnes. ........................................................................................................................13
Figure 1.9 : Bases orientées graphe. ...........................................................................................................................14
Figure 2.1 : Ecosystème Hadoop................................................................................................................................ 17
Figure 2.2 : L’architecture d’HDFS .......................................................................................................................... 19
Figure 2.3 : Le fonctionnement du Secondary NameNode ....................................................................................... 20
Figure 2.4 : Lecture d'un fichier dans HDFS. ............................................................................................................ 20
Figure 2.5 : Etapes lecture d'un fichier dans HDFS. .................................................................................................. 21
Figure 2.6 : Ecriture d'un fichier dans HDFS .............................................................................................................. 21
Figure 2.7 : Processus d’écriture d'un fichier dans HDFS............................................................................................22
Figure 2.8 : Exemple d’un programme MapReduce (WordCount) .............................................................................23
Figure 2.9 : Schéma de fonctionnement de MapReduce............................................................................................. 25
Figure 2.10 : Communication entre Jobtracker et les Tasktrackers............................................................................. 25
Figure 2.11 : Architecture de YARN............................................................................................................................ 28
Figure 2.12 : Schéma de fonctionnement de MapReduce 2......................................................................................... 29
Figure 3.1 : Algorithme de jointure de deux ensembles de données par Map- Reduce............................................... 32
Figure 3.2.a : Jointure de trois relations par MapReduce............................................................................................. 33
Figure 3.2.b : Jointure de trois relations en un seul job par MapReduce..................................................................... 33
Figure 3.3 :Exemple de jointure par répartition de deux relations................................................................................35
Figure 3.4 : Arbre de décision relatif aux stratégies de jointure .................................................................................. 35
Figure 3.5 : Le model conceptuel de trois relations . ................................................................................................ 38
Figure 3.6 : Le schéma de model relationnel de trois relations.................................................................................. 40
Figure 4.1 : VirtuelBox............................................................................................................................................... 43
Figure 4.2 : LinuxCentos 7……………………………………………………......................................................... 43
Figure 4.3 : Evolution de l’intérêt de recherche Cloudera vs hortonworks.................................................................44
Figure 4.4 : La solution HADOOP exploitée dans le moteur de recherche (elasticsearch) ....................................... 46
Figure 4.4 : Démarrage des services d’HADOOP ………………………………………………………………..…47
Figure 4.5 : Emulateur de terminal Linux pour Windows ……………………………………………………..……48
Figure 4.6 : Environnement de développement des jobs MapReduce ………………………………………............50
Figure 4.7 : Création le fichier Jar de programme ………………………………………………………………..…52

Figure 4.8 : L’exécution du job jointure...................................................................................................................... 54
Figure 4.9 : Déroulement de l’exécution d’un job MapReduce.................................................................................. 55
Figure 4.10 : Affichage du résultat..............................................................................................................................56
Figure 4.11: Temps d’exécution en fonction des configurations du cluster............................................................... 57
Figure 4.12 : L’exécution du job sélection................................................................................................................. 58
Figure 4.13 : Temps d’exécution en fonction des configurations du cluster............................................................. 59
Figure 4.14 : L’exécution du job projection............................................................................................................... 60
Figure 4.15: Temps d’exécution en fonction des configurations du cluster............................................................... 61
Figure 4.16 : Temps d’exécution en fonction du nombre de noeud esclave............................................................. .62
Figure 4.17 : L’état du Namenode secondaire ……………………………………………………………………...62
Résumé :
Dans le monde d’aujourd’hui de multiples acteurs de la technologie numérique produisent des

quantités infinies de données. Capteurs, réseaux sociaux ou e-commerce, ils génèrent tous de l’information qui
s’incrémente en temps-réel selon les 3V de Gartner : en Volume, en Vitesse et en Variabilité.
L’optimisation du temps de traitement des opérations sur les bases de données ont toujours été un
sujet très étudié aussi bien par les développeurs que par les chercheurs. L’apparition des systèmes distribué a
pu guidé les études ainsi que les recherches vers des techniques de résolutions de plus en plus optimales, en
divisant en ensemble de tâches destinées à être réparties sur différents noeuds ou cluster.
Avec l’émergence des applications intensives en manipulation de données, les approches
d’évaluation des opérations réparties basées sur le modèle de program-mation MapReduce ont gagné en
popularité. Néanmoins, ces approches n’évitent pas le problème de déséquilibrage des valeurs de l’attribut
dans la première phase du modèle MapReduce.
Pour répondre à cette question et après une étude des techniques proposées qui traitent les opérations de
base de données (jointure, sélection et projection) avec MapReduce, le présent travail propose une approche
pour équilibrer les charges de traitements sur des différentes machines. Cette approche exploite le mécanisme
de la deuxième version du traitement distribué MapReduce 2.
Mots-clés : MapReduce, Big Data, NoSQL, Hadoop, HDFS.
Introduction Générale
Introduction Générale :
Chaque jour, de plus en plus d'entreprises basculent au numérique, de plus en plus d'informations
commence à être numérisées et le volume des données publiées et stockées augmente. Ceci a conduit à l'âge de
pétaoctets des informations stockées. Une technologie d’émergence, qui gère des quantités de données de très
grandes tailles : le « Big Data ».
Selon Gill PRESS dans un article publié sur Forbes.com le 05 Mai 2013, l’explosion des données est
en effet d’abord perçue comme une menace sur la vie privée. Côté technique l’espace de stockage grandit,
mais les données s’étendent systématiquement jusqu’à le combler.
Dans les années 70, la qualité des données est enfin mise en cause : tout est stocké, il n’est plus utile
de faire le tri.
La montée en puissance des sites Facebook, Linkedin, Amazon et Twitter dans les années 2000 et
plus particulièrement à partir de 2005, révèle tout le potentiel des données publiques disponibles sur internet.
Les succès économiques des grands du web commencent alors à nourrir deux idées principales :
1- Les données brutes accumulées ont une valeur intrinsèque de par les fameuses 3 composantes en V(pour
volume essentiellement mais aussi variété et vitesse de leur production donc leur fraîcheur). Cette valeur
est monétisable et Facebook en est l’illustration par excellence !
2- Ces données brutes ont une autre valeur liée aux analyses et corrélations auxquelles elles s’offrent et
l’information qui en découle participe à la chaîne de valeur de l’entreprise.
La gestion et le stockage de données constituent pour les entreprises les principaux obstacles et défis en
matière de développement de capacités d’analyse détaillée des données[1]. La performance d’un système de
gestion de bases de données est portée essentiellement par le temps dédié au processus d’évaluation des
requêtes, surtout quand il s’agit de grandes quantités de données manipulées. La solution intuitive est
l'utilisation de la puissance de traitement, et en particulier, en exploitant le traitement parallèle.
Les opérations les plus courantes dans l'évaluation des requêtes sont la sélection, la projection et la
jointure qui combine les enregistrements de deux ensembles de données ou plus, généralement sur la base de
certaines conditions.
1
Problématique :
Composé de son système de gestion de fichiers distribués HDFS (Hadoop Distributed File System)
et d’un modèle de traitements parallèles en occurrence le paradigme MapReduce, Hadoop est une plate-
forme qui prend en charge le traitement de grands ensembles de données dans un environnement de calcul
distribué. Conçue pour offrir une évolutivité optimale, cette solution permet aux entreprises de bénéficier
d’un niveau de performances prévisible, à mesure que le volume des ensembles de données (Datasets) à
traiter s’accroît.
Ainsi, Hadoop permet aux organisations de stocker et d’analyser de grand volumes de données,
qu’elles soient structurées ou non, relationnelles ou non. Il vient compléter les plates-formes traditionnelles
d’analyse des données, telles que les bases de données relationnelles. Hadoop améliore les performances de
ces mêmes plates-formes en matière d’analyse SQL interactive des sources de données. Dès lors, Quel est
l’apport de Hadoop dans le cadre de l’analyse Big Data ?
Le Framework MapReduce est associé au système de fichiers distribués(HDFS) pour effectuer le
calcul distribué sur de grandes quantités de données, avec une répartition de la charge sur un grand nombre
de machines et avec un niveau d’abstraction quasi-totale de la couche matérielle. Les entreprises ont
commencé à utiliser MapReduce pour gérer de grandes quantités de données et quand il y a plusieurs
ensembles de données concernées, il y aura toujours un besoin de réaliser la jointure entre ces ensembles de
données. La stratégie de rendre l'information au cœur du métier de l'ANEM, nécessite de mettre en œuvre
une plateforme de gestion de données volumineuses . Durant le plan d'action 2019, la DSI de l'ANEM veux
mettre en place un prototype afin de réalisé un projet pilote basé sur la plateforme de Big-Data où Plusieurs
scénarios sont envisageables :
1-Indexation de données via elasticsearch (stockage et calcul sous Hadoop)

2-Analyse des Log (trafique réseau) via Analytic RealTime
3-Machine Learning pour la recommandation de profil
4-Accès au données structurés et semi-structurée stockée sur Hadoop via la passerelle polybase de sql
server (2016) afin de greffé les données à la plateforme décisionnelle actuelle.
Notre travail est impliqué dans le premier scénario, dont l’objectif est bien de résoudre le problème
de stockage des données massives, réduire le temps d’exécution quelque soit la taille de la données
(scalabilité), assurer la disponibilité des données (réplication). Actuellement, le scénario consiste à indexer
les données relatives aux dispositives DAIP réparties sur le territoire national (48 serveurs) vers une base
de données centrale traitée par moteur de recherche (elasticsearch), ce dernier a pour objet de consulter et
faire des recherches sur les contrats DAIP en basant sur les demandeurs d’emploie, leur métiers et
diplômes.
2
Figure 1 : Shéma d’indexation de données DAIP
La solution proposée est de remplacer la base de données RED par un stockage orienté fichier
distribué d’une part, et d’autre part , l’implémentation des algorithmes de traitement distribué pour accélérer
le processus d’indexation et de recherche. Pour ce faire, nous allons mettre en œuvre une architecture Hadoop
qui contient un system de gestion de fichier HDFS et le système du traitement parallèle YARN (mapreduce
version 2 ) en basant sur la distribution HORTONWORKS .
3
Organisation du Mémoire :
Ce mémoire est organisé en six chapitres :

- Le chapitre1, Big Data :
 Le « BIG DATA » et les caractéristiques de ses données,
 Différence entre BI (Business intelligence) et Big Data
 Architecture Big Data
 Big Data et Datawarehouse
 SGBD NoSQL et ses catégories.
- Le chapitre 2, La Plate-forme Hadoop, nous détaillerons la plateforme Hadoop dans ses deux
principaux volets : le système HDFS et le paradigme MapReduce .
- Le chapitre 3, Conception et l’environnement des données : où nous montrons les
opérations relationnelles déployées sur les données relatives au secteur de l’emploie :
 La jointure ,
 La Sélection,
 La projection.
- Le chapitre 4, Mise en œuvre, Test et Evaluation :
Nous y présentons les résultats des expérimentations effectuées dans le secteur de l’emploie pour
évaluer les opérations réparties, et décrivons l'environnement d'évaluation et les conditions expérimentales,
où nous donnons la configuration matérielle et logicielle de l’environnement.
4
CHAPITRE 1 BIG DATA
Chapitre 1 : Big Data
1.1. Introduction :
Les réseaux d’Internet fournissent une infrastructure pour le stockage des données et facilitent le partage
d’un très grand volume de données via divers moyens de communication. Ce dernier (le partage) est une des
principales clés de succès des applications Web.
Aujourd’hui, beaucoup d’applications Web voient leurs utilisateurs qui croître fortement pour atteindre
des centaines de millions de personnes (en 2012, Facebook atteint plus de 845 millions de membres actifs [3] ).
Face à cette forte demande, les applications Web sont confrontées à un problème de passage à l’échelle. En
particulier, les systèmes de gestion de données atteignent rapidement les limites de la charge qu’ils peuvent
traiter. Cela peut provoquer une dégradation des temps de réponses perçus par l’utilisateur, situation qu’il
n’accepte pas. Pour éviter cela, il est nécessaire d’augmenter les ressources de calcul, de stockage et de
communications utilisées par les applications exploitées.
Pour faire face à l'explosion du volume des données, on parle actuellement de pétaoctet (billiard d’octets)
voir de zettaoctet (trilliard d’octets), un nouveau domaine technologique a vu le jour : le Big Data inventé par les
géants du web, au premier rang comme Yahoo, Google et Facebook, qui ont été les tous premiers à déployer ce
type de technologie.
Ce concept apporte une architecture distribuée et scalable pour le traitement et le stockage de données. Ce
nouveau paradigme a pour principal objectif l’amélioration des performances et l’augmentation de la vitesse
d’exécution des requêtes et des traitements.
1.2. Big Data :
Le Big Data est le phénomène d’émergence de quantités de données hétérogènes et de très grandes tailles.
Ce phénomène est né du contexte actuel caractérisé par la généralisation de l’utilisation d’internet, des réseaux
sociaux et d’appareils générant des données.
Les données créées, répliquées et consommées chaque année dans le monde devraient passer de 898
exabyte(1018) à 6,6 zettabytes(1021) entre 2012 et 2020, soit plus de 25% par an, ce qui signifie qu’ils doublent
environ tous les trois ans [2]. La Figure 1.1 montre la croissance exponentielle des données.
5
CHAPITRE 1 BIG DATA
Figure 1.1 : Accroissement du stockage de données entre 2009 et 2020
Littéralement Big Data est défini comme : « Grosses données » ou « grande quantité de données » ou
« données massives ». C’est une expression anglophone utilisée pour désigner des ensembles de données qui
deviennent tellement volumineux qu'ils en deviennent difficiles à traiter avec des outils classiques de gestion des
grands entrepôts de données. Il s’agit donc d’un ensemble de technologies, d’architecture, d’outils et de
procédures permettant à une organisation très rapidement de capter, traiter et analyser de larges quantités et
contenus hétérogènes et changeants, et d’en extraire les informations pertinentes à un coût accessible.
Ce phénomène est considéré comme l'un des grands défis informatiques de la décennie 2010-2020 . Il
engendre une dynamique importante de la part des spécialistes sur le terrain des technologies informatiques.
Nous pouvons citer, à titre illustratif, quelques exemples de sources de données volumineuses :
 Du Web : journaux d’accès, réseaux sociaux, e-commerce, indexation, stockage de
documents, de photos, de vidéos ;
 De l’internet et des objets communicants : réseaux de capteurs, journaux des appels en
téléphonie ;
 Des sciences : génomique, astronomie, physique subatomique, climatologie,
 De données commerciales (ex : historique des transactions dans une chaîne
d’hypermarchés) ;
 De données personnelles (ex : dossiers médicaux) ;
 De données publiques (open data).
6
CHAPITRE 1 BIG DATA
1.2.1. Caractéristiques du BigData :
Le Big Data (en français "Grandes données") regroupe une famille d'outils qui répondent à une triple
problématiques : C'est la règle dite des 3V. [10]
Figure 1.2 : Le Big Data, les 3 V [16]
 Volume :
Le développement d’Internet conjugué à la production excessive de données par les utilisateurs, ont eu
pour effet l’accélération de l’évolution des volumes de données disponibles. Donc une augmentation
considérable des tailles de données à traiter. Si le volume est un critère majeur du BigData en revanche, son
évaluation est délicate et évolutive.
Selon Eric Schmidt, PDG de Google de 2001 jusqu’à 2011, «il existe 5 millions de téraoctets
d’informations dans le monde et nous n’en avons indexé que 170 téraoctets (c’est-à-dire beaucoup moins de
1%) ». Twitter comme exemple, génère 7 To de données chaque jour.
 Vitesse :
Aujourd'hui, les applications sur Internet tels que les réseaux sociaux, produisent des données en
permanence (flux continu) qui sont difficilement maîtrisables. De tels volumes imposent un traitement
instantané de l’information pour au moins sélectionner celle qui devra être analysée et écarter le reste. Et si
l’activité impose une réaction en temps réel, il devient nécessaire de construire également des systèmes
d'analyse quasiment en temps réel. Le BigData consiste donc à analyser de gros volumes de données dans des
délais très courts qui se rapprochent du temps réel.
 Variété :
La variété représente la gamme de données structurées, semi structurées et non structurées. Le
traitement de gros volumes de données structurées n'est ni récent, ni compliqué. En effet, les entrepôts de
données des banques, des assureurs, des distributeurs et des compagnies de télécommunication sont gérés par
ces derniers depuis plusieurs décennies. Le nouveau problème est de pouvoir analyser un grand volume de
données semi-structurées et/ou non structurées, comme les données sociales (les photos, vidéos, mails,
commentaires et avis des
7
CHAPITRE 1 BIG DATA
internautes sur Facebook ou Twitter par exemple) ou d’une autre provenance comme les sciences de la vie et de
la terre ou la santé...
1.2.2 Différence entre BI (Business intelligence) et Big Data :

La méthodologie BI traditionnel fonctionne sur le principe de regrouper toutes les données de
l’entreprise dans un serveur central (Datawarehouse ou entrepôt de données). Les données sont généralement
analyse en mode déconnecté. Les données sont généralement structurées en SGBDR avec très peu de données
non structurées. [2][5]
Une solution Big Data, est différente d’une BI traditionnel dans les aspects suivants :
- Les données sont conservées dans un système de fichiers distribué et scalable plutôt que sur un serveur
central ;
- Les données sont de formats différents, à la fois structurées ainsi que non structurées ;
- Les données sont analysées en temps réel ;
- La technologie Big Data s’appuie sur un traitement massivement parallèle.
1.2.3 Architecture Lambda de Big Data :

On distingue principalement les couches suivantes :
- Couche Batch (Batch Layer)
- Couche service (Serving Layer)
- Couche temps réel (Realtime Layer) voir figure 1.3 [2]
8
CHAPITRE 1 BIG DATA
Figure 1.3 : Architecture Lambda de Big Data
1.2.4 Avantages de l’architecture Big Data :

Plusieurs avantages peuvent être associés à une architecture Big Data, nous pouvons citer par exemple :
- Evolutivité (scalabilité) : Quelle est la taille que devra avoir votre infrastructure ? Combien
d’espace disque est nécessaire aujourd’hui et à l’avenir ? le concept Big Data nous permet de
s’affranchir de ces questions, car il apporte une architecture scalable.
- Performance : Grâce au traitement parallèle des données et à son système de fichiers
distribué, le concept Big Data est hautement performant en diminuant la latence des requêtes.
- Coût faible : Le principal outil Big Data à savoir Hadoop est en Open Source, en plus on n’aura
plus besoin de centraliser les données dans des baies de stockage souvent excessivement chère,
avec le Big Data et grâce au système de fichiers distribués les disques internes des serveurs
suffiront.
- Disponibilité : On a plus besoin des RAID disques, souvent coûteux. L’architecture Big Data
apporte ses propres mécanismes de haute disponibilité.
1.2.5 Big Data et Datawarehouse :

Datawarehouse est une base de données (données structurées) regroupant une partie ou l’ensemble des
données fonctionnelles d’une entreprise. Il entre dans le cadre de l’informatique décisionnelle ; son but est de
fournir un ensemble de données servant de référence unique, utilisées pour la prise de décisions dans l’entreprise
9
CHAPITRE 1 BIG DATA
par les baies de statistiques et de rapports réalisés via des outils de reporting. D’un point de vue technique, il sert
surtout à ‘délester’ les bases de données opérationnelles des requêtes pouvant nuire à leurs performances. [17]
Les organisations continueront inévitablement à utiliser des entrepôts de données pour gérer le type de
données structurées et opérationnelles qui caractérise les systèmes relationnels(SGBDR). Ces entrepôts seront
toujours fournis aux analystes avec la capacité pour analyser les données clés, les tendances, et ainsi de suite.
Cependant, avec l’avènement du Big Data, le défi pour les entrepôts de données est de réfléchir à une
approche complémentaire avec le Big Data, on pourrait concevoir un modèle hybride. Dans ce modèle les restes
de données optimisées opérationnelles très structurées seront stockées et analysées dans l’entrepôt de données,
tandis que les données qui sont fortement distribuées et non structurées seront contrôlées par Big Data (Hadoop
ou NoSQL). [3][5]
La tendance serait de stocker la grande masse de données non structurées dans une vaste gamme de
serveurs Big Data (Hadoop/MapReduce) pour tirer profit de la scalabilité et la rapidité d’analyse de Big Data,
ensuite à l’aide d’outils, ces données seront déplacées dans le modèle relationnel de sorte qu’elles peuvent être
interrogées avec le langage SQL traditionnel (SGBDR et Datawarehouse).
On peut donc interfacer Big Data avec le Datawarehouse(DW), effectivement les données non
structurées provenant de différentes sources peuvent être regroupées dans un HDFS avant d’être transformées et
chargées à l’aide d’outils spécifiques dans le Datawarehouse et les outils traditionnels de BI. [2][5]
Comme les DW traditionnels ne gèrent pas les données non structurées, Big Data peut servir comme un
moyen de stockage et d’analyse des données non structurées qui seront chargées dans les DW.
Figure 1.4 : Lien entre Big Data et DW [2]
10
CHAPITRE 1 BIG DATA
1.2.6 Big Data et les ETL (extraction, transformation et chargement) :

Certains outils ETL traditionnels comme Talent commence à s’adapter avec le monde Big Data. Les
outils ETL sont utilisés pour transformer les données dans le format requis par l’entrepôt de
données(Datawarehouse). La transformation est effectivement faite dans un endroit intermédiaire avant que les
données ne seront chargées dans l’entrepôt de données.
Pour le Big Data des outils ETL comme Informatica ont été utilisés pour permettre une solution d’ingestion
rapide et flexible des données non structurées (supérieure à 150 Go/jour). [2]
Figure 1.5 : Utilisation d’ETL Informatica pour Big Data [2]
1.2.7 Les principales technologies de Big Data :

Elles sont nombreuses. Pour optimiser les temps de traitement sur des bases de données géantes, plusieurs
solutions peuvent entrer en jeu :
 Des bases de données NoSQL (comme MongoDB, Cassandra ou Redis) qui implémentent des systèmes de
stockage considérés comme plus performants que le traditionnel SQL pour l'analyse de données en masse (orienté
clé/valeur, document, colonne ou graphe).
 Des infrastructures de serveurs pour distribuer les traitements sur des dizaines, centaines, voire milliers
de noeuds. C'est ce qu'on appelle le traitement massivement parallèle. Le Framework Hadoop est sans doute le
plus connu d'entre eux. Il combine le système de fichiers distribué HDFS, la base NoSQL HBase et l'algorithme
MapReduce.
1.2.8 Les Système de Gestion de Bases de Données NoSQL :
Les bases de données NoSQL (No-SQL ou Not Only SQL) sont un sujet très à la mode en ce moment. Le
terme NoSQL désigne une catégorie de systèmes de gestion de base de données destinés à manipuler des bases de
données volumineuses pour des sites de grande audience. NoSql peut être interprété comme le refus du langage
11
CHAPITRE 1 BIG DATA
SQL mais au lieu de NoSQL, il serait plus juste d’utiliser l’appellation NoRDBMS (Not Only Relational
DataBase Management System). En effet, ce ne sont pas les langages SQL qui sont rejetés mais plutôt les
systèmes de gestion de base de données classiques SGBDR/RDBMS.
Les bases données NoSQL sont scalables, elles permettent de traiter les données d’une façon distribuée.
Parmi les avantages du NoSQL on trouve :
- Leurs performances ne s’écroulent jamais quel que soit le volume traité. Leur temps de réponse est
proportionnel au volume ;
- Elles se migrent facilement. En effet, contrairement aux SGBDR classiques, il n’est pas nécessaire de
procéder à une interruption de service pour effectuer le déploiement d’une fonctionnalité impactant les
modèles des données ;
- Elles sont facilement scalable. A titre d’exemple, le plus gros cluster de NoSQL fait 400 To, tandis
qu’Oracle sait traiter jusqu’à une vingtaine de Téraoctet (pour des temps de réponse raisonnable).
1.2.8.1 Les types des bases NoSQL : Il en existe 4 types distincts qui s'utilisent différemment et qui se prêtent
mieux selon le type données que l'on souhaite y stocker.
 Paradigme clé/valeur : Les BD NoSQL fonctionnant sur le principe Clé-Valeur sont les plus
basiques que l'on peut trouver :
- Elles fonctionnent comme un grand tableau associatif et retourne une valeur dont elle ne
connaît pas la structure ;
- Leur modèle peut être assimilé à une table de hachage (hashmap) distribuée ;
- Les données sont simplement représentées par un couple clé/valeur ;
- La valeur peut être une simple chaîne de caractères, ou un objet sérialisé.
Figure 1.6 : Paradigme clé / valeur.
12
CHAPITRE 1 BIG DATA
 Document : Elles sont basées sur le modèle « clé-valeur » mais la valeur est un document en format
semi-structuré hiérarchique de type JSON ou XML (possible aussi de stocker n'importe quel objet, via
une sérialisation). Elles stockent une collection de "documents" .
Figure 1.7 : Bases documentaires
 Colonnes : Les données sont stockées par colonne, non par ligne, on peut facilement ajouter des
colonnes aux tables, par contre l'insertion d'une ligne est plus coûteuse quand les données d'une
colonne se ressemblent, on peut facilement compresser la colonne.
C’est un modèle proche d’une table dans un SGBDR mais ici le nombre de colonnes:
- Est dynamique ;
- Peut varier d’un enregistrement à un autre, ce qui évite de retrouver des colonnes ayant
des valeurs NULL.
Figure 1.8 : Bases orientées colonnes.
13
CHAPITRE 1 BIG DATA
 Paradigme graphe : Ce paradigme est le moins connu de ceux de la mouvance NoSQL. Ce modèle
s’appuie Elles permettent la modélisation, le stockage et la manipulation de données complexes liées
par des relations non-triviales ou variables :
- modèle de représentation des données basé sur la théorie des graphes ;
- s’appuie sur les notions de noeuds, de relations et de propriétés qui leur sont rattachées.
décrire les arcs (relations entre les objets), ceux-ci étant orientés et disposant de propriétés
(nom, date..).
Figure 1.9 : Bases orientées graphe.
1.2.8.2 Les principales bases de données NoSQL :
 MongoDB :
La plus populaire des bases NoSQL documentaires est écrite en C et n’utilise pas de machine
virtuelle JAVA. Cette base est idéale pour débuter car elle est à la fois polyvalente et simple. [18]
 Cassandra :
Cassandra est le projet open source qui découlent de la technologie de stockage Facebook. À
l’origine, elle a été écrite spécifiquement pour répondre à la croissance explosive de cette entreprise.
Cassandra est une base de données en colonnes écrite en JAVA. [18]
 HBase :
Hbase est inspirée des publications de Google sur BigTable. Comme BigTable, elle est une base de
données oriente colonne. Basée sur une architecture maitre/esclave, les bases de données HBase sont
capables de gérer d’énormes quantités d’informations (plusieurs milliards de lignes par table). [5]
14
CHAPITRE 1 BIG DATA
1.3. Conclusion :
Le phénomène du Big Data s’est façonné en 2011, mais a connu une croissance fulgurante en 2012,
modifiant partiellement, mais d’une façon drastique, tous les aspects de la gestion des données. Les systèmes de
Big Data ont ainsi entrainé des changements dans les méthodes de gestion et de traitements des données, dans
les opérations d’extraction (ETL). L’apparition de ces nouveaux paradigmes a entraîné des changements majeurs
dans la manière d’aborder la conception des applications et leur rapport à la base.
Pourtant, à l’aube de 2013, aucune des technologies Big Data ne semblent être plus actives que les bases
de données NoSQL et le Framework Hadoop. Et, surtout, leur marge de progression semble aujourd’hui presque
sans limites.
Ainsi, les technologies NoSQL et Hadoop semblent être les deux moyens clés pour prendre en charge
les données non-structurées. Comme le montre Apache Hadoop, ces technologies ont souvent des racines liées à
l’Open Source, et sont entrées très récemment dans le monde commercial.
Dans le chapitre suivant, nous détaillons une technique de programmation distribuée très utilisée dans le
milieu NoSQL, en l’occurrence MapReduce du Framework Hadoop.
15
CHAPITRE 2 La Plate-forme Hadoop
2.1. Introduction :
Pour que les entreprises tirent pleinement profit de leurs informations, la gestion des données
volumineuses, la gestion de la croissance des données, l’approvisionnement du stockage et la réalisation
d’analyses « Big data » rapides et fiables constituent, des priorités.
La plate-forme émergente Hadoop est l’une des solutions récemment adoptée par les entreprises afin de
répondre à leurs besoins d’analyse Big Data. Conçue pour de gestion de données et de traitements distribués et
offrir une évolutivité optimale, cette solution permet aux entreprises de bénéficier d’un niveau de performances
prévisibles, à mesure que le volume des données à traiter/analyser s’accroît.
Hadoop est un Framework Java open source d'Apache, qui prend en charge le traitement de grands
ensembles de données dans un environnement de calcul distribué. Il fait partie du projet Apache parrainé par
l'Apache Software Fondation1. Aussi, il permet d'exécuter des applications sur les systèmes avec des milliers de
noeuds impliquant des milliers de Téra-octets. Son système de fichiers distribué facilite le transfert de données
rapide entre les nœuds .
2.2 Présentation d’Hadoop :
Le Framework Hadoop créé par Doug Cutting en 2009 (projets de la fondation Apache) est utilisé par
les principaux acteurs tels que Google, Amazon, Yahoo, Facebook, eBay et IBM, en grande partie pour des
applications impliquant des moteurs de recherche (l’analyse des requêtes) et la publicité (l’analyse des logs).
Hadoop est caractérisé par :
Robuste : si un nœud de calcul tombe, ses tâches sont automatiquement réparties sur d’autres
nœuds. Les blocs de données sont également répliqués;
Coût : il optimise les coûts via une meilleure utilisation des ressources présentées;
 Souple : car il répond à la caractéristique de variété des données en étant capable de traiter
différents types de données;
Virtualisation : ne plus se reposer directement sur l’infrastructure physique (baie de stockage
coûteuse), mais choisir la virtualisation de ses clusters Hadoop.
Trois principales distributions Hadoop sont aujourd’hui disponibles : Cloudera, Hortonworks, MapR. Nous
allons présenter deux concepts fondamentaux d'Hadoop à savoir :
- HDFS un système de fichier qui répartit les données sur de nombreuses machines,
- YARN un mécanisme d’ordonnancement de programmes de type MapReduce.
16

Hadoop contient de nombreux sous-projets qui relèvent de la même catégorie de l'informatique distribuée
et du traitement de données à grande échelle. L'écosystème Hadoop est composé des principaux composants
représentés dans la Figure 2.1 mais il n’est pas limité à cette liste, l'écosystème est construit à une vitesse très
rapide et de nouveaux projets lui sont ajoutés [16] .
Figure 2.1 : Ecosystème Hadoop
2.2.1 Le système de fichier distribué d’Hadoop HDFS :

Quand les tailles des ensembles de données manipulées (Dataset) dépassent largement la capacité de
stockage d'une seule machine physique, il serait nécessaire de les partager à travers un réseau de machines créant
ainsi un système de fichiers distribués.
Hadoop utilise un système de fichiers virtuel qui lui est propre : le HDFS (Hadoop Distributed File
System). HDFS est un système de fichier distribué, extensible et portable inspiré par le Google File System
(GFS).
Il a été conçu pour stocker de très gros volumes de données sur un grand nombre de machine équipées
de disques durs banalisés, il permet de l’abstraction de l’architecture physique de stockage, afin de manipuler un
système de fichier distribué comme s’il s’agissait d’un disque dur unique. [19]
Toutefois, HDFS se démarque d'un système de fichiers classique pour les principales raisons suivantes [15]:
 HDFS n'est pas dépendant du noyau du système d'exploitation. Il assure une portabilité et peut
être déployé sur différents systèmes d'exploitation;
 HDFS est un système distribué sur un système classique, la taille du disque est généralement
considérée comme la limite globale d'utilisation. Dans HDFS, chaque noeud d'un cluster
correspond à un sous-ensemble du volume global des données du cluster. Pour augmenter ce
17
volume global, il suffira d'ajouter de nouveaux noeuds. On retrouvera également dans HDFS, un
service central appelé NameNode qui aura la tâche de gérer les métadonnées ;
 HDFS utilise des tailles de blocs largement supérieures à ceux des systèmes classiques. Par
défaut, la taille est fixée à 64 Mo. Il est toutefois possible de monter à 128 Mo, 256 Mo, 512 Mo
voire 1 Go. L'intérêt de fournir des tailles plus grandes permettant de réduire le temps d'accès à un
bloc. Notez que si la taille du fichier est inférieure à la taille d'un bloc, le fichier n'occupera pas la
taille totale de ce bloc ;
 HDFS fournit un système de réplication des blocs dont le nombre de réplications est configurable.
Pendant la phase d'écriture, chaque bloc correspondant au fichier est répliqué sur plusieurs
noeuds. Pour la phase de lecture, si un bloc est indisponible sur un noeud, des copies de ce bloc
seront disponibles sur d'autres noeuds.
Hadoop est caractérisé par une architecture maître-esclave où le maître HDFS est le NameNode et les
esclaves HDFS sont les DataNodes. Ces deux agents principaux composent ce système de fichiers :
2.2.1.1 Les composantes d’HDFS :
 Le NameNode qui se caractérise par :
- Responsable de la distribution et de la réplication des blocs ;
- Serveur d’informations du Hdfs pour le client Hdfs ;
- Stocke et gère les métadonnées ;
- Comporte la liste des blocs pour chaque fichier (dans le cas de lecture) ;
- Contient la liste des DataNodes pour chaque bloc (dans le cas de l’écriture) ;
- Logs toute métadonnée et toute transaction sur un support persistant ;
- Démarre à partir d’une image d’HDFS (fsimage).
 Les DataNodes qui se caractérise par :
- Stocke des blocs de données dans le système de fichier local ;
- Serveur de bloc de données pour le client hdfs ;
- Heartbeat avec le Namenode : Heartbeat est système permettant sous Linux la
mise en clusters de plusieurs serveurs pour effectuer entre eux un processus de
tolérance de panne. Le processus Heartbeat se chargera de passer un message-
aller vers le NameNode indiquant : son identité, sa capacité totale, son espace
utilisé, son espace restant.
La Figure 2.2 illustre la méthode de stockage de deux fichiers qui sont décomposé en blocs où chaque
bloc est répliqué trois (02) fois. Chaque répliqua d’un bloc est stocké dans un DataNode différent des autres
répliquas du bloc.
18
Figure 2.2 : L’architecture d’HDFS [21]
 Secondary NameNode : Le NameNode dans l'architecture Hadoop est un point unique de

défaillance. Si ce service est arrêté, il n'y a pas moyen de pouvoir extraire les blocs d'un fichier
donné. Pour résoudre ce problème, un NameNode secondaire appelé Secondary NameNode a
été mis en place dans l'architecture Hadoop. Son rôle consiste à :
- Télécharger régulièrement les logs sur le NameNode ;
- Crée une nouvelle image en fusionnant les logs avec l’image HDFS ;
- Renvoie la nouvelle image au NameNode. [9]
 Mode high availabilitye (haute disponibilité) :
Comme le namenode est absolument vital pour HDFS mais unique, Hadoop propose une
configuration appelée high availability dans laquelle il y a 2 autres namenodes en secours,
capables de prendre le relais instantanément en cas de panne du namenode initial.
Les namenodes de secours se comportent comme des clones. Ils sont en état d’attente et mis à jour
en permanence à l’aide de services appelés JournalNodes.
Les Namenodes de secours font également le même travail que le secondary namenode,
d’archiver régulièrement l’état des fichiers, donc ils rendent ce dernier inutile.
19
Figure 2.3 : Fonctionnement du Secondary NameNode [9]
2.2.1.2 HDFS et tolérance aux fautes : Pour éviter un crash du DataNode la solution serait :
- Plus de Heartbeat (détection par le NameNode) ;
- Plus de réplication distribuée (robustesse des données) ;
Dans le cas d’un crash du NameNode (voir Figure 2.3) :
- Sauvegarde des logs de transaction sur un support stable ;
- Redémarrage sur la dernière image du hdfs.
2.2.1.3. Lecture et écriture d’un fichier dans HDFS :
Pour la lecture d’un bloc dans HDFS, le client HDFS interroge le NameNode pour récupérer la liste des
DataNodes hébergeant ses différents répliquas, le client lit ensuite le bloc du DataNode, et s’il y a un problème
avec le bloc, il lit le bloc d’un autre DataNode. Le client lit le plus proche répliqua . Voir la Figure 2.4 et 2.5 .
Figure 2.4 : Lecture d'un fichier dans HDFS. [3]
20
Figure 2.5 : Etapes lecture d'un fichier dans HDFS. [15]
2.2.1.4 Ecriture dans un fichier ou volume HDFS : Pour écrire un fichier au sein d’HDFS:
Etape 1 : On va utiliser la commande principale de gestion de Hadoop: Hadoop, avec l'option fs.
Admettons qu'on souhaite stocker le fichier data.txt sur HDFS.
Etape 2 : Le programme va diviser le fichier en blocs de 64KB (ou autre, selon la configuration) –
supposons qu'on ait ici 3 blocs.
Etape 3 : Le NameNode lui indique les DataNodes à contacter.
Etape 4 : Le client contacte directement le DataNode concerné et lui demande de stocker le bloc.
Etape5 : les DataNodes s'occuperont – en informant le NameNode – de répliquer les données entre
eux pour éviter toute perte de données.
Etape 6 : Le cycle se répète pour le bloc suivant.
Figure 2.6 : Ecriture d'un fichier dans HDFS . [3]
21
Figure 2.7 : Processus d’écriture d'un fichier dans HDFS . [15]
2.2.2. Le paradigme MapReduce :

MapReduce est un modèle de programmation proposé par Google. L’objectif est de traiter de manière
parallèle de grandes quantités de données aux seins d’un cluster de noeuds. Il est conçu pour la scalabilité et la
tolérance aux pannes.. Il est conçu pour la scalabilité et la tolérance aux pannes.
Le modèle de programmation fournit un cadre à un développeur afin d'écrire une fonction Map et une
fonction Reduce. Tout l'intérêt de ce modèle de programmation est de simplifier la vie du développeur.
Ainsi, ce développeur n'a pas à se soucier du travail de parallélisation et de distribution du travail.
MapReduce permet au développeur de ne s'intéresser qu'à la partie algorithmique. [15]
Un programme MapReduce peut se résumer à deux fonctions Map () et Reduce () :
 La première, MAP, va transformer les données d'entrée en une série de couples clef /valeur. Elle
va regrouper les données en les associant à des clefs, choisies de telle sorte que les couples
clef/valeur aient un sens par rapport au problème à résoudre. Par ailleurs, cette opération doit être
parallélisable: on doit pouvoir découper les données d'entrée en plusieurs fragments, et faire
exécuter l'opération MAP à chaque machine du cluster sur un fragment distinct. La fonction Map
s'écrit de la manière suivante : Map (clé1, valeur1) → List (clé2, valeur2).
 La seconde, REDUCE, va appliquer un traitement à toutes les valeurs de chacune des clefs
distinctes produite par l'opération MAP. Au terme de l'opération REDUCE, on aura un résultat
pour chacune des clefs distinctes. Ici, on attribuera à chacune des machines du cluster une des
clefs uniques produites par MAP, en lui donnant la liste des valeurs associées à la clef. Chacune
des machines effectuera alors l'opération REDUCE pour cette clef. La fonction Reduce s'écrit de
la manière suivante :
Reduce (clé2, List (valeur2)) → List (valeur2).
22
L’exemple classique est celui du WordCount qui permet de compter le nombre d’occurrences d’un mot
dans un fichier. En entrée l'algorithme reçoit un fichier texte qui contient les mots suivants : voiture la le elle de
elle la se la maison voiture ,dans notre exemple, la clé d'entrée correspond au numéro de ligne dans le fichier et
tous les mots sont comptabilisés à l'exception du mot « se » dont le résultat de la fonction Map est donné comme
suite :
(voiture, 1) /(la,1) /(le,1) / (elle,1) / (de,1) / (elle,1) / (la,1) / (la,1) / (maison,1) / (voiture,1)
Avant de présenter la fonction Reduce, deux opérations intermédiaires doivent être exécutées pour
préparer la valeur de son paramètre d'entrée. La première opération appelée shuffle permet de grouper les valeurs
dont la clé est commune. La seconde opération appelée sort permet de trier par clé. A la différence des fonctions
Map et Reduce, shuffle et sort sont des fonctions fournies par le Framework Hadoop, donc, il n’a pas à les
implémenter. Ainsi, après l'exécution des fonctions shuffle et sort le résultat de l'exemple est le suivant :
(de, [1]) / (elle, [1,1]) / (la, [1, 1,1]) / (le, [1]) / (maison, [1]) / (voiture, [1,1]
Suite à l'appel de la fonction Reduce, le résultat de l'exemple est le suivant :
(de, 1) / (elle, 2) / (la, 3) / (le, 1) / (maison, 1) / (voiture, 2)
Figure 2.8 : Exemple d’un programme MapReduce (WordCount) [15]
2.2.2.1.MapReduce dans Hadoop : Il existe Deux versions notables du MapReduce :

 Version 0.x et 1.x : architecture purement maître-esclave ;
 Version 2.x YARN : architecture maître-esclave à deux niveaux (Stable depuis oct. 2013). [9]
2.2.2.2 Architecture du Framework MapReduce (purement maître-esclave) : Le MapReduce possède une

architecture maître-esclave :
 Le maître MapReduce : le JobTracker ;
 Les esclaves MapReduce : les TaskTracker ;
23
1. Le JobTracker : C’est un processus qui fait la liaison entre l’application (le client) et Hadoop.
Une fois que le code est soumis au cluster, le JobTracker détermine le plan d'exécution en
déterminant quels répertoires de données à traiter, assigne à des nœuds (TaskTrackers) différentes
tâches et surveille toutes les tâches durant leur fonctionnement. Si une tâche échoue, le JobTracker
relancera automatiquement la tâche, probablement sur un nœud différent, jusqu'à une limite
prédéfinie des tentatives :
- Gère l’ensemble des ressources du système ;
- Reçoit les jobs des clients ;
- Ordonnance les différentes tâches des jobs soumis ;
- Assigne les tâches aux TaskTrackers ;
- Réaffecte les tâches défaillantes ;
- Maintient des informations sur l’état d’avancement des jobs. [9]
2.Un TaskTracker : Une responsabilité du TaskTracker est de communiquer constamment avec le

JobTracker. Si ce dernier ne reçoit pas de rapports d'un TaskTracker dans une période spécifique,
il supposera que le TaskTracker s'est brisé et resoumettra les tâches correspondantes à d'autres
noeuds dans le cluster. Les fonctionnalités du Tasktracker sont les suivantes :
- Exécute les tâches données par le Jobtracker ;

- Exécution des tâches dans une autre JVM (Child) ;
- A une capacité en termes de nombres de tâches qu’il peut exécuter ;
- Heartbeat avec le JobTracker. [9]
2.2.2.3 Fonctionnement du Framework MapReduce : L’exécution d’un job MapReduce, concerne quatre
entités indépendantes :
 Le client, qui soumet le job MapReduce;
 Le JobTracker, qui coordonne l'exécution et le partage du job en sous tâches. Le Jobtracker est
une application Java dont la classe principale est JobTracker;
 Les TaskTrackers, qui gèrent les tâches que le JobTracker lui a confiées. Les Tasktrackers sont
des applications Java dont la classe principale est TaskTracker;
 Le système de fichiers distribué, qui est utilisée pour le partage de fichiers de travail entre les autres
entités (Tasktrackers). [4][5]
24
Figure 2.9 : Schéma de fonctionnement de MapReduce [5]
Figure 2.10 : Communication entre Jobtracker et les Tasktrackers [24]
25
L’exécution de MapReduce se fait selon la démarche suivante :

1- Lancement du job :
Le processus de lancement du job est établi par JobSummitter qui effectue les opérations suivantes (étape 1 de la
figure 2.9) :
 Demande aux JobTrackers l’ouverture d’un nouvel job ID(en appelant getNewJobId () sur
JobTracker) (étape 2 de la figure 2.9) ;
 Vérifie si les fichiers en input et output existent bien, si ce n’est pas le cas il retourne une erreur ;
 Etablit la liste des sous tâches qui seront données aux tasktrackers, et renvoi une erreur en cas de
problème (exemple : fichier de l’input introuvable) ;
 Copie les ressources nécessaires pour exécuter le travail, y compris le fichier JAR (programme
MapReduce) du job, les paramètres de configuration Hadoop (hdfs.xml et core-site.xml) et les sous-
tâches. La copie se fait dans le système de fichiers du JobTracker dans un répertoire nommé d'après
l'ID du job. Le JAR du job est copié avec une réplication haute (contrôlé par le paramètre
Mapred.submit.replication dans le fichier mapred-site.xml, qui est par défaut (10), de sorte qu'il y’est
beaucoup de copies à travers le cluster pour les tasktrackers (étape 3 de la Figure 2.9) ;
 Indique au JobTracker que le job est prêt pour l'exécution en appelant submitJob () sur JobTracker
(étape 4 de la figure 2.9).
2- Initialisation du job : Une fois que le jobtracker exécute le submitJob () les actions suivantes sont
déclenchées :
 Création d'un objet pour représenter le job ou la tâche à exécutée et lance un processus pour garder
une trace de l'état d'avancement du job (étape 5) ;
 Récupération de la liste des sous tâches (input split compute) crées précédemment lors de l’étape3,
récupération du nombre maximum de Reduce tasks crées est déterminé par la variable
Mapred.Reduce.tasks dans {$HADOOP_HOME}/conf/mapred-site.xml(étape 6).
26
3- Affectation des tâches :
 Les TaskTrackers envoient régulièrement des Heartbeat au JobTracker pour lui signifier leurs
disponibilités à exécuter des jobs, si le Jobtracker possède des jobs en fille d’attente il confiera la
tâche au TaskTracker ;(étape 7)
 Après attribution du job au TaskTracker, il commence tout d'abord par localiser le fichier JAR (copié
lors de l’étape 3) en le copiant depuis le système de fichiers partagé. Il copie également tous les
fichiers nécessaires à partir du cache distribué par l'application sur le disque local. (étape 8)
4- Exécution du job : TaskRunner lance une nouvelle machine virtuelle Java (JVM, étape 9) pour exécuter
chaque tâche (étape 10)
2.2.2.4. Hadoop MapReduce 2.x: YARN :
YARN est une évolution de l’architecture d’Hadoop permettant de décharger le Jobtracker qui avait
tendance à cumuler trop de rôles et devenait donc complexe à maintenir et à mettre à l’échelle (scaler). Cette
remise à plat des rôles a permis aussi de découpler Hadoop de Map-Reduce et de permettre à des Framework
alternatifs d’être portés directement sur Hadoop et HDFS et non au-dessus du Map-Reduce. Cependant, une
couche de rétrocompatibilité avec les versions antérieures de Hadoop est maintenue afin de permettre une
migration en douceur pour garantir une meilleure scalabilité. A cet effet, un nouveau composant a été crée dans
l’architecture maître-esclave à deux niveaux par rapport aux architectures précédentes des versions 0.x et 1.x. Le
Yarn ressource manager, coordonne l'attribution des ressources de calcul sur le cluster;
L'idée fondamentale de YARN est de diviser les deux principales responsabilités du
JobTracker/TaskTracker en deux entités distinctes. Voir la Figure 2.11:
 Un ResourceManager global (RM).
 Une ApplicationMaster par application (AM).
 Un NodeManager esclave par nœud (NM).
 Un conteneur par application fonctionnant sur un NodeManager.
Le ResourceManager et le NodeManager forment le nouveau système générique de gestion des
applications de manière distribuée . L’ApplicationMaster par application a la responsabilité de négocier les
conteneurs de ressources appropriée du planificateur, le suivi de leur état et le suivi de leurs progrès. Du point de
vue système, l’ApplicationMaster fonctionne comme un conteneur normal.
27
Figure 2.11 : Architecture de YARN [24].
ResourceManager :
Le ResourceManager (RM) est le maître qui arbitre toutes les ressources disponibles du cluster et qui
permet de gérer les applications distribuées en cours d'exécution sur le système YARN. Il travaille en
collaboration avec les NodeManagers par nœud (NMs) et les ApplicationMasters par application (AMs).
 NodeManagers acceptent les instructions du ResourceManager et gèrent les ressources
disponibles sur un seul nœud.
 ApplicationMasters sont des entités spécifiques responsables de la négociation des ressources
avec le ResourceManager et du travail avec les NodeManagers pour démarrer les conteneurs .
Le ResourceManager a un ordonnanceur qui est responsable de l'allocation des ressources aux
différentes applications en cours d'exécution, selon des contraintes telles que les capacités de la file d'attente et
les limites d'utilisation. Le planificateur exécute sa fonction de planification basée sur les besoins des
applications.
NodeManager :
Le NodeManager (NM) est un agent qui prend en charge les nœuds de calcul individuels dans un
cluster Hadoop. Il est responsable du lancement des conteneurs des applications. Il tient au courant le
ResourceManager (RM), supervise la gestion du cycle de vie des conteneurs, surveille l'utilisation des
ressources (mémoire, CPU, disque, réseau) des conteneurs individuels, suit la santé des nœuds, gère enfin le
journal et les services auxiliaires qui peuvent être exploités par des applications différentes du YARN [25].
28
Figure 2.12 : Schéma de fonctionnement de MapReduce 2. [5]
2.3 Les outils de Requêtage et de Scripting des données dans Hadoop :
 Hive (Facebook) : Hive est à l’origine un projet Facebook qui permet de faire le lien entre le
monde SQL et Hadoop. Il permet l’exécution de requêtes SQL sur un cluster Hadoop en vue
d’analyser et d’agréger les données. Le langage SQL est nommé HiveQL. C’est un langage de
visualisation uniquement, c’est pourquoi seules les instructions de type “Select” sont
supportées pour la manipulation des données. Dans certains cas, les développeurs
doivent faire le Mapping entre les structures de données et Hive. (Voir figure 2.1)
 Pig (Yahoo) : Apportent un modèle de développement de plus haut niveau, et donc beaucoup
plus expressif et simple à appréhender, afin de démocratiser l’écriture de traitements
MapReduce. Pig se rapproche plus d’un ETL où on part d’un ou plusieurs flux de données que
l’on transforme étape par étape jusqu’à atteindre le résultat souhaité. Les différentes étapes de
la transformation sont exprimées dans un langage procédural (Pig Latin).Pig est à l’origine un
projet Yahoo qui permet le requêtage des données Hadoop à partir d’un langage de script.
Contrairement à Hive, Pig est basé sur un langage de haut niveau Pig Latin qui permet de créer
des programmes de type MapReduce. Il ne dispose pas d’interface web, Pig se base sur HDFS
et MapReduce pour exécuter le script en backround (en arrière-plan). (Voir figure 2.1) [5]
29
2.4 Les outils de gestion et de supervision du cluster Hadoop : [5]
 Apache ZooKeeper : ZooKeeper est un service de coordination des services d’un cluster
Hadoop, en particulier, le rôle de ZooKeeper est de fournir aux composants Hadoop les
fonctionnalités de distribution, pour cela il centralise les éléments de configuration du cluster
Hadoop, propose des services de clustérisassions et gère la synchronisation des différents
éléments (événements). ZooKeeper est un élément indispensable au bon fonctionnement de
Hbase. (Voir figure 2.1)
 Apache Ambari (HortonWorks) : Ambari est un projet d’incubation Apache initié par
HortonWorks et destiné à la supervision et à l’administration de clusters Hadoop. C’est un
outil web qui propose un tableau de bord, cela permet de visualiser rapidement l’état d’un
cluster. [5]
Ambari dispose d’un tableau de bord dont le rôle est de fournir une représentation :
- De l’état des services ;
- De la configuration du cluster et des services ;
- De l’exécution des jobs ;
- Des métriques de chaque machine et du cluster. (Voir figure 2.1)
2.5. Conclusion
Ce chapitre a été consacré à l’étude de la plateforme Hadoop, dans lequel nous avons présenté la
plate-forme Hadoop, son mode de fonctionnement et quelques sous projets qui relèvent de la même catégorie
de l'informatique distribuée et du traitement de données à grande échelle. Le fonctionnement de Hadoop se
base sur le système de fichier distribué HDFS et un paradigme Map-Reduce de traitement de données très
volumineuses. HDFS est le système de fichiers distribués utilisé, pour le stockage des données Hadoop. HDFS
a une architecture de type maître/esclave et et est constitué d’un unique NameNode, d’un espace de nom et de
plusieurs DataNodes. HDFS se caractérise par sa grande tolérance aux fautes, sa scalabilité et le fait qu’il soit
conçu pour stocker de très gros volumes de données de manière fiable.
Le modèle MapReduce est aujourd’hui l’un des modèles de programmation parallèle les plus utilisés.
Définissant une architecture Maître-Esclave, dans laquelle s’exécute une succession d’ensembles de tâches
indépendantes, elle permet le traitement parallèle de grandes masses de données. Un des principaux avantages
de ce modèle est sa simplicité. Chaque Job MapReduce soumis par un utilisateur est une unité de travail
composée de données en entrée, des deux fonctions Map et Reduce et d’informations de configuration.
30
Chapitre 3 Conception et l’environnement des données
3.1. Introduction :
Dans le chapitre précédent, nous avons évoqué également quelques travaux traitant ce problème par
l’approche : distribuée. Dans cette partie du mémoire nous présentons les détails de notre travail qui consiste à
proposer des algorithmes de jointure, sélection et projection sur les données volumineuse, puis l’implémentation et
l’expérimentation de cet algorithme basé sur le mécanisme de Mapreduce version 2 .
3.2. Les Opérations sur BIGDATA :
3.2.1 : la jointure :
Avant d’entrée dans les spécifications et méthodes de traitement de cette opération. Envisagez d'abord de
calculer une jointure simple : q (x, y, z) = R (x,y), S (y, z). Cela peut être fait facilement dans un cycle de
communication. Dans la première étape, chaque noeud inspecte son fragment de R, et envoie chaque tuple de la forme
R (a1, b1) au serveur de destination , de même, il envoie chaque tuple S (b2, c2) au serveur . Après ce cycle de
communication, les serveurs calculent la jointure localement et rapportent les réponses. Et voila le cycle générale mais
dans la jointure n’est pas seulement pour un deux ensemble de données, il y a aussi la jointure pour plus de deux
ensemble. Et la même pour deux relation seulement l’opération de jointure va découpe sur plusieurs sous jointure et en
calcule entre eux de façon séquentiel .
3.2.1.1 Calcul de la jointure par MapReduce:
La manière d’évaluation des requêtes dans le contexte des bases de données classiques est différente de celle
utilisée dans un système MapReduce. Les méthodes classiques de réalisation des jointures ne sont plus utilisées, telles
que la jointure par hachage, boucle imbriqué et trie fusion. Les systèmes à base de MapReduce, tels que Hive ,
Hadoop et Pig s’appuient sur des nouveaux algorithmes d’évaluation des requêtes. Dans cette section, nous présentons
une description détaillée de ces algorithmes.
 Jointure de deux ensembles de données (tow-way join) : L’équijointure (tow-way join)
entre deux ensembles de données R(a, b) et S(b, c) est la combinaison des tuples de R et S,
tel que R.b = S.b, avec b est la clé de la jointure. Sous MapReduce, la jointure entre R et S
est calculée par un seul job MapReduce. L’algorithme de calcul de la jointure de deux
ensembles de données (R(a, b) ►◄ S(b, c)) par MapReduce est présenté par la Figure 3.1 .
- Fonction Map : Pour chaque tuple (a, b) de R, la fonction Map produit un
couple clé-valeur (b,(R, a)) et pour chaque tuple (b, c) de S, elle produit un
couple clé-valeur (b,(S, c)). Autrement dit, une collection de processus Map
transforme chaque tuple des deux relations en un couple clé-valeur dont la clé
est la clé de la jointure et la valeur associée est le reste du tuple.
Ensuite, étiqueté chaque tuple par le nom de la relation pour que la fonction
Reduce puisse distinguer la source de données de chaque tuple.
- Fonction Reduce : Le rôle de la fonction Reduce est de combiner les tuples de
R et S ayant la même valeur de b. Ainsi, les tuples qui ont la même valeur de la
clé doivent être envoyé au même processus Reduce par le biais d’une fonction
31
de hachage. Les processus Reduce écrivent les résultats de la jointure (les tuples
(a, b, c)) dans un seul fichier de sortie.
L’algorithme de jointure sur MapReduce est défini comme suit :
Figure 3.1 : Algorithme de jointure de deux ensembles de données par Map- Reduce [34].
 Jointure plus de deux ensembles de données (multi-way join) : La jointure multi-way

implique la jointure de plus de deux ensembles de données. Cette jointure est calculée par
une séquence de jointure tow-way [35]. Supposons la jointure de trois relations R, S et T
(R(a, b) × S(b, c) × T(c, d)) avec des agrégations sur les résultats de la jointure. La plupart
des systèmes basés sur MapReduce transforment cette requête en quatre jobs MapReduce
[36]. Le premier job calcule la jointure de R et S et écrit le résultat U dans le systéme de
fichier. Le deuxième job calcule la jointure de T et U et produit V qui sera aussi écrit dans
le système de fichier (voir la Figure 3.2.a).
Le troisième job calcule des agrégations sur V et si plus d’un Reducer sont utilisés dans
l’étape trois, un quatrième job est utilisé pour fusionner les résultats et écrire les résultats
sous le système de fichier.
Durant l’étape une et deux de la jointure, l’algorithme de la figure 3.1 est utilisé. Une
autre manière de la jointure permet de joindre ces trois relations par un seul job MapReduce
(voir Figure 3.2.b). Les processus Map envoient chaque tuple de R et T à plusieurs
processus Reduce différents, tandis que chaque tuple de S est envoyé à un seul processus
Reduce [35].
32
processus Map envoient chaque tuple de R et T à plusieurs processus Reduce différents, tandis que
chaque tuple de S est envoyé à un seul processus Reduce [35].
Figure 3.2.a : Jointure de trois relations par MapReduce
Figure 3.2.b : Jointure de trois relations en un seul job par MapReduce
33
3.2.1.2 Stratégie de jointure :

On fait référence par stratégie de jointure à la manière de transformation d’un opérateur de jointure en un
plan d’exécution physique. Blanas et al. [41]
 Jointure par répartition :
La jointure par répartition est la stratégie de jointure la plus utilisée dans le Framework MapReduce.
Elle est similaire à la jointure tri-fusion partitionnée dans les SGBD parallèles. Cette jointure est
implémentée par un seul job MapReduce. Chaque tache Map s’exécute sur un Split de l’un des deux
relations de la jointure (R ou S).Dans cette phase, chaque tuple est étiqueté par le nom de sa relation
d’origine et transformé en un couple clé-valeur. Ensuite, les enregistrements de chaque clé de la
jointure sont groupés et envoyés au Reducer. Dans la phase Reduce, la fonction Reduce sépare les
enregistrements d’entrée en deux ensembles selon la source de données et effectue le produit cartésien
(cross-product) entre les enregistrements des deux ensembles. La Figure 3.3 illustre un exemple d’une
jointure par répartition entre deux relations L et R.
 Jointure par diffusion :
La plus petite table est diffusée dans son intégralité à chaque nœud, pour éviter le tri des deux tables et
surtout le transfert de la plus grande table sous réseau. Cette petite table est peut être simplement
répliqué sur tous les noeuds. Ensuite la jointure est effectuée localement. Cette jointure est effectuée
en Map uniquement.
 Semi-jointure :
Ce type de jointure est exploitée pour minimiser la quantité de données transférées sous réseau. Les
enregistrements de la plus large relation qui ne sont pas référenciés par la jointure ne seront pas
transférés à travers le réseau. Cette jointure se déroule en trois phases, chacune correspond `a un job
MapReduce :
- Phase 1 : Correspond à un job MapReduce complet. La fonction Map extrait les clés de
jointure uniques dans la première relation (supposée la plus large). Ensuite, la fonction Reduce
fusionne toutes les cl´es uniques dans un seul fichier.
-Phase 2 : S’exécute en un job Map-only et similaire à la jointure par diffusion. La fonction
Map extrait chaque enregistrement dans la deuxième relation (supposée la plus petite) dont sa
clé se trouve dans le fichier des clés uniques construit dans la phase 1. La sortie de cette phase
est un fichier pour chaque split qui contient des enregistrements filtrés de la deuxième relation.
-Phase 3 : Utilisé la jointure par diffusion pour joindre les fichiers construits dans la
34
phase2 et la première relation.
Figure 3.3 : Exemple de jointure par répartition de deux relations
Dans cette technique, nous avons examiné la façon d'utiliser la jointure par répartition pour combiner
trois ensembles de données. La construction de jointure par répartition implique plusieurs étapes par rapport aux
autres approches de jointure, mais c'est un moyen puissant lorsque nous travaillons avec de grands ensembles de
données (où l'un des ensembles de données doit être réduit à une taille qui correspond à la mémoire).
3.2.1.3 Synthèse :
Chacune des stratégies de jointure que nous avons détaillées possède des forces et des faiblesses, alors
comment peut-on déterminer qui conviendra mieux pour les données que nous traitons ? La Figure 3.4 résume les
compromis de l'étude des stratégies de jointure dans un arbre de décision :
Figure 3.4 : Arbre de décision relatif aux stratégies de jointure.
35
Basé sur les statistiques, telles que la taille des données relatives et la fraction de la clé de jointure
référencée (ces statistiques pourraient être recueillies sur un échantillon des entrées). Cet arbre de décision tente de
déterminer quelle est la bonne stratégie de jointure pour une circonstance donnée. Si les données ne sont pas
prétraitées, la meilleure stratégie de jointure dépend de la taille des données transférées via le réseau. Si le coût de
la diffusion dans le réseau de la table R à chaque nœud est moins cher que le transfert de R et L, alors la jointure
par diffusion doit être utilisée.
Lorsque le prétraitement est permis, la semi-jointure, avec suffisamment de partitions est le meilleur choix. Elle
offre une plus grande flexibilité puisque ses étapes de prétraitement sont insensibles à la façon dont la table de
journal est structurée, et donc adaptée à un certain nombre de tables de référence [42].
En outre, les étapes de prétraitement des deux algorithmes : jointure répartie et jointure par diffusion sont
moins coûteuses car il n'y a pas de réarrangement des données du journal.
 Si l'un des ensembles de données est assez petit pour tenir dans la mémoire d'un MAPPER, la
jointure par diffusion est suffisante.
 Si le volume les deux ensembles de données est important, et un ensemble de données peut
être considérablement réduits par des éléments de filtration, la mise en œuvre de semi-jointure
est adéquate.
 Si nous ne pouvons pas prétraiter les ensembles de données et les tailles de ces ensembles sont
trop grandes par rapport à la mémoire cache d’un noeud de traitement, ceci signifie
l’obligation d’effectuer la jointure dans le REDUCER, alors la jointure répartie doit être
utilisée.
La stratégie que nous avons adoptée dans notre travail est la stratégie de jointure par répartition, car Il
s’agit d’une utilisation simple du paradigme MapReduce qui utilise les clés de jointure comme clés de sortie du
mappeur, peut être utilisée aussi pour tout type de jointure (intérieure, gauche, droite, complète extérieure…).
3.2.2 : La sélection : σ prédicat(R)
La sélection travaille sur R et définit une relation qui ne contient que les tuples de R qui satisfont à la
condition (ou prédicat) spécifié .La sélection : opérateur SELECT sélection d’un sous-ensemble de tuples d’une
relation qui vérifient une condition.
Exemple : aadresse=ORANdemandeur
36
Demandeur :
Lieu de
ID Nom Prénom Date de naissance Adresse
naissance
01122588 Amin Aissa 10/12/1994 Sobha Boukadir
88957444 Abdellatif sahouadj 02/02/1987 Karimia Oran
22583331 Omar naamoun 17/03/1990 Haouche gaba Oran
11005824 Slimane Rahmoun 21/08/1997 Chlef Oran
55248564 Saado noura 10/04/1995 Oued fodda Tenes
23241943 Boujeltia faiza 07/06/1992 Abou el hassen Talassa
36258713 Dermal samir 26/05/1989 Taougrite Ain merane
3.2.3 : La projection :
La projection travaille sur R et définit une relation restreinte à un sous-ensemble des attributs de R, en
extrayant les valeurs des attributs spécifiés et en supprimant les doublons.
La projection : opérateur PROJECT sélection de certaines colonnes d’une relation.
demandeur
Exemple : ID,Nom, Prénom, Adresse
Demandeur :
Lieu de
ID Nom Prénom Date de naissance Adresse
naissance
01122588 Amin Aissa 10/12/1994 Sobha Boukadir
88957444 Abdellatif sahouadj 02/02/1987 Karimia Oran
22583331 Omar naamoun 17/03/1990 Haouche gaba Oran
11005824 Slimane Rahmoun 21/08/1997 Chlef Oran
55248564 Saado noura 10/04/1995 Oued fodda Tenes
23241943 Boujeltia faiza 07/06/1992 Abou el hassen Talassa
36258713 Dermal samir 26/05/1989 Taougrite Ain merane
37
3.3 Modalisation du system:

3.3.1 Jointure de trois relations :
Les données utilisées dans ce travail, nous avons utilisé les références du secteur de l’emploie comme
source de données :
demandeur (id_dem , nom_dem ,prenom_dem ,date_naiss,lieu_naiss) ;

diplome (id_dem, intitul_dip, anne_dip) ;
metier (id_dem, intitul_metier)
Figure 3.5 : Le schéma de model relationnel de trois relations
Demandeur
Id du demandeur Nom Prénom Date naissance Lieu de naissance
9F3EEA62-5840-4D2D- DJEBEL MESSAAD,M
BENALLIA SALAH 1981-12-31
BB0D-B81AF22270F4 SILA
9F3E9875-7B7E-49AD- BENABDALLA
MOHAMMED 1995-05-09 GUELMA,GUELMA
B689-B9EFE604ED58 H
9F3E6D1C-D90F-4292-
TANIRI ABDALLAH 1988-03-29 AIN SEFRA,NAAMA
A5CD-48CFD36FBD11
EF22E22A-2A9D-4ACA- OUED EL ALENDA,EL
BEBBOUKHA AFIFA 1983-11-11
9BBB-B9314EFF0050 OUED
38
Diplôme
Id du demandeur Intitulé diploma Année d’obtention
9F3EEA62-5840-4D2D-BB0D- DEUA 2004
B81AF22270F4
9F3E9875-7B7E-49AD-B689- Licence LMD 2017
B9EFE604ED58
9F3E6D1C-D90F-4292-A5CD- CAP 2017
48CFD36FBD11
EF22E22A-2A9D-4ACA-9BBB- Ingénieur 2007
B9314EFF0050
Métier
Id du demandeur Intitulé métier
EF22E22A-2A9D-4ACA- Electrotechnicien en
9BBB-B9314EFF0050 installation d'exploitation
9F3E6D1C-D90F-4292-A5CD- Animateur hygiene
48CFD36FBD11
9F3E9875-7B7E-49AD-B689- Chauffeur de direction
B9EFE604ED58
9F3EEA62-5840-4D2D-BB0D- Administrateur système
B81AF22270F4 informatique
3.3.1.1 Requête SQL Correspond en Map/Reduce :

Dans notre étude, nous supposons deux requêtes SQL :
 Récupérer tout les demandeurs avec leurs diplômes et métiers :
Select id_dem , Nom_dem, prénom_dem, date_naiss, intitul_dip, anne_dip , intitul_metier from
,demandeur, diplôme , metier
Where demandeur.id_dem = diplome.id_dem and demandeur.id_dem = metier.id_dem and
metier.id_dem = diplome.id_dem group by id_dem
3.3.1.2 Cycle des opérations qui réalise la jointure répartie entre trois tables :
La figure 3.6 résume l’enchainement de l’opération d’une jointure en map-reduce. La première partie
(split et mapper et partitionner) découpes et rassemble et restriction les données en données hiérarchiques. La
deuxième partie (group et tri et reducer) et spécifique au traitement de la jointure.
Les mappeurs lu les blocs de la relation Contrat assure ou de la relation Assure .pour chaque
enregistrement lu, il recherche la valeur de l’attribut qui servira de clé commun pour la jointure entre les trois
tables, après va générer une paire clé-valeur et dont la valeur sera un couple d’information.
39
40
Tout les enregistrement ayant le même valeur d’attribut de jointure seront donc stockés dans des paires ayant la
même clé, qui seront routées vers le même reducer par l’étape de shuffle & sort.
Un reducer verra donc arriver sur lui tous l’enregistrement des relations demandeur, diplome et métier de
même clé, avec lesquels il devra construire les lignes de la table de jointure qui sont associées à cette clé. C’est
donc le Reducer qui fait le Jointure. Le Reducer reçoit en fait en entrée une paire clé - liste de valeurs et la
redécomposer en une liste d’enregistrements venant des tables . Ensuite le Reducer va constituer des paire clé-
valeur composé de la clé reçue, et les enregistrements fusionnés.
Toutes les combinaisons seront produites afin de générer l’ensemble des lignes de la relation jointure. Il ne restera
plus au Reducer qu’à écrire dans un fichier de sortie selon les besoins de la suite de l’application .
3.3.2 Implémentation de la jointure multi-way :
Dans un environnement MapReduce, la jointure de plusieurs tables peut être optimisée en un seul job
MapReduce. Par exemple, Hive transforme une requête de jointure de plusieurs tables en un seul job MapReduce,
si pour chaque table le même attribut est utilisé dans les clauses de la jointure. Cependant, si les attributs de la
jointure ne sont pas les mêmes, la requête sera transformée en plusieurs jobs MapReduce.
3.4.Conclusion
Bien que le mapreduce est une solution élégant mais comme tous les nouveau approche intéressante il y a
des avantages et des inconvénients, même il y a eu des partisans et des opposants à cette idéologie.
Ce paradigme a reçu beaucoup d’attention ces dernières années pour le traitement parallèle de grosses
quantités de données. A travers le modèle de coût proposé, nous avons arrivé à estimer le coût d’exécution des
requêtes décisionnelles sur le Cloud, dans un environnement MapReduce, en termes de temps d’exécution et en
termes de coût de paiement .
41
Chapitre 4 Mise en œuvre, Test et Evaluation
4.1 .Introduction :
Dans ce chapitre, nous allons aborder la partie pratique de notre projet qui consiste à décrire l’architecture,
la conception technique et la mise en œuvre complète de l’environnement distribué Hadoop. Nous définirons les
différentes étapes d’installation et de configuration de notre cluster Hadoop ainsi que les différents tests effectués sur
des tâches MapReduce.
4.2.Description de la solution proposée :

Pour tester notre système Hadoop, on a proposé comme solution d’exécuter plusieurs jobs en s’appuyant sur
le modèle MapReduce écrit en java :
 L’algorithme de jointure de 3 tables

 L’algorithme de sélection
 L’algorithme de projection
Le stockage des données est effectué dans des fichiers distribués d’Hadoop HDFS.
4.3. L’environnement de travail :
Dans la section suivante, on va décrire les outils et systèmes composant notre environnement de travail. (voir le
schéma ci-dessous)
4.3.1 Architecture physique:
Nous avons utilisé 4 machines pour créer un Cluster HADOOP qui sont caractérisées par :
 Processeur Core 2 Duo soit totalité de 8 (2*4) cœurs

 4 Go de Ram pour chaque machine soit totalité de 16 Go(4*4)
 Disque dur de 228 Go soit la totalité de 912 Go(228*4)
 Système d’exploitation Centos 7 Redhat Linux 64 bit
4.3.2 Architecture virtuelle :
VirtuellBox est un logiciel qui permet la création d’une ou plusieurs machines virtuelles simulant plusieurs
systèmes d’exploitation au sein d’un même système d’exploitation. Celles-ci, pouvant être reliées au réseau local
avec des adresses IP différentes, tout en étant sur la même machine physique qui existe réellement. Il est possible de
faire fonctionner plusieurs machines virtuelles en même temps. Dans notre cas, la virtualisation sera utilisée pour
renforcer le nombre de nodes du cluster hadoop ou nous avons ajouté 2 machines virtuelles ayant les caractéristiques
suivantes : (voir annexe 6)
 Système d’exploitation Centos 7 Redhat Linux 64 bit

 Processeur 1 cœur
42
 Une Ram de 1Go

 Disque dur dynamique (40 Go maximal)
Figure 4.1 – VirtualBox

4.3.3 Linux CentOS-7 :
CentOS (Community entreprise Operating System) est une distribution GNU/Linux principalement destinées
aux serveurs. Tous ses paquets, à l’exception du logo, sont des paquets compilés à partir des sources de la
distribution RHEL (Red Hat Entreprise Linux), éditée par la société Hat. On peut télécharger CentOS sous la forme
DVD OU CD.
Figure 4.2 – Centos 7
43
4.3.4 Hortonworks HDP :
HDP est la distribution open source la plus complète et gratuite à 100%, malgré qu’elle soit moins populaire
que Cloudera dans le m1onde. En janvier 2019, la fusion HDP-Cloudera a rendu la distribution comme celle la plus
utilisé dans le monde.
Figure 4.3 : Evolution de l’intérêt de recherche Cloudera vs hortonworks1
4.4. Installation hybride d’Hadoop :
Le mode d’installation hybride consiste à mettre en place un cluster hadoop en deux modes différents :
 Le mode Fully-Distributed Operation (Multi Node Cluster) : 4 machines physiques

 Le mode Pseudo-DistributedOperation : 2 machines VM
Après avoir préparé les stations avec leurs paramètres, nous avons procédé à la création et configuration du
cluster HADOOP avec HA (Hight Availability) dont ses caractéristiques techniques sont indiquées ci-après.
Dans le cluster utilisé nous allons d’abord préparer les noeuds en installant et en configurant les composants
de l’Ambari (HortonWorks Distribution Apache Hadoop) en mode distribué :
4.4.1 Le mode Fully-Distributed Operation (Multi Node Cluster):
 Ambari :
 Host : nommé hdp-nodemaster.localdomain
 @IP : 10.2.5.105
 Services : HDFS, YARN, Mapréduce2, Zookeper, Ambari métrics
 Namenode (machine maître):
1
https://trends.google.fr/trends/?geo=FR
44
 Host : nommé hdp-node01.localdomain

 @IP : 10.2.5.103
 Taille de disque alloué : 200 Go (pour la racine Root)
 Datanode (machine esclave):
 Host :
- Hdp-node01.localdomain avec son @IP :10.2.5.103
- Hdp-nodemaster.localdomain avec son @IP :10.2.5.105
 Taille de disque alloué : 200 Go (pour la racine Root de chaque machine)
 Ressourcemanager : (machine maitre assure aussi le Namenode secours)
 Host : nommé hdp-node02.localdomain
 @IP : 10.2.5.110
 Mémoire allouée : 2 Go
 Processeur alloué : 2 Cœur
 Nodemanager (machine esclave) :
 Host :
- Hdp-nodemaster.localdomain avec son @IP :10.2.5.105
 Mémoire allouée : 2 Go (pour chaque machine)
 Processeur alloué : 2 Cœur (pour chaque machine)
4.4.2 Le mode Pseudo -Distributed Operation :
a. Création des machines virtuelles sous virtualbox
b. Configuration du mode d’accès réseaux : accès par pont (voir annexe 6)
c. Installation de centos 7 au niveau des 2 machines VM
e. d. Mise a jours du kernel (voir annexe 1)
f. Configuration de la sécurité, pare-feu, mode d’accès SSH et installation de quelques utilitaires
(voir annexe 1)
g. Injection les deux machines virtuelles au cluster HADOOP via l’Ambari (voir annexe 2)
45
En résumé, notre environnement d’évaluation est composé d’un serveur Ambari (voir annexe 1), via lequel
un cluster de 6 Nœuds a été crée dont à chaque nœud nous avons installé un Nodemanager et Datanode ainsi
qu’une machine Namenode et une machine Ressourcemanager (voir annexe 2).
Pour la sauvegarde journalière des indexes des données, nous avons mis en place un NameNode secondaire
(Secondary Namenode) dans la même machine qui contient le master Ressourcemanager.
Figure 4.4 – La solution HADOOP exploitée dans le moteur de recherche (elasticsearch)
46
4.5. Plan d’exécution :
Pour tirer profit du traitement parallèle que fournit Hadoop, nous exprimons nos requêtes comme des jobs
de MapReduce2, qui seront exécutées sur un cluster de machines. Nous allons traiter les données relatives aux
demandeurs d’emploi, leurs diplôme et métiers en appliquant les opérations de jointure, sélection et projection. Ces
données sont stockées dans un format txt , puis les transférer au notre cluster HADOOP .Les étapes effectuées pour
exécuter les requêtes sont décrites comme suite :
4.5.1- Lancez les services du cluster en utilisant l’espace Web Ambari :

http://10.2.5.105:8080 ou http://hdp-nodemaster:8080
Figure 4.4 : Démarrage des services d’HADOOP
47
4.5.2-Copier les données vers une machine locale (Linux centos 7) par le biais de l’application
MobaXterm (émulateur de terminal Linux pour Windows) :
Figure 4.5 : Emulateur de terminal Linux pour Windows
4.5.3 - Ensuite transférer ces données vers le cluster HADOOP par le client HDFS pour quelles soit
stockées de façon distribué dans les différents Datanode dont la taille de bloc est configurée à 128 Mo :
Table Demandeur d’emploi :
Fichier Taille(Mo) Taille du bloc(Mo)

D5 473.84 128
 Hadoop fs –copyFromLocal /usr/hdp/D1.txt /tmp/Data

48
Table Diplôme :

DIP 129.2 128
 Hadoop fs –copyFromLocal /usr/hdp/DIP.txt /tmp/Data

Table Métier :

M1 59.35 128
M2 118.69 128
M3 177.95 128
M4 237.17 128
M5 296.41 128
 Hadoop fs –copyFromLocal /usr/hdp/DIP.txt /tmp/Data

La répartition des fichiers de données en ce format a pour but d’effectuer les opérations relationnelles sur
multiples fichiers en augmentant la taille du fichier à chaque fois et marquant le temps d’exécution du job, et par
conséquent nous montrons la scalabilité du cluster HADOOP.
4.5.4 - Environnement de développement des programmes MapReduce :
Au cours du développement nous avons utilisé des programmes, des logiciels et des outils nécessaires à la
réalisation de l’application qui est l’implémentation de l’algorithme de jointure, sélection et projection . Parmi ces
programmes et logiciels utilisés, nous avons :
 Le Système d’exploitation Centos 7 .
 Version de java JVM 1.8.164
 Framework Hadoop 3.0.1.0
 Un éditeur Eclipse
Comme outils de programmation, nous allons travailler avec Eclipse java, pour cela nous allons
commencer par importer les packages de Hadoop.
49
Figure 4.6 : Environnement de développement des jobs MapReduce
La Figure 4.6 illustre l’environnement de développement des jobs MapReduce, nous avons notamment
utilisé les packages plus important : Package org.apache.hadoop.fs , Package org.apache.hadoop.io et Package
org.apache.mapred. Nous allons faire une brève description des principales classes de ces packages.
 Package org.apache.hadoop.io : Ce package est utilisé lors de la lecture et de l’écriture des données sur
le réseau, bases de données, et les fichiers, les principales classes de ce package sont : [43]
Classe Usage de classe

IntWritable Pour la lecture et écriture d’un entier.
LongWritable Pour la lecture et écriture d’un long donnée.
 Package org.apache.hadoop.fs : Ce package gère les systèmes de fichiers

(notamment HDFS), parmi ses principales classes : [43]
50

Path Spécifie les noms des fichiers ou de répertoires dans un système de fichiers.
Utiliser en général pour la lecture, il encapsule les données, et fait le lien entre le
FSDataInputStream
Namenode et les Datanodes.
Utiliser lors de l’écriture d’un fichier, il se charge de la coordination entre le
FSDataOutputStream
Namenode et les Datanodes lors de l’écriture.
 Package org.apache.hadoop.mapreduce : Il est utilisé pour l’implémentation du MapReduce, parmi

ses principales classes : [43][44]
InputFormat<K,V> Input Format décrit l’entrée d’un job MapReduce (keys,value)
Implémente la fonction Map(), reçoit une liste de clé value en input et génère
Mapper<K1,V1,K2,V2>
une autre liste de clé value.
I’mplémente la fonction Reduce(), reçoit une liste de clé value en input
Reducer<K2,V2,K2,V3>
(k2,v2) et génère une liste réduite (k2,v3).
 Code source : Pour avoir les 3 Jobs relatifs à la jointure, sélection et la projection, nous allons
implémenter tout d’abord les fonctions Map et Réduce sous Eclipse IDE dont le tableau descriptif ci-
après illustre les différentes classes java déployées pour effectuer les requêtes dans un environnement
distribué :
Opération Classes Fonction
joinfiles.java Programme principal
MultipleMap1.java Transformer les données d'entrée en une série de couples clef /valeur pour
Jointure du 3 fichiers
MultipleMap2.java jointure de 3 fichiers
(voir annexe 3)
MultipleMap3.java
MultipleReducer.java Traitement de jointure de toutes les valeurs produites par l'opération MAP
selectmain.java Programme principal
selectmaper.java Transformer les données d'entrée en une série de couples clef /valeur pour
Sélection d’un fichier
sélection
(voir annexe 4)
selectreducer.java Traitement de sélection de toutes les valeurs produites par l'opération
MAP
projection.java Programme principal
Projection d’un projectionmap.java Transformer les données d'entrée en une série de couples clef /valeur pour
fichier projection
(voir annexe 5) projectionreducer.java Traitement de projection de toutes les valeurs produites par l'opération
MAP
51
4.5.5 Création des fichiers JAR: après avoir édité le code source des classes java mentionnées ci-dessus
relatives aux Jobs MapReduce, nous montrons par la suite les étapes de compilation desdites classes selon
les figures suivantes :
 Exporter l’un des projets vers un fichier JAR;
Figure 4.7 – Création le fichier Jar de programme
 Choisir le projet à exporter avec distination du fichier JAR ;

 continuer les étapes restantes avec les paramètres par défaut ;
 Refaire les étapes pour les deux autres projets MapReduce .
52
4.6. Test et Evaluation :

Pour test et expérimenter l’environnement mis en œuvre, on va utiliser 3 Jobs :
 jointure
 selection
 projection
Au début nous avons commencé par le premier job jointure et le deuxième selection puis projection en
effectuant les mêmes étapes sauf des changements sur le chemin et les fichiers input et bien sur le format du résultat.
Le point d’entrer d’un mapReduce est une masse de données composée de plusieurs fichiers comme indiqué
au début du présent chapitre. Ces fichiers vont être découpés en splits. Un split correspond à un bloc, donc au moins
un split par fichier (si la taille du fichier est supérieure a la taille d’un bloc du HDFS alors nous utilisons plusieurs
splits).
A l’initialisation (création de l’application Master), le nombre de maps dépend directement du nombre de
splits calculé au préalable.
4.6.1 La jointure :
Nous allons tester le job de jointure en utilisant trois fichiers (Demandeur , Diplôme et Métier) transférés au
systèm HDFS dont nous varions leurs tailles pour effectuer un ensemble test montrant le passage à l‘échelle sur le
cluster :
Pour lancer le job , il faut donner les paramètres d’entrées et les paramètres de sortie à l’aide de la ligne de
commande suivante :
Hadoop jar /usr/hdp/jointure3.jar hdp.joinfiles /tmp/Data/D1.txt /tmp/Data/DIP.txt /tmp/Data/M1.txt /tmp/result

53
Figure 4.8 : L’exécution du job jointure
4.6.1.1 Explication du schéma d’exécution d’un job MapReduce :

Il faut comprendre que YARN lance une instance de Map pour chaque ligne de chaque fichier des données
à traiter. Chaque instance traite la ligne qu’on lui a attribuée et produit des paires en sortie.
1. Le client mapredude connecte au ResourceManager en lui sollicitant l’execution du Job avec les fichiers d’entrer.
2.ResourceManager se renseigne sur l’emplacement des données auprès du namenode et créer une
ApplicationMaster
3. La phase Split consiste à construire des paires des fichiers (n° de n-uplet, n-uplet) à fournir aux tâches Map.
4. YARN crée des processus Map sur chaque machine contenant une partie des données et leur fournit les paires
(Key,Values) de leur machine successivement.
5. Chaque tâche Map analyse ses données et émet une paire. Ça peut consister à convertir des chaînes en nombres, à
faire des calculs, etc.
6. YARN trie les paires sortant de Map selon leur clés et les envoie sur la machine qui fait tourner la tâche Reduce
concernée par cette clé.
7. Les tâches Reduce reçoivent une liste de paires et effectuent la réduction des valeurs (organise chaque clé avec ses
valeurs ). Elles émettent en cascade la valeur finale de chaque clé pour générer le résultat de jointure .
8- ApplicationMaster à son rôle envoie le fichier global de jointure au ResourceManager qui libère par la suite les
ressources allouées à cette application.
54
Nous pouvons suivre la progression de l’execution d’une application par la plate forme web Ambari en cliquant
sur YARN puis RessourceManagerUI , dans cette page on peut consulter plusieurs informations :
Figure 4.9 : Déroulement de l’exécution d’un job MapReduce
4.6.1. 2 Affichage du résultat :
Le résultat du l’execution d’un job MapReduce c’est un fichier stocké dans le système HDFS qu’on peut le
voir aussi via l’interface graphique Ambari en cliquant sur HDFS puis NameNodeUI puis cliquer sur Utilities,
comme ullstré dans la figure 4.7. Dans cette section nous pouvons télécharger le fichier résultat part-r-00000 et
également voir ses caractéristiques à savoir la taille, nombre de block .
55
Figure 4.10 : Affichage du résultat
4.6.1.3 Interprétation des résultats de jointure :

Après l’exécution des tests précédents, on peut synthétiser les résultats dans le tableau suivant :
Taille des fichiers(Mo) Nombre de noeud Temps d’execution (mn)

D5,DIP,M1 (473.84, 129.2, 59.35) 3 5,48
D5,DIP,M2 (473.84, 129.2, 118.69) 4 6,16
D5,DIP,M3 (473.84, 129.2, 177.95) 5 7,41
D5,DIP,M4 (473.84, 129.2, 237.17) 6 8,4
D5,DIP,M5 (473.84, 129.2, 296.41) 8 8,63
56
Evolution du temp d'excution de l'algorithme map reduce de

jointure selon volumétrie et nombre de nodes
10
9
8,4 8,63
8
7,41
7
6 6,16
5,48
5
4
3
2
1
0
88,590 177,18 265,77 354,37 473,84
volume de données
No bre de œud Temps d'execution
Figure 4.11: Temps d’exécution en fonction des configurations du cluster
Le graphe ci-dessus montre une croissance lente du temps d’exécution quand on augmente le volume des
fichiers. Après lecture des résultats obtenus, on peut remarquer que le critère de performance à savoir le temps de
réponse, est en faveur de l’architecture à plusieurs nœuds. L’utilisation CPU (2 coeur par machine) et mémoire
(2Go par machine) ont été distingués comme un facteur limitant durant toutes nos expérimentations, ça peut être
expliqué par le fait que le système à plusieurs nœuds applique un fort parallélisme et on maintient une scalabilité du
cluster malgré la croissance des données.
Les résultats seraient différents, si on travaillait sur des machines physiques plus performantes à mémoire
et CPU non partagés.
Un autre renseignement peut être tiré des résultats précédents, est le fait que des résultats obtenus en output
ont été conservés malgré la défaillance d’un noeud, ce qui implique une forte tolérance aux pannes, dû
principalement au principe de réplication des données, considéré comme un principe de base et un atout des
systèmes distribués tel qu’Hadoop Distributed File System.
4.6.2 La sélection :
Dans cette partie nous allons tester le job de selection en utilisant le fichier Demandeur déjà transféré dans le
test précédent au systèm HDFS dont nous varions son taille pour effectuer aussi un ensemble test montrant le
passage à l‘échelle sur le cluster :
commande suivante :
57
Hadoop jar /usr/hdp/selection.jar selectcondition.selectmain /tmp/Data/D1.txt /tmp/result1


Figure 4.12 : L’exécution du job sélection
Interprétation des résultats :

Après l’exécution des tests de sélection, on peut synthétiser les résultats dans le tableau suivant :

D1 88.59 2 1,75
D2 177.18 2 0,96
D3 265.77 3 1,45
D4 354.37 3 0,98
D5 473.84 4 3,18
58
Evolution du temp d'excution de l'algorithme map reduce de

selection selon volumétrie et nombre de nodes
4,5
4
3,5
3,18
3
2,5
2
1,75
1,5 1,45
1 0,96 0,98
0,5
0
88,590 177,18 265,77 354,37 473,84
volume de données
Volume des données Temps d'execution
Figure 4.13 : Temps d’exécution en fonction des configurations du cluster
Le graphe ci-dessus montre la diminution du temps d’exécution quand nous augmentons le nombre de
nœuds (blocs des données) dans le cluster de calcul, après, le temps d’exécution remonte en vue de l’augmentation
du volume sans changement du nombre des nœuds(3), et va stagner quant le nombre de nœud se croisse .
Lecture des résultats obtenus, on peut remarquer que le critère de performance à savoir le temps de réponse,
est en faveur de l’architecture à plusieurs nœuds.
4.6.3 La projection :
Finalement nous allons tester le job de projection en utilisant le fichier Demandeur déjà transféré dans le test
précédent au système HDFS dont nous varions son taille pour effectuer aussi un ensemble test montrant le passage à
l‘échelle sur le cluster :
commande suivante :
Hadoop jar /usr/hdp/projection.jar projection.projection /tmp/Data/D1.txt /tmp/result1

59
Figure 4.14 : L’exécution du job projection
Interprétation des résultats :

Après l’exécution des tests de projection, on peut synthétiser les résultats dans le tableau suivant :
D1 88.59 2 2,33
D2 177.18 2 3,08
D3 265.77 3 3,26
D4 354.37 3 4,33
D5 473.84 4 4,75
60
Evolution du temp d'excution de l'algorithme map reduce

de projection selon volumétrie et nombre de nodes
5
4,75
4,5
4,33
4
3,5
3,26
3 3,08
2,5
2,33
2
1,5
1
0,5
0
88,590 177,18 265,77 354,37 473,84
volume de données
Figure 4.15 : Temps d’exécution en fonction des configurations du cluster
Le graphe ci-dessus montre aussi une croissance lente du temps d’exécution quand on augmente le volume
des fichiers. Après lecture des résultats obtenus, on peut affirmer que la complexité des données influe directement
sur le temps d’exécution quant le nombre de nœuds ne change pas ,ce qui indique que l’architecture à plusieurs
nœuds applique un fort parallélisme en maintiennent une scalabilité du cluster malgré la croissance des données.
4.7. La tolérance de panne:

Pour montrer la tolérance de panne, nous avons effectué des tests de projection sur un volume de données fixe
en ajoutant à chaque fois un nœud esclave dont le temps d’exécution du traitement est montré comme suite :
Nombre de nœud
Taille des fichiers(Mo) Temps d’execution (mn)
esclaves
D1 88,59 4 1,21
D1 88,59 3 1,94
D1 88,59 2 2,33
D1 88,59 1 3,05
61
Evolution du temp d'excution de test de la tolérance de

panne par projection selon volumétrie et nombre de nodes
3,05
2,33
1,94
1,21
88,590 88,590 88,590 88,590

volume de données
Figure 4.16 : Temps d’exécution en fonction du nombre de nœud esclave
La déduction faite après l’exécution d’un job de projection (exemple d’un traitement), c’est bien que la
précision et le résultat obtenu est préservé malgré la défaillance d’un noeud, ce qui confirme la forte tolérance aux
pannes d’Hadoop Distributed File System.
4.8. La Haute disponibilité (Hight Availabilty) :

Comme on a définit dans le chapitre 2 la nécessité d’un Namenode secondaire pour assurer de la Haute
disponibilité, nous avons configuré une machine (hdp-node02.localdomain) qui assurera le rôle d’un Namenode
secondaire sur l’@ IP : 10.2.5.110 .
Figure 4.17 : L’état du Namenode secondaire
62
Les résultats obtenus en output ont été conservés malgré la défaillance à un moment donné du Namenode
principal (Figure 4.13), ce qui implique une forte tolérance aux pannes, dû principalement au principe de la haute
disponibilité, considéré comme un principe de base indispensable et un atout des systèmes distribués tel qu’Hadoop
Distributed File System.
4.9. Conclusion :
Dans ce chapitre nous avons commencé par montrer les caractéristiques et détails de la conception de
l'environnement de travail, puis nous avons exposé les différentes classes java de notre application en décrivant leurs
utilités. Nous avons ensuite présenté les résultats de l'expérimentation de notre outil suivis par leurs interprétations.
Les tests et les expérimentations effectués dans ce chapitre ont amené à la conclusion des points suivants :
 L’augmentation du nombre de nœuds influe sur l’exécution des programmes MapReduce2, réduit son temps
d’exécution et en conséquence la latence est minimisée.
 La réplication des données garantit un niveau de fiabilité pour le système Hadoop en cas de défaillance d’un
de ses nœuds et en conséquence assure la disponibilité du système.
 La flexibilité d’une telle architecture distribuée en augmentant le nombre de nœuds des clusters reflète le
passage à l’échelle et assure l’extensibilité.
63
Conclusion générale
Conclusion générale :
Notre projet a fait l’objet d’une étude des nouvelles technologies du Big Data, Nous nous sommes intéressés
au Framework Hadoop. La partie applicative consistait à un déploiement d’Hadoop avec ses composants YARN et
HDFS dans un environnement distribué à base de la distribution Hortonworks.
Les différents systèmes de gestion des données conçus ces dernières années, se distinguent à base de trois facteurs
principaux : La performance, caractérisée par la latence et le débit, l’extensibilité (élasticité ou scalabilité) et la
disponibilité.
La mise en oeuvre d’un cluster Hadoop avec ses composants, l’exécution de plusieurs jobs MapReduce2 sur
des fichiers HDFS dans des architectures à plusieurs nœuds et l’évaluation des différents statistiques des opérations
effectuées nous ont permis d’approuver l’impact de la distribution et le parallélisme sur l’efficacité des systèmes
gérant de grands volumes de données en réduisant la latence et en garantissant et une meilleure extensibilité.
D’un autre côté, on a pu constater, que la réplication des données sur les différents nœuds du réseau garanti
un certain niveau de disponibilité du système même en cas de défaillance d’un ou plusieurs noeuds du réseau.
Perspectives :
Le domaine de recherche reste très ouvert aux différents travaux et différents tests dans des architectures
fortement distribuées, néanmoins le futur projet qui se voit très intéressant, est la mise en œuvre d’un cluster Hadoop
sur des machines physiques puissantes dans une plateforme High-Performance-Computing (HPC) pour pallier les
problèmes du Hardware qu’on a rencontré. Aussi, la démonstration des points forts d’Hadoop à savoir la
performance, la latence et l’extensibilité en appliquant plusieurs tests sur des données très volumineux de plusieurs
téraoctets sur des centaines de noeuds voire des milliers de nœuds peut faire l’objet d’autres prochains sujets de
recherche.
64
Annexe 1 Installation de l’Ambari
Guide d’i stallatio de A bari (Centos 7)
Via puTTY : sudo root

Password : enter password
Mise à jour kernel :
yum update –y
65
Installation wget
Important sur ensemble des hosts pour le téléchargement de l’agent et installation à distance
Sudo yum install wget :
Installation nano :
sudo yum install nano
66
Renommer les machines:
hostnamectl set-hostname nom_machine

ex :
hostnamectl set-hostname hdp-node02.localdomain
Modifier le fichier hosts
Même fichier host pour chaque node :

Vi /etc/hosts :
Test de Ping entre les différentes machines du cluster .

Limitation de consommation de ressource
ulimit -n 1000 pagination
67
Désactivation de la sécurité linux et firewall

vi /etc/selinux/config SELEINUX=disabled
Service firewalld stop

chkconfig firewalld off
systemctl stop firewalld
systemctl disable firewalld
installation du client ntp

yum install -y ntp
systemctl enable ntpd
68
Génération de la clé private :
Dispatching de la clé public sur les nodes :
Dispatching de la clé public sur les nodes : nodemaster.localdomain + hdp-node[01-04].localdomain.

ssh-copy-id -f root@nodemaster.localdomain
69
Actualisation des key ssh :
Lorsque l'on réinstalle un serveur Linux et que l'on établit une nouvelle connexion SSH vers celui-ci, on se
retrouve souvent avec ce message d'erreur : Warning: remote host identification has changed ! Cela signifie
que les clefs SSH ont changé.
Suppression de la clé publique du fichier known_hosts au niveau du hdp-nodemaster et redistribuer la clé
public sur la machine mise à jour.
Installation NMON :
yum install dnf
dnf install epel-release
dnf install nmon
Installation jps :
yum list java*devel*
yum install java-1.8.0-openjdk-devel.x86_64
Installation ambari :
https://www.linuxhelp.com/how-to-install-ambari-server-on-centos-7
Pour installer Ambari Server on CentOS 7 :
Le projet Apache Ambari vise à simplifier la gestion de Hadoop en développant un logiciel permettant de
provisionner, de gérer et de surveiller les clusters Apache Hadoop. Ambari fournit une interface utilisateur Web
de gestion Hadoop intuitive et facile à utiliser, renforcée par ses API RESTful. C'est vraiment simple d'installer
Ambari Server sur CentOS 7 et ce tutoriel couvre le même processus.
Installing Ambari :
Commençons maintenant ce processus en ajoutant le référentiel public pour Ambari. Utilisez la commande
suivante dans le même but.
[root@localhost ~]# wget -nvhttp://public-repo-
1.hortonworks.com/ambari/centos7/2.x/updates/2.7.3.0/ambari.repo -O /etc/yum.repos.d/ambari.repo
Une fois que le repolist est ajouté, vous devez mettre à jour le repolist que vous venez d'ajouter. Exécutez la
commande suivante pour effectuer cette action.
[root@localhost ~]# yum repolist
70
Loaded plugins: fastestmirror, langpacks
Updates-ambari-2.2.2.0 | 2.9 kB 00:00:00
Updates-ambari-2.2.2.0/primary_db | 6.3 kB 00:00:00
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
repo id repo name status
Updates-ambari-2.2.2.0 ambari-2.2.2.0 - Updates 8
base/7/x86_64 CentOS-7 - Base 9,591
extras/7/x86_64 CentOS-7 - Extras 329
updates/7/x86_64 CentOS-7 - Updates 1,720
repolist: 11,648
Une fois les étapes ci-dessus terminées, vous devez installer Ambari Server à partir du référentiel
public Ambari :
[root@localhost ~]#
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: centos.excellmedia.net
* extras: centos.excellmedia.net
* updates: centos.excellmedia.net
Resolving Dependencies
--> Running transaction check
---> Package ambari-server.x86_64 0:2.2.2.0-460 will be installed
71
--> Processing Dependency: postgresql-server > = 8.1 for package: ambari-server-2.2.2.0-

460.x86_64
---> Package postgresql-server.x86_64 0:9.2.23-3.el7_4 will be installed
--> Processing Dependency: postgresql-libs(x86-64) = 9.2.23-3.el7_4 for package: postgresql-

server-9.2.23-3.el7_4.x86_64
--> Processing Dependency: postgresql(x86-64) = 9.2.23-3.el7_4 for package: postgresql-server-

9.2.23-3.el7_4.x86_64
--> Processing Dependency: libpq.so.5()(64bit) for package: postgresql-server-9.2.23-

3.el7_4.x86_64
---> Package postgresql.x86_64 0:9.2.23-3.el7_4 will be installed
---> Package postgresql-libs.x86_64 0:9.2.23-3.el7_4 will be installed
Installed:
ambari-server.x86_64 0:2.2.2.0-460
Dependency Installed:
postgresql.x86_64 0:9.2.23-3.el7_4 postgresql-libs.x86_64 0:9.2.23-3.el7_4 postgresql-

server.x86_64 0:9.2.23-3.el7_4
Complete!
Ensuite, exécutez la commande setup pour configurer votre serveur Ambari, votre base de données, votre
JDK, votre LDAP et d’autres options.
[root@localhost ~]# ambari-server setup
72
Using python /usr/bin/python
Setup ambari-server
Checking SELinux...
SELinux status is ' enabled'
SELinux mode is ' enforcing'
Temporarily disabling SELinux
WARNING: SELinux is set to ' permissive' mode and temporarily disabled.
OK to continue [y/n] (y)?
Customize user account for ambari-server daemon [y/n] (n)?
Adjusting ambari-server permissions and ownership...
Checking firewall status...
Redirecting to /bin/systemctl status iptables.service
Unit iptables.servicecould not be found.
Checking JDK...
[1] Oracle JDK 1.8 + Java Cryptography Extension (JCE) Policy Files 8
[2] Oracle JDK 1.7 + Java Cryptography Extension (JCE) Policy Files 7
[3] Custom JDK
========================================================================
======
Enter choice (1):
To download the Oracle JDK and the Java Cryptography Extension (JCE) Policy Files you must
accept the license terms found at
73
http://www.oracle.com/technetwork/java/javase/terms/license/index.html and not accepting will

cancel the Ambari Server setup and you must install the JDK and JCE files manually.
Do you accept the Oracle Binary Code License Agreement [y/n] (y)?
Downloading JDK from http://public-repo-1.hortonworks.com/ARTIFACTS/jdk-8u60-linux-

x64.tar.gz to /var/lib/ambari-server/resources/jdk-8u60-linux-x64.tar.gz
jdk-8u60-linux-x64.tar.gz... 100% (172.8 MB of 172.8 MB)
Successfully downloaded JDK distribution to /var/lib/ambari-server/resources/jdk-8u60-linux-

x64.tar.gz
Installing JDK to /usr/jdk64/
Successfully installed JDK to /usr/jdk64/
Downloading JCE Policy archive from http://public-repo-

1.hortonworks.com/ARTIFACTS/jce_policy-8.zip to /var/lib/ambari-server/resources/jce_policy-
8.zip
Successfully downloaded JCE Policy archive to /var/lib/ambari-server/resources/jce_policy-8.zip
Installing JCE policy...
Completing setup...
Configuring database...
Enter advanced database configuration [y/n] (n)?y
Configuring database...
========================================================================
======
Choose one of the following options:
[1] - PostgreSQL (Embedded)
74
[2] - Oracle
[3] - MySQL
[4] - PostgreSQL
[5] - Microsoft SQL Server (Tech Preview)
[6] - SQL Anywhere
========================================================================
======
Enter choice (1):1
Database name (ambari):
Postgres schema (ambari):
Username (ambari):
Enter Database Password (bigdata):
Default properties detected. Using built-in database.
Configuring ambari database...
Checking PostgreSQL...
Running initdb: This may take upto a minute.
Initializing database ... OK
About to start PostgreSQL
Configuring local database...
Connecting to local database...done.
Configuring PostgreSQL...
Restarting PostgreSQL
75
Extracting system views...
ambari-admin-2.2.2.0.460.jar
......
Adjusting ambari-server permissions and ownership...
Ambari Server ' setup' completed successfully.
Une fois la configuration terminé, on démare Ambari server.
[root@localhost ~]# ambari-server start
Using python /usr/bin/python
Starting ambari-server
Ambari Server running with administrator privileges.
Organizing resource files at /var/lib/ambari-server/resources...
Server PID at: /var/run/ambari-server/ambari-server.pid
Server out at: /var/log/ambari-server/ambari-server.out
Server log at: /var/log/ambari-server/ambari-server.log
Waiting for server start....................
Ambari Server ' start' completed successfully.
[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# systemctl disable firewalld
Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service.
Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service.
maintenant on peut déployer le cluster en utilisant Ambari Web UI, et tapez :
76
http://localhost:8080 or http://<ambari-server-host> :8080
A partir de cet espace, on install le cluster HADOOP

Augmenter le time out de ambari :
/etc/ambari-server/conf/ambari.properties
77
Annexe 2 Installation de Cluster HADOOP
Tapez le nom du Cluster et la version :
78
Ajouter les hostes (machines) du Cluster avec la clé privé :
79
Configuration des services d’HADOOP :
80
Définir les machines assurant les masters :
Définir les machines assurant les slaves :
81
configuré les paramètres spécifiques aux maitre et slaves :
82
Annexe 3 Les classes MapReduce du jointure
1.La classe joinfiles.java :
package hdp;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.conf.Configured;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.Text;
import org.apache.hadoop.mapreduce.Job;
import org.apache.hadoop.mapreduce.lib.input.MultipleInputs;
import org.apache.hadoop.mapreduce.lib.input.TextInputFormat;
import org.apache.hadoop.mapreduce.lib.output.FileOutputFormat;
import org.apache.hadoop.util.GenericOptionsParser;
import org.apache.hadoop.util.Tool;
import org.apache.hadoop.util.ToolRunner;
public class joinfiles extends Configured implements Tool{
public static void main(String[] args) throws Exception

{
if (args.length != 4 ){
System.err.println ("Usage :<inputlocation1> <inputlocation2>
<outputlocation> >");
System.exit(0);
}
int res = ToolRunner.run(new Configuration(), new joinfiles(), args);
System.exit(res);
}
public int run(String[] args) throws Exception {
Configuration c=new Configuration();
c.set("mapred.textoutputformat.separator",",");
String[] files=new GenericOptionsParser(c,args).getRemainingArgs();
Path p1=new Path(files[0]);
FileSystem fs = FileSystem.get(c);
if(fs.exists(p4)){
83
fs.delete(p4, true);
}
Job job = new Job(c,"Multiple Job");
job.setJarByClass(joinfiles.class);
MultipleInputs.addInputPath(job, p1, TextInputFormat.class, MultipleMap1.class);
MultipleInputs.addInputPath(job,p2, TextInputFormat.class, MultipleMap2.class);
MultipleInputs.addInputPath(job,p3, TextInputFormat.class, MultipleMap3.class);
job.setReducerClass(MultipleReducer.class);
job.setOutputKeyClass(Text.class);
job.setOutputValueClass(Text.class);
FileOutputFormat.setOutputPath(job, p4);
boolean success = job.waitForCompletion(true);
/*return success?0:1;*/
System.exit(success ? 0 : 1);
return 0;
}
2.La classe MultipleMap1.java :
package hdp;
import java.io.IOException;
import org.apache.hadoop.mapreduce.Mapper;
public class MultipleMap1 extends Mapper<Object,Text,Text,Text>
{
Text keyEmit = new Text();
Text valEmit = new Text();
public void map(Object k, Text value, Context context) throws IOException,
InterruptedException
{
String line=value.toString();
String[] words=line.split(",");
keyEmit.set(words[0]);
valEmit.set(words[1]+" "+words[2]+"/*");
context.write(keyEmit, valEmit);
84
}
}
package hdp;
public class MultipleMap2 extends Mapper<Object,Text,Text,Text>
{
public void map(Object k, Text v, Context context) throws IOException,
{
String line=v.toString();
valEmit.set(words[1]+" "+words[2]+"/#");
}
}
85
package hdp;
import org.apache.hadoop.io.LongWritable;
public class MultipleMap3 extends Mapper<LongWritable,Text,Text,Text>

{
public void map(LongWritable k, Text value,Context context) throws IOException,
{
String line=value.toString();
valEmit.set(words[1]+"/&");
}
}
5.La classe MultipleReducer.java :
package hdp;
import org.apache.hadoop.mapreduce.Reducer;
public class MultipleReducer extends Reducer<Text,Text,Text,Text>

{
String merge = "";
public void reduce(Text key, Iterable<Text> values, Context context)
throws IOException , InterruptedException
{
int i =0;
86
for(Text value:values)
{
String valeur[] = t.toString().split("/");
if(valeur[1].equals("*"))
demandeur = demandeur + valeur[0]+',';
if(valeur[1].equals("#"))
diplome = diplome + valeur[0]+' ';
if(valeur[1].equals("&"))
metie = metie + valeur[0]+' ';
}
diplome=diplome+',';
valEmit.set(demandeur+diplome+metie);
context.write(key, valEmit);
}
}
87
Annexe 4 Les classes MapReduce du selection
1.La classe selectmain.java :
package selectcondition;
import org.apache.hadoop.io.*;
import org.apache.hadoop.mapred.*;
public class selectmain {

public static void main(String[] args) {

JobClient my_client = new JobClient();
// Create a configuration object for the job
JobConf job_conf = new JobConf(selectmain.class);
// Set a name of the Job

job_conf.setJobName("selection");
// Specify data type of output key and value

job_conf.setOutputKeyClass(Text.class);
job_conf.setOutputValueClass(IntWritable.class);
/* Specify names of Mapper and Reducer Class*/

job_conf.setMapperClass(selectmaper.class);
job_conf.setReducerClass(selectreducer.class);
// Specify formats of the data type of Input and output

job_conf.setInputFormat(TextInputFormat.class);
job_conf.setOutputFormat(TextOutputFormat.class);
/* Set input and output directories using command line arguments,

arg[0] = name of input directory on HDFS, and arg[1] = name of output directory to
be created to store the output file.*/
FileInputFormat.setInputPaths(job_conf, new Path(args[0]));

FileOutputFormat.setOutputPath(job_conf, new Path(args[1]));
my_client.setConf(job_conf);
88
try {
// Run the job
JobClient.runJob(job_conf);
} catch (Exception e) {
e.printStackTrace();
}
}
}
2.La classe selectmaper.java :
import org.apache.hadoop.io.IntWritable;
public class selectmaper extends MapReduceBase implements Mapper<LongWritable, Text, Text,

IntWritable> {
private final static IntWritable one = new IntWritable(1);
public void map(LongWritable key, Text value, OutputCollector<Text, IntWritable> output,

Reporter reporter) throws IOException {
String valueString = value.toString();

String[] SingleCountryData = valueString.split(",");
if(SingleCountryData[7].equals("ADRAR"))
output.collect(new Text(SingleCountryData[0]+' '+SingleCountryData[1]+'
'+SingleCountryData[2]+' '+SingleCountryData[3]+' '+SingleCountryData[4]+'
'+SingleCountryData[5]+' '+SingleCountryData[6]+' '+SingleCountryData[7]), one);
}
}
89
3.La classe selectreducer.java :
import java.util.*;
public class selectreducer extends MapReduceBase implements Reducer<Text, IntWritable, Text,

IntWritable> {
public void reduce(Text t_key, Iterator<IntWritable> values,

OutputCollector<Text,IntWritable> output, Reporter reporter) throws IOException {
Text key = t_key;
output.collect(key,null);
}
}
90
Annexe 5 Les classes MapReduce du projection
1.La classe projection.java :
package projection;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.io.*;
import org.apache.hadoop.util.GenericOptionsParser;
public class projection {

public static void main(String[] args) throws IOException {

Path p1=new Path(args[0]);

Path p2=new Path(args[1]);
FileSystem fs = FileSystem.get(c);
if(fs.exists(p2))
fs.delete(p2, true);
JobClient my_client = new JobClient();

// Create a configuration object for the job
JobConf job_conf = new JobConf(projection.class);
// Set a name of the Job

job_conf.setJobName("projection");
// Specify data type of output key and value

job_conf.setOutputKeyClass(Text.class);
job_conf.setOutputValueClass(IntWritable.class);
/* Specify names of Mapper and Reducer Class*/

job_conf.setMapperClass(projectionmap.class);
job_conf.setReducerClass(projectionreducer.class);
91
// Specify formats of the data type of Input and output

job_conf.setInputFormat(TextInputFormat.class);
job_conf.setOutputFormat(TextOutputFormat.class);
/* Set input and output directories using command line arguments,

arg[0] = name of input directory on HDFS, and arg[1] = name of output directory to
be created to store the output file.*/
FileInputFormat.setInputPaths(job_conf, p1);
FileOutputFormat.setOutputPath(job_conf, p2);
my_client.setConf(job_conf);
try {
// Run the job
JobClient.runJob(job_conf);
} catch (Exception e) {
e.printStackTrace();
}
}
}
2.La classe projectionmape.java :
package projection;
public class projectionmap extends MapReduceBase implements Mapper<LongWritable, Text, Text,

IntWritable> {
private final static IntWritable one = new IntWritable(1);
public void map(LongWritable key, Text value, OutputCollector<Text, IntWritable> output,

Reporter reporter) throws IOException {
String valueString = value.toString();

String[] SingleCountryData = valueString.split(",");
92
output.collect(new Text(SingleCountryData[0]+' '+SingleCountryData[1]+'

'+SingleCountryData[2]+' '+SingleCountryData[3]+' '+SingleCountryData[7]), one);
}
}
3.La classe projectionreducer.java :
package projection;
import java.util.*;
public class projectionreducer extends MapReduceBase implements Reducer<Text, IntWritable,

Text, IntWritable> {
public void reduce(Text t_key, Iterator<IntWritable> values,

OutputCollector<Text,IntWritable> output, Reporter reporter) throws IOException {
Text key = t_key;
/*int frequencyForCountry = 0;
while (values.hasNext()) {
// replace type of value with the actual type of our value
IntWritable value = (IntWritable) values.next();
frequencyForCountry += value.get();
}*/
output.collect(key, null);
93
Annexe 6 Configuration VM Centos + installation
Etape 1 : Lancer Virtual box en mode administrateur :
Etape 2 : crée une nouvelle machine de type Linux version RedHat (64-bit)
94
Etape 3 : attribution de la RAM (1 Go)
Etape 04 : création de disque virtuel (dynamique) de 40 GO
95
Etape 5 : allez à configuration de la VM, sous l'onglet système et augmentez le nombre de

cœurs à 2
Etape 06 : configuration du disque virtuel de démarrage pour l'installation de Centos 7
96
Etape 07 : configuration du mode réseau a : accès par Pont
97
Etape 08 : lancement installation de Centos 7
Etape 9 : une fois la machine virtuelle hdp-node03 installée, veuillez cloner cette
dernière et renommé la : hdp-node04
Afin d'evité le serveur DHCP qu'il attribue la même adresse IP à la VM clonée

,veuillez réinitialisé l'adresse MAC de la machine :
98
Sélection le type de clone : intégrale pour créer une deuxième copie de la machine
virtuelle :
Clone en cours ….
99
Etape 10 : changer l'adresse IP de la machine / nom hosts : hsp-node04.localdomain avec

la commande nmtui
100
101
Références bibliographiques
Références bibliographiques :
Livres électroniques :
[1] Olivier BENDAVID, Bi in the Cloud, 18/06/10.
[2] Big data application and archetecteure; de himanshu et Nitin Sawant, Apress Berkely, CA, USA ©2013
[3] Big Data for Dummies, Copyright © 2013 by John Wiley , Hoboken New Jersey , Canada
[4] Hadoop The Definitive Guide.3rd.Edition, May 2012.Edition OReilly.
Thèse :
[5] Mekideche Mounir, Conception et implémentation d’un moteur de recherche à base d’une architecture
Hadoop (Big Data), Avril 2015.
PDF :
[6] Benjamin Renaut, Hadoop/Big Data, Université de Nice Sophia-Antipolis, 114p, 2013-2014.
[7] Bernard ESPINASSE, Introduction aux systèmes NoSQL (Not Only SQL), Ecole Polytechnique
Universitaire de Marseille, 19p, Avril 2013.
[8] Pierre Nerzic février-mars 2019 , France
[9] Jonathan Lejeune, Hadoop : une plate-forme d’exécution de programme Map-reduce, École des Mines de
Nantes, 83p, Janvier 2015.
[10] M.CORINUS, T.Derey, J.Marguerie, W.Techer, N.Vic, Rapport d’étude sur le Big Data, SRS Day, 54p,
2012.
Sites internet :
[11] http://www.journaldunet.com/solutions/analytics/big-data, consulté le1/03/ 2015.
[12]http://webcache.googleusercontent.com/search?q=cache:2DfXDe1Z_mEJ:www.aubay.com/fileadmin/us
er_upload/Publications_FR/Regard_Aubay__Big_Data_Web.pdf+&cd=1&hl=ar&ct=clnk&gl=dz,consulté
le 2/03/2015.
[13]http://webcache.googleusercontent.com/search?q=cache:GTE9JlAU6mAJ:www.bigdataparis.com/guide/
Guide_du_Big_Data_2013_2014.pdf+&cd=1&hl=ar&ct=clnk&gl=dz, consulté le3/03/2015.
[14]http://blog.ippon.fr/2013/05/14/big-data-la-jungle-des-differentes-distributions-open-source-hadoop/,
consulté le15/04/2015.
[15] http://mbaron.developpez.com/tutoriels/bigdata/hadoop/introduction-hdfs-map-reduce/, consulté le
27/04/ 2015.
[16] http://www.redsen-consulting.com/2013/06/big-data/, consulté le 9/06/ 2015.
[17] http://fr.wikipedia.org/wiki/Entrep%C3%B4t_de_donn%C3%A9es,consulté le 9/04/2015.
[18] http://www.technologies-ebusiness.com/langages/les-bases-no-sql, consulté le. 6/06/2015
[19] http://fr.wikipedia.org/wiki/Hadoop, consulté le 10/04/2015.
[20]http://blog.ippon.fr/2013/05/14/big-data-la-jungle-des-differentes-distributions-open-source-hadoop/,
consulté le 10/04/2015.
102
Références bibliographiques
[21]http://www.devx.com/opensource/exploring-the-hadoop-distributed-file-system-hdfs.html,consulté le
25/04/2015.
[35] F.N. Afrati and J.D. Ullman. Optimizing joins in a map-reduce environment. In EDBT’10, Proceedings
of the 13 th International Conference on Extending Database Technology, pp. 99-110, Lausanne,
Switzerland, (2010).
[41] Blanas, S., et al. A comparison of join algorithms for log processing in mapreduce. in Proceedings of the
2010 ACM SIGMOD International Conference on Management of data. 2010. ACM.
[42]. Lin, J. and C. Dyer, Data-intensive text processing with MapReduce. Synthesis Lectures on Human
Language Technologies, 2010. 3(1): p. 1-177.
[43] S.NITIN and Others. Big data application and archetecture 22/12/2013.
[44]. M. MEKIDECHE. Conception et implementation d’un moteur de recherché a base d’une architecture
hadoop (big data). Master’s thesis, Université d’Oran 1 Ahmed Ben Bella, 03/2015.
103

DML - Based - Map Reduce20190911 74762 1m5fgig With Cover Page v2

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

DML - Based - Map Reduce20190911 74762 1m5fgig With Cover Page v2

Transféré par

Droits d'auteur :

Formats disponibles

Accelerat ing t he world's research.

DML based Map-reduce

Related papers Download a PDF Pack of t he best relat ed papers 

Courses big dat a

Faculté des Sciences Exactes & Informatique

Département de Mathématique et Informatique

Soutenue le 16/07/2019 devant le jury composé de :

Mme. BELKADHI Khadija Enseignante / UHB-Chlef Président

KELLA Abdelaziz Enseignant / UHB-Chlef Examinateur

HADJ HENNI M’hammed Enseignant/ UHB-Chlef Examinateur

ARRIDJ Mohammed Enseignant/ UHB-Chlef Encadreur

Année Universitaire 2018-2019

Je dédie ce travail à mes chers parents que

dieu les garde et les protège, à ma grande famille :

frères et sœurs et leurs enfants. surtout à mes

chers enfants et que je leur souhaite de dieu de

réussir leurs études et leur vie.

1.2.3 Architecture Big Data……………..……………………………….……………..…………….………...8

1.2.5 Big Data et Datawarehouse ………………….…………………………………………….…………….9

1.2.6 Big Data et les ETL (extraction, transformation et chargement)………………………………………..11

1.2.7 Les principales technologies de Big Data …………..……………………………..…….…..………….11

1.2.8.1 Les types des bases NoSQL ……………………….………………………………………………..12

1.3 Conclusion ...…………………………………………………………………………………………..….…..15

Chapitre 2 : La Plate-forme Hadoop

2.2.1.1 Les composantes d’HDFS ........................................................................................................... 18

2.2.2.2 Architecture du Framework MapReduce (purement maître-esclave) ……………………................23

3.2.2 La sélection ………………………………………..……………………………………..…….……...36

4.3.2 Architecture virtuelle.................................................................................................................. 42

4.5 Plan d’exécution .…………………………….……………….………………………………….….…….47

4.6.2 La sélection ...……………………………….……………………………………………….……....57

4.6.3 La projection .……………………………….……………………………………………………….59

4.7 La tolérance de panne ..…………….……………………………………………………………………. 61

Figure 4.4 : Démarrage des services d’HADOOP ………………………………………………………………..…47

Figure 4.5 : Emulateur de terminal Linux pour Windows ……………………………………………………..……48

Figure 4.6 : Environnement de développement des jobs MapReduce ………………………………………............50

Figure 4.7 : Création le fichier Jar de programme ………………………………………………………………..…52

Dans le monde d’aujourd’hui de multiples acteurs de la technologie numérique produisent des

1-Indexation de données via elasticsearch (stockage et calcul sous Hadoop)

Figure 1 : Shéma d’indexation de données DAIP

Ce mémoire est organisé en six chapitres :

Chapitre 1 : Big Data

1.2. Big Data :

Figure 1.1 : Accroissement du stockage de données entre 2009 et 2020

1.2.1. Caractéristiques du BigData :

Figure 1.2 : Le Big Data, les 3 V [16]

1.2.2 Différence entre BI (Business intelligence) et Big Data :

1.2.3 Architecture Lambda de Big Data :

Figure 1.3 : Architecture Lambda de Big Data

1.2.4 Avantages de l’architecture Big Data :

1.2.5 Big Data et Datawarehouse :

Figure 1.4 : Lien entre Big Data et DW [2]

1.2.6 Big Data et les ETL (extraction, transformation et chargement) :

Figure 1.5 : Utilisation d’ETL Informatica pour Big Data [2]

1.2.7 Les principales technologies de Big Data :

1.2.8 Les Système de Gestion de Bases de Données NoSQL :

Figure 1.6 : Paradigme clé / valeur.

Figure 1.7 : Bases documentaires

Figure 1.8 : Bases orientées colonnes.

Figure 1.9 : Bases orientées graphe.

1.2.8.2 Les principales bases de données NoSQL :

Figure 2.1 : Ecosystème Hadoop

2.2.1 Le système de fichier distribué d’Hadoop HDFS :

Figure 2.2 : L’architecture d’HDFS [21]