Arquitetura de referência de processamento de dados genômicos

Neste documento, descrevemos as arquiteturas de referência para usar a API Cloud Life Sciences com outros produtos do Google Cloud para executar o processamento de dados genômicos usando diferentes métodos e mecanismos de fluxo de trabalho. Especificamente, este documento concentra-se nas etapas de alinhamento e chamada de variantes da análise secundária e destina-se a bioestatísticos, pesquisadores, equipes de TI de pesquisa e outros especialistas técnicos em uma organização de ciências da vida.

O Google Cloud oferece um conjunto flexível de APIs, serviços e ferramentas para executar uma solução de análise secundária econômica em escala. A análise secundária inclui, mas não se limita a, filtrar leituras brutas, alinhar e montar leituras de sequência e chamadas de controle de qualidade e variantes em leituras alinhadas. O diagrama a seguir ilustra as etapas no processamento de dados genômicos em escala e mostra quais etapas são realizadas no Google Cloud.

Processamento de dados genômicos em escala com o Google Cloud.

Como mostra o diagrama anterior, uma amostra de dados genômicos passa primeiro pela análise e, em seguida, é processado como dados brutos no Google Cloud para análise. Em seguida, os dados processados passam por uma análise de nível superior e produzem relatórios, como PDFs, que podem ser baixados da nuvem por bioestatísticos e outros especialistas técnicos.

Componentes de arquitetura de referência do processamento de dados genômicos

Este documento inclui detalhes sobre o uso da API Cloud Life Sciences e suas duas visões gerais da arquitetura de referência que descrevem maneiras diferentes de usar a API para executar o processamento de dados genômicos.

Como usar a API Cloud Life Sciences

A API Cloud Life Sciences oferece um serviço de computação totalmente gerenciado que disponibiliza os melhores recursos computacionais, com base nos requisitos de recursos para um job em lote. A API fornece uma maneira de criar, executar e monitorar ferramentas de linha de comando das instâncias do Compute Engine em execução em contêiner do Docker. É possível organizar várias ferramentas de linha de comando para serem executadas em uma ordem específica com dependências entre as etapas. A API Cloud Life Sciences inclui o serviço WorkflowsServiceV2Beta, que pode ser usado para executar fluxos de trabalho, como pipelines consistêntes em contêineres do Docker.

Um objeto Pipeline consiste em uma ou mais descrições Action e uma mensagem Resources que descreve quais recursos da nuvem são necessários para executar o pipeline. Cada ação descreve uma única execução de contêiner do Docker, que pode incluir um ou mais objetos command. Os objetos Action são executados em sequência, com cada um deles aguardando sua vez até que o objeto anterior saia, a menos que o objeto anterior esteja definido para ser executado em segundo plano. Há sinalizações que afetam como cada objeto Action é executado e como o status de saída afeta as ações no pipeline. Por exemplo, se um objeto Action precisar ser executado em segundo plano ou se o status de saída for ignorado. Como autor do pipeline, você cria uma mensagem Resources que descreve os recursos da nuvem necessários para executar o pipeline.

As especificações na mensagem Resources podem incluir o seguinte, por exemplo:

  • Tamanhos de máquina virtual (VM), incluindo formatos de máquina personalizados e a capacidade de preempção
  • Zonas e regiões para alocação de VM
  • Opções de rede (importantes para grandes projetos de processamento, devido a limites de tamanho de rede)
  • Aceleradores anexados (GPUs)
  • Discos anexados
  • Contas de serviço e escopo

A API Cloud Life Sciences realiza as seguintes tarefas quando recebe um objeto Pipeline por meio de uma chamada de API:

  1. Cria uma instância de VM do Compute Engine com base no conteúdo da mensagem Resources.
  2. Faz o download de todas as imagens do Docker especificadas em uma descrição Action.
  3. Executa cada objeto Action como um novo contêiner do Docker com a imagem e o comando especificados.
  4. Exclui a instância de VM do Compute Engine.

Um conjunto típico de tarefas apontadas em uma descrição Action pode incluir, por exemplo:

  • o download dos arquivos de entrada;
  • execução de comandos;
  • cópia dos registros para o Cloud Storage;
  • o upload de arquivos de saída.

