Chapitre 4 : Présentation du Framework Hadoop

1. Historique
Hadoop a débuté avec Doug Cutting et Mike Cafarella en 2002, lorsqu’ils ont tous
deux commencé à travailler sur le projet Apache Nutch. Le projet Apache Nutch consistait à
créer un système de moteur de recherche pouvant indexer 1 milliard de pages.
En 2003, ils sont tombés sur un article décrivant l’architecture du système de fichiers
distribués de Google, appelé GFS (Google File System), publié par Google, pour stocker les
grands ensembles de données. Maintenant, ils se rendent compte que cet article peut résoudre
leur problème de stockage de fichiers très volumineux générés à cause des processus
d’exploration et d’indexation Web. Mais ce papier n’était que la demi-solution à leur problème.
En 2004, Google a publié un autre article sur la technique MapReduce, qui était la
solution pour traiter ces grands ensembles de données. Maintenant, ce papier était une autre
demi-solution pour Doug Cutting et Mike Cafarella pour leur projet Nutch. Ces deux techniques
(GFS et MapReduce) n’étaient que sur du papier blanc chez Google. Google n’a pas mis en
œuvre ces deux techniques. Doug Cutting savait grâce à son travail sur Apache Lucene (c’est
une bibliothèque logicielle de recherche d’informations gratuite et open source, écrite à
l’origine en Java par Doug Cutting en 1999) que l’open source est un excellent moyen de
diffuser la technologie à plus de personnes. Ainsi, avec Mike Cafarella, il a commencé à
implémenter les techniques de Google (GFS & MapReduce) en open source dans le projet
Apache Nutch.
En 2006, Doug Cutting a rejoint Yahoo avec le projet Nutch. Il voulait fournir au
monde un framework informatique open source, fiable et évolutif, avec l’aide de Yahoo. Donc,
chez Yahoo d’abord, il sépare les parties informatiques distribuées de Nutch et forme un
nouveau projet Hadoop (Il a donné le nom
Hadoop c’était le nom d’un éléphant jouet jaune qui appartenait au fils de Doug
Cutting. Et il était facile à prononcer et était le mot unique.) Maintenant, il voulait créer Hadoop
de manière à ce qu’il puisse bien fonctionner sur des milliers de nœuds. Alors avec GFS et
MapReduce, il a commencé à travailler sur Hadoop.
En 2007, Yahoo a testé avec succès Hadoop sur un cluster de 1000 nœuds
et a commencé à l’utiliser.
En janvier 2008, Yahoo a publié Hadoop en tant que projet open source
pour ASF (Apache Software Foundation) . Et en juillet 2008, Apache Software
 Foundation a testé avec succès un cluster de 4000 nœuds avec Hadoop.
En 2009, Hadoop a été testé avec succès pour trier un PB (PetaByte) de
données en moins de 17 heures pour gérer des milliards de recherches et indexer des
millions de pages Web. Et Doug Cutting a quitté Yahoo et a rejoint Cloudera pour
relever le défi de diffuser Hadoop dans d’autres secteurs.
En décembre 2011, Apache Software Foundation a publié Apache
Hadoop version 1.0.
Et plus tard en août 2013, la version 2.0.6 était disponible.
Et le 18 octobre 2024, Apache Hadoop version 3.4.1 est sortie.

2. Les composants de base du Framework Hadoop

Pour bénéficier de l’écosystème de Hadoop, il faut savoir combiner ses composants
que nous regroupons en trois grandes catégories :
Le système de fichier distribué, par exemple le HDFS d’Hadoop, qui gère
le stockage distribué des données et fournit la tolérance aux pannes nécessaire lors de
l’exploitation d’un cluster.
Le modèle de calcul, comme MapReduce, qui est la façon dont les
données sont parallélisées dans les nœuds du cluster.
Le gestionnaire de ressources, comme YARN, qui permet de faire tourner
plusieurs moteurs de calcul dans le cluster et d’exploiter son potentiel à son maximum.
Le dernier module est Hadoop Common qui utilise des bibliothèques
Java standards entre chaque module, afin de les faire interagir.
 Figure 1: Architecture Hadoop

