UNIVERSITE BADJI MOKHTAR – ANNABA

Faculté des Sciences de l’Ingénieur

Département Informatique

Support de cours
Big Data,
Hadoop et MapReduce

Pr. Halima BAHI

Promotion 2ème année Master

Systèmes Informatiques de Décision

Année universitaire 2018/2019

 Chapitre 1 :
Introduction au Big Data
1.1. Introduction au Big Data
Le terme Anglais « Big Data » a été proposé par John Mashey, alors expert scientifique chez
Silicon Graphics. Les big data, (grosses données, megadonnées, ou données massives), désignent
des ensembles de données qui deviennent tellement volumineux qu'ils en deviennent difficiles à
travailler avec des outils classiques de gestion de base de données ou de gestion de l'information.
La notion de Big Data est un concept qui s’est popularisé en 2012 pour traduire le fait que les
entreprises sont confrontées à des volumes de données à traiter de plus en plus considérables et
présentant un fort enjeux commercial et marketing.
Ces Grosses Données en deviennent difficiles à travailler avec des outils classiques de gestion de
base de données. Il s’agit donc d’un ensemble de technologies, d’architecture, d’outils et de
procédures permettant à une organisation de très rapidement 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.

1.2. Les frontières du Big Data

“Big Data” est un concept très difficile à définir avec précision, puisque la notion même de
“big”en termes de volumétrie des données varie d’une entreprise à l’autre. En Règle générale, on
considère du BigData quand le traitement devient trop long pour une seule machine.

Fig. 1.1. Les frontières du Big Data

Retenons que :
1 Megaoctet = 106 octets
1 Gigaoctet = 109 octets
1 Teraoctet = 1012 octets

2
1 Petaoctet = 1015 octets
1 Exaoctet = 1018 octets
1Zttaoctet = 1021 octets

1.3. Spécificités du Big Data

Comme l’expression l’indique, le « Big » Data se caractérise par la taille ou la volumétrie des
informations. Mais d’autres attributs, notamment la vitesse et le type de données, sont aussi à
considérer. En ce qui concerne le type, le Big Data est souvent rattaché à du contenu non
structuré ou semi-structuré, ce qui peut représenter un défi pour les environnements classiques de
stockage relationnel et de calcul.

1.3.1. Volume
Internet étant le principal acteur dans l’avènement du Big Data, dans une minute Internet : on a
30h Vidéo téléchargées, 204 Millions d’emails échangés et 300 milles Tweets envoyés, …
1.3.2. Variété
Dans un contexte Big Data les données sont sous forme structurée (bases de données structurée, feuilles
de calcul venant de tableur,…) et non structurée (textes, sons, images, vidéos, données de capteurs,
fichiers journaux, medias sociaux, signaux,…) qui doivent faire l’objet d’une analyse collective. On
estime à 80% les données non structurées pour 20% des données structurées.
1.3.3. Vitesse
Fait référence à la vitesse à laquelle de nouvelles données sont générées et la vitesse à laquelle les
données sont traitées par le système pour être bien analysées.
1.3.4. Véracité
La véracité fait référence à la qualité de la fiabilité et la confiance des données (données bruités,
imprécises, prédictives,…)
1.3.5. Valeur
La démarche Big Data n’a de sens que pour atteindre des objectifs stratégiques de création de
valeur pour les clients et pour l’entreprise; dans tous les domaines d’activité: commerce, industrie,
services…En effet, le succès d’un projet Big Data n'a d'intérêt aux utilisateurs que s'il apporte de
la valeur ajoutée et de nouvelles connaissances.

1.4. Les solutions Big Data

La plupart des outils et des frameworks de Big Data sont construits en gardant à l'esprit les
caractéristiques suivantes:
La distribution des données: Le grand ensemble de données est divisé en morceaux ou en petits
blocs et réparti sur un nombre N de nœuds ou de machines. Ainsi les données sont réparties sur
plusieurs nœuds et sont prêtes au traitement parallèle. Dans le monde du Big Data, ce type de

3
distribution des données est réalisé à l'aide d'un Système de Fichiers Distribués-DFS (Distributed
File System).

Fig.1.2. Distribution des données

Le traitement en parallèle: Les données distribuées obtiennent la puissance de N nombre de

serveurs et de machines où les données résident. Ces serveurs travaillent en parallèle pour le
traitement et l'analyse. Après le traitement, les données sont fusionnées pour le résultat final
recherché.
La tolérance aux pannes: En général, nous gardons la réplique d'un seul bloc (ou chunk) de
données plus qu'une fois. Par conséquent, même si l'un des serveurs ou des machines est
complètement en panne, nous pouvons obtenir nos données à partir d'une autre machine ou d’un
autre «data center».
L'utilisation de matériel standard: La plupart des outils et des frameworks Big Data ont besoin
de matériel standard pour leur travail. Donc nous n'avons pas besoin de matériel spécialisé avec
un conteneur spécial des données «RAID»1. Cela réduit le coût de l'infrastructure totale.
Flexibilité, évolutivité et scalabilité: Il est assez facile d'ajouter de plus en plus de nœuds dans
le cluster quand la demande pour l'espace augmente. De plus, la façon dont les architectures de
ces frameworks sont faites, convient très bien au scénario de Big Data.

Fig.1.3. Scalabilité verticale vs horizontale

1.5. Perspectives et domaines d’application

4
Les perspectives d’utilisation de ces données sont énormes, notamment pour l’analyse d’opinions
politiques, de tendance industrielles, la génomique, la lutte contre la criminalité et la fraude, les
méthodes de marketing publicitaire et de vente etc…

1.6. Les acteurs du Big Data

Les grands acteurs du web tel que Google, Yahoo, Facebook, Twitter, LinkedIn…ont été les
premiers à être confrontés à des volumétries de données extrêmement importantes et ont été à
l’origine des premières innovations en la matière portées principalement sur deux types de
technologies:
1. Les plateformes de développement et de traitement des données (GFS, Hadoop, Spark,…)
2. Les bases de données (NoSQL)

1.6.1. Le cas Google

