Arquitectura de referencia del procesamiento de datos genómicos

En este documento, se describen las arquitecturas de referencia para usar Cloud Life Sciences API con otros productos de Google Cloud a fin de realizar el procesamiento de datos genómicos mediante diferentes métodos y motores de flujo de trabajo. En particular, en este documento se detallan los pasos de alineación y tipificación de variantes de análisis secundarios, y está dirigido a bioinformáticos, investigadores, equipos de TI de investigación y otros especialistas técnicos de una organización de ciencias biológicas.

Google Cloud ofrece un conjunto flexible de API, servicios y herramientas para ejecutar una solución rentable de análisis secundario a gran escala. El análisis secundario incluye, entre otros, el filtrado de lecturas sin procesar, la alineación y el ensamblaje de lecturas de secuencias, y el control de calidad y la llamada de variantes en lecturas alineadas.

Arquitectura

En el siguiente diagrama, se muestran los pasos para procesar datos genómicos a gran escala y se muestran los pasos que se realizan en Google Cloud.

Procesa datos genómicos a gran escala con Google Cloud.

Como se muestra en el diagrama anterior, una muestra de datos genómicos primero se somete a un análisis principal y, luego, se transfiere como datos sin procesar a Google Cloud para un análisis secundario. A continuación, los datos procesados se someten a un análisis terciario y se generan informes como PDF, que los bioinformáticos y otros especialistas técnicos pueden descargar de la nube.

Componentes de la arquitectura de referencia del procesamiento de datos genómicos

En este documento, se incluyen detalles sobre el uso de Cloud Life Sciences API y dos descripciones generales de la arquitectura de referencia en las que se describen diferentes formas de usar la API para realizar el procesamiento de datos genómicos.

Usa la API de Cloud Life Sciences

La API de Cloud Life Sciences proporciona un servicio de procesamiento completamente administrado que ofrece recursos de procesamiento óptimos, según los requisitos de recursos para un trabajo por lotes. La API proporciona una forma de crear, ejecutar y supervisar herramientas de línea de comandos en instancias de Compute Engine que se ejecutan en un contenedor de Docker. Puedes organizar varias herramientas de línea de comandos para ejecutarlas en un orden específico con dependencias entre los pasos. La API de Cloud Life Sciences incluye el servicio WorkflowsServiceV2Beta, que puedes usar para ejecutar flujos de trabajo, como canalizaciones que contienen contenedores de Docker.

Un objeto Pipeline consta de una o más descripciones Action y un mensaje Resources en el que se describe qué recursos de la nube son necesarios para ejecutar la canalización. Cada acción describe una sola ejecución de contenedor de Docker, que puede incluir uno o más objetos command. Los objetos Action se ejecutan de forma secuencial y cada uno está en espera hasta que el objeto anterior salga, a menos que el objeto anterior esté configurado para ejecutarse en segundo plano. Hay marcas que afectan cómo se ejecuta cada objeto Action y cómo el estado de salida afecta las acciones en la canalización, por ejemplo, si un objeto Action debe ejecutarse en segundo plano o si el estado de salida debe ignorarse. Como autor de la canalización, creas un mensaje Resources en el que se describen los recursos en la nube necesarios para ejecutar la canalización.

Las especificaciones del mensaje Resources pueden incluir lo siguiente:

  • Tamaños de máquinas virtuales (VM), incluidas las formas y la interrumpibilidad de las máquinas personalizadas
  • Zonas y regiones para la asignación de VM
  • Opciones de Herramientas de redes (importantes para proyectos de procesamiento grandes debido a los límites de tamaño de la red)
  • Aceleradores adjuntos (GPU)
  • Discos conectados
  • Cuentas de servicio y permisos

Cloud Life Sciences API realiza las siguientes tareas cuando recibe un objeto Pipeline a través de una llamada a la API:

  1. Crea una instancia de VM de Compute Engine basada en el contenido del mensaje Resources.
  2. Descarga todas las imágenes de Docker especificadas en una descripción de Action.
  3. Ejecuta cada objeto Action como un contenedor de Docker nuevo con la imagen y el comando especificados.
  4. Borra la instancia de VM de Compute Engine.

Un conjunto típico de tareas descritas en una descripción de Action puede incluir lo siguiente:

  • Descargar archivos de entrada
  • Ejecutar comandos
  • Copiar los registros a Cloud Storage
  • Subir archivos de salida

