RapportGerlierChen

8/2/2019 RapportGerlierChen

http://slidepdf.com/reader/full/rapportgerlierchen 1/22

Julien Gerlier

Siman Chen

Prototypage et évaluation deperformances d’un service de traçabilité

avec une architecture distribuée basée

sur Hadoop

Rapport de projet de fin d’étude

ASR 2010/2011

Encadrants :

- Bruno Defude (TMSP),

- Elisabeth Brunet (TMSP),

- Amin Sakka (Novapost)



SommaireSommaire ............................................................................................................................. 2

Introduction ......................................................................................................................... 3

I. Présentation du projet ...................................................................................................... 4

a) Contexte ................................................................................................................ 4

b) Objectifs ................................................................................................................ 4

c) Technologies choisies ............................................................................................ 5

d) Travail à effectuer .................................................................................................. 5

II. Cassandra ......................................................................................................................... 6

a) Introduction........................................................................................................... 6

b) La structure de données........................................................................................ 6

c) Les avantages ...................................................................................................... 10

d) Les limites ............................................................................................................ 10

III. Hadoop et HDFS ............................................................................................................ 10

a) Introduction......................................................................................................... 10

b) Conception et déploiement d’un système de fichiers distribué ......................... 11

c) Prévention des échecs d’écriture ........................................................................ 12

d) Paramètres de performances .............................................................................. 12

e) MapReduce ......................................................................................................... 13

IV. Mise en place du prototype et tests ............................................................................. 14

a) Environnement de travail .................................................................................... 14

b) Conception de la base de données ..................................................................... 14

c) Insertion massive dans la base ............................................................................ 16

d) Couplage Hadoop / Cassandra ............................................................................ 18

e) HBase................................................................................................................... 19

V. Difficultés rencontrées ................................................................................................... 20

a) Manque de documentation ................................................................................ 20

b) Matériel trop peu puissant .................................................................................. 20

Conclusion .......................................................................................................................... 21

a) Conclusion personnelle ....................................................................................... 21

b) Estimation du temps de travail ........................................................................... 21

Références ......................................................................................................................... 22



Introduction

Le cloud computing est un concept apparu récemment, mais de plus en plus à la

mode dans le secteur de l’informatique. Littéralement "l'informatique dans les

nuages", il consiste pour les entreprises à externaliser et distribuer les ressources

numériques qu'elles stockent, c’est-à-dire l'utilisation de la mémoire et des

performances des ordinateurs, avec des serveurs répartis dans le monde entier liés

par un réseau, tel Internet. Les utilisateurs du nuage pourraient ainsi disposer d'une

puissance informatique considérable et modulable.

Novapost est une entreprise qui propose un services de dématérialisation de

documents à valeur légales, comme des feuilles de paie par exemple, qui sont

stockés sous forme numérique et suivi par un service de traçage qui enregistre les

moindres opérations effectuées sur ces fiches afin de maintenir leur valeur légale.

Pour l’instant le service de Novapost repose sur une architecture client/ser veur

classique mais suite au nombre croissant de client, ils envisagent de totalement

distribuer leur architecture.

Notre projet de fin d’étude a pour but d’étudier les méthodes et technologiespermettant réaliser la nouvelle architecture répartie.

Nous nous intéresserons particulièrement aux technologies Cassandra, Système de

Gestion de Base de Données (SGBD) NoSQL, et Hadoop, framework Java destiné aux

applications distribuées et à la gestion intensive des données. Ce sont des

technologies récentes, encore relativement peu connues du grand public mais

auxquelles on associe déjà des grands noms parmi lesquels : Facebook, Yahoo ou

encore Twitter.

Ce présent rapport se divisera en cinq grandes parties. Dans un premier temps, nous

allons présenter de manière détaillée notre les objectifs du projet et les étapesenvisagées au départ. Puis, les deuxième et troisième parties porteront sur

respectivement nos études de Cassandra et d’Hadoop, les deux technologies clés de

notre projet. La partie suivante explicitera les différents tests et développement que

nous avons effectués. Enfin, nous parlerons dans une dernière partie des difficultés

que nous rencontrées et des bilans que nous en avons tirés.



I. Présentation du projet

a) Contexte

Novapost est une entreprise qui propose à d’autres entreprises un service dedématérialisation de leur processus de gestion documentaire, un exemple : la

gestion des fiches de paie.

Dans le monde de la dématérialisation, les exigences sur la traçabilité des documents

sont très importantes. En effet, la dématérialisation des processus et des documents

s’inscrit dans un cadre législatif rigoureux, on doit tenir compte de la criticité des

documents à gérer, et assurer leur pérennité ainsi que confidentialité. D’où le besoin

pour un service décrivant les opérations effectuées sur les documents par les

différents systèmes et acteurs intervenant dans la chaine de traitement de ce