Pour stocker son index grandissant, Google a mis en place un nouveau système propriétaire: GFS
(Google File Système) en 2003. C’est un algorithme inventé par Google, afin de distribuer des
traitements sur un ensemble de machines avec le système GFS. Google possède aujourd'hui plus
de 10000000 de serveurs interconnectés dans le monde.

MFD

Dir2
Dir1

Dir3

File1

File3 File2

Fig .1.4. Une arborescence GFS

5
 Chapitre 2 :
Hadoop
2.1. Généralités
En 2004, Google a développé un paradigme de programmation appelé MapReduce. Yahoo! a mis
en place Hadoop comme implémentation de MapReduce en 2005 et a fini par le lancer en tant
que projet open source en 2007.
Hadoop est une plateforme (framework) open source conçue pour
réaliser d'une façon distribuée des traitements sur des volumes de
données massives, de l'ordre de plusieurs pétaoctets. Ainsi, il est
destiné à faciliter la création d'applications distribuées et
échelonnables (scalables). Il s'inscrit donc typiquement sur le terrain
du Big Data.
À l’instar des autres systèmes opérationnels, Hadoop possède les structures de base nécessaires à
effectuer des calculs: un système de fichiers, un langage de programmation, une méthode pour
distribuer les programmes ainsi générés à un cluster, un mode pour obtenir les résultats et arriver
à une consolidation unique de ces derniers, ce qui est le but.
Avec Hadoop, le Big Data est distribué en segments étalés sur une série de nœuds s’exécutant sur
des périphériques de base. Au sein de cette structure, les données sont dupliquées à différents
endroits afin de récupérer l’intégralité des informations en cas de panne. Il s'occupe de toutes
les problématiques liées au calcul distribué, comme l’accès et le partage des données, la
tolérance aux pannes, ou encore la répartition des tâches aux machines membres du cluster: le
programmeur a simplement à s'occuper du développement logiciel pour l'exécution de la
tâche.

Hadoop assure les critères des solutions Big Data à savoir:

Performance: support du traitement d'énormes data sets (millions de fichiers, Go à To de
données totales) en exploitant le parallélisme et la mémoire au sein des clusters de calcul.
Economie: contrôle des coûts en utilisant des matériels de calcul de type standard.
Evolutivité (scalabilité): un plus grand cluster devrait donner une meilleure performance.
Tolérance aux pannes: la défaillance d'un nœud ne provoque pas l'échec de calcul.
Parallélisme de données: le même calcul effectué sur toutes les données.

2.2. Composants fondamentaux de Hadoop

Hadoop est constitué de deux grandes parties :
Hadoop Distibuted File System – HDFS : destiné pour le stockage distribué des données
Distributed Programing Framework - MapReduce : destiné pour le traitement distribué des
données.

6
 Fig. 2.1. Composants de Hadoop
2.3. Le système de fichier (HDFS)
HDFS (pour Hadoop Distributed File System) est un système de fichiers distribué associé à
Hadoop. C'est là qu'on stocke les données d'entrée, de sortie, etc.

HDFS 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. Il 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.
 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.
 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.

7
2.4. Architecture HDFS
Une architecture de machines HDFS inclut trois types de composants majeurs :
NameNode (noeud de nom) : Un Namenode est un service central (généralement appelé
aussi maître) qui s'occupe de gérer l'état du système de fichiers. Il maintient l'arborescence
du système de fichiers et les métadonnées de l'ensemble des fichiers et répertoires d'un
système Hadoop. Le Namenode a une connaissance des Datanodes dans lesquels les blocs
sont stockés.
Secondary Namenode : Le Namenode dans l'architecture Hadoop est un point unique de
défaillance (Single Point of Failure en anglais). Si ce service est arrêté, il n'y a pas un
moyen de pouvoir extraire les blocs d'un fichier donné. Pour répondre à cette problématique, un
Namenode secondaire appelé Secondary Namenode a été mis en place dans l'architecture Hadoop
version2. Son fonctionnement est relativement simple puisque le Namenode secondaire vérifie
périodiquement l'état du Namenode principal et copie les métadonnées. Si le Namenode principal
est indisponible, le Namenode secondaire prend sa place.
Datanode : Un Datanode contient les blocs de données. En effet, il stocke les blocs de données
lui-mêmes. Il y a un DataNode pour chaque machine au sein du cluster. Les Datanodes sont
sous les ordres du Namenode et sont surnommés les
Workers. Ils sont donc sollicités par les Namenodes lors des opérations de lecture et
d'écriture.

Fig.2.2. Trois types de machines de HDFS

8
2.5. Les commandes de HDFS
La commande permettant de stocker ou extraire des fichiers de HDFS est l'utilitaire
console hadoop, avec l'option fs. Il réplique globalement les commandes systèmes standard
Linux. On trouve par exemple :
 hadoop fs -put [Link] /data_input/[Link]
Permet de stocker le fichier [Link] sur HDFS dans le répertoire /data_input.
 hadoop fs -get /data_input/[Link] [Link]
Permet d’obtenir le fichier /data_input/[Link] de HDFS et le stocker dans le fichier local
[Link].
 hadoop fs -mkdir /data_input
Pour créer le répertoire /data_input
 hadoop fs -rm /data_input/[Link]
Pour supprimer le fichier /data_input/[Link]

9
 Chapitre 3 :
MapReduce
3.1. Généralités
En 2004, Google a développé un paradigme appelé MapReduce, et en 2005, Yahoo! a mis en
place Hadoop comme implémentation de MapReduce et a fini par le lancer en tant que projet
open source en 2007.
À l’instar des autres systèmes opérationnels, Hadoop possède les structures de base nécessaires à
effectuer des calculs: un système de fichiers, un langage de programmation, une méthode pour
distribuer les programmes ainsi générés à un cluster, un mode pour obtenir les résultats et arriver
à une consolidation unique de ces derniers, ce qui est le but.

3.2. Exemple introductif

Supposons qu’une entreprise possède plusieurs magasins qu’elle gère à travers le monde. Pour
cela, elle a un très grand livre de comptes qui contient TOUTES les ventes.

Objectif : Calculer le total des ventes par magasin pour l’année en cours
Supposons que les lignes du livre aient la forme suivante: Jour Ville produit Prix

2018-01-01 London Books 51.3