API de Cloud Life Sciences usa la potencia de procesamiento y almacenamiento escalable y de alto rendimiento de Google Cloud junto con instancias de VM interrumpibles, GPU y unidades de procesamiento tensorial (TPU) a fin de ayudar a proporcionar un entorno seguro y escalable para el análisis de datos. Esto incluye la ejecución de frameworks de análisis secundario estándares de la industria, como Genome Analysis Toolkit (GATK) y DeepVariant, en una sola muestra o en conjuntos de datos unidos, de forma rentable, fácil y rápida.

La API de Cloud Life Sciences está integrada a motores de flujo de trabajo de código abierto, como Cromwell, Nextflow y Galaxy. Además, Nextflow y Galaxy admiten el procesamiento en Google Cloud mediante integraciones directas en Compute Engine y Cloud Storage. En el siguiente diagrama, se muestra una arquitectura de referencia que incluye componentes de Cloud Life Sciences API y otros servicios necesarios para ejecutar una canalización de análisis genómico secundario en Google Cloud.

Arquitectura de referencia que muestra Cloud Life Sciences API que se ejecuta en nodos de procesamiento de Compute Engine mediante Persistent Disk, Container-Optimized OS y GPU.

Procesamiento de datos genómico: usar Cromwell para ejecutar flujos de trabajo de las prácticas recomendadas de GATK

Puedes usar la API de Cloud Life Sciences con un motor de flujo de trabajo para organizar las tareas. En el siguiente ejemplo, Cromwell se usa para realizar análisis secundarios mientras se aplican los flujos de trabajo de las prácticas recomendadas de GATK.

Cromwell es un sistema de administración de flujo de trabajo de código abierto que se puede ejecutar en una variedad de entornos para programar, ejecutar y administrar flujos de trabajo. Cromwell lee un flujo de trabajo definido en Workflow Description Language (WDL) [Lenguaje de descripción de flujo de trabajo (WDL)] y ejecuta tareas individuales desde el flujo de trabajo mediante Cloud Life Sciences API. En este caso, un servidor de Cromwell se ejecuta en una instancia de VM de Compute Engine con un servidor de Cloud SQL para almacenar datos operativos. A continuación, la VM de Cromwell ejecuta cada una de las tareas definidas mediante la realización de llamadas a la API de la API de Cloud Life Sciences a fin de iniciar instancias de VM para cada una de las tareas configuradas en WDL.

GATK incluye herramientas para el descubrimiento de variantes y el genotipado. Los flujos de trabajo de las prácticas recomendadas de GATK incluyen una serie de canalizaciones para casos prácticos específicos. Este ejemplo se centra en el flujo de trabajo de producción, PairedEndSingleSampleWf. El flujo de trabajo incluye el procesamiento previo de datos, la tipificación inicial de variantes del polimorfismo de un solo núcleo de línea celular (SNP) y el descubrimiento de indel en una muestra única, datos de secuenciación del genoma humano.

El flujo de trabajo toma datos de secuencia de finalización de pares vinculados de genoma completo en el formato BAM (uBAM) sin asignación con uno o más grupos de lectura y usa el genoma de referencia Hg38 con contigs ALT. En los resultados, se incluyen un archivo cram, un índice cram, cram md5, GVCF y un índice correspondiente, un informe BQSR y varias métricas de resumen. La muestra usada es una versión con reducción de muestreo de NA12878 que contiene solo 3 grupos de lectura de la muestra completa. El flujo de trabajo se empaqueta como una serie de archivos de WDL en los que se definen las tareas individuales, una especificación de entrada y opciones genéricas. Los archivos de WDL especifican los recursos en la nube para cada tarea, como la cantidad de núcleos de CPU y memoria para cada instancia de VM, qué contenedor instalar en cada instancia de VM y el comando para ejecutar, y las ubicaciones de los archivos de entrada y salida. También hay otras especificaciones, por ejemplo, si un paso debe ejecutarse en máquinas interrumpibles y cuántas veces reintentar un objeto Action.

En el siguiente diagrama, se muestra una arquitectura típica para realizar análisis genómicos secundarios mediante Cromwell a fin de ejecutar los flujos de trabajo de las prácticas recomendadas de GATK con Cloud Life Sciences API, incluidos los pasos necesarios para ejecutar el análisis.

Usar Cromwell para ejecutar las prácticas recomendadas de GATK con Cloud Life Sciences API.

