Ce document décrit les architectures de référence permettant d'utiliser l'API Cloud Life Sciences avec d'autres produits Google Cloud pour effectuer le traitement des données génomiques à l'aide de différents moteurs et méthodes de workflow. Ce document porte sur les étapes d'alignement et d'appel de variantes de l'analyse secondaire. Il s'adresse aux bio-informaticiens, chercheurs, équipes informatiques et autres spécialistes techniques des entreprises du secteur des sciences de la vie.
Google Cloud propose un ensemble flexible d'API, de services et d'outils permettant d'exécuter une solution d'analyse secondaire économique à grande échelle. L'analyse secondaire inclut, sans s'y limiter, le filtrage des lectures brutes, l'alignement et l'assemblage des lectures de séquences, ainsi que les appels de contrôle qualité et de variantes sur les lectures alignées.
Architecture
Le schéma suivant illustre les étapes de traitement des données génomiques à grande échelle et indique celles qui sont effectuées dans Google Cloud.
Comme le montre le schéma précédent, un échantillon de données génomiques est d'abord soumis à une analyse primaire, puis ingéré sous forme de données brutes dans Google Cloud pour une analyse secondaire. Les données traitées subissent ensuite une analyse tertiaire et produisent des rapports, tels que des fichiers PDF, qui peuvent être téléchargés à partir du cloud par des bio-informaticiens et d'autres spécialistes techniques.
Composants de l'architecture de référence du traitement des données génomiques
Ce document comprend des informations sur l'utilisation de l'API Cloud Life Sciences, ainsi que les présentations de deux architectures de référence qui décrivent différentes manières d'utiliser l'API pour effectuer le traitement des données génomiques.
Utiliser l'API Cloud Life Sciences
L'API Cloud Life Sciences fournit un service de calcul entièrement géré qui offre des ressources de calcul optimales en fonction des besoins en ressources d'une tâche par lot. L'API vous permet de créer, d'exécuter et de surveiller des outils de ligne de commande sur des instances Compute Engine exécutées dans un conteneur Docker.
Vous pouvez organiser plusieurs outils de ligne de commande que vous souhaitez exécuter dans un ordre spécifique avec des dépendances entre les étapes. L'API Cloud Life Sciences inclut le service WorkflowsServiceV2Beta que vous pouvez utiliser pour exécuter des workflows, tels que des pipelines constitués de conteneurs Docker.
Un objet Pipeline comprend une ou plusieurs descriptions Action et un message Resources décrivant les ressources cloud qui sont nécessaires pour exécuter le pipeline.
Chaque action décrit une seule exécution du conteneur Docker, qui peut inclure un ou plusieurs objets command.
Les objets Action s'exécutent de manière séquentielle, chacun devant attendre, pour entrer en jeu, que son prédécesseur ait cessé de s'exécuter, à moins que celui-ci soit configuré pour s'exécuter en arrière-plan. Vous pouvez utiliser des options qui modifient la façon dont chaque objet Action s'exécute et dont l'état de sortie affecte les actions dans le pipeline. Par exemple, si un objet Action doit s'exécuter en arrière-plan ou si l'état de sortie doit être ignoré.
En tant qu'auteur d'un pipeline, vous créez un message Resources décrivant les ressources cloud requises pour l'exécuter.
Les spécifications du message Resources peuvent inclure les éléments suivants :
- Tailles de machines virtuelles (VM), y compris les configurations et la qualité de préemption des machines personnalisées
- Zones et régions pour l'allocation de VM
- Options de mise en réseau (importantes pour les projets de traitement volumineux, en raison des limites de taille du réseau)
- Accélérateurs associés (GPU)
- Disques associés
- Comptes de service et champ d'application
L'API Cloud Life Sciences effectue les tâches suivantes lorsqu'elle reçoit un objet Pipeline via un appel d'API :
- Elle crée une instance de VM Compute Engine en fonction du contenu du message
Resources. - Elle télécharge toutes les images Docker spécifiées dans une description
Action. - Elle exécute chaque objet
Actionen tant que nouveau conteneur Docker avec l'image et la commande spécifiées. - Elle supprime l'instance de VM Compute Engine.
Un ensemble type de tâches spécifié dans une description Action peut inclure les éléments suivants :
- Télécharger des fichiers d'entrée
- Exécuter des commandes
- Copier des journaux dans Cloud Storage
- Importer des fichiers de sortie
L'API Cloud Life Sciences utilise la puissance de traitement et le stockage évolutifs et hautes performances de Google Cloud, ainsi que les instances de VM préemptives, les GPU et les TPU (Tensor Processing Units), afin de fournir un environnement sécurisé et évolutif pour l'analyse des données. Cela inclut l'exécution de frameworks d'analyse secondaire standards dans l'industrie, tels que Genome Analysis Toolkit (GATK) et DeepVariant, sur un seul échantillon ou sur des ensembles de données communs, rapidement, facilement et à moindre coût.
L'API Cloud Life Sciences est intégrée aux moteurs de workflow Open Source, tels que Cromwell, Nextflow et Galaxy. En outre, Nextflow et Galaxy sont compatibles avec le service de calcul sur Google Cloud via des intégrations directes avec Compute Engine et Cloud Storage. Le schéma suivant illustre une architecture de référence incluant des composants de l'API Cloud Life Sciences, ainsi que d'autres services requis pour exécuter un pipeline d'analyse secondaire génomique dans Google Cloud.
Traitement des données génomiques : utiliser Cromwell pour exécuter les workflows de bonnes pratiques GATK
Vous pouvez utiliser l'API Cloud Life Sciences avec un moteur de workflow pour orchestrer des tâches. Dans l'exemple suivant, Cromwell est utilisé pour effectuer une analyse secondaire tout en appliquant les workflows de bonnes pratiques GATK.
Cromwell est un système de gestion de workflows Open Source qui peut être exécuté dans divers environnements pour planifier, exécuter et gérer des workflows. Cromwell lit un workflow défini dans le langage de description de workflow (WDL, Workflow Description Language) et exécute des tâches individuelles à partir de ce workflow à l'aide de l'API Cloud Life Sciences. Dans ce cas, un serveur Cromwell s'exécute sur une instance de VM Compute Engine, avec un serveur Cloud SQL pour le stockage des données opérationnelles. La VM Cromwell exécute ensuite chacune des tâches définies en effectuant des appels d'API vers l'API Cloud Life Sciences afin de démarrer les instances de VM pour chacune des tâches selon la configuration dans le langage WDL.
GATK inclut des outils pour la découverte de variantes et le génotypage. Les workflows de bonnes pratiques GATK incluent de nombreux pipelines pour des cas d'utilisation spécifiques. Cet exemple concerne le workflow de production, PairedEndSingleSampleWf. Le workflow inclut le prétraitement des données, l'appel de variantes initial pour les polymorphismes de nucléotide unique (SNP, Single Nucleotide Polymorphism) de la lignée germinale et la découverte indel dans un seul échantillon de données de séquençage du génome entier.
Le workflow utilise des données de séquençage du génome humain entier en paire ("paired-end") dans le format non mappé BAM (uBAM) avec un ou plusieurs groupes de lecture, ainsi que le génome de référence Hg38 avec des contigs ALT. Les résultats incluent un fichier cram, un index cram, un fichier cram md5, un fichier GVCF ainsi qu'un index correspondant, un rapport BQSR et plusieurs métriques récapitulatives. L'échantillon utilisé est une version sous-échantillonnée de NA12878 qui ne contient que trois groupes de lecture de l'échantillon complet.
Le workflow est empaqueté sous la forme d'une série de fichiers WDL qui définissent les tâches individuelles, avec une spécification d'entrée et des options génériques. Le fichier WDL spécifie les ressources cloud de chaque tâche, comme le nombre de cœurs de processeur et la mémoire pour chaque instance de VM, le conteneur à installer sur chaque instance de VM et la commande à exécuter, ainsi que les emplacements des fichiers d'entrée et de sortie. Il existe également d'autres spécifications, par exemple si une étape doit s'exécuter sur des machines préemptives et le nombre de tentatives d'un objet Action.
Le schéma suivant illustre une architecture classique d'analyse secondaire génomique à l'aide de Cromwell pour exécuter les workflows de bonnes pratiques GATK avec l'API Cloud Life Sciences, y compris la procédure d'analyse.
Le schéma présente les étapes à suivre pour exécuter une analyse secondaire :
- Après le séquençage, vous enregistrez les appels de base bruts dans un espace de stockage local ou en réseau (NAS), où ils sont convertis en fichiers uBAM. Vous transférez ensuite ces fichiers uBAM vers un bucket Cloud Storage.
- Vous vous authentifiez pour agir en tant que compte de service à l'aide de la gestion de l'authentification et des accès (IAM).
Vous envoyez la tâche au serveur Cromwell qui s'exécute sur Compute Engine.
La requête passe par Identity-Aware Proxy, qui est configuré pour autoriser l'accès au cloud privé virtuel à l'aide de règles de pare-feu Google Cloud.
Le serveur Cromwell extrait le workflow de GATK à partir de dépôts publics.
Le serveur Cromwell appelle l'API Cloud Life Sciences pour démarrer des tâches.
L'API Cloud Life Sciences récupère les conteneurs pour chaque tâche à partir des dépôts publics GATK.
L'API Cloud Life Sciences démarre les VM sur Compute Engine pour chaque tâche et le conteneur sur chaque machine.
L'instance de VM récupère les fichiers d'entrée des buckets Cloud Storage.
L'instance de VM effectue des tâches de calcul et enregistre les fichiers intermédiaires, les fichiers journaux et les fichiers de sortie dans un bucket Cloud Storage.
Traitement des données génomiques : exécuter DeepVariant
DeepVariant est un pipeline d'analyse Open Source qui exploite un réseau de neurones profond pour appeler des variantes génétiques à partir de données sur le séquençage de l'ADN nouvelle génération. Ce pipeline d'analyse, qui a été développé par une équipe de recherche de Google, utilise TensorFlow pour les appels de variantes SNP et indel sur des exomes ou des génomes. DeepVariant est utilisé pour transformer les lectures de séquençage alignées en appels de variantes.
Pour utiliser DeepVariant, vous devez fournir trois entrées au niveau le plus élevé :
- Un génome de référence au format FASTA et son fichier d'index
.faicorrespondant, générés à l'aide de la commande Samtoolsfaidx. - Un fichier de lectures alignées au format BAM et son fichier d'index correspondant (
.bai). Les lectures doivent être alignées sur le génome de référence fourni. - Le modèle de ML DeepVariant à utiliser pour les appels de variantes.
Le résultat de DeepVariant est une liste de tous les appels de variantes au format VCF. DeepVariant est intégré au framework de machine learning TensorFlow.
Vous pouvez exécuter DeepVariant dans un conteneur Docker ou dans les fichiers binaires directs, et à l'aide du matériel sur site ou dans le cloud. DeepVariant inclut la compatibilité avec les accélérateurs matériels tels que les GPU et les TPU. Vous pouvez utiliser Docker pour exécuter DeepVariant à partir d'un conteneur Docker à l'aide d'une seule commande, comme décrit dans le guide de démarrage rapide DeepVariant. Pour les cas d'utilisation en production sur Google Cloud, nous vous recommandons d'intégrer le processus DeepVariant dans votre workflow et d'effectuer l'appel depuis votre moteur de workflow.
Vous pouvez également utiliser DeepVariant Runner qui exploite l'API Cloud Life Sciences d'une manière similaire aux méthodes décrites dans le tutoriel Exécuter DeepVariant. Cette méthode vous permet d'exécuter DeepVariant à grande échelle à l'aide d'un pipeline basé sur Docker optimisé en termes de coût et de vitesse.
Le schéma suivant montre une architecture classique pour l'exécution d'un pipeline DeepVariant sur Google Cloud.
Voici les étapes à suivre pour exécuter DeepVariant, comme illustré dans le schéma précédent :
- Après avoir créé des lectures d'ADN mappées à partir d'échantillons, vous transférez ces fichiers BAM vers un bucket Cloud Storage.
- Vous vous authentifiez pour agir en tant que compte de service à l'aide d'IAM.
- Vous exécutez DeepVariant qui appelle l'API Cloud Life Sciences pour démarrer des tâches.
- L'API Cloud Life Sciences extrait le conteneur DeepVariant pour chaque tâche à partir des dépôts publics.
- L'API Cloud Life Sciences démarre les VM sur Compute Engine pour chaque tâche et le conteneur sur chaque machine.
- L'instance de VM récupère les fichiers d'entrée des buckets Cloud Storage.
- L'instance de VM effectue des tâches de calcul et enregistre les fichiers intermédiaires, les fichiers journaux et les fichiers de sortie dans un bucket Cloud Storage.
Gouvernance des données
L'architecture décrite dans ce document est consacrée aux composants spécifiques à l'analyse des données génomiques. Pour une intégration en production incluant des données génomiques humaines, vous devrez peut-être configurer des composants supplémentaires dans Google Cloud en fonction des exigences et des bonnes pratiques de votre juridiction.
Google Cloud offre une architecture de bout en bout qui regroupe les bonnes pratiques Google Cloud afin de répondre aux besoins de sécurité, de confidentialité et de conformité dans le domaine de la santé. Le toolkit de protection des données Cloud Healthcare comprend une grande partie des contrôles de sécurité et de confidentialité recommandés pour les données de santé, tels que la configuration de l'accès approprié, la gestion des journaux d'audit et la surveillance des activités suspectes. Pour en savoir plus sur ces fonctionnalités et sur la manière dont Google Cloud protège les données des clients, consultez le livre blanc Stocker des données en toute confiance avec Google Cloud.
Résidence des données
Pour les organisations ayant des exigences en termes de résidence des données, consultez la section traitant des services généraux du document Conditions spécifiques au service pour consulter l'engagement de Google Cloud quant à la résidence des données. Ce document met en évidence les outils et les contrôles disponibles pour configurer les environnements des utilisateurs afin de répondre à ces exigences.
Règles d'administration
Pour limiter l'emplacement physique d'une ressource dans un projet, vous pouvez définir une règle d'administration qui inclut une contrainte d'emplacement de ressource. Pour obtenir la liste des services compatibles, consultez la page Services compatibles avec les emplacements de ressources.
Identifiants de ressources Google Cloud
Pour les besoins du présent document, les engagements en termes de résidence des données ne s'appliquent pas aux identifiants de ressources, ni aux attributs, ni aux autres libellés de données. Vous devez vous assurer qu'aucune donnée sensible n'est exposée dans ces identifiants, attributs ou autres libellés de données, par exemple dans un nom de fichier.
Zones et régions de l'API Cloud Life Sciences
Lorsque vous effectuez des appels vers l'API Cloud Life Sciences, vous devez spécifier la région dans laquelle la requête sera envoyée. L'exemple suivant illustre un URI de point de terminaison pour l'exécution d'un pipeline dans le projet Google Cloud foo et dans la région us-central1 :
v2beta/projects/foo/locations/us-central1/workflows:runPipeline
Toutes les métadonnées enregistrées pour l'opération, y compris les noms d'image de conteneur, les noms de fichier d'entrée et de sortie et les autres informations envoyées dans la requête adressée à l'API Cloud Life Sciences, sont enregistrées.
Lorsque l'API Cloud Life Sciences démarre une instance de VM Compute Engine, l'appel d'API doit inclure une région ou une zone dans laquelle démarrer l'instance de VM. Vous pouvez configurer une ou plusieurs régions ou zones pour restreindre l'emplacement de la VM. L'instance de VM, les données au repos dans Compute Engine et les disques persistants restent dans la région spécifiée. Les fonctionnalités disponibles pour les instances Compute Engine, telles que les plates-formes de processeur, les types de machines, les disques SSD et les GPU, diffèrent selon la région et la zone. Par conséquent, assurez-vous que les ressources requises sont disponibles dans une région ou une zone avant de limiter l'utilisation à cette région ou cette zone.
Pour plus d'informations, consultez les détails et les conditions de résidence des données Compute Engine.
Google Cloud Storage
Vous pouvez stocker des fichiers d'entrée et de sortie, des fichiers professionnels temporaires et des instantanés de disque persistant dans Cloud Storage. Les données au repos dans les buckets Cloud Storage restent dans la région, la zone birégionale ou multirégionale que vous sélectionnez lors de la configuration du bucket. Pour en savoir plus, consultez la liste actuelle des emplacements des buckets Cloud Storage.
Pour optimiser la disponibilité, les performances et l'efficacité, vous pouvez utiliser une zone birégionale Cloud Storage. Lorsque vous sélectionnez cette option, les données du bucket sont copiées de manière asynchrone dans deux régions spécifiques, ce qui rend les données redondantes entre les régions. Pour plus d'informations, consultez la page Zones birégionales Cloud Storage.
Pour optimiser les performances et la résidence des données, utilisez la même région pour Cloud Storage, Compute Engine et l'API Life Sciences, si possible.
Pour en savoir plus, consultez les détails et les conditions de résidence des données Cloud Storage.
Étape suivante
- Consultez la documentation Cloud Life Sciences.
- Essayez les tutoriels Cloud Life Sciences.
- Consultez la présentation de Cloud Storage.
- Apprenez-en davantage sur IAM.
- Continuez le traitement de vos données génomiques à l'aide des outils Variant Transforms.
- Utilisez BigQuery pour analyser vos données génomiques et vos variantes.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.