本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 为私有 HealthOmics 工作流程运行优化
<a name="workflows-run-optimize"></a>

您可以根据总成本、总运行时间或两者的组合来优化运行。 HealthOmics 提供数据和工具，帮助您做出运行优化决策。运行优化不适用于 Ready2Run 工作流程，因为您无法控制该服务如何管理这些工作流程的资源配置。

第一步是了解运行中任务的当前任务资源使用情况和成本，然后应用优化运行成本和性能的方法。

**Topics**
+ [运行分析器](#workflows-run-analyzer)
+ [确定运行成本](#workflows-run-costs)
+ [确定运行时间使用情况](#workflows-run-time)
+ [优化运行的方法](#run-optimize-methods)
+ [两次运行之间文件大小差异的影响](#workflows-run-file-variance)
+ [优化资源并发的方法](#run-optimize-concurrency)

## 运行分析器
<a name="workflows-run-analyzer"></a>

HealthOmics 提供了一个名为 [Run Analyzer](https://github.com/awslabs/amazon-omics-tools?tab=readme-ov-file#omics-run-analyzer) 的开源工具。该工具可提取运行的任务级资源使用信息，并建议成本和运行性能的优化机会。

**注意**  
运行分析器根据运行该工具时的标 AWS 价估算任务成本和潜在的成本节约。评估优化建议，并实施对您的用例有意义的优化建议。测试您采用的优化，确保它们适用于您的运行。

运行 Analyzer 执行以下任务：
+ 评估内存和计算瓶颈。
+ 确定内存或 CPU 配置过剩的任务，并推荐可以降低成本的新实例大小。
+ 计算单个任务的成本估算值，并计算应用建议后可能节省的成本。
+ 为您提供任务的时间表视图，以便您可以验证任务依赖关系和处理顺序。时间轴还可以帮助您识别长时间运行的任务。
+ 提供有关运行存储空间的文件系统大小的建议。
+ 显示任务配置时间，以便您可以确定大型容器装载可能会减慢配置时间的区域。
+ 该工具包括一个输入参数（净空），可用于控制优化建议的积极性。

以下各节包含有关使用 Run Analyzer 优化运行的具体建议。

## 确定运行成本
<a name="workflows-run-costs"></a>

您可以使用以下方法和指南来确定运行成本：
+ 要查看账单周期的总运行成本，请执行以下步骤：

  1. 打开 B [illing and Cost Managem](https://console.aws.amazon.com/costmanagement/) ent 控制台，然后选择**账单**。

  1. 在 “**按服务收费”** 中，展开 **Omics**。

  1. 展开**区域**，然后按组学实例类型、运行存储类型和 Ready2Run 工作流程逐项查看所有运行的成本。
+ 要生成包含每次运行信息的成本报告，请执行以下步骤：

  1. 打开 B [illing and Cost Managem](https://console.aws.amazon.com/costmanagement/) ent 控制台，然后选择 “**数据导出**”。

  1. 选择 “**创建**” 以创建新的数据导出。

  1. 输入数据**导出的导出名称**。将其他字段保留为默认值以创建 CUR（成本和使用情况）报告。

  1. 对于**时间粒度**，请选择每小时或每天。

  1. 在 “**数据导出存储设置”** 下，执行以下配置步骤：

     1. 为数据导出配置一个 Amazon S3 存储桶。

     1. 对于**文件版本控制**，选择是覆盖现有的导出文件还是每次都创建一个新文件。

     系统将在接下来的 24 小时内生成第一份报告，随后每天生成一次报告。

  1. 有关如何创建数据导出的更多信息，请参阅《数据导[出用户指南》中的创建AWS](https://docs.aws.amazon.com/cur/latest/userguide/dataexports-create.html)*数据导*出。
+ 您可以按类别（例如按团队或项目）标记运行以监控和优化成本。如果您使用标签，请按照以下步骤按标签类别查看运行成本：

  1. 打开[账单和成本管理](https://console.aws.amazon.com/costmanagement/)控制台，然后选择 Cos **t Explorer**。

  1. 在**报告参数 > 分组依**据中，选择**标签**作为维度。然后选择所需的**标签**名称。
+ 要查看任务的资源使用情况，请查看运行清单日志 CloudWatch。有关更多信息，请参阅 [HealthOmics 使用 CloudWatch 日志进行监控](monitoring-cloudwatch-logs.md)。
+ 使用该[运行分析器](#workflows-run-analyzer)工具提取运行的任务资源使用信息。

## 确定运行时间使用情况
<a name="workflows-run-time"></a>

您可以使用以下方法来帮助您调查运行时使用情况：
+ 在控制台的 “**运行**” 页面上，您可以查看一次运行的总运行时间。
+ 在**运行详细信息**页面上，您可以查看以下项目：
  + 查看一次运行的总运行时间。
  + 查看运行中每项任务的运行时间。
  + 选择其中一个链接来查看 Amazon S3 中的日志，或者查看运行日志或运行清单日志 CloudWatch。
+ 从 “**运行任务**” 列表中，选择任务的 “**查看日志**” 链接以查看任务日志 CloudWatch。
+ 对 `listRuns` API 操作的响应包括运行开始时间和停止时间，因此您可以计算总运行时间。
+ 该[运行分析器](#workflows-run-analyzer)工具在时间轴视图上显示任务持续时间。此工具提供任务处理顺序的可视化表示，您可以将其与预期顺序进行匹配。

## 优化运行的方法
<a name="run-optimize-methods"></a>

HealthOmics 自动配置、管理和优化执行数据暂存的资源（例如数据导入和数据导出）。 HealthOmics 还会启动并运行适用于您的工作流程的工作流引擎。但是，您可以通过设置各种运行配置来影响运行开始时间、任务开始时间和任务总体运行时间。工作流程定义和设计的总体方法也会影响任务的运行时间。以下列表描述了可能影响运行和任务性能的因素：

**运行存储类型**  
运行存储类型会影响运行性能和运行配置时间。动态运行存储配置速度更快，并且永远不会耗尽内存，因为它可以根据您的运行存储需求进行动态扩展。动态运行存储也非常适合开发中的工作流程，在这种工作流程中，您可能经常启动和停止工作流程以解决问题。  
静态运行存储需要更长的文件系统配置时间，但可以更快地完成某些运行，通常是在运行具有高任务并发性或需要大于 9.6 TiB 的文件系统容量的情况下。静态运行存储非常适合 I/O 要求很高的长时间运行的工作流程。  
为了帮助您评估给定运行中每种运行存储类型的成本与性能，您可以尝试 A/B 测试，以了解哪种运行存储类型可提供更好的性能。另外，可以考虑在开发周期中使用动态运行存储，然后使用静态运行存储进行大规模生产运行。  
有关运行存储类型的更多信息 [在 HealthOmics 工作流程中运行存储类型](workflows-run-types.md)

**过度配置运行静态存储**  
如果您的工作流任务计算受到I/O, consider over-provisioning the static run storage. Storage cost increases with its size, but maximum throughput of the file system also increases. If an expensive compute task is experiencing I/O瓶颈的限制，则增加文件系统大小以缩短任务运行时间可能会降低总体成本。

**减小容器镜像的大小**  
当每个任务启动时， HealthOmics 加载您为该任务指定的容器。较大的集装箱需要更长的时间才能装载。优化容器使其尽可能小，以提高启动新任务的效率。如果您向容器中添加大型数据集，请考虑将数据集存储在 S3 中，然后让您的工作流程从 S3 导入数据。有关 HealthOmics 支持的最大容器大小，请参阅[HealthOmics 工作流程固定大小配额](fixed-quotas.md#fixed-quotas-workflows)。

**任务大小**  
您可以将小型的连续任务合并成单个任务，以节省任务配置时间。此外， HealthOmics 还收取一分钟的最短任务时长费用，因此合并任务可以降低成本。在组合任务中，你可以使用 Unix 管道来避免序列化和反序列化文件 I/O 的成本。

**文件压缩**  
避免过度压缩工作流程中间文件。大多数基因组学格式使用 “gzip” 或 “block gzip” 压缩。解压缩任务输入文件和重新压缩任务输出文件可能会占用任务总体 CPU 使用率的很大一部分。某些基因组学应用程序允许您在序列化输出时设置压缩级别。通过降低压缩级别，可以缩短 CPU 时间，尽管较大的文件会增加写入磁盘所花费的时间。根据任务和应用程序，您可以找到运行时间最短的中间文件的最佳压缩级别。我们建议您首先将输出文件最大的任务作为目标。2 的压缩级别适用于多种场景。您可以针对您的用例从这个级别开始，然后通过尝试其他压缩级别来比较结果。

**线程数**  
如果您在任务定义中指定线程，请将线程数设置为与请求的数量 v 相同的值CPUs。

**指定计算和内存**  
如果您未在任务中指定内存或计算资源，则会将最小的实例类型 (`omics.c.large`) HealthOmics 指定为默认值。如果您想分配更大的实例类型， HealthOmics 请明确声明您的内存和计算需求。  
HealthOmics 分配您请求的 v CPUs、内存和 GPU 资源的数量。例如，如果你要求 15v CPUs 和 33GiB，则会为你的任务 HealthOmics 分配一个 omics.m.4xl 实例（16v CPUs、64GB），但你的任务只能使用 15 v 和 33GiB。CPUs 因此，我们建议您请求与 omics 实例相匹配的 v CPUs 和内存资源。

**将多个样本批处理成一次运行**  
由于文件系统配置在运行开始时需要时间，因此您可以通过将多个样本批处理到同一个运行中来节省配置时间。在决定采用这种方法之前，请考虑以下因素：  
+ 单个不良样本可能导致工作流程失败，因此批处理样本可能会增加失败的工作流程数量。如果您不确定自己的工作流程在大多数情况下都能成功，那么每个样本运行一次可能是更好的方法。
+ HealthOmics 为整个工作流程分配一个运行存储文件系统。对于一批样品，请确保指定足够大的运行存储空间来处理所有样本。
+ 每个工作流程都有最大运行存储量，因此这可能会限制您可以添加到批次中的样本数量。
+ 最小运行存储大小为 1.2 TiB，因此，如果工作流程使用的存储空间比每个样本的最小存储空间少得多，则批处理可以降低成本。
+ 运行存储可以同时处理多个连接，因此使用相同的运行存储空间执行多个任务不应造成 I/O 瓶颈。
+ 每次运行都有自己的一组标签。如果您使用用于预算或跟踪的信息来标记工作流程，则最好使用单独的运行。
+ IAM 角色适用于整个运行。每个用户都可以访问一批样本的所有数据。将工作流程分开后，您就能够使用更精细的权限。
+ HealthOmics 为工作流程中的最大并发工作流数量和最大并发任务数设置账户级别配额。有关如何申请提高这些配额的信息，请参阅[HealthOmics 服务配额](service-quotas.md)。

**使用容器镜像的参数**  
对容器镜像进行参数化，而不是将其嵌入工作 URIs 流程中。当它们是运行参数时， HealthOmics 会在运行开始之前验证运行是否可以访问您的容器。否则，任务将在运行期间失败，因为任何已完成的任务都产生了费用。此外，由于这些是参数化输入，因此会在运行清单中 HealthOmics 生成校验和，从而改善运行来源。

**使用 linter**  
在运行新工作流程之前，使用 linter 查找常见的工作流程错误。有关更多信息，请参阅 [中的工作流程提示 HealthOmics](workflows-linter.md)。

**用于 EventBridge 举报问题**  
使用 EventBridge 自定义警报来捕捉特定于您的业务逻辑的异常。

**使用序列存储**  
考虑对源数据使用序列存储，以节省存储成本。如需了解更多信息，请通过 HealthOmics博客文章查看[任何规模的经济高效地存储组学数据](https://aws.amazon.com/blogs/industries/store-omics-data-cost-effectively-at-any-scale-with-aws-healthomics/)。

## 两次运行之间文件大小差异的影响
<a name="workflows-run-file-variance"></a>

用户通常使用少量测试数据来设计和测试运行，然后在生产运行中遇到各种各样的数据，文件大小差异很大。在优化运行时，请务必将此差异考虑在内。

以下列表描述了文件大小存在显著差异的优化建议：

**在测试数据中改变文件大小 **  
在开发过程中，尽量使用具有代表性差异的测试数据。

**使用运行分析器 **  
 使用 Run Analyzer 工具对各种样本进行分析，以考虑数据大小的差异。  
您可以使用运行分析器来了解生产数据样本中运行之间的差异。使用 Run Analyzer 中的`--batch`模式为一批运行生成统计数据，并分析处理数据集中的异常值所需的最大计算资源。  
例如，您可以为运行分析器提供批处理模式下的完整数据流单元，以了解整个流通池的 vCPU 和内存利用率峰值。

**减少输入数据集的大小差异 **  
如果您发现样本大小差异很大，则可以将上游的样本分开， HealthOmics 并为每个批次选择不同的文件系统大小，以节省运行存储成本。  
在 WDL 中，使用`size`函数将大样本和小样本的单个任务的资源分配分开。将此策略应用于最昂贵的任务，以产生最大的影响。  
在 Nextflow 中，使用条件资源根据文件大小或文件名对资源分配进行分层。有关更多信息，请参阅 Nextflow GitHub 网站上的[有条件流程资源]( https://nextflow-io.github.io/patterns/conditional-resources)。

**不要过早优化**  
在投入大量的性能调整工作之前，请先完成工作流程代码和逻辑。更改代码可能会对所需资源产生重大影响。如果您在开发过程中过早优化运行，则可能会过度优化，或者如果稍后工作流程定义发生变化，则可能需要再次优化。

**定期重新运行运行分析器工具**  
如果您随着时间的推移对工作流程定义进行了更改，或者样本方差发生了变化，请定期运行 Run Analyzer 工具来帮助您进行其他优化。

## 优化资源并发的方法
<a name="run-optimize-concurrency"></a>

HealthOmics 提供以下功能，可帮助您在大规模处理运行时控制和管理成本：
+ 使用运行组来控制您的成本和资源使用情况。可以在运行组中设置并发运行次数 v CPUs 和每个任务的总运行时间的最大值。 GPUs如果不同的团队或小组使用相同的帐户，则可以为每个团队创建单独的跑步小组。您可以通过配置运行组的最大值来控制每个团队的资源使用量和成本。有关更多信息，请参阅 [使用 HealthOmics 跑步组](creating-run-groups.md)。
+ 在开发过程中，您可以配置一个具有较低最大值的单独运行组，以捕获失控的任务。
+ Service Quotas 还有助于保护您的账户免受过多资源请求的影响。有关 Service Quotas 的信息，包括如何请求增加配额值，请参阅 [HealthOmics 服务配额](service-quotas.md)