Julien Gerlier Siman Chen

Rapport de projet de fin dtude ASR 2010/2011

Prototypage et valuation de performances dun service de traabilit avec une architecture distribue base sur Hadoop

Encadrants :
- Bruno Defude (TMSP), - Elisabeth Brunet (TMSP), - Amin Sakka (Novapost)

Sommaire
Sommaire ............................................................................................................................. 2 Introduction ......................................................................................................................... 3 I. Prsentation 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 donnes........................................................................................ 6 c) Les avantages ...................................................................................................... 10 d) Les limites ............................................................................................................ 10 III. Hadoop et HDFS ............................................................................................................ 10 a) Introduction......................................................................................................... 10 b) Conception et dploiement dun systme de fichiers distribu ......................... 11 c) Prvention des checs dcriture ........................................................................ 12 d) Paramtres 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 donnes ..................................................................... 14 c) Insertion massive dans la base ............................................................................ 16 d) Couplage Hadoop / Cassandra ............................................................................ 18 e) HBase................................................................................................................... 19 V. Difficults rencontres ................................................................................................... 20 a) Manque de documentation ................................................................................ 20 b) Matriel trop peu puissant.................................................................................. 20 Conclusion.......................................................................................................................... 21 a) Conclusion personnelle ....................................................................................... 21 b) Estimation du temps de travail ........................................................................... 21 Rfrences ......................................................................................................................... 22

Introduction

Le cloud computing est un concept apparu rcemment, mais de plus en plus la mode dans le secteur de linformatique. Littralement "l'informatique dans les nuages", il consiste pour les entreprises externaliser et distribuer les ressources numriques qu'elles stockent, cest--dire l'utilisation de la mmoire et des performances des ordinateurs, avec des serveurs rpartis dans le monde entier lis par un rseau, tel Internet. Les utilisateurs du nuage pourraient ainsi disposer d'une puissance informatique considrable et modulable. Novapost est une entreprise qui propose un services de dmatrialisation de documents valeur lgales, comme des feuilles de paie par exemple, qui sont stocks sous forme numrique et suivi par un service de traage qui enregistre les moindres oprations effectues sur ces fiches afin de maintenir leur valeur lgale. Pour linstant le service de Novapost repose sur une architecture client/serveur classique mais suite au nombre croissant de client, ils envisagent de totalement distribuer leur architecture. Notre projet de fin dtude a pour but dtudier les mthodes et technologies permettant raliser la nouvelle architecture rpartie. Nous nous intresserons particulirement aux technologies Cassandra, Systme de Gestion de Base de Donnes (SGBD) NoSQL, et Hadoop, framework Java destin aux applications distribues et la gestion intensive des donnes. Ce sont des technologies rcentes, encore relativement peu connues du grand public mais auxquelles on associe dj des grands noms parmi lesquels : Facebook, Yahoo ou encore Twitter. Ce prsent rapport se divisera en cinq grandes parties. Dans un premier temps, nous allons prsenter de manire dtaille notre les objectifs du projet et les tapes envisages au dpart. Puis, les deuxime et troisime parties porteront sur respectivement nos tudes de Cassandra et dHadoop, les deux technologies cls de notre projet. La partie suivante explicitera les diffrents tests et dveloppement que nous avons effectus. Enfin, nous parlerons dans une dernire partie des difficults que nous rencontres et des bilans que nous en avons tirs.

I. Prsentation du projet
a) Contexte

Novapost est une entreprise qui propose dautres entreprises un service de dmatrialisation de leur processus de gestion documentaire, un exemple : la gestion des fiches de paie. Dans le monde de la dmatrialisation, les exigences sur la traabilit des documents sont trs importantes. En effet, la dmatrialisation des processus et des documents sinscrit dans un cadre lgislatif rigoureux, on doit tenir compte de la criticit des documents grer, et assurer leur prennit ainsi que confidentialit. Do le besoin pour un service dcrivant les oprations effectues sur les documents par les diffrents systmes et acteurs intervenant dans la chaine de traitement de ce dernier. Pour cela, Novapost a mis en place un service de traabilit appel LX Track : cest un service qui permet de centraliser les traces des oprations effectus sur les documents afin dassurer leur valeur probante.

