INSTITUT AFRICAIN D’INFORMATIQUE

*************
AFRICAN INSTITUTE OF COMPUTER SCIENCE

République du Cameroun
Centre d’Excellence Technologique PAUL BIYA
BP : 113719 Yaoundé, Cameroun
Tel: +237 242 729 957
Site web: www.iaicameroun.com
E-mail : [email protected]

EXPOSE de BigData

PRESENTATION DU
FRAMEWORK HADOOP

Classe : SR3A Groupe

Membres du Groupe :
 CELESTIN KOLWE Saïmann ;
 CHONTCHA KENGMENE Julien ;
 DJEUPA TAPET Thierry.

Sous la Supervision de : M. TANKOU Eddy

Année Académique 2023-2024

Sommaire
Sommaire..............................................................................................................................................1
Liste des figures.....................................................................................................................................2
I. Historique......................................................................................................................................3
II. Composants de base du framework hadoop.................................................................................5
III. Présentation du système de fichier HDFS..................................................................................6
IV. Présentation du modèle de calcul MapReduce............................................................................12
V. Présentation du gestionnaire de ressource YARN........................................................................20
VI. Présentation de quelques composants d’extension optionnelle..............................................24
Conclusion...........................................................................................................................................27
Table des matières...............................................................................................................................28

Page | 1
Liste des figures
Figure 1: logo de nutch............................................................................................................................3
Figure 2: Evolution du framework hadoop..............................................................................................4
Figure 3: Architecture du système de fichier HDFS................................................................................7
Figure 4: Trajet du système de fichier.....................................................................................................8
Figure 5: exécution de la phase Map()...................................................................................................14
Figure 6: Phase Shuffle().......................................................................................................................15
Figure 7: exécution de la phase reduce..................................................................................................16
Figure 8: étapes d’exécution d’un job MapReduce dans un cluster Hadoop.........................................18
Figure 9: A partir de Hadoop 2, les instances ou tâches des jobs sont exécutés chacun dans des
containers orchestrés par un orchestrateur de ressources type YARN ou Kubernetes..........................19
Figure 10: Evolution de Hadoop avec ajout de la fonctionnalité YARN...............................................20
Figure 11: Gestionnaire de YARN.........................................................................................................21

Page | 2
I. Historique
Lors de l'avènement du World Wide Web à la fin des années 90 et
au début des années 2000, les moteurs de recherche et les index furent
créés pour aider à localiser des informations pertinentes au sein de
contenus textuels. Au départ, les résultats de recherche étaient renvoyés
par des humains. Bien entendu, lorsque le nombre de pages a
augmenté à plusieurs dizaines de millions, l'automatisation est
devenue nécessaire. Les web crawlers ont alors été créés,
principalement en tant que projets de recherche universitaires. Les
moteurs de recherche comme Yahoo et AltaVista ont également
commencé à apparaître. Parmi ces moteurs de recherche, le projet open
source Nutch fut créé par Doug Cutting et Mike Cafarella. Leur objectif
était de proposer des résultats de recherche web plus rapidement
en distribuant des données et des calculs sur différents
ordinateurs pour accomplir des tâches multiples simultanément.
Dans le même temps, le moteur de recherche Google était en
développement. Ce projet était basé sur le même concept de stockage et
de traitement de données d'une façon distribuée et automatisée pour
proposer des résultats de recherche plus rapidement.

Figure 1: logo de nutch

En 2006, Cutting a décidé de rejoindre Yahoo et a emporté avec lui

le projet Nutch et les idées basées sur les premiers travaux de Google en
termes de traitement et de stockage de données distribués. Le projet
Nutch fut divisé en plusieurs parties. Les web crawlers gardèrent le
nom Nutch, tandis que le calcul et le traitement distribués

Page | 3
devinrent Hadoop (du nom de la peluche d'éléphant jaune du fils
de Cutting).
En 2008, Yahoo proposa Hadoop sous la forme d'un projet Open Source.
Aujourd'hui, le framework et son écosystème de technologies sont
gérés et maintenus par l'association non lucrative Apache
Software Foundation, une communauté mondiale de développeurs de
logiciels et de contributeurs.
Après quatre ans de développement au sein de la communauté
Open Source, Hadoop 1.0 fut proposé au public à partir de
novembre 2012 dans le cadre du projet Apache, sponsorisé par la
Apache Software Foundation. Depuis lors, le framework n'a cessé
d'être développé et mis à jour.

Figure 2: Evolution du framework hadoop

La version deuxième version Hadoop 2 a permis d'améliorer la

gestion de ressource et la planification. Elle comporte une option de
système fichier à haute disponibilité, et prend en charge Microsoft
Windows et d'autres composants afin d'étendre la polyvalence du
framework pour le traitement et l'analyse de données. Hadoop est
actuellement proposé en version 2.6.5.
Les entreprises peuvent déployer les composants Hadoop et
les packages de logiciels compatibles dans leur Data Center local.
La plupart des projets Big Data reposent toutefois sur un usage à court
terme de ressources informatiques substantielles. Ce type d'utilisation est
davantage adapté à des services de Cloud public hautement

Page | 4
scalables, comme Amazon Web Sevices, Google Cloud Platform et
Microsoft Azure.
Les fournisseurs de services Cloud prennent généralement en
charge les composants Hadoop au travers de services basiques, comme
AWS Elastic Compute Cloud et Simple Storage Services. Il existe
également des services conçus sur mesure pour les tâches
Hadoop, comme AWS Elastic MapReduce, Google Cloud Dataproc
et Microsoft Azure HDInsight.

Page | 5
II. Composants de base du framework hadoop
Le noyau ou Core Hadoop représente la base de l'écosystème de Hadoop. Il
renferme ses principales fonctionnalités pour le traitement des données. On y retrouve quatre
principaux modules à savoir le Hadoop Common, le Hadoop Distributed File System
(HDFS), le MapReduce Engine et le YARN (Yet Another Resource Negotiator).
 Hadoop Common : est un module qui dispose d'une large palette de fonctions de
base. Cela inclut notamment les données d'archives Java (JAR) qui sont nécessaires
pour démarrer Hadoop. Les composants Hadoop Common permettant de gérer des
systèmes de fichiers distribués. Bon nombre de modules se basent sur Hadoop
Common qui se sert des bibliothèques Java standards entre chaque module.
 Hadoop Distributed File System : (HDFS) est utilisé pour le stockage d'importantes
quantités de données ou data dans un cluster d'ordinateurs en charge de la
maintenance des données. Il est comparable à un système de fichier local sur un
ordinateur classique. Cependant, ses performances sont largement supérieures. Le
HDFS fait montre d'une excellente élasticité. De ce fait, le passage d'une machine à
plusieurs milliers se fait facilement. Avec le traitement des données de HDFS,
la longueur des blocs de données et leur degré de redondance sont configurables.
 Le MapReduce Engine : implémenté dans la version 1 du framework Hadoop est
