基因组工作流程，第4部分处理档案数据
基因组工作流：处理存档数据
关键要点
- 本文探讨了如何处理存档基因组数据，以便于进一步分析。
- 介绍了一种基于事件驱动和无服务器架构的可靠数据恢复过程。
- 重点在于利用 Amazon S3 Glacier 提供成本效益高的存储解决方案。
- 详细讨论了恢复请求的生成、查询和状态更新的过程。
基因组工作流程能够处理 PB 级别的数据。在处理完成后，数据通常被存档到冷存储类别中。在某些情况下，例如对 DNA变异与大型数据集之间关联的研究，存档数据在后续处理时是必需的。这意味着需要手动启动每个存档对象的恢复并监控进度。科学家们需要一种可靠的按需存档数据恢复流程，以确保他们的工作流程不会失败。
在本系列的第 4 部分中，我们将探讨处理存档数据的基因组负载以及如何利用 Amazon Simple Storage Service (AmazonS3) 设计可靠的数据恢复流程。当数据可用时，该流程将通知工作流以便继续前进。我们基于第 1-3部分中所提出的设计模式，通过采用事件驱动和无服务器的原则，提供最具成本效益的解决方案。
使用案例
我们的使用案例侧重于存放在 Amazon Simple Storage Service Glacier (Amazon S3Glacier) 上的数据存储类别。S3 Glacier Instant Retrieval 存储类别为长期保存但很少访问的数据提供最低成本的存储，同时支持毫秒级的检索。
和 提供了进一步的成本节省，检索时间从几分钟到几小时不等。我们重点关注后者，以便提供最具成本效益的解决方案。
您必须在访问之前先恢复对象。我们的基因组工作流程将在数据恢复完成之前暂停。该工作流程的要求包括：
- 可靠启动恢复，以避免因为 或未恢复所有对象而导致工作流失败。
- 事件驱动的设计，以反映基因组工作流程的事件驱动性质，在请求时执行检索。
- 成本有效且易于管理，利用无服务器服务实现。
- 在形成基因组工作流任务时提前检测存档数据，避免产生计算任务造成费用消耗。
- 可扩展和弹性以满足大规模存档数据集的恢复需求。
解决方案概述
基因组工作流程需要多个输入参数来准备启动，例如启动 ID、数据路径、工作流端点和工作流步骤。我们将这些数据（包括工作流配置）存储在 S3 存储桶中。一项 任务读取该 S3 存储桶中的数据并准备工作流程。它检测输入参数是否包含 S3 Glacier 的 URL。
我们使用 Amazon Simple Queue Service (Amazon SQS) 将 S3 Glacier 索引创建与对象恢复操作进行解耦（见图 1）。这提高了我们流程的可靠性。
图 1. S3 Glacier 对象恢复的解决方案架构
一个 函数会在指定的 中创建所有对象的索引，并将其提交为 SQS 消息。
另一个 Lambda 函数轮询 SQS 队列并提交请求来恢复 S3 Glacier 对象至 。
该函数将每个 S3 Glacier 恢复请求的作业 ID 写入 。恢复完成后，Lambda将工作流的状态设置为 READY 。只有在此之后，计算作业（如使用 ）才能开始。
实施考虑
我们考虑使用 和 的使用案例，这在本系列的 中进行了详细说明。这使我们能够深入了解启动细节。
Snakemake 是一个开源工具，适用于以 00240-7/fulltext) 格式进行全基因组序列映射。Snakemake 使用
声明工作流步骤和命令。Tibanna 是一个开源的、AWS 原生软件，运行生物信息学数据管道。它支持 Snakefile 语法，以及其他工作流语言，包括 和 Workflow DescriptionLanguage (WDL)。
如果您的使用案例不需要 Tibanna，建议使用 或者如果您的工作流定义符合支持的 WDL 和 规格，则可以使用 。
制定恢复请求
Snakemake Fargate 启动容器会检测请求的 S3 存储桶下的对象是否存储在 S3 Glacier 中。该容器生成并将一个 JSON 二进制基本调用 (BCL) 配置文件放入 S3存储桶中并成功退出。此文件包括工作流的启动 ID，与 DynamoDB 项目密钥对应，以及要恢复的 S3 URL。
查询 S3 URL
一旦 JSON BCL 配置文件到达该 S3 存储桶，
事件会触发一个 Lambda 函数。该函数解析配置文件并递归查询所有需要恢复的 S3 对象 URL。
启动恢复
主 Lambda 函数随后向 SQS 队列提交消息，其中包含需要恢复的所有 S3 URL 的完整列表。SQS 消息还包括工作流的启动 ID，以确保我们可以将具体的恢复作业与特定的工作流启动绑定。如果所有 S3 Glacier 对象属于 ，Lambda 函数会将 URL 放入单个 SQS 消息中，以便通过 进行恢复。Lambda 函数还在相应的 DynamoDB 项中将工作流的状态设置为 WAITING。WAITING 状态用于通知最终用户作业正在等待数据恢复处理，一旦数据恢复完成将继续进行。
一个辅助的 Lambda 函数会轮询新的 SQS 消息。该 Lambda 函数提交恢复请求，例如，使用
API 提交免费的大宗检索。该函数随后将每个请求的 S3 Glacier 作业 ID 写入我们的 DynamoDB 表。这使得主 Lambda函数能够检查与工作流启动 ID 相关联的所有作业 ID 是否已完成。
更新状态
在 Glacier 对象恢复未完成时，我们的工作流启动状态将保持 WAITING 。已完成的 S3 Glacier 作业 ID 的 AWSCloudTrail 会通过 触发我们的主 Lambda 函数，以更新在 DynamoDB 表中恢复作业的状态。每次调用时，函数会检查与工作流启动 ID 相关联的所有作业 ID是否完成。
在所有对象均已恢复后，函数会将工作流启动更新为状态 READY 。这将启动与恢复之前相同的启动 ID 的工作流。
结论
在本博文中，我们展示了生命科学研究团队如何利用其存档数据进行基因组研究。我们设计了一个基于事件驱动的 S3 Glacier恢复过程，以便在请求时检索数据。我们讨论了如何可靠地启动恢复以避免工作流失败。此外，我们还在前期判断是否需要 S3 Glacier 的恢复，并使用 WAITING 状态来防止工作流失败。
通过这个解决方案，生命科学研究团队可以使用 Amazon S3 Glacier 节省成本，而无需担心日常工作或手动管理 S3 Glacier 对象的恢复。
相关信息
标签:
作者介绍
Rostislav Markov
Rostislav 是 AWS 专业服务的首席架构师。作为 AWS 行业的技术领导，他与 AWS客户和合作伙伴合作推进他们的云转型项目。在工作之余，他喜欢与家人一起享受户外活动、打网球和滑雪。
Leave a Reply