ADAM comme moteur de recherche

ADAM COMME MOTEUR DE RECHERCHE 

Conversion vers ADAM

La performance des bases de données relationnelles est inadéquate pour ce projet de recherche, car elles comportent des limitations importantes pour être utilisables dans le contexte de mégadonnées. De plus, il a été mentionné, lors de l’introduction, que les formats et les activités d’analyse de données en génétique et bio-informatique requièrent un niveau de performance qui dépasse leurs capacités. Conséquemment, quelle serait la pile technologique la plus adaptée pour répondre à ces besoins ? De plus, quelles technologies Big Data sont éprouvées dans ce domaine ?

Au laboratoire de recherche AmpLab, de l’université de Berkeley, les chercheurs ont mis au point un format moderne et efficace pour le traitement de données génétique. Ce nouveau format de données génétiques est appelé ADAM (Massie M, 2013 Dec 15). Ce format inclut une librairie comprenant les étapes de traitement pour le séquençage de données génomiques. Ce nouveau format est disponible librement et livré sous une licence Apache 2. Il requiert l’utilisation de deux technologies modernes du domaine du Big Data.

Premièrement, il utilise la technologie Apache Avro qui est un cadriciel d’appels de procédures distantes et de sérialisation de données utilisant le format JSON pour la définition des types de données et des protocoles, et sérialise les données dans un format binaire plus compact et adapté aux mégas données. (D. Cutting, 2011) Deuxièmement, il utilise aussi le format Apache Parquet (D. Vohra, 2016) qui est un format interopérable très efficace pour le stockage de données à l’aide des technologies de bases de données NoSQL (c.-à-d. base de données en colonnes popularisées par le mouvement Big Data) incontournables pour le traitement efficace de mégadonnées.

Le pipeline de ADAM a été testé avec la technologie Spark (Zaharia M, 2016), qui est un cadriciel de traitement distribué. L’utilisation conjointe de ces trois technologies comporte les avantages suivants :
• Avro procure un schéma explicite pour l’accès aux données, et l’extraction peut se faire en C, C++, C#, Java, Scala et Python ;
• Parquet permet l’accès comme à une base de données ;
• Spark améliore la performance par rapport aux technologies antérieures telle que HADOOP en utilisant une cache, et en réduisant les entrées et sorties sur le disque.

La performance de ce pipeline génétique, pour le traitement et l’extraction de données, a démontré qu’il était 100 fois plus rapide que les pipelines conventionnels. Pour les raisons susmentionnées, nous avons donc décidé d’expérimenter avec le format et la technologie émergente d’ADAM pour la conversion du génome de référence HG38 de 1000Genome (1000 Genomes Project Consortium, 2010) en format Parquet.

Les fichiers du génome de référence ont un format VCF (Variant Calling Format), et ADAM utilise un schéma différent pour décrire des séquences génomiques, des génotypes et autres paramètres avec ce type de fichier. Une fois les données traitées avec le format d’ADAM, elles sont sauvegardées avec l’aide du cadriciel Apache Parquet qui utilise un format par colonne.

Nous savons que les données patientes utilisées par les chercheurs contiennent des mutations, ou des données déviant de la norme. Il est donc important d’utiliser un génome de référence humain disponible à des fins de comparaison. Pour la première preuve de concept de ce projet de recherche, le génome de référence HG38 de 1000Genome sera converti au format ADAM afin de tester la performance d’extraction de données génomiques. Ce sera le premier objectif du projet de recherche GNOMEViewer. L’objectif initial est que le visualisateur GNOMEViewer puisse être utilisé avec n’importe quel pipeline de séquençage utilisant ADAM. Ainsi il sera possible de visualiser les données et les résultats qui pourront être téléchargés et sauvegardés dans le dossier des patients, dont les génomes sont en cours d’analyse.

Utilisation d’EMR sur AWS 