2.1. Présentation du système de fichier HDFS

Le HDFS est un système de fichiers distribué, extensible et portable développé par
Hadoop à partir du GoogleFS. Écrit en Java, il a été conçu pour stocker de très gros volumes de
données sur un grand nombre de machines équipées de disques durs. Il permet l'abstraction de
l'architecture physique de stockage, afin de manipuler un système de fichiers distribué comme
s'il s'agissait d'un disque dur unique.
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.
Une architecture de machines HDFS (aussi appelée cluster HDFS) repose sur deux
types de composants majeurs : NameNode et DataNode
NameNode dans sa traduction littérale, nœud de noms, gère l'espace de
noms, l'arborescence du système de fichiers et les métadonnées des fichiers et des
répertoires. Il centralise la localisation des blocs de données répartis dans le cluster. Il
est unique mais dispose d'une instance secondaire qui gère l'historique des modifications
 dans le système de fichiers (rôle de backup). Ce NameNode secondaire permet la
continuité du fonctionnement du cluster Hadoop en cas de panne du NameNode
d'origine. Afin d’assurer la haute disponibilité de l’arborescence, un NameNode
secondaire appelé Secondary NameNode a été mis en place dans l'architecture Hadoop.
Son fonctionnement est relativement simple puisque le NameNode secondaire vérifie
périodiquement l'état du NameNode principal et copie les métadonnées via les fichiers
edits_xxx et fsimage_xxx. Si le NameNode principal est indisponible, le NameNode
secondaire prend sa place.
DataNode (les Workers) ou nœud de données, ce composant stocke et
restitue les blocs de données. Lors du processus de lecture d'un fichier, le NameNode
est interrogé pour localiser l'ensemble des blocs de données. Pour chacun d'entre eux,
le NameNode renvoie l'adresse du DataNode le plus accessible, c'est-à-dire le DataNode
qui dispose de la plus grande bande passante. Les DataNodes communiquent de manière
périodique au NameNode la liste des blocs de données qu'ils hébergent. Si certains de
ces blocs ne sont pas assez répliqués dans le cluster, l'écriture de ces blocs s'effectue en
cascade par copie sur d'autres.
Chaque DataNode sert de bloc de données sur le réseau en utilisant un protocole
spécifique au HDFS. Le système de fichiers utilise la couche TCP/IP pour la communication.
Les clients utilisent le Remote Procedure Call pour communiquer entre eux. Le HDFS stocke
les fichiers de grande taille sur plusieurs machines. Il réalise la fiabilité en répliquant les
données sur plusieurs hôtes et par conséquent ne nécessite pas de stockage RAID sur les hôtes.
Avec la valeur par défaut de réplication, les données sont stockées sur trois nœuds :
deux sur le même support et l'autre sur un support différent. Les DataNodes peuvent
communiquer entre eux afin de rééquilibrer les données et de garder un niveau de réplication
des données élevé.
 Figure 2: architecture HDFS (source: [Link]
projectdist/hadoop-hdfs/[Link] )

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

MapReduce est un patron d'architecture de développement informatique, inventé par
Google, dans lequel sont effectués des calculs parallèles, et souvent distribués, de données
potentiellement très volumineuses, typiquement supérieures en taille à un téraoctet. De la
manière la plus simple, on peut comprendre que MapReduce divise une requête en plusieurs
parties (fonction map()) et que chaque partie traite désormais les données de manière cohérente.
Vient ensuite l'étape Reduce, où les nœuds les plus bas font remonter leurs résultats au
nœud parent qui les avait sollicités. Celui-ci calcule un résultat partiel à l'aide de la fonction
Reduce (réduction) qui associe toutes les valeurs correspondantes à la même clé à une unique
paire (clé, valeur). Puis il remonte l'information à son tour.
Un cluster MapReduce utilise une architecture de type Maître-esclave où un nœud
maître dirige tous les nœuds esclaves. MapReduce possède quelques caractéristiques :
Le modèle de programmation du MapReduce est simple mais très
expressif.
 Bien qu’il ne possède que deux fonctions, map() et reduce(), elles