Ce service est constitu dun client web qui interroge le service de traage, lensemble des fichiers de trace tant indexs par une base SQL.

b)

Objectifs

Lune des priorits de Novapost est la performance : chaque service Novapost est dvelopp pour tre opr dans un contexte de haute disponibilit, avec une capacit de traitement industriel. Un tel service doit supporter de brusque monte en charge sur des quipements standards (quand tout le monde consulte sa feuille de paie la fin du mois par exemple). Or, le service actuel utilise une base de

donnes MySQL classique qui supporte de plus en plus mal ces montes en charge et ne sera bientt plus adapte en raison du nombre croissant de connexion et de fichiers stocker. Pour cette raison, nous souhaitons rendre larchitecture de ce service totalement rparti. Ceci ncessite lutilisation dun systme de stockage distribu.

c)

Technologies choisies

Pour lindexation des fichiers de traces, Novapost souhaite migrer le modle 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 (Systme de gestion de base de donnes) NoSQL dvelopp par la fondation Apache. Cassandra est conue pour grer des quantits massives de donnes rparties sur plusieurs serveurs (cluster), en assurant tout particulirement une disponibilit maximale des donnes et en liminant les point individuel de dfaillance. Initialement dveloppe par Facebook, l'application a t libre dans l'espace open-source et rapidement adopte par plusieurs grandes entreprises grant d'importants volumes de donnes, telles que Twitter ou digg.com. Pour interroger les traces de manire la plus rapide possible, Novapost nous a propos dutiliser une architecture base sur Hadoop, un framework dimplmentation de lalgorithme MapReduce en Java dvelopp lui aussi par Apache. Hadoop est un systme scalable, avec une bonne tolrance aux fautes pour le stockage et le traitement de gros volumes de donnes. Il utilise un systme de fichiers distribu appel HDFS (Hadoop Distributed File System) mais peut aussi effectuer des oprations directement dans une base de donne SQL.

d)

Travail effectuer

Les objectifs au commencement du projet taient les suivants : Etudier Cassandra et son modle de base de donnes Dfinir une structure de base de donnes adapte Etudier Hadoop et lalgorithme MapReduce Proposer une implmentation de prototype alliant Hadoop Cassandra permettant dinterroger les traces via des oprations MapReduce Effectuer des tests de performance du prototype : monte en charge, insertion massive de donne, etc. Optimiser le modle pour obtenir quil soit au maximum paralllis.

II. Cassandra
a) Introduction
Le modle de donne de Cassandra est plus ou moins driv de celui de BigTable, un SGBD NoSQL dvelopp par Google. Les dveloppement de Cassandra ont commencs au sein de Facebook, puis ont t transmis la communaut Open Source. Cette base de donnes non relationnelle comme toute base NoSQL a pour but d'amliorer les bases de donnes dans une direction ncessitant une volutivit horizontale. Sa structure se rapproche de celle de tous les autres modle NoSQL : on dit que cest une base oriente colonne. Cassandra peut tre pense 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), identifis par une cl. Chaque row contient des colonnes. Une colonne est un triplet {cl, valeur, timestamp} qui sapparente 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 llment valeur contient lui-mme une colonne (triplet {cl, valeur, timestamp}. Les SGBD classiques sont orients lignes. Chaque ligne contient un tuple qui a un nombre prcis dattributs. Dans un SGBD orient colonne, chaque ligne peut stocker un nombre diffrent de colonnes, et deux lignes appartenant la mme ColumnFamily (plus ou moins quivalente une table dans un SGBD classique) peuvent contenir des colonnes de types diffrents. Il ny a alors plus de relations entre les donnes au sens dun SGBD relationnel classique : il faut penser plus en termes defficacit des requtes quen termes de relation entre les donnes.

b)
Les Keyspaces:

La structure de donnes

Il faut penser les keyspaces comme des espaces de travail, des domaines. Il sagit du plus haut niveau dorganisation de Cassandra.

Les colonnes : Les colonnes sont des structures qui sont identifies par une cl (aussi appel nom) et une valeur dfini par lutilisateur ainsi que par un timestamp qui indique la dernire date laquelle a t modifie la donne. Il faut noter que dans Cassandra les cls ont une valeur informative, elles ne sont pas gnres de manire arbitraire comme pour les tuples dune base de donnes SQL. Ainsi on peut par exemple