A API Cloud Life Sciences usa a capacidade de armazenamento e processamento escalonável e de alto desempenho do Google Cloud, além das instâncias de VM preemptivas, GPUs e unidades de processamento de tensor (TPUs) para ajudar a fornecer um ambiente seguro e escalonável para análise de dados. Isso inclui a execução de estruturas de análise secundária padrão do setor, como o Genome Analysis Toolkit (GATK) e o DeepVariant, em uma única amostra ou em conjuntos de dados, de maneira rápida, fácil e econômica.

A API Cloud Life Sciences é integrada a mecanismos de fluxo de trabalho de código aberto, como Cromwell, Nextflow e Galaxy. Além disso, o Nextflow e o Galaxy oferecem suporte à computação no Google Cloud por meio de integrações diretas com o Compute Engine e o Cloud Storage. O diagrama a seguir mostra uma arquitetura de referência que inclui componentes da API Cloud Life Sciences e outros serviços necessários para executar um pipeline de análise secundária genômica no Google Cloud.

Arquitetura de referência que mostra a API Cloud Life Sciences em execução nos nós de computação do Compute Engine usando disco permanente, SO otimizado para contêineres e GPUs.

Processamento de dados genômicos: como usar o Cromwell para executar fluxos de trabalho de práticas recomendadas do GATK

Você pode usar a API Cloud Life Sciences com um mecanismo de fluxo de trabalho para orquestrar tarefas. No exemplo a seguir, o Cromwell é usado para realizar análises secundárias ao aplicar os fluxos de trabalho de práticas recomendadas do GATK.

O Cromwell é um sistema de gerenciamento de fluxo de trabalho de código aberto que pode ser executado em vários ambientes para programar, executar e gerenciar fluxos de trabalho. O Cromwell lê um fluxo de trabalho definido na Linguagem de descrição do fluxo de trabalho (WDL) e executa tarefas individuais do fluxo de trabalho usando a API Cloud Life Sciences. Nesse caso, um servidor Cromwell é executado em uma instância de VM do Compute Engine, com um servidor do Cloud SQL para armazenar dados operacionais. A Cromwell VM executa cada uma das tarefas definidas, fazendo chamadas de API para a API Cloud Life Sciences iniciando instâncias de VM para cada uma das tarefas, conforme configurado na WDL.

O GATK inclui ferramentas para descoberta e genotipagem de variantes. Os fluxos de trabalho das práticas recomendadas do GATK incluem vários canais para casos de uso específicos. Este exemplo se concentra no fluxo de trabalho de produção, PaparadoEndSingleSampleWf. O fluxo de trabalho inclui pré-processamento de dados, variante de chamada inicial solicitando polimorfismos de nucleotídeo único (SNPs) da linha germinativa e descoberta de indel em uma única amostra, dados de sequenciamento de genoma humano inteiro.

O fluxo de trabalho usa dados de sequenciamento de pareamento inteiro de genoma humano no formato BAM (uBAM) não mapeado com um ou mais grupos de leitura e usa o genoma de referência Hg38 com contigs ALT. As saídas incluem um arquivo cram, um índice cram, o md5 cram, GVCF e um índice correspondente, um relatório BQSR e várias métricas resumidas. A amostra usada é uma versão reduzida do NA12878 que contém apenas três grupos de leitura da amostra completa. O fluxo de trabalho é empacotado como uma série de arquivos WDL que definem as tarefas individuais com uma especificação de entrada e opções genéricas. Os arquivos da WDL especificam os recursos da nuvem para cada tarefa, como o número de núcleos de CPU e memória para cada instância de VM, qual contêiner instalar em cada instância de VM e o comando para ser executado, assim como os locais dos arquivos de entrada e saída. Há também outras especificações, por exemplo, se uma etapa precisa ser executada em máquinas preemptivas e quantas vezes executar novamente um objeto Action.

O diagrama a seguir mostra uma arquitetura típica para realizar análises secundárias genômicas usando o Cromwell para executar os fluxos de trabalho de práticas recomendadas do GATK com a API Cloud Life Sciences, incluindo as etapas necessárias para executar a análise.

Como usar o Cromwell para executar as práticas recomendadas do GATK com a API Cloud Life Sciences.

