Esta página foi traduzida pela API Cloud Translation.
Switch to English

Como processar entradas grandes

Nesta página, você aprende a melhorar o desempenho e reduzir custos usando a ferramenta Variant Transforms para carregar um número grande de arquivos.

Configurações padrão da ferramenta Variant Transforms

Quando você executa a ferramenta Variant Transforms, ela usa as seguintes configurações padrão:

Sinalização Padrão
--optimize_for_large_inputs Falso
--max_num_workers Determinado automaticamente
--worker_machine_type n1-standard-1
--disk_size_gb 250
--worker_disk_type PD
--num_bigquery_write_shards 1

Cada uma dessas configurações pode ser ajustada para otimizar o desempenho da ferramenta. Também é possível solicitar uma cota do Compute Engine. Veja abaixo a explicação de cada sinalização:

--optimize_for_large_inputs

Essa sinalização otimiza o pipeline do Dataflow para entradas grandes, o que pode diminuir bastante os custos e reduzir o tempo de resposta. No entanto, para entradas pequenas, a sobrecarga criada pode aumentar os custos e o tempo de retorno.

Defina essa sinalização como true quando você estiver carregando mais de 50.000 arquivos e/ou a mesclagem de variantes estiver habilitada para um grande número (mais de 3 bilhões) de variantes.

--max_num_workers

Por padrão, o Dataflow usa um algoritmo de escalonamento automático que escolhe o número apropriado de instâncias de worker necessárias para executar o job (limitado pela cota do Compute Engine).

Ajustar essa sinalização aumenta o número máximo de workers no job em que o Dataflow será escalonado automaticamente. Também é possível usar a sinalização --num_workers para especificar o número de workers atribuídos inicialmente ao job.

--worker_machine_type

Por padrão, o Dataflow usa o tipo de máquina n1-standard-1, que vem com 1 vCPU e 3,75 GB de RAM. Se você estiver carregando um grande número de arquivos, talvez precise solicitar uma máquina maior. Para mais detalhes, consulte Tipos de máquina predefinidos.

Para ter o melhor desempenho com o Dataflow, use várias máquinas pequenas em vez de poucas máquinas grandes. Por exemplo, use 200 workers n1-standard-4 em vez de 25 workers n1-standard-32. Essa recomendação se deve ao fato de as operações de entrada/saída por segundo (IOPS, na sigla em inglês), tanto de disco quanto de rede, serem limitadas em cada máquina, principalmente se a mesclagem de variantesestiver ativada.

No entanto, devido aos limites de cota em disco e endereços IP, nem sempre é possível usar um número grande de workers. Nesses casos, use SSDs (definidos com a sinalização --worker_disk_type) com uma máquina grande (n1-standard-16 ou maior). Isso gera IOPS de disco maiores e evita ciclos de CPU ociosa. Como o disco é significativamente mais barato que a CPU, tente otimizar tendo em vista a alta utilização da CPU em vez do uso do disco.

--disk_size_gb

Por padrão, cada worker tem 250 GB de tamanho de disco. A quantidade total de espaço em disco para todos os workers precisa ser, no mínimo, tão grande quanto o tamanho descompactado de todos os arquivos VCF que estão sendo processados. No entanto, o tamanho de disco recomendado é de três a quatro vezes maior que o tamanho descompactado de todos os arquivos VCF que estão sendo processados. Isso se deve aos seguintes motivos:

  • Os estágios intermediários do pipeline exigem mais espaço em disco.
  • Os estágios de transformação têm sobrecarga extra. Por exemplo, o nome de amostra é repetido em cada registro na saída do BigQuery, mas é especificado apenas uma vez no cabeçalho do VCF.

Se a mesclagem de variantes ou a sinalização --num_bigquery_write_shards forem ativadas, um tamanho de disco maior pode ser necessário para cada worker porque as mesmas variantes serão agregadas em uma única máquina.

--worker_disk_type

Há dois tipos principais de armazenamento disponíveis para instâncias do Compute Engine: padrão e SSD.

Os SSDs oferecem bem mais IOPS que discos padrão, mas são mais caros. No entanto, ao trabalhar com uma máquina grande, como n1-standard-16, os SSDs são econômicos. Isso acontece porque a limitação de IOPS dos SSDs pode evitar ciclos de CPU ociosa.

Use SSDs se a mesclagem de variantes ou a sinalização --num_bigquery_write_shards estiverem ativadas. Essas operações embaralham dados, o que requer quantidades significativas de E/S de disco.

Para usar SSDs, defina a sinalização --worker_disk_type como compute.googleapis.com/projects//zones//diskTypes/pd-ssd.

--num_bigquery_write_shards

O pipeline do Dataflow que serve de base para a ferramenta Variant Transforms grava dados no BigQuery como uma etapa de pós-processamento, depois que as principais transformações são concluídas. O BigQuery tem limitações de gravação. Portanto, é necessário fragmentar os dados quando eles estão sendo gravados. A fragmentação de dados torna o processo de gravação no BigQuery muito mais rápido, porque ela realiza o processo de gravação em paralelo e permite o carregamento de conjuntos grandes de dados (maiores que 5 TB) no BigQuery de uma só vez.

Ao carregar dados que tenham mais de um bilhão de linhas (após a mesclagem de variante) ou 1 TB de saída, defina a sinalização --num_bigquery_write_shards como 20.

Se você estiver usando um grande número de fragmentos, como 50, pode haver uma falha no processo de gravação de dados no BigQuery porque há um limite no número de gravações simultâneas para cada tabela do BigQuery.

Como solicitar uma cota do Compute Engine