dernier.

Pour cela, Novapost a mis en place un service de traçabilité appelé « LX Track » :

c’est un service qui permet de centraliser les traces des opérations effectués sur les

documents afin d’assurer leur valeur probante.

Ce service est constitué d’un client web qui interroge le service de traçage,

l’ensemble des fichiers de trace étant indexés par une base SQL.

b) Objectifs

L’une des priorités de Novapost est la performance : chaque service Novapost est

développé pour être opéré dans un contexte de haute disponibilité, avec une

capacité de traitement industriel. Un tel service doit supporter de brusque montée

en charge sur des équipements standards (quand tout le monde consulte sa feuillede paie à la fin du mois par exemple). Or, le service actuel utilise une base de



données MySQL classique qui supporte de plus en plus mal ces montées en charge et

ne sera bientôt plus adaptée en raison du nombre croissant de connexion et de

fichiers à stocker.

Pour cette raison, nous souhaitons rendre l’architecture de ce service totalement

réparti. Ceci nécessite l’utilisation d’un système de stockage distribué.

c) Technologies choisies

Pour l’indexation des fichiers de traces, Novapost souhaite migrer le modèle

relationnel actuel vers un model NoSQL (« Not Only SQL ») distribué pour assurer

une évolutivité transversale du service.

Parmi les nombreuses solutions NoSQL, Amin Sakka qui est notre contact chez

Novapost nous a conseillé Cassandra, une SGBD (Système de gestion de base dedonnées) NoSQL développé par la fondation Apache. Cassandra est conçue pour

gérer des quantités massives de données réparties sur plusieurs serveurs (cluster),

en assurant tout particulièrement une disponibilité maximale des données et en

éliminant les point individuel de défaillance. Initialement développée par Facebook,

l'application a été libérée dans l'espace open-source et rapidement adoptée par

plusieurs grandes entreprises gérant d'importants volumes de données, telles que

Twitter ou digg.com.

Pour interroger les traces de manière la plus rapide possible, Novapost nous a

proposé d’utiliser une architecture basée sur Hadoop, un frameworkd’implémentation de l’algorithme MapReduce en Java développé lui aussi par

Apache. Hadoop est un système scalable, avec une bonne tolérance aux fautes pour

le stockage et le traitement de gros volumes de données. Il utilise un système de

fichiers distribué appelé HDFS (Hadoop Distributed File System) mais peut aussi

effectuer des opérations directement dans une base de donnée SQL.

d) Travail à effectuer

Les objectifs au commencement du projet étaient les suivants :

Etudier Cassandra et son modèle de base de données

Définir une structure de base de données adaptée

Etudier Hadoop et l’algorithme MapReduce

Proposer une implémentation de prototype alliant Hadoop à Cassandra permettant

d’interroger les traces via des opérations MapReduce

Effectuer des tests de performance du prototype : montée en charge, insertion

massive de donnée, etc.

Optimiser le modèle pour obtenir qu’il soit au maximum parallélisé.



II. Cassandra

a) Introduction

Le modèle de donnée de Cassandra est plus ou moins dérivé de celui de BigTable, unSGBD NoSQL développé par Google. Les développement de Cassandra ont

commencés au sein de Facebook, puis ont été transmis à la communauté Open

Source. Cette base de données non relationnelle comme toute base NoSQL a pour

but d'améliorer les bases de données dans une direction nécessitant une évolutivité

horizontale. Sa structure se rapproche de celle de tous les autres modèle NoSQL : on

dit que c’est une base orientée colonne.

Cassandra peut être pensée comme une structure à 4 dimensions dont les noms sont

les Keyspaces, les ColumnFamily, les SuperColumns et les Colonnes. Un keyspace est

composé de ColumnFamily, qui contient des lignes (rows), identifiés par une clé.Chaque row contient des colonnes. Une colonne est un triplet {clé, valeur,

timestamp} qui s’apparente à un tuple.

Une ColumnFamily peut être de type super : ses rows ne contiennent alors pas des

colonnes mais des SuperColumn. Une SuperColumn est elle aussi un triplet {clé,

valeur, timestamp}, dont l’élément « valeur » contient lui-même une colonne (triplet

{clé, valeur, timestamp}.

Les SGBD classiques sont orientés lignes. Chaque ligne contient un tuple qui a un

nombre précis d’attributs. Dans un SGBD orienté colonne, chaque ligne peut stocker

un nombre différent de colonnes, et deux lignes appartenant à la mêmeColumnFamily (plus ou moins équivalente à une table dans un SGBD classique)

peuvent contenir des colonnes de types différents. Il n’y a alors plus de relations

entre les données au sens d’un SGBD relationnel classique : il faut penser plus en

termes d’efficacité des requêtes qu’en termes de relation entre les données.

b) La structure de données

