Administración de 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 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 gran cantidad de variantes (más de 3,000 millones).

--max_num_workers

De forma predeterminada, Dataflow usa un algoritmo de ajuste de escala automático que elige la cantidad adecuada de instancias de trabajador necesarias para ejecutar el trabajo (limitadas por tus cuotas de Compute Engine).

Si modificas esta marca, aumenta la cantidad máxima de trabajadores en el trabajo a la que Dataflow puede realizar un ajuste de escala automático. También puedes usar la marca --num_workers para especificar la cantidad de trabajadores que se asignan inicialmente al trabajo.

--worker_machine_type

De forma predeterminada, Dataflow usa el tipo de máquina n1-standard-1, que viene con 1 CPU virtual y 3.75 GB de RAM. Si vas a cargar una gran cantidad de archivos, es posible que debas solicitar una máquina más grande. Para obtener información, consulta Tipos predefinidos de máquinas.

Para obtener el mejor rendimiento con Dataflow, utiliza una cantidad grande de máquinas pequeñas en lugar de una cantidad pequeña de máquinas grandes. Por ejemplo, es mejor usar 200 trabajadores n1-standard-4 que 25 trabajadores n1-standard-32. El motivo de esta recomendación es que cada máquina admite una cantidad limitada de operaciones de entrada/salida por segundo (IOPS) de disco y red, 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, usa SSD (con la marca --worker_disk_type) y una máquina grande (n1-standard-16 o mayor). De esta manera, obtienes más IOPS de disco y evitas 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.

Usa SSD si se habilita la combinación de variantes o la marca --num_bigquery_write_shards. Estas operaciones redistribuyen los datos, lo que requiere cantidades considerables de E/S de disco.

Para usar SSD, establece la marca --worker_disk_type en compute.googleapis.com/projects//zones//diskTypes/pd-ssd.

--num_bigquery_write_shards

La canalización de 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 cargues datos que tengan más de mil millones de filas (después de la combinación de variantes) o 1 TB de salida, configura la marca --num_bigquery_write_shards en 20.

Si utilizas una cantidad grande de fragmentos, como 50, el proceso de escritura de datos en BigQuery puede fallar, ya que se admite una cantidad limitada de escrituras simultáneas por cada tabla de BigQuery.

Cómo solicitar cuota de Compute Engine

Según la configuración predeterminada, Compute Engine tiene cuotas de recursos para evitar el uso involuntario. Puedes aumentar las cuotas para iniciar más máquinas virtuales de forma simultánea y así incrementar la capacidad de procesamiento y reducir 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 configurado en 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, tal vez sea conveniente ejecutar el preprocesador con la marca --report_all_conflicts para obtener un informe completo de los archivos. Este paso puede requerir tiempo adicional, pero te brinda 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 cuando pasas la marca --variant_merge_strategy.

Según la configuración predeterminada, las llamadas entre los archivos VCF no se combinan. Por ejemplo, si los dos archivos VCF que aparecen a continuación estuvieran en el mismo depósito de Cloud Storage y los cargaras 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 a continuación:

  • reference_name
  • start_position
  • end_position
  • reference_bases
  • alternate_bases

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

  • calls se combinan sin un orden en particular.
  • Se elige el valor de 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. Cuando hay campos repetidos, se elige un solo conjunto que los represente.

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 de cada archivo en el conjunto de llamadas especificadas en ese archivo. Esto es útil cuando se combinan archivos VCF de llamada única, 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 variante se combinarán de acuerdo con 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 a las llamadas los campos AA y AF.

    Si una clave se repite en los campos INFO y FORMAT, esta no puede moverse a las llamadas y se produce un error.

    Consulta la sintaxis de las expresiones regulares para conocer las especificaciones correspondientes.

Ejemplos

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

Los siguientes ejemplos muestran el resultado de la combinación de los archivos gs://my-bucket/a.vcf y gs://my-bucket/b.vcf anteriores.

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 a 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"