peuvent être utilisées pour de nombreux types de traitement des données, les fouilles de
données, les graphes… Il est indépendant du système de stockage et peut manipuler de
nombreux types de variable.
Le système découpe automatiquement les données en entrée en bloc de
données de même taille. Puis, il planifie l’exécution des tâches sur les nœuds
disponibles.
Il fournit une tolérance aux fautes à grain fin grâce à laquelle il peut
redémarrer les nœuds ayant rencontré une erreur ou affecter la tâche à un autre nœud.
Le parallélisme est invisible à l'utilisateur afin de lui permettre de se
concentrer sur le traitement des données

Figure 3: fonctionnement MapReduce (source:

[Link] )
Une fois qu'un nœud a terminé une tâche, on lui affecte un nouveau bloc de données.
Grâce à cela, un nœud rapide fera beaucoup plus de calculs qu'un nœud plus lent. Le nombre
de tâches Map ne dépend pas du nombre de nœuds, mais du nombre de blocs de données en
entrée. Chaque bloc se fait assigner une seule tâche Map. De plus, toutes les tâches Map n'ont
pas besoin d'être exécutées en même temps en parallèle, les tâches Reduce suivent la même
logique. Par exemple, si des données en entrée sont divisées en 400 blocs et qu'il y a 40 nœuds
dans le cluster, le nombre de tâches Map sera de 400. Il faudra alors 10 vagues de Map pour
réaliser le mapping des données.

Quelques faiblesses de MapReduce

La technologie est encore jeune. Elle souffre de quelques points faibles :
Elle ne supporte pas les langages haut niveau comme le SQL
 Elle ne gère pas les index. Une tâche MapReduce peut travailler une fois
les données en entrée stockées dans sa mémoire. Cependant, MapReduce a besoin
d'analyser chaque donnée en entrée afin de la transformer en objet pour la traiter, ce qui
provoque des baisses de performance.
Elle utilise un seul flot de données. MapReduce est facile à utiliser avec
une seule abstraction mais seulement avec un flot de donnée fixe. Par conséquent,
certains algorithmes complexes sont difficiles à implémenter avec seulement les
méthodes map() et reduce(). De plus, les algorithmes qui requièrent de multiples
éléments en entrée ne sont pas bien supportés car le flot de données du MapReduce est
prévu pour lire un seul élément en entrée et génère une seule donnée en sortie.

Quelques points peuvent réduire les performances de MapReduce. Avec

sa tolérance aux pannes et ses bonnes performances en passage à l'échelle, les opérations
de MapReduce ne sont pas toujours optimisées pour les entrées/sorties. De plus, les
méthodes map() et reduce() sont bloquantes. Cela signifie que pour passer à l'étape
suivante, il faut attendre que toutes les tâches de l'étape courante soient terminées.
MapReduce n'a pas de plan spécifique d'exécution et n'optimise pas le transfert de
données entre ces nœuds.

2.3. Présentation du gestionnaire de ressources YARN

YARN compte parmi les principaux composants. Cette technologie de gestion des
ressources et de planification de tâches a pour rôle d’allouer les ressources du système aux
différentes applications exécutées dans un cluster Hadoop. Elle sert aussi à planifier l’exécution
des tâches sur différentes grappes de clusters. Cette technologie est devenue un sous-projet
d’Apache Hadoop en 2012, et a été ajoutée comme une fonctionnalité clé de Hadoop avec la
mise à jour 2.0 déployée en 2013. Avant l’ajout de YARN, Hadoop ne pouvait exécuter que des
applications MapReduce.
YARN a donc beaucoup augmenté les cas d’usage potentiels du Framework. En
découplant la gestion des ressources et la planification du composant de traitement de données
de MapReduce, YARN a également permis à Hadoop de prendre en charge davantage
d’applications et de types de traitement différents.
Les principaux composants de YARN sont le ResourceManager, les NodeManagers et
les ApplicationMasters.
 Le ResourceManager est le composant maître de YARN. Il est lui-