2018-01-01 Paris Music 22.5
2018-01-02 Rome Clothes 100.1
2018-01-02 London Clothes 46

Possibilité́ :
 Pour chaque entrée, saisir la ville et le prix de vente
 Si on trouve une entrée avec une ville déjà saisie, on les regroupe en faisant la somme des
ventes
Dans un environnement traditionnel, on fera des Hash table sous la forme <clé-valeur>
 Dans ce cas, la clé sera l’adresse du magasin et la valeur le total de ventes

10
 2018-01-01 London Books 51.3
2018-01-01 Paris Music 22.5
2018-01-02 Rome Clothes 100.1
2018-01-02 London Clothes 46

London 51.3 London 97.3

Paris 22.5 Paris 22.5
Rome 100.1 Rome 100.1

Bien qu’il est fort possible de rencontrer des problèmes de taille mémoire, et que le traitement
séquentiel s’avère long en plus du problème classique de l’ajout de nouveaux magasins, le
résultat peut s’avérer correct.
2018-01-01 London Books 51.3
2018-01-01 Paris Music 22.5
2018-01-02 Rome Clothes 100.1
2018-01-02 London Clothes 46

Clé Valeur

London 97.3
Paris 22.5
Rome 100.1

Le Map-Reduce est un moyen plus efficace et plus rapide de traiter ces données, le principe
consiste en :
 Au lieu d’avoir une seule personne qui parcourt le livre, on recruterait plusieurs.
 Appeler un premier groupe les Mappers et un autre les Reducers
 Diviser le livre en plusieurs parties, et en donner une à chaque Mapper

Les Mappers peuvent travailler en même temps, chacun sur une partie des données :
Mappers
 Pour chaque entrée, saisir la ville et le total de ventes dans une fiche
 Rassembler les fiches d’un même magasin dans une pile

11
Reducers
 Chaque reducer sera responsable d’un ensemble de magasins
 Collectent les fiches associées des différents mappers
 Pour chaque ville, ils parcourent les piles en ordre alphabétique et font la somme des
enregistrements

3.3 Le modèle de programmation MapReduce

Dans le modèle de programmation MapReduce, le développeur implémente 2 fonctions : la
fonction Map et la fonction Reduce
Fonction Map : prend en entrée un ensemble de « Clé, Valeurs » et retourne une liste intermédiaire de
«Clé1, Valeur1» :
Map(key,value) -> list(key1,value1)

Fonction Reduce : prend en entrée une liste intermédiaire de « Clé1, Valeur1 » et fournit en
sortie une ensemble de « Clé1, Valeur2 » :
Reduce(key1,list(value1)) -> value2

L’algorithme MapReduce s’exécute en 5 phases :

1. La phase Initialisation
2. La phase Map
3. La phase regroupement (Shuffle)
4. La phase de Tri
5. La phase Reduce

3.4. Fonctionnement de MapReduce

Lorsque l’application MapReduce est lancée, elle crée un composant « Master » responsable de
la distribution des données et de la coordination de l’exécution de différentes unités de travail ou
« Workers ». Le Master attribue aux Workers les tâches Map et Reduce

Un Worker possède 3 états:

 idle : il est disponible pour un nouveau traitement
 in-progress : un traitement est en cours d’exécution
 completed : il a fini un traitement, il en informe alors le Master de la taille, de la
localisation de ses fichiers intermédiaires

Le Master gère la synchronisation, la réorganisation, le tri et le regroupement des données :

12
lorsqu’un Worker de type Map a fini son traitement, le Master regroupe, trie et renvoie le résultat
à un Worker de type Reduce

Fig.3.1. Le flux MapReduce

3.5. Exemples illustratifs

3.5.1. Le comptage de mots
Imaginons qu'on nous donne un texte écrit en langue Française. On souhaite déterminer
pour un travail de recherche quels sont les mots les plus utilisés au sein de ce texte. Les données
d'entrée sont constituées du contenu du texte.
Première étape: déterminer une manière de découper (split) les données d'entrée pour que
chacune des machines puisse travailler sur une partie du texte. On décide de découper les
données d'entrée ligne par ligne. Chacune des lignes du texte sera un fragment de nos
données d'entrée.
Celui qui croyait au ciel
Celui qui n’y croyait pas
Fou qui fait le délicat
Fou qui songe à ses querelles

Il est de coutume de simplifier le travail en enlevant la ponctuation et les caractères accentués

ainsi que les majuscules. On obtient les quatre fragments suivants :
celui qui croyait au ciel

13
 celui qui ny croyait pas
fou qui fait le délicat
fou qui songe a ses querelles

D’abord, on détermine la clé à utiliser pour l’opération MAP, et écrire son code. Comme on
s'intéresse aux occurrences des mots dans le texte, la clef qu’on choisit est le mot.
L’opération MAP consiste à parcourir le fragment considéré et, pour chacun des mots, émettre le
couple clef/valeur: (MOT ; 1). Cela signifie que nous avons rencontré une fois le mot. Le pseudo
code de la fonction Map peut être :

Pour chaque mot de la ligne

emettre (mot ; 1)

Pour nos fragments, les couples (clé,valeur) ainsi générés sont :

celui qui croyait au ciel (celui ;1) (qui ;1) (croyait ;1) (au ;1) (ciel ;1)
celui qui ny croyait pas (celui ;1) (qui ;1) (ny ;1) (croyait ;1) (pas ;1)
fou qui fait le délicat (fou ;1) (qui ;1) (fait ;1) (le ;1) (délicat ;1)
fou qui songe a ses querelles (fou ;1) (qui ;1) (songe ;1) (a ;1) (ses ;1) (querelles ;1)

Une fois l’opération « Map » achevée, un mécanisme intermédiaire permet de regrouper les
couples par clé commune ; on obtient :
(celui ;1) (celui ;1)
(qui ;1) (qui ;1) (qui ;1) (qui ;1)
(croyait ;1) (croyait ;1)
(fou ;1) (fou ;1)
(au ;1)
(ciel ;1)
etc.
La fonction « Reduce » considère chacun des groupements de clés où elle va opérer à une somme.
Le pseudo code peut être :

Total=0
Pour chaque Couple dans Groupe
Total=Total+1
emettre(mot ; total)