O diagrama mostra as seguintes etapas para executar uma análise secundária:

  1. Após o sequenciamento, é possível salvar as chamadas de base brutas no armazenamento local ou no armazenamento conectado à rede (NAS, sigla em inglês), onde elas são convertidas em arquivos uBAM. Em seguida, transfira esses arquivos uBAM para um intervalo do Cloud Storage.
  2. Você se autentica para atuar como uma conta de serviço usando o gerenciamento de identidade e acesso (IAM, na sigla em inglês).
  3. Envie o job para o servidor Cromwell em execução no Compute Engine.

    A solicitação passa pelo Identity-Aware Proxy, que é configurado para permitir o acesso à nuvem privada virtual usando as regras de firewall do Google Cloud.

  4. O servidor Cromwell extrai o fluxo de trabalho do GATK dos repositórios públicos.

  5. O servidor do Cromwell faz chamadas para a API Cloud Life Sciences para iniciar jobs.

  6. A API Cloud Life Sciences extrai os contêineres de cada tarefa dos repositórios públicos do GATK.

  7. A API Cloud Life Sciences inicia VMs no Compute Engine para cada tarefa e inicia o contêiner em cada máquina.

  8. A instância de VM recupera arquivos de entrada dos intervalos do Cloud Storage.

  9. A instância de VM executa tarefas computacionais e salva arquivos intermediários, de registro e de saída em um intervalo do Cloud Storage.

Processamento de dados genômicos: execução do DeepVariant

O DeepVariant é um pipeline de código aberto para análise que usa uma rede neural profunda para chamar variantes genéticas de dados de sequenciamento de DNA de última geração. Esse pipeline de análise foi desenvolvido pela equipe de pesquisa do Google e usa o TensorFlow para SNP e chamadas de variantes indel em exomas ou genomas. O DeepVariant é usado para transformar leituras de sequenciamento alinhadas em chamadas de variantes.

Para usar o DeepVariant, no nível mais alto, você precisa fornecer três entradas:

  • Um genoma de referência no formato FASTA e o respectivo arquivo de índice .fai, gerado usando o comando Samtools faidx.
  • Um arquivo de leitura alinhado no formato BAM e o respectivo arquivo de índice (.bai). As leituras precisam estar alinhadas ao genoma de referência fornecido.
  • Modelo de ML do DeepVariant usado para chamadas de variantes.

A saída do DeepVariant é uma lista de todas as chamadas de variantes no formato VCF. O DeepVariant é integrado ao framework de aprendizado de máquina do TensorFlow.

É possível executar o DeepVariant em um contêiner do Docker, nos binários diretos e executá-lo usando hardware local ou na nuvem. O DeepVariant inclui suporte para o uso de aceleradores de hardware, como GPUs e TPUs. Use o Docker para executar o DeepVariant a partir de um contêiner do Docker usando apenas um comando, conforme descrito no Guia de início rápido do DeepVariant. Para casos de uso em produção no Google Cloud, recomendamos que você integre o processo do DeepVariant ao seu fluxo de trabalho e faça a chamada a partir do mecanismo de fluxo de trabalho.

Use o DeepVariant Runner, com a API Cloud Life Sciences de maneira semelhante aos métodos explicados no tutorial Como executar o DeepVariant, de forma facultativa. Isso permite executar o DeepVariant em escala, usando um pipeline baseado no Docker otimizado para custo e velocidade.

O diagrama a seguir mostra uma arquitetura típica para executar um pipeline do DeepVariant no Google Cloud.

Arquitetura para executar um pipeline do DeepVariant no Google Cloud.

Veja a seguir as etapas para executar o DeepVariant, conforme representado no diagrama anterior:

  1. Depois de criar leituras de DNA mapeadas a partir de amostras, transfira esses arquivos BAM para um bucket do Cloud Storage.
  2. Você se autentica para atuar como uma conta de serviço usando o IAM.
  3. Execute o DeepVariant, fazendo chamadas para a API Cloud Life Sciences para iniciar jobs.
  4. A API Cloud Life Sciences extrai o contêiner do DeepVariant para cada tarefa dos repositórios públicos.
  5. A API Cloud Life Sciences inicia VMs no Compute Engine para cada tarefa e inicia o contêiner em cada máquina.
  6. A instância de VM recupera arquivos de entrada dos intervalos do Cloud Storage.
  7. A instância de VM executa tarefas computacionais e salva arquivos intermediários, de registro e de saída em um intervalo do Cloud Storage.

Governança de dados