Les Keyspaces:Il faut penser les keyspaces comme des espaces de travail, des domaines. Il s’agit du

plus haut niveau d’organisation de Cassandra.

Les colonnes :

Les colonnes sont des structures qui sont identifiées par une clé (aussi appelé nom)

et une valeur défini par l’utilisateur ainsi que par un timestamp qui indique la

dernière date à laquelle a été modifiée la donnée. Il faut noter que dans Cassandra

les clés ont une valeur informative, elles ne sont pas générées de manière arbitrairecomme pour les tuples d’une base de données SQL. Ainsi on peut par exemple



prendre comme clé le nom de l’attribut, comme dans cet exemple :

{ // ceci est une colonne

name: "emailAddress",

value: "[email protected]",

timestamp: 123456789}

Les colonnes peuvent être triées par leur clé ou leur timestamp. Ce paramètre doit

être déterminé à la création de la ColumnFamily, car les colonnes sont triées à leur

insertion.

Les super-colonnes :

Les colonnes de type super sont des structures qui ont une clé, un timestamp et quiont pour valeur un nombre infini de colonnes associées, chacune repérée par une clé

qui est simplement le nom de la colonne. Ils ont les mêmes caractéristiques que les

colonnes. L’ordre de tri peut encore être explicitement donné dans un fichier de

configuration, pour chacune des familles de colonnes.

{ // cest une SuperColumn

name: "homeAddress",

value: {

// qui contient 3 colonnes

{name: "street", value: "1234 x street", timestamp:123456789},

{name: "city", value: "san francisco", timestamp: 123456789},

}

}

Si on simplifie en ignorant le timestamp et les écritures de “name””value” on obtient

quelque chose plus lisible:

homeAddress: {

street: "1234 x street",

city: "san francisco",

}

Les familles de colonnes (ColumnFamily) :

Un keyspace est composée d’une ou plusieurs Familles de colonnes. Le nombre, le

nom, le type (simple ou super), le format de stockage des données, ainsi que les

autres paramètres des ColumnFamily sont fixés lors de leur création . Il n’y pas delimitation quant au nombre de Familles de colonnes mais ce nombre doit rester



relativement restreint : chacune d’elle est stockées dans des systèmes de fichier

distinct, il est donc plus couteux d’accéder à plusieurs ColumnFamily différentes

simultanément.

Au sein de chaque famille, les données sont stockées en ligne (identifié par une clé

elle aussi défini par l’utilisateur) qui contient un ensemble de colonnes ou de supercolonnes.

On est assez proche dans ce cas de la notion de table, au sens SGBDR classique.

UserProfile = { // ceci est une ColumnFamily

phatduckk: { // ceci est la clé de la row

// cette row contient 3 colonnes

username: "phatduckk",

email: "[email protected]",

phone: "(900) 976-6666"

}, // end row

ieure: { // ceci est la clé d’une autre row de la même ColumnFamily

// cette row contient 5 colonnes

username: "ieure",

email: "[email protected]",

phone: "(888) 555-1212"

age: "66",

gender: "undecided"

},

}

Les familles de colonnes peuvent être de type Super également, dans ce cas chaque

ligne contient un ensemble de SuperColumns et sont toujours identifiées par une clé.

AddressBook = {// ceci est une ColumnFamily de type super (ou SuperColumnFamily)

Paul: { // ceci est la clé de la row, elle correspond ici au propriétaire

de l’AddressBook

// ici nous avons deux SuperColumn dans cette row, chaque SuperColumn

est une entrée de l’AdressBook

John: { // SuperColumn qui contient 3 colonnes

street: "Howard street",

zip: "94404",

city: "FC",

state: "CA"

},

Kim: {

street: "X street",

zip: "87876",



city: "Balls",

state: "VA"},

}, // end row

Pierre: {// ceci est la clé d’une autre row

joey: {

street: "A ave",

zip: "55485",

city: "Hell",

state: "NV"

},

William: {

street: "Armpit Dr",

zip: "93301",

city: "Bakersfield",

state: "CA"

},

},

}

Ci-dessous un exemple graphique pour la gestion de magasins de jouets :



c) Les avantages

Flexibilité du schéma : Cassandra permet de ne pas figer les structures qui seront

utilisées. On peut ajouter ou en retirer au fur et à mesure des SuperColumn ou des

colonnes indépendamment pour chaque row. Attention il faut néanmoins, aumoment du démarrage du cluster fixer les noms des keyspaces et des ColumnFamily

qui seront utilisées (on ne peut pas créer à la volée).

Scalabilité réelle : Cassandra permet de passer à l’échelle très facilement. On peut

ajouter une machine à la volée sans avoir a redémarrer aucun processus, ni changer

les requêtes ou avoir a re-dispatcher les données. Par ailleurs, des outils permettent