A la fin de l’opération, on obtient pour chaque mot son nombre d’apparition dans le texte.

14
(celui ;2)
(qui ;4)
(croyait ;2)
(au ;1)
(ciel ;1)
etc.

Fig. 3.2. Flux de données MapReduce avec 1 seule tâche Reduce

3.5.2. Longueur moyenne des mots

On s’intéresse maintenant à calculer la longueur moyenne des mots dans un texte. On procède
alors au découpage comme précédemment au texte d’entrée en lignes. Pour chaque ligne, on
calcule le nombre de mots et la longueur de la ligne (ie le nombre de caractères). La longueur
moyenne se fait selon la formule :
𝑛
1
𝜇 = ∑ 𝑥𝑖
𝑛
1
L'entrée de Map est un ensemble de mots {w} d'un fragment du texte, la fonction « Map » calcule
le nombre de mots dans le fragment et la longueur totale des mots. La sortie de la fonction
« Map » contient deux couples : <“count”, #mots> et <“length”, longueur totale>.
L'entrée de Reduce est un ensemble {<clé, {valeur}>}, où clé = “count” ou “length” et valeur est
un entier. La fonction « Reduce » calcule le nombre total de mots : N = somme de toutes les
valeurs “count” et la longueur totale des mots : L = somme de toutes les valeurs “length”
La sortie « Reduce » est <“count”, N> et <“length”, L>, Le résultat est obtenu en faisant la
division μ=L/N.
Fig..3.3. Flux de données MapReduce avec 2 tâches Reduce

16
 Chapitre 4 :
Mise en œuvre de MapReduce sous Hadoop
4.1. Architecture MapReduce de Hadoop
Comme pour HDFS, la gestion des tâches de Hadoop se base sur deux serveurs (des
daemons):
 Le JobTracker, qui va directement recevoir la tâche à exécuter (un .jar Java), ainsi
que les données d'entrées (nom des fichiers stockés sur HDFS) et le répertoire où stocker
les données de sortie (toujours sur HDFS). Il y a un seul JobTracker sur une seule
machine du cluster Hadoop. Le JobTracker est en communication avec le
NameNode de HDFS et sait donc où sont les données.
 Le TaskTracker, qui est en communication constante avec le JobTracker et va recevoir les
opérations simples à effectuer (MAP/REDUCE) ainsi que les blocs de données
correspondants (stockés sur HDFS). Il y a un TaskTracker sur chaque machine du
cluster.

Comme le JobTracker est conscient de la position des données (grâce au

NameNode), il peut facilement déterminer les meilleures machines auxquelles attribuer
les sous-tâches (celles où les blocs de données correspondants sont stockés).
Pour effectuer un traitement Hadoop, on va donc stocker nos données
d'entrée sur HDFS, créer un répertoire où Hadoop stockera les résultats
sur HDFS, et compiler nos programmes MAP et REDUCE au sein d'un
.jar Java.

Fig. 4.1. Architecture logicielle MapReduce de Hadoop

17
On soumettra alors le nom des fichiers d'entrée, le nom du répertoire des résultats, et le .jar lui-
même au JobTracker: il s'occupera du reste (et notamment de transmettre les programmes
MAP et REDUCE aux serveurs TaskTracker des machines du cluster).
L'entrée de MapReduce doit être fait à partir de fichiers dans HDFS où Chaque bloc contient une
liste de pairs clé-valeur.

4.1.1. Le JobTracker
Le déroulement de l'exécution d'une tâche Hadoop suit les étapes suivantes du point de vue du
JobTracker :
1. Le client (un outil Hadoop console) va soumettre le travail à effectuer au JobTracker : une
archive java .jar implémentant les opérations Map et Reduce. Il va également
soumettre le nom des fichiers d'entrée et l'endroit où stocker les résultats.
2. Le JobTracker communique avec le NameNode HDFS pour savoir où se trouvent les
blocs correspondant aux noms de fichiers donnés par le client.
3. Le JobTracker, à partir de ces informations, détermine quels sont les nœuds
TaskTracker les plus appropriés, c'est à dire ceux qui contiennent les données sur
lesquelles travailler sur la même machine, ou le plus proche possible (même rack/rack
proche).
4. Pour chaque « morceau » des données d'entrée, le JobTracker envoie au TaskTracker
sélectionné le travail à effectuer (MAP/REDUCE, code Java) et les blocs de données
correspondants.
5. Le JobTracker communique avec les noeuds TaskTracker en train d'exécuter les
tâches. Ils envoient régulièrement un « heartbeat », un message signalant qu'ils
travaillent toujours sur la sous-tâche reçue. Si aucun heartbeat n'est reçu dans une
période donnée, le JobTracker considère la tâche comme ayant échouée et donne le
même travail à effectuer à un autre TaskTracker.
6. Si par hasard une tâche échoue (erreur java, données incorrectes, etc.), le TaskTracker va
signaler au JobTracker que la tâche n'a pas pu être exécutée.
7. Le JobTracker va alors décider de la conduite à adopter :
 Demander au même TaskTracker de ré-essayer.
 Redonner la sous-tâche à un autre TaskTracker.
 Marquer les données concernées comme invalides, etc.
 Il pourra même blacklister le TaskTracker concerné comme non-fiable dans certains
cas.
8. Une fois que toutes les opérations envoyées aux TaskTracker (MAP + REDUCE) ont été
effectuées et confirmées comme effectuées par tous les noeuds, le JobTracker
marque la tâche comme « effectuée ». Des informations détaillées sont disponibles
(statistiques, TaskTracker ayant posé problème, etc.).

Remarques:
Par ailleurs, on peut également obtenir à tout moment de la part du JobTracker des informations
sur les tâches en train d'être effectuées: étape actuelle (MAP, SHUFFLE, REDUCE), pourcentage
de complétion, etc.