Por padrão, o Compute Engine tem cotas de recursos para impedir o uso não intencional. Ao aumentar as cotas, inicie mais máquinas virtuais simultaneamente, aumentando a capacidade e reduzindo o tempo de retorno.

Se você estiver carregando um número grande de arquivos e a ferramenta estiver com desempenho ruim ou não estiver funcionando, solicite uma cota extra acima do padrão do seu projeto. Algumas recomendações para aumento de cotas:

  • CPUs: no mínimo uma por worker, mais se for usado um tipo de máquina maior.
  • Padrão de disco permanente (GB): pelo menos 250 GB por worker, mais se for usado um disco maior.
  • SSD de disco permanente (GB): necessário somente se a sinalização --worker_disk_type estiver definida como SSD. O tamanho de cota recomendado é de pelo menos 250 GB por worker, mais se for usado um disco maior.
  • Endereços IP em uso: um por worker.

A cota do Compute Engine é um limite superior dos recursos disponíveis para um job. Por exemplo, se a cota de endereços IP em uso for definida como 10, mas você executar a ferramenta com --max_num_workers definido como 20, o job será executado com apenas 10 workers, em vez de 20.

Como lidar com entradas grandes com a ferramenta de pré-processador

O processamento de entradas grandes pode ser caro e levar várias horas. Portanto, execute a ferramenta de pré-processador em arquivos VCF antes de carregá-los no BigQuery. Isso pode evitar falhas devido a registros inválidos e, portanto, reduzir custos e tempo de resposta.

Dependendo da qualidade dos arquivos de entrada, execute a ferramenta de pré-processador com a sinalização --report_all_conflicts para receber um relatório completo dos arquivos. Isso pode levar mais tempo, mas fornece um relatório mais preciso sobre os dados. Essa etapa é altamente recomendada se você não tiver certeza sobre a qualidade dos arquivos de entrada.

Mesclagem de variantes

Use a mesclagem de variantes para mesclar chamadas em arquivos VCF. Há diferentes opções de mesclagem disponíveis que podem ser especificadas transmitindo a sinalização --variant_merge_strategy.

Por padrão, as chamadas entre arquivos VCF não são mescladas. Por exemplo, se os dois arquivos VCF abaixo estivessem no mesmo bucket do Cloud Storage e você os carregasse ao mesmo tempo (transmitindo a sinalização --input_pattern gs://my-bucket/*.vcf), a ferramenta Variant Transforms carregaria duas linhas no 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

Mesmo que todas as chamadas tenham a mesma variante, uma linha teria chamadas S1 e S2, enquanto a outra linha teria a chamada S3.

Estratégia MOVE_TO_CALLS

A estratégia --variant_merge_strategy MOVE_TO_CALLS mescla chamadas de todos os arquivos que têm os mesmos campos a seguir:

  • reference_name
  • start_position
  • end_position
  • reference_bases
  • alternate_bases

Por padrão, esses campos são mesclados da seguinte maneira:

  • calls são mescladas sem uma ordem específica.
  • O valor quality mais alto é escolhido entre as variantes que estão sendo mescladas.
  • Todos os valores filter são mesclados e as respectivas duplicações são eliminadas.
  • Todos os names (equivalentes à coluna ID na especificação VCF) são mesclados e as respectivas duplicações são eliminadas.
  • Um campo INFO é escolhido para representar todo o registro de variantes mescladas, sem uma ordem específica. Para campos repetidos, um único conjunto é escolhido para representar esse campo específico.

É possível personalizar a estratégia de mesclagem com as seguintes sinalizações:

  • --copy_quality_to_calls e/ou --copy_filter_to_calls

    Copia os valores quality e/ou filter em cada arquivo para o conjunto de chamadas especificado nesse arquivo. Isso é útil ao mesclar arquivos VCF de chamada única porque os valores quality e filter normalmente correspondem à qualidade e ao filtro no nível da chamada. Os valores quality e filter no nível da variante ainda serão mesclados de acordo com a lógica descrita acima.

  • --info_keys_to_move_to_calls_regex REGEX

    Move os campos INFO que correspondem à expressão regular fornecida para as chamadas associadas. Isso garante que todos os campos INFO sejam mantidos durante a mesclagem.

    Exemplos:

    • Especificar --info_keys_to_move_to_calls_regex .* move todas as chaves INFO para chamadas.
    • Especificar --info_keys_to_move_to_calls_regex ^(AA|AF)$ move somente os campos AA e AF para chamadas.

    Se uma chave for a mesma nos campos INFO e FORMAT, ela não poderá ser movida para chamadas e ocorrerá um erro.

    Consulte Sintaxe de expressão regular para saber detalhes sobre especificações de expressões regulares.

Exemplos

Para ver um exemplo de como a lógica de mesclagem é implementada, leia o código e a documentação no arquivo move_to_calls_strategy.py (em inglês) no GitHub. Observe, em particular, o método get_merged_variants (em inglês).

Os exemplos a seguir mostram o resultado da mesclagem dos arquivos gs://my-bucket/a.vcf e gs://my-bucket/b.vcf acima.

Configurações padrão

O exemplo a seguir mostra a saída da execução da ferramenta Variant Transforms com suas configurações padrão e a sinalização --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"

Como copiar quality e filter para chamadas

O exemplo a seguir mostra a saída da execução da ferramenta Variant Transforms com configurações padrão e as seguintes sinalizações:

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

Como mover campos INFO para chamadas associadas com uma expressão regular

O exemplo a seguir mostra a saída da execução da ferramenta Variant Transforms com configurações padrão e as seguintes sinalizações:

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