d’équilibrer le volume de donnée entre les différents nœuds automatiquement.

Ecritures distribuées : Cassandra est conçue pour que les écritures n’échouent

jamais, il n’y a pas de « single point of failure » : si un nœud tombe, un autre prend

le relais. Par ailleurs les données sont répliquées lors de l’écriture. Ainsi si un nœud

tombe on peut accéder à la donnée sur un autre nœud.

d) Les limites

Toutes les données contenues dans une row doivent tenir sur un même disque, car

seules les clés des rows sont utilisées pour déterminer les facteurs de réplication de

celle-ci entre les différents nœuds. Une colonne ne doit par ailleurs pas excéder la

taille de 2 GB.

En outre, dans les ColumnFamily de type super, seule les colonnes sont indexées, et

donc l’accès à une colonne déserialise toutes les colonnes qui sont contenues dans la

même SuperColumn. Cet inconvénient devrait être supprimé dans les prochaines

versions.

III. Hadoop et HDFS

a) Introduction

HDFS est un système de fichier distribué. Il se démarque des autres systèmes de

fichier distribués par sa grande tolérance aux fautes et le fait qu’il soit conçu pour

être déployé sur des machines à faible coût. HDFS fournit un haut débit d’accès aux

données et est adapté pour les applications qui nécessitent de grands groupes de

données. Il a été à l’origine conçu pour le projet de moteur de recherche web

Apache Nutch.



b) Conception et déploiement d’un système de fichiers distribué

HDFS a une architecture de type maitre/esclave. Un cluster HDFS est constitué d’un

unique NameNode, un serveur maitre qui gère le système de fichier et notamment

les droits d’accès aux fichiers. A cela s’ajoute des DataNodes, en général un parnœud dans le cluster, qui gère le stockage des données affectés au nœud sur lequel

elle se trouve.

HDFS dispose d’un espace de nom et permet de stocker les données sous forme de

fichiers. Chaque fichier est divisé en blocs, qui sont stockées dans un groupe de

DataNodes. Ce sont eux qui répondent aux requêtes de lecture et écriture qui vienne

du client, et ce sont eux également qui gèrent la création, la suppression et la

réplication des blocs selon les instructions du NameNode.

HDFS est conçu pour tourner sur des machines simples sous GNU/linux, et est

programmé en Java. Toute machine qui dispose de Java peut donc faire tourner un

NameNode ou un DataNode.

Les noeuds communiquent entre eux via SSH. Il faut donc entrer la clé publique de

chaque DataNode dans le fichier authorized_keys du NameNode afin qu’il puisse se

connecter aux autres noeuds via ssh sans avoir besoin de taper un mot de passe à

chaque fois.

Le NameNode dispose d’un fichier de configuration dans lequel il entre l’adresse de

chaque machine sur laquelle tourne un DataNode, et se connecte ensuite à chacune

de ces machines via SSH au démarrage de HDFS. Par ailleurs, le NameNode est

l’arbitre et le dépositaire de toutes les métadonnées du HDFS. HDFS est conçu de



telle sorte qu’aucune donnée de l’utilisateur ne transite par le NameNode.

Chaque donnée insérée dans HDFS est répliquée pour assurer sa persistance. Le

facteur de réplication est égal à 3 par défaut, mais il peut être modifié pour chaque

fichier.

Par ailleurs, HDFS est « rack-aware », c'est-à-dire que la réplication s’adapte à

l’architecture du cluster. Ainsi si on laisse le facteur de réplication par défaut à 3, en

écrivant un block sur un DataNode, HDFS va ensuite écrire la première réplique sur

un nœud dans un autre rack, puis la dernière réplique sur un nœud du même rack

que la première.

c) Prévention des échecs d’écriture

Chaque DataNode envoie périodiquement un “heartbeat” au NameNode. Si leNameNode ne reçoit plus ce heartbeat d’un DataNode, il considère ce dernier

comme inaccessible, et re-réplique les données en conséquence.

Par ailleurs, HDFS intègre un mécanisme de checksum afin de détecter les données

corrompues. Ainsi, à sa création chaque fichier du HDFS se voit attribuer un

checksum. Quand un client accède à un fichier dans le HDFS, il vérifie que les

données reçues de chaque DataNode corresponde au checksum donné. Si ce n’est

pas le cas, il peut choisir de récupérer un bloc de données d’un a utre DataNode qui

en a la réplique.

Le seul “single point of failure” est le NameNode. Si ce dernier tombe, il est

nécessaire de le redémarrer manuellement, sauf si on a lancé l’exécution d’un

SecondaryNameNode qui peut alors prendre le relais.

d) Paramètres de performances

HDFS est fait pour stocker de gros fichiers (chaque fichier est divisé en bloc de 64 MB

par défaut). D’après la documentation officielle, un fichier typique dans HDFS fait

