Professeur-superviseur Alain April

(1)

RAPPORT TECHNIQUE

PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE DANS LE CADRE DU COURS GTI792

BASE DE DONNÉES DISTRIBUÉE APPLIQUÉE EN GÉNÉTIQUE DANS LE CADRE DE L'ANALYSE DE SÉQUENÇAGE GÉNOMIQUE

JEAN-PHILIPPE BOND BONJ06048709

DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI

Professeur-superviseur Alain April

MONTRÉAL, 13 AOÛT 2012 ÉTÉ 2012

(2)

REMERCIEMENTS

Alain April : Professeur de génie logiciel.

Patrice Dion : Analyste des systèmes et réseaux informatiques, département de systèmes éducationnels et de recherche de l’ÉTS.

Anna Klos : Diplômée de l’ÉTS en génie logiciel.

Ousmane Diallo, B.Sc. : programmeur pour le projet S2D, laboratoire Guy Rouleau, CRCHUM.

(3)

OPTIMISATION DE RECHERCHE GRÂCE À HBASE SOUS HADOOP

JEAN-PHILIPPE BOND BONJ06048709

RÉSUMÉ

Ce projet s’insère dans un contexte d’affaires où le Centre de Recherche du Centre Hospitalier de l’Université de Montréal (CRCHUM) est aux prises avec des problèmes avec un système d’identification de gènes et où l’ÉTS est désireuse d’amasser du matériel en vue d’un cours sur le « Cloud Computing ».

Le CRCHUM, possédant bien au-delà de 150 millions d’enregistrements de données génomiques, utilise à l’heure actuelle un système permettant d’effectuer des recherches sur des gênes afin de, par exemple, trouver certaines variantes de gènes partageant des similarités. Selon les informations publiées sur le site Web du laboratoire Roueleau,

