UNIVERSIDADE ESTADUAL DE CAMPINAS FACULDADE DE CIÊNCIAS MÉDICAS
WÉLLITON DE SOUZA
DESENVOLVIMENTO DE SISTEMAS ESCALÁVEIS PARA PESQUISA GENÔMICA EM AMBIENTES DE COMPUTAÇÃO DE ALTO DESEMPENHO
CAMPINAS 2020
WÉLLITON DE SOUZA
DESENVOLVIMENTO DE SISTEMAS ESCALÁVEIS PARA PESQUISA GENÔMICA EM AMBIENTES DE COMPUTAÇÃO DE ALTO DESEMPENHO
Tese apresentada à Faculdade de Ciências Médicas da
Universidade Estadual de Campinas como parte dos requisitos exigidos para a obtenção do título de Doutor em Ciências.
ORIENTADORA: PROFA. DRA. ÍSCIA TERESINHA LOPES CENDES
ESTE TRABALHO CORRESPONDE À VERSÃO FINAL DA TESE DEFENDIDA PELO ALUNO WÉLLITON DE SOUZA E ORIENTADA
PELA PROFA. DRA. ÍSCIA TERESINHA LOPES CENDES.
CAMPINAS 2020
Biblioteca da Faculdade de Ciências Médicas Maristella Soares dos Santos - CRB 8/8402
Souza, Wélliton de,
So89d SouDesenvolvimento de sistemas escaláveis para pesquisa genômica em ambientes de computação de alto desempenho / Wélliton de Souza. – Campinas, SP : [s.n.], 2020.
SouOrientador: Íscia Teresinha Lopes Cendes.
SouTese (doutorado) – Universidade Estadual de Campinas, Faculdade de Ciências Médicas.
Sou1. Biologia computacional. 2. Metodologias computacionais. 3.
Sequenciamento de nucleotídeos em larga escala. 4. Reprodutibilidade dos testes. I. Lopes-Cendes, Íscia Teresinha, 1964-. II. Universidade Estadual de Campinas. Faculdade de Ciências Médicas. III. Título.
Informações para Biblioteca Digital
Título em outro idioma: Development of scalable systems for genomic research at high-performance computing environments
Palavras-chave em inglês: Computational biology Computing methodologies
High-throughput nucleotide sequencing Reproducibility of results
Área de concentração: Fisiopatologia Médica Titulação: Doutor em Ciências
Banca examinadora:
Íscia Teresinha Lopes Cendes [Orientador] André Schwambach Vieira
Diego Fernando Troggian Veiga Monica Barbosa de Melo
Wilson Araújo da Silva Júnior Data de defesa: 26-10-2020
Programa de Pós-Graduação: Fisiopatologia Médica
Identificação e informações acadêmicas do(a) aluno(a)
- ORCID do autor: https://orcid.org/0000-0001-8377-1836 - Currículo Lattes do autor: http://lattes.cnpq.br/1630790974761077
COMISSÃO EXAMINADORA DA DEFESA DE DOUTORADO
WÉLLITON DE SOUZA
ORIENTADOR: PROFA. DRA. ÍSCIA TERESINHA LOPES CENDES
MEMBROS TITULARES:
1. PROFA. DRA. ÍSCIA TERESINHA LOPES CENDES
2. PROF. DR. ANDRÉ SCHWAMBACH VIEIRA
3. DR. DIOGO FERNANDO TROGGIAN VEIGA
4. PROFA. DRA. MONICA BARBOSA DE MELO
5. DR. WILSON ARAÚJO DA SILVA JÚNIOR
Programa de Pós-Graduação em Fisiopatologia Médica da Faculdade de Ciências Médicas da Universidade Estadual de Campinas.
A ata de defesa com as respectivas assinaturas dos membros encontra-se no SIGA/Sistema de Fluxo de Dissertação/Tese e na Secretaria do Programa da FCM.
DEDICATÓRIA
À Profa. Dra. Iscia Lopes-Cendes, que me orientou desde o Mestrado e me confiou a realização deste trabalho e de muitos outros que contribuíram para minha formação. Eu também agradeço a Profa. Iscia pela paciência e sensibilidade às mudanças e desafios que nos deparamos ao longo deste projeto.
Ao Prof. Dr. Benilton Carvalho, que enriqueceu este trabalho ao me confiar a execução de atividades desafiadoras e de alto impacto. Muito do que eu produzi neste projeto teve as sugestões do Prof. Benilton. Também o agradeço pela sua inestimável amizade, tão importante ao longo desta jornada.
Aos meus colegas de laboratório, Cristiane Rocha, Estela Bruxel, Maíra Rodrigues, Murilo Borges, Rodrigo Secolin e Tânia de Araujo, por terem proporcionado um ambiente de trabalho tranquilo, inspirador e de alta produtividade. Agradeço também aos visitantes e estagiários do laboratório, em especial a Elizabeth Borgognoni, por terem colaborado conosco e compartilhado suas visões e valores sobre a pesquisa. Agradecimento especial ao Lucas Cendes, que durante seu estágio colaborou como os primeiros resultados que levaram a elaboração e desenvolvimento deste projeto.
Aos colaboradores com os quais eu trabalhei diretamente e contribuíram para o desenvolvimento deste trabalho, Amanda Canto, Amanda Donatti, Danielle Bruno, Fabiana Oliveira, Jaqueline Geraldis, Lucas Carvalho, Mariana Martin e Miriam Nunes. Agradecimento especial à Profa. Dra. Claudia Maurer Morelli por todos esses anos de colaboração e amizade.
Às instituições que possibilitaram o desenvolvimento deste trabalho, Faculdade de Ciências Médicas, Universidade Estadual de Campinas, e Instituto Brasileiro de Neurociência e Neurotecnologia. Aos funcionários Elio Segundo, Patrícia Araújo, Regina de Paula e Sônia Silva.
À Fundação de Amparo à Pesquisa do Estado de São Paulo (processo: 2016/04204-8 - FAPESP) pelo apoio financeiro durante todo o desenvolvimento desse doutorado.
momentos. Aos meus familiares e amigos, em especial ao Guilherme Gasparini, pelas incontáveis horas de conversa e companheirismo.
A todas as pessoas que participaram, contribuindo para realização deste trabalho, direta ou indiretamente, meu agradecimento.
Tecnologias de sequenciamento de alto rendimento e a demanda crescente por análise de conjuntos de dados genômicos em larga escala criaram desafios computacionais e de reprodutibilidade. Grandes volumes de dados exigem sistemas otimizados para execução em ambientes de alto desempenho e eficientes, ao mesmo tempo em que os projetos de pesquisa expandem e novos recursos computacionais são adquiridos. Nesse contexto os protocolos de processamento tornaram-se mais complexos conforme técnicas de sequenciamento foram desenvolvidas para outras áreas além da genômica, como transcriptômica e epigenômica. Esses protocolos são compostos de dezenas de tarefas que devem ser executadas em um fluxo de trabalho que pode ter ramificações e uso de técnicas de paralelismo dificultando a publicação de pesquisas completamente reprodutíveis, requisito cada vez mais presente na literatura. Durante a execução deste trabalho, protocolos de processamento reprodutíveis foram descritos em Workflow Description Language e executados utilizando o sistema gerenciador de protocolos Cromwell. O sistema RNNR foi desenvolvido para gerenciamento de recursos computacionais, distribuição e execução de tarefas de processamento em computadores em rede. Outras ferramentas como Espresso-Caller e MethSeq foram desenvolvidas para automatizar a execução de protocolos complexos. As ferramentas computacionais desenvolvidas, quando combinadas a outros sistemas e padrões desenvolvidos pela comunidade, criaram um ecossistema para análises reprodutíveis de dados de sequenciamento de larga escala e suportado em diferentes ambientes computacionais. RNNR diminuiu o tempo total de análises de grandes volumes de dados de sequenciamento. As ferramentas de automação simplificaram a execução de análises com centenas de amostras. O ecossistema foi utilizado para analisar milhares de amostras de sequenciamento e possibilitou a execução de estudos em genômica, transcriptômica e epigenômica.
Palavras-chave: Biologia Computacional, Metodologias Computacionais,
Sequenciamento de Nucleotídeos em Larga Escala, Reprodutibilidade dos Testes.
High-throughput sequencing technologies and the growing demand for large-scale analysis of genomic data sets have created computational and reproducibility challenges. Large volumes of data require systems optimized for execution in high performance and efficient environments, while research projects expand, and new computational resources are acquired. In this context, processing protocols have become more complex as sequencing techniques have been developed for areas other than genomics, such as transcriptomics and epigenomics. These protocols are composed of dozens of tasks that must be performed in a workflow that may have ramifications and use of parallel techniques, making it difficult to publish completely reproducible research, a requirement that is increasingly present in the literature. Throughout the execution of this work, reproducible pipelines were described in Workflow Description Language and executed using the Cromwell management system. The RNNR system was developed to manage computational resources and distribute and execute processing tasks across networked computers. Other tools such as Espresso-Caller and MethSeq were developed to automate the execution of complex workflows. The computational tools built, when combined with other systems and standards developed by the community, created an ecosystem for analyzing large-scale sequencing data in reproducible and supported in different computing environments. RNNR decreased the total analysis time of large volumes of sequencing data. Automation tools have simplified the execution of analyzes with hundreds of samples. The ecosystem was used to analyze thousands of sequencing samples and empowered studies in genomics, transcriptomics and epigenomics.
Keywords: Computational Biology, Computing Methodologies,
NGS Next-generation sequencing, sequenciamento de nova geração DNA Deoxyribonucleic acid, ácido desoxirribonucleico
RNA Ribonucleic acid, ácido ribonucleico
WES Whole-exome sequencing, sequenciamento completo do exoma WGS Whole-genome sequencing, sequenciamento complete do
genoma
SNP Single-nucleotide polymorphism, polimorfismo de nucleotídeo único
CNV Copy number variation, variação de número de cópia cDNA Complementary DNA, DNA complementar
RNA-seq RNA sequencing, sequenciamento de RNA
WGBS Whole-genome bisulfite sequencing, sequenciamento completo do genoma convertido por bissulfito
DMR Differentially methylated region, região diferencialmente metilada BIPMed Brazilian Initiative on Precision Medicine
DSL Domain-specific language, linguagem de domínio específico DAG Directed acyclic graph, grafo acíclico dirigido
CWL Common Workflow Language WDL Workflow Description Language JSON JavaScript Object Notation YAML YAML Ain't Markup Language WOM Workflow Object Model
SGE Sun Grid Engine
API Application programming interface, interface de programação de aplicativo
TES Task Execution Service
GA4GH Global Alliance for Genomics and Health
HPC High-performance computing, computação de alto desempenho CPU Central processing unit, unidade central de processamento
TB Terabyte
SAM Sequence Alignment/Map
BAM Binary SAM
uBAM Unmapped BAM VCF Variant Call Format gVCF Genomic VCF CRAM Compressed SAM
HTTP Hypertext Transfer Protocol
RPC Remote procedure call, chamada de procedimento remoto SRA Sequence Read Archive
INTRODUÇÃO ...13
Sequenciamento de alto rendimento ...13
Pesquisa reprodutível ...15
Isolamento de processos ...16
Protocolos de processamento ...18
Computação de alto desempenho ...22
OBJETIVOS ...25
Objetivo Principal ...25
Objetivos Específicos...25
MATERIAL E MÉTODOS ...26
Conjuntos de dados de sequenciamento ...26
Ambientes computacionais ...27
Protocolos de processamento ...27
Programas de automação ...32
Sistema de distribuição e execução de tarefas ...35
Avaliação de desempenho e reprodutibilidade ...38
RESULTADOS ...40
Protocolos de processamento ...40
Programas de automação ...40
Sistema de distribuição e execução de tarefas ...42
Ecossistema ...44 DISCUSSÃO ...46 Eficiência e reprodutibilidade ...46 Limitações identificadas ...47 Computação em nuvem ...48 CONCLUSÃO ...50 REFERÊNCIAS ...51 ANEXOS ...58
INTRODUÇÃO
Sequenciamento de alto rendimento
Tecnologias de sequenciamento de nova geração (NGS) tornaram-se populares em estudos genéticos devido a sua capacidade de gerar grandes volumes de dados a um baixo custo (1). Os métodos de NGS envolvem quebrar longas moléculas de DNA ou RNA em fragmentos menores que são lidos simultaneamente por equipamentos de alto rendimento produzindo mais de um bilhão de fragmentos de leitura (reads) em uma única execução. As leituras são compostas das chamadas de bases e pontuações de qualidade associadas a confiabilidade dos ciclos de sequenciamento (2). As taxas de erros de NGS são 0,1% a 15% maiores que plataformas de sequenciamento Sanger, que são consideradas a primeira geração (3).
Tecnologias de NGS têm diferentes aplicações biológicas, ou seja, podem ser utilizadas em diferentes ômicas como por exemplo genômica, transcriptômica e epigenômica. Dentre as técnicas, alguns exemplos são o sequenciamento completo do exoma (WES) (4,5) e do genoma (WGS) (6), que podem ser utilizados para identificação de variantes genômicas como SNPs, indels e CNVs; sequenciamento de transcritos convertidos em cDNA (RNA-seq) (7), utilizados para quantificar sequências de RNA mensageiro, identificar splicing alternativos e genes de fusão; sequenciamento de pequenos transcritos (Small RNA-seq) (8), para predizer e quantificar micro-RNAs, isomiRs e outras moléculas pequenas de RNA; e sequenciamento completo do genoma após tratamento químico para identificação de metilação de DNA (WGBS) (9), para encontrar regiões diferencialmente metiladas (DMR).
A evolução das técnicas de NGS criaram novos desafios computacionais devido ao alto rendimento (10,11). O volume de dados é ainda maior em estudos que exigem sequenciamento profundo, ou seja, quando o mesmo genoma deve ser lido centenas de vezes para maior confiabilidade (12). Esse volume cresce significativamente em estudos com grande número de indivíduos como ocorre em estudos de populações (13), iniciativas de medicina de precisão como o BIPMed (14), e análises integrativas de diferentes ômicas (15,16). Dentre algumas áreas de Big Data, como astronomia, redes
sociais e hospedagem de vídeos, a genômica tem gerado grandes volumes de dados globalmente, ultrapassando 1 zettabyte por ano (zettabyte equivale a 1021 bytes) (17). A Figura 1 apresenta a estimativa de crescimento de dados de sequenciamento a partir dos registros históricos até 2015, indicando um crescimento expressivo na demanda de processamento e análise.
Figura 1 - Crescimento do volume de dados de sequenciamento gerado ao longo dos anos e a estimativa para o futuro. Número cumulativos de genomas humanos (eixo da esquerda) e capacidade anual de sequenciamento no mundo todo (eixo da direita). Linha preta é o crescimento registrado; linha vermelha é a taxa de crescimento prevista com base nos anos anteriores (dobra a cada 7 meses); linha amarela é a estimativa de crescimento pela empresa Illumina (dobra a cada 12 meses); linha azul é a Lei de Moore que é a capacidade computacional estimada (dobra a cada 18 meses). Retirado de (17).
A demanda de análise de dados de sequenciamento em larga escala tem levado a novos desafios computacionais para armazenamento, processamento e compartilhamento desses dados. Além disso, princípios de localidade, acessibilidade, interoperabilidade e reutilização dos dados de
pesquisa têm se tornado requerimentos para publicação de estudos genômicos (18).
Pesquisa reprodutível
Reprodutibilidade é a capacidade de recalcular os resultados a partir de um conjunto de dados, os protocolos de entrada e os programas utilizados (19). Do ponto de vista da computação, existem três principais componentes para um estudo reprodutível: a) os dados brutos de um experimento estarem disponíveis (como arquivos FASTQ de sequenciamento genômico, e arquivos CEL de microarranjos), b) códigos fontes e documentação para reproduzir a análise estarem disponíveis, c) análise de dados realizada corretamente (20). A pesquisa reprodutível favorece a confiabilidade de um estudo, colabora com o crescimento do grupo de bioinformática e estreita a comunicação entre o analista de dados com os outros pesquisadores. A Figura 2 apresenta o espectro de reprodutibilidade.
Figura 2 – Espectro de reprodutibilidade. Tornar disponível dados brutos, programas utilizados e códigos fontes da análise leva ao padrão ouro de reprodutibilidade na ciência da computação. Adaptado de (20).
Análises de dados de sequenciamento são compostas por inúmeros algoritmos implementados como programas de linha de comando ou bibliotecas de programação por exemplo. Para obter códigos portáveis, ou seja, que podem ser executados em outros ambientes computacionais, é necessário métodos que empacotam os programas e todas as suas dependências permitindo assim o isolamento dos processos.
Isolamento de processos
Ferramentas científicas costumam ser difíceis de instalar e configurar apropriadamente. Esses programas podem depender de outros programas, bibliotecas de códigos e componentes específicos do sistema operacional para funcionarem. Ao longo do ciclo de vida de desenvolvimento, um programa de bioinformática pode receber atualizações periódicas para corrigir problemas ou adicionar novas funcionalidades. Isso pode levar a resultados discordantes quando a versão utilizada do programa não é corretamente documentada (21).
Tecnologias de virtualização, como máquinas virtuais e conteinerização, têm sido utilizadas em análise de dados para aumentar a reprodutibilidade (22). Docker é uma tecnologia de virtualização para isolar o ambiente de execução, programas, arquivos e rede do sistema operacional anfitrião (23). Docker utiliza sistema de arquivos em camadas para empacotar os programas e suas dependências. Essas imagens de aplicativos ocupam pouco espaço porque não armazenam arquivos relacionados ao sistema operacional e utilizam técnicas de copiar ao escrever (copy-on-write) mantendo apenas as diferenças entre as camadas e versões. Uma imagem pode ter diferentes versões que dependem da mesma imagem base, dessa forma é possível associar versões de imagens com versões do programa de bioinformática. Imagens de aplicativos são hospedadas em registros públicos como DockerHub. Ao tentar executar um programa. o Docker verifica se a imagem já está instalada, caso contrário o sistema procura nos registros e copia para computador quando encontrada (24). O projeto BioContainers desenvolve e distribui imagens de aplicativos de bioinformática (25). São mais de duas mil imagens disponíveis para utilização imediata sem a necessidade de instalar ou configurar as aplicações.
Container é a imagem (e suas camadas) instanciada ao executar um programa pelo Docker. A imagem original mais a camada de ambiente de execução e arquivo gerados também é uma imagem que pode ser copiada mantendo o estado daquele container. A cada execução um novo contêiner é criado, ou seja, uma nova imagem composta da imagem original mais o estado da aplicação. Essa nova imagem pode ser reutilizada ou inspecionada para
copiar arquivos gerados ou visualizar mensagens de erros que podem ter sido acometidos durante a execução do programa. Como o container é uma instância efêmera, é recomendado montar a sistemas de arquivos do sistema anfitrião durante a execução do programa para que os arquivos importantes sejam gravados fora do container. A Figura 3 apresenta o comparativo entre um programa rodando no sistema operacional e programas rodando a partir do Docker.
Figura 3 - Diferenças entre programas instalados no sistema operacional e imagens de aplicativos Docker. O contêiner é uma cópia da imagem de aplicativo original (e suas camadas) mais uma camada com dados do ambiente de execução e arquivos gerados, ou seja, o estado da aplicação. Adaptado de (24).
A utilização do Docker em processamento de dados genômicos adiciona tempo insignificante, comparado à execução sem containers, em protocolos de longa duração (26). Dessa forma, Docker tornou-se uma ferramenta computacional importante para pesquisa reprodutível (27).
Protocolos de processamento
O processamento e análise de dados genômicos constitui de etapas individuais onde cada etapa tem seus próprios parâmetros, arquivos de entradas e arquivos de resultados. Quanto maior e mais complexo são os protocolos de análise, mais difícil é a tarefa de desenvolver protocolos eficientes, robustos e reprodutíveis em diferentes ambientes computacionais (28).
Protocolos de processamento (workflows, pipelines) são linguagens de domínio-específico (DSL) para definição de workflows, tarefas, dependências, ramificações, iterações e resultados esperados. DSLs para bioinformática podem depender de uma plataforma específica, por exemplo, Snakemake depende do interpretador Python para funcionar (29). O motor do Snakemake, o qual interpreta arquivos fontes (Snakefiles), baseia-se em regras que são compostas de arquivos de entrada, saída e comandos. A dependência entre arquivos de entrada das regras implica no workflow, que é representado por um grafo acíclico dirigido (DAG). Esse grafo permite ao motor definir a ordem das tarefas, verificar os arquivos de saída e a executar tarefas independentes ao mesmo tempo (paralelismo). O programa que funciona como motor da linguagem também é o gerenciador de workflows, recursos computacionais, submissão das tarefas como trabalhos (jobs) para sistemas de fila, e recuperação de falhas.
Conforme tecnologias de sequenciamento de alto rendimento tornaram-se mais acessíveis e os conjuntos de dados genômicos ficaram maiores contento amostras de centenas de indivíduos, programas que utilizam DAG tornaram-se limitados ao uso de memória para gerar e armazenar o grafo antes iniciar a execução das tarefas. A popularização de ambientes computacionais sob demanda limitou a reprodutibilidade de protocolos de processamento escritos em DSLs dependentes de plataforma. Dessa forma, novas linguagens foram desenvolvidas. Common Workflow Language (CWL) baseia-se na linguagem de descrição YAML para definição de protocolos de processamento independente de plataforma (30). O sistema gerenciador de workflows, como Toil (31), é responsável por interpretar o arquivo fonte e executar as tarefas em um ambiente computacional suportado. Isso permite
que protocolo pode ser executado por outro gerenciador que suporta outros ambientes computacionais.
Workflow Description Language (WDL) possui todas as funcionalidades de CWL e acrescenta uma biblioteca padrão de funções. Essas funções facilitam o desenvolvimento de protocolos mais complexos que precisam manipular arquivos para tomar decisões ao longo do processamento. Por exemplo, contar o número de amostras descritas em um arquivo texto para avaliar qual método computacional deve ser utilizado. WDL suporta o método de paralelismo scatter-gather de forma nativa. Tanto CWL quanto WDL suportam isolamento de processos através de tecnologias de container, fica a critério do gerenciador de workflows utilizar os requisitos de tempo de execução (runtime).
A linguagem Nextflow segue o paradigma de programação de fluxo de dados (dataflow programming model) (32). A linguagem permite incorporar códigos em R, Python e Bash de forma nativa. As dependências para execução do código podem ser definidas usando tecnologias de containers como Bioconda (33), Docker e Singularity (34). A DSL é uma extensão da linguagem Groovy. Groovy roda na Java Virtual Machine (JVM), o que significa que é possível escrever trechos de códigos que utilizam bibliotecas Java ou utilizar códigos em Groovy nativamente. Além disso Nextflow não é uma linguagem independente de plataforma como CWL e WDL, mas mantém a independência de ambiente computacional e funciona em plataformas que suportam a JVM.
As DSLs separam a definição do protocolo dos parâmetros de entrada, escritos em JSON ou YAML, permitindo que o mesmo protocolo possa ser reutilizado para analisar outros conjuntos de dados. A independência de plataforma e separação entre definição e parâmetros de entrada levaram CWL, WDL e Nextflow tonaram-se as linguagens mais utilizadas em estudos genômicos reprodutíveis e para compartilhamento de protocolos reutilizáveis. A Figura 4 apresenta a visão geral dos componentes para utilização de protocolos de processamento nessas linguagens.
Figura 4 – Estratégia de processamento de dados genômicos utilizando protocolos reprodutíveis. Workflow e tarefas de processamento são definidos numa linguagem específica. O workflow é composto de tarefas que podem estar definidas no mesmo arquivo ou em arquivos separados. Cada tarefa depende de uma imagem de aplicativo que possui os programas necessários para realizar a etapa de processamento. Os parâmetros de entrada são descritos em um arquivo separado que aponta a localização dos arquivos de entrada. O sistema gerenciador lê os arquivos de workflow, importado os arquivos que descrevem as tarefas, e os parâmetros de entrada. A partir desses arquivos, o executor consegue criar containers a partir das imagens de aplicativos e executar os programas de bioinformática com os arquivos de entrada. O sistema pode se recuperar de falhas utilizando arquivos temporário e gera os arquivos de saída como resultados conforme definidos no workflow. A execução é bem-sucedida quando todos os arquivos de saída esperado foram gerados. A utilização de imagens de aplicativo é dependente do ambiente computacional.
WDL é a linguagem utilizada na implementação dos protocolos de melhores práticas do GATK4 desenvolvidos pelo Broad Institute (35). Essa DSL foi desenvolvida em conjunto com o sistema gerenciador de workflows Cromwell. O sistema também suporta CWL. Cromwell não utiliza DAG para
executar as tarefas, ao invés disso, as tarefas são executadas sequencialmente. As duas linguagens possuem declarações de tarefas independentes e Cromwell utiliza essas declarações para executar as tarefas em paralelo. Cromwell converte ambas as linguagens para um formato intermediário chamado Workflow Object Model (WOM). Durante esse processo erros de sintaxe são identificados cancelando a execução do protocolo. Dessa forma um erro de digitação não irá comprometer um processamento demorado.
Cromwell suporta diferentes ambientes computacionais, como local, cluster e computação em nuvem através de backends configuráveis. Ambiente local significa um único computador que pode ser utilizado em conjunto com Docker para isolamento de processos. Cluster depende de um sistema de filas, como Sun Grid Engine (SGE) e PBS Pro, os quais não suportam nativamente tecnologias de container, sendo necessário instalar todos os programas necessários em todos os nós computacionais antes de submeter protocolos ao Cromwell. Essa limitação dificulta a utilização de protocolos mais complexos que podem utilizar diferentes versões de um mesmo programa e diminui a reprodutibilidade da pesquisa. Computação em nuvem exige que todas as tarefas definam uma imagem de aplicativo, além de outros parâmetros de runtime como número de CPUs, memória e disco, porque as máquinas virtuais são instanciadas no momento da execução da tarefa. A Figura 5 apresenta um diagrama com exemplos de backends suportados pelo Cromwell.
Figura 5 – Cromwell funciona um ou mais backends de acordo com a configuração. Retirado de (36).
Cromwell, assim como outros sistemas gerenciadores de workflows, não suportam todos os ambientes computacionais existentes. Dessa forma, foi criado uma interface de programação de aplicativos (API) chamada Task Execution Service (TES) para permitir que esses sistemas deleguem a execução de tarefas submetendo-as a serviços que implementam esse protocolo de comunicação (37). A API TES é mantida pela Global Alliance for Genomics and Health (GA4GH). Cromwell e Nextflow possuem backends para submeter tarefas de processamento através da GA4GH API TES.
Os recursos computacionais necessários para analisar conjuntos de dados de NGS ultrapassam a capacidade de computadores pessoais. Mesmo estações de trabalhos e servidores podem ser ineficientes para processar grandes volumes de dados em tempo hábil. Além disso, o uso compartilhado dos dados por diferentes usuários e a demanda crescente de espaço de armazenamento podem inviabilizar projetos de grandes proporções. Dessa forma, é necessário buscar técnicas de computação de alto desempenho (HPC) para otimizar a utilização de ambientes científicos com grandes poderes de processamento.
Computação de alto desempenho
Estudos em genômicas podem aumentar a demanda de processamento ao longo do tempo de vida do projeto. Por exemplo, o Projeto 1000 Genomas que teve como plano inicial sequenciar e analisar 1092 amostras de 14 populações (38), mas que no final dados de 2504 indivíduos de 26 populações foram analisados e disponibilizados (39). Dessa forma é necessário que as soluções computacionais sejam escaláveis, ou seja, que sejam capazes processar um volume crescente de dados ao passo de aumentar também os recursos computacionais disponíveis, sem perder a eficiência (40).
A computação em nuvem é um modelo para permitir acesso onipresente, conveniente e de rede sob demanda a um conjunto compartilhado de recursos de computação configuráveis que podem ser rapidamente provisionados e liberados com o mínimo esforço de gerenciamento ou interação do provedor de serviços (41).
Programas de bioinformática implementam técnicas de programação concorrente para otimizar a execução dividindo os dados de entrada em pedaços menores e independentes para serem processados em paralelo em computadores com múltiplas unidades de processamento (CPUs). Essa solução tem sido utilizada para reduzir o tempo de processamento ao custo de maior utilização de memória. Entretanto, quando se trata de estudos com várias amostras de sequenciamento, é necessário buscar técnicas de processamento distribuído. Scatter-gather é uma técnica suportada por linguagens de definição de protocolos que consiste em definir um conjunto de arquivos como independentes para que as mesmas tarefas sejam executadas paralelamente sobre os arquivos, no final os dados de resultados podem ser reunidos num único arquivo. Esse método pode ser utilizado para dividir uma única amostra de sequenciamento por regiões genômicas independentes (cromossomo, janelas de tamanho fixo), processar os pedaços paralelamente e depois reunir os resultados. Trabalhos do nosso grupo mostraram que a utilização de técnica de scatter-gather para otimizar o processamento de dados de WES reduziu o tempo de processamento de uma amostra de 25 horas para 5 horas em um ambiente de HPC (42). A Figura 6 apresenta o esquema da técnica.
Figura 6 - Técnica scatter-gather para otimizar processamento de dados. Arquivos de entrada podem ser amostras inteiras ou divididas em regiões genômicas. Após o processamento os resultados intermediários são reunidos na etapa seguinte. Retirado de (43).
Técnicas de programação paralela, protocolos de processamento, tecnologias de isolamento de processos e sistemas gerenciadores possibilitam o desenvolvimento de sistemas reprodutíveis e escaláveis para processamento de grandes volumes de dados de sequenciamento. Entretanto existem limitações em sistemas capazes de distribuir e processar tarefas em múltiplos computadores em rede e soluções melhores para automatizar a utilização dos protocolos para centenas de amostra. Também se faz necessário o desenvolvimento e aplicação de protocolos de processamento reprodutíveis em estudos genômicos de larga escala. Este trabalho apresenta protocolos de processamento bem testados e otimizados para grandes quantidades de amostras. Também é apresentado soluções computacionais desenvolvidas compõem um ecossistema para análises genômicas reprodutíveis e escaláveis.
OBJETIVOS
Objetivo Principal
Analisar, aplicar e desenvolver soluções em computação de alto desempenho para otimização de protocolos e ferramentas em bioinformática voltadas para processamento de dados de sequenciamento de nova geração, enfatizando a reprodutibilidade dos resultados.
Objetivos Específicos
• Gerar conhecimento técnico-científico em métodos computacionais de alto desempenho para processamento de dados de sequenciamento.
• Avaliar a aplicação de soluções de computação de alto desempenho para resolver problemas relacionados com grandes volumes de dados com alta dimensionalidade.
• Implementar ou otimizar ferramentas em bioinformática utilizando soluções de alto desempenho.
• Aplicar as ferramentas desenvolvidas para processar dados de sequenciamento gerados pelo nosso próprio grupo.
MATERIAL E MÉTODOS
Conjuntos de dados de sequenciamento
O Laboratório de Biologia Computacional e Bioestatística (BCBLab) é responsável pelo armazenamento, análise e compartilhamento de dados de microarranjo e de sequenciamento gerados pelo Laboratório de Genética da Faculdade de Ciências Médicas (FCM) da Universidade Estadual de Campinas (UNICAMP), e colaboradores. Conjuntos de dados de sequenciamento foram utilizados durante o desenvolvimento e testes dos protocolos de processamento e sistemas computacionais. A
Tabela 1 apresenta os conjuntos de dados utilizados e seus respectivos projetos de pesquisa.
Tabela 1 - Conjuntos de dados de sequenciamento, número de amostras e descrição do projeto.
Tipo de dados Amostras Descrição
RNA-seq 18 Estudos funcionais de genes de inflamação e microRNAs relacionados às crises epilépticas no modelo do zebrafish.
Small RNA-seq 8
Small RNA-seq 175 Análise de variantes genômicas raras e dos padrões de expressão de microRNAs em pacientes com acidente vascular cerebral.
Small RNA-seq 35 Identificação de biomarcadores não-invasivos para melhorar o diagnóstico de epilepsias.
WGBS 15 Análise do padrão da Metilação do DNA
genômico na epilepsia do lobo temporal mesial associada à esclerose hipocampal.
WGBS 38 Detecção de DNA circulante metilado como biomarcador não invasivo para identificação de
pacientes com epilepsia do lobo temporal mesial e acidente vascular cerebral isquêmico.
WES 1038 Amostras do Laboratório de Genética (incluindo BIPMed).
Para os testes de desempenho e validação dos sistemas foram utilizados dois subconjuntos de dados.
• BIPMed WES 12 - Conjunto de dados de sequenciamento completo do exoma (WES), do projeto BIPMed. Foram utilizadas amostras de 12 indivíduos.
• 1KG WGS 50 – Conjunto de dados de sequenciamento completo do genoma (WGS) de baixa cobertura do Projeto 1000 Genomas (34).
Ambientes computacionais
O BCBLab possui um parque computacional com 5 servidores de processamento (total 136 núcleos de CPU e 756 GB de memória) e um servidor de arquivos distribuídos em rede (NFS - Network File System) com 80 TB de capacidade de armazenamento. Todos os servidores possuem o sistema operacional Ubuntu Server, sistema Docker instalado, e estão conectados em uma rede local.
O Centro de Computação em Ciências e Engenharia (CCES) possui um cluster, chamado de Kahuna, que possui um servidor de processamento com 64 CPU e 1 TB de memória, um servidor de NFS com quota de 20 TB e um servidor de acesso.
Protocolos de processamento
Os protocolos de processamento foram desenvolvidos utilizando Workflow Description Language (WDL). WDL foi escolhido por ser independente de plataforma, suportar Docker e possuir biblioteca de funções. Os protocolos são otimizados para processar várias amostras utilizando a técnica de scatter-gather, ou seja, é possível processar múltiplas amostras ao mesmo tempo. Todas as tarefas que compõem esses protocolos requerem
imagens de aplicativos Docker, dessa forma, nenhuma tarefa é executada no sistema operacional anfitrião. Essas imagens de aplicativos também foram desenvolvidas e são atualizadas conforme novas versões dos programas de bioinformática utilizados são lançadas. As imagens foram publicadas no DockerHub e são instaladas automaticamente na primeira execução do protocolo. Foram desenvolvidos protocolos para os seguintes tipos de dados de sequenciamento, RNA-seq, Small RNA-seq, WGBS e WES/WGS.
Os protocolos RNAseq e MirnaSeq possuem um fluxo de processamento similar alterando apenas os programas e os parâmetros utilizados. Esses protocolos realizam a filtragem de fragmentos de sequências, alinham os reads válidos no genoma de referência, e contam o número de alinhamentos em regiões genômicas conhecidas, como genes e micro-RNAs, gerando assim uma tabela de contagem com todas as amostras. Essa contagem pode ser utilizada para análise de expressão diferencial utilizando pacotes estatísticos como o DESeq2 (44) e o edgeR (45). Os protocolos foram baseados na literatura (46–51).
A versão 2.1.0 do protocolo RNAseq utiliza os programas: TrimGalore 0.6.4 para filtragem; STAR 2.6.3a para alinhamento; e HTSeq-count 0.11.1 para contagem. A versão 2.0.0 do protocolo MirnaSeq utiliza os programas: TrimGalore 0.6.4 para filtragem; BWA 0.7.17 para alinhamento; e featureCounts 2.0.0 para contagem. A Figura 7 apresenta o fluxo de trabalho desses dois protocolos.
Figura 7 – Fluxo de processamento para contagem de regiões conhecidas como genes e micro-RNAs. Arquivos FASTQ contendo sequências originais são filtrados para remover contaminações (como adaptadores e outros artefatos). Depois as sequências válidas são mapeadas contra um genoma de referência. Os fragmentos alinhados são contados de acordo com anotações disponíveis sobre o genoma gerando assim uma tabela de contagens.
O protocolo de criação de perfil de metilação em dados de WGBS possui três variações para corresponder as diferenças entre as técnicas sequenciamento para identificação de metilação de DNA: Accel-NGS Methyl-Seq DNA Library (WGBS), Pico Methyl-Methyl-Seq Library (PicoMethyl), e NEBNext Enzymatic Methyl-seq (EM-seq). Todas as variações possuem as mesmas tarefas de processamento, realizadas para cada amostra de forma independente: filtragem dos fragmentos de sequência, alinhamento dos reads válidos no genoma de referência, remoção de alinhamentos duplicados, extração e quantificação da metilação (5-methylcytosine) em CpG (citosina seguida imediatamente por uma guanina, na fita 5’) ao longo do genoma que gera a tabela de metilação ao longo de todo o genoma. A tabela de metilação pode ser utilizada para identificar regiões diferencialmente metiladas com o pacote bsseq (52) e o methylKit (53). Os protocolos foram baseados em trabalhos anteriores (54) e na literatura(55–57).
Os protocolos utilizam os programas: TrimGalore 0.6.5 para filtragem; Bismark 0.22.2 para alinhamento, de-duplicação e contagem; e FastQC 0.11.8 para controle de qualidade. A Figura 8 apresenta o fluxo de trabalho do protocolo.
Figura 8 - Fluxo de trabalho do protocolo de processamento de dados de WGBS e variantes.
O protocolo HaplotypeCalling é composto de 5 protocolos para identificação de variantes genômicas em dados de sequenciamento. Esses protocolos foram desenvolvidos pelo Broad Institute e são considerados pelos desenvolvedores do programa GATK versão 4 as melhores práticas para esse tipo de análise (58). Os protocolos são: 1) conversão dos arquivos FASTQ para o formato uBAM; 2) pré-processamento de arquivos uBAM para arquivos de alinhamentos (59); 3) os arquivos BAM são utilizados para chamadas de variantes gerando arquivos de variantes ao longo de todo o genoma (gVCF) para cada amostra (60). O protocolo também possui uma etapa para converter os arquivos final de alinhamento do formato BAM (61) para o formato CRAM. Esse formato reduz o espaço necessário para armazenamento ao registrar apenas as diferenças (delta) dos fragmentos de sequência mapeados e a sequência de referência (62).
Os protocolos de terceiros processam apenas uma amostra, mas utilizam a técnica de scatter-gather para dividir os dados da amostra em regiões genômicas. Já o protocolo HaplotypeCalling aceita múltiplas amostras utilizando a mesma técnica. Dessa forma, o protocolo gera centenas de tarefas potencializando a otimização em ambientes HPC. O protocolo foi desenvolvido para funcionar com diferentes versões do genoma de referência humano: hg19, b37 e GRCh38.
A versão 1.2.2 do protocolo HaplotypeCalling incorpora os protocolos: PairedFastqToUnmappedBam 3.0.0 para converter arquivos FASTQ em uBAM; ProcessingForVariantDiscoveryGATK4 2.0.0 para alinhamento; ValidateBams 2.0.0 para validação de dados de alinhamento; ConvertToCram 1.0.0 para converter arquivo BAM em CRAM; e HaplotypeCallerGvcfGATK4 2.0.0 para chama de variantes de cada amostra; A Figura 9 apresenta o fluxo de trabalho geral do protocolo.
Figura 9 - Diagrama de fluxo de trabalho do protocolo HaplotypeCalling. Documentos representam arquivos e quadrados são os protocolos incorporados. FASTQ são os arquivos de entrada contendo os fragmentos de sequência que são convertidos para o formato uBAM. Diferente do formato FASTQ, uBAM permite registrar metadados das amostras. Os reads são mapeados em um genoma de referências. Os dados de alinhamento passam por tarefas de preparação antes de gerar o arquivo BAM pronto para identificação de variantes. Arquivos BAM finais são validados, convertidos para o formato CRAM e utilizados para chamadas de variantes. Essa última etapa resulta em arquivos gVCF (variantes ao longo de todo o genoma).
Os resultados do protocolo HaplotypeCalling são arquivos no formato VCF (63) com informações sobre as variantes identificadas ao longo de todo o genoma (gVCF). Esses arquivos podem ser utilizados em protocolos de identificação de variantes, recalibração e filtragens mais complexos como JointDiscovery, desenvolvido também pelo Broad Institute. O protocolo
JointDiscovery versão 1.1.2 foi utilizado para gerar os arquivos VCF finais dos conjuntos de dados. Arquivo VCF final contém todas as amostras e as variantes compartilhadas entre os indivíduos. Esse arquivo pode ser utilizado para análises seguintes utilizando pacotes como VariantAnnotation (64), ou incorporado em banco de variantes genômicas como o BIPMed através de beacons (65) e outros sistemas como o BraVE – BIPMed Variant Explorer (66).
Programas de automação
Para utilizar os protocolos de processamento escritos em WDL é necessário escrever o arquivo de parâmetros de entrada. Esse arquivo pode ser facilmente escrito em um editor de texto simples. Entretanto, quando o conjunto de dados contém centenas de amostras, o arquivo de parâmetros pode ter milhares de linhas para descrever todos os arquivos relacionados as amostras e genoma de referência, além de inúmeros parâmetros. A análise de identificação de variantes genômicas utilizando os protocolos HaplotypeCalling e JointDiscovery é um exemplo de como protocolos complexos pode levar a falhas de execução devido a problemas nos arquivos de parâmetros de entrada. Dessa forma, foi desenvolvido o programa Espresso-Caller para automatizar todo a análise de identificação de variantes em dados de WES e WGS.
Espresso-Caller é um programa de linha de comando que realiza cinco etapas: 1) verificar os arquivos de entrada (se os arquivos têm seus pares) e de referência (se todos os arquivos existem); 2) gerar o arquivo com todos os parâmetros; 3) submeter os protocolos de processamento para o Cromwell; 4) verificar o estado da execução do protocolo; e 5) coletar os arquivos de resultados. A verificação dos arquivos de entrada utiliza convenções sobre configuração, ou seja, o programa presume que os dados de WES/WGS estão divididos por orientação da fita (forward e reverse) no formato FASTQ. O programa espera que todos os arquivos referência, de acordo com a versão escolhida pelo usuário, estejam acessíveis. Caso alguma dessas verificações falhe o programa não irá continuar. O próximo passo é gerar o arquivo de entrada contendo todos os parâmetros exigidos pelo protocolo. Para
isso o programa utiliza novamente convenções, arquivos templates e expressões regulares.
Após as verificações o Espresso-Caller grava os arquivos WDL e de parâmetros de entrada no diretório de resultados que foi especificado pelo usuário. A partir desses arquivos o programa submete os protocolos para o Cromwell (no modo servidor) através de sua API própria. Após a submissão o Espresso-Caller mantém a comunicação com o Cromwell até que o servidor informe que a execução do protocolo foi concluída. Caso a execução tenha dado certo o programa então coleta os arquivos de resultados, copiando ou movendo conforme as instruções do usuário, para o diretório de resultados.
A análise de identificação de variantes utiliza dois protocolos independentes. Quando concluído a execução do protocolo HaplotypeCalling e o programa já coletou todos os resultados, o protocolo JointDiscovery é executado em seguida realizando todas as etapas anteriores (verificar arquivos de entrada e referência, submeter protocolo para Cromwell e coletar resultados quando concluído). O usuário pode determinar que apenas um dos protocolos deve ser executado.
Espresso-caller permite que o usuário incorpore conjuntos de dados já processados (arquivos gVCF) como entrada do protocolo JointDiscovery. Dessa forma, o programa irá executar o protocolo HaplotypeCalling sobre todas as amostras de entrada (arquivos FASTQ) e então adicionar as amostras extras antes de executar a segunda etapa gerando o arquivo VCF final com variantes dos indivíduos dos dois conjuntos. Essa estratégia foi utilizada para processar as amostras de WES em conjunto com 258 amostras de mesmo tipo do projeto BIPMed. A Figura 10 apresenta como o Espresso-Caller executa os protocolos.
Figura 10 - Fluxo de execução dos protocolos incorporados pelo Espresso-Caller. Amostras já processadas podem ser adicionadas na segunda parte.
Espresso-Caller foi especialmente utilizado no ambiente Kahuna. Dessa forma fez-se necessário implantar um ecossistema que permitisse distribuir as tarefas de processamento no computador multiprocessado. A Figura 11 apresenta a visão geral de como Espresso-Caller foi utilizado no Kahuna.
Figura 11 – Visão geral do ecossistema implantado no Kahuna. O usuário utiliza o comando espresso (Espresso-Caller) para executar a análise de identificação de variantes genômicas. O programa submete os protocolos para o Cromwell. Cromwell foi configurado para delegar as tarefas para o sistema de processamento em fila PBS Pro. Esse sistema, por sua vez, executa as tarefas no computador. Os arquivos são mantidos no NFS.
Sistema de distribuição e execução de tarefas
O sistema RNNR foi projetado para distribuir as tarefas de processamento entre nós computacionais conectados em rede local com acesso a um sistema de arquivos compartilhado. O programa foi escrito na linguagem de programação Go (67). O sistema possui dois modos de execução: Master e Worker. Um único programa de linha de comando permite iniciar uma instância de RNNR nos dois modos além de oferecer comandos para consulta de tarefas e administração de nós computacionais.
RNNR Master implementa a API TES, através do protocolo HTTP, para comunicação com sistemas gerenciadores de workflow. É por meio dessa API que sistemas como Cromwell submetem tarefas para serem executadas. Essas tarefas são mantidas em uma fila única até que o escalonador atribua um nó computacional com recursos suficientes. O escalonador monitora o recebimento de novas tarefas, identifica qual nó computacional disponível é
mais adequado para executar a tarefa, delega a execução da tarefa para o nó selecionado e verifica o estado de execução das tarefas.
Dentre os nós computacionais habilitados e com recursos suficientes para executar a uma determinada tarefa, o algoritmo prioriza o nó que terá menos recursos disponíveis após a inicialização da tarefa, ou seja. Essa estratégia é utilizada para que computadores com mais recursos estejam disponíveis para processar eventuais tarefas que computadores capazes não estariam habilitados. Por exemplo, ocupar um único computador (8 CPUs) com as tarefas de filtragem de sequências deixa liberado computadores com mais recursos (16 CPUs) para processar tarefas de alinhamento. A Figura 12 apresenta o diagrama de estados do sistema escalonador de tarefas.
Figura 12 – Diagrama de estados do escalonador de tarefas do sistema RNNR. As tarefas submetidas são verificadas e alteradas para o estado em fila (Queued). Quando houver um nó computacional habilitado para executar a tarefa a mesma tem seu estado alterado para inicializando (Initializing). Se o container for criado e executado corretamente a tarefa muda para o estado rodando (Running). A tarefa fica nesse estado até que o container seja terminado. Se o comando executado dentro do container concluir com sucesso a tarefa muda seu estado para terminado (Complete) e o container é removido liberando espaço. Os estados erro de sistema (System Error) está relacionado a problemas que ocorreram no escalonador ou no gerenciador de containers e erro do executor (Executor Error) acontece quando o comando termina com erros. O estado pausado (Paused) não é utilizado pelo sistema.
As informações sobre as tarefas e nós computacionais são armazenadas são mantidos pelo Master utilizando uma instância de MongoDB. RNNR estende a API TES versão 0.4.0 adicionando campos sobre métricas de uso de recursos por tarefas e informações sobre nó computacionais. A Figura 13 apresenta o diagrama do banco de dados.
Figura 13 – Diagrama do banco de dados do sistema RNNR. Campos em itálico não são utilizados pelo sistema e campos em negrito são específicos.
A instância Master comunica-se com as instancias Woker através da rede local utilizando o protocolo gRPC. Worker é inicializado em cada um dos computadores que serão utilizados para executar as tarefas de processamento. Worker é responsável por gerenciar os Docker containers e coletar as métricas de uso dos recursos como tempo de CPU, porcentagem máxima de CPU e quantidade máxima de memória registrado pelo container. O usuário adiciona as instancias Worker definindo os recursos máximos que estarão disponíveis para a instancia Master. Worker foi projetado para não manter estado (dados em memória ou banco de dados) e utilizar a menor quantidade possível de recursos do nó computacional.
Avaliação de desempenho e reprodutibilidade
O programa de automação Espresso-Caller foi utilizado para testar o sistema RNNR em diferentes configurações e validar os resultados de saída. Espresso-Caller foi escolhido porque incorpora os protocolos de processamento mais complexos dentre os protocolos desenvolvidos e utilizados, além de simplificar a submissão de vários workflows para o sistema Cromwell. Para o teste inicial foi determinado três configurações distintas: 1)
Cromwell Local com 4 tarefas em paralelo utilizando sistema de arquivos
local (discos rígidos no mesmo servidor); 2) Cromwell + RNNR com 8 tarefas utilizando 2 servidores em rede cada um com até 4 tarefas e um servidor para armazenamento de arquivos distribuídos (NFS); e 3) Cromwell + RNNR com
12 tarefas é uma variação da segunda configuração com acréscimo de um
servidor com 4 tarefas. O Espresso-Caller foi executado 3 vezes em cada cenário para processar 12 amostras de WES do BIPMed (BIPMed WES 12). Nesse teste foi verificado se os arquivos VCF resultados eram equivalentes entre os testes. Também foi avaliado a distribuição do tempo total de processamento de cada execução. A Figura 14 apresenta os dois ambientes computacionais.
Figura 14 - Diferentes configurações para executar protocolos reprodutíveis em ambientes computacionais utilizando rede local. Cromwell Local utiliza o
sistema de arquivos do servidor para armazenar os arquivos. As tarefas são executadas dentro de containers gerenciados pelo próprio Cromwell. Cromwell + RNNR utiliza o sistema de arquivos em rede para armazenar os arquivos de processamento. Cromwell submete as tarefas para RNNR Master que, por sua vez, envia-as para os nós computacionais que possuem uma instância RNNR Worker cadastrada. RNNR armazena os dados de tarefas em MongoDB e Cromwell armazena os dados em MySQL.
O teste seguinte avaliou a capacidade do sistema RNNR de gerenciar centenas de tarefas ao mesmo tempo, distribuindo-as em 4 nós computacionais com capacidades de processamento diferentes. Para isso Espresso-Caller foi executado para processar 50 amostras de sequenciamento completo do genoma de baixa cobertura do projeto 1000 Genomas (1KG WGS 50) utilizando a seguinte configuração: um servidor NFS para hospedar todos os arquivos. Um nó computacional foi designado para manter os serviços Cromwell e RNNR Master. Outros 4 nós computacionais rodaram instâncias de RNNR Worker. A configuração soma um total de 120 núcleos de CPU e 120 GB de memória. As métricas foram coletadas do RNNR, dos registros de eventos (logs) dos containers RNNR Master e Cromwell, e estatísticas do Docker.
RESULTADOS
Protocolos de processamento
Os protocolos de processamento desenvolvidos são independentes de plataforma, contribuem para a reprodutibilidade da análise e são otimizados para processar múltiplas amostras. Os protocolos RNAseq e MirnaSeq foram utilizados para processar os dados do projeto “Estudos funcionais de genes de inflamação e microRNAs relacionados às crises epilépticas no modelo do zebrafish”. O protocolo MirnaSeq também foi utilizado em dois outros projetos: “Análise de variantes genômicas raras e dos padrões de expressão de microRNAs em pacientes com acidente vascular cerebral”, e “Identificação de biomarcadores não-invasivos para melhorar o diagnóstico de epilepsias”.
Os protocolos para dados de WGBS, através do programa MethylSeq versão 1.0.1, foram utilizados nos projetos “Análise do padrão da Metilação do DNA genômico na epilepsia do lobo temporal mesial associada à esclerose hipocampal”, e “Detecção de DNA circulante metilado como biomarcador não invasivo para identificação de pacientes com epilepsia do lobo temporal mesial e acidente vascular cerebral isquêmico”. Os protocolos HaplotypeCalling e JointDiscovery, através do programa Espresso-Caller, foram utilizados para processar os dados de WES do Laboratório de Genética incluindo as amostras do BIPMed.
Os protocolos estão disponíveis em
https://github.com/labbcb/workflows/ Os arquivos que descrevem as imagens de aplicativos estão em disponíveis em https://github.com/labbcb/dockerfiles. Esses protocolos podem ser reutilizados para o processamento de futuros conjuntos de dados de sequenciamento ou até mesmo por outros grupos de pesquisa.
Programas de automação
O programa de linha de comando Espresso-Caller versão 1.2.2 foi utilizado para processar conjuntos de dados com centenas de amostras, incluindo indivíduos do projeto BIPMed. Sua utilização simplifica o trabalho de executar protocolos de processamento ao gerar os arquivos de parâmetros de
entrada, submeter para o Cromwell versão 47 e coletar os arquivos de resultados automaticamente. Através de convenções de nomes de arquivos é possível processar múltiplos lotes de amostras ao mesmo tempo. O programa também permite incorporar amostras previamente processadas para aumentar a confiança das chamadas de variantes. Espresso-Caller está disponível em
https://github.com/labbcb/espresso-caller.
A partir dos registros de atividades (logs) gerados durante a execução do Espresso-Caller para analisar os dados do Laboratório de Genética foi possível estimar o tempo necessário para processar amostras de WES utilizando o ambiente Kahuna. Foi estimado que uma amostra leva 49,52 minutos para ser processada (39,36 e 10,16 minutos para executar HaplotypeCalling e JointDiscovery respectivamente). Quando processado em conjunto com as 258 amostras do BIPMed já processadas (arquivos gVCF), o tempo total aumenta para 44,53 horas. A Figura 15 apresenta o tempo de processamento e o tempo estimado para 4 lotes de amostras de WES (150, 161, 285 e 433 indivíduos).
Figura 15 – Tempo de processamento e o tempo estimado para lotes de amostras de WES em conjunto com os dados do BIPMed.
Espresso-Caller é um exemplo de programa que permitiu automatizar etapas complexas de análise de grandes volumes de dados ao incorporar protocolos escritos em WDL. Essa estratégia foi utilizada para criar o programa MethSeq que permite ao usuário definir o tipo de dados: WGBS, PicoMethyl ou EM-seq. O programa também oferece parâmetros para filtragem dos fragmentos de leitura. MethSeq está disponível em
https://github.com/labbcb/methseq.
Sistema de distribuição e execução de tarefas
O sistema RNNR foi desenvolvido para permitir a execução de tarefas de processamento distribuindo-as em computadores conectados em rede local. O sistema é interoperável com o Cromwell versão 48. Os testes de desempenho mostraram que RNNR escala ao aumentar o número de unidades de processamento (CPUs) fazendo com que o tempo total do processamento diminua. A Figura 16 apresenta compara tempos de execuções do Espresso-Caller em configurações para chamada de variantes.
Figura 16 – Distribuição do tempo total para chamada de variantes de 12 amostras WES em diferentes configurações.
O sistema RNNR também foi testado em conjunto com Cromwell e Espresso-Caller para processar um conjunto de dados de 10 amostras de WGS de baixa cobertura do projeto 1000 Genomas (67). Nesse teste foi avaliado a capacidade do RNNR de distribuir e executar 1182 tarefas de processamento em 4 nós computacionais. O tempo total de execução foi de 1 dia e 20 horas. A partir das métricas do uso de recursos por tarefas coletadas pelas instancias de RNNR foi possível calcular a eficiência do escalonador ao atribuir tarefas com diferentes requisitos computacionais (CPU e memória) aos computadores com recursos disponíveis. A Figura 17 apresenta a porcentagem de uso dos recursos e o número total de tarefas em execução ao longo do tempo.
Figura 17 – Porcentagem do uso dos recursos (CPU e memória) de todos os nós computacionais e número de tarefas em execução ao longo do tempo de processamento do protocolo HaplotypeCalling.
Ecossistema
Os sistemas utilizados, em conjunto com os programas e protocolos desenvolvidos, permitiram a criação de um ecossistema eficiente e reprodutível para processamento de conjuntos de dados de NGS em ambientes de HPC. O ecossistema é dividido em três partes: Usuário, Serviços e Infraestrutura. Programas de linha de comando e aplicativos web utilizados pelo usuário encarregam-se de comunicar com o sistema Cromwell. Esses programas funcionam como clientes do serviço Cromwell submetendo workflows e controlando o estado da execução dos protocolos. Os programas Espresso-Caller e MethSeq são exemplos de programas de automação específicos para um tipo de dado de sequenciamento. Cromwell submete as tarefas de processamento para o backend configurado. Esse ecossistema foi implantado em dois ambientes computacionais diferentes: Kahuna e BCBLab. No ambiente Kahuna, Cromwell utiliza o backend HPC para submeter jobs para o sistema de filas PBS Pro. Já no ambiente BCBLab, o sistema comunica, através da API TES, com o servidor RNNR que executa as tarefas de processamento em containers Docker. A Figura 18 apresenta a visão geral do ecossistema.
Figura 18 - Visão geral do ecossistema para processamento de dados genômicos de larga escala. Programas de automação, como Espresso-Caller e MethSeq, e outros sistemas de submissão de protocolos, como programas de linha de comando (CLI) e aplicativos (Web UI), são executados pelo usuário para iniciar o processamento de um conjunto de dados. Esses programas fazem requisições ao serviço Cromwell. Este por sua vez, é configurado para preparar arquivos de entrada e submeter tarefas de processamento para sistemas compatíveis com a infraestrutura computacional como PBS Pro (Kahuna) e RNNR (BCBLab). Cada sistema irá executar as tarefas de acordo com suas próprias configurações utilizando os recursos computacionais disponíveis, como fila de tarefas e isolamento de processos via Docker.
O ecossistema pode ser expandido para suportar outras soluções computacionais. Por exemplo, Nextflow pode ser utilizado em paralelo ao Cromwell para submeter protocolos escritos em Nextflow. O sistema também suporta múltiplos backends incluindo PBS Pro e RNNR através da API TES.
DISCUSSÃO
Eficiência e reprodutibilidade
Programas de bioinformática costumam suportar processamento em múltiplos núcleos para diminuir o tempo de execução ao custo de aumentar o uso de memória. Para processar conjuntos de dados com poucas amostras, mas não escala bem para grandes quantidades de amostras. Executar programas em paralelo, ou seja, processar duas ou mais amostras ao mesmo tempo, exige orquestração e controle sobre o uso dos recursos da máquina. Quando o processamento ocorre de forma distribuída, ou seja, em dois ou mais computadores, é necessário considerar a comunicação em rede. RNNR utiliza protocolos bem definidos para chamadas de procedimentos remotos (RPC) adicionando uma camada de segurança e tolerância a falhas. O sistema escalonamento das tarefas de processamento, criado especificamente para protocolos de bioinformática, otimiza a utilização dos recursos computacionais distribuídos em diferentes computadores, diminui os tempos da análise e permite aumentar a poder computacional adicionando mais computadores ao custo de aumentar o tráfego na rede local.
Para que uma pesquisa genômica seja reprodutível é necessário disponibilizar os dados originais. Esses arquivos normalmente são submetidos para bancos de dados centralizados como o Sequence Read Archive (SRA). Com os arquivos originais disponíveis, análises realizadas no Ecossistema criados não completamente reprodutíveis. Os arquivos de protocolo (WDL) e parâmetros de entrada (JSON) utilizados na análise podem ser utilizados para executar todas as tarefas de processamento. Como cada tarefa depende de uma imagem Docker todos os programas necessários estão empacotados e acessíveis. A grande maioria das análises em bioinformática dependem de bancos de dados ou genomas de referência. Para isso, os parâmetros de entrada podem apontar ao para o arquivo que pode ser acessado remotamente via HTTP ou FTP por exemplo. Quando necessário, protocolos suplementares ou documentação podem descrever como preparar os arquivos de referência.
Limitações identificadas
Espresso-Caller e outros programas de automatização incorporam protocolos de processamento (WDL) que aplicam as mesmas tarefas aos arquivos de entrada, através da técnica de scatter-gather, para definir que esses arquivos podem ser processados independentemente permitindo paralelização. Entretanto, ao utilizar esses protocolos para centenas de amostras, a demanda de orquestração de tarefas e o uso de memória aumenta consideravelmente. Além disso, caso aconteça alguma falha durante o processamento, dependendo do ambiente computacional, é necessário executar todas as amostras novamente desde o início. Uma possível solução para esse problema é incorporar protocolos que processam apenas uma amostra. O programa de automação deve orquestrar a submissão do mesmo protocolo para todas os arquivos de entrada. Além disso, o programa pode implementar um sistema que verifica se uma amostra já foi processada com sucesso antes de submeter o protocolo. Essa solução pode melhorar a escalabilidade de análises com centenas de amostras e diminuir o tempo de processamento em situações de recuperação de falhas ao custo de aumentar a complexidade do programa de automação.
RNNR depende de conexão com a Internet para buscar e instalar imagens de aplicativo Docker antes de executar a tarefa. O sistema possui tolerância a falhas de conexão quando a imagem necessária já está instalada no sistema. Uma possível solução é implementar suporte a registros de imagens de aplicativos executadas localmente. Dessa forma RNNR buscaria a imagem nos registros locais antes de procurar no DockerHub. Essa configuração permitiria adicionar outros registros públicos como o Quay.io.
O sistema de escalonamento de tarefas do RNNR não coleta dados de utilização dos recursos computacionais do nó, ou seja, o sistema executa tarefas conforme os recursos liberados ao inscrever o nó computacional (unidades de processamento e memória). Caso o mesmo computador seja utilizado por outros meios, como executar um processo diretamente no sistema anfitrião, pode fazer com que os protocolos executados pelo Ecossistema sejam menos eficientes ou até mesmo levar a falhas de execução das tarefas. Há diferentes formas de resolver esse problema, seja através de políticas de