une taille de l’ordre du GB voire du TB. HDFS est fait pour une très grande scalabilité

et tourne déjà en production sur des très gros clusters (plus de 1000 machines) dans

des sociétés comme Facebook ou Yahoo.

HDFS est également fait pour qu’on puisse y insérer de très gros fichiers très

rapidement (quelques minutes pour quelques GB), du moment qu’on dispose d’un

cluster assez puissant, en terme de puissance de calcul aussi bien qu’en terme de

charge réseau.

De plus HDFS est avant tout conçu pour être utilisé avec Hadoop. La philosophie de

l’implémentation d’Hadoop repose sur le principe qu’il est plus efficace de déplacer

de la capacité de calcul que des donnés (“Moving Computation is Cheaper thanMoving Data”). HDFS fournit donc une interface pour pouvoir déplacer le traitement



des données au plus près de celles-ci.

En outre, Hadoop n’est pas fait pour exécuter un job de manière ponctuelle, mais

plutôt pour exécuter une file de jobs en mode batch de manière périodique. Yahoo!

a développé des outils afin de gérer la planification et la sécurisation de l’exécution

de jobs et notamment dans le cas ou plusieurs utilisateurs utilisent le même cluster.

Par ailleurs HDFS ne gère pas pour l’instant le rééquilibrage de charge. Ainsi si on

rajoute un DataNode, aucune donnée ne sera déplacée vers celui-ci afin de répartir

la charge, il faut le faire manuellement.

e) MapReduce

L'opération "map", écrit par l'utilisateur, consiste à produire une paire clé/valeurs

intermédiaire pour chaque paire de clé/valeur reçue en entrée. Ensuite la librairieMapReduce groupe toutes les clés intermédiaires associées à la même valeur et les

passe à la fonction "reduce". L'opération "reduce" consiste à fusionner les valeurs

d'une même clé intermédiaire afin de créer une unique valeur associée à cette clé et

renvoyer un unique couple clé/valeur en sortie pour chaque clé intermédiaire.

L’exemple classique est celui du WordCount. En entrée l'algorithme reçoit le couple

"nom du document"/"contenu". L'opération "map" crée une liste de couple clé

intermédiaire/valeur (ici "mot recherché/"1" où "1" correspondant à une occurrence

du mot dans le contenu du document) qu'elle passe à la fonction "reduce". Ensuite la

fonction "reduce" fusionne les couples de clés intermédiaire/valeur correspondant àla même clé intermédiaire (ici "mot recherché") en incrémentant un compteur pour

chaque occurrence de la même clé dans la liste de clés intermédiaires. Elle renvoie

ensuite en sortie le couple clé/valeur "mot recherché"/"nombre d'occurrence".

Les jobs MapReduce se structurent toujours autour de trois parties : deux classes

static « Mapper » et « Reducer », et une méthode main qui dirige l’application.

L’exécution des jobs se fait à l’aide d’un JobTracker et de Tasktrackers : lors de son

exécution le job est soumis au JobTracker qui s’occupe de le distribuer au

Tasktracker qui tourne sur chaque nœud. Le JobTracker choisit toujours les

TaskTracker qui sont les plus proches de l’emplacement de la donnée à traiter.



IV. Mise en place du prototype et tests

a) Environnement de travail

Nous avions besoin des droits administrateur pour pouvoir travailler avec Hadoop etCassandra. Ainsi nous avons choisi de travailler avec les machines virtuelles installées

sur les comptes Unix de l’école, le tout sur des comptes locaux afin d’avoir un espace

de stockage suffisant et un système de fichier performant.

Nous avons cependant été limités par la performance du matériel : il n’est possible

d’affecter qu’un seul cœur à une machine virtuelle et seulement la moitié de la RAM

totale (soit 2 GB) du PC hôte.

Nous avons travaillé avec la version 0.7 beta 2 de Cassandra, car la version 0.7

apporte de nombreuses fonctionnalités supplémentaires par rapport à la version 0.6,

notamment en termes de compatibilité avec Hadoop.

Par ailleurs nous avons utilisé la version 0.21 d’Hadoop.

b) Conception de la base de données

Cassandra est une base de donnée NoSQL, il faut pour cela s’affranchir de la pensée

« relationnelle » des bases de données classiques : la base doit être construite afin

de permettre l’accès le plus rapide possible aux données, quitte à avo ir des

redondances. Ainsi Amin Sakka a préféré ne pas nous donner le schéma de la base

de données relationnelle utilisée par Novapost actuellement, mais plutôt lesrequêtes principales par lesquelles s’opèreront les accès aux fichiers dans la base.



Les requêtes en question sont les suivantes :

String createTrack (String documentId, String identificationSystem) : crée

