持续增强吞吐量的人类全基因组测序数据分析的集装箱化框架

医学信息学解锁25（2021）100684人类全基因组测序数据分析的实施：持续和增强吞吐量的集装箱化框架Abhishek Pandaa，1，Krithika Subramaniana， 1，Bratati Kahalia，*a印度班加罗尔印度科学研究所脑研究中心A R T I C L EI N FO关键词：集装箱资源优化全基因组测序变体调用管道人类A B S T R A C T全基因组测序（WGS）提供了二倍体人类基因组的整个32亿碱基对中每个碱基的信息。因此，WGS在识别人群的遗传变异和了解队列研究或罕见遗传疾病病例中的疾病特征方面发挥着重要作用。尽管如此，来自高通量WGS的发现依赖于有效处理、分析和存储这种大量的基因组测序数据，通常在PB级。尽管近年来基因组测序成本显著降低，但高性能计算成本并没有以直接成比例的方式降低本工作的目的是开发一种基于Docker的容器方法，用于人类全基因组测序数据处理和分析，以检测来自配对末端WGS短读段的遗传变异。我们的方法提供了一种在单个计算系统内同时处理多个基因组的方法，同时保证持续稳定地处理基因组数据处理的内存需求，并确保当前运行的并行作业不会出现不必要的终止。该方法还实现了40%的执行时间减少。为了鼓励广泛采用和简化WGS分析，我们的集装箱管道将公开提供。我们已经对Illumina WGS平台上的人类基因组数据测试了这种方法，并在此通信中报告了两种不同工作站环境中的基准指标。与真值集相比，我们的方法调用变体具有99%的准确率和召回率。1. 介绍在过去的几十年里，基因组学领域的技术进步已经导致全基因组测序成本的大幅降低。这对于进行大规模WGS是非常有益的，其随后提供了对几个世界人群的遗传组成的更深入的理解，并有助于鉴定疾病易感性遗传变异[1，2]。此外，来自种群的大规模基因组数据也可以揭示一些关于它们的进化和迁移模式的未回答的问题[3]。由于测序成本的降低，WGS数据分析和存储的新范例因此变得越来越重要，因为从高通量WGS产生的数百亿个序列读数需要复杂的计算资源用于数据分析和存储。尽管一个人类样本的WGS成本约为1000美元，但对于内部部署，计算分析和长期存储成本可能高达数千美元。云实例的基础设施要求或成本。为了从WGS原始数据中识别遗传变异，我们使用标准基因组分析工具包（GATK）最佳实践，将其称为单核苷酸多态性（SNP），短插入和缺失（InDel），其他全球联盟也遵循这一做法[4]。WGS数据处理和分析管道中的每个阶段都至关重要，因为对数据处理的要求不同。我们在图1a中描绘了整个管道。流水线的每个阶段的计算基础设施要求在很大程度上是异构的，因为它们在存储器要求、多线程执行兼容性和可用计算能力的总体利用率（通常称为负载平均）方面彼此不同。这种异构性质使得在不同的计算平台（诸如独立工作站以及大规模分布式系统或高性能计算集群）中调整和稳定它同时期望保证可持续的吞吐量具有挑战性。与高维护和高成本的集群基础设施相比，多个独立服务器将是一个更* 通讯作者。电子邮件地址：bratati@iisc.ac.in（B.Kahali）。1 同等贡献。https://doi.org/10.1016/j.imu.2021.100684接收日期：2021年4月27日;接收日期：2021年7月10日;接受日期：2021年7月28日在线预订2021年7月30日2352-9148/©2021的 自行发表通过Elsevier 公司这是一个开放接入文章下的CCBY-NC-ND许可证（http://creativecommons.org/licenses/by-nc-nd/4.0/）中找到。可在ScienceDirect上获得目录列表医学信息学期刊主页：www.elsevier.com/locate/imuA. Panda等人医学信息学解锁25（2021）1006842在成本、维护和人力方面，处理几千个基因组是可行的解决方案。但是，在工作站上同时尝试多个基因组的WGS数据分析是徒劳的，因为在某个时间点，内存成为核心瓶颈，并且执行时间非常高。内存瓶颈导致内核自动终止一个或多个同时运行的进程以释放内存。一个接一个地连续处理整个基因组将花费不合理的大量时间，即使是处理几百个基因组。在本文中，我们设想了基于Docker的容器化来处理人类WGS数据，以规避内存瓶颈问题，从而使服务器能够同时处理基因组。本文中采用容器化的一个关键动机是控制计算服务器内的计算资源分配，以进行人类WGS数据分析处理。容器化是应用程序级的虚拟化，它本质上是轻量级的，将应用程序软件及其必要的依赖关系绑定到一个可执行包中。通过使用名为Docker的容器部署引擎，我们将计算服务器隔离为多个较小的逻辑单元，称为容器，具有固定数量的中央处理单元（CPU）核心和分配的内存，因此我们可以更好地控制WGS分析过程中的有效资源利用率。这种机制有助于对分配给容器的资源设置上限约束。与虚拟机相比，容器中的性能开销非常少[5，6]，这使得容器化WGS工作负载非常理想。1.1. 相关工作在过去的十年中，人们对提高WGS数据分析性能进行了广泛的研究。WGS数据分析性能的现有文献包括CPU和GPU基础设施上的并行实现算法（如对齐、排序）[7]、基因组应用的硬件和软件的协同设计，以及Field 可编程网关 阵列（FPGA） [八]《中国日报》 基于实现a-选择。在IBM关于GATK的白皮书中，他们展示了对GATK的优化后昂贵POWER9处理器（https://www.ibm）。com/downloads/cas/ZJQD0QAL）。IBM具有采用分裂在单个POWER9计算节点上对一个公开可用的基因组NA 12878的序列间隔和源代码修改进行了测试。他们使用Kubernetes和Docker通过IBM云推出了POWER9优化的GATK。近年来的其他出版物报道了基于Docker的下一代测序处理管道[9，10]。但是，它们不能在实验室服务器上复制，也不能提供有关计算资源利用率的每个阶段的详细信息，这从实现的角度来看很重要，因为即使在容器化环境中，WGS管道中的某些步骤也会根据计算资源的不同而不同。Broad GATK（https://gatk.broadinstitute.org/hc/en-us/articles/360035889991-然而，在这方面， 的高端企业级 IBM Power9服务器是为繁重的工作量而设计的，因此对于学术界基于WGS的研究来说，它的成本高得令人望而却步。报告的自动化管道不能保证资源优化和提高吞吐量，这是我们工作的主要目标之一在这篇手稿中，我们详细介绍了这一过程与适当的per-perception基准，使它是由不同的研究人员可以实现的，并需要最小的干预。通过部署我们的方法，使用Docker的资源控制和分配功能，可以在不到6个月的时间内在常规的独立服务器上处理1000个人工WGS。我们的研究显示了在独立服务器环境中对多个WGS数据的容器化并行处理和非容器化串行处理之间的比较分析，突出了以下几点：WGS数据分析管道的执行时间分析，高效的资源利用基准，安全处理增加的内存需求，同时并行处理多个WGS数据集，并量化服务器处理WGS数据集的最小配置阈值。Fig. 1. 人类全基因组测序的关键要素概述：（a）描述人类全基因组测序（WGS）数据分析管道的工作流程，从fastq文件开始以获得GVCF文件，用于鉴定一个或多个个体中的种系短变体（SNP和Indel）。(b)容器和非容器模式中用于来自人WGS Illumina HiSeq和NovaSeq实验数据的种系变体调用的计算模型的示意图。A. Panda等人医学信息学解锁25（2021）10068432. 方法2.1. 实验设计Fig. 1. （续）。生成个体水平的基因组变体调用文件格式（例如VCF）。我们使用Docker引擎在工作站环境上启动容器来完成所有这些操作。我们将这个实验设置为容器到WGS样本的一对一映射，WGS数据分析流程大致由5个阶段组成（图1a）。我们首先将原始图像 库 调 用 （ .bcl ） 转 换 为 NovaSeq 6000 数 据 的 可 分 析 序 列 格 式（.fastq）。然后，我们转换了。将HiSeq 2000和NovaSeq 6000的fastq转化为未比对的bam文件，用于针对当前hg38人类基因组比对读段对的预处理 构建 使用 皮卡德 工具（http://www.broadinstitute.github.io/picard/）。我们使用BWA-100（Burrows-Wheeler aligner）（https：//ARXiv.org/pdf/1303.3997.pdf）进行比对，并使用基因组分析工具-试剂盒（GATK，https://software.broadinstitute.org/gatk/）进行变异识别。比对后，我们对输出的BAM文件进行排序，并将重复标记为相同的DNA序列可以多次测序，然后下游GATK工具将默认忽略这些重复读取， 通过 的 内部 应用 的 一 读 滤波 然后我们在单个机器/节点上处理四组NovaSeq和三组HiSeq WGS数据，并且因此当我们以并行执行模式部署它们时实现最佳资源利用。使用Dockers，我们配置了限制内存使用的容器，并有效地使用swap来确保我们的管道处理的受控环境。图Ib示出了容器的工作流程和用于全基因组测序数据分析管道的所有这些执行的非基于容器的方法的示意图。WGS流水线由十多个广泛的步骤组成（图1a），如前所述，这些步骤在计算要求上有很大差异。在这项工作中强调的五个阶段描述了计算密集型阶段，因此我们基于Docker的方法的实用性是显而易见的。A. Panda等人医学信息学解锁25（2021）1006844==-2.2. 数据集用于部署WGS数据分析管道的数据集如表1所示。我们从IlluminaBaseSpace平台下载了NovaSeq 6000 NA12878数据。bcl格式（https://basespace.illumina.com/run/50719672/S1_DVT_N350_DFL）。 它由来自同一个体的四个重复组成。的总大小。4次重复的cbcl文件为218 GB。这些重复中的每一个由约10亿个读取组成。我们从1000个基因组的HiSeq实验中检索原始WGS数据（http://ftp.1000genomes.ebi.ac.uk/vol1/ftp/phase3/data/）（通过FTP）。fastq格式，适用于个人ID NA 12878（.fastq文件~119 GB）、NA 12891个人ID（.fastq文件~134 GB）、NA 12892个人ID（.fastq文件~136 GB）。 这些基因组数据中的每一个由~ 24亿个读取组成。2.3. 配置和命令行参数2.3.1. Dockerfile配置Dockerfile是一个配置文件，其中嵌入了构建Docker镜像的分步说明。在我们的例子中，管道中涉及的所有软件模块以及其他开发和性能工具（如我们在这个谷歌驱动器（www.example.com）中提供了这个Dockerfile链接https://drive.google.com/open?id1XMWKfuIzYQMukz6EKp95yeLo61t0WiH2）和GitHub链接（ https://github.com/BratatiKahaliLab/Containerized_WGS_Data_Pipeline）。2.4. 创建Docker镜像名为“pipeline“的Docker镜像是从Dockerfile（www.example.com）构建https://drive.google.com/open? id = 1 XMWKfuIzYQMukz 6 EKp 95 yeLo 61 t0 WiH 2）使用以下命令：“docker build -t pipeline/ Docker/file/path/."，其中build参数从Dockerfile和上下文构建镜像，-t参数指定镜像的名称，在本例中是管道”。在上面的命令中表示上下文。Google Drive链接（https://drive.google.com/open? ID1k4IHXFWPp-uh 3Q 1-Ie8 QrX 5 BThewVgK 5）显示了我们在本地Docker存储库中构建的管道映像。2.5. 部署容器我们使用以下命令从镜像启动容器：- “docker- m- 存储器交换1 -cpuset-cpus“k-p”\- v/host/path/Output/：/Container/path/Output/\- v/host/path/Output/：/Container/path/Output/\- t表1本研究中使用的公开可用数据集的详细信息：选择了来自两个不同测序平台的测序数据。一组来自HiSeq 2000，其由3个样品组成，另一组来自NovaSeq6000，其由4个样品组成。其中run参数部署容器，-i参数以交互模式启动容器，-G是分配给容器的内存软限制，--1是允许容器使用主机上可用的交换空间的参数，-根据上面的命令行参数，我们将容器启动为表2中列出的配置。2.6. 用硬件我们已经在具有不同处理器微架构和不同RAM配置的两个工作站上执行并基准测试了容器以及基于非容器的WGS数据分析流水线，我们在表3中描述了硬件基础设施。2.7. 用于容器与非容器模式对于非容器模式，我们已经在表3中提到的硬件配置中连续执行了基因组数据的处理。在容器模式中，我们将一个基因组映射到一个容器。每个容器根据主机进行配置，如表2所示。2.8. 基准在 实 验 过 程 中 ， 我 们 使 用 基 于 LinuX 的 顶 级 分 析 器 3.3.10 版（http://www.man7.org/linu x/man-pages/man1/top.1.html ） 捕 获了在容器和非容器模式下运行的进程的资源利用率统计数据。 在容器模式下，我们还使用Docker引擎中的dockerstats工具以下指标已用于测量和比较容器和非容器环境中平均负载：它是内核运行队列中可用进程总数的度量。这里，以百分比表示的标准化负载是通过将顶部分析器报告的负载值除以机器中存在的处理器数量，然后将其乘以100来计算的。CPU利用率：CPU利用率是一个任务的份额的度量以百分比表示的CPU时间。这里，标准化的CPU %是通过将CPU%值（由特定任务的顶级分析器报告）除以计算机中存在的处理器总数来计算的。常驻内存：这表示当前的物理内存表2容器的配置：为HiSeq数据和NovaSeq数据配置的容器在分配的内存和CPU核心限制方面有所不同。在两个不同的工作站环境中，对于HiSeq数据，配置了3个容器，而对于NovaSeq数据，配置了4个容器。平台样本读取总数读取长度%GC数据集平台数量每个容器的配置HiSeq NA12878 2，783，700，988 101 40电话：+86-10 - 8888888传真：+86-10 - 88888888部署的集装箱分配的核心数分配的内存电话：+86-10 - 8888888传真：+86-10 - 88888888NovaSeq S1重复测定936，633，060 35NovaSeq工作站14 12 23 GBS2复制品1，062，504，340 35HiSeq（Centos-7）3 16 30 GBS3重复968，921，366 35NovaSeq工作站24 6 16 GBS4复制品1，093，524，074 35HiSeq（Centos-7）3 8 20 GBA. Panda等人医学信息学解锁25（2021）1006845表3硬件基础设施：在这项研究中，两个不同的工作站与不同的微架构为基础的处理器已被用来基准的容器与非容器模式的人类全基因组测序变异调用管道的执行。机处理器微体系结构时钟频率（GHz）数量的核内存（GB）存储硬盘（TB）操作系统工作站1英特尔Skylake2.6489630CentOS-7工作站2英特尔Sandy Bridge2.424646（随机存取存储器/RAM）在该时间点使用的任务。但是，我们将在本文中互换使用术语RAM和常驻内存，因为它们具有相同的含义。我们使用上述指标来考虑对运行的容器和非容器模式进行基准测试，因为它们是通过LinuX操作系统中的本地顶级分析器无缝捕获的。top profiler提供了以批处理模式记录运行系统的实时信息的功能。它不需要检测源代码，这反过来又避免了源代码最终输出的性能开销和不准确性。我们通过为WGS流程的特定阶段提供process-id，通过顶级分析器捕获基准度量。这些指标，负载平均值和CPU利用率类似于CPU的信息，而驻留内存表示WGS管道的特定阶段的RAM。2.9. 软件详细信息我 们 已 经 使 用 BWA 软 件 版 本 0.7.17-r1194-dirty （ http ：bwa.sourceforge.net/bwa.shtml）来进行序列读数与参考基因组的比对。对于基因组变异调用，我们有使用GATK3.7我们已经使用了以下软件为其他管道的中间步骤：Picard-2.17.4（http://www.broadinstitute.github.io/picard/）、Sambamba-0.6.5[12] 、 Samblaster-0.1.24 [13] 、 Samtools-1.3.1 [14] 、 bamUtil-NonPrimaryDedup-1.0.14（https：github.com/statgen/bamUtil）的示例。我们使用Docker Engine版本18.06.1-ce（https://www.docs.docker.com/engine/install/centos/）来构建和启动容器。3. 结果WGS数据分析管道是多线程和串行实现模块的组合。一次在单个节点上处理多个基因组的WGS流水线的不同阶段将通过创建不必要的计算瓶颈而导致性能资源这就是容器化方法提供的“金发姑娘环境”，它允许定义内存和CPU核心的显式限制，否则会约束WGS数据分析过程。在这项工作中，我们以并行方式为容器模式中的所有数据集实现WGS分析，而在非容器模式中，每个数据集都是串行处理的。我们比较了容器和非容器模式的基准指标，即，驻留内存（RAM），负载平均，CPU利用率的不同阶段的分析。图在图2和图3以及补充图S1A到S1E中，我们分别描绘了Novaseq和Hiseq数据集的基准指标相对于执行时间的趋势。在表4和表5中，我们分别报告了NovaSeq和HiSeq数据集的基准度量的最大值、平均值和总值。3.1. 分选uBAM阶段对于NovaSeq数据集，在对bam文件进行排序时，我们观察到每个样本在容器模式下具有受约束的内存利用率模式，而非容器模式每个样本具有更高的内存利用率。我们在容器模式下为4个样本中的每一个描绘了这种模式，其中内存已达到最大5 GB（图2Ai. a），并且整体内存利用率有效地总计为17.78GB（表4），而在非容器模式下，每个样本的内存利用率高于7.5 GB（图2A i.b），平均内存利用率仅为8.66 GB（表4）。我们能够在容器中指定内存利用率限制，因此它显示了内存的有效使用，而这种对内存利用率的适应在无限制的非容器执行中没有观察到。在HiSeq数据集中观察到类似的分类趋势，容器模式（图S1Ai. a）中的总内存利用率为23.52GB（表5），非容器模式（图S1Ai.b）中为14 GB（表5）。在大多数时间段内，负载平均值始终大于100%（图2A ii.a），在容器运行中达到最大值108.48%（表4）。重载的原因是每个容器中产生的线程数量太多。然而，非容器对应物显示出75%至100%之间的负载平均值趋势，具有高度可变性（图2A ii.b），因为每个样品一个接一个地连续采集整个工作站。在容器模式（图S1Aii. a）和非容器模式（图S1Aii.b）的HiSeq数据集中发现了类似的负载模式。容器模式中HiSeq数据的总负载为106.98%（表5），略微过载，而非容器模式中负载为100%（表5），类似于Novaseq数据中的行为。对于NovaSeq数据，对于容器模式中的4个样品中的每一个，CPU利用率在4000 s-12000 s的时段之间波动这是因为每个容器分配的核的数量（表2）是12，这远小于由容器使用的核的数量非容器模式即，48（表3）。然而，对于3个样品中的每一个，非容器模式在大部分时间内稳定在100%（图2Aiii.b），并且所有48个芯可用于连续处理每个样品。通过减少内核数量和相应调整的CPU利用率，与非容器模式相比，容器模式实现了更高的样品处理吞吐量。我们观察到容器（补充图S1Aiii. a）与非容器模式（补充图S1Aiii.b）中HiSeq数据集（表5）的类似CPU利用率趋势。3.2. BWA对准阶段基因组变异识别流程中的另一个关键阶段是将原始读段与人类参考基因组进行比对。对于NovaSeq和HiSeq数据，该阶段的所有三个度量的总利用率和/或峰值利用率分别描绘于表4和5中。对于容器模式下的NovaSeq数据，我们观察到每个样品都保持了超过6GB的持久存储器模式（图2Bi. a），这与非容器模式下的持久存储器模式（图2Bi.b）相似。但是，在容器模式下，工作站-1对NovaSeq数据的总体内存利用率约为28.82 GB（表4），而非容器对应物的平均峰值内存利用率仅为7.46 GB（表4），因为每个样本都以串行方式执行。HiSeq数据中的记忆模式不同于流水线的该比对阶段的NovaSeq数据，因为HiSeq数据在处理的读取序列的数量方面是两倍以上（表1）。因此，HiSeq数据中存储在RAM中的数据量高于NovaSeq数据集。我们可以在容器模式下以并行方式处理HiSeq数据集的所有三个样本，而不超过30 GB内存的上限（补充图S1.Bi.a），而仅为了在非容器模式下处理HiSeq数据集的单个样本，在流水线的BWA比对模块中需要41 GB的RAM（图S1.Bi.b）。根据单个BWA对齐的内存占用A. Panda等人医学信息学解锁25（2021）1006846图二. A.i用于对NovaSeq数据中的UBAM文件进行排序的存储器模式：（a）关于4个NovaSeq样品的执行时间的并行存储器利用的图示，每个样品在单独的容器中处理（容器模式）。。（b）关于4个NovaSeq样品的执行时间的串行存储器利用率的图示，一个接一个（非容器模式）。 图 2 A.ii用于对NovaSeq数据中的UBAM文件进行排序的负载模式：（a）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，每个样品在单独的容器（容器模式）中并行处理。。（b）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示图2Aiii用于对NovaSeq数据中的UBAM文件进行排序的CPU利用率模式：（a）关于4个NovaSeq样品的执行时间的CPU利用率的图示，每个样品在单独的容器（容器模式）中并行处理。（b）当一个样品在另一个样品之后连续处理（非容器模式）时，4个NovaSeq样品的CPU利用率相对于执行时间的图示 图用于BWA比对阶段的2Bi NovaSeq数据存储器模式：（a）关于4个NovaSeq样品的执行时间的并行存储器利用的图示，每个样品在单独的容器中处理（容器模式）。（b）关于4个NovaSeq样品的执行时间的串行存储器利用率的图示，一个接一个（非容器模式）。 图 2 B ii BWA比对阶段的NovaSeq数据负载模式：（a）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，每个样品在单独的容器（容器模式）中并行处理。(b)关于4个NovaSeq样品的执行时间的处理器上的平均负载的图示，一个样品在另一个样品之后连续处理（非容器模式）。 图 2Biii BWA比对阶段的NovaSeq数据CPU利用率模式：（a）关于4个NovaSeq样品的执行时间的CPU利用率的图示，每个样品在单独的容器（容器模式）中并行处理。（b）当一个样品在另一个样品之后连续处理（非容器模式）时，4个NovaSeq样品的CPU利用率相对于执行时间的图示 图 2用于SAM到BAM转换阶段的C i NovaSeq数据存储器模式：（a）关于4个NovaSeq样品的执行时间的并行存储器利用的图示，每个样品在单独的容器中处理（容器模式）。（b）关于4个NovaSeq样品的执行时间的串行存储器利用率的图示，一个接一个（非容器模式）。 图2 C ii NovaSeq数据加载模式SAM到BAM转换阶段：（a）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，每个样品在单独的处理器中处理。集装箱（集装箱模式）并行。。（b）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，一个样品在另一个样品之后连续处理（非容器模式）。 图SAM到BAM转换阶段的NovaSeq数据CPU利用率模式：（a）关于4个NovaSeq样品的执行时间的CPU利用率的图示，每个样品在单独的容器（容器模式）中并行处理。（b）中央处理机的说明A. Panda等人医学信息学解锁25（2021）1006847当一个样品在另一个样品之后连续处理（非容器模式）时，4个NovaSeq样品的相对于执行时间的利用率。图2D是用于GATK BaseRecalibration阶段的NovaSeq数据存储器模式：（a）关于4个NovaSeq样品的执行时间的并行存储器利用的图示，每个样品在单独的容器中处理（容器模式）。(b)4个NovaSeq样品的串行存储器利用率相对于执行时间的图示，一个接一个（非容器模式）。图2Dii用于GATK BaseRecalibration阶段的NovaSeq数据负载模式：（a）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，每个样品在单独的容器（容器模式）中并行处理。(b)关于4个NovaSeq样品的执行时间的处理器上的平均负载的图示，一个样品在另一个样品之后连续处理（非容器模式）。(a)4个NovaSeq样品的CPU利用率相对于执行时间的图示，每个样品在单独的容器（容器模式）中并行处理。(b)4个NovaSeq样品的CPU利用率相对于执行时间的图示，其中一个样品在另一个样品之后连续处理（非容器模式）。图2Ei GATK HaplotypeCaller阶段的NovaSeq数据存储器模式：（a）关于4个NovaSeq样品的执行时间的并行存储器利用的图示，每个样品在单独的容器中处理（容器模式）。(b)4个NovaSeq样品的串行存储器利用率相对于执行时间的图示，一个接一个（非容器模式）。图2Eii GATK HaplotypeCaller阶段的NovaSeq数据负载模式：（a）关于4个NovaSeq样品的执行时间的处理器上的负载平均值的图示，每个样品在单独的容器（容器模式）中并行处理。(b)关于4个NovaSeq样品的执行时间的处理器上的平均负载的图示，一个样品在另一个样品之后连续处理（非容器模式）。图2E iii GATK单倍型调用者阶段的NovaSeq数据CPU利用模式：（a）关于4个NovaSeq样品的执行时间的CPU利用率的图示，每个样品在单独的容器（容器模式）中并行处理。(b)4个NovaSeq样品的CPU利用率相对于执行时间的图示，其中一个样品在另一个样品之后连续处理（非容器模式）。图二. （续）。虽然在一个过程中，如果我们想要对所有三个HiSeq平台样本（表1）或甚至在常规本地服务器中的多于一个样本进行多过程BWA比对，则将难以处理存储器要求，因为Workstation-1上可用的物理内存为96 GB，需要120 GB以上的RAM。为了解决所需的过多内存，我们将每个HiSeq样本映射到一个容器（配置A. Panda等人医学信息学解锁25（2021）1006848图二. （续）。图三. 在容器模式下并行执行HiSeq数据期间的BWA对齐线程和交换存储器行为。红色突出显示部分表示在所有三个子图中在相同时间点不同地调制的BWA螺纹图案5、18、5。同样，绿色突出显示部分显示了所有三个子图中的5、5、18 BWA螺纹模式。(a)该图描述了NA12878示例的交换内存使用情况与执行时间的关系。内存曲线上的浅蓝色轨迹表示18个线程，而深蓝色轨迹表示正在使用的5个线程。(b)该图描述了NA12891示例的交换内存使用情况与执行时间的关系。内存曲线上的浅蓝色轨迹表示18个线程，而深蓝色轨迹表示正在使用的5个线程。(c)该图描述了NA12892示例的交换内存使用情况与执行时间的关系。内存曲线上的浅蓝色轨迹表示18个线程，而深蓝色轨迹表示正在使用的5个线程。(For关于这一图中颜色的解释，请读者参阅本文的网络版。）详细信息见表2），内存（RAM）配置上限为30 GB。容器模式下的总体内存利用率为87 GB（表5），而非容器模式下的总体内存利用率为41GB（表5）。这表明，即使使用如此庞大的数据集，容器模式也可以有效地管理内存利用率，保持所有3个HiSeq数据集的并行处理不变。NovaSeq数据的负载平均值保持在65%（图2Bii. a）在容器模式下，与非容器模式相比（图2B ii. b）负载平均值一致为96%。在HiSeq数据中，容器模式（补充图S1.Bii. a）中的负载平均值在25%至80%之间变化很大，而非容器模式（补充图S1.Bii.b）则持续为80%。容器模式中这种变化的原因是BWA线程的挂起以及在交换存储器中容纳相应的页面（在图3中解释）。这重申了单个计算节点中的现有资源不能支持WGS分析管道的某些特定阶段的处理，例如BWA比对，即使是对于一些人类全基因组。NovaSeq数据在容器模式下的CPU利用率约为74%（图2Biii. a），而非容器模式描绘了96.16%的CPU利用率（图2B iii.b）。NovaSeq数据中容器模式下CPU利用率降低的原因是分配的CPU核心数量较少。与非容器模式相比，容器模式期间的CPU利用率更低也反映了这种行为。我们表明，容器模式下处理HiSeq数据的CPU利用率为87%（图S1.Biii. a ） ， 而 非 容 器 模 式 下 的 峰 值 CPU 利 用 率 为 93% （ 补 充 图S1.Biii.b）。这是由于HiSeq数据的体积更大的性质导致线程的挂起和存储器页面的卸载以进行交换。在非容器中，每个HiSeq样品利用工作站-1的全部能力串行处理，使CPU利用率达到较高值。我们还想强调，并行处理多个样本的受限CPU利用率 在容器模式下，无需更改BWA源代码即可实现。因此，我们可以在容器化模式下有效利用资源，以在单个计算节点中比对3个HiSeq样本。A. Panda等人医学信息学解锁25（2021）1006849表4工作站1-表中还列出了总时间一个样品样品一个样品样品一个样品样品a数字四舍五入至小数点后两位表5工作站1-表中还列出了总时间一个样品样品一个样品样品一个样品样品a数字四舍五入至小数点后两位3.3. SAM到BAM转换级在将对齐的读段转换为二进制对齐映射文件期间，在NovaSeq数据中，容器模式下的总内存利用率为35.37 GB（表4; BAM转换），而非容器计数器的平均内存利用率为37GB（表4; BAM转换）。这里要注意的是，我们专门控制了容器模式下每个样本的内存，仅使用8 GB（图2C i. a）。在非容器模式中，对于每个样本观察到更高的内存利用率，因为没有资源约束（图2Ci.b）。容器化迫使所有三个HiSeq样本在47 GB RAM内一起处理，而非容器模式要求每个样本40 GB RAM（图S1.Ci. a和图S1.C i.b）。&峰值和总RAM反映了与表5所示相同的模式。在两种执行模式中，负载平均值在运行开始时达到峰值（容器为41.38%，非容器为47.94%，参见表4），然后在容器模式（图2C ii. a）和NovaSeq数据中，在执行的主要持续时间内保持15%和25%之间的两个不同的一致性模式，而在非容器模式（图2C ii. a）中， 2 C ii.b）较小的负载平均值在7%和15%之间%，保持。对于HiSeq数据，容器（图S1.Cii. a）中的负载平均值持续在10%和30%之间，而在非容器（图S1.Cii.b）中，负载平均值在整个执行时间内未显示一致的模式。对于NovaSeq数据，容器和非容器模式中的CPU利用率显示出几乎相似的趋势（图2Ciii. a和b），其在所有4个样品中保持。非容器模式中唯一的例外是第四个示例，它描述了一个较低的CPU执行模式容器非容器总时间（小时）100165变异识别RAM（GB）LA（%）[总计使用的CPU参数（%）[总计作为基准指标RAM（GB）LA（%）CPU（%）管道[4人样品]4个样品]4个样品]4项总计的峰值4项总计的峰值4项总计的峰值uBAM生成9.6315.9050.58.6734.1712.0835.8569.13249.33排序uBAM17.78108.481008.6632.9996388.46100400皮卡德-雷弗特萨姆0.8710.8529.580.421.558.4825.4417.0826.16皮卡德-0.9410.6027.230.381.225.8116.6717.0834.67MarkIlluminaAdapters皮卡德0.9811.2345.30.421.355.6519.7120.4229.52BWA-BWA对准28.8267.574.427.4629.5496.23376.3896.17384.52染色体亚基0.6094.9422.690.4131.61258.35212.9868.79264.83采样转换和排序为35.3741.3870.033713047.94154.3565.19223.17BAM标记重复项13.3799.3498.226.3724.55104.3412.04100400GATK-BaseRecalibration24.3982.9898.58239287.60277.5297.08356.63GATK-17.76100.1599.51456104.5401.4898.60372.75RealignerTargetCreatorGATK-IndelRealigner24.513.2983.83135218.8359.81100338.23GATK-HaplotypeCaller91.2102.3339.693313292.10357.94100400执行模式容器非容器总时间（小时）167215变异识别RAM（GB）LA（%）[总计使用的CPU参数（%）[总计作为基准指标RAM（GB）LA（%）CPU（%）管道[3人样品]3个样品]3个样品]3的总峰值3的总峰值3的总峰值uBAM生成10.6314.3581.568.9526.7515.9022.9650.5207.23排序uBAM23.52106.9899.561438100267.79100300皮卡德-雷弗特萨姆0.889.5418.310.441.210.8516.6329.5813.52皮卡德-0.899.6713.380.381.0610.6013.8527.2310.69MarkIlluminaAdapters皮卡德0.7710.4274.940.360.9211.2318.3145.310.80BWA-BWA对准8786.5287.814112067.5280.4493288.75染色体亚基1.2761.2757.630.832.4594.9485.0622.6977.60采样转换和排序为47.348.081004012041.38142.5670.03211.98BAM标记重复项9.75107.791007.7522.23102.73302.15100300GATK-BaseRecalibrati