prendre comme cl le nom de lattribut, comme dans cet exemple : { // ceci est une colonne name: "emailAddress", value: "arin@example.com", timestamp: 123456789 } Les colonnes peuvent tre tries par leur cl ou leur timestamp. Ce paramtre doit tre dtermin la cration de la ColumnFamily, car les colonnes sont tries leur insertion.

Les super-colonnes : Les colonnes de type super sont des structures qui ont une cl, un timestamp et qui ont pour valeur un nombre infini de colonnes associes, chacune repre par une cl qui est simplement le nom de la colonne. Ils ont les mmes caractristiques que les colonnes. Lordre 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 namevalue on obtient quelque chose plus lisible: homeAddress: { street: "1234 x street", city: "san francisco", }

Les familles de colonnes (ColumnFamily) : Un keyspace est compose dune ou plusieurs Familles de colonnes. Le nombre, le nom, le type (simple ou super), le format de stockage des donnes, ainsi que les autres paramtres des ColumnFamily sont fixs lors de leur cration. Il ny pas de limitation quant au nombre de Familles de colonnes mais ce nombre doit rester

relativement restreint : chacune delle est stockes dans des systmes de fichier distinct, il est donc plus couteux daccder plusieurs ColumnFamily diffrentes simultanment. Au sein de chaque famille, les donnes sont stockes en ligne (identifi par une cl elle aussi dfini par lutilisateur) qui contient un ensemble de colonnes ou de super colonnes. 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 clde la row // cette row contient 3 colonnes username: "phatduckk", email: "phatduckk@example.com", phone: "(900) 976-6666" }, // end row ieure: { // ceci est la cl dune autre row de la m ColumnFamily me // cette row contient 5 colonnes username: "ieure", email: "ieure@example.com", 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 identifies par une cl.

AddressBook = {// ceci est une ColumnFamily de type super (ou SuperColumnFamily) Paul: { // ceci est la clde la row, elle correspond ici au propri taire de lAddressBook // ici nous avons deux SuperColumn dans cette row, chaque SuperColumn est une entre de lAdressBook 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 dune 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 schma : Cassandra permet de ne pas figer les structures qui seront utilises. On peut ajouter ou en retirer au fur et mesure des SuperColumn ou des colonnes indpendamment pour chaque row. Attention il faut nanmoins, au moment du dmarrage du cluster fixer les noms des keyspaces et des ColumnFamily qui seront utilises (on ne peut pas crer la vole). Scalabilit relle : Cassandra permet de passer lchelle trs facilement. On peut ajouter une machine la vole sans avoir a redmarrer aucun processus, ni changer les requtes ou avoir a re-dispatcher les donnes. Par ailleurs, des outils permettent dquilibrer le volume de donne entre les diffrents nuds automatiquement. Ecritures distribues : Cassandra est conue pour que les critures nchouent jamais, il ny a pas de single point of failure : si un nud tombe, un autre prend le relais. Par ailleurs les donnes sont rpliques lors de lcriture. Ainsi si un nud tombe on peut accder la donne sur un autre nud.

d)

Les limites

Toutes les donnes contenues dans une row doivent tenir sur un mme disque, car seules les cls des rows sont utilises pour dterminer les facteurs de rplication de celle-ci entre les diffrents nuds. Une colonne ne doit par ailleurs pas excder la taille de 2 GB. En outre, dans les ColumnFamily de type super, seule les colonnes sont indexes, et donc laccs une colonne dserialise toutes les colonnes qui sont contenues dans la mme SuperColumn. Cet inconvnient devrait tre supprim dans les prochaines versions.

III. Hadoop et HDFS

a) Introduction
HDFS est un systme de fichier distribu. Il se dmarque des autres systmes de fichier distribus par sa grande tolrance aux fautes et le fait quil soit conu pour tre dploy sur des machines faible cot. HDFS fournit un haut dbit daccs aux donnes et est adapt pour les applications qui ncessitent de grands groupes de donnes. Il a t lorigine conu pour le projet de moteur de recherche web Apache Nutch.

b) Conception et dploiement dun systme de fichiers distribu