une trace pour un document, retourne l'identifiant de trace unique TUUID

void addAction (String trackId) : ajoute une action à la trace du document

void addAction (String documentId, String identificationSystem) : ajoute une action à

la trace du document

Track getTrackByTrackId (String trackId): retourne la trace d'un document

Track getTrack(String documentId, String identificationSystem) : retourne la trace

d'un document

List <Track> getTrackByFingerPrint (String fingerPrint, String

algorithm): retourne la liste de traces des documents ayant cette empreinte (le

résultat est une liste car plusieurs copies du même document peuvent exister)

Ainsi, nous nous sommes mis d’accord sur le modèle suivant (ici en notation JSON) :

Keyspace : LXTrack

{

"Document" (SCF){

RowKey: ApplicationReference {

SCKey: OwnerReference {

{name:"TUUID" value: TUUID}

{name: form, value: FingerPrint}

}

}

"Track" (SCF){

RowKey: "Declaration" {

SCKey: TUUID {

{name: timeStamp, value: declarationContent}

}

RowKey: "Document" {

SCKey: TUUID {

{name: ApplicationReference, value: OwnerReference}

}

}

RowKey: "Fingerprint” {



SCKey: TUUID {

{name: form, value: FingerPrint}

}

}

}

"Fingerprint" (SCF){ {

RowKey: "Document" {

SCKey: FingerPrint {

{name: ApplicationReference, value: OwnerReference}

}

}

RowKey: "Track" {

SCKey: FingePrint {

{name: algorithm, value: TUUID}

}

}

}

}

Nous avons choisir de répéter certaines données, car d’une part cela permet

d’effectuer chaque requête de manière toute aussi efficace. D’autre part Cassandra

est construite de telle sorte que les écritures sont plus rapides que les lectures, ce

qui nous a poussés à penser en termes d’optimisation des accès et non des

insertions.

Par ailleurs même si répliquer les données ne nous a pas paru être une solution

optimale d’un point de vue sécurité (la même donnée est écrite deux fois à desmoments différents à deux endroits différents, ce qui ne garantie pas la consistance

de cette donnée), elle avait l’avantage de nous permettre de pouvoir comparer

différentes façons d’accéder aux données avec Hadoop.

c) Insertion massive dans la base

Nous avons effectués des insertions massives de traces dans Cassandra en suivant le

modèle décrit précédemment sur un cluster de 2 puis de 5 machines. Ainsi l’objectif

était d’insérer 10 millions de traces dans Cassandra.



Pour cela nous avons utilisé un client haut niveau développé pour Cassandra appelé

Hector. Ce dernier fournit une API facilement compréhensible pour insérer et

accéder à des données dans Cassandra, le client fournit avec Cassandra, Thrift, étant

bas niveau et plutôt difficile à prendre en main. Hector gère un grand nombre de

paramètres de manière automatique, ce qui permet de faire des insertions et

requêtes de manière assez simple.

Cependant, nous ne sommes jamais arrivés à un tel résultat. En effet, Cassandra est

censé flusher les données sur le disque quand son « heap space » (mémoire vie

allouée à Cassandra) dépasse un certain seuil, ce qu’elle ne fait pas. Au lieu de ça

Cassandra flush de moins en moins les données jusqu’à se retrouver bloquée et

crasher. Nous avons essayé de forcer Cassandra à flusher en modifiant de nombreux

paramètres mais ça n’a rien changé.

Ainsi, nous n’avons pu insérer qu’environ 1 700 000 traces dans la base de donnée

sur un cluster de 5 machines.

Evolution du heap space pour l’insertion de 1 500 000 traces consécutives (machine

qui insérait les données) :

Allure de la courbe sur les autres machines (le heap space de la machine n’était ici

pas vide au démarrage du test) :



Ainsi on remarque que les donnés sont principalement insérées sur la machine ou

s’exécute le programme d’insertion mais également distribuées sur les autres

machines.

Par ailleurs Cassandra stocke ses données sous plusieurs formes : tout d’abord dans

son heap space, puis dans des commitlogs, qui sont des fichiers écrit en permanence

durant l’exécution au cas où le nœud crash, et enfin dans son système de fichier sur

le disque lorsque le heap-space est flushé. Ainsi nous avons vu sur plusieurs forums

des utilisateurs de Cassandra conseiller de ne pas écrire les commitlogs et les flushs

du heap space sur le même disque afin de gagner en performance, ce que nous ne

pouvions pas faire.

De plus, les utilisateurs conseillent un heap space de l’ordre de 4 à 8 GB pour faire

tourner Cassandra, le fait que nous ne disposions que de 1 GB a surement limiter nos

possibilités de test.

d) Couplage Hadoop / Cassandra

Nous avons installé et fait fonctionner Hadoop et HDFS sur un cluster de 6 machines

