Cette page a été traduite par l'API Cloud Translation.
Switch to English

Traiter un grand nombre d'entrées

Cette page explique comment améliorer vos performances et réduire vos coûts lorsque vous chargez un grand nombre de fichiers à l'aide de l'outil Variant Transforms.

Paramètres par défaut de l'outil Variant Transforms

Lorsque vous exécutez l'outil Variant Transforms, il utilise les paramètres par défaut suivants :

Option Par défaut
--optimize_for_large_inputs False
--max_num_workers Défini automatiquement
--worker_machine_type n1-standard-1
--disk_size_gb 250
--worker_disk_type Disque persistant
--num_bigquery_write_shards 1

Chacun de ces paramètres peut être ajusté pour optimiser les performances de l'outil. Vous pouvez également faire une demande de quota Compute Engine. Vous trouverez une description de chaque option ci-dessous :

--optimize_for_large_inputs

Cette option optimise le pipeline Dataflow pour traiter un grand nombre d'entrées, ce qui peut réduire les coûts et les délais d'exécution de manière significative. En revanche, les petites entrées entraînent une surcharge supplémentaire qui peut augmenter les coûts et les délais d'exécution.

Définissez cette option sur true lorsque vous chargez plus de 50 000 fichiers et/ou que la fusion des variantes est activée pour un grand nombre (plus de trois milliards) de variantes.

--max_num_workers

Par défaut, Dataflow applique un algorithme d'autoscaling qui détermine automatiquement le nombre d'instances de nœuds de calcul requises pour exécuter votre tâche (limité par votre quota Compute Engine).

Vous pouvez ajuster cette option afin d'augmenter le nombre maximal de nœuds de calcul dans la tâche. Dataflow l'utilise ensuite pour effectuer l'autoscaling. Vous pouvez également indiquer le nombre de nœuds de calcul initialement attribués à la tâche à l'aide de l'option --num_workers.

--worker_machine_type

Par défaut, Cloud Dataflow utilise le type de machine n1-standard-1, fourni avec un processeur virtuel et 3,75 Go de RAM. Si vous chargez un grand nombre de fichiers, vous devrez peut-être demander un type de machine avec des caractéristiques plus importantes. Pour en savoir plus, consultez la page présentant les types de machines prédéfinis.

Pour bénéficier de meilleures performances avec Dataflow, utilisez plusieurs petites machines plutôt qu'un faible nombre de grandes machines. Utilisez, par exemple, 200 nœuds de calcul n1-standard-4 plutôt que 25 n1-standard-32. Nous vous recommandons cette pratique, car les opérations d'entrée/sortie par seconde (IOPS) du disque et du réseau sont limitées sur chaque machine, en particulier si la fusion des variantes est activée.

Néanmoins, il n'est pas toujours possible d'utiliser un grand nombre de nœuds de calcul compte tenu de la limite de quota du disque et des adresses IP. Dans ce cas, utilisez des disques SSD (définis à l'aide de l'option --worker_disk_type) avec un type de machine aux caractéristiques plus importantes (n1-standard-16 ou supérieur). Cela permet de générer des IOPS de disque plus élevées et d'éviter les cycles inactifs du processeur. Étant donné que le disque coûte beaucoup moins cher que le processeur, essayez d'optimiser l'utilisation élevée du processeur plutôt que celle du disque.

--disk_size_gb

Chaque nœud de calcul dispose d'une taille de disque de 250 Go par défaut. La quantité totale d'espace disque de tous les nœuds de calcul doit être au minimum égale à la taille non compressée de tous les fichiers VCF en cours de traitement. Cependant, la taille de disque recommandée est trois à quatre fois supérieure à la taille non compressée de tous les fichiers VCF en cours de traitement pour les raisons suivantes :

  • Les étapes intermédiaires du pipeline nécessitent un espace disque supplémentaire.
  • Les étapes de transformation entraînent une surcharge supplémentaire. Par exemple, le nom de l'échantillon est repris dans chaque enregistrement de la sortie BigQuery, mais n'est spécifié qu'une seule fois dans l'en-tête des fichiers VCF.

