基因组工作流程，第4部分：处理档案数据 架构博客

基因组工作流：处理存档数据

关键要点

基因组工作流程能够处理 PB 级别的数据。在处理完成后，数据通常被存档到冷存储类别中。在某些情况下，例如对 DNA 变异与大型数据集之间关联的研究，存档数据在后续处理时是必需的。这意味着需要手动启动每个存档对象的恢复并监控进度。科学家们需要一种可靠的按需存档数据恢复流程，以确保他们的工作流程不会失败。

在本系列的第 4 部分中，我们将探讨处理存档数据的基因组负载以及如何利用 Amazon Simple Storage Service (Amazon S3) 设计可靠的数据恢复流程。当数据可用时，该流程将通知工作流以便继续前进。我们基于第 13 部分中所提出的设计模式，通过采用事件驱动和无服务器的原则，提供最具成本效益的解决方案。

使用案例

我们的使用案例侧重于存放在 Amazon Simple Storage Service Glacier (Amazon S3 Glacier) 上的数据存储类别。S3 Glacier Instant Retrieval 存储类别为长期保存但很少访问的数据提供最低成本的存储，同时支持毫秒级的检索。

S3 Glacier Flexible Retrieval 和 S3 Glacier Deep Archive 提供了进一步的成本节省，检索时间从几分钟到几小时不等。我们重点关注后者，以便提供最具成本效益的解决方案。

您必须在访问之前先恢复对象。我们的基因组工作流程将在数据恢复完成之前暂停。该工作流程的要求包括：

解决方案概述

基因组工作流程需要多个输入参数来准备启动，例如启动 ID、数据路径、工作流端点和工作流步骤。我们将这些数据包括工作流配置存储在 S3 存储桶中。一项 AWS Fargate 任务读取该 S3 存储桶中的数据并准备工作流程。它检测输入参数是否包含 S3 Glacier 的 URL。

我们使用 Amazon Simple Queue Service (Amazon SQS) 将 S3 Glacier 索引创建与对象恢复操作进行解耦见图 1。这提高了我们流程的可靠性。

图 1 S3 Glacier 对象恢复的解决方案架构

一个 AWS Lambda 函数会在指定的 S3 存储桶 URL 中创建所有对象的索引，并将其提交为 SQS 消息。

另一个 Lambda 函数轮询 SQS 队列并提交请求来恢复 S3 Glacier 对象至 S3 Standard 存储类别。

该函数将每个 S3 Glacier 恢复请求的作业 ID 写入 Amazon DynamoDB。恢复完成后，Lambda 将工作流的状态设置为 READY。只有在此之后，计算作业如使用 AWS Batch才能开始。

实施考虑

我们考虑使用 Snakemake 和 Tibanna 的使用案例，这在本系列的 Part 2 中进行了详细说明。这使我们能够深入了解启动细节。

Snakemake 是一个开源工具，适用于以 有向无环图 格式进行全基因组序列映射。Snakemake 使用 Snakefiles 声明工作流步骤和命令。Tibanna 是一个开源的、AWS 原生软件，运行生物信息学数据管道。它支持 Snakefile 语法，以及其他工作流语言，包括 Common Workflow Language 和 Workflow Description Language (WDL)。

如果您的使用案例不需要 Tibanna，建议使用 Amazon Genomics CLI 或者如果您的工作流定义符合支持的 WDL 和 Nextflow 规格，则可以使用 Amazon Omics。

制定恢复请求

Snakemake Fargate 启动容器会检测请求的 S3 存储桶下的对象是否存储在 S3 Glacier 中。该容器生成并将一个 JSON 二进制基本调用 (BCL) 配置文件放入 S3 存储桶中并成功退出。此文件包括工作流的启动 ID，与 DynamoDB 项目密钥对应，以及要恢复的 S3 URL。

查询 S3 URL

一旦 JSON BCL 配置文件到达该 S3 存储桶，S3 事件通知 PutObject 事件会触发一个 Lambda 函数。该函数解析配置文件并递归查询所有需要恢复的 S3 对象 URL。

启动恢复

主 Lambda 函数随后向 SQS 队列提交消息，其中包含需要恢复的所有 S3 URL 的完整列表。SQS 消息还包括工作流的启动 ID，以确保我们可以将具体的恢复作业与特定的工作流启动绑定。如果所有 S3 Glacier 对象属于 Flexible Retrieval 存储类别，Lambda 函数会将 URL 放入单个 SQS 消息中，以便通过 Bulk Glacier Job Tier 进行恢复。Lambda 函数还在相应的 DynamoDB 项中将工作流的状态设置为 WAITING。WAITING 状态用于通知最终用户作业正在等待数据恢复处理，一旦数据恢复完成将继续进行。

一个辅助的 Lambda 函数会轮询新的 SQS 消息。该 Lambda 函数提交恢复请求，例如，使用 RestoreObject API 提交免费的大宗检索。该函数随后将每个请求的 S3 Glacier 作业 ID 写入我们的 DynamoDB 表。这使得主 Lambda 函数能够检查与工作流启动 ID 相关联的所有作业 ID 是否已完成。

更新状态

在 Glacier 对象恢复未完成时，我们的工作流启动状态将保持 WAITING。已完成的 S3 Glacier 作业 ID 的 AWS CloudTrail 日志 会通过 Amazon EventBridge 规则 触发我们的主 Lambda 函数，以更新在 DynamoDB 表中恢复作业的状态。每次调用时，函数会检查与工作流启动 ID 相关联的所有作业 ID 是否完成。

在所有对象均已恢复后，函数会将工作流启动更新为状态 READY。这将启动与恢复之前相同的启动 ID 的工作流。

结论

在本博文中，我们展示了生命科学研究团队如何利用其存档数据进行基因组研究。我们设计了一个基于事件驱动的 S3 Glacier 恢复过程，以便在请求时检索数据。我们讨论了如何可靠地启动恢复以避免工作流失败。此外，我们还在前期判断是否需要 S3 Glacier 的恢复，并使用 WAITING 状态来防止工作流失败。

通过这个解决方案，生命科学研究团队可以使用 Amazon S3 Glacier 节省成本，而无需担心日常工作或手动管理 S3 Glacier 对象的恢复。

相关信息

标签 基因组学

作者介绍

Rostislav MarkovRostislav 是 AWS 专业服务的首席架构师。作为 AWS 行业的技术领导，他与 AWS 客户和合作伙伴合作推进他们的云转型项目。在工作之余，他喜欢与家人一起享受户外活动、打网球和滑雪。

Matt NoyceMatt Noyce 是一名高级应用架构师，专注于 AWS 专业服务中的医疗保健和生命科学客户。他与客户合作，构建、设计满足其业务需求的解决方案。在空闲时间，Matt 喜欢跑步、远足和探索新城市及地点。