18
4.1.2. Le TaskTracker
Le TaskTracker dispose d'un nombre de « slots » d'exécution. A chaque « slot »
correspond une tâche exécutable (configurable). Ainsi, une machine ayant par exemple un
processeur à 8 cœurs pourrait avoir 16 slots d'opérations configurées.
Lorsqu'il reçoit une nouvelle tâche à effectuer (MAP, REDUCE, SHUFFLE) depuis
le JobTracker, le TaskTracker va démarrer une nouvelle instance de Java avec le
fichier .jar fourni par le JobTracker, en appelant l'opération correspondante.
Une fois la tâche démarrée, il enverra régulièrement au JobTracker ses messages
heartbeats. En dehors d'informer le JobTracker qu'il est toujours fonctionnels, ces messages
indiquent également le nombre de slots disponibles sur le TaskTracker concerné.
Lorsqu'une sous-tâche est terminée, le TaskTracker envoie un message au
JobTracker pour l'en informer, que la tâche se soit bien déroulée ou non (il indique
évidemment le résultat au JobTracker)
4.1.3. Architecture Hadoop
De manière similaire au NameNode de HDFS, il n'y a qu'un seul JobTracker et s'il
tombe en panne, le cluster tout entier ne peut plus effectuer de tâches. Des résolutions aux
problèmes sont ajoutées dans la version 2 de Hadoop.
Généralement, on place le JobTracker et le NameNode HDFS sur la même machine (une
machine plus puissante que les autres), sans y placer de TaskTracker/DataNode HDFS
pour limiter la charge. Cette machine particulière au sein du cluster (qui contient les deux «
gestionnaires», de tâches et de fichiers) est communément appelée le noeud maître («Master
Node »). Les autres noeuds (contenant TaskTracker + DataNode)
sont communément appelés noeuds esclaves (« slave node »).

Fig. 4.2. Architecture Hadoop

19
4.2. Exemple illustratif
Les données: Les données utilisées pour cet exemple proviennent du National Climatic Data
Center, les données sont stockées sous forme de lignes ASCII, où chaque ligne représente un
enregistrement. Chaque enregistrement comporte un certain nombre d’informations
météorologiques, certaines sont optionnelles ou de longueur variable, mais nous ne nous
intéresserons qu’à la température qui est toujours présente et a une largeur de champ fixe.

Fig. 4.2. Format d’un enregistrement de la NCDC

Les fichiers de données sont organisés par date et par station d’observation. Il y’a un répertoire
pour les données pour chaque année. Exemple pour 1990:
% ls raw/1990 | head
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]
[Link]

20
Pour cet exemple les données sont présentées à la fonction Map sous forme de paire clé-valeur
(offset/ligne):
(0, 0067011990999991950051507004…9999999N9+00001+99999999999…)
(106, 0043011990999991950051512004…9999999N9+00221+99999999999…)
(212, 0043011990999991950051518004…9999999N9-00111+99999999999…)
(318, 0043012650999991949032412004…0500001N9+01111+99999999999…)
(424, 0043012650999991949032418004…0500001N9+00781+99999999999…)

La fonction Map va seulement extraire la température pour chaque année.

(1950, 0)
(1950, 22)
(1950, −11)
(1949, 111)
(1949, 78)
…
Avant d’être envoyé au Reducer, la sortie de la fonction Map sont groupés et triés par clé/valeur.
On obtient pour l’exemple précédent:
(1949, [111, 78])
(1950, [0, 22, −11])

Parmi ces listes les fonctions reduce renvoient le maximum.

(1949, 111)
(1950, 22)

4.3. Mise en œuvre sous Hadoop

La programmation d’un job MapReduce en Java nécessite de définir trois classes :
 Une sous-classe de Mapper. Elle contient une seule méthode, appelée map qui reçoit une
paire clé-valeur en paramètre. Elle génère un nombre quelconque de paires.
 Une sous-classe de Reducer. Elle contient également une seule méthode, appelée reduce
qui reçoit une liste de paires en paramètre. Elle génère une seule paire.
 Une classe générale qui crée un Job faisant référence aux deux précédentes classes.

Les deux premières sont des patrons (templates) paramétrées par les types des clés et des valeurs.

21
4.3.1. Les types de données MapReduce
La classe Mapper est paramétrée par 4 types. Ce ne sont pas les types standard de Java, mais des
types spéciaux permettant de transmettre efficacement des données entre les différents
ordinateurs du cluster.

Type Description
Text Chaîne UTF-8
BooleanWritable Booléen
IntWritable Entier 32 bits
LongWritable Entier 64 bits
FloatWritable Réel 32 bits
DoubleWritebale Réel 64 bits

Les types Text, IntWritable. . . sont des implémentations d’une interface appelée Writable. Cette
interface comprend :
 un constructeur. On peut mettre la valeur initiale en paramètre. IntWritable
val = new IntWritable(34);
 un modificateur : void set(nouvelle valeur);
[Link](35);
 un accesseur : type get()
int v = [Link]();

L’interface Writable permet la sérialisation, c’est à dire l’écriture d’une structure de données sous forme
d’octets et l’opération inverse, la dé-sérialisation qui permet de reconstruire une structure de données à
partir d’octets.
La sérialisation est nécessaire pour échanger des données entre machines. On ne peut pas
simplement échanger les octets internes car les machines du cluster ne sont pas obligatoirement
toutes pareilles : nombre d’octets, ordre des octets. . .

Writable contient deux méthodes :

 void write(DataOutput out) : sérialisation
 void readFields(DataInput in) : dé-sérialisation

La classe Text permet de représenter n’importe quelle chaîne. Elle possède quelques méthodes à
connaître :

22
  String toString() extrait la chaîne Java
 int getLength() retourne la longueur de la chaîne
 int charAt(int position) retourne le code UTF8 (appelé point) du caractère présent à cette
position

La méthode reduce reçoit une collection de valeurs venant du Mapper. CleI et ValeursI sont les
clés et valeurs intermédiaires. Il faut itérer sur chacune pour produire la valeur de sortie du
réducteur.
Comme pour map, la classe est paramétrée par les types des clés et des valeurs à manipuler. Ce
sont des Writable : Text, IntWritable. . .
Il est obligatoire que les types des clés TypCleI et valeurs d’entrée TypValI du réducteur soient
exactement les mêmes que les types des clés et valeurs de sortie du mapper. Si vous mettez des
types différents, ça passe à la compilation mais il y’aura erreur à l’exécution.

4.3.2. La classe Map

La fonction Map est structuré selon le format suivant :