HDFS a une architecture de type maitre/esclave. Un cluster HDFS est constitu dun unique NameNode, un serveur maitre qui gre le systme de fichier et notamment les droits daccs aux fichiers. A cela sajoute des DataNodes, en gnral un par nud dans le cluster, qui gre le stockage des donnes affects au nud sur lequel elle se trouve. HDFS dispose dun espace de nom et permet de stocker les donnes sous forme de fichiers. Chaque fichier est divis en blocs, qui sont stockes dans un groupe de DataNodes. Ce sont eux qui rpondent aux requtes de lecture et criture qui vienne du client, et ce sont eux galement qui grent la cration, la suppression et la rplication des blocs selon les instructions du NameNode. HDFS est conu 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 quil puisse se connecter aux autres noeuds via ssh sans avoir besoin de taper un mot de passe chaque fois. Le NameNode dispose dun fichier de configuration dans lequel il entre ladresse de chaque machine sur laquelle tourne un DataNode, et se connecte ensuite chacune de ces machines via SSH au dmarrage de HDFS. Par ailleurs, le NameNode est larbitre et le dpositaire de toutes les mtadonnes du HDFS. HDFS est conu de

telle sorte quaucune donne de lutilisateur ne transite par le NameNode. Chaque donne insre dans HDFS est rplique pour assurer sa persistance. Le facteur de rplication est gal 3 par dfaut, mais il peut tre modifi pour chaque fichier. Par ailleurs, HDFS est rack-aware , c'est--dire que la rplication sadapte larchitecture du cluster. Ainsi si on laisse le facteur de rplication par dfaut 3, en crivant un block sur un DataNode, HDFS va ensuite crire la premire rplique sur un nud dans un autre rack, puis la dernire rplique sur un nud du mme rack que la premire.

c)

Prvention des checs dcriture

Chaque DataNode envoie priodiquement un heartbeat au NameNode. Si le NameNode ne reoit plus ce heartbeat dun DataNode, il considre ce dernier comme inaccessible, et re-rplique les donnes en consquence. Par ailleurs, HDFS intgre un mcanisme de checksum afin de dtecter les donnes corrompues. Ainsi, sa cration chaque fichier du HDFS se voit attribuer un checksum. Quand un client accde un fichier dans le HDFS, il vrifie que les donnes reues de chaque DataNode corresponde au checksum donn. Si ce nest pas le cas, il peut choisir de rcuprer un bloc de donnes dun autre DataNode qui en a la rplique. Le seul single point of failure est le NameNode. Si ce dernier tombe, il est ncessaire de le redmarrer manuellement, sauf si on a lanc lexcution dun SecondaryNameNode qui peut alors prendre le relais.

d)

Paramtres de performances

HDFS est fait pour stocker de gros fichiers (chaque fichier est divis en bloc de 64 MB par dfaut). Daprs la documentation officielle, un fichier typique dans HDFS fait une taille de lordre du GB voire du TB. HDFS est fait pour une trs grande scalabilit et tourne dj en production sur des trs gros clusters (plus de 1000 machines) dans des socits comme Facebook ou Yahoo. HDFS est galement fait pour quon puisse y insrer de trs gros fichiers trs rapidement (quelques minutes pour quelques GB), du moment quon dispose dun cluster assez puissant, en terme de puissance de calcul aussi bien quen terme de charge rseau. De plus HDFS est avant tout conu pour tre utilis avec Hadoop. La philosophie de limplmentation dHadoop repose sur le principe quil est plus efficace de dplacer de la capacit de calcul que des donns (Moving Computation is Cheaper than Moving Data). HDFS fournit donc une interface pour pouvoir dplacer le traitement

des donnes au plus prs de celles-ci. En outre, Hadoop nest pas fait pour excuter un job de manire ponctuelle, mais plutt pour excuter une file de jobs en mode batch de manire priodique. Yahoo! a dvelopp des outils afin de grer la planification et la scurisation de lexcution de jobs et notamment dans le cas ou plusieurs utilisateurs utilisent le mme cluster. Par ailleurs HDFS ne gre pas pour linstant le rquilibrage de charge. Ainsi si on rajoute un DataNode, aucune donne ne sera dplace vers celui-ci afin de rpartir la charge, il faut le faire manuellement.

e)

MapReduce

