Prototypage et évaluation de performances d un service de traçabilité avec une architecture distribuée basée sur Hadoop

Transcription

1 Julien Gerlier Siman Chen Rapport de projet de fin d étude ASR 2010/2011 Prototypage et évaluation de performances d un service de traçabilité avec une architecture distribuée basée sur Hadoop Encadrants : - Bruno Defude (TMSP), - Elisabeth Brunet (TMSP), - Amin Sakka (Novapost)

2 Sommaire Sommaire... 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 d) Les limites III. Hadoop et HDFS a) Introduction b) Conception et déploiement d un système de fichiers distribué c) Prévention des échecs d écriture d) Paramètres de performances e) MapReduce IV. Mise en place du prototype et tests a) Environnement de travail b) Conception de la base de données c) Insertion massive dans la base d) Couplage Hadoop / Cassandra e) HBase V. Difficultés rencontrées a) Manque de documentation b) Matériel trop peu puissant Conclusion a) Conclusion personnelle b) Estimation du temps de travail Références... 22

3 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/serveur 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 technologies permettant 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 étapes envisagé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.

4 I. Présentation du projet a) Contexte Novapost est une entreprise qui propose à d autres entreprises un service de dé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 feuille de paie à la fin du mois par exemple). Or, le service actuel utilise une base de

5 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 de donné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 framework d 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é.

6 II. Cassandra a) Introduction Le modèle de donnée de Cassandra est plus ou moins dérivé de celui de BigTable, un SGBD 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ême ColumnFamily (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. Les Keyspaces: b) La structure de données 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 arbitraire comme pour les tuples d une base de données SQL. Ainsi on peut par exemple

7 prendre comme clé le nom de l attribut, comme dans cet exemple : { // ceci est une colonne name: " address", value: "arin@example.com", timestamp: 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 qui ont 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: , {name: "city", value: "san francisco", timestamp: , 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 de limitation quant au nombre de Familles de colonnes mais ce nombre doit rester

8 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 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 cléde la row // cette row contient 3 colonnes username: "phatduckk", "phatduckk@example.com", phone: "(900) ", // end row ieure: { // ceci est la clé d une autre row de la même ColumnFamily // cette row contient 5 colonnes username: "ieure", "ieure@example.com", phone: "(888) " 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",

9 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 :

10 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, au moment 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.

11 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 par nœ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

12 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 le NameNode 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 autre 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 than Moving Data ). HDFS fournit donc une interface pour pouvoir déplacer le traitement

13 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 librairie MapReduce 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.

14 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 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 à avoir 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 les requêtes principales par lesquelles s opèreront les accès aux fichiers dans la base.

15 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 {

16 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 à des moments 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.

17 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 traces dans la base de donnée sur un cluster de 5 machines. Evolution du heap space pour l insertion de 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) :

18 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

19 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 Pas de notion de table Tri des colonnes Concept de SuperColumn => flexibilité Support de Map Reduce très récent. Nécessité d un cluster Hadoop => transfert entre cluster. Cassandra adapté au stockage mais moins au traitement de données Maintenance relativement simple si pas d Hadoop 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 données. Hbase très bien adapté au traitement de données. 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ème Adapté aux clusters de machines situées à Adapté même aux clusters

20 courtes distances les uns des autres, repose sur la rapidité de transfert sur fibre Donne priorité à la disponibilité des données transcontinentaux. 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 gens maitrisent 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 bien leur 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