public class TraitementMapper

extends Mapper<TypCleE , TypValE , TypCleI, TypValI>
{
@Override
public void map(TypCleE cleE, TypValE valE, Context context)
throws Exception
{
/** traitement: cleI = ..., valI = ... **/
TypCleI cleI = new TypCleI(...);
TypValI valI = new TypValI(...);
[Link](cleI, valI);
}
}

Pour l’exemple de la température maximale, la fonction Map s’écrit en Java, comme suit :

23
4.3.3. La fonction Reduce
La fonction Map est structuré selon le format suivant :

public class TraitementReducer

extends Reducer<TypCleI,TypValI, TypCleS,TypValS>
{
@Override
public void reduce(TypCleI cleI, Iterable<TypValI> listeI,
Context context) throws Exception
{
TypCleS cleS = new TypCleS();
TypValS valS = new TypValS();
for (TypValI val: listeI) {
/** traitement: [Link](...), [Link](...) **/
}
[Link](cleS, valS);
}
}

24
Pour l’exemple de la température maximale, la fonction Reduce s’écrit en Java, comme suit :

4.3. La classe principale

Dans un Job MapReduce les classes Map et Reduce sont utilisé via la classe qui implémente le
Job. Voici la classe principale qui crée et lance le job MapReduce :
public class Traitement extends Configured implements Tool
{
public int run(String[] args) throws Exception
{
/* */
}
public static void main(String[] args) throws Exception
{
if ([Link] != 2) [Link](-1);
Traitement traitement = new Traitement();
[Link]( [Link](traitement, args) );
}
}
Pour l’exemple de la température maximale, la fonction « main » s’écrit en Java, comme suit :

25
Un objet Job constitue la spécification du job et vous donne le contrôle sur la façon dont le job est
exécuté. Lorsque nous exécutons ce job sur un cluster Hadoop, nous le paquetons dans un fichier
JAR (que Hadoop distribuera au travers du cluster). Plutôt que de spécifier explicitement nom du
fichier JAR, nous pouvons passer une classe dans la méthode setJarByClass () du Job, que
Hadoop utilisera pour localiser le fichier JAR approprié en recherchant le fichier JAR contenant
cette classe.
Après avoir construit un objet Job, nous spécifions les chemins d'entrée et de sortie. Un chemin
d'entrée est spécifié en appelant la méthode statique addInputPath () sur FileInputFormat, et il
peut être un seul fichier, un répertoire (dans ce cas, l'entrée forme tous les fichiers dans ce
répertoire), ou un modèle de fichier. Comme son nom l'indique, addInputPath () peut être appelé
plus d'une fois pour utiliser des entrées provenant de plusieurs chemins.

26
Le chemin de sortie (dont il n'y en a qu'un) est spécifié par la static setOutputPath () méthode sur
FileOutputFormat. Il spécifie un répertoire où les fichiers de sortie du Reducer sont écrits. Le
répertoire ne doit pas exister avant d'exécuter le travail, car Hadoop ne va pas exécuter le travail.
Cette précaution vise à prévenir la perte de données.
Ensuite, nous spécifions les types du Mapper et du Reducer via setMapperClass () et Méthodes
setReducerClass ().
Les méthodes setOutputKeyClass () et setOutputValueClass () contrôlent les types de sortie pour
la fonction Reduce, et doit correspondre à ce que la classe Reduce produit. La sortie de la
fonction Map sont par défaut ceux de la fonction Reduce, ainsi si le Mapper produit le m^me type
de sorite que le Reducer, ils n’ont pas besoin d'être définis (comme c'est le cas ici ). Cependant,
s'ils sont différents, les types de sortie du Map doivent être définis à l'aide de
setMapOutputKeyClass () et Méthodes setMapOutputValueClass ().
Les types d'entrée sont contrôlés via le format d'entrée, que nous n'avons pas explicitement défini
parce que nous utilisons le TextInputFormat par défaut.
Après avoir défini les classes qui définissent les fonctions Map et Reduce, nous sommes prêts à
exécuter le job. La méthode waitForCompletion () sur Job soumet le travail et attend qu'il se
termine.
Le seul argument de la méthode est un drapeau indiquant si la sortie verbeuse est généré. Lorsque
la valeur est true, le travail écrit des informations sur sa progression dans la console.
La valeur de retour de la méthode waitForCompletion () est un booléen indiquant le succès (true)
ou failure (false), que nous traduisons par le code de sortie 0 ou 1 du programme.

Lancement du job:
$ export HADOOP_CLASSPATH=[Link]
$ hadoop MaxTemperature input/ncdc/[Link] output

27
 Chapitre 5 :
Les bases de Données NoSQL
5. 1. Introduction
L’essor des très grandes plateformes et applications Web (Google, Facebook, Twitter, LinkedIn,
Amazon, …) et le volume considérable de données à gérer par ces applications nécessitant une
distribution des données et leur traitement sur de nombreux serveurs : « Data Centers » ; ces
données étant souvent associées à des objets complexes et hétérogène ont montré les limites des
SGBD traditionnels (relationnels et transactionnels) basés sur SQL.
Ainsi, de nouvelles approches de stockage et de gestion des données sont apparues, permettant
une meilleure scalabilité dans des contextes fortement distribués et offrant une gestion d’objets
complexes et hétérogènes sans avoir à déclarer au préalable l’ensemble des champs représentant
un objet.
Ces approches regroupées derrière le terme NoSQL (proposé par Carl Strozzi) ne se substituent
pas aux SGBD Relationnels mais les complètent en comblant leurs faiblesses (Not Only SQL).

5.2. Limites des SGBD relationnels

Les SGBD Relationnels offrent un système de jointure entre les tables permettant de construire
des requêtes complexes impliquant plusieurs entités ainsi qu’un système d’intégrité référentielle
permettant de s’assurer que les liens entre les entités sont valides. Dans un contexte fortement
distribué, ces mécanismes ont un coût considérable. En effet, avec la plupart des SGBD
relationnels, les données d’une BD liées entre elles sont placées sur le même nœud du serveur. Si
le nombre de liens important, il est de plus en plus difficile de placer les données sur des noeuds
différents.
D’autre part, les SGBD Relationnels sont généralement transactionnels et la gestion de
transactions respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability).
Dans un contexte fortement distribué, cette gestion a un coût considérable car il est nécessaire de
distribuer les traitements de données entre différents serveurs, il devient alors difficile de
maintenir les contraintes ACID à l’échelle du système distribué entier tout en maintenant des
performances correctes. De ce fait, la plupart des SGBD « NoSQL » relâchent les contraintes
ACID, ou même ne proposent pas de gestion de transactions.

