Tutoriel d'introduction à Apache Hadoop

Avant de commencer l'installation, nous allons opérer une modification sur le fichier /etc/hosts de chaque système d'exploitation de façon à ce qu'il contienne toutes les IP des autres machines du cluster. Par exemple pour la machine s-virtual-machine1, le fichier /etc/hosts devra contenir les informations suivantes :

127.0.0.1    localhost
193.55.163.212    s-virtual-machine1
193.55.163.213    s-virtual-machine2
193.55.163.214    s-virtual-machine3
193.55.163.215    s-virtual-machine4
193.55.163.216    s-virtual-machine5
193.55.163.217    s-virtual-machine6
...

Pensez à supprimer la ligne 127.0.1.1 s-virtual-machine* du fichier /etc/hosts, elle peut être la cause de problèmes.

Cloudera Manager nécessite d'exécuter des tâches d'administration sur les machines du cluster. Pour permettre cela, ajoutez la ligne suivante dans le fichier /etc/sudoers de chaque machine pour désactiver la demande de mot de passe (hadoopmanager correspond au nom de l'utilisateur de la machine virtuelle) :

hadoopmanager     ALL=NOPASSWD: ALL

Cloudera Manager se présente sous la forme d'un serveur Web et d'une application cliente. Ce n'est pas l'installation d'Hadoop, il sert juste de facilitateur pour installer et administrer les modules Hadoop. C'est en gros l'outil qui va automatiser l'ensemble des packages que nous avions déjà installés lors du deuxième tutoriel, mais avec une dimension cluster. L'installation du serveur Cloudera Manager se fera sur la première machine s-virtual-machine1.

Connectez-vous en SSH sur la machine s-virtual-machine1 pour installer Cloudera Manager.

Téléchargez la version de Cloudera Manager vers le répertoire HOME de l'utilisateur hadoopmanager.

$ wget http://archive-primary.cloudera.com/cm5/installer/5.1.2/cloudera-manager-installer.bin

Modifier les droits afin d'autoriser l'exécution puis exécuter le binaire en root.

$ chmod u+x cloudera-manager-installer.bin
$ sudo ./cloudera-manager-installer.bin

Différents écrans apparaissent. Veuillez suivre les différentes propositions et accepter la licence d'utilisation.

L'installation démarre et s'occupe d'installer tous les packages nécessaires. Si tout s'est bien passé, vous devriez obtenir l'écran suivant qui vous donne des indications pour accéder à Cloudera Manager.

Cloudera Manager est désormais prêt à l'emploi. Nous allons pouvoir l'utiliser pour installer Hadoop sur un petit cluster de trois nœuds. Pour cela, Cloudera Manager fournit une interface Web très simpliste pour initialiser un Cluster. L'interface Web est accessible depuis l'URL (http://s-virtual-machine1:7180). L'identifiant de connexion et le mot de passe sont par défaut admin.

Sélectionnez l'édition Cloudera Express puis cliquez Continuer.

L'ensemble des modules Hadoop qui seront installés (Hadoop Core, HBase, ZooKeeper, Oozie, Hive, Hue…) sont détaillés sur l'écran suivant.

Dans le dernier écran, il vous sera demandé les machines qui feront partie du cluster. Nous débuterons avec un cluster trois nœuds. Le premier nœud est le NameNode/DataNode identifié par s-virtual-machine1 et déjà utilisé puisqu'il s'agit du nœud où est installé Cloudera Manager. Pour les deux autres, il s'agit de s-virtual-machine2 et de s-virtual-machine3.

Veuillez saisir l'adresse IP des machines dans le formulaire pour constituer une première base de machines pour notre cluster.

À la première étape d'installation du cluster, laissez les paramètres par défaut en vous assurant que la version Cloudera Hadoop 5 est sélectionnée (CDH-5.x.y-z.w), puis cliquez Continuer.

À la deuxième étape, ne cochez pas « Installer les fichiers de politique de cryptage de niveau illimité Java », puis cliquez Continuer.

À la troisième étape, sélectionnez l'option Un autre utilisateur et saisissez la valeur hadoopmanager, saisissez le mot de passe deux fois hadoopmanager, puis cliquez Continuer.

À la quatrième étape, l'installation du cluster démarre et après un petit temps vous devriez obtenir l'écran suivant.

La cinquième étape consiste à installer les différentes parcels (équivalent à des paquets, mais adaptées au déploiement sur un cluster Hadoop Cloudera). Dans la suite, nous utiliserons indifféremment le mot module pour désigner parcel.

Finalement à la sixième étape, un récapitulatif est donné.

À la suite de l'installation, Cloudera Manager vous propose désormais de configurer le cluster.

À la première étape, il vous est demandé de sélectionner les services à installer sous forme de combinaison. Choisissez la première option Core Hadoop. Cette combinaison contient HDFS, Yarn (MapReduce 2), Zookeeper, Oozie, Hive, Hue et Sqop. Ces projets seront suffisants pour réaliser nos expérimentations.

À la deuxième étape, différentes options pour les affectations des rôles sont proposées. Assurez-vous de mettre la valeur de DataNode dans la catégorie HDFS à Tous les hôtes de façon à ce que le premier nœud soit à la fois NameNode et DataNode.

Par ailleurs, grâce à ces options, vous pourriez choisir par exemple la machine qui prendrait en charge le NameNode ou choisir de désactiver le secondary NameNode. Veuillez noter que la plupart des informations sont modifiables une fois les nœuds installés.

À la troisième étape, des options liées aux configurations des bases de données traditionnelles utiles par exemple pour Hive. Faites simplement Tester la connexion.

À la quatrième étape, vous avez la possibilité de modifier certaines configurations d'Hadoop et des sous-projets installés. Vous pourriez par exemple modifier le répertoire de données DataNode qui correspond au dossier HDFS. Nous laisserons les valeurs par défaut.

À la cinquième étape, la configuration démarre.

Finalement, l'écran de l'étape 6 vous félicite d'avoir réussi à installer un cluster Hadoop Cloudera à deux nœuds. Étudions maintenant l'interface d'administration de Cloudera Manager.

L'interface d'administration du cluster est présentée sur la figure ci-dessous.

Sans trop vouloir détailler, cette interface permet d'obtenir une vision globale du cluster, que ce soit au niveau matériel (les nœuds du cluster) ou des modules installés (HDFS, Hive…).

• Sur la partie gauche sont donnés les différents modules installés avec leur état (pastilles vertes indiquant un fonctionnement correct).
• Sur la partie haute sous forme de bandeau horizontal, sont fournis des accès aux fonctionnalités principales (Clusters, Hôtes, Diagnostics, Audits, Tableaux et Administrations).
• Sur la partie centrale est présenté un tableau de bord à base de graphiques. Il permet de visualiser différentes métriques du cluster. On peut retrouver des métriques notamment pour mesurer les entrées/sorties sur HDFS, sur le temps d'exécution d'un job, sur l'occupation processeur, etc. (l'ensemble des métriques est décrit dans la documentation officiellede Cloudera Manager). Les métriques peuvent cibler le cluster dans sa globalité ou des nœuds en particulier. Cette granularité est pratique si vous souhaitez monitorer uniquement le NameNode pour connaître l'occupation mémoire. La figure ci-dessus par exemple présente les entrées/sorties des disques, du réseau, de HDFS et l'occupation processeur. Ces métriques peuvent être exportées sous différents formats exploitables comme JSON ou CSV via une API Rest (API Rest Cloudera V6). Un peu plus tard dans ce tutoriel, nous montrerons comment accéder à ces métriques via un script, afin de montrer le comportement du cluster lors de l'exécution d'un Job MapReduce. Enfin, ce tableau de bord est paramétrable et il est possible d'ajouter de nouveaux graphiques suivant de nombreux critères. Une interface simpliste basée sur le langage de requête tsquery « à la SQL » est fournie (voir figure suivante).

Dans cette section, nous nous intéressons à ajouter un nœud supplémentaire (appelé Hôtes sous Cloudera Manager) de données (DataNode) à notre cluster. Pour rappel, ce dernier est actuellement composé d'un nœud NameNode/DataNode et de deux nœuds DataNode. La capacité du système de fichiers HDFS avec trois nœuds de données est de ~ 1 To (2x500 Go). Cette information est visible depuis l'interface dédiée au module HDFS. Nous souhaitons donc passer à trois nœuds de données et nous assurer que l'ajout d'une nouvelle machine augmentera la taille de notre système de fichiers.

Lorsqu'un nouveau nœud est intégré à un cluster, un certain nombre de modules doivent être installés. Ces modules sont regroupés dans des modèles (template). Par exemple, suite à l'installation et à la configuration de notre cluster trois nœuds, les deux nœuds spécifiques DataNode s-virtual-machine2 et s-virtual-machine3 avaient un modèle différent du nœud NameNode. Ce modèle appelé Template - 1 dédié au DataNode contient les modules suivants : DataNode Default Group, Gateway Default Group et NodeManager Default Group. L'intérêt des modèles est de pouvoir réaliser des regroupements et de les appliquer à un nouveau nœud, ce que nous allons réaliser par la suite en ajoutant s-virtual-machine4 au cluster.

Sélectionnez depuis le bandeau le menu hôte puis faites Ajouter de nouveaux hôtes au cluster.

Ajoutez le nœud identifié par le nom s-virtual-machine4 puis cliquez Continuer.

Le reste de l'installation et de la configuration restent similaires à ce que nous avions déjà rencontré lors de la section Installation d'un cluster 1 NameNode 1 DataNodeInstallation et configuration d'un cluster multinœud.

À l'étape 7, il vous est demandé de choisir un modèle d'hôte. Choissez le modèle Template - 1. Si ce modèle n'existe pas, créez-le avec les modules suivants pour rappel : DataNode Default Group, Gateway Default Group et NodeManager Default Group.

À l'étape finale 8, vous devriez obtenir l'écran suivant.

Afin de valider les modifications sur le Cluster, vous devrez Déployer la configuration Client et faire Rédémarrer le cluster. Ces options sont disponibles depuis la vue cluster.

On aperçoit clairement l'intérêt de Cloudera Manager. Il s'occupe des changements à opérer sur les fichiers de configuration. Il vous suffira de redémarrer le serveur afin que ces changements soient appliqués.

Nous présentons ci-dessous un script Bash dont la fonction est de prendre en paramètre une source texte (paramètreB1) et d'ajouter son contenu n fois (paramètre 3) dans un fichier de sortie (paramètre 2). Les paramètres 2 et 3 sont optionnels et des valeurs par défaut sont définies, bigfile.txt pour le fichier de sortie et 10 000 pour le nombre d'itérations.

#!/bin/bash
OUTPUT=${2:-bigfile.txt}
ITERATE=${3:-10000}

for ((c=1; c<=$ITERATE; c++))
do
    cat $1 >> $OUTPUT
done

Téléchargez donc le fichier lié à l'œuvre intégrale de William Shakespeare, puis exécuter la commande suivante

$ ./createbigfile.sh 100.txt 50big100.txt 10000

Ceci va construire un fichier 50big100.txt d'une capacité de ~54 Go.

Le code complet du script createbigfile.sh est disponible sur mon Github.

Les paramètres de ce programme ad hoc en Java sont les suivants :

• un fichier texte source contenant les mots à compter ;
• un nom de fichier de sortie qui contiendra pour chaque mot le nombre d'occurrences présentes ;
• un nom de fichier pour le rapport d'exécution qui contiendra des métriques sur le temps d'exécution ;
• le nombre d'instances de Thread dédié au comptage de mots.

Les modules du programme sont les suivants :

• un module type « contrôleur » qui traite les paramètres et coordonne tous les autres modules ;
• un module qui découpe le fichier en plusieurs parties afin d'alimenter les différentes instances du Thread dédié au comptage de mots ;
• un module de map, qui crée les instances de Thread et qui distribue les différentes parties du fichier ;
• un module de reduce, qui fusionne les résultats obtenus pour chaque instance de Thread ;
• un module de sortie de la partie reduce ;
• un module de sortie pour les rapports d'exécution.

Intéressons-nous à détailler le code de chaque module.

Le premier, code ci-dessous, concerne celui qui traite les paramètres et appelle successivement les cinq principaux modules (entre lignes 31 et 40).

public class WordCounterMultiThread {
    public static void main(String[] args) throws NumberFormatException, IOException {
        if (args == null) {
            WordCounterMultiThread.displayArgumentsAreMissing();
            return;
        }

        if (args.length == 4) {
            new WordCounterMultiThread(args[0], args[1], args[2], Integer.parseInt(args[3]));
        } else {
            WordCounterMultiThread.displayArgumentsAreMissing();
            return;
        }
    }

    private static void displayArgumentsAreMissing() {
        System.out.println("Arguments are missing.");
        System.out.println("  - The first argument must specify the source file.");
        System.out.println("  - The second must specify the output file.");
        System.out.println("  - The third must specify the report file.");
        System.out.println("  - The fourth the thread number.");
    }

    public WordCounterMultiThread(String source, String destination, int pChunksNumber) throws IOException {
        start = System.currentTimeMillis();    
        maxThreads = Runtime.getRuntime().availableProcessors();
        fileProcessors = new ArrayList<FileProcessor>();
        sourceFile = new File(source);
        this.chunksNumber = pChunksNumber;

        // 1-Determine the offsets.
        offsets = this.split();
        // 2-Execute threads.
        this.map();
        // 3-Reduce the Map.
        this.reduce();
        // 4-Write the output.
        this.printAllCounts(destination);
        // 5-Print the report.
        this.printReport(report);
    }

    ...

La fonction long[] split découpe le fichier en plusieurs parties. Un RandomAccessFile (ligne 45) est utilisé afin de changer et récupérer la position du curseur de lecture. La position de chaque début de partie est stockée dans un tableau d'entiers (long[] offsets).

    private long[] split() throws IOException {
        long[] offsets = new long[chunksNumber];
        RandomAccessFile raf = new RandomAccessFile(sourceFile, "r");

        if (chunksNumber == 1) {
            offsets[0] = 0;
        } else {
            for (int i = 1; i < chunksNumber; i++) {
                raf.seek(i * sourceFile.length() / chunksNumber);
                while (true) {
                    int read = raf.read();
                    if (read == '\n' || read == -1) {
                        break;
                    }
                }
                offsets[i] = raf.getFilePointer();
            }
        }

        raf.close();
        finishSplit = System.currentTimeMillis();        
        return offsets;
    }

Nous présentons ci-dessous la méthode map().

Deux types de Thread sont gérés. Le premier type de Thread concerne FileProcessor est s'occupe de compter pour une partie du fichier les mots. Le résultat est stocké dans une TreeMap. Le second type de Thread concerne ConsoleProcessor qui gère l'affichage. Seule une instance de ce Thread sera créée (ligne 70).

Pour la gestion des instances multiples des Threads, nous faisons appel à ExecutorService. Le nombre d'instances de Thread est borné au nombre de Threads demandé en paramètre plus un Thread supplémentaire dédié à l'affichage sur console (ligne 69).

L'instruction de la ligne 81, permet de mettre en attente le Thread courant tant que les instances des Threads FileProcessor et ConsoleProcessor n'ont pas terminé leur exécution.

    public void map() {
        // Process each chunk using a thread for each one
        ExecutorService service = Executors.newFixedThreadPool(chunksNumber + 1);
        service.execute(new ConsoleProcessor(fileProcessors));
        for (int i = 0; i < chunksNumber; i++) {
            long startOffsets = offsets[i];
            long end = i < chunksNumber - 1 ? offsets[i + 1] : sourceFile.length();
            final FileProcessor newFileProcessor = new FileProcessor(i,sourceFile, startOffsets, end);
            fileProcessors.add(newFileProcessor);
            service.execute(newFileProcessor);
        }
        service.shutdown();

        try {
            service.awaitTermination(Long.MAX_VALUE, TimeUnit.MILLISECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        finishMap = System.currentTimeMillis();
    }

    class FileProcessor implements Runnable {
        private TreeMap<String, Integer> frequencyData = new TreeMap<String, Integer>();
    
        public void run() {
            try {
                RandomAccessFile raf = new BufferedRandomAccessFile(file, "r");
                raf.seek(start);

                String word; Integer count;
                while (raf.getFilePointer() < end) {
                    String line = raf.readLine();
                    if (line == null) {
                        continue;
                    }

                    StringTokenizer tokenizer = new StringTokenizer(line);
                    while (tokenizer.hasMoreTokens()) {
                        word = tokenizer.nextToken();
                        count = getCount(word, frequencyData) + 1;
                        frequencyData.put(word, count);
                    }

                    percentage = Math.round(((raf.getFilePointer() - start) * 100) / (end - start));
                }
                raf.close();
            } catch (IOException e) {
                // Deal with exception.
            }
        }
    }

Dans le code ci-dessous, nous présentons la méthode reduce(). Son travail consiste à fusionner l'ensemble des TreeMap de chaque instance de Thread de FileProcessor.

    public void reduce() {
        for (FileProcessor current : fileProcessors) {
        for (String key : current.getFrequencyData().keySet()) {
        if (frequencyData.containsKey(key)) {
            frequencyData.put(key, frequencyData.get(key) + current.getFrequencyData().get(key));
        } else {
            frequencyData.put(key, current.getFrequencyData().get(key));
        }
        }
    }
    finishReduce = System.currentTimeMillis();
    }
    ...
}

Le code complet de ce programme est disponible sur mon Github.

L'exécution de ce programme sera faite dans la section suivante dédiée à l'expérimentationExpérimentation.

Le fichier 50big100.txt d'une capacité respective de ~50 Go doit être copié dans le système de fichiers HDFS afin de pouvoir exécuter le job MapReduce correspondant. Nous utiliserons la commande hadoop fs déjà étudiée dans le deuxième tutoriel.

Exécutez les instructions ci-dessous et patientez quelques instants, le temps que la copie soit terminée.

$ sudo -u hdfs hadoop fs -put 50big100.txt /user/hdfs/books/50big100.txt

Comme la taille d'un bloc HDFS est configurée à 128 Mo, 417 blocs seront nécessaires pour stocker ce fichier sur le système de fichiers. Ainsi, lors de l'exécution du job MapReduce, 417 tâches map devront être créées.

V-D-1. Configuration du job MapReduce : solution par Hue▲

Avant de configurer le job MapReduce depuis Hue, le programme Java MapReduce du WordCount (hadoop-mapreduce-examples.jar) doit être placé dans HDFS. Sous Cloudera et si vous avez choisi la gestion des packages par facets, le fichier jar se trouve dans ce répertoire /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce

Supposons que vous soyez dans le répertoire où se trouve le fichier hadoop-mapreduce-examples.jar, la commande pour ajouter l'archive jar est la suivante :

 

Sélectionnez

$ sudo -u hdfs hadoop fs -put hadoop-mapreduce-examples.jar /user/hdfs

Depuis l'application Web Hue (http://s-virtual-machine1:8888), sélectionnez le menu Éditeurs de requêtes, puis cliquez sur Job Designer.

Choisissez Nouvelle Action et sélectionnez Java

Saisissez ensuite, les valeurs comme cela est indiquée ci-dessous :

• Nom : WordCount ;
• Chemin des fichiers Jar : /user/hdfs/hadoop-mapreduce-examples.jar ;
• Main Class : org.apache.hadoop.examples.WordCount ;
• Args : /user/hdfs/books /user/hdfs/output.

Finalement, validez en enregistrant vos informations.

V-D-2. Configuration du job MapReduce : solution par le Shell▲

$ sudo -u hdfs hadoop jar /opt/cloudera/parcels/CDH/lib/hadoop-mapreduce/hadoop-mapreduce-examples.jar wordcount /user/hdfs/books /user/hdfs/output

Nous détaillons dans cette section les outils qui nous serviront à générer les métriques pour notre expérimentation. Deux outils seront utilisés : iostat pour l'exécution de notre programme ad hoc Java et le tableau de bord de Cloudera Manager pour l'exécution du job MapReduce. Nous focaliserons notre analyse sur le temps d'exécution et sur les données liées à l'occupation du processeur et du disque dur.

V-E-1. Programme ad hoc en Java▲

$ sudo apt-get install sysstat

$ iostat -xt 2
Linux 3.11.0-15-generic (s-virtual-machine1)     11/10/14     _x86_64_    (2 CPU)

11/10/14 17:44:13
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.49    0.00    0.92    0.11    0.13   86.36

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     3.26    1.42    5.87    57.95   102.62    44.05     0.12   16.22    8.55   18.06   0.55   0.40

11/10/14 17:44:15
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          16.19    0.00    0.78    0.00    0.26   82.77

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     7.00    0.00    3.00     0.00    42.00    28.00     0.00    1.33    0.00    1.33   1.33   0.40

#!/bin/bash
...
    iostat $frequency -xt | awk -v r=$outputiostat '
        NF==2 {
            getline;getline;uservar=$1;systemvar=$3;getline;getline;getline;
            print uservar+systemvar";"$14 > r
        }
        ' &
...

6.85;0.69
0;0.40
0;0.00
0.12;0.00
13.63;4.10
50.56;2.20
50.19;2.70
50;3.30
...

set terminal pngcairo color dashed enhanced size 800,500
set title sizeinput
set label 1 "Finish Split=".splitvalue."s" at splitvalue+100,20
set arrow from splitvalue,0 to splitvalue,80 nohead
set label 2 "Finish Map=".mapvalue."s" at mapvalue-10,40 right
set arrow from mapvalue,0 to mapvalue,80 nohead
set label 3 "Finish Reduce=".reducevalue."s" at reducevalue-10,60 right
set arrow from reducevalue,0 to reducevalue,80 nohead
set datafile separator ';'
set xlabel "Time (hh:mm:ss)"
set ylabel "Percentage (%)"
set xdata time
set xtics 1000
set xtics format "%H:%M:%S"
set output reportpng
set yrange [0:100]
plot outputiostat using ($0*frequency):1 w l lt rgb "#0000FF" title 'CPU usage', outputiostat using ($0*frequency):2 w l lt rgb "#FF0000" title 'Disk usage'

V-E-2. Job MapReduce▲

#!/bin/bash
...
wget -q --user=$USER --password=$PASSWORD -O $outputData/clusterioutilization.csv "$SERVER/api/v7/timeseries?query=select stats(utilization_across_disks, avg) where category = CLUSTER&contentType=text/csv&from=$STARTDATE&to=$FINISHDATE&desiredRollup=RAW"
wget -q --user=$USER --password=$PASSWORD -O $outputData/clustercpuusage.csv "$SERVER/api/v7/timeseries?query=select stats(cpu_percent_across_hosts,avg) where category = CLUSTER&contentType=text/csv&from=$STARTDATE&to=$FINISHDATE&desiredRollup=RAW"
...
gnuplot << EOF
set title "CPU & Disk usage during a WordCount MapReduce execution ($# nodes, 50 Gb bigfile.txt)"
set terminal pngcairo size 800,500
set output "$outputImage/mrclustercpuio$#.png"
set datafile separator ','
set xlabel "Time (hh:mm)"
set ylabel "Percentage (%)"
set xtics format "%H:%M"
set xdata time
set yrange [0:100]
set grid x y
plot "$outputData/clusterioutilization.csv" using (\$0*60):4 w l lt rgb "#FF0000" title 'Disk utilization', "$outputData/clustercpuusage.csv" using (\$0*60):4 w l lt rgb "#0000FF" title 'CPU Usage'
EOF
...

Nous montrons pour chacun de nos deux programmes comment réaliser leurs exécutions et les fichiers obtenus.

VI-A-1. Programme ad hoc Java▲

$ ./startwcjbench.sh 4 50big100.txt 5

VI-A-2. Programme Hadoop▲

$ ./generatehadoopplot.sh 2015-01-21T18:43:00.000Z 2015-01-22T00:30:00.000Z s-virtualmachine1-lias s-virtualmachine2-lias

Nous donnons ci-après une analyse des résultats des exécutions du programme ad hoc et du MapReduce.

VI-B-1. Programme ad hoc Java▲

Le tableau ci-dessous présente le temps de traitement de chaque exécution avec un nombre d'instances de Thread/cœur différent. La dernière ligne du tableau présente l'évolution d'une exécution par rapport à sa précédente commençant par un Thread.

Nbre Thread/Cœur	1	2	3	4	5	6
Temps exécution (hh:mm:ss)	2h:29m:22s	1h:11m:09s	0h:48m:26s	0h:37m:56s	0h:29m:29s	0h:27m:11s
Évolution / à deux instances	+0%	-52%	-31%	-21%	-22%	-7%

Nous pouvons remarquer rapidement sur le tableau que l'augmentation du nombre d'instances de Thread et de cœur améliore considérablement le temps d'exécution. Le pourcentage de diminution est plus flagrant sur le début que vers la fin.

Les six graphiques ci-dessous montrent les sollicitations du CPU et du disque dur avec un nombre d'instances de Thread et de cœur croissant (de une à six instances de Thread/cœur). La courbe en bleu désigne l'occupation CPU (utilisateur + système) tandis que la courbe en rouge désigne la sollicitation du disque dur. Pour chaque graphique, nous avons identifié les principales étapes d'exécution : le découpage, la phase de map et la phase de reduce. La phase de map est toujours la plus longue.

Un Thread▲

Dans le cas de cette première exécution, nous distinguons que l'occupation CPU est à son maximum, ce qui est cohérent puisque le nombre de cœurs est à 1. Cette remarque sera valable pour tous les graphiques suivants. Nous voyons sur le graphique que le facteur limitant de cette exécution est le CPU puisqu'il est à son maximum et que l'unité de disque est très peu sollicitée (~ 3 %).

Le temps de split tout comme le temps reduce sont infiniment petits par rapport à la tâche de map, ce qui explique les valeurs à 0 s.

Deux Threads▲

Dans ce deuxième graphique, peu de changement hormis le temps d'exécution qui a été divisé par deux. Le disque dur est relativement plus sollicité (~ 9 %) que sur le premier graphique, mais l'occupation CPU est toujours le facteur limitant.

Trois Threads▲

Peu de changement par rapport au graphique précédent, le temps d'exécution est descendu à moins d'une heure. Le taux d'utilisation du disque augmente légèrement (~ 12 %).

Quatre Threads▲

Ce quatrième graphique est sensiblement équivalent au précédent.

Cinq Threads▲

Le taux d'utilisation du disque augmente pour atteindre presque les 20 %.

Six Threads▲

Ce dernier graphique est cohérent par rapport aux précédents. Le taux d'utilisation du disque dépasse les 20 %.

VI-B-2. Programme Hadoop▲

Le tableau ci-dessous présente les temps d'exécution du job MapReduce WordCount avec différents nombres de nœuds. Comme pour le programme Java ad hoc, la troisième ligne du tableau présente l'évolution par rapport à trois instances de nœuds qui est supposée être la configuration minimale d'un cluster Hadoop. Nous avons ajouté une ligne qui donne le temps moyen d'exécution d'une tâche de map. Cette information nous a été donnée par l'application JobHistoryJob MapReduce.

Nbre Nœud DataNode	1	2	3	4	5	6
Temps exécution (hh:mm:ss)	5h:24m:17s	3h:23m:37s	1h:48m:05s	1h:11m:05s	0h:54m:54s	0h:49m:49s
Évolution / à deux instances	+0%	-37%	-47%	-34%	-24%	-9.2%
Temps moyen d'un map (mm:ss)	45s	47s	51s	54s	57s	01m:06s

On remarque que tout naturellement le nombre de nœuds a une incidence sur le temps de résolution du job MapReduce.

Les sous-sections suivantes montrent les sollicitations du CPU et du disque dur pour des configurations de cluster différentes en termes de nombre de nœuds. Plus précisément pour chaque configuration de cluster, nous avons deux graphiques : un pour la sollicitation du CPU et un deuxième pour la sollicitation du disque dur. Pour chaque graphique, il y a autant de courbes que de nœuds sur le serveur (représentées par un trait continu) plus une courbe (représentée par une courbe pointillée noire) qui donne une moyenne du point de vue du cluster. Au temps 0, le job MapReduce est démarré pour la phase de map.

Un nœud DataNode▲

Petite surprise avec un seul nœud de type NameNode/DataNode, l'exécution du job MapReduce ne se lançait pas. J'ai un peu triché et j'ai mis en place un cluster avec deux nœuds dont le premier est un NameNode sans DataNode et le second est un DataNode exclusif.

La première exécution est très longue de l'ordre de plus de cinq heures. Ceci n'est pas surprenant sachant qu'une tâche map en moyenne est de 45 s et qu'il y a 470 tâches map à traiter. Une piste pour réduire le nombre de map serait d'augmenter la taille des blocs de données HDFS.

On constate également que le CPU n'est pas utilisé à son maximum de l'ordre de 60 % et que le disque n'est pas du tout sollicité ~ 3 %.

Deux nœuds DataNode▲

Avec deux nœuds DataNode, le temps d'exécution complet a été diminué de 37 %. L'utilisation du CPU est toujours de moitié pour les deux nœuds. On constate toutefois que l'occupation CPU du premier nœud est plus élevée de 10 % par rapport au second nœud. Cela s'explique par la présence sur le premier nœud des services spécifiques à Cloudera (Cloudera Manager, Hue, NameNode…).

On remarque au temps 2h:25m que l'utilisation CPU du second nœud est descendue au plus bas tandis que l'utilisation CPU du premier nœud continue. L'explication donnée est que les tâches map du second nœud se sont terminées plus tôt et ont continué pour le second nœud. Un pic sur le second nœud est identifié à la fin ce qui peut justifier les tâches reduce dont le nombre était de deux. Ainsi chaque nœud a terminé l'exécution par une phase reduce.

Pour finir, l'utilisation du disque est semblable à la première exécution.

Trois nœuds DataNode▲

Le graphique de l'occupation CPU est proche du précédent. Nous noterons toutefois que la charge CPU du troisième nœud a atteint pratiquement 100 % pour descendre à une valeur identique au deuxième nœud vers 1h:20m. Vous remarquerez qu'à la fin de l'exécution 1h48m un pic de 20 %, il s'agit toujours de la tâche reduce. L'autre tâche reduce est menée par le troisième nœud.

Concernant l'utilisation du disque, on notera que pour le troisième nœud, le niveau est le plus haut.

Quatre nœuds DataNode▲

Il n'y a pas de grosse différence avec la précédente exécution. Les deuxième et troisième nœuds sont désormais au maximum de l'occupation CPU.

Concernant l'utilisation du disque, c'est toujours très bas, il n'est pas du tout sollicité.

Cinq nœuds DataNode▲

Pas de différence sur l'occupation CPU, hormis le fait que maintenant trois nœuds sont à 100 %.

L'utilisation du disque est toujours identique aux précédents et cela ne changera pas pour la suite, car on a clairement identifié que le CPU était le facteur limitant.

Six nœuds DataNode▲

L'exécution est descendue sous la barre des une heure. Nous avons toujours deux nœuds qui ne sont pas totalement sollicités. Une explication plausible viendrait de la tâche reduce. Comme elles sont au nombre de deux, Hadoop réserve deux nœuds pour accomplir les tâches. Par ailleurs, d'après les configurations dans le fichier mapred-default.xml, le paramètre mapreduce.reduce.cpu.vcores spécifie le nombre de cœurs qui est fixé à 1 par défaut. Par conséquent comme nos machines virtuelles sont configurées avec deux cœurs virtuels, Hadoop n'allouerait pour les deux nœuds qu'un seul cœur à chaque fois pour les tâches map.