l'algorithme de Google. Son rôle est de gérer les ressources et de guider le processus
de calcul. La tâche Map se charge de convertir les données en paires clés valeurs. La
tâche Reduce, quant à elle, consomme les données d'entrée, les agrège puis produit le
résultat. Le fonctionnement combiné des phases Map et Reduce permet aux fichiers
de données d'être travaillés directement sur leur lieu de stockage. De quoi réduire le
temps de calcul et minimiser la consommation excessive de la bande passante du
réseau.
 YARN : Le YARN ou MapReduce 2.0 est un négociateur de ressources qui
permettent de panifier les tâches, de surveiller les nœuds de clusters et de gérer les
ressources. Le module YARN joue le rôle d'un système opérationnel réparti afin de
gérer les ressources pour les applications Hadoop Big Data. Il possède trois
nouvelles entités à savoir : le ResourceManager, le NodeManager et
l'ApplicationMaster.

Page | 6
Page | 7
III. Présentation du système de fichier HDFS
HDFS (Hadoop Distributed File System) reprend de nombreux concepts proposés par
des systèmes de fichiers classiques comme ext2 pour Linux ou FAT pour Windows. Nous
retrouvons donc la notion de blocs (la plus petite unité que l'unité de stockage peut gérer), les
métadonnées qui permettent de retrouver les blocs à partir d'un nom de fichier, les droits ou
encore l'arborescence des répertoires.
Toutefois, HDFS se démarque d'un système de fichiers classique pour les principales raisons
suivantes.
 HDFS n'est pas solidaire du noyau du système d'exploitation. Il assure une
portabilité et peut être déployé sur différents systèmes d'exploitation. Un des
inconvénients est de devoir solliciter une application externe pour monter une unité de
disque HDFS.
 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 un système
distribué comme HDFS, chaque nœud d'un cluster correspond à un sous-ensemble du
volume global de données du cluster. Pour augmenter ce volume global, il suffira
d'ajouter de nouveaux nœuds. 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. Alors que sur des systèmes classiques, la taille
est généralement de 4 Ko, l'intérêt de fournir des tailles plus grandes permet 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 nœuds. Pour la phase de lecture, si un bloc est indisponible
sur un nœud, des copies de ce bloc seront disponibles sur d'autres nœuds.

Page | 8
 1. Architecture du système de fichier HDFS
HDFS est un composant Open source d'Apache Software Foundation qui gère les
données. HDFS a l'évolutivité, la disponibilité et la réplication comme fonctionnalités
clés. Les nœuds de nom, les nœuds de nom secondaires, les nœuds de données, les nœuds de
point de contrôle, les nœuds de sauvegarde et les blocs constituent tous l'architecture de
HDFS. HDFS est tolérant aux pannes et est répliqué. Les fichiers sont distribués sur les
systèmes de cluster à l'aide du nœud Nom et des nœuds de données. La principale différence
entre Hadoop et Apache HBase est qu'Apache HBase est une base de données non
relationnelle et Apache Hadoop est un magasin de données non relationnelles.

Figure 3: Architecture du système de fichier HDFS

a. NameNode
Tous les blocs sur DataNodes sont gérés par NameNode, appelé nœud maître. Il
remplit les fonctions suivantes :
 Surveillez et contrôlez toutes les instances DataNodes.
 Permet à l'utilisateur d'accéder à un fichier.
 Stocke tous les enregistrements de bloc sur une instance DataNode.
 Les EditLogs sont enregistrés sur le disque après chaque opération d'écriture dans le
stockage de données de Name Node. Les données sont ensuite répliquées sur tous les
autres nœuds de données, y compris le nœud de données et le nœud de données de
sauvegarde. En cas de panne du système, les EditLogs peuvent être récupérés
manuellement par Data Node.

Page | 9
  Tous les blocs des DataNodes doivent être actifs pour que tous les blocs soient
supprimés des nœuds de données.
 Par conséquent, chaque UpdateNode d'un cluster connaît chaque DataNode du cluster,
mais un seul d'entre eux gère activement la communication avec tous les
DataNodes. Puisque chaque DataNode exécute son propre logiciel, ils sont
complètement indépendants. Par conséquent, si un DataNode échoue, le DataNode
sera remplacé par un autre DataNode. Cela signifie que la défaillance d'un DataNode
n'aura pas d'impact sur le reste du cluster, puisque tous les DataNodes connaissent
chaque DataNode du cluster.
Il existe deux types de fichiers dans NameNode : les fichiers FsImage et les fichiers
EditLogs :
 FsImage : Il contient tous les détails sur un système de fichiers, y compris tous les
répertoires et fichiers, dans un format hiérarchique. On l'appelle également image de
fichier car elle ressemble à une photographie.
 EditLogs : le fichier EditLogs garde une trace des modifications qui ont été apportées
aux fichiers du système de fichiers.

Figure 4: Trajet du système de fichier

b. Secondary NameNode
Lorsque NameNode manque d'espace disque, un NameNode secondaire est activé
pour effectuer un point de contrôle. Le NameNode secondaire effectue les tâches suivantes.
 Il stocke toutes les données du journal des transactions (de toutes les bases de données
sources) dans un seul emplacement de sorte que lorsque vous souhaitez les relire, elles
se trouvent à un seul emplacement. Une fois les données stockées, elles sont

Page | 10
 répliquées sur tous les serveurs, soit directement, soit via un système de fichiers
distribué.
 Les informations stockées dans le système de fichiers sont répliquées sur tous les
nœuds du cluster et stockées dans tous les nœuds de données. Les nœuds de données
stockent les données. Les nœuds de cluster stockent les informations sur les nœuds de
cluster. Ces informations sont appelées métadonnées. Lorsqu'un nœud de données lit
les données du cluster, il utilise les métadonnées pour déterminer où envoyer les
données et de quel type de données il s'agit. Ces métadonnées sont également écrites
sur un disque dur. Les nœuds du cluster écriront ces informations si le cluster est
redémarré. Le cluster lira ces informations et les utilisera pour déterminer où envoyer
les données et de quel type de données il s'agit.
 Le FsImage peut être utilisé pour créer une nouvelle réplique de données, qui peut
être utilisée pour mettre à l'échelle les données. Si le nouveau FsImage doit être utilisé
pour créer une nouvelle réplique, cette réplication démarrera avec un nouveau
FsImage. Il existe certains cas où il est nécessaire de récupérer après un échec de
FsImage. Dans cette situation, une nouvelle FsImage doit être créée à partir d’une
ancienne. Le FsImage peut être utilisé pour créer des sauvegardes de données. Les
données stockées dans le cluster Hadoop peuvent être sauvegardées et stockées dans
un autre cluster Hadoop, ou les données peuvent être stockées sur un système de
fichiers local.
c. DataNode
Chaque machine esclave contenant des données organise un DataNode. DataNode
stocke les données au format de fichier ext3 ou ext4 sur DataNodes. Les DataNodes
effectuent les opérations suivantes :
 Les DataNodes stockent toutes les données.
 Il gère toutes les opérations demandées sur les fichiers, telles que la lecture du
contenu du fichier et la création de nouvelles données, comme décrit ci-dessus.
 Toutes les instructions sont suivies, y compris le nettoyage des données sur
DataNodes, l'établissement de partenariats, etc.
d. Backup Node
Backup nodes are used to provide high availability of the data. In case one of the
active NameNode or DataNodes goes down, the backup node can be promoted to active and
the active node switched over to the backup node. Backup nodes are not used to recover from

Page | 11
a failure of the active NameNode or DataNodes. Instead, you use a replica set of the data for
that purpose. Data nodes are used to store the data and to create the FsImage and editsLogs
files for replication. Data nodes connect to one or more replica sets of the data to create the
FsImage and editsLogs files for replication. Data nodes are not used to provide high
availability.
e. Blocks
Cette taille par défaut peut être modifiée par n'importe quelle valeur comprise entre 32
et 128 mégaoctets, en fonction des performances requises. Les données sont écrites dans les
DataNodes chaque fois qu'un utilisateur effectue une modification, et de nouvelles données
sont ajoutées à la fin du DataNode. Les DataNodes sont répliqués pour garantir la cohérence
des données et la tolérance aux pannes. Si un nœud tombe en panne, le système récupère
automatiquement les données à partir d'une sauvegarde et les réplique sur les nœuds sains
restants. Les DataNodes ne stockent pas les données directement sur les disques durs, mais
utilisent plutôt le système de fichiers HDFS. Cette architecture permet à HDFS d'évoluer
horizontalement à mesure que le nombre d'utilisateurs et les types de données
augmentent. Lorsque la taille du fichier augmente, la taille du bloc augmente
également. Lorsque la taille du fichier devient supérieure à la taille du bloc, les données les
plus volumineuses sont placées dans le bloc suivant. Par exemple, si les données font 135 Mo
et la taille du bloc est de 128 Mo, deux blocs seront créés. Le premier bloc fera 128 Mo,
tandis que le deuxième bloc fera 135 Mo. Lorsque la taille du fichier devient supérieure à
cela, les données les plus volumineuses seront placées dans le bloc suivant. Cela garantit que
la plupart des données seront toujours stockées dans le même bloc.

2. Caractéristiques du système de fichier HDFS

Voici les principaux avantages de HDFS :
 HDFS peut être configuré pour créer plusieurs répliques pour un fichier particulier. Si
une réplique échoue, l'utilisateur peut toujours accéder aux données des autres
répliques. HDFS offre la possibilité de configurer le basculement automatique en cas
de panne. Ainsi, en cas de panne matérielle ou d'erreur, l'utilisateur peut récupérer ses
données depuis un autre nœud où les données ont été répliquées. HDFS offre la
possibilité d'effectuer un basculement logiciel. Ceci est similaire au basculement
automatique ; cependant, elle est effectuée au niveau du fournisseur de
données. Ainsi, en cas de panne matérielle ou d'erreur, l'utilisateur peut récupérer ses
données depuis un autre nœud où les données ont été répliquées.

Page | 12
  L'évolutivité horizontale signifie que les données stockées sur plusieurs nœuds
peuvent être stockées dans un seul système de fichiers. L'évolutivité verticale signifie
que les données peuvent être stockées sur plusieurs nœuds. Les données peuvent être
répliquées pour garantir leur intégrité. La réplication se produit grâce à l'utilisation de
facteurs de réplication plutôt que des données elles-mêmes. HDFS peut stocker
jusqu'à 5 Po de données dans un seul cluster et gère la charge en choisissant
automatiquement le meilleur nœud de données sur lequel stocker les données. Les
données peuvent être lues/mises à jour rapidement car elles sont stockées sur plusieurs
nœuds. Les données stockées sur plusieurs nœuds via la réplication augmentent la
fiabilité des données.
 Les données sont stockées sur HDFS, et non sur le système de fichiers local de votre
ordinateur. En cas de panne, les données sont stockées sur un serveur distinct et sont
accessibles par l'application exécutée sur votre ordinateur local. Les données sont
répliquées sur plusieurs serveurs pour garantir que même en cas de panne du serveur,
vos données restent accessibles. Les données sont accessibles via un outil client tel
que le client Java, le client Python ou la CLI. L'accès aux données est accessible via
une grande variété d'outils clients. Cela permet d’accéder aux données d’une grande
variété de langages de programmation.

3. Gestion de la réplication de l’architecture HDFS

HDFS est capable de survivre aux pannes informatiques et de se remettre d'une
corruption de données. HDFS fonctionne sur le principe des doublons, donc en cas de panne,
il peut continuer à fonctionner tant qu'il y a des répliques disponibles. Lorsque l'on travaille
sur le principe des réplicas, les données sont dupliquées et stockées sur différentes machines
du cluster DHFS. Une réplique de chaque bloc est stockée sur au moins trois
DataNodes. HDFS utilise une technique appelée maintenance nameNode pour conserver des
copies sur plusieurs DataNodes. Le nameNode garde une trace du nombre de blocs qui ont
été sous- ou sur-répliqués, et ajoute ou supprime ensuite des copies en conséquence.
a. Opération d'écriture
Le processus se poursuit jusqu'à ce que tous les DataNodes aient reçu les
données. Une fois que les DataNodes ont reçu une copie du fichier, ils renvoient
l'emplacement du dernier bloc qu'ils ont reçu. Cela permet au NameNode de reconstruire le
fichier. Après avoir reçu le dernier bloc, les DataNodes informent le NameNode que le travail
est terminé. Le NameNode répond alors avec un fichier complet pouvant être utilisé par

Page | 13
l'application. Lorsqu'un fichier est divisé en segments, il doit être réassemblé pour renvoyer
les données du fichier à l'application. Le fractionnement d'un fichier en segments est une
méthode qui permet au NameNode d'optimiser sa capacité de stockage. La division d'un
fichier en segments améliore également la tolérance aux pannes et la disponibilité. Lorsque le
client reçoit un fichier fractionné, le processus est similaire à celui d'un fichier unique. Le
client divise le fichier en segments, qui sont ensuite envoyés au DataNode. DataNode 1 reçoit
le segment A et le transmet au DataNode 2 et ainsi de suite.
b. Opération de lecture
Le client envoie ensuite le fichier au réplicateur. Le réplicateur ne dispose pas de
copie du fichier et doit lire les données à partir d'un autre emplacement. En arrière-plan, les
données sont ensuite envoyées au DataNode. Le DataNode ne dispose que de métadonnées et
doit contacter les autres nœuds de données pour recevoir les données réelles. Les données
sont ensuite envoyées au réplicateur. Là encore, le réplicateur ne dispose pas de copie du
fichier et doit lire les données à partir d'un autre emplacement. Les données sont ensuite
envoyées au réducteur. Le Réducteur a une copie des données, mais une version compressée.

IV. Présentation du modèle de calcul MapReduce

Le MapReduce est d’abord et avant tout un modèle algorithmique, c’est-à-dire une
manière de penser le découpage d’un problème en tâches. Il consiste à découper le traitement
d’un fichier de données en tâches indépendantes en suivant 2 phases : une phase Map, une et
une phase Reduce. L’utilisateur spécifie une fonction de hachage Map qui transforme les
données d’entrée en paires de clés/valeurs, et une fonction de hachage Reduce qui agrège
toutes les valeurs associées à la même clé. Une phase intermédiaire entre le Map et le
Reduce, appelée shuffle trie les paires de clés/valeurs générées par clé.
Ce programme, écrit dans un style fonctionnel, est automatiquement parallélisé et
exécuté dans un cluster. Une couche logicielle installée sur le cluster
(YARN, Kubernetes ou Mesos) s’occupe des détails du partitionnement et du stockage des
données, de la planification de l’exécution du programme à travers tous les nœuds du cluster,
de la gestion des pannes, et de la gestion de la communication entre les nœuds du cluster.
Plus bas dans la chronique, nous expliquons de façon détaillée comment le MapReduce est
exécuté sur le cluster. En fait, avec le MapReduce, vous écrivez des programmes mono-
tâches, et vous obtenez le parallélisme gratuitement ! Ceci permet aux programmeurs
n’ayant aucune expérience en programmation parallèle et distribuée d’utiliser facilement les
ressources du cluster.

Page | 14
 En fait, le but véritable du MapReduce est de fournir aux développeurs, une
abstraction qui masque la complexité des opérations liées au parallélisme, la distribution des
traitements de données, la gestion de leur exécution dans le cluster, et la gestion des
défaillances qui peuvent survenir dans le cluster pendant le traitement. Le mapreduce est un
style de programmation qui facilite l’exploitation des ressources d’un cluster grâce à une
approche « divide & conquer » où tout travail sera divisé en tâches et chaque tâche sera isolée
dans un noeud et traitée par ce nœud. Maintenant que vous comprenez ce qu’est le
mapreduce, entrons dans les détails de son fonctionnement.
Attention !!! Les phases Map, Shuffle et Reduce sont complètement indépendantes. Cela
signifie que l’utilisateur n’est pas obligé d’écrire à chaque fois une phase Map, puis une
phase Reduce. Il peut écrire une phase Map sans écrire de phase Reduce.
Une fonction de hachage (hash function en anglais), est une fonction qui assigne à une
donnée d’entrée une valeur particulière. La table de hachage, générée par une fonction de
hachage, fait correspondre la donnée d’entrée à sa valeur assignée correspondante à l’aide
d’une clé.

1. Details des différentes phases du MapReduce

Le Mapreduce est un modèle algorithmique qui fournit un style de programmation
fonctionnelle type « divide & conquer » qui découpe automatiquement les traitements de
données en tâches et les isole sur les noeuds d’un cluster. Ce découpage est réalisé en 3
phases (ou 3 étapes) : une phase map(), une phase shuffle() et une phase reduce().
Regardons ensemble de très près chacune de ces phases.
a. La phase map()
Dans cette phase, le fichier de données à traiter a déjà été partitionné dans le HDFS ou
le système de fichiers distribué du cluster. A chaque partition des données est affectée une
tâche map. Ces tâches Map se sont en réalité des fonctions qui transforment la partition à
laquelle chacune est assignée en paires de clé/valeurs. La façon dont les données d’entrée
sont transformées en clé/Valeurs est à la discrétion de l’utilisateur. Attention, pour ceux qui
travaillent dans le développement des bases de données, le terme « clé » peut générer de la
confusion. Les clés générées ici ne sont pas les « clés » dans le sens de « clé primaire » des
bases de données relationnelles, elles ne sont pas uniques, ce sont juste des nombres, des
identifiants arbitraires qui sont affectés aux valeurs de la paire. La spécificité cependant est
qu’à toutes les valeurs identiques de la partition sont affecté la même clé. Pour que vous
compreniez mieux cela, prenons l’illustration du comptage de mots dans une pile de 3

Page | 15
documents. Chaque document
dans la pile est une partition stockée
dans un nœud du cluster, la fonction
avec pour argument (clé,
valeur) est définie de la façon
suivante : M(k,v) = List
(k,v) avec k la clé, qui est ici le mot
contenu dans le document, et v, la
valeur, qui représente ici la
référence du document dans
lequel est situé la clé.

Figure 5: exécution de la phase Map()

b. La phase shuffle()
Une fois que toutes les tâches Map sont achevées (c’est-à-dire lorsque tous les nœuds
du cluster ont fini d’exécuter la fonction Map qui leur a été assignée), la
phase Shuffle démarre. Cette phase consiste d’une part à trier par clé, toutes les paires
clé/valeurs générées par la phase Map, et d’autre part à regrouper dans une liste pour chaque
clé, l’ensemble de ses valeurs éparpillées à travers les nœuds auxquels a été assignée la
fonction Map. Formellement, les paires de clés/valeurs à cette phase ont la forme
suivante : (k,[v1,v2,v3,…………..,vn])

Page | 16
 Au niveau du Nœud central du cluster, un processus qui gère l’exécution des tâches
Map est actif. Ce processus, souvent appelé processus maître, connait le nombre de tâches
Reduce qu’il va y avoir. Appelons r ce nombre. L’utilisateur, lorsqu’il spécifie la fonction
MapReduce, spécifie également le nombre de tâches Reduce qui sera nécessaire pour le
traitement efficace de sa fonction. r processus exécutant les r tâches Reduce vont être
déclenchées au niveau de
r nœuds du cluster. Ces r
nœuds, chacun à
partir d’une fonction de
hachage, vont créer un
fichier chacune pour
sa tâche Reduce et
vont attribuer à ce fichier
un nombre entre 0 et r –
1. Par ailleurs,
chaque clé qui est
générée à l’issue de la
phase Map est hachée
(c’est-à-dire est associée
à un nombre entre 0 et r-1, cela permet de lui affecter à une tâche Reduce précise). Les
processus Reduce vont à l’aide de ce hachage être capables d’identifier tous les fichiers Map
qui correspondent à leur tâche Reduce et effectuer une jointure verticale de ces fichiers.
Enfin, dans le fichier joint, le cluster trie et réorganise les paires clé/valeurs sous forme
de listes de clé/valeurs. C’est cette liste qui se présente formellement sur la forme (k,
[v1,v2,v3,…………..,vn]) où (k,v1),(k,v2),(k,v3),…,(k,vn) sont les paires de clé/valeurs, avec k
la clé venant de toutes les tâches Map. La figure ci-après illustre la phase Shuffle et ce qui se
passe dans les r fichiers où se produisent le Shuffle.
Une jointure verticale est une concaténation de fichiers en lignes. Elle se différence de
la jointure classique qui concatène les fichiers de données en colonnes selon une clé unique.

Page | 17
 Figure 6: Phase Shuffle()

c. La phase Reduce()
La phase Shuffle s’achève avec la construction des r fichiers contenant les listes de
clés/valeurs qui vont servir d’arguments à la fonction Reduce. Le but de cette phase est
d’agréger les valeurs des clés reçues par le Shuffle et de joindre verticalement l’ensemble des
r fichiers pour obtenir le résultat final. L’utilisateur définit dans la fonction Reduce l’agrégat
qu’il veut utiliser, par exemple la somme, le comptage…etc., et ce qu’il souhaite faire des
résultats : soit les afficher à l’aide d’une instruction « print », soit les charger dans une base
de données ou soit les envoyer à un autre job MapReduce. Prenons l’exemple précédent et
supposons qu’on souhaite à l’aide du Reduce compter le nombre d’occurrence de chaque mot
dans l’ensemble de la pile des 3 documents. La figure ci-après illustre le résultat.

Page | 18
Figure 7: exécution de la phase reduce

Maintenant, vous avez compris conceptuellement comment le MapReduce parvient à

découper les traitements à exécuter sur un cluster en tâches parallèles. Vous avez également
compris que la programmation MapReduce consiste à écrire 2 fonctions : Map(), Reduce(),
et le système gère pour vous l’exécution parallèle, et la coordination des tâches dans le
cluster. Mais, quel est le lien avec Hadoop, et comment s’exécute-t-il dans un cluster Hadoop
? C’est ce que nous allons voir dans la partie suivante.

2. Détails de l’exécution du MapReduce dans un cluster

Hadoop
Dans cette partie, nous allons présenter succinctement les étapes d’exécution d’un
traitement MapReduce dans un cluster Hadoop. Les étapes d’exécution du MapReduce dans
un cluster Hadoop sont assez similaires aux étapes citées dans la partie précédente. Mais il
existe tout de même quelques changements stratégiques dans Hadoop.
Le traitement MapReduce écrit par l’utilisateur s’appelle un job MapReduce dans la
terminologie du cluster Hadoop et s’exécute en 7 étapes :
 Au départ, l’utilisateur configure le Job MapReduce : il écrit la fonction Map, la
fonction Reduce, spécifie le nombre r de tâches Reduce, le format de lecture du
fichier d’entrée, le format de sortie des r fichiers Reduce, éventuellement la taille des
blocs du fichier d’entrée et le facteur de réplication. Une fois que tout cela est fait et
qu’il déclenche l’exécution du job, l’orchestrateur de ressources (YARN ou
Kubernetes) démarre les r tasktrackers dans des containers au niveau des nœuds qui
vont effectuer les r tâches Reduce que l’utilisateur a spécifiées ;

Page | 19
 Le HDFS partitionne le fichier d’entrée en blocs de taille fixe, généralement 64 Mo
par bloc (sauf si l’utilisateur a spécifié une taille de bloc différente à la première
étape). Ensuite, le HDFS réplique ces blocs selon le facteur de réplication définie par
l’utilisateur (3 par défaut) et les distribue de façon redondante dans des nœuds
différents dans le cluster. Le fait de partitionner le fichier d’entrée en blocs de taille
fixe permet de répartir de façon équilibrée la charge de traitement parallèle entre les
nœuds du cluster, ce qui permet aux tâches de s’achever à peu près au même moment
dans l’ensemble des nœuds du cluster ;
 Par défaut, le l’orchestrateur déclenche M tasktrackers sur les M nœuds de données
dans lesquels ont été répartis les M partitions du fichier d’entrée, pour exécuter les
tâches Map, soit un tasktracker Map pour chaque bloc de fichier. Après, étant donné
que chaque tasktracker s’exécute dans un container au niveau du nœud, il n’est pas
exclu que plusieurs containers soient déclenchés dans le même nœud. Chaque
tasktracker lit le contenu de sa partition par rapport au format d’entrée spécifié par
l’utilisateur, le transforme par le processus de hachage définie dans la fonction Map
en paires de clés/valeurs. Ce processus de hachage s’effectue en mémoire locale du
nœud ;
 Périodiquement, dans chaque nœud, les paires de clés/valeurs sont sérialisées dans un
fichier sur le disque dur local du nœud. Ensuite ce fichier est partitionné en r régions
(correspondant aux r tâches Reduce spécifiées par l’utilisateur) par une fonction de
hachage qui va assigner à chaque région une clé qui correspond à la tâche Reduce à
laquelle elle a été assignée. Les informations sur la localisation de ces régions sont
transmises à l’orchestrateur, qui fait suivre ces informations aux r tasktrackers qui
vont effectuer les tâches Reduce ;
 Lorsque les r tasktrackers Reduce sont notifiés des informations de localisation, ils
utilisent des appels de procédures distantes (protocole RPC) pour lire depuis le disque
dur des nœuds sur lesquels les tâches Map se sont exécutées, les régions des fichiers
Map leur correspondant. Ensuite, ils les trient par clé. Notez au passage que le tri
s’effectue en mode batch dans la mémoire du tasktracker Reduce. Si les données
sont trop volumineuses, alors cette étape peut augmenter de façon significative le
temps total d’exécution du job ;
 Les tasktrackers Reduce itèrent à travers toutes les données triées et pour chaque clé
unique rencontrée, ils la passent avec sa valeur à la fonction Reduce écrite par
l’utilisateur. Les résultats du traitement de la fonction Reduce sont alors sérialisés
Page | 20
 dans le fichier ri (avec i l’indice de la tâche Reduce) selon le format de sortie spécifié
par l’utilisateur. Cette fois-ci, les fichiers ne sont pas sérialisés dans le disque dur du
nœud tasktracker, mais dans le HDFS, ceci pour des raisons de résilience (tolérance
aux pannes) ;
 Le job s’achève là, à ce stade, les r fichiers Reduce sont disponibles et Hadoop
applique en fonction de la demande de l’utilisateur, soit un « Print Ecran », soit leur
chargement dans un SGBD, soit alors leur passage comme fichiers d’entrée à un autre
job MapReduce ;

Figure 8: étapes d’exécution d’un job MapReduce dans un cluster Hadoop

La couleur jaune traduit les traitements, la verte représente la RAM, le blanc

représente les opérations d’accès à la données et les cylindres bleus les fichiers Map.
A partir de la version 2 d’Hadoop, ce schéma d’exécution change un peu, car
désormais Hadoop supporte plusieurs modèles algorithmiques au-delà du MapReduce. Cela
est possible grâce au remplacement du Job Tracker par un orchestrateur de ressources,
notamment YARN.

Page | 21
 Fondamentalement, YARN sépare le rôle d’exécution des jobs MapReduce (via les
taskTackers) de celui du suivi de la progression de l’exécution des tâches dans le cluster en
deux processus indépendants : un processus gestionnaire appelé Resource Manager, qui gère
l’utilisation des ressources du cluster, et un processus applicatif appelé Application Master,
qui gère le cycle de vie des jobs tournant sur le cluster. L’idée du YARN est que le
processus Application Master négocie avec le processus Ressource Manager les ressources
du cluster (mémoire, CPU, Disque dur, Réseau, etc.), décrites en termes de containers ;
chaque container ayant une limite mémoire qu’il ne peut pas dépasser. Des jobs de calcul
distribués tels que les jobs MapReduce, s’exécutent à l’intérieur de ces containers. Les
containers sont surveillés par des processus appelés Node Managers, exécutés sur les nœuds
de données pour s’assurer que l’application ou le job qui s’exécute dans le container n’utilise
pas plus de ressources que celles qu’il lui a été accordées.
Contrairement au Job Tracker qui gère seul tous les jobs MapReduce qui sont
exécutés dans le cluster, avec le YARN chaque instance d’application ou job possède une
Application Master, qui s’exécute pour la durée du job. En d’autres termes, il y’a autant de «
négociateur de ressources » (Resources Negotiator) ou Application Master, qu’il y’a de jobs.
C’est grâce à ce mode de fonctionnement que les orchestrateurs de ressources tels que
YARN parviennent à faire coexister dans le même cluster différents modèles de calcul
distribué et c’est également grâce à cela qu’ils peuvent exécuter de multiples jobs
simultanément, là où le JobTracker était obligé d’exécuter plusieurs jobs de façon
séquentielle. C’est important de noter que tous les orchestrateurs de ressources fonctionnent
quasiment exactement de cette façon, que ce soit Kubernetes ou Mesos.

Page | 22
Figure 9: A partir de Hadoop 2, les instances ou tâches des jobs sont exécutés chacun dans des containers orchestrés par un
orchestrateur de ressources type YARN ou Kubernetes.

Page | 23
V. Présentation du gestionnaire de ressource YARN
YARN (Yet Another Resource Négociateur) est un composant essentiel de l'écosystème
Hadoop. Il fonctionne comme une couche de gestion des ressources du cluster, responsable de
la gestion et de l'allocation des ressources telles que le processeur, la mémoire et le stockage
pour les applications distribuées exécutées sur un cluster Hadoop.

1. Pourquoi a-t-on besoin du YARN ?

L'objectif principal de YARN est de découpler les fonctionnalités de gestion des
ressources et de traitement des données en composants distincts. Cela permet à un
gestionnaire de ressources global capable de prendre en charge diverses applications de
traitement de données, telles que MapReduce, Spark, Storm, Tez et autres, de s'exécuter sur
un seul cluster.

Figure 10: Evolution de Hadoop avec ajout de la fonctionnalité YARN

Avant l'introduction de YARN, Apache Hadoop utilisait un gestionnaire de ressources

appelé MapReduce, qui servait à la fois de gestionnaire de ressources et de moteur de
traitement. Ce système était étroitement couplé au système de fichiers distribués Hadoop
(HDFS) et limité à l'exécution de tâches MapReduce uniquement. Cela rendait difficile pour
les utilisateurs d'exécuter d'autres types d'applications sur le cluster Hadoop.
Pour surmonter ces limitations, YARN a été développé. YARN sépare le moteur de
traitement et les fonctions de gestion de MapReduce, lui permettant de prendre en charge
plusieurs moteurs de traitement et applications.

Page | 24
 2. Avantages du YARN
 Gestion centralisée des ressources : YARN fournit un système de gestion centralisé
des ressources qui peut allouer et gérer dynamiquement les ressources pour différents
frameworks/applications exécutés sur le cluster Hadoop.
 Flexibilité : les capacités de planification et de gestion des ressources sont séparées du
composant de traitement des données. Cela permet d'exécuter différents types
d'applications de traitement de données sur un seul cluster.
 Meilleure utilisation du cluster : l'allocation dynamique des ressources de YARN
garantit que chaque application obtient les ressources dont elle a besoin pour
fonctionner correctement sans affecter les autres applications. De plus, les ressources
inutilisées par un framework/une application peuvent être consommées par un autre.
 Rentable : avec YARN, un cluster Hadoop « à tout faire » peut exécuter un ensemble
diversifié de charges de travail et prendre en charge une variété d'applications, ce qui
en fait une plate-forme plus efficace et plus rentable pour le traitement du Big Data.
 Mouvement de données réduit : comme il n'est pas nécessaire de déplacer les
données entre Hadoop, YARN et les systèmes exécutés sur différents clusters
d'ordinateurs, le mouvement des données est réduit.

3. Architecture et composants de YARN

Les trois éléments importants de l'architecture YARN sont :
 Resource Manager (RM)
 Application Master (AM)
 Node Managers (NM)

Figure 11: Gestionnaire de YARN

Page | 25
 a. Resource Manager(RM)
ResourceManager est un processus Java exécuté sur le nœud maître qui est responsable
de la gestion et de l'allocation des ressources telles que le processeur, la mémoire et le disque
sur le cluster Hadoop en fonction des besoins de diverses tâches.
 Suivi des ressources du cluster : il maintient une vue globale du cluster et suit
les ressources disponibles sur chaque nœud.
 Surveillance de la santé du cluster : il surveille la santé des nœuds du cluster et
gère le basculement des ressources en cas de panne de nœud.
 Allocation des ressources du cluster : il reçoit les demandes de ressources des
maîtres d'application et alloue les ressources nécessaires pour exécuter
l'application.
 Planification des tâches : voir Planificateur
 Gestion du maître d'application : voir Gestionnaire d'applications
Le ResourceManager comporte deux composants principaux :
1. Planificateur : il effectue la planification des tâches en fonction des politiques et
des priorités définies par l'administrateur.
2. Gestionnaire d'applications : il surveille la santé de l'application maître dans le
cluster et gère le basculement en cas de panne.
i. Planificateurs
Le planificateur de YARN est responsable de la planification et de la médiation des
ressources disponibles dans le cluster entre les applications soumises, conformément à une
politique définie. Il permet différentes politiques pour gérer les contraintes telles que la
capacité, l'équité et les accords de niveau de service (SLA).
Il existe trois types de politiques de planification disponibles dans YARN :
1. Planificateur FIFO : il s'agit d'un planificateur simple qui suit une approche du
premier arrivé, premier servi et convient aux clusters plus petits et aux charges de
travail simples.
2. Planificateur de capacité : il s'agit d'un planificateur qui divise les ressources du
cluster en plusieurs files d'attente, chacune avec ses propres ressources réservées
tout en étant capable d'utiliser dynamiquement les ressources inutilisées des autres
files d'attente. Il convient aux environnements multi-utilisateurs à grande échelle.
3. Fair Scheduler : il s'agit d'un planificateur conçu pour équilibrer les ressources
de manière équitable et équitable entre les tâches acceptées, sans nécessiter une

Page | 26
 quantité définie de capacité réservée. Il convient au cluster qui exécute des tâches
de tailles et de besoins en ressources variables.
ii. Gestionnaire d'applications
Le gestionnaire d’application est une interface qui maintient une liste des applications
soumises, en cours d'exécution ou terminées. Il est chargé de :
 Gestion de la soumission des tâches : Accepter les soumissions de tâches à YARN,
 Négociation des ressources pour l'ApplicationMaster : négociation du premier
conteneur pour l'exécution du maître d'application spécifique à l'application, et
 Gestion du basculement de l'ApplicationMaster : Redémarrage du conteneur maître
de l'application en cas d'échec.
b. Application Master(AM)
L'ApplicationMaster est un processus qui exécute la fonction principale/point d'entrée
d'une application, telle que le pilote Spark. Il a plusieurs responsabilités, notamment :
 Demander des ressources : négocier avec le gestionnaire de ressources pour obtenir
des ressources permettant de lancer des conteneurs pour exécuter des tâches.
 Exécution du programme Master/Driver : il exécute le programme Master/Driver,
tel que Spark Driver, qui élabore le plan d'exécution des tâches, attribue les tâches dans
les conteneurs alloués, suit l'état d'exécution des tâches, surveille la progression et gère
les échecs des tâches.
c. Node Manager(NM)
Les NodeManagers sont des processus Java qui s'exécutent sur des nœuds
esclaves/travailleurs dans un cluster Hadoop. Ils sont responsables de la gestion des
conteneurs et des ressources sur chaque nœud de travail, en fournissant un environnement
d'exécution sécurisé pour les applications et en permettant une allocation efficace et flexible
des ressources.
 Rapport sur l'état du nœud : chaque gestionnaire de nœuds s'annonce au
ResourceManager et envoie périodiquement un battement de cœur pour fournir
l'état et les informations du nœud, y compris la mémoire et les cœurs virtuels. En
cas de panne, le gestionnaire de nœuds signale tout problème au gestionnaire de
ressources, détournant les allocations de ressources vers des nœuds sains.
 Lancement de conteneurs : les gestionnaires de nœuds suivent les instructions
du ResourceManager, lancent des conteneurs sur leurs nœuds et configurent
l'environnement de conteneur avec les contraintes de ressources spécifiées.

Page | 27
  Gestion des conteneurs : les gestionnaires de nœuds gèrent le cycle de vie des
conteneurs, les dépendances, les baux, l'utilisation des ressources et la gestion des
journaux.
i. Le conteneur
Un conteneur est une unité d'allocation de ressources, une abstraction représentée sur
un nœud de travail spécifique dans un cluster Hadoop. Les conteneurs sont chargés d'exécuter
des tâches à partir d'applications, telles que des tâches MapReduce ou des tâches Spark.
Chaque conteneur dispose d'une quantité spécifique de ressources qui lui sont allouées, telles
que le processeur, la mémoire et l'espace disque, permettant à la tâche de s'exécuter dans un
environnement contrôlé et isolé.
 ResourceManager : le ResourceManager dans YARN est responsable
de l'allocation des conteneurs aux maîtres d'application en fonction de leurs
demandes de ressources. Il fournit le contexte de lancement du conteneur
(CLC) qui inclut des variables d'environnement, des dépendances, des jetons de
sécurité et des commandes pour créer le processus de lancement de l'application.
 NodeManager : Le NodeManager dans YARN est responsable du lancement des
conteneurs avec des contraintes de ressources spécifiées (CLC).
 ApplicationMasters : les Application Masters gèrent l'exécution des tâches au
sein de ces conteneurs, surveillent leur progression et gèrent tout échec ou
réaffectation de tâches.

VI. Présentation de quelques composants d’extension

optionnelle
En plus des éléments de base, l’écosystème Hadoop comprend de nombreuses
extensions qui le complètent et qui apportent beaucoup au logiciel framework en matière
de fonctionnalité et de flexibilité. De par le code source ouvert et les nombreuses interfaces,
les composants supplémentaires peuvent être intégrés à l’envi aux fonctionnalités de base.
La liste suivante dévoile une sélection des projets les plus populaires dans
l’écosystème Hadoop :
 Ambari : le projet Ambari, d’Apache, a été initié par le distributeur Hadoop
Hortonworks et complète l’écosystème avec un outil d’installation et de gestion qui
met à disposition les ressources informatiques et facilite la gestion d’Hadoop. De plus,
Ambari propose un « Step-by-Step-Wizard », une assistance à l’installation étape par

Page | 28
 étape pour Hadoop. Une interface utilisateur graphique informe du statut du système.
De plus, Ambari permet grâce au Ambari Metrics System et au Ambari Alert
Framework d’enregistrer des métriques et de configurer divers niveaux d’alarmes.
 Avro : en ce qui concerne Apache Avro, il s’agit d’un système permettant la
sérialisation de données. Avro est basé sur JSON pour définir les types de données et
les protocoles. Les données sont quant à elles sérialisées dans un format compact
binaire. Cela sert de format de transfert des données pour la communication entre les
différents nœuds Hadoop et les programmes client.
 Cassandra : Apache Cassandra est programmé en Java. Ce système de gestion de
base de données partagé est structuré pour les quantités importantes de données, qui
suit un principe non relationnel. On évoque également dans cet ensemble les bases de
données NoSQL. L’objectif de ce système en open source initialement développé pour
Facebook est de permettre un échelonnage souple pour les grandes structures Hadoop
réparties. La sauvegarde des données s’effectue sur la base d’une clé en relation avec
la valeur réelle du paramètre.
 HBase : avec HBase, il s’agit également d’une base de données ouverte NoSQL. Elle
permet en temps réel d’exécuter les accès en lecture et en écriture de grandes
quantités de données au sein d’un cluster d’ordinateurs. HBase se base sur BigTable
de Google, un système très performant de bases de données. Comparé à d’autres bases
de données NoSQL, HBase se démarque par une cohérence des données hors norme.
 Chukwa : avec Chukwa, les utilisateurs bénéficient d’un système d’analyse et de
collecte des données basé sur le framework Big Data d’Hadoop (HDFS et
MapReduce). La surveillance en temps réel est possible même avec les systèmes les
plus grands. Pour cela, Chukwa a recours à des agents qui collectent des données sur
chaque nœud à surveiller. Ces données sont par la suite transmises à des collectors et
stockées dans le HDFS.
 Flume : Apache Flume est également un service qui a été créé pour permettre la
collecte, l’agrégation et la mobilité de données log. Pour exploiter les données à des
fins de stockage et d’analyse de différentes sources vers HDFS, Flume se base sur des
formats de transport comme Apache Thrift ou Avro.
 Pig : avec Apache Pig, les utilisateurs ont recours à une plateforme d’analyse
d’importantes quantités de données. Les utilisateurs d’Hadoop bénéficient du langage
de programmation élaboré Pig Latin. Cela permet de décrire de manière abstraite le
flux de données des jobs MapReduce. Ainsi, les requêtes MapReduce ne sont plus
Page | 29
 programmées en Java, mais en Pig Latin, qui est un langage plus efficace. Les jobs
MapReduce sont simplifiés, ainsi que les analyses. À l’origine, Pig Latin a été
développé par Yahoo. L’idée réside dans le fait que tout comme les cochons (qui sont
omnivores), Pig est programmé de manière à travailler tous les types de données.
 Hive : avec Apache Hive, Hadoop propose une base de données centrale créée et
optimisée pour les analyses. Le logiciel a été développé par Facebook, et se base sur
le framework MapReduce. Avec HiveQL, Hive dispose d’une syntaxe semblable à
SQL qui permet de consulter des données sauvegardées en HDFS ou de les analyser.
C’est pourquoi Hive traduit les requêtes semblables à SQL automatiquement dans les
jobs MapReduce.
 HCatalog : Un des composants de base d’Apache Hive est HCatalog, un système de
gestion tabulaire et de métadonnées. Il permet de sauvegarder et de travailler les
données indépendamment de leur format. HCatalog décrit la structure des données et
facilite l’utilisation avec Hive ou Pig.
 Mahout : Apache Mahout est une extension de la bibliothèque Java pour
l’écosystème Hadoop. Cette application de data mining et mathématique a été pensée
pour l’apprentissage machine. Les algorithmes qui sont implémentés par Mahout pour
Hadoop permettent des opérations comme le classement, le clustering et le filtrage
collectif. En pratique, Mahout peut être utilisé pour le développement de services de
conseils à la clientèle (de type : « les clients qui ont acheté ce produit consultent
également les articles suivants »).
 Oozie : les composants optionnels de flux de travail Oozie permettent de construire
des chaînes de processus et de les automatiser en temps voulu. Ainsi, Oozie compense
le déficit du MapReduce Engine présent sur Hadoop 1.
 Sqoop : avec Apache Sqoop, il s’agit de composants logiciels qui structurent l’import
et l’export d’importantes quantités de données du Big Data du framework Hadoop. En
règle générale, les données sont stockées dans des bases de données relationnelles par
les entreprises de nos jours. Sqoop permet un échange efficace entre les systèmes de
stockage et les clusters d’ordinateurs.
 ZooKeeper : Apache ZooKeeper offre des services pour que les processus du cluster
soient coordonnés, en permettant des fonctions de sauvegarde, de répartition et
d’actualisation.

Page | 30
Conclusion
Le framework Apache Hadoop est un outil open source dédié au stockage et au
traitement de grands volumes de données. Il est particulièrement apprécié pour sa grande
capacité de mise à l’échelle, permettant à une application développée sur cette bibliothèque
logicielle de s’exécuter quelle que soit l’architecture matérielle. Hadoop combine deux
technologies principales : HDFS pour le stockage distribué de données et MapReduce pour
l’exécution de tâches de calcul sur ces données 2. Ces technologies, en constante évolution,
font de Hadoop l’un des outils les plus largement utilisés dans le domaine du Big Data.
Cependant, Hadoop a été développé pour fonctionner en mode batch, un mode de traitement
par lots qui peut ne pas convenir aux exigences de rapidité et de performances pour l’analyse
rapide de données.
En somme, malgré quelques limites, Hadoop reste un framework puissant et flexible
pour la gestion de Big Data.

Page | 31
Table des matières
Sommaire...................................................................................................................................1
Liste des figures.........................................................................................................................2
I. Historique............................................................................................................................3
II. Composants de base du framework hadoop.......................................................................5
III. Présentation du système de fichier HDFS.......................................................................6
1. Architecture du système de fichier HDFS......................................................................7
a. NameNode...................................................................................................................7
b. Secondary NameNode.................................................................................................8
c. DataNode.....................................................................................................................9
d. Backup Node...............................................................................................................9
e. Blocks........................................................................................................................10
2. Caractéristiques du système de fichier HDFS...............................................................10
3. Gestion de la réplication de l’architecture HDFS.........................................................11
a. Opération d'écriture...................................................................................................11
b. Opération de lecture..................................................................................................12
IV. Présentation du modèle de calcul MapReduce.................................................................12
1. Details des différentes phases du MapReduce..............................................................13
a. La phase map()..........................................................................................................13
b. La phase shuffle()......................................................................................................14
c. La phase Reduce().....................................................................................................15
2. Détails de l’exécution du MapReduce dans un cluster Hadoop....................................16
V. Présentation du gestionnaire de ressource YARN.............................................................20
1. Pourquoi a-t-on besoin du YARN ?...............................................................................20
2. Avantages du YARN.....................................................................................................21
3. Architecture et composants de YARN..........................................................................21
a. Resource Manager(RM)............................................................................................22
i. Planificateurs.........................................................................................................22
ii. Gestionnaire d'applications....................................................................................23
b. Application Master(AM)...........................................................................................23
c. Node Manager(NM)..................................................................................................23
i. Le conteneur..........................................................................................................24
VI. Présentation de quelques composants d’extension optionnelle....................................24
Conclusion................................................................................................................................27
Table des matières....................................................................................................................28

Page | 32