L'opration "map", crit par l'utilisateur, consiste produire une paire cl/valeurs intermdiaire pour chaque paire de cl/valeur reue en entre. Ensuite la librairie MapReduce groupe toutes les cls intermdiaires associes la mme valeur et les passe la fonction "reduce". L'opration "reduce" consiste fusionner les valeurs d'une mme cl intermdiaire afin de crer une unique valeur associe cette cl et renvoyer un unique couple cl/valeur en sortie pour chaque cl intermdiaire. Lexemple classique est celui du WordCount. En entre l'algorithme reoit le couple "nom du document"/"contenu". L'opration "map" cre une liste de couple cl intermdiaire/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 cls intermdiaire/valeur correspondant la mme cl intermdiaire (ici "mot recherch") en incrmentant un compteur pour chaque occurrence de la mme cl dans la liste de cls intermdiaires. 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 mthode main qui dirige lapplication.

Lexcution des jobs se fait laide dun JobTracker et de Tasktrackers : lors de son excution le job est soumis au JobTracker qui soccupe de le distribuer au Tasktracker qui tourne sur chaque nud. Le JobTracker choisit toujours les TaskTracker qui sont les plus proches de lemplacement de la donne traiter.

IV. Mise en place du prototype et tests

a) Environnement de travail
Nous avions besoin des droits administrateur pour pouvoir travailler avec Hadoop et Cassandra. Ainsi nous avons choisi de travailler avec les machines virtuelles installes sur les comptes Unix de lcole, le tout sur des comptes locaux afin davoir un espace de stockage suffisant et un systme de fichier performant. Nous avons cependant t limits par la performance du matriel : il nest possible daffecter quun seul cur une machine virtuelle et seulement la moiti de la RAM totale (soit 2 GB) du PC hte. Nous avons travaill avec la version 0.7 beta 2 de Cassandra, car la version 0.7 apporte de nombreuses fonctionnalits supplmentaires par rapport la version 0.6, notamment en termes de compatibilit avec Hadoop. Par ailleurs nous avons utilis la version 0.21 dHadoop.

b)

Conception de la base de donnes

Cassandra est une base de donne NoSQL, il faut pour cela saffranchir de la pense relationnelle des bases de donnes classiques : la base doit tre construite afin de permettre laccs le plus rapide possible aux donnes, quitte avoir des redondances. Ainsi Amin Sakka a prfr ne pas nous donner le schma de la base de donnes relationnelle utilise par Novapost actuellement, mais plutt les requtes principales par lesquelles sopreront les accs aux fichiers dans la base.

Les requtes en question sont les suivantes :

String createTrack (String documentId, String identificationSystem)

: cre

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 rsultat est une liste car plusieurs copies du mme document peuvent exister) Ainsi, nous nous sommes mis daccord sur le modle 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 rpter certaines donnes, car dune part cela permet deffectuer chaque requte de manire toute aussi efficace. Dautre part Cassandra est construite de telle sorte que les critures sont plus rapides que les lectures, ce qui nous a pousss penser en termes doptimisation des accs et non des insertions. Par ailleurs mme si rpliquer les donnes ne nous a pas paru tre une solution optimale dun point de vue scurit (la mme donne est crite deux fois des moments diffrents deux endroits diffrents, ce qui ne garantie pas la consistance de cette donne), elle avait lavantage de nous permettre de pouvoir comparer diffrentes faons daccder aux donnes avec Hadoop.

c)

Insertion massive dans la base

Nous avons effectus des insertions massives de traces dans Cassandra en suivant le modle dcrit prcdemment sur un cluster de 2 puis de 5 machines. Ainsi lobjectif tait dinsrer 10 millions de traces dans Cassandra.

Pour cela nous avons utilis un client haut niveau dvelopp pour Cassandra appel Hector. Ce dernier fournit une API facilement comprhensible pour insrer et accder des donnes dans Cassandra, le client fournit avec Cassandra, Thrift, tant bas niveau et plutt difficile prendre en main. Hector gre un grand nombre de paramtres de manire automatique, ce qui permet de faire des insertions et requtes de manire assez simple. Cependant, nous ne sommes jamais arrivs un tel rsultat. En effet, Cassandra est cens flusher les donnes sur le disque quand son heap space (mmoire vie alloue Cassandra) dpasse un certain seuil, ce quelle ne fait pas. Au lieu de a Cassandra flush de moins en moins les donnes jusqu se retrouver bloque et crasher. Nous avons essay de forcer Cassandra flusher en modifiant de nombreux paramtres mais a na rien chang. Ainsi, nous navons pu insrer quenviron 1 700 000 traces dans la base de donne sur un cluster de 5 machines.

