3 HADOOP
3.1 Histoire
L'histoire de Hadoop commence avec le projet Nutch,
initié par Doug Cutting en 2002. Son but était de proposer un
moteur de recherche open-source de type « crawler »,
c'est-à-dire capable de parcourir et d'indexer automatiquement
l'ensemble du web, quand les moteurs de recherche de cette époque
pratiquaient un référencement manuel des sites web.
Les quantitéscroissantes voire inattenduesde
données à stocker et à traiter devinrent une
difficulté, l'infrastructure supportant le projet Nutch ne reposaient en
effet que sur quelques machines.
En 2003, Google publia un article de recherche concernant un
système de fichiers, le GoogleFS (Sanjay Ghemawat, Howard Gobioff, and
Shun-Tak Leung, 2003). Ilse compose d'un cluster de noeuds, le rendant scalable
et distribué :
- la taille du FS n'est pas limitée et peut être
étendue par ajout d'un nouveau noeud
- la taille de chacun des fichiers qu'il contient n'est pas
limitée non plus etces fichiers sont répartis, par blocs, sur
plusieurs noeuds
Le GoogleFS est ainsi parfaitement adapté aux traitements
distribués.
En 2004, Google publia un nouvel article de recherche
concernant un framework de traitement distribué : le MapReduce
(Jeffrey Dean and Sanjay Ghemawat, 2004).
Dès 2004, les travaux de Google permirent au projet
Nutchde résoudre ses difficultés de stockage et de traitement en
concevant une implémentation open-source de GoogleFS et
MapReduce :c'est Hadoop. Ce dernier estainsi composéde son propre
composant de stockage (HadoopFS ou HDFS) et de son propre composant de
traitement (MapReduce).
D'abord utilisé par Yahoo en 2006, puis passé sous
licence Apache en 2009, la première version stable de Hadoop fut
proposée en 2011.
3.2 Le composant de
stockage (HDFS)
Tout comme le GoogleFS, le HDFS repose sur un cluster scalable
et distribué (Tom White, 2015). Il est composé d'un noeud
principal exécutant le service « NameNode »
(maître) et de plusieurs noeuds exécutant un service
« DataNode » (esclave).
Les DataNodes contiennent les fichiers découpés
en blocs. Par défaut :
- un bloc a une taille de 128MB (contre 4KB pour un FS
« classique »),
- un même bloc sera copié sur 3 DataNodes
distincts.
Le NameNodemaintient l'arborescence du système de
fichier (répertoires, fichiers et blocs composant chaque fichier) et
connaît l'emplacement (unDataNode) de chaque bloc constituant chaque
fichier.
Il s'ensuit que toute demande de lecture ou d'écriture
d'un fichier passera d'abord par le NameNode, soit pour obtenir la liste des
blocs et leurs emplacements, soit pour allouer/désallouer de nouveaux
blocs.
Ces caractéristiques impliquent que le HDFS est
optimisé pour traiter spécifiquement des fichiers de grande
taille, le plus rapidement possible. En effet, si la taille des blocs est aussi
élevée, c'est pour être en mesure de lire les fichiers
à la vitesse permise par le disque. Si ce dernier à une vitesse
de lecture de 100MB/s et un temps d'accès de 10ms, un fichier de 128MB
sera lu en 1,29s (1,28s+0,01s) et ne sera pas pénalisé pas le
temps d'accès. A contrario, la lecture de 128 fichiers de 1MB
nécessitera 2,56s (1,28s+0,01s×128) et la nécessité
de solliciter autant de DataNodes (si chaque fichier est réparti sur un
DataNode différent).
En outre, le HDFS fonctionne en mode « write-once,
read-many-times », c'est-à-dire qu'une fois
créé, un fichier ne peut être modifié, sauf pour une
opération de concaténation ou de suppression. Cela permet de
garantir la cohérence des données lorsqu'elles sont
sollicitées simultanément. De plus, la modification d'un fichier
de très grande taille serait bloquante et donc incompatible avec
l'objectif de traiter des fichiers le plus rapidement possible.
Enfin, le HDFS est tolérant aux pannes du point de vue
de ses DataNodes, puisque chaque bloc sera recopié 3 fois. En revanche,
le NameNode doit être considéré comme un « single
point of failure », dans la mesure où il stocke en
mémoire l'arborescence du système de fichier et l'emplacement de
chaque bloc. Comme un objet nécessite 150B de mémoire (quelle que
soit sa taille), une quantité élevée d'objets peut
conduire à l'arrêt du NameNode et donc à la panne du HDFS.
A titre indicatif, un milliard de fichiers nécessitent 300GB de
mémoire vive : pour chaque fichier, il faut considérer 150B
pour le fichier et 150B pour le bloc sur lequel il repose.
Le morcellement de HDFS en blocs de données de grande
taille est étudié pour être utilisé par une
application distribuée : MapReduce.
| 