5.3. Caractéristiques générales des BD NoSQL

Les BD NoSQL :
 Adoptent une représentation de données non relationnelle
 ne remplacent pas les BD relationnelles mais sont une alternative, un complément
apportant des solutions plus intéressantes dans certains contextes
 apportent une plus grande performance dans le contexte des applications Web avec des
volumétries de données exponentielle
 utilisent une très forte distribution de ces données et des traitements associés sur de
nombreux serveurs
29
  font un compromis sur le caractère « ACID » des SGBDR pour plus de scalabilité
horizontale et d’évolutivité.
L’adoption croissante des bases NoSQL par des grands acteurs du Web (Google, faceBook, …)
favorise la multiplication des offres de systèmes NoSQL.

5.4. Fondements des systèmes NoSQL

Les systèmes NoSQL se fondent sur les éléments suivants :
5.4.1. Le Sharding
Le « Sharding » est un ensemble de techniques qui permet de répartir les données sur plusieurs
machines pour assurer la scalabilité de l’architecture. C’est un mécanisme de partitionnement
horizontal (par tuples) des données dans lequel les objets-données sont stockées sur des nœuds
serveurs différents en fonction d’une clé (ex : fonction de hachage).
Certains systèmes utilisent aussi un partitionnement vertical (par colonnes) dans lequel des
parties d'un enregistrement sont stockées sur différents serveurs.
5.4.2. Le « Consistent hashing»
Le « Consistent hashing» est un mécanisme de partitionnement (horizontal) dans lequel les objet-
données sont stockés sur des nœuds-serveurs différents en utilisant la même fonction de hachage
à la fois pour le hachage des objets et le hachage des nœuds.
5.4.3. Le « Map Reduce »
Le « Map Reduce » est un modèle de programmation parallèle permettant de paralléliser tout un
ensemble de tâches à effectuer sur un ensemble de données,
5.4.4. Le MVCC
Le « MVCC » (Contrôle de Concurrence Multi-Version) est un mécanisme permettant d’assurer
le contrôle de concurrence,
5.4.5. Le « Vector – Clock »
Le « Vector-Clock» ou horloges vectorielles permet des mises à jours concurrentes en datant les
données par des vecteurs d’horloge.
4.5. Typologie des BD NoSQL
Selon la représentation adopté pour les données, différents types de BD NoSQL existent :
« Clé-valeur / Key-value » : basique, chaque objet est identifié par une clé unique constituant la
seule manière de le requêter.
 Voldemort, Redis, Riak, …
« Colonne / Column » : permet de disposer d'un très grand nombre de valeurs sur une même
ligne, de stocker des relations « one-to-many », d’effectuer des requêtes par clé (adaptés au
stockage de listes : messages, posts, commentaires, ...)
 HBase, Cassandra, Hypertable, …

30
« Document » : pour la gestion de collections de documents, composés chacun de champs et de
valeurs associées, valeurs pouvant être requêtées (adaptées au stockage de profils utilisateur).
 MongoDBn, CouchDB, Couchbase, …
« Graphe » : pour gérer des relations multiples entre les objets (adaptés au données issues de
réseaux sociaux, …)
 Neo4j, OrientDB, …

5.5. HBase
HBase est un système de stockage efficace pour des données très volumineuses. Il permet
d’accéder aux données très rapidement même quand elles sont gigantesques. Une variante de
HBase est notamment utilisée par FaceBook pour stocker tous les messages SMS, email et chat.

Fig.5.1. HBase dans l’écosystème Hadoop

5.5.1. Présentation

HBase mémorise des n-uplets constitués de colonnes (champs). Les n-uplets sont identifiés par
une clé. À l’affichage, les colonnes d’un même n-uplet sont affichées successivement : Clés,
Colonnes et Valeurs.
isbn7615 colonne=auteur valeur="Jules Verne"
isbn7615 colonne=titre valeur="De la Terre à la Lune"
isbn7892 colonne=auteur valeur="Jules Verne"
isbn7892 colonne=titre valeur="Autour de la Lune"

31
Pour obtenir une grande efficacité, les données des tables HBase sont séparées en régions. Une
région contient un certain nombre de n-uplets contigus (un intervalle de clés successives).
Une nouvelle table est mise initialement dans une seule région. Lorsqu’elle dépasse une certaine
limite, elle se fait couper en deux régions au milieu de ses clés. Et ainsi de suite si les régions
deviennent trop grosses.
Chaque région est gérée par un Serveur de Région (Region Server). Ces serveurs sont distribués
sur le cluster, ex: un par machine. Un même serveur de région peut s’occuper de plusieurs
régions de la même table. Au final, les données sont stockées sur HDFS.

Fig. 5.2. Tables et régions de HBase

5.5.2. Structure de données
Au plus haut niveau, une table HBase est un dictionnaire <clé, n-uplet> trié sur les clés,
 Chaque n-uplet est une liste de familles,
 Une famille est un dictionnaire <nomcolonne, cellule> trié sur les noms de colonnes
(aussi appelées qualifier),
 Une cellule est une liste de (quelques) paires <valeur, date>.
 La date, un timestamp permet d’identifier la version de la valeur.
Donc finalement, pour obtenir une valeur isolée, il faut fournir un quadruplet :
(clé, nomfamille, nomcolonne, date)
Si la date est omise, HBase retourne la valeur la plus récente.

5.5.3. Nature des clés

Les familles et colonnes constituent un n-uplet. Chacun est identifié par une clé.