Evolution du heap space pour linsertion de 1 500 000 traces conscutives (machine qui insrait les donnes) :

Allure de la courbe sur les autres machines (le heap space de la machine ntait ici pas vide au dmarrage du test) :

Ainsi on remarque que les donns sont principalement insres sur la machine ou sexcute le programme dinsertion mais galement distribues sur les autres machines. Par ailleurs Cassandra stocke ses donnes sous plusieurs formes : tout dabord dans son heap space, puis dans des commitlogs, qui sont des fichiers crit en permanence durant lexcution au cas o le nud crash, et enfin dans son systme 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 mme disque afin de gagner en performance, ce que nous ne pouvions pas faire. De plus, les utilisateurs conseillent un heap space de lordre de 4 8 GB pour faire tourner Cassandra, le fait que nous ne disposions que de 1 GB a surement limiter nos possibilits de test.

d)

Couplage Hadoop / Cassandra

Nous avons install et fait fonctionner Hadoop et HDFS sur un cluster de 6 machines sans problmes. Nous avons notamment pu excuter un job MapReduce simple, le clbre wordcount, qui compte les mots contenus dans plusieurs fichiers. Nous avons cependant t surpris par le temps que mettait Hadoop pour effectuer une opration 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, laccs aux fichiers tant plutt long. Nous avons ensuite entrepris de faire fonctionner Hadoop au dessus de Cassandra, tant donn que Cassandra fournit une interface pour surcharger les classes dHadoop de manire ce que ce dernier charge ses donnes directement depuis

Cassandra au lieu de les charger depuis le HDFS. Cependant, nous navons pas russi excuter de job MapReduce avec cette interface. Aprs des recherche sur des forums et des mailing liste relatives lutilisation dHadoop, il se trouve que nous avons utilis une version de Cassandra trop ancienne (la version stable est sortie mi-janvier) avec une version dHadoop trop rcente (apparemment la version 0.21 comporte encore de nombreux bugs lis linterface avec Cassandra). Cependant il tait trop tard pour migrer toute notre configuration.

e)

HBase

Il nous a sembl judicieux de comparer Cassandra HBase, car mme si nous navions ni le temps ni le matriel pour rellement effectuer des tests de performances permettant de comparer les deux, nous avons essay de faire linventaire des principales caractristiques et diffrences entre ces deux SGBD NoSQL. Par ailleurs, HBase a t dvelopp dans le but premier dtre compatible avec Hadoop, il y a donc de fortes chances quil soit plus facile dimplmenter Hadoop sur HBase. Cependant le personnel de Novapost souhaitait que nous utilisions Cassandra car eux-mmes staient document sur le sujet et jugeait que ce SGBD serait plus adapt leur besoins. Ainsi nous sommes arrivs cette comparaison tablie suite aux avis que nous avons pu lire sur des blogs et sites spcialiss :

Cassandra Pas de notion de table Tri des colonnes Concept de SuperColumn => flexibilit Support de Map Reduce trs rcent. Ncessit dun cluster Hadoop => transfert entre cluster. Cassandra adapt au stockage mais moins au traitement de donnes

Hbase

La notion de tables existe Pas de tri de colonnes Pas de SuperColumn Map Reduce a toujours t utilis avec Hbase. Hbase construit sur Hadoop => Pas de transfert de donnes. Hbase trs bien adapt au traitement de donnes. Maintenance relativement simple si pas Maintenance assez complexe dHadoop Pas de Java API et peu de documentation Possde un Java API => Facilite la documentation Pas de serveur ma => Pas de Single Serveur ma tre tre la fois Datanode et Point of failure Namenode, si serveur ma en panne, tre seul le Namenode pose problme Adapt aux clusters de machines situes Adapt mme aux clusters

courtes distances les uns des autres, transcontinentaux. repose sur la rapidit de transfert sur fibre Donne priorit la disponibilit des Donne priorit la consistance des donnes donnes