sans problèmes. Nous avons notamment pu exécuter un job MapReduce simple, le

célèbre wordcount, qui compte les mots contenus dans plusieurs fichiers. Nous

avons cependant été surpris par le temps que mettait Hadoop pour effectuer une

opération aussi simple à partir de fichier contenus dans le HDFS, ce qui a confirmé le

fait que HDFS est fait avant tout pour stocker de gros fichier, l’accès aux fichiers

étant plutôt long.

Nous avons ensuite entrepris de faire fonctionner Hadoop au dessus de Cassandra,

étant donné que Cassandra fournit une interface pour surcharger les classes

d’Hadoop de manière à ce que ce dernier charge ses données directement depuis



Cassandra au lieu de les charger depuis le HDFS. Cependant, nous n’avons pas réussi

à exécuter de job MapReduce avec cette interface. Après des recherche sur des

forums et des mailing liste relatives à l’utilisation d’Hadoop, il se trouve que nous

avons utilisé une version de Cassandra trop ancienne (la version stable est sortie

mi- janvier) avec une version d’Hadoop trop récente (apparemment la version 0.21

comporte encore de nombreux bugs liés à l’interface avec Cassandra). Cependant il

était trop tard pour migrer toute notre configuration.

e) HBase

Il nous a semblé judicieux de comparer Cassandra à HBase, car même si nous

n’avions ni le temps ni le matériel pour réellement effectuer des tests de

performances permettant de comparer les deux, nous avons essayé de faire

l’inventaire des principales caractéristiques et différences entre ces deux SGBD

NoSQL.

Par ailleurs, HBase a été développé dans le but premier d’être compatible avec

Hadoop, il y a donc de fortes chances qu’il soit plus facile d’implémenter Hadoop sur

HBase. Cependant le personnel de Novapost souhaitait que nous utilisions Cassandra

car eux-mêmes s’étaient documenté sur le sujet et jugeait que ce SGBD serait plus

adapté à leur besoins.

Ainsi nous sommes arrivés à cette comparaison établie suite aux avis que nous avons

pu lire sur des blogs et sites spécialisés :

Cassandra Hbase

Pas de notion de table La notion de tables existe

Tri des colonnes Pas de tri de colonnes

Concept de SuperColumn => flexibilité Pas de SuperColumn

Support de Map Reduce très récent.

Nécessité d’un cluster Hadoop => transfert

entre cluster.

Cassandra adapté au stockage mais moinsau traitement de données

Map Reduce a toujours été utilisé avec

Hbase.

Hbase construit sur Hadoop => Pas de

transfert de données.Hbase très bien adapté au traitement de

données.

Maintenance relativement simple si pas

d’Hadoop

Maintenance assez complexe

Pas de Java API et peu de documentation Possède un Java API => Facilite la

documentation

Pas de serveur maître => Pas de « Single

Point of failure »

Serveur maître à la fois Datanode et

Namenode, si serveur maître en panne,

seul le Namenode pose problèmeAdapté aux clusters de machines situées à Adapté même aux clusters



courtes distances les uns des autres,

repose sur la rapidité de transfert sur fibre

transcontinentaux.

Donne priorité à la disponibilité des

données

Donne priorité à la consistance des

données

V. Difficultés rencontrées

a) Manque de documentation

La principale difficulté que nous avons rencontrée a été le manque de

documentation due à la nouveauté des technologies utilisées, notamment Cassandra.

En effet il y a un grand engouement pour ces technologies, mais peu de gensmaitrisent leur mise en production. Ainsi de nombreux articles de blog ou de sites

spécialisés détaillent les pour et les contre de chaque implémentation, et annoncent

les différentes fonctionnalités offertes par chaque technologie, mais peu de

documentation existe sur la mise en application de ces technologies.

Par ailleurs, nous pensions au départ que le développement du prototype pour

Novapost était l’objectif principal, mais nous avons compris au fur et à mesure des

discussions avec nos professeurs encadrant que l’objectif était avant tout de bien

comprendre et de tester Hadoop et Cassandra car eux-mêmes ne connaissaient que

très peu ces technologies, ils comptaient donc en premier lieu sur nous pour bienleur expliquer leur fonctionnement et les problèmes associés afin d’évaluer la

viabilité d’une mise en production.

Ainsi de nombreux messages d’erreurs sont restés inexplicables pour nous malgré

nos recherches, et il était assez frustrant de voir sur les forums que nous n’étions pas

les seuls à tomber sur ces erreurs mais que personne ne pouvait donner de solution.

b) Matériel trop peu puissant

Les machines virtuelles nous ont offert un grand confort de travail, mais elles

étaient limitées par la faible puissance qu’on pouvait leur affecter. A de nombreuses