En el diagrama, se muestran los siguientes pasos para ejecutar un análisis secundario:

  1. Después de la secuencia, guardas las llamadas base sin procesar en el almacenamiento local o en el almacenamiento conectado a la red (NAS), en el que se convierten en archivos uBAM. Luego, transfieres estos archivos uBAM a un bucket de Cloud Storage.
  2. Debes autenticarte para actuar como una cuenta de servicio mediante la administración de identidades y accesos (IAM).
  3. Envías el trabajo al servidor de Cromwell que se ejecuta en Compute Engine.

    La solicitud pasa por Identity-Aware Proxy, que está configurado para permitir el acceso a la nube privada virtual mediante las reglas de firewall de Google Cloud.

  4. El servidor de Cromwell extrae el flujo de trabajo para GATK de los repositorios públicos.

  5. El servidor de Cromwell realiza llamadas a Cloud Life Sciences API para iniciar trabajos.

  6. Cloud Life Sciences API extrae los contenedores para cada tarea de los repositorios públicos de GATK.

  7. Cloud Life Sciences API inicia las VM en Compute Engine para cada tarea e inicia el contenedor en cada máquina.

  8. La instancia de VM recupera los archivos de entrada de los depósitos de Cloud Storage.

  9. La instancia de VM realiza tareas de procesamiento y guarda archivos intermedios, de registro y de salida en un bucket de Cloud Storage.

Procesamiento de datos genómicos: Ejecuta DeepVariant

DeepVariant es una canalización de análisis de código abierto que usa una red neuronal profunda para tipificar variantes genéticas a partir de datos de secuenciación de ADN de última generación. Esta canalización de análisis fue desarrollada por un equipo de investigación dentro de Google y usa TensorFlow para la tipificación de variantes y de SNP en exomas o genomas. DeepVariant se usa para transformar las lecturas de secuencia alineada en tipificaciones de variantes.

Para usar DeepVariant, al más alto nivel, debes proporcionar tres entradas:

  • Un genoma de referencia en formato FASTA y su archivo de índice .fai correspondiente, generado con el comando faidx de Samtools
  • Un archivo alineado de lectura en formato BAM y su archivo de índice correspondiente (.bai). Las lecturas deben alinearse con el genoma de referencia proporcionado.
  • El modelo de AA de DeepVariant que se usará para la llamada de variantes

El resultado de DeepVariant es una lista de todas las tipificaciones de variantes en formato VCF. DeepVariant está integrado en el marco de trabajo de aprendizaje automático de TensorFlow.

Puedes ejecutar DeepVariant en un contenedor de Docker o en los objetos binarios directos, y puedes hacerlo con hardware local o en la nube. DeepVariant incluye compatibilidad con el uso de aceleradores de hardware, como GPU y TPU. Puedes usar Docker para ejecutar DeepVariant desde un contenedor de Docker con un solo comando, como se describe en la guía de inicio rápido de DeepVariant. Para casos prácticos de producción en Google Cloud, recomendamos que integres el proceso de DeepVariant en tu flujo de trabajo y realices la tipificación desde el motor de flujo de trabajo.

Como alternativa, puedes usar DeepVariant Runner, que usa la API de Cloud Life Sciences de una manera similar a los métodos explicados en el instructivo Ejecuta DeepVariant. Esto te permite ejecutar DeepVariant a gran escala mediante una canalización basada en Docker que está optimizada para el costo y la velocidad.

En el siguiente diagrama, se muestra una arquitectura típica para ejecutar una canalización de DeepVariant en Google Cloud.

Arquitectura para ejecutar una canalización de DeepVariant en Google Cloud

A continuación, se indican los pasos para ejecutar DeepVariant, como se representa en el diagrama anterior:

  1. Después de crear lecturas de ADN asignadas de muestras, transfiere estos archivos BAM a un bucket de Cloud Storage.
  2. Realiza la autenticación para actuar como una cuenta de servicio mediante IAM.
  3. Ejecuta DeepVariant, que realiza llamadas a la API de Cloud Life Sciences para iniciar trabajos.
  4. Cloud Life Sciences API extrae el contenedor de DeepVariant para cada tarea de los repositorios públicos.
  5. Cloud Life Sciences API inicia las VM en Compute Engine para cada tarea e inicia el contenedor en cada máquina.
  6. La instancia de VM recupera los archivos de entrada de los depósitos de Cloud Storage.
  7. La instancia de VM realiza tareas de procesamiento y guarda archivos intermedios, de registro y de salida en un bucket de Cloud Storage.

Administración de datos

La arquitectura descrita en este documento se centra en los componentes específicos del análisis de datos genómicos. Para una integración de producción que incluya datos genómicos humanos, es posible que debas configurar componentes adicionales en Google Cloud, según los requisitos y las prácticas recomendadas en tu jurisdicción.

Google Cloud proporciona una arquitectura de extremo a extremo que resume las prácticas recomendadas de Google Cloud para satisfacer las necesidades de seguridad, privacidad y cumplimiento de la atención médica. Cloud Healthcare Data Protection Toolkit incluye muchos de los controles de prácticas recomendadas de seguridad y privacidad que se sugieren para los datos de atención médica, como configurar el acceso adecuado y mantener registros de auditoría, y la supervisión de actividades sospechosas. Para obtener más información sobre estas funciones y sobre cómo Google Cloud ayuda a proteger los datos de los clientes, consulta el informe Confía en los datos con Google Cloud.

Residencia de datos

Para las organizaciones que tienen requisitos de residencia de datos, consulta la sección “Servicios generales” del documento Condiciones específicas del servicio para revisar el compromiso de residencia de datos de Google Cloud, en el que se destacan las herramientas y los controles disponibles para ayudar a configurar los entornos de los usuarios a fin de cumplir con estos requisitos.

Políticas de la organización

Para limitar la ubicación física de un recurso en un proyecto, puedes establecer una política de la organización que incluya una restricción de ubicación de recursos. Para obtener una lista de los servicios compatibles, consulta Servicios compatibles con las ubicaciones de los recursos.

Identificadores de recursos de Google Cloud

Para los fines de este documento, los compromisos de residencia de datos no se aplican a identificadores de recursos, atributos ni otras etiquetas de datos. Eres responsable de garantizar que no se muestren datos sensibles en estos identificadores, atributos u otras etiquetas de datos, como en un nombre de archivo.

Regiones y zonas de Cloud Life Sciences API

Cuando realizas llamadas a Cloud Life Sciences API, debes especificar la región en la que se enviará la solicitud. En el siguiente ejemplo, se muestra un URI de extremo para ejecutar una canalización en el proyecto de Google Cloud foo y la región us-central1:

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

En esta región, se guardan todos los metadatos guardados para la operación, incluidos los nombres de las imágenes de los contenedores, los nombres de los archivos de entrada y salida, y otro tipo de información enviada en la solicitud a la API de Cloud Life Sciences.

Cuando la API de Cloud Life Sciences inicia una instancia de VM de Compute Engine, la llamada a la API debe incluir una región o una zona en la que iniciar la instancia de VM. Puedes configurar una o más regiones o zonas para restringir la ubicación de la VM. La instancia de VM, los datos en reposo en Compute Engine y los discos persistentes permanecen en la región especificada. Las características disponibles para las instancias de Compute Engine, como las plataformas de CPU, los tipos de máquinas, los SSD y las GPU, varían según la región y la zona. Por lo tanto, asegúrate de que los recursos necesarios estén disponibles en una región o una zona antes de restringir el uso a esa región o zona.

Para obtener más información, consulta Detalles y condiciones de la residencia de datos de Compute Engine.

Google Cloud Storage

Puedes almacenar archivos de entrada y salida, instantáneas de discos persistentes y archivos de trabajo temporales en Cloud Storage. Los datos en reposo en los buckets de Cloud Storage permanecen dentro de la región, la región doble o multirregión que seleccionas cuando configuras el bucket. Para obtener más información, consulta la lista actual de ubicaciones de buckets de Cloud Storage.

Para optimizar la disponibilidad, el rendimiento y la eficiencia, puedes usar una región doble de Cloud Storage. Cuando seleccionas esta opción, los datos en el bucket se copian de forma asíncrona en dos regiones específicas, lo que hace que los datos sean redundantes entre regiones. Para obtener más información, consulta Regiones dobles de Cloud Storage.

En el caso del rendimiento y la residencia de datos, usa la misma región para Cloud Storage, Compute Engine y la API de Life Sciences, si es posible.

Para obtener más información, consulta Detalles y condiciones de la residencia de datos de Cloud Storage.

¿Qué sigue?