A arquitetura descrita neste documento se concentra nos componentes específicos da análise de dados genômicos. Para uma integração de produção que inclua dados genômicos humanos, pode ser necessário configurar componentes adicionais no Google Cloud, dependendo dos requisitos e melhores práticas em sua região.

O Google Cloud oferece uma arquitetura de ponta a ponta que encapsula as práticas recomendadas do Google Cloud para atender às necessidades de segurança, privacidade e assistência médica. O documento conceitual Arquitetura: Cloud Healthcare alinhado ao HIPAA e o tutorial relacionado Como configurar um projeto alinhado ao HIPAA usam o Kit de ferramentas de proteção de dados do Cloud Healthcare para implantar a estrutura organizacional completa do Google Cloud. Isso inclui muitos dos controles de práticas recomendadas de segurança e privacidade para dados de assistência médica, como configuração de acesso apropriado, manutenção de registros de auditoria e monitoramento de atividades suspeitas. Para saber mais sobre esses recursos e como o Google Cloud ajuda a proteger os dados dos clientes, consulte o artigo Como proteger seus dados com o Google Cloud.

Residência dos dados

Para organizações que têm requisitos de residência de dados, consulte a seção "Serviços gerais" do documento Termos específicos de serviço para revisar o compromisso de residência de dados do Google Cloud, que destaca ferramentas e controles disponíveis para ajudar a configurar os ambientes dos usuários. para atender a esses requisitos.

Políticas da organização

Para limitar a localização física de um recurso em um projeto, você pode definir uma política da organização que inclua uma restrição de local do recurso. Para ver uma lista de serviços compatíveis, consulte Serviços compatíveis com locais de recursos.

Identificadores de recursos do Google Cloud

Para os fins deste documento, os compromissos de residência de dados não se aplicam a identificadores de recursos, atributos ou outros rótulos de dados. Você é responsável por garantir que nenhum dado confidencial seja exposto nesses identificadores, atributos ou outros rótulos de dados, como em um nome de arquivo.

Regiões e zonas da API Cloud Life Sciences

Ao fazer chamadas à API Cloud Life Sciences, você precisa especificar a região em que a solicitação será enviada. O exemplo a seguir mostra um URI de endpoint para executar um pipeline no projeto foo do Google Cloud e na região us-central1:

v2beta/projects/foo/locations/us-central1/workflows:runPipeline

Todos os metadados salvos para a operação, incluindo nomes de imagem de contêiner, nomes de arquivos de entrada e saída e outras informações enviadas na solicitação para a API Cloud Life Sciences, serão salvos nessa região.

Quando a API Cloud Life Sciences inicia uma instância de VM do Compute Engine, a chamada de API precisa incluir uma região ou zona para iniciá-la. É possível configurar uma ou mais regiões ou zonas para restringir o local da VM. A instância de VM, os dados em repouso no Compute Engine e os discos permanentes permanecem na região especificada. Os recursos disponíveis para instâncias do Compute Engine, como plataformas de CPU, tipos de máquina, SSDs e GPUs, são diferentes por região e zona. Portanto, verifique se os recursos necessários estão disponíveis em uma região ou zona antes de restringir o uso a elas.

Para mais informações, consulte Detalhes e termos de residência de dados do Compute Engine.

Google Cloud Storage

É possível armazenar arquivos de entrada e saída, arquivos de trabalho temporários e instantâneos de discos permanentes no Cloud Storage. Os dados em repouso nos buckets do Cloud Storage permanecem na região ou multiregião selecionada na configuração do bucket. Para mais informações, consulte a lista atual de regiões de intervalos do Cloud Storage.

Para otimizar a disponibilidade, o desempenho e a eficiência, especifique o Cloud Storage como multiregional. Ao selecionar essa opção, os dados associados a recursos multiregionais não são vinculados a uma região específica e podem ser movidos entre elas dentro de uma área multirregional maior, por exemplo, EUA, Europa ou Ásia. Objetos armazenados em um local multirregional são geograficamente redundantes. Para mais detalhes sobre locais multiregionais, consulte recursos multiregionais.

Para desempenho e residência de dados, use a mesma região para o Cloud Storage, o Compute Engine e a API Life Sciences, se possível.

Para mais informações, consulte Detalhes e termos de residência de dados do Cloud Storage.

A seguir