reprises nous avons constatés que les personnes qui utilisent Hadoop conseillent des

configurations assez musclés (8 GB de RAM et au moins 4 cœurs) qui sont loin de la

puissance de notre machine virtuelle monoprocesseur dotée de 2 GB de RAM. En

outre nous n’avons jamais pu faire tourner le cluster sur plus de 6 machines, ce qui

limite également la performance.

Ainsi nous avons pu mettre en place des tests mais les résultats ne nous permettent

pas vraiment d’évaluer les performances d’Hadoop et Cassandra de manière chiffrée.

Elles nous ont cependant permis d’évaluer la complexité de la mise en place d’un tel



système distribuée et surtout de l’importance capitale de la configuration d’un tel

système. Nous nous sommes vite rendu compte que les performances de Cassandra

dépendent directement de la bonne configuration du cluster. Malheureusement

nous avons du limiter celle-ci du fait de la faible puissance des machines. Ainsi nous

aurions aimé étudier l’influence du facteur de réplication sur les performances de

Cassandra mais dès qu’on augmentait celui-ci le système crashait rapidement.

Conclusion

a) Conclusion personnelle

Nous avons énormément appris sur ce projet, et nous gardons le sentiment d’avoir

acquis des connaissances sur des technologies très prometteuses. L’utilisation

d’Hadoop et des bases de données NoSQL ne fait qu’augmenter, et sans elles des

systèmes comme Facebook ne pourraient pas fonctionner. Par ailleurs les blocages

auxquels nous avons fait face nous ont poussés à beaucoup nous documenter, ce qui

nous a permis de bien comprendre les mécanismes d’Hadoop et Cassandra.

Cependant nous ressentons de la frustration due aux nombreuses heures que nous

avons passés à configurer Hadoop et Cassandra, sans succès, pour finalement finir

sur un semi-échec puisque nous n’avons pas pu évaluer la performance de

l’association de ces deux technologies. En effet nous aurions aimé passer plus de

temps sur les problèmes d’implémentation et d’optimisation du modèle que sur la

configuration d’Hadoop et Cassandra.

Le manque de documentation et les nombreux bugs et incompatibilités que nous

avons rencontré nous a cependant montré l’importance du choix d’une technologie,

surtout lorsqu’il s’agit d’open source. Ainsi nous avons compris qu’il ne faut pas se

précipiter sur les version trop récentes d’un projet, car la documentation repose

beaucoup sur les retours des utilisateurs, et qu’une communauté importante est

primordiale : la plupart des solutions aux bugs que nous avons rencontré se trouvent

sur les mailing liste des projets concernés.

b) Estimation du temps de travail

Travail effectué Julien Siman Total (h)

Rendez-vous avec l’encadrant 8 8 16

Documentation sur Cassandra et conception

du modèle de donnée

10 10

20

Installation et configuration Cassandra

(Cluster)

12 10

22



Documentation sur Hector 4 2 6

Développement Hector-Cassandra 6 4 10

Mise en place et exécutions des tests 15 5 20

Documentation Hadoop 7 12 19

Installation et configuration Hadoop (Cluster) 12 14 26Intégration Hadoop/Cassandra 8 5 13

Rapport 12 20 32

Slides 3 4 7

Soutenance 1.50 1.50 191

Références

http://www.novapost.fr/

http://fr.wikipedia.org/wiki/NoSQL

http://fr.wikipedia.org/wiki/Cassandra_%28base_de_donn%C3%A9es%29

http://fr.wikipedia.org/wiki/Hadoop

http://www.geekontheloose.com/programming/java/cassandra-0-7-and-hector-for-noo

bs/

http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model

http://cassandra.apache.org/

http://hadoop.apache.org/

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluste

r/

http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-multi-node-cluster

/

http://cxwangyi.blogspot.com/2009/12/wordcount-tutorial-for-hadoop-0201.html

http://code.google.com/p/hadoop-map-reduce-examples/ http://www.higherpass.com/java/Tutorials/Building-Hadoop-Mapreduce-Jobs-In-Java/

http://cscarioni.blogspot.com/2010/11/hadoop-basics.html

http://www.datastax.com/sites/default/files/hector-v2-client-doc.pdf

http://www.divconq.com/2010/cassandra-columns-and-supercolumns-and-rows/

http://blog.octo.com/nosqleu-et-nosql-quen-est-il/









http://www.geekontheloose.com/programming/java/cassandra-0-7-and-hector-for-noobs/









http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-single-node-cluster/



http://www.michael-noll.com/tutorials/running-hadoop-on-ubuntu-linux-multi-node-cluster/





http://code.google.com/p/hadoop-map-reduce-examples/


http://www.higherpass.com/java/Tutorials/Building-Hadoop-Mapreduce-Jobs-In-Java/






























Documents

RapportGerlierChen