« l’objectif principal du projet Synapse to Disease (de la synapse à la maladie ou S2D) est d’identifier des gènes causants ou prédisposant à des maladies du développement et du fonctionnement neuronal » (http://www.laboguyrouleau.ca/S2D.html). S’appuyant sur une base de données relationnelle conventionnelle, le CRCHUM voit rapidement sa solution atteindre un plateau. En effet, plusieurs de leurs requêtes sont longues à effectuer et ont déjà demandé un remaniement de la base de données important. Leurs responsables voient donc, à l’horizon, un problème dans leur capacité de stocker et effectuer des requêtes efficaces sur les données. Le projet consiste donc à la migration d’une partie du système vers une solution NoSQL.

(4)

TABLE DES MATIÈRES

Page

2.1 Hadoop ...5

2.2 Hbase...6

3.1 Installation et configuration ...9

4.1 Analyse du système...11

5.1 Schéma ...16

5.2 Stratégie de requêtes ...18

5.3 MapReduce vs API HBase...21

6.1 Optimisation des performances sur HBase ...23

7.1 Application cliente ...25

7.2 Application serveur ...26

8.1 Environnement de développement ...27

ANNEXE I ÉTAPES À SUIVRE POUR EFFECTUER L’INSTALLATION EN MODE DISTRIBUÉ ...33

ANNEXE II REQUÊTES SQL DU SYSTÈME DU CRCHUM ...41

ANNEXE III GESTION DES DÉPENDANCES AVEC MAVEN ...43

ANNEXE IV FICHIER ANT ...45

(5)

LISTE DES TABLEAUX

Page Tableau 1 – Exemple de table HBase ...7

(6)

LISTE DES FIGURES

Page

Figure 1 - Architecture de Hadoop ...5

Figure 2 - Architecture du cluster ...10

Figure 3 - Base de données de système S2D ...13

Figure 4 - Table HBase ...17

Figure 5 - Performance du scanneur ...24

Figure 6 - Démonstration de l'application cliente ...25

Figure 7 - Structure du projet Eclipse ...27

(7)

LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES

API Application Programming Interface ADN Acide désoxyribonucléique

CRCHUM Centre de Recherche du CHUM CPU Central Processing Unit

GIG GigaByte

HDFS Hadoop Distributed File system JPS Java Process Status tool

MB MegaByte

NoSQL Not only SQL

RAM Random Access Memory

SGBD Système de gestion de base de données

SSH Secure SHell

JDK Java Development Kit

REST Representational State Transfer RIA Rich Internet Application

(8)

INTRODUCTION

Au cours des dernières années, un nombre impressionnant de nouvelles technologies ont émergé dans le secteur des technologies de l’information. Nous avons assisté au développement d’un nombre marquant de technologies disposé au traitement de « Big Data

». Ce dernier désigne des ensembles de données très volumineux qui sont difficilement exploitables à l’aide des outils classiques de gestion de base de données. Ces nouvelles technologies sont destinées à résoudre ce problème en fournissant les outils nécessaires au développement de solutions logicielles permettant d’exploiter un nombre quasi infini de données. Les perspectives générées par ces technologies sont nombreuses, non seulement pour les entreprises dans le domaine des technologies, mais aussi pour le domaine financier et la science en général. La Biologie est l’un des domaines qui pourront grandement bénéficier de ces avancements technologiques, les scientifiques exerçants dans cette discipline sont quotidiennement confrontés au traitement d’un très grand nombre de données qui ne cessent d’augmenter grâce au progrès continu de cette science.

L’arrivée de l’ère « Big Data » est grandement attribuable au développement et au succès qu’ont connu les grandes entreprises du Web depuis les années 2000. On parle ici notamment de Google et Facebook, les problèmes complexes rencontrés par ces entreprises ont forcé le développement de nouvelles technologies pour subvenir aux demandes grandissantes des utilisateurs. Ces technologies sont dorénavant disponibles pour les développeurs, la majorité étant des solutions « open source ». Elles sont de plus en plus matures et faciles à utiliser malgré leur complexité. L’une des solutions les plus populaires est appelée « Hadoop », un

«framework » facilitant la construction de systèmes distribués permettant le traitement d’un grand nombre de données.

Lors de ce projet, nous nous intéresserons à l’application de base de données distribuée pour l’analyse du séquençage du génome humain. Cette discipline de la Biologie nécessite l’analyse d’un très grand nombre de données. La capacité de traiter un nombre grandissant de

(9)

données ne peut que favoriser la découverte de nouvelles corrélations entre les éléments analysés et ainsi parvenir à trouver des solutions qui sont jusqu’à maintenant inconnues.

En premier lieu, la problématique, le contexte et l’objectif du projet seront présentés. Il y aura ensuite un survol des technologies impliquées ainsi qu’une brève définition expliquant leur fonctionnement. Par ailleurs, la façon d’intégrer et déployer l’ensemble des technologies sur un « cluster » de machines sera expliquée en détail. Suite à l’explication des technologies, nous enchainerons sur la problématique du CRCHUM et les différentes techniques analysées pour migrer vers une base de données HBase. L’ensemble des tests et expérimentations sera présenté tout en expliquant les avantages et les inconvénients de chacune des solutions.

Enfin, nous terminerons avec un retour sur le projet et des recommandations pour les développements futurs.

(10)

CHAPITRE 1

PROBLÉMATIQUE, CONTEXTE ET OBJECTIFS DU PROJET

Le projet est réalisé dans le cadre d’une collaboration entre le centre de recherche du centre hospitalier de l’Université de Montréal (CRCHUM) et le professeur Alain April. Il consiste à répliquer une partie de la base de données relationnelle d’un système permettant de faire de l’analyse de séquence d’ADN vers une solution plus flexible qui faciliterait le traitement d’un nombre grandissant de données. Pour ce faire, il a été décidé d’utiliser le « framework »

« open source » Hadoop et la base de données qui est déployée sur son système de fichier distribué, HBase. Nous tenterons donc de reproduire la logique d’affaire permettant d’interroger les données de la base de données relationnelle actuelle sur une base de données HBase.

L’un des principaux problèmes du logiciel actuel est dû aux limitations des bases de données relationnelles quant au traitement d’un très grand nombre de données. Lorsque la quantité de données voulant être traitées doit être fragmentée pour être stockée sur plusieurs disques, il est difficile de mettre en œuvre une gestion efficace des blocs de données réparties. Par conséquent, il est fréquent d’avoir des problèmes de performances lorsque ce type d’application utilise une base de données relationnelle. Puisque l’un des objectifs du CRCHUM est d’éventuellement être en mesure d’ajouter des données, la migration vers un système utilisant une base de données distribuée serait grandement profitable.

Pour parvenir à une solution, plusieurs étapes devront être réalisées. D’abord, nous devrons être en mesure de migrer le modèle de données relationnel vers un modèle non relationnel.

Lorsque nous aurons atteint cet objectif, les diverses possibilités pour traiter les données du nouveau modèle seront considérées et expérimentées. Pour vérifier les performances des solutions développées, nous tenterons de faire un comparatif entre le temps d’exécution des requêtes sur HBase par rapport aux temps d’exécution des requêtes sur le système actuel.

Pour ce faire, nous mettrons en place en environnement de test sur un cluster de 3 machines.

(11)

Le second objectif du projet vise à créer un environnement de développement pour Hadoop et HBase pouvant être utilisé par M. Alain April dans le cadre de son nouveau cours d’informatique en nuage. L’environnement de développement permettrait à des étudiants du cours de développer une application utilisant Hadoop et HBase. Puisque la technologie est relativement récente et qu’il y a un nombre restreint de documentations, cet environnement faciliterait la tâche des étudiants tout en leur fournissant un cadre de développement stable et fonctionnel.

Pour débuter le projet, nous nous baserons sur les travaux entrepris par Mme Anna Klos.

Lors de ses travaux, Mme Klos a réussi à transférer une partie des données du système du CRCHUM vers une base de données HBase et a réussi à effectuer des requêtes de bases.

Nous essayerons donc d’améliorer la solution dans le but de réaliser un système ayant les mêmes fonctionnalités que le système du CRCHUM.

(12)

CHAPITRE 2

REVUE DE LA LITÉRATURE

Plusieurs technologies seront utilisées pour réaliser le projet, un cours résumé expliquant le fonctionnement de chacune d’entre elles sera présenté dans cette section. Puisque l’objectif du projet n’est pas nécessairement de travailler directement sur le développement des technologies, certaines notions seront seulement présentées sommairement, des références seront proposées pour les lecteurs qui désirent avoir plus d’information.

2.1 Hadoop

Comme mentionné ci-haut, Hadoop est un « framework » « open source » permettant le développement d’application distribué traitant un nombre quasi infini de données. Hadoop est basé sur deux publications faites par Google au début des années 2000, « Google MapReduce » et « Google File System ». Voici un diagramme illustrant l’architecture haut niveau de Hadoop :

Figure 1 - Architecture de Hadoop

(13)

HDFS est le système de stockage primaire utilisé par les applications Hadoop, il permet de faciliter la gestion des données distribuées en répliquant et répartissant des blocs de données sur les nœuds du cluster. L’architecture de HDFS est basée sur le modèle maître-esclave, il y a donc un processus maître (NameNode) qui s’occupe de la gestion de la distribution des données sur le cluster et des processus esclaves (DataNode) qui permettent de traiter les données sur chacun des nœuds. Typiquement, les données sont divisées en bloc de 64MB ou 128MB.

Pour traiter les données dans un système ayant cette architecture, de nouvelles techniques ont été développées. Hadoop utilise une technique qui se nomme MapReduce, c’est en fait un

« framework » permettant le traitement parallèle des données distribuées. Dans l’architecture illustrée ci-haut, les deux processus permettant d’exécuter des tâches MapReduce sont le JobTracker et le TaskTracker. Le JobTracker est utilisé pour distribuer les tâches sur les nœuds du cluster, il contacte le NameNode pour localiser les données et ensuite soumettre les tâches aux TaskTracker. Les TaskTracker sont en fait les processus qui acceptent les tâches et qui exécutent les différentes opérations sur chacun des nœuds où se retrouvent les données.

Le traitement des données se fait en deux étapes, « map » et « reduce ». Généralement, lors du lancement d’un « job » MapReduce, les données sont divisées en plusieurs ensembles indépendants. Chacun des ensembles est traité par une tâche « map » qui s’occupe de réorganiser et traiter les données. La sortie de la tâche « map » est utilisée comme entrée de la tâche « reduce ». Celle-ci consiste à récupérer les données de la tâche « map » et les réduire en un seul ensemble trié. Chacun des éléments traités par MapReduce est stocké dans un « HashMap » contenant des ensembles de clés et valeurs.

2.2 Hbase

HBase est une base de données non relationnelle distribuée sur le système de fichier de Hadoop (HDFS), son développement a fortement été influencer par la publication de Google sur leur base de données Big Table. HBase est une base de données orientée colonne, c’est-à-

(14)

7

dire que les données sont stockées dans des familles de colonnes plutôt que dans des rangées fixes comme dans la majorité des bases de données relationnelles. Sur le disque, les données sont stockées dans des « Map » multidimensionnels triés par ordre lexicographique. Par exemple, si nous avons plusieurs entrées ayant les clés : 000001, 000010, 00000a, 00001a, 00000b, 110000. Les données seront ordonnées de la façon suivante : 000001, 00000a, 00000b, 000010, 00001a, 110000. Il est donc important de bien définir les clés lorsque l’on fait la modélisation d’un schéma HBase, elles auront impact significatif sur la performance du système.

Si l’on prend l’exemple d’une base de données qui permet de stocker des courriels, le modèle relationnel serait composé de trois tables : utilisateur, courriel et une table pour faire la relation entre les utilisateurs et les courriels. Pour chaque courriel, il aurait une entrée dans la table de courriel et une entrée dans la table de référence. Sur HBase, il y aurait une seule table pour stocker toute l’information en utilisant une rangée par utilisateur. Chaque rangée contiendrait deux familles de colonnes, une pour stocker l’information de l’utilisateur et l’autre pour stocker les courriels. Donc, les colonnes d’une table HBase pourraient être illustrées de la façon suivante :

Tableau 1 – Exemple de table HBase

Utilisateur Courriel

1 utilisateur:nom utilisateur:email courriel:timestamp1 courriel:timestamp2 courriel:timestampN 2 utilisateur:nom utilisateur:email courriel:timestamp1 courriel:timestamp2 courriel:timestampN 3 utilisateur:nom utilisateur:email courriel:timestamp1 courriel:timestamp2 courriel:timestampN

Il y aurait donc autant de colonnes dans la famille courriel que de courriels reçus par cet utilisateur. Dans cet exemple, nous utilisons un « timestamp » pour définir la clé d’un courriel, ce qui a pour avantage d’avoir les courriels triés par date. Puisque la majorité du temps, nous risquons de consulter seulement les derniers courriels reçus, la sélection d’un intervalle de date serait facilement accessible pour la première page d’une interface graphique présentant les courriels reçus. La définition des clés pour la problématique que

(15)

l’on tente de résoudre sera présentée dans la section sur les stratégies de requêtes et les performances de HBase.

La façon dont HBase stocke les fichiers dans HDFS ne sera pas présentée dans ce rapport puisqu’elle ne fait pas parti de la portée du projet. Par contre, pour avoir plus d’information sur les détails techniques, il est intéressant de jeter un coup d’œil sur la documentation de HDFS et HBase. Un article très pertinent a aussi été écrit sur le sujet par Lars Goerge, un

membre de la communauté HBase depuis le début du projet.

(http://www.larsgeorge.com/2010/05/hbase-file-locality-in-hdfs.html)

(16)

CHAPITRE 3

DÉPLOIEMENT DE HADOOP ET HBASE EN MODE DISTRIBUÉ

3.1 Installation et configuration

Hadoop et HBase peuvent être déployés en mode autonome, pseudo distribué ou distribué.

Le mode autonome est généralement utilisé à des fins de tests tant disque le mode distribué est utilisé en production. Dans cette section, la démarche pour déployer Hadoop et HBase en mode distribué sera présentée. Pour tester le déploiement de notre solution sur un cluster, nous avons décidé d’utiliser un cluster de 3 machines. Bien sûr, il faudrait davantage de machines pour déployer notre solution en production, nous voulions seulement être en mesure de faire des tests sur ce type d’architecture.

Le cluster utilisé est en fait 3 machines virtuelles fonctionnant avec Ubuntu 12.02. Chacune des machines virtuelles utilise 4 CPU, 32GIG de RAM et 125GIG d’espaces disque. Les distributions de Hadoop et HBase utilisées pour le déploiement sur le cluster sont les suivantes :

 HBase-0.92.1

 Hadoop-1.0.3

Puisque nous avons seulement 3 machines à notre disposition, nous avons décidé d’utiliser une machine pour le « master » de Hadoop et HBase et deux machines « slave » pour stocker les données. Le diagramme suivant illustre la disposition des processus sur le cluster :

(17)

Figure 2 - Architecture du cluster

Avant de commencer l’installation de Hadoop sur le cluster, il est important de considérer certains éléments pour éviter d’avoir des problèmes. En premier lieu, il faut s’assurer que le

« firewall » installé sur nos machines ne bloque pas l’accès aux ports qui seront utilisés par les processus de Hadoop et HBase. Tous les ports utilisés par l’application sont configurables. Généralement, si certains ports ne sont pas accessibles lors du démarrage de l’application, des messages d’erreurs indiquant que l’accès a été refusé devraient apparaitre dans les logs des machines concernées.

Ensuite, il est important d’utiliser les mêmes distributions de Hadoop et HBase sur l’ensemble des machines du cluster. Si des distributions différentes sont utilisées sur certaines machines, il risque d’y avoir des problèmes de compatibilité entre les API. Par exemple, une tâche MapReduce pourrait fonctionner seulement sur les nœuds ayant la même distribution puisque l’API de MapReduce a été modifié et certaines classes ont été changées ou même supprimées.

Toutes les indications et étapes permettant d’installer le cluster sont présentées dans l’annexe 1.

(18)

11

CHAPITRE 4

SYSTÈME DU CRCHUM

4.1 Analyse du système

Pour faire simple, le système du CRCHUM permet de comparer les variantes contenues dans les séquences du génome de patients qui sont atteints de certaines maladies. Le système permet d’identifier les variantes qui se retrouvent dans les séquences du génome d’un ou des patients ayant une maladie et qui ne se retrouvent pas dans les séquences du génome d’autres patients n’ayant pas cette maladie ou ayant une autre maladie.

L’ensemble des algorithmes et outils utilisés pour séquencer le génome d’un patient est appelé un pipeline de dépistage, généralement, il utilise des variantes des éléments suivants :

 Un séquenceur

 Algorithme de détection de variant

 Algorithme d’annotation de variant

 Algorithme d’alignement de séquence

Le pipeline est construit en combinant les éléments précédents, il existe donc autant de pipelines différents que de combinaison possible. Les variantes d’une séquence sont connues, ce qui varie entre les patients est la position qu’ils peuvent occuper dans une séquence. Donc, le système doit stocker l’information sur toutes les variantes contenue dans les séquences d’un échantillon pour chacun des pipelines utilisé pour l’analyse. Puisqu’un échantillon contient des milliers de variants, il y a un très grand nombre de données à stocker.

Puisque l’élément du système qui nous intéresse pour la migration vers HBase est la base de données, seulement cette composante sera analysée. Le système actuel utilise une base de données MySQL et le moteur d’accès Infobright. Ce dernier est un SGBD orienté colonne.

Même si HBase est souvent référencé comme étant un SGBD orienté colonne, il y a des différences fondamentales entre les deux technologies. Pour stocker les données, HBase

(19)

utilise des « Map » multidimensionnels tant disque Infobright utilise le modèle traditionnel des bases de données relationnelles, c’est pourquoi il est possible d’utiliser des requêtes SQL avec Infobright. La différence majeure entre Infobright et une base de données traditionnelle est qu’il stocke les données par colonne et que chaque colonne peut être accéder de façon indépendante. Le fait de stocker les données par colonnes permet d’avoir un meilleur taux de compression puisque généralement les données d’une même colonne sont très similaires.

Enfin, Infobright est un SGBD permettant de stocker et traiter un nombre de données important tout en utilisant une interface SQL. Même s’il est plus performant qu’une base de données relationnelle pour traiter un grand nombre de données, la technologie est tout de même limitée due à son caractère non distribué.

Avant de regarder le schéma HBase qui a été développé, la base de données actuelle sera présentée, cette analyse permettra de justifier certains concepts et comprendre la logique derrière les requêtes utilisées. La figure suivante illustre le schéma de la base de données du système actuellement utilisé par le CRCHUM :

(20)

13

Figure 3 - Base de données de système S2D

(21)

Comme mentionnée ci-haut, la table « NGS_vcf_screening_pipeline » contient les différentes combinaisons d’algorithme qui compose un pipeline de dépistage. Ces tables contiennent peu de données et ne seront pas considérées pour la migration vers HBase.

Seulement les identifiants faisant référence à un pipeline sont utilisés dans le reste des tables.

Même chose pour la table « NGS_variant_type », « chromosome », « NGS_capture_kit » et

« NGS_vcf_info ».

Les tables qui contiennent les échantillons, les variants, les variants des échantillons pour chacun des pipelines utilisés ainsi que les positions sont des tables qui contiennent énormément de données. De ce fait, les tables contenant ces valeurs seront considérées pour la migration vers HBase. Bref, les tables qui seront impliquées dans la migration sont :

« NGS_vcf_variant », « sample », « NGS_vcf_sample », « NGS_vcf_format ».

Les requêtes qui posent problèmes sont celles où l’utilisateur veut faire une analyse de ségrégation, c’est-à-dire qu’il veut comparer les variants qui sont présentes dans une famille (un ou plusieurs individus) et qui ne sont pas présentes dans une cohorte de contrôle (plusieurs individus). Enfin, l’utilisateur veut connaitre les variants qui sont partagées entre les individus d’une famille ou qui se retrouvent dans au moins un individu de la famille et qui ne sont pas présentes dans la cohorte de contrôle. Pour réussir à récupérer ces données dans les tables, plusieurs requêtes doivent être exécutées. Les étapes à réaliser sont les suivantes :

1. Exclure, si nécessaire, des variants appartenant à un ou un ensemble d’individus et stocker le résultat dans une variable. (Cohorte de contrôle)

2. Inclure les variants appartenant à un ou un ensemble d’individus. Durant cette étape, l’utilisateur veut être en mesure d’inclure seulement les variants séquencées à l’aide d’un ou plusieurs pipelines. (Famille 1)

3. Récupérer la liste de variants qui sont présentes dans la famille 1 et qui ne sont pas présentes dans la cohorte de contrôle. Durant cette étape, l’utilisateur doit pouvoir être capable de récupérer les variants d’un ou plusieurs types, par exemple, seulement les variants en mutation.

(22)

15

Des exemples de requêtes permettant de réaliser ces trois étapes sont présentés dans l’annexe 2. Par contre, puisque les requêtes sont celles qui étaient utilisées avant la migration vers la base de données Infobright, le nom de certaines tables a changé et d’autres ont été supprimés.

Enfin, il est tout de même facile de comprendre la logique derrière les requêtes SQL.

(23)

CHAPITRE 5

MIGRATION VERS HBASE

5.1 Schéma

La première étape à franchir pour migrer les tables problématiques vers HBase est la conception du schéma. Pour ce faire, plusieurs éléments devaient être considérés. Puisque les requêtes seront déterminées par les choix de l’utilisateur dans l’interface graphique, les requêtes se doivent d’être performantes et paramétrables. Pour nous assurer d’avoir un schéma qui soit performant pour les requêtes qui sont fréquemment utilisées, nous avons demandé au CRCHUM de nous fournir de l’information supplémentaire sur les habitudes des utilisateurs du système. En nous basant sur cette information, nous en sommes venues à la conclusion que l’utilisation d’une seule table contenant toutes les données serait la meilleure solution. En utilisant une seule table, nous avons l’avantage d’être en mesure de réaliser la logique expliquer dans la section précédente un utilisant une seule requête puisque HBase ne supporte par les jointures. La table contient donc l’ensemble des données provenant des 4 tables devant être migrer vers HBase. Bien sûr, puisqu’il n’y a pas de table permettant de faire de lien entre les données comme dans la base de données relationnelle, certaines données seront décuplées. Nous considérons que l’espace qui sera occupé par des données décuplées reste négligeable et qu’il est préférable d’avoir des données dupliquées que d’avoir plusieurs tables. L’utilisation de plusieurs tables ajouterait beaucoup de complexité aux requêtes qui doivent être exécutées. Il faut noter que ce ne sont pas tous les colonnes de toutes les tables qui ont été incluses dans la table HBase, seulement les colonnes contenant les données qui seront retournées lors des requêtes ont été considérées.

La procédure pour transférer les données vers HBase à partir d’une base de données relationnelle est expliquée dans le rapport de mon partenaire, M. Jean-Francois Hamelin.

Mme Klos a aussi fait un très bon travail pour décrire les procédures et les outils utilisés pour effectuer le transfert de données entre ces deux types de base de données. Il est donc suggéré de consulter l’un de ses rapports pour comprendre la procédure de migration des données.

(24)

17

Structure de la table HBase :

Figure 4 - Table HBase

Puisque HBase ne possède pas de langage comme SQL pour exécuter les requêtes, une commande « get » ou « scan » doit être utilisée. Pour exécuter des requêtes avec des « get », il faut connaitre l’ensemble des clés des rangées que l’on veut récupérer dans la base de données. Puisque la majorité des requêtes qui seront exécutées retourne plusieurs milliers de résultats, nous avons modélisé la clé en considérant que des requêtes « scan » seraient utilisées. D’ailleurs, les requêtes « scan » nous permettront de développer des filtres qui faciliteront le développement des requêtes paramétrables. À cet égard, nous avons décidé d’utiliser une clé composée comprenant les attributs sur lesquels les requêtes seront exécutées. La clé sera construite de la façon suivante :

Le caractère « | » sera utilisé pour délimiter les attributs de la clé. Chaque rangée de la table aura une clé de ce type. En fonction des attributs choisis par l’utilisateur, des

expressions régulières seront utilisées pour filtrer les résultats.

(25)

5.2 Stratégie de requêtes

Comme mentionnés dans la section 4.1, des « scans » seront utilisés pour interroger les données. Ils consistent à balayer un ensemble de rangées d’une table de la base de données.

En fait, on peut voir le « scan » comme un itérateur au niveau des rangées d’une table. À partir de l’application cliente, l’utilisation d’un « scan » permet d’itérer sur les données d’une table en spécifiant l’intervalle sur lequel les données doivent être consultées. Si aucun intervalle n’est précisé, l’ensemble de la table sera balayé lors de la requête. Afin de déterminer les données qui seront retournées lors de l’utilisation d’un « scan », il est possible de spécifier des filtres qui permettront de sélectionner seulement les données qui ont été choisies par l’utilisateur. Il existe un grand nombre de filtres permettant de faciliter la sélection des données, mais puisque nous avons une clé composée, nous utiliserons les filtres à base d’expression régulière pour récupérer l’ensemble des variants répondant à la requête.

Les expressions régulières seront générées à partir des choix faits par l’utilisateur dans l’interface graphique. Puisque la clé est composée, chacune des sections de la clé aura sa propre expression régulière. Par exemple, si l’utilisateur sélectionne les valeurs suivantes :

Type de variant : 000003 Sample id : 013127, 013141 Pipeline id : Tous les pipelines

L’expression régulière générée serait la suivante :

En ajoutant cette expression régulière comme filtre dans notre scanneur, seulement les variants de type 000003 appartenant aux échantillons 013127 et 013141 seraient sélectionnées. Si l’on considère les choix précèdent, l’intervalle du « scan » serait le suivant :

(26)

19

000003 | 013127 | 000000 | 000000000000000 À

000003 | 013142 | 000000 | 000000000000000

Dans cet exemple, les choix de l’utilisateur sont simples et implique le balayage de très peu de données puisque les données sont triées par ordre alphanumérique. Dans le cas où un utilisateur choisirait plusieurs types de variants, le nombre de données qui devraient être balayées augmenterait en fonction de la distance numérique entre les identifiants des types de variants. Par exemple, si l’utilisateur avait choisi le type de variants 000003 et 000010, l’intervalle aurait été le suivant :

000003 | 013127 | 000000 | 000000000000000 À

000010 | 013142 | 000000 | 000000000000000

Il y aurait donc un grand nombre de données balayé pour seulement être en mesure de récupérer les variants de type 000003 et 000010. Puisque le but est de réduire au maximum le nombre de données balayé par un scanneur, il a été décidé d’utiliser plusieurs scanneurs pour répondre à une requête. L’utilisation de plusieurs scanneurs a plusieurs avantages, en plus de réduire considérablement le nombre de données balayé lors d’une requête, la grosseur des expressions régulière permettant de répondre à la requête est de beaucoup réduite puisqu’elle serait distribuée en fonction des intervalles de chacun des scanneurs. Maintenant, pour être en mesure de diviser la requête sur plusieurs scanneurs, des paramètres permettant de définir l’intervalle maximum pouvant être traité par un scanneur ont été définis. Les paramètres permettent de choisir l’intervalle maximum pour chacun des attributs de la clé, ce qui permet d’avoir davantage de flexibilité pour maximiser les performances en fonction des besoins.

(27)

Voici un exemple de paramètres pouvant être choisis par l’utilisateur :

Dans cet exemple, un scanneur ne pourrait itérer sur un intervalle de plus d’un type de variants. De plus, pour chacun des types de variants sélectionnés, le scanneur itérerait sur maximum 50 échantillons. Puisqu’il existe seulement 25 pipelines, tous les pipelines et les variants seraient considérés pour chacun des échantillons balayés.

En considérant les paramètres précédents, si un utilisateur décidait de faire une requête sur les attributs suivants, 4 scanneurs seraient générés par l’application.

• Variant id : 000001, 000004

• Sample id : 000001, 000040, 001140, 001170

• Pipeline : 000001 à 000024

Les 4 scanneurs itéreraient respectivement sur les intervalles suivants :

000001 | 000001 | 000000 | 000000000000000 - 000001 | 000040 | 000024 | ################

000001 | 001140 | 000000 | 000000000000000 - 000001 | 001170 | 000024 | ################

000004 | 000001 | 000000 | 000000000000000 - 000001 | 000040 | 000024 | ################

000004 | 001140 | 000000 | 000000000000000 - 000001 | 001170 | 000024 | ################

Puisque plusieurs scanneurs sont exécutés pour récupérer les données sur HBase, un

« HashMap » (Ensemble de clés-valeurs) est utilisé pour réunir le résultat. Lorsqu’une valeur est retournée par un scanneur, elle est automatique stocker dans le « HashMap » en utilisant l’identifiant du variant. De cette façon, il est certain qu’il n’y aura pas de variants dupliquées dans la réponse finale.

(28)

21

Ce processus fonctionne bien pour réaliser les étapes 2 et 3 de la section 3.1, il permet de sélectionner les variants en fonction du pipeline, des échantillons et des types de variant.

Pour être capable de réaliser l’étape 1, soit l’exclusion de variants, un traitement supplémentaire doit être fait. Pour exclure des variants, des échantillons sont sélectionnés dans la liste d’exclusions, tous les variants se retrouvant dans ces échantillons doivent être exclus de la réponse. Pour ce faire, la liste des variants se retrouvant dans les échantillons sélectionnés doit être connue, une requête doit donc est fait sur la base de données avant d’exécuter les scanneurs. Plusieurs solutions ont été considérées pour cette problématique, une seconde table HBase où chaque rangée contiendrait l’ensemble des identifiants des variants pour un échantillon aurait pu être utilisée. Cette solution nous aurait permis de récupérer les identifiants rapidement à l’aide de « get » sans compromettre l’extensibilité du système. Par manque de temps, nous n’avons pu implémenter cette solution, nous avons donc utilisé la table de la base de données relationnelle permettant de relier les échantillons à leurs variants. Donc, avant d’exécuter la série de scanneurs, une requête permettant de récupérer tous les identifiants de variant devant être exclus est exécuté et les résultats sont stocké dans un « HashMap ». Pour exclure les variants de la réponse finale, une vérification est faite sur le « HashMap » d’exclusion avant d’insérer le variant dans le « HashMap » qui contient le résultat de la requête.

5.3 MapReduce vs API HBase

Au début, il était entendu que MapReduce serait utilisé pour faire les requêtes. Pour plusieurs raisons, il a été difficile d’implémenter notre solution sur MapReduce dans le cadre du projet.

Premièrement, pour effectuer des requêtes avec MapReduce, il aurait fallu utiliser le cluster pour obtenir des performances raisonnables. Par manque de temps, nous n’avons pu migrer l’application serveur permettant de faire des requêtes sur Hbase vers le cluster. Puisque l’application serveur était déployée sur nos ordinateurs personnels, les performances des requêtes étant exécuté sur le réseau par le VPN de l’université étaient très mauvaises. Il va de soi que généralement une application de ce type doit directement être connectée sur le cluster pour avoir de bonne performance. De ce fait, pour réussir à avoir une application

(29)

fonctionnelle, des scanneurs opérants dans un seul « Thread » ont été utilisés. En utilisant MapReduce, il aurait été possible d’exécuter les scanneurs en parallèle dans plusieurs

« Threads », soit plusieurs tâches « Map » s’exécutant sur chacun des nœuds du cluster.

Enfin, pour optimiser le système actuel, il faudrait éventuellement développer des tâches MapReduce permettant d’exécuter les scanneurs en parallèle sur un cluster.

(30)

CHAPITRE 6

PERFORMANCE

6.1 Optimisation des performances sur HBase

Contrairement à une base de données relationnelle, il existe plusieurs façons d’optimiser les performances d’une base de données HBase, son caractère distribué implique une gestion appropriée des requêtes sur les réseaux. Plusieurs paramètres doivent donc être considérés lors du développement d’une application.

L’un des paramètres les plus importants lorsque l’on utilise des scanneurs est celui permettant de contrôler la cache. Par défaut, lorsque l’on itère sur un intervalle de données, chaque fois qu’une rangée répond aux critères des filtres du scanneur, la donnée est retournée à l’application cliente, ce qui implique un transfert sur le réseau. Par conséquent, lorsqu’une requête retourne des milliers de résultats, il y a plusieurs milliers de transferts qui sont initialisés sur le réseau. Dans le but de réduire l’impact sur les performances, il est possible de définir un paramètre de cache, ce paramètre indique au scanneur qu’il doit récupérer un certain nombre de données avant de les transférer sur le réseau. Par exemple, si l’on fixe le paramètre à la valeur 500, le scanneur attendra de récupérer 500 rangées répondant aux critères des filtres avant de les transmettre sur le réseau. Cependant, l’utilisation d’une telle cache n’est pas gratuite, lorsque la valeur fixée est grande, les nœuds du serveur consommeront plus de mémoire lorsqu’ils répondront aux requêtes. Il faut donc trouver la valeur qui permettra de maximiser les performances en fonction de la mémoire disponible.

Pour trouver la valeur maximisant les performances du système, plusieurs valeurs ont été testées à partir d’une requête standard itérant sur des milliers de résultats.

(31)

Voici les résultats obtenus :

Figure 5 - Performance du scanneur

Pour cette requête, la valeur du paramètre ayant le meilleur compromis entre la mémoire utilisé et les performances du système est de 500. C’est donc cette valeur qu’il a été utilisé par défaut.

Ensuite, il est important d’utiliser la compression lorsque l’on stocke beaucoup de données sur HBase. Elle permettra d’augmenter les performances presque à coup, car l’utilisation du CPU pour décompresser les données est moins couteuse que la lecture de données non compressée sur le disque. Il existe plusieurs algorithmes et librairie pour compresser les données sur HBase, l’une des plus populaires est Google Snappy, la librairie utilisée par Google dans leur système Big Table. Elle offre un bon compromis entre le niveau de compression et l’utilisation du CPU pour décompresser les données. Enfin, il y a beaucoup d’autres paramètres à considérer lorsque l’on veut déployer une solution en production, surtout si un grand nombre de machines est utilisé. Une section complète de la documentation de HBase est dédiée à l’optimisation des performances, il est fortement conseillé de la consulter si l’on veut développer une application performante.

(http://hbase.apache.org/book/performance.html)

(32)

25

CHAPITRE 7

DEMONSTRATION

Comme mentionnés dans les sections précédentes, nous avons développé une application pour mettre en pratique les éléments théoriques abordés.

7.1 Application cliente

L’application cliente a été développée à l’aide de la librairie ExtJS, une librairie javascript permettant de développer des RIA (Rich Internet Application). Des services

REST (Representational State Transfer) sont utilisés pour communiquer avec l’application serveur. Voici une capture d’écran illustrant l’interface graphique :

Figure 6 - Démonstration de l'application cliente

(33)

7.2 Application serveur

Du côté de l’application serveur, nous avons utilisé Spring MVC pour exposer les services REST et Hibernate pour gérer la persistance de la base de données relationnelle.

L’application utilise le JDK 7 et est déployée sur le serveur applicatif Tomcat 7.2.

L’application fonctionne actuellement avec les environnements Hadoop 1.03 et HBase 0.92.1 en mode pseudo distribué. Comme mentionnés dans la section précédente, des tests ont été faits en utilisant la couche de persistance du cluster, par contre, puisque l’application n’est pas déployée sur une machine directement connectée au cluster, les performances laissent à désirer. La prochaine étape serait donc de déployer l’application sur une machine du cluster pour être en mesure de transférer les requêtes vers MapReduce.

(34)

CHAPITRE 8

DÉVELOPPEMENT SUR HADOOP ET HBASE

8.1 Environnement de développement

Dans cette section, la description d’un environnement de développement permettant de développer une application cliente pour Hadoop et HBase sera présentée. Il ne s’agît pas nécessairement des tous les outils utilisés pour développer la démonstration, mais bien des éléments nécessaires pour développer une application et faire des tests. Tout d’abord, voici la liste des outils que nous avons utilisés pour construire l’environnement de travail :

 Eclipse

 Ant

 Maven

Structure du projet Eclipse :

Figure 7 - Structure du projet Eclipse

Pour s’assurer d’avoir les bonnes librairies et pour éviter d’avoir des conflits entre les dépendances des distributions de Hadoop et Hbase, l’outil de gestion de dépendances Maven est utilisé. Pour faciliter son utilisation, il est préférable d’installer le « plug-in » m2e pour

(35)

Eclipse. Le fichier « pom.xml » (Project Object Model) que nous avons utilisé pour construire le projet est défini dans l’annexe 3.

Pour éviter d’avoir à gérer les instances de Hadoop et HBase lorsque l’application doit être testée, des scripts Ant ont été développés. Pour que les scripts soient fonctionnels dans son environnement de travail, le fichier « hadoop-project.properties » doit être modifié avec les valeurs correspondant à l’installation de Hadoop et Hbase sur le poste de travail. Par exemple, pour mon poste de travail, la configuration était la suivante :

Le fichier « build.xml » est défini dans l’annexe 4. Les tâches suivantes peuvent être exécutées à partir du fichier :

start-hadoop : Démare tous les processus de Hadoop stop-hadoop : Stop tous les processus de Hadoop start-hbase : Démare tous les processus de HBase stop-hadoop : Stop tous les processus de HBase

start-all : Démare tous les processus de Hadoop et HBase stop-hadoop : Stop tous les processus de Hadoop et HBase

Pour éviter d’ajouter les paramètres de connexion à HBase directement dans le code, il est possible d’ajouter un fichier « hbase-site.xml » dans le « classpath » du projet.

L’emplacement par défaut selon l’API de HBase est le dossier « conf » à la racine du

« classpath ». Si un fichier de configuration est placé dans le dossier « conf », il sera automatique récupérer lorsque le développeur utilisera la ligne de code suivante :

Configuration config = HBaseConfiguration.create();

#Hadoop directory

hadoop.dir=/usr/local/hadoop

#Hbase directory

hbase.dir=/usr/local/hbase

#Hadoop default name

hadoop.default.name=hdfs://localhost:54310

(36)

CONCLUSION

Le phénomène du « Big Data » ne fait que commencer, nous risquons, au cours des prochaines années d’assister à l’émergence d’un grand nombre de technologies. Ces technologies sont en grande partie peu connues par l’ensemble des développeurs, mais seront monnaie courante et seront enseignées dans les Universités, et ce, dans un futur proche. En réalisant ce projet, nous avons pris conscience de l’avancement technologique dans ce domaine et des possibilités qu’il risque d’amener au domaine des technologies de l’information. Même si les technologies ne sont pas tout à fait matures, elles le sont de plus en plus et elle évolue rapidement. Pour réussir à développer un projet, il ne faut pas avoir peur d’essayer de nouvelles choses tout en essayant de comprendre les concepts malgré le manque de documentation.

Pour conclure, nous pouvons affirmer que le projet est une réussite dans son ensemble, tous les objectifs ont été atteints et nous avons eu beaucoup de plaisir à y travailler. Il reste tout de même beaucoup de chose sur lesquelles il faut travailler pour avoir un système « S2D » utilisant HBase en production. Enfin, ce projet aura tout de même permis d’élaborer une preuve de concept démontrant qu’il est bel et bien possible de développer ce type de système avec HBase.

(37)

RECOMMANDATIONS

Tout d’abord, il faudrait utiliser la stratégie de Scan développée par notre équipe dans un contexte MapReduce optimisé. Plus précisément, il faudrait utiliser une « job » Map par objet Scan créé par l’application et lancer le tout en parallèle dans un environnement distribué plus grand que trois noeuds. Le Reducer serait utilisé pour effectuer les exclusions de variants en fonction des échantillons.

Ensuite, il faudrait revoir le schéma de données du laboratoire Guy Rouleau dans son ensemble. Nous avons uniquement eu un ensemble de données limité et qui date de l’an dernier sur lequel travailler. Selon ce que M. Ousmane Diallo nous a mentionné lors de notre visite au laboratoire, le schéma SQL du CRCHUM a changé depuis. Il faudrait ensuite réviser entièrement le schéma HBase sur réception du schéma SQL complet du laboratoire Rouleau. L’objectif de cette opération serait de valider que le schéma HBase développé convienne réellement aux besoins du laboratoire et est intègre par rapport au schéma actuellement utilisé. Il faudrait, si nécessaire, revoir le schéma HBase et le modifier pour qu’il reflète les derniers changements du CRCHUM.

Il serait aussi souhaitable de revoir la composition de la clé de rangée selon l’occurrence des paramètres de recherche. En effet, la composition de la clé est très importante, puisqu’elle définit l’ordonnancement effectué par HBase. Cependant, avec le peu d’information que nous disposons sur les requêtes effectuées par les employés du laboratoire Guy Rouleau, nous sommes loin d’être certains que la composition actuelle de la clé concatène de manière optimale les paramètres de recherche.

Par ailleurs, il serait intéressant de montrer le travail accompli au laboratoire du CRCHUM afin de récolter une rétroaction de leur part. De cette façon, il serait possible de connaitre leur opinion sur les fonctionnalités de l’application ainsi que sur les requêtes effectuées et les résultats présentés. Avec la rétroaction du client, il serait possible de produire de nouveaux

(38)

31

requis, qu’ils soient logiciels ou non, et d’itérer dessus afin d’améliorer continuellement le prototype et peut-être le voir un jour remplacer le système S2D actuel.

Afin de comparer les produits disponibles sur le marché, il serait pertinent d’installer et de tester les performances d’autres systèmes de base de données distribuées. Par exemple, il serait possible de reproduire le même genre de solution, mais avec HyperTable ou Cassandra.

Ensuite, il faudrait analyser les performances de ces systèmes, les comparer à HBase et les classer selon la complexité de mise en place. Puisque ce projet a aussi pour but de fournir un travail pratique à un futur cours de l’ÉTS, la solution ne doit pas être excessivement

complexe à mettre en place.

Enfin, il n’y a de limites que celles que l’on s’impose lorsqu’il est question d’amélioration logicielle. Les possibilités d’amélioration d’un tel système sont infinies.

(39)

BIBLIOGRAPHIE

Wikipédia. (2012, août 1). Hadoop. Consulté le juin 15, 2012, sur Wikipédia:

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

Wikipédia. (2012, mars 29). MapReduce. Consulté le juin 15, 2012, sur Wikipédia:

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

G. Noll, M. (2012, juillet 12). Running Hadoop on ubuntu linux (multi node cluster). Consulté le juin 12, 2012, sur michael-noll.com :

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

Wikipédia. (2012, juillet 20). Big Data. Consulté le juillet 10, 2012, sur Wikipédia:

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

Google, (2012). Google Snappy. Consulté le juillet 30, 2012 sur Google : http://code.google.com/p/snappy/

Apache Software Foundation. (2012, 01 août). Apache HBase Reference Guide . Consulté le juin 30, 2012, sur Apache : http://hbase.apache.org/book.html

George, L. (2011). HBase: The Definitive Guide. Sebastopol: O'Reilly Media.

White, T. (2012). Hadoop: The Definitive Guide. Sebastopol: O'Reilly Media.

Klos, A. (2012). Optimisation de recherche grâce à HBase sous Hadoop. Montréal: École de technologie supérieure.

(40)

ANNEXE I

ÉTAPES À SUIVRE POUR EFFECTUER L’INSTALLATION EN MODE DISTRIBUÉ

Toutes les étapes de l’installation et les exemples fournis sont expliqués en fonction du cluster que nous avions à notre disposition. Il faut noter que pour un cluster contenant plus de machines, l’installation pourrait varier à certains endroits.

La première étape est d’ajouter le nom des machines et leur adresse IP dans le fichier

« hosts » de Linux. Alors, sur chacune des machines, il faut éditer le fichier et ajouter les valeurs pour chacune des autres machines du cluster. Alors, pour le master, le fichier devrait avoir les valeurs suivantes :

Pour faciliter la gestion des utilisateurs qui utiliseront Hadoop et Hbase, il est préférable de créer un groupe et d’utiliser un utilisateur de ce groupe pour l’installation.

OpenSSH doit être installé sur toutes les machines du cluster, il est utilisé par le master afin de communiquer avec les machines slaves pour démarrer les processus lorsque Hadoop est lancé sur la machine master. Donc, pour éviter d’avoir à inscrire le mot de passe pour accéder les machines en SSH, nous avons besoin de générer une clé RSA et de nous connecter en SSH sur chacune des machines avec l’utilisateur que l’on désire utiliser pour travailler avec Hadoop.

sudo vi /etc/hosts 127.0.0.1 localhost

###.###.###.### master

###.###.###.### slave1

###.###.###.### slave2

sudo addgroup hgroup

sudo adduser --ingroup hgroup huser

(41)

Création de la clé :

Sur chacune des machines, il faut autoriser en local en utilisant la commande suivante :

Pour tester la connexion SSH, il faut tout simplement utiliser :

Puisque le master devra communiquer avec les autres machines, il faut exécuter les commandes suivantes sur le master seulement

Installation de Hadoop

Cette étape doit être réalisée sur toutes les machines du cluster. Pour installer Hadoop, il suffit d’exécuter les commandes suivantes. Il faut noter que l’emplacement de l’installation peut varier, nous avons décidé d’utiliser l’emplacement /user/local.

Lorsque Hadoop est installé sur toutes les machines, il faut s’assurer qu’ils utilisent la bonne version de Java. Hadoop requiert au minimum la version 1.6. Pour exporter la bonne version de Java, il faut éditer le fichier hadoop-env.sh sur chacune des machines et pointer le répertoire ou Java est installé sur la machine.

ssh-keygen –t rsa –P ""

Appuyer sur entrée lorsque l’on demande l’emplacement de la clé

Cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Ssh localhost

Inscrire « yes » lorsque l’on demande si vous voulez continuer

Ssh slave1

Inscrire « yes » lorsque l’on demande si vous voulez continuer Ssh slave2

Inscrire « yes » lorsque l’on demande si vous voulez continuer

cd /usr/local

wget %url pour telecharger Hadoop 1.0.3%

sudo tar xvfz hadoop-1.0.3.tar.gz sudo mv hadoop-1.0.3 hadoop

sudo chown –R huser:hgroup hadoop

(42)

35

Configuration du master :

Pour que le master puisse reconnaitre les machines esclaves, le fichier slave doit être édité :

Il faut ensuite éditer le fichier master pour que la machine se reconnaisse en tant que master :

Configuration sur toutes les machines :

Création du répertoire pour stocker les fichiers temporaires de Hadoop et HDFS. Le répertoire par défaut stock les fichiers dans /tmp, il est préférable de configurer un autre répertoire si l’on ne veut pas perdre de fichier lorsque l’on redémarre le système.

Les fichiers suivants doivent être édités sur toutes les machines : vi /usr/local/hadoop/conf/hadoop-env.sh

# The java implementation to use. Java 1.6 required.

export JAVA_HOME=/usr/local/java-6-sun

vi /usr/local/hadoop/conf/slaves slave1

slave2

sudo vi /usr/local/hadoop/conf/master master

sudo mkdir /usr/local/hadoop-data

sudo chown huser:hgroup /usr/local/hadoop-data

(43)

Il faut noter que par défaut, le « path » défini par la propriété « hadoop.tmp.dir » sera utilisé sur le système d’exploitation et sur HDFS. Sur HDFS, le « path » sera {hadoop.tmp.dir}/dfs/name.

Avant d’utiliser Hadoop, il est nécessaire de formater HDFS : vi /usr/local/hadoop/conf/core-site.xml

<name>hadoop.tmp.dir</name>

<value>/usr/local/hadoop-data</value>

<description>Répertoire de base temporaire pour Hadoop et HDFS</description>

</property>

<name>fs.default.name</name>

<value>hdfs://master:8020</value>

<description>Le nom du système de fichier par défault</description>

</property>

vi /usr/local/hadoop/conf/mapred-site.xml

<name>mapred.job.tracker</name>

<value>master:8021</value>

<description>L’hote et le port du MapReduce JobTracker</description>

</property>

vi /usr/local/hadoop/conf/hdfs-site.xml

<name>dfs.replication</name>

<description>Le nombre de replication d’un block par default.

Seulement utilisé. Si la valeur n’est pas spécifié lors de la création d’un fichier.</description>

</property>

/usr/local/hadoop bin/hadoop namenode -format

… INFO dfs.Storage: Storage directory /usr/local/hadoop-data/dfs/name has been successfully formatted.

(44)

37

Test de l’installation

Le démarrage du cluster se fait en 2 étapes, il faut d’abord démarrer HDFS (namenode et datanode) et ensuite MapReduce (tasktracker et jobtracker). Pour vérifier si l’installation fonctionne bien, il préférable de vérifier les logs après le démarrage d’un processus. Dans Hadoop, les logs se retrouvent par défaut dans le répertoire $HADOOP_HOME/logs. Les logs sont générés de la façon suivante :

Par exemple, le log du namenode sur la machine master serait :

Démarrer HDFS :

Démarrer MapReduce:

Si vous avez installé « openjdk » sur votre système, vous pouvez utiliser la commande « jps » pour vérifier le statut des processus Java en cours. C’est un bon indicateur lors du démarrage de Hadoop et HBase. Voici un exemple sur le cluster lors du démarrage de Hadoop :

$HADOOP_HOME/logs hadoop-%utilisateur%-%process%-%hostname%.log

$HADOOP_HOME/logs/hadoop-huser-namenode-master.log

sh /usr/local/hadoop/bin/start-dfs.sh

sh /usr/local/hadoop/bin/start-mapred.sh

(45)

Installation de HBase

Lorsque l’installation de Hadoop est terminée et qu’il fonctionne correctement, nous pouvons commencer l’installation de HBase. En premier lieu, il faut télécharger la distribution de HBase sur toutes les machines, nous utiliserons la version 0.92.1 pour cet exemple.

cd /usr/local

wget %url pour telecharger HBase 0.92.1%

sudo tar xvfz hbase-0.92.1.tar.gz sudo mv hbase-0.92.1 hbase

sudo chown –R huser:hgroup hbase

(46)

39

Lorsque vous avec télécharger HBase, vous devez éditer le fichier suivant sur toutes les machines :

vi /usr/local/hbase/conf/hbase-site.xml

<name>hbase.zookeeper.quorum</name>

<value>master</value>

</property>

<name>dfs.replication</name>

</property>

<name>hbase.zookeeper.property.clientPort</name>

<description>Property from ZooKeeper's config zoo.cfg.

<name>hbase.rootdir</name>

<value>hdfs://master:8020/hbase</value>

</property>

<name>hbase.master</name>

<value>master:60000</value>

<description>The host and port that the HBase master runs at.</description>

</property>

<name>hbase.regionserver.port</name>

<description>The port the HBase RegionServer binds to</description>

</property>

<name>hbase.master.port</name>

<description>The host and port that the HBase master runs at.</description>

</property>

<name>hbase.cluster.distributed</name>

</property>

<name>hbase.tmp.dir</name>

<value>/home/huser/Hadoop/hbase/temp</value>

</property>

(47)

The port at which the clients will connect.

</description>

</property>

<name>hbase.zookeeper.property.dataDir</name>

<value>/home/huser/zookeeper</value>

<description>Property from ZooKeeper's config zoo.cfg.

The directory where the snapshot is stored.

</description>

</property>

Lorsque tous les fichiers ont été édités, il suffit de lancer la commande suivante pour démarrer HBase. Hadoop doit préalablement avoir été démarré lorsque la commande est exécutée.

sh /usr/local/hbase/bin/start-hbase.sh

(48)

ANNEXE II

REQUÊTES SQL DU SYSTÈME DU CRCHUM

Étape 1 :

La requête suivante permet de récupère l’identifiant des variants à exclure et stocke le résultat dans la variable « excludeVariantsResults »

Étape 2 :

La requête suivante permet de sélectionner les identifiants des variants à inclure dans l’ensemble final :

Si l’utilisateur veut inclure seulement les variants séquencé à l’aide d’un ou plusieurs pipelines, la requête suivante doit être utilisée pour l’inclusion :

Durant cette étape, tous les variants retournés qui étaient présent dans la variable

« excludeVariantsResults » doivent être exclus de l’ensemble final qui sera stocké dans la variable « resultSet ».

SELECT SQL_BIG_RESULT DISTINCT variant_id FROM NGS_sample_variant

WHERE sample_id in ( sample_ids_to exclude ) ORDER BY variant_id

Results => @excludeVariantsResults;

SELECT DISTINCT sv.variant_id FROM NGS_sample_variant sv

WHERE sv.sample_id in ( sample_ids_to_include ) GROUP BY sv.variant_id

ORDER BY sv.variant_id

SELECT DISTINCT ngc.variant_id FROM NGS_coverage ngc

WHERE ngc.sample_id in ( sample_ids_to_include ) AND screening_pipeline_id in ( selected_pipeline ) GROUP BY ngc.variant_id

ORDER BY ngc.variant_id

(49)

Étape 3 :

La requête suivante permet de récupérer tous les variants correspondants aux identifiants de la variable « resultSet » qui sont en mutation (variant_type_id = 4).

SELECT SQL_BIG_RESULT v.id, v.variant_class, v.strand, v.variant_genotype,

v.dbSNP_rs, v.variant_type_id as s2d_type, v.gene, v.freq_1000g, v.Sift_score, qvp.chromosome_name as chromosome, qvp.hg18_position as

hg18_chrom_position, qvp.hg19_position as hg19_chrom_position

FROM NGS_variant v, NGS_queryVariantPosition qvp

WHERE v.position_id = qvp.position_id AND v.id in (@resultSet ) AND v.variant_type_id = 4

GROUP BY v.id

(50)

ANNEXE III

GESTION DES DÉPENDANCES AVEC MAVEN

Fichier Pom.xml utilisé pour la gestion des dépendances entre HBase 0.92.1 et Hadoop 1.0.3 pour une application client permettant d’exécuter des « jobs » MapReduce et des requêtes sur HBase.

<project xmlns="http://maven.apache.org/POM/4.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

<artifactId>hadoop-project-maven</artifactId>

<version>0.0.1-SNAPSHOT</version>

<name>hadoop-project-maven</name>

<url>http://maven.apache.org</url>

<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

</properties>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

</dependency>

<groupId>org.apache.hadoop</groupId>

<artifactId>hadoop-core</artifactId>

</dependency>

<groupId>org.apache.ftpserver</groupId>

<artifactId>ftplet-api</artifactId>

</dependency>