V. Difficults rencontres
a) Manque de documentation
La principale difficult que nous avons rencontre a t le manque de documentation due la nouveaut des technologies utilises, notamment Cassandra. En effet il y a un grand engouement pour ces technologies, mais peu de gens maitrisent leur mise en production. Ainsi de nombreux articles de blog ou de sites spcialiss dtaillent les pour et les contre de chaque implmentation, et annoncent les diffrentes fonctionnalits offertes par chaque technologie, mais peu de documentation existe sur la mise en application de ces technologies. Par ailleurs, nous pensions au dpart que le dveloppement du prototype pour Novapost tait lobjectif principal, mais nous avons compris au fur et mesure des discussions avec nos professeurs encadrant que lobjectif tait avant tout de bien comprendre et de tester Hadoop et Cassandra car eux-mmes ne connaissaient que trs peu ces technologies, ils comptaient donc en premier lieu sur nous pour bien leur expliquer leur fonctionnement et les problmes associs afin dvaluer la viabilit dune mise en production. Ainsi de nombreux messages derreurs sont rests inexplicables pour nous malgr nos recherches, et il tait assez frustrant de voir sur les forums que nous ntions pas les seuls tomber sur ces erreurs mais que personne ne pouvait donner de solution.

b)

Matriel trop peu puissant

Les machines virtuelles nous ont offert un grand confort de travail, mais elles taient limites par la faible puissance quon pouvait leur affecter. A de nombreuses reprises nous avons constats que les personnes qui utilisent Hadoop conseillent des configurations assez muscls (8 GB de RAM et au moins 4 curs) qui sont loin de la puissance de notre machine virtuelle monoprocesseur dote de 2 GB de RAM. En outre nous navons 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 rsultats ne nous permettent pas vraiment dvaluer les performances dHadoop et Cassandra de manire chiffre. Elles nous ont cependant permis dvaluer la complexit de la mise en place dun tel

systme distribue et surtout de limportance capitale de la configuration dun tel systme. Nous nous sommes vite rendu compte que les performances de Cassandra dpendent 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 linfluence du facteur de rplication sur les performances de Cassandra mais ds quon augmentait celui-ci le systme crashait rapidement.

Conclusion
a) Conclusion personnelle
Nous avons normment appris sur ce projet, et nous gardons le sentiment davoir acquis des connaissances sur des technologies trs prometteuses. Lutilisation dHadoop et des bases de donnes NoSQL ne fait quaugmenter, et sans elles des systmes comme Facebook ne pourraient pas fonctionner. Par ailleurs les blocages auxquels nous avons fait face nous ont pousss beaucoup nous documenter, ce qui nous a permis de bien comprendre les mcanismes dHadoop et Cassandra. Cependant nous ressentons de la frustration due aux nombreuses heures que nous avons passs configurer Hadoop et Cassandra, sans succs, pour finalement finir sur un semi-chec puisque nous navons pas pu valuer la performance de lassociation de ces deux technologies. En effet nous aurions aim passer plus de temps sur les problmes dimplmentation et doptimisation du modle que sur la configuration dHadoop et Cassandra. Le manque de documentation et les nombreux bugs et incompatibilits que nous avons rencontr nous a cependant montr limportance du choix dune technologie, surtout lorsquil sagit dopen source. Ainsi nous avons compris quil ne faut pas se prcipiter sur les version trop rcentes dun projet, car la documentation repose beaucoup sur les retours des utilisateurs, et quune communaut importante est primordiale : la plupart des solutions aux bugs que nous avons rencontr se trouvent sur les mailing liste des projets concerns.

b)

Estimation du temps de travail

Travail effectu Julien 8 Rendez-vous avec lencadrant Documentation sur Cassandra et conception 10 du modle de donne Installation et configuration Cassandra 12 (Cluster)

Siman
8 10

Total (h)
16 20

10

22

Documentation sur Hector Dveloppement Hector-Cassandra Mise en place et excutions des tests Documentation Hadoop Installation et configuration Hadoop (Cluster) Intgration Hadoop/Cassandra Rapport Slides Soutenance

4 6 15 7 12 8 12 3 1.50

2 4 5 12 14 5 20 4 1.50

6 10 20 19 26 13 32 7 191

Rfrences
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/