Si la fusion des variantes ou l'option --num_bigquery_write_shards est activée, une taille de disque plus conséquente peut être requise pour chaque nœud de calcul, car les mêmes variantes sont agrégées sur une seule machine.

--worker_disk_type

Il existe deux principaux types de stockage disponibles pour les instances Compute Engine : standard et SSD.

Les disques SSD fournissent beaucoup plus d'IOPS que les disques standards, mais sont plus coûteux. Ils permettent néanmoins de réaliser des économies lorsque vous utilisez une grande machine, telle que n1-standard-16. En effet, les disques SSD peuvent éviter les cycles inactifs du processeur grâce à leurs limites d'IOPS.

Utilisez des disques SSD si la fusion des variantes ou l'option --num_bigquery_write_shards est activée. Ces opérations brassent les données, ce qui nécessite des quantités importantes d'E/S de disque.

Pour utiliser des disques SSD, définissez l'option --worker_disk_type sur compute.googleapis.com/projects//zones//diskTypes/pd-ssd.

--num_bigquery_write_shards

Le pipeline Dataflow sous-jacent à l'outil Variant Transforms écrit des données dans BigQuery en tant qu'étape de post-traitement, une fois les transformations principales effectuées. Étant donné que BigQuery présente des limites d'écriture, vous devez partitionner les données en cours d'écriture. La partition des données accélère considérablement le processus d'écriture des données dans BigQuery. En effet, elle permet simultanément de réaliser le processus d'écriture et de charger de grands ensembles de données (supérieurs à 5 To) dans BigQuery.

Lorsque vous chargez plus d'un milliard de lignes (après fusion des variantes) ou 1 To de sortie, définissez l'option --num_bigquery_write_shards sur 20.

Si vous utilisez beaucoup de partitions (par exemple, 50), le processus d'écriture des données peut échouer, car le nombre d'écritures simultanées est limité pour chaque table BigQuery.

Demander un quota Compute Engine

Par défaut, Compute Engine a mis en place des quotas de ressources qui permettent d'éviter toute utilisation accidentelle. En augmentant les quotas, vous pouvez lancer plus de machines virtuelles simultanément, ce qui augmente le débit et réduit les délais d'exécution.

Si vous chargez un grand nombre de fichiers et que l'outil ne fonctionne pas bien ou pas du tout, vous pouvez demander un quota supplémentaire par rapport au quota par défaut de votre projet. Voici quelques recommandations pour augmenter les quotas :

  • Processeurs : au moins un par nœud de calcul, plus si vous utilisez un type de machine avec des caractéristiques plus importantes.
  • Disque persistant standard (Go) : au moins 250 Go par nœud de calcul, plus si vous utilisez une taille de disque plus importante.
  • Disque persistant SSD (Go) : nécessaire uniquement si l'option --worker_disk_type est définie sur SSD. Nous vous recommandons de disposer d'un quota d'au moins 250 Go par nœud de calcul, plus si vous utilisez une taille de disque plus importante.
  • Adresses IP en cours d'utilisation : 1 par nœud de calcul.

Notez que le quota de Compute Engine correspond à une limite maximale des ressources disponibles pour une tâche. Par exemple, si le quota d'adresses IP en cours d'utilisation est défini sur 10, mais que vous exécutez l'outil avec l'option --max_num_workers définie sur 20, la tâche n'est exécutée qu'avec 10 nœuds de calcul, au lieu de 20.

Traiter un grand nombre d'entrées à l'aide du préprocesseur

Le traitement d'un grand nombre d'entrées peut être coûteux et peut prendre plusieurs heures. Par conséquent, nous vous conseillons d'exécuter le préprocesseur sur vos fichiers VCF avant de les charger dans BigQuery. Cette opération permet d'éviter les défaillances dues à des enregistrements non valides, et ainsi de réduire les coûts et les délais d'exécution.

Selon la qualité des fichiers d'entrée, vous pouvez exécuter le préprocesseur avec l'option --report_all_conflicts pour obtenir un rapport complet sur les fichiers. Cette opération peut prendre plus de temps, mais fournit un rapport plus précis sur les données. Cette étape est vivement recommandée en cas de doute sur la qualité des fichiers d'entrée.

Fusion de variantes

Vous pouvez activer la fusion des variantes pour fusionner des appels dans les fichiers VCF. Plusieurs types de fusion sont disponibles. Vous pouvez les spécifier en transmettant l'option --variant_merge_strategy.

Les appels entre les fichiers VCF ne sont pas fusionnés par défaut. Par exemple, si les deux fichiers VCF ci-dessous se trouvent dans le même bucket Cloud Storage et que vous devez les charger en même temps (en transmettant l'option --input_pattern gs://my-bucket/*.vcf), l'outil Variant Transforms charge deux lignes dans 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

Même si tous les appels ont la même variante, une ligne peut contenir les appels S1 et S2, et l'autre ligne l'appel S3.

Stratégie MOVE_TO_CALLS

La stratégie --variant_merge_strategy MOVE_TO_CALLS fusionne les appels des fichiers qui disposent des champs suivants :

  • reference_name
  • start_position
  • end_position
  • reference_bases
  • alternate_bases

Par défaut, ces champs sont fusionnés comme suit :

  • Les appels calls sont fusionnés sans ordre particulier.
  • La valeur la plus élevée de quality est choisie parmi les variantes en cours de fusion.
  • Toutes les valeurs filter sont fusionnées et les doublons sont éliminés.
  • Tous les champs names (équivalents à la colonne ID dans la spécification VCF) sont fusionnés et les doublons sont éliminés.
  • Un champ INFO est choisi pour représenter l'intégralité de l'enregistrement des variantes fusionné, sans ordre particulier. Un seul ensemble est choisi pour représenter les champs répétés.

Vous pouvez personnaliser la stratégie de fusion à l'aide des options suivantes :

  • --copy_quality_to_calls et/ou --copy_filter_to_calls

    Copie les valeurs quality et/ou filter de chaque fichier dans l'ensemble des appels spécifiés dans ce fichier. Ces options sont utiles lors de la fusion de fichiers VCF en un seul appel, car les valeurs quality et filter correspondent généralement à la qualité et au filtre définis au niveau de l'appel. Les valeurs quality et filter définies au niveau de la variante continuent d'être fusionnées conformément à la logique décrite ci-dessus.

  • --info_keys_to_move_to_calls_regex REGEX

    Déplace les champs INFO correspondant à l'expression régulière fournie vers les appels associés. Cela permet de s'assurer que tous les champs INFO sont conservés lors de la fusion.

    Exemples :

    • Définir l'option --info_keys_to_move_to_calls_regex .* pour qu'elle déplace toutes les clés INFO vers les appels
    • Définir l'option --info_keys_to_move_to_calls_regex ^(AA|AF)$ pour qu'elle déplace uniquement les champs AA et AF vers les appels

    Si la clé des champs INFO et FORMAT est identique, elle ne peut pas être déplacée vers les appels et une erreur est générée.

    Pour en savoir plus sur les spécifications des expressions régulières, consultez la page Syntaxe des expressions régulières.

Exemples

Pour consulter un exemple d'application de la logique de fusion, lisez le code et la documentation dans le fichier move_to_calls_strategy.py sur GitHub. Retenez en particulier la méthode get_merged_variants.

Les exemples suivants montrent le résultat de la fusion des fichiers gs://my-bucket/a.vcf et gs://my-bucket/b.vcf ci-dessus.

Paramètres par défaut

L'exemple suivant montre le résultat de l'exécution de l'outil Variant Transforms avec ses paramètres par défaut et l'option --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"

Copier les valeurs quality et filter dans les appels

L'exemple suivant montre le résultat de l'exécution de l'outil Variant Transforms avec ses paramètres par défaut et les options suivantes :

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

Déplacer les champs INFO vers les appels associés avec une expression régulière

L'exemple suivant montre le résultat de l'exécution de l'outil Variant Transforms avec ses paramètres par défaut et les options suivantes :

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