32
Les clés HBase sont constituées de n’importe quel tableau d’octets : chaîne, nombre. . . En fait,
c’est un point assez gênant quand on programme en Java avec HBase, on doit tout transformer en
tableaux d’octets : clés et valeurs. En Java, ça se fait par :
final byte[] octets = [Link](donnée);
Si on utilise le shell de HBase, alors la conversion des chaînes en octets et inversement est faite
implicitement.
Les n-uplets sont classés par ordre des clés et cet ordre est celui des octets. C’est donc l’ordre
lexicographique pour des chaînes et l’ordre des octets internes pour les nombres. Ces derniers
sont donc mal classés à cause de la représentation interne car le bit de poids fort vaut 1 pour les
nombres
négatifs ; -10 est rangé après 3.
Par exemple, si les clés sont composées de "client" concaténée à un numéro, le classement sera :
client1
client10
client11
client2
Client3
Il faudrait écrire tous les numéros sur le même nombre de chiffres.
Pour retrouver rapidement une valeur, il faut bien choisir les clés. Il est important que des
données connexes aient une clé très similaire.
Par exemple, on veut stocker des pages web. Si on indexe sur leur domaine, les pages vont être
rangées n’importe comment. La technique consiste à inverser le domaine, comme un package
Java.
URL URL inversé

[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]

Même chose pour les dates : AAAAMMJJ

5.5.4. Exemple
On veut enregistrer les coordonnées et les achats de clients. On va construire une table contenant
trois familles:

33
  La famille personne contiendra les informations de base:
 colonnes personne:nom et personne:prenom
 La famille coords contiendra l’adresse :
 colonnes coords:rue, coords:ville, coords:cp, coords:pays
 La famille achats contiendra les achats effectués :
 colonnes achats:date, achats:montant, achats:idfacture

HBase autorise à dé-normaliser un schéma (redondance dans les informations) afin d’accéder aux
données plus rapidement.

5.5.5. Les commandes de base

[Link]. Création d’une table
 create 'NOMTABLE', 'FAMILLE1', 'FAMILLE2'...
D’autres propriétés sont possibles, par exemple VERSIONS pour indiquer le nombre de versions
à garder.
Remarques :
 Les familles doivent être définies lors de la création. C’est coûteux de créer une
famille ultérieurement.
On ne définit que les noms des familles, pas les colonnes. Les colonnes sont créées
dynamiquement.

[Link]. Destruction d’une table

C’est en deux temps, il faut d’abord désactiver la table, puis la supprimer :
1. disable 'NOMTABLE'
2. drop 'NOMTABLE'
Désactiver la table permet de bloquer toutes les requêtes.
[Link]. Ajout et suppression de n-uplet
 Ajout de cellules
Un n-uplet est composé de plusieurs colonnes. L’insertion d’un n-uplet se fait colonne par
colonne.
On indique la famille de la colonne. Les colonnes peuvent être créées à volonté.
put 'NOMTABLE', 'CLE', 'FAM:COLONNE', 'VALEUR‘
 Suppression de cellules

34
Il y a plusieurs variantes selon ce qu’on veut supprimer, seulement une valeur, une cellule, ou
tout un n-uplet :
deleteall 'NOMTABLE', 'CLE', 'FAM:COLONNE', TIMESTAMP
deleteall 'NOMTABLE', 'CLE', 'FAM:COLONNE'
deleteall 'NOMTABLE', 'CLE'

[Link]. Affichage de n-uplet

La commande get affiche les valeurs désignées par une seule clé. On peut spécifier le nom de la
colonne avec sa famille et éventuellement le timestamp.
get 'NOMTABLE', 'CLE'
get 'NOMTABLE', 'CLE', 'FAM:COLONNE'
get 'NOMTABLE', 'CLE', 'FAM:COLONNE', TIMESTAMP
La première variante affiche toutes les colonnes ayant cette clé. La deuxième affiche toutes les
valeurs avec leur timestamp.

[Link]. Recherche de n-uplet

La commande scan affiche les n-uplets sélectionnés par les conditions.
scan 'NOMTABLE', {CONDITIONS}
Parmi les conditions possibles :
COLUMNS=>['FAM:COLONNE',...] pour sélectionner certaines colonnes.
STARTROW=>'CLE1', STOPROW=>'CLE2' pour sélectionner les n-uplets de [CLE1, CLE2[.
Ou alors (exclusif), une condition basée sur un filtre :
FILTER=>"PrefixFilter('binary:client')"

[Link]. Les filtres

L’ensemble des filtres d’un scan doit être placé entre "...".
Plusieurs filtres peuvent être combinés avec AND, OR et les parenthèses.
Exemple :
{ FILTER => "PrefixFilter('client') AND ColumnPrefixFilter('achat')" }
 PrefixFilter('chaîne') : accepte les valeurs dont la clé commence par la chaîne
ColumnPrefixFilter('chaîne') : accepte les valeurs dont la colonne commence par la chaîne.
Ensuite, on a plusieurs filtres qui comparent quelque chose à une valeur constante. La syntaxe
générale est du type :
MachinFiter(OPCMP, VAL), . . . avec OPCMP VAL définies ainsi :

35
  OPCMP doit être l’un des opérateurs <, <=, =, !=, > ou >= (sans mettre de quotes
autour)
 VAL est une constante qui doit valoir :
 'binary:chaine' pour une chaîne telle quelle
 'substring:chaine' pour une sous-chaîne
 …
Exemple :
{ FILTER => "ValueFilter(=,'substring:univ-annaba')"}
Plusieurs filtres questionnent la clé, famille ou colonne d’une valeur :
 RowFilter(OPCMP, VAL)
 FamilyFilter(OPCMP, VAL)
 QualifierFilter(OPCMP, VAL)
accepte les n-uplet dont la clé, famille, colonne correspond à la constante
 SingleColumnValueFilter('fam','col',OPCMP,VAL)
garde les n-uplets dont la colonne 'fam:col' correspond à la constante. Ce filtre est utile pour
garder des n-uplets dont l’un des champs possède une valeur qui nous intéresse.
 ValueFilter(OPCMP, VAL)
accepte les valeurs qui correspondent à la constante

36
 Références et Webographie

R. Bruchez, Les bases de données NoSQL: Comprendre et mettre en œuvre, Eyrolles, 2013.

T. White, Hadoop : The Definitive Guide, O’Reilly, 2012.

[Link]

[Link]

[Link]

37