View a markdown version of this page

HealthOmics ETags et provenance des données - AWS HealthOmics
Étiquettes électroniques Amazon S3Comment HealthOmics calcule les ETags

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

HealthOmics ETags et provenance des données

Un HealthOmics ETag (étiquette d'entité) est un hachage du contenu ingéré dans un magasin de séquences. Cela simplifie la récupération et le traitement des données tout en préservant l'intégrité du contenu des fichiers de données ingérés. L'ETag reflète les modifications apportées au contenu sémantique de l'objet, et non à ses métadonnées. Le type d'ensemble de lecture et l'algorithme spécifiés déterminent le mode de calcul de l'ETag. Le calcul de l'ETag ne modifie pas le fichier réel ni les données génomiques. Lorsque le schéma de type de fichier de l'ensemble de lecture le permet, le magasin de séquences met à jour les champs liés à la provenance des données.

Les fichiers ont une identité binaire et une identité sémantique. L'identité binaire signifie que les bits d'un fichier sont identiques, et l'identité sémantique signifie que le contenu d'un fichier est identique. L'identité sémantique résiste aux modifications des métadonnées et aux modifications de compression car elle capture l'intégrité du contenu du fichier.

Les ensembles de lecture placés dans des magasins de HealthOmics séquences sont soumis à compression/decompression des cycles et à un suivi de la provenance des données tout au long du cycle de vie d'un objet. Au cours de ce traitement, l'identité binaire d'un fichier ingéré peut changer et devrait changer chaque fois qu'un fichier est activé ; toutefois, l'identité sémantique du fichier est conservée. L'identité sémantique est capturée sous la forme d'une étiquette d' HealthOmics entité, ou ETag, calculée lors de l'ingestion du magasin de séquences et disponible sous forme de métadonnées d'ensemble de lectures.

Lorsque le schéma de type de fichier de l'ensemble de lecture le permet, les champs de mise à jour du magasin de séquences sont liés à la provenance des données. Pour les fichiers uBam, BAM et CRAM, une nouvelle Comment balise @CO or est ajoutée à l'en-tête. Le commentaire contient l'identifiant du magasin de séquences et l'horodatage d'ingestion.

Étiquettes électroniques Amazon S3

Lorsque vous accédez à un fichier à l'aide de l'URI Amazon S3, les opérations de l'API Amazon S3 peuvent également renvoyer des valeurs d'eTag et de somme de contrôle Amazon S3. Les valeurs de l'ETag et de la somme de contrôle d'Amazon S3 sont différentes des HealthOmics ETags car elles représentent l'identité bit à bit du fichier. Pour en savoir plus sur les métadonnées descriptives et les objets, consultez la documentation de l'API Amazon S3 Object. Les valeurs ETag d'Amazon S3 peuvent changer à chaque cycle d'activation d'un ensemble de lecture et vous pouvez les utiliser pour valider la lecture d'un fichier. Cependant, ne mettez pas en cache les valeurs ETag d'Amazon S3 pour les utiliser pour la validation de l'identité du fichier pendant le cycle de vie du fichier, car elles ne restent pas cohérentes. En revanche, l' HealthOmics ETag reste cohérent tout au long du cycle de vie du jeu de lecture.

Comment HealthOmics calcule les ETags

L'ETag est généré à partir d'un hachage du contenu du fichier ingéré. La famille d'algorithmes ETag est définie sur MD5up par défaut, mais elle peut être configurée différemment lors de la création du magasin de séquences. Lorsque l'ETag est calculé, l'algorithme et les hachages calculés sont ajoutés au jeu de lecture. Les algorithmes MD5 pris en charge pour les types de fichiers sont les suivants.

  • FastQ_MD5up — Calcule le hachage MD5 d'une source de jeu de lecture FASTQ complète et non compressée.

  • BAM_MD5up — Calcule le hachage MD5 de la section d'alignement d'un ensemble de lecture BAM ou UbAM non compressé tel que représenté dans le SAM, sur la base de la référence liée, le cas échéant.

  • Cram_MD5up — Calcule le hachage MD5 de la section d'alignement du jeu de lecture CRAM non compressé tel que représenté dans le SAM, sur la base de la référence liée.

Note

Le hachage MD5 est connu pour être vulnérable aux collisions. De ce fait, deux fichiers différents peuvent avoir le même ETag s'ils ont été fabriqués pour exploiter la collision connue.

Les algorithmes suivants sont pris en charge pour la famille SHA256. Les algorithmes sont calculés comme suit :

  • FastQ_SHA256up — Calcule le SHA-256 hachage d'une source de jeu de lecture FASTQ complète et non compressée.

  • BAM_SHA256up — Calcule le SHA-256 hachage de la section d'alignement d'un ensemble de lecture BAM ou UbAM non compressé tel que représenté dans le SAM, sur la base de la référence liée, le cas échéant.

  • CRAM_Sha256up — Calcule le SHA-256 hachage de la section d'alignement d'une source de jeu de lecture CRAM non compressée telle que représentée dans le SAM, en fonction de la référence liée.

Les algorithmes suivants sont pris en charge pour la famille SHA512. Les algorithmes sont calculés comme suit :

  • FastQ_SHA512up — Calcule le SHA-512 hachage d'une source de jeu de lecture FASTQ complète et non compressée.

  • BAM_SHA512up — Calcule le SHA-512 hachage de la section d'alignement d'une source d'ensembles de lecture BAM ou UbAM non compressée telle que représentée dans le SAM, sur la base de la référence liée, le cas échéant.

  • CRAM_Sha512up — Calcule le SHA-512 hachage de la section d'alignement d'une source de jeu de lecture CRAM non compressée telle que représentée dans le SAM, sur la base de la référence liée.