Pour exécuter la visualisation de données génétiques à grande échelle, il est nécessaire de sélectionner une infrastructure matérielle facilement extensible. La technologie Elastic Map Reduce (EMR) est disponible sur la plateforme offerte par AWS (Amazon Web Services) (Cloud, 2011) qui fournit une infrastructure Hadoop permettant le traitement de grandes quantités de données sur des instances EC2 (Elastic Compute Cloud) et ce dynamiquement (c.- à-d. vous avez la possibilité d’agrandir ou réduire la puissance à votre guise). Cette plateforme est flexible et, il est aussi possible d’utiliser d’autres cadriciels courants tels qu’Apache Spark, HBase (HBase A., 2016), Presto (GUIDE, 2015) et Flink (Carbone P, 2015) et d’interagir avec d’autres instances d’AWS telles que Amazon S3 ou Amazon DynamoDB pour faciliter la gestion de cette infrastructure matérielle sur demande.

Dans le cadre de cette recherche, puisque ADAM a été testé par Berkeley avec la technologie Spark et non Hadoop et que la conversion du génome de référence va engendrer des fichiers Parquet, nous avons choisi d’expérimenter avec la technologie AWS EMR avec des instances S3 pour le stockage des fichiers Parquet.

Lorsqu’EMR est offert avec Spark préinstallé, la technologie YARN (Vavilapalli VK) est préinstallée sur les instances AWS à titre de gestionnaire de la grappe de calculs qui rassemble les ressources dans un seul conteneur. Ce dernier est simplement un ensemble de ressources (dans notre cas l’ensemble des instances EC2) qui sont assemblées et colocalisées pour un traitement efficace. De plus, une fonctionnalité intéressante de YARN, sur EMR, est que l’allocation dynamique de ressources est offerte par défaut. Donc, il n’y a pas de nécessité de sélectionner le nombre d’exécuteurs (c.-à-d. d’instances) sur un nœud, car YARN met à l’échelle automatiquement le nombre d’exécuteurs sur les grappes de calculs EC2 qui sont disponibles.

Afin d’effectuer la conversion des fichiers de format VCF vers le génome de référence, et ce d’une manière efficace, nous avons expérimenté avec la fonction « adam2vcf » qui prend un fichier VCF en entrée et produit un dossier pour l’écriture du fichier Parquet en sortie. La commande utilisée pour exécuter cette conversion est : adam-submit vcf2adam fichier_vcf dossier_sortie_hadoop

Les fichiers, au format VCF, qui contiennent les données du génome de référence HG38 ont été téléchargés à l’aide d’un format compressé et ont été sauvegardés sur une instance AWS de type S3 au préalable ont été effectuées :
1)Copier le fichier VCF compressé dans le dossier Hadoop d’EMR ;
2)Décompresser ce dernier ;
3)Mettre le fichier compressé en Hadoop, car il s’agit d’un prérequis d’ADAM, que tout fichier donné en entrée avec une fonction ADAM doit être en Hadoop ;
4)Convertir les fichiers en parquet avec la commande de conversion « adam2vcf » ;
5)Sauvegarder dans les instances S3 afin de pouvoir les réutiliser par la suite puisque les instances EMR ne conservent pas de fichiers.

Table des matières

INTRODUCTION
CHAPITRE 1 REVUE LITTÉRAIRE
1.1 Le besoin de visualisation
1.2 Taille des données générées en génétique et oncogénétiques
1.3 Outils et bases de données publiques disponibles
1.4 Problématique
1.5 Conclusion
CHAPITRE 2 CRÉATION DE L’INTERFACE POUR VISUALISATION DU PROFIL GÉNÉTIQUE DE PATIENTS
2.1 Prérequis pour la création du module de visualisation de profil génétique
2.2 Réutilisation d’architecture et des données d’un projet précédent
2.3 Conclusion
CHAPITRE 3 ADAM COMME MOTEUR DE RECHERCHE
3.1 Conversion vers ADAM
3.2 Utilisation d’EMR sur AWS
3.3 Compte rendu de la conversion
3.3.1 Observations liées à la taille des fichiers VCF une fois décompressé
3.3.2 Observations liées à la conversion des fichiers VCF vers ADAM
3.4 Création du module « matching » dans ADAM
3.5 Connexion de l’interface avec Spark pour la recherche de mutations dans ADAM
et mesure de la performance
3.6 Conclusion
CHAPITRE 4 INTERPRÉTATION DES RÉSULTATS ET DIRECTION FUTURE
4.1 Résultats obtenus par rapport aux objectifs fixés
4.2 Directions futures
4.3 Utilisation de ADAM
4.4 Itérations futures pour la complétion du projet et aperçu de l’architecture finale
4.5 Conclusion
CONCLUSION

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *