Cómo administrar entradas grandes

En esta página, se muestra cómo mejorar el rendimiento y reducir los costos cuando se utiliza la herramienta Variant Transforms para cargar cantidades grandes de archivos.

Configuración predeterminada de la herramienta Variant Transforms

Cuando ejecutas la herramienta Variant Transforms, se utiliza la siguiente configuración predeterminada:

Marca Configuración predeterminada
--optimize_for_large_inputs Falso
--max_num_workers Determinado automáticamente
--worker_machine_type n1-standard-1
--disk_size_gb 250
--worker_disk_type DP
--num_bigquery_write_shards 1

Cada una de estas configuraciones puede ajustarse para optimizar el rendimiento de la herramienta. También puedes solicitar la cuota de Compute Engine. A continuación, se incluye una explicación de cada marca:

--optimize_for_large_inputs

Esta marca optimiza la canalización de Cloud Dataflow para entradas grandes, lo que puede reducir los costos significativamente, así como el tiempo de respuesta. Sin embargo, para las entradas pequeñas, la sobrecarga adicional que crea puede aumentar los costos y el tiempo de respuesta.

Configura esta marca como true cuando cargues más de 50,000 archivos o cuando la combinación de variantes esté habilitada para una cantidad grande (más de 3,000 millones) de variantes.

--max_num_workers

Con la configuración predeterminada, Cloud Dataflow utiliza un algoritmo de ajuste de escala automático que elige la cantidad adecuada de instancias de trabajador necesarias para ejecutar el trabajo (limitadas por las cuotas de Compute Engine).

El ajuste de esta marca aumenta la cantidad máxima de trabajadores en el trabajo en el que Cloud Dataflow ajustará la escala automáticamente. También puedes usar la marca --num_workers para especificar la cantidad de trabajadores que se asignan inicialmente al trabajo.

--worker_machine_type

Con la configuración predeterminada, Cloud Dataflow utiliza el tipo de máquina n1-standard-1, que viene con 1 CPU virtual y 3.75 GB de memoria RAM. Si estás cargando una cantidad grande de archivos, es posible que necesites solicitar una máquina más grande. Para obtener información, consulta Tipos de máquinas predefinidos.

Para obtener el mejor rendimiento con Cloud Dataflow, utiliza una cantidad grande de máquinas pequeñas en lugar de una cantidad pequeña de máquinas grandes. Por ejemplo, deberías usar 200 trabajadores n1-standard-4 en lugar de 25 trabajadores n1-standard-32. Esta recomendación se debe a que las operaciones de entrada/salida por segundo (IOPS) de disco y red son limitadas en cada máquina, especialmente si está habilitada la combinación de variantes.

Sin embargo, debido a los límites de cuota en el disco y las direcciones IP, no siempre es posible usar una cantidad grande de trabajadores. En estos casos, utiliza discos SSD (configurados con la marca --worker_disk_type) con una máquina grande (n1-standard-16 o mayor). Esto genera más IOPS de disco y evita los ciclos de CPU inactivos. Dado que el disco es significativamente más económico que la CPU, intenta aumentar el uso de CPU en lugar del uso del disco.

--disk_size_gb

Con la configuración predeterminada, cada trabajador tiene 250 GB de disco. La cantidad total de espacio en el disco para todos los trabajadores debe ser, como mínimo, igual al tamaño de todos los archivos VCF sin comprimir que se van a procesan. Sin embargo, el tamaño de disco recomendado es de tres a cuatro veces más grande que el tamaño de todos los archivos VCF sin comprimir que se van procesan por los siguientes motivos:

  • Las etapas intermedias de la canalización requieren espacio adicional en el disco.
  • Las etapas de transformación tienen una sobrecarga adicional. Por ejemplo, el nombre de muestra se repite en cada registro en la salida de BigQuery, pero se especifica solo una vez en el encabezado de VCF.

Si la combinación de variantes o la marca --num_bigquery_write_shards están habilitadas, es posible que se requiera un tamaño de disco más grande para cada trabajador, ya que las mismas variantes se agregarán juntas en una sola máquina.

--worker_disk_type

Existen dos tipos principales de almacenamiento disponible para las instancias de Compute Engine: estándar y SSD.

Los discos SSD proporcionan significativamente más IOPS que los discos estándares, pero son más caros. Sin embargo, cuando se trabaja con una máquina grande, como n1-standard-16, los discos SSD ofrecen ahorros en los costos. Esto se debe a que los discos SSD pueden evitar ciclos de CPU inactivos debido a sus limitaciones de IOPS.

Utiliza los discos SSD si la combinación de variantes o la marca --num_bigquery_write_shards está habilitada. Estas operaciones reproducen los datos aleatoriamente, lo que requiere cantidades considerables de E/S de disco.

Para utilizar los discos SSD, configura la marca --worker_disk_type en compute.googleapis.com/projects//zones//diskTypes/pd-ssd.

--num_bigquery_write_shards

La canalización de Cloud Dataflow que sustenta la herramienta Variant Transforms escribe datos en BigQuery como un paso de procesamiento posterior después de que se hayan completado las transformaciones principales. BigQuery tiene limitaciones de escritura, por lo que es necesario dividir los datos cuando se los escribe. La fragmentación de datos hace que el proceso de escritura de datos en BigQuery sea mucho más rápido, ya que paraleliza el proceso de escritura y permite cargar conjuntos grandes de datos (superiores a 5 TB) en BigQuery al mismo tiempo.

Cuando se carguen datos que tengan más de 1,000 millones de filas (después de la combinación de variantes) o 1 TB de salida, configura la marca --num_bigquery_write_shards como 20.

Si utilizas una cantidad grande de fragmentos, como 50, el proceso de escritura de datos en BigQuery puede fallar porque hay un límite en el número de escrituras simultáneas para cada tabla de BigQuery.

Cómo solicitar cuotas de Compute Engine

Según la configuración predeterminada, Compute Engine tiene cuotas de recursos para evitar el uso involuntario. Mediante el aumento de las cuotas, puedes iniciar más máquinas virtuales de forma simultánea, lo que aumenta la capacidad de procesamiento y reduce el tiempo de respuesta.

Si cargas una cantidad grande de archivos y la herramienta tiene un rendimiento deficiente o no funciona, puedes solicitar una cuota adicional superior al valor predeterminado de tu proyecto. A continuación, se incluyen algunas recomendaciones para los aumentos de cuota:

  • CPU: 1 por trabajador como mínimo o una cantidad mayor si se utiliza un tipo de máquina más grande.
  • Estándar de disco persistente (GB): 250 GB por trabajador como mínimo o una cantidad mayor si se utiliza un disco más grande.
  • SSD de disco persistente (GB): Solo es necesario si la marca --worker_disk_type está configurada como SSD. El tamaño de cuota recomendado es de 250 GB por trabajador como mínimo o una cantidad mayor si se necesita un disco más grande.
  • Direcciones IP en uso: 1 por trabajador

Ten en cuenta que la cuota de Compute Engine es un límite superior a los recursos disponibles para un trabajo. Por ejemplo, si la cuota para las direcciones IP en uso se establece en 10, pero ejecutas la herramienta con --max_num_workers configurada como 20, el trabajo se ejecutará con solo diez trabajadores, en lugar de 20.

Cómo administrar entradas grandes con el preprocesador

Procesar grandes entradas puede ser costoso y demorar varias horas. Por lo tanto, debes ejecutar el preprocesador en los archivos VCF antes de cargarlos en BigQuery. Así, puedes evitar fallas por registros no válidos y, por lo tanto, reducir los costos y el tiempo de respuesta.

Según la calidad de los archivos de entrada, es posible que tengas que ejecutar el preprocesador con la marca --report_all_conflicts para obtener un informe completo de los archivos. Esta tarea puede demorar más, pero obtendrás un informe más preciso sobre los datos. Este paso es muy recomendable si no estás seguro de la calidad de los archivos de entrada.

Combinación de variantes

Puedes utilizar la combinación de variantes para combinar llamadas en archivos VCF. Existen diferentes opciones de combinación disponibles que puedes especificar; para ello, pasa la marca --variant_merge_strategy.

Con la configuración predeterminada, las llamadas entre los archivos VCF no se combinan. Por ejemplo, si los dos archivos VCF que figuran a continuación estuviesen en el mismo depósito de Cloud Storage, y estuvieras por cargarlos al mismo tiempo (con la marca --input_pattern gs://my-bucket/*.vcf), la herramienta Variant Transforms cargaría dos filas en BigQuery:

gs://my-bucket/a.vcf:

## <headers omitted>
#CHROM  POS   ID    REF   ALT   QUAL  FILTER  INFO    FORMAT  S1      S2
1       100   rs1   A     T     29    PASS    DP=14   GT:GQ   0|1:48  0/0:30

gs://my-bucket/b.vcf:

## <headers omitted>
#CHROM  POS   ID    REF   ALT   QUAL  FILTER  INFO         FORMAT  S3
1       100   rs1   A     T     7     q10     DP=11;AA=G   GT:GQ   1/1:2

A pesar de que todas las llamadas tienen la misma variante, una fila tendría las llamadas S1 y S2, y la otra fila tendría la llamada S3.

Estrategia MOVE_TO_CALLS

La estrategia --variant_merge_strategy MOVE_TO_CALLS combina las llamadas en los archivos que tienen los mismos campos que se indican a continuación:

  • reference_name
  • start_position
  • end_position
  • reference_bases
  • alternate_bases

Con la configuración predeterminada, estos archivos se combinan de la siguiente manera:

  • Las calls se combinan sin un orden en particular.
  • Se elige el valor quality más alto entre las variantes que se combinan.
  • Todos los valores filter se combinan y se anula la duplicación.
  • Todos los names (equivalentes a la columna de ID en la especificación VCF) se combinan y se anula la duplicación.
  • Se elige un campo INFO para representar todo el registro de variantes combinado sin un orden en particular. Para los campos repetidos, se elige un solo conjunto para representar ese campo particular.

Puedes personalizar la estrategia de combinación con las siguientes marcas:

  • --copy_quality_to_calls o --copy_filter_to_calls

    Copia los valores quality o filter en cada archivo en el conjunto de llamadas que se especifica en ese archivo. Esto es útil cuando se combinan archivos VCF de una sola llamada, ya que los valores quality y filter generalmente corresponden al filtro y la calidad del nivel de la llamada. Los valores quality y filter del nivel de la variante se combinarán según la lógica descrita anteriormente.

  • --info_keys_to_move_to_calls_regex REGEX

    Mueve los campos INFO que coincidan con la expresión regular proporcionada a las llamadas asociadas. Esto garantiza que todos los campos INFO se conserven durante la combinación

    Ejemplos:

    • Cuando se especifica --info_keys_to_move_to_calls_regex .*, se mueven todas las claves INFO a las llamadas.
    • Cuando se especifica --info_keys_to_move_to_calls_regex ^(AA|AF)$, solo se mueven los campos AA y AF a las llamadas.

    Si una clave es la misma en los campos INFO y FORMAT, la clave no puede moverse a las llamadas y se producirá un error.

    Consulta Sintaxis de expresión regular para obtener información sobre las especificaciones de expresiones regulares.

Ejemplos

Para ver un ejemplo de cómo se implementa la lógica de combinación, lee el código y la documentación en el archivo move_to_calls_strategy.py en GitHub. Presta especial atención al método get_merged_variants.

En los siguientes ejemplos se muestra el resultado de la combinación de los archivos gs://my-bucket/a.vcf y gs://my-bucket/b.vcf mencionados con anterioridad.

Configuración predeterminada

En el siguiente ejemplo se muestra el resultado de la ejecución de la herramienta Variant Transforms con su configuración predeterminada y la marca --variant_merge_strategy MOVE_TO_CALLS:

reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
  ]
}
DP: 14  # This can also be 11.
AA: "G"

Cómo copiar quality y filter en las llamadas

En el siguiente ejemplo se muestra el resultado de la ejecución de la herramienta Variant Transforms con su configuración predeterminada y las siguientes marcas:

  • --variant_merge_strategy MOVE_TO_CALLS
  • --copy_quality_to_calls
  • --copy_filter_to_calls
reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
    quality: 7
    filter: ["q10"]
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
    quality: 29
    filter: ["PASS"]
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
    quality: 29
    filter: ["PASS"]
  ]
}
DP: 14  # This can also be 11.
AA: "G"

Cómo mover los campos INFO a las llamadas asociadas con una expresión regular

En el siguiente ejemplo se muestra el resultado de la ejecución de la herramienta Variant Transforms con su configuración predeterminada y las siguientes marcas:

  • --variant_merge_strategy MOVE_TO_CALLS
  • --copy_quality_to_calls
  • --copy_filter_to_calls
  • --info_keys_to_move_to_calls_regex ^DP$
reference_name: "1"
start_position: 100
end_position: 101
reference_bases: "A"
alternate_bases: {alt: "T"}
names: ["rs1"]
quality: 29
filter: ["PASS", "q10"]
call: {
  [
    name: "S3",
    genotype: [1, 1]
    phaseset: null
    GQ: 2
    quality: 7
    filter: ["q10"]
    DP: 11
  ],
  [
    name: "S1",
    genotype: [0, 1]
    phaseset: "*"
    GQ: 48
    quality: 29
    filter: ["PASS"]
    DP: 14
  ],
  [
    name: "S2",
    genotype: [0, 0]
    phaseset: null
    GQ: 30
    quality: 29
    filter: ["PASS"]
    DP: 14
  ]
}
AA: "G"
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...