même principalement composé d'un ordonnanceur (scheduler) et d'un gestionnaire
d'applications (ApplicationManager). L’ordonnanceur est responsable de l'allocation
des ressources (CPU, mémoire, disque, réseau, etc.) aux applications en cours
d'exécution. En ce qui concerne l'ApplicationManager, il gère l'exécution des
ApplicationMasters dans le cluster : il est responsable du démarrage des
ApplicationMasters, mais aussi de la surveillance et du redémarrage de ceux-ci sur
différents nœuds en cas de défaillance.
Les NodeManagers sont les composants travailleurs de YARN. Un
NodeManager ne gère qu'un nœud travailleur du cluster. Il est
responsable de la gestion du cycle de vie des conteneurs, il surveille leur utilisation de
ressources et en fait un rapport au ResourceManager. Il assure également la surveillance
de la santé du nœud sur lequel il s'exécute, la gestion des journaux et services auxiliaires
qui peuvent être exploités par différentes applications YARN. Le ResourceManager et
les NodeManagers forment le framework de calcul.
L’ApplicationMaster est un processus de YARN qui peut être exécuté
sur n’importe quel nœud du cluster. Il est responsable de la négociation des ressources
avec le ResourceManager et travaille avec les NodeManagers pour exécuter et surveiller
les tâches. Il y a un ApplicationMaster pour chaque application.
 Figure 4: fonctionnement YARN (source:
[Link]
big-data/ )
Il existe actuellement plusieurs types d’algorithmes d’ordonnancement prises en
charge par Capacity Scheduler dont les plus utilisés sont FIFO et FAIR.
Avec la politique FIFO, les ressources sont allouées aux applications
selon leurs ordres d’arriver dans la file d’attente. L’inconvénient de cet algorithme est
que si une application a suffisamment de requêtes, elle empêchera les autres applications
de démarrer alors qu'elles se voient d'abord allouer des ressources en tant qu'application
la plus ancienne ;
Le Completely Fair Scheduler (ordonnanceur complètement équitable)
: Contrairement au précédent ordonnanceur, CFS n'est pas basé sur des files de
processus, mais utilise un arbre implémentant une chronologie des futures exécutions
des tâches. En effet, l'arbre trie les processus selon une valeur représentative du manque
de ressources par rapport au temps qu'aurait alloué un processeur dit multitâche idéal,
sur lequel tous les processus s'exécuteraient en même temps et à la même vitesse. Ainsi,
à chaque intervention de l'ordonnanceur, il suffit à ce dernier de choisir le processus le
plus en manque de temps d'exécution pour tendre au mieux vers le comportement du
processeur multitâche idéal. De plus, l'ordonnanceur utilise une granularité temporelle
à la nanoseconde, rendant redondante la notion de tranches de temps, les unités
atomiques utilisées pour le partage du CPU entre processus.
Gestion des Priorités : Lorsque les ressources sont allouées sur plusieurs
files d'attente, celle dont la capacité relative est la plus faible obtient les ressources en
premier. Si vous êtes dans un scénario où vous souhaitez avoir une file d'attente à haute
priorité qui reçoit les ressources avant les autres, le passage à une priorité plus élevée
est un moyen simple de le faire. Aujourd'hui, l'utilisation des priorités de file d'attente
avec LLAP et Tez permet des charges de travail plus interactives car ces files d'attente
peuvent se voir attribuer des ressources à une priorité plus élevée afin de réduire la
latence finale qu'un utilisateur final peut rencontrer.

3. Présentation de quelques composants d’extension optionnels

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 en matière de fonctionnalités
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.
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 é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 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.