Docker的性能损耗
关键词：工作流，管线，Docker，虚拟化，生物信息学
简介：
基因组管线通常依赖多个第三方研究软件的组合，这些应用程序往往是学术原型，在安装、配置和部署方面经常有一定困难。在一个特定环境中运行的程序，对其它程序，库和组件有很多隐含的依赖。因此，在一个环境中构造出来的计算分析流程，很难在另一个环境中不付出大量努力便顺利运行起来。过去，我们会采用虚拟化技术来处理这种问题，然而，这种方法有一些明显的缺点。虚拟机映像很大（通常有几 GB），它们需要操作系统 (OS) 文件的完整复制。即使仅添加或更改单个文件，也需要组装和部署整个虚拟机。而且虚拟机内软件或数据的重用也几乎是不可能的，因为其内容不是系统描述的，也不能通过标准的工具/协议访问。
Docker容器科技近来得到科学区的关注，因为它能让应用运行在一个隔离的，自包含的软件包中，实现快速分发和跨多个平台的执行。
其最显著的优势是将繁琐的软件安装过程，简化成了下载一个事先build好的，随时能运行起来的镜像，镜像中包含了所有的软件及其需要的配置。
Docker的另一个优势在于每个进程运行在相互隔离的容器中，避免了同一个主机环境中多个程序的冲突，同时保证了每个进程运行在一个可控的系统配置中，即使后续对软件的错误配置，系统更新或程序错误也不会影响这个环境。
一个容器只需要几分之一秒就可以启动，而且许多实例可以在同一托管环境中运行。这是可能的，因为它在主机操作系统的用户空间中作为一个独立的进程运行，与其他容器共享内核。
IBM Research的一项研究表明，Docker容器对CPU和内存带来的开销可以忽略不计，在所有测试中，在容器中运行的应用程序的性能与传统虚拟机技术相同甚至更好。
那么问题来了，与“本机”执行相比，Docker容器的使用在多大程度上可能会影响计算工作流的性能。在这项工作中，我们将通过现实的计算生物学场景，来评估Docker容器对基因组分析流程的性能影响。ENCODE通常被定义为DNA元素百科全书，是一个大规模的基因组注释项目，旨在描述一组选定细胞系中的转录组、调控状态和表观基因组的一部分。作为原理证明，我们在第14天和第18天，在两个生物复制品中分析从两个小鼠胚胎脑样本（CNS）随机取样的RNA-Seq读数。
方法：
为了评估 Docker 使用对生物信息学工具执行性能的影响，我们对三个不同的基因组管线进行了基准测试。分别在Docker和物理机的环境下，处理同一组数据。测试是使用集群节点 HP BL460c Gen8 执行的，该节点具有 12 处理器 Intel Xeon X5670 (2.93 GHz)、96 GB RAM 并在 Scientific Linux 6.5（内核 2.6.32-431.29.2.el6.x86_64）上运行。
Docker的版本是1.0，device mapper作为存储驱动。用于基准测试的 Docker 镜像是从 Scientific Linux 6.5 基础镜像开始构建的。计算节点是为基准执行保留的（这意味着没有其他工作负载被分派给它）；此外，为了防止可能以不可预测的方式影响执行时间的任何可能的网络延迟，所有测试都使用节点本地磁盘作为主存储来执行。
这三个分析流程都通过Nextflow开发，Nextflow可以简化计算流的跨平台部署，并且支持Docker。这样一来，不改代码，就可以把相同的分析流程运行在本地或Docker两种环境中，只需要在Nextflow中简单修改Docker镜像的配置文件。
需要说明的是，基于Docker的实现方式并不是说所有的分析流程都运行在一个容器中，而是每个从分析流程分隔出来的任务都运行在各自的容器中。容器的工作路径被设定到Dockervolume中，这个volume被挂载到主机文件系统的一个本地目录中。这样一来，各个任务之间可以共享数据，也不影响分析流程的执行流程。每个任务还能使用不同的镜像，使用网络共享存储（比如NFS）的集群还能实现无缝扩展。
每组基准测试中，通过在Docker和物理机，分别运行10个实例并计算平均运行时间，再进行比较。由于整个分析流程分为多个并行的任务，整个工作的执行时间为所有任务执行时间的总，具体计算方式是启动和完成的系统时间戳之差，所以其中包含了容器的实例化时间开销（不包含pull镜像的时间）。
通过比较10个运行Docker和不运行Docker的实例的平均执行时间，估计了容器技术对管线性能带来的开销。当管道运行并行任务时，执行时间被规范化，将每个实例中所有任务的执行时间相加。任务执行时间计算为启动和完成系统时间戳之间的差值（使用system.currentTimeMillis Java API以毫秒分辨率）。因此，它包括使用Docker时的容器实例化时间开销（而不是提取之前下载的所需映像所需的时间）。
基准测试1
第一次性能评估是使用简单的RNA-Seq数据分析管线进行的。
该管线将原始的RNA-Seq序列作为输入，然后按照序列比对，回贴（map）到参考基因组和转录注释。回贴信息通过参考的转录注释，确定各个转录本的表达量。每一个进程样本，会生成一个所有转录组相对表达量的table。
同一组数据将分别在Docker和物理机环境中分别被处理10次。转录组测序（RNA-Seq）数据取自ENCODE项目（ENOCDE，Encyclopedia of DNA Elements。ENCODE是一个大规模基因注释工程，旨在描述基因组中所编码的全部功能性序列元件），分别从两只幼鼠（一只14天，一只18天）脑部样本数据中随机抽取。
每个完整分析流程包含9个任务：Bowtie运行一个index任务（为基因组创建索引），Tophat2运行4个mapping的任务（序列回帖到基因组），Cufflinks来运行4个transcript的任务（用回帖到基因组的短序列来拼接转录本）。Mapping和transcript的任务是并行执行的。软件版本分别是Samtools 0.1.18，Bowtie2 2.2.3，Tophat-2.0.12，Cufflinks 2.2.1。
整个分析流程在物理机环境下的平均执行时间是1156.0分钟（19h 16m 14s），在Docker环境下的平均执行时间是1158.2分钟（19h 18m 14s），所以容器带来的开销大概在0.1%。
基准测试2
基准测试 2是基于『Minimum Information for Reporting NextGeneration Sequencing Genotyping” (MIRING)』的基于拼接的突变鉴定流程，用于组织相容性，免疫遗传和免疫基因的应用。
来自靶向人类白细胞抗原 (HLA) 和杀伤细胞免疫球蛋白样受体 (KIR) 基因的双端基因组读数组装成共有序列。 然后将读取和共有序列与人类基因组参考比对，并用于调用变体。
该管道使用针对主要组织相容性复合体 (MHC) I 类 HLA-A、HLA-B 和 HLA-C 基因以及 MHC II 类基因 HLA-DRB1 的 Illumina 配对末端基因组读数启动 10 次，来自 8 个个体。具体的工具和版本为：ngs-tools 1.7，SSAKE 3.8.2，BWA0.7.12-r1039和Samtools1.2。
每次运行执行 48 个任务，可以并行执行的最大任务数设置为 10。大多数任务在几秒钟内完成，不包括需要 2 到 3.5 小时才能完成的 SSAKE 阶段。
这个分析流程在物理机的平均执行时间是1254.0分钟（20h 53m 58s），Docker环境下的时间是1283.8分钟（21h 23m 50s），这意味着当使用 Docker 运行时，执行速度降低了 2.4%。
基准测试3
最后一个基准测试是使用 Piper-NF 进行的，Piper-NF 是一种用于检测和映射长非编码 RNA 的基因组管线。
该管线将 FASTA 格式的 cDNA 转录序列作为输入，这些序列使用 BLAST 与一组同样以 FASTA 格式提供的基因组进行比对。 目标基因组上的同源区域用作锚点，然后提取周围区域并与原始查询重新对齐。 如果比对器可以比对这些序列，并且比对覆盖原始查询所需的最小区域，则使用这些序列构建多序列比对，然后使用该比对获得每个同源序列与原始查询之间的相似性。
和前两次一样，整个分析流程会在Docker环境和物理机环境中分别被执行10次。我们使用来自 Gallus gallus 物种的 FASTA 格式的一组 100 个 RNA-Seq 转录序列作为输入查询。 输入序列被映射和比对一组基因组，包括 Anas platyrhynchos、Anolis carolinensis、Chrysemys picta bellii、Ficedula albicollis、Gallus gallus、Meleagris gallopavo、 Melobsittacus undulatus、Pelodiscus sinensis、Taeniopygia guttlata。所用工具为T-Coffee 10.00.r1613， NCBI BLAST 2.2.29 ， Exonerate 2.2.0。每个工作流被分为98个任务，可以并行执行的任务数为10。
在物理机所用的平均时间是58.5分钟，Docker环境下的平均时间是96.5分钟。Docker带来的额外开销在65%左右（见表1）。
主要原因在于，这个分析流程的执行包括多个短的实时任务，任务的平均执行时间是35.8s，中值是5.5s。这样一来，由Docker启动程序和挂载主机文件系统所带来的时间开销，相比很短的任务就变得不容忽视了。
结论：
在本文中，我们评估了 Docker 容器技术对基因组管线性能的影响，表明容器“虚拟化”在由中/长时间运行的任务组成时对管线性能的开销可以忽略不计，这在计算基因组管线中是最常见的场景。
有趣的是，对于这些任务，当使用 Docker 运行时，观察到的标准偏差更小。 这表明容器的执行更加“同质”，大概是由于容器环境提供的隔离。
对于大多数任务具有细粒度或非常细粒度（几秒或几毫秒）的管线，性能下降更为显着。 在这种情况下，容器实例化时间虽然很小，但不能忽略，并且会产生明显的性能损失。
在处理容器技术时，应考虑其他对执行性能没有直接影响的因素。 例如，Docker 映像虽然比等效的虚拟机映像小，但需要一些时间才能从远程存储库下载。 此时间取决于可用的 Internet 连接和图像大小（通常为数百兆字节）。安装允许图像缓存在本地组织网络中的本地存储库镜像是加快下载速度的好策略。
Docker 镜像也可以使用 Dockerfile 从头开始创建，即一个简单的文本文件，其中列出了组装目标镜像所需的依赖项和命令（例如，下载和安装软件包、设置环境变量等）。 镜像构建过程由 Docker 引擎自动管理，通常需要几分钟。 由于 Dockerfile 是一种小资源，因此可以很容易地与其他研究人员共享。 因此，它可以用作交换预先构建的 Docker 映像二进制文件的“廉价”替代方案（尽管这种方法不如将映像存储在 Docker 存储库中可靠，因为由于软件组件和 Web 资源的易变性， 尝试构建映像时，所需的依赖项可能会更改或不再可用）。<!--
剩余内容已隐藏，支付完成后下载完整资料
The impact of Docker containers on the performance of genomic pipelines
Di Tommaso P, Palumbo E, Chatzou M, et al. PeerJ
Abstract：Genomic pipelines consist of several pieces of third party software and, because of their experimental nature, frequent changes and updates are commonly necessary thus raising serious deployment and reproducibility issues. Docker containers are emerging as a possible solution for many of these problems, as they allow the packaging of pipelines in an isolated and self-contained manner. This makes it easy to distribute and execute pipelines in a portable manner across a wide range of computing platforms. Thus, the question that arises is to what extent the use of Docker containers might affect the performance of these pipelines. Here we address this question and conclude that Docker containers have only a minor impact on the performance of common genomic pipelines, which is negligible when the executed jobs are long in terms of computational time.
Keywords: Workflow, Pipelines, Docker, Virtualisation, Bioinformatics
Introduction：
Genomic pipelines usually rely on a combination of several pieces of third party research software. These applications tend to be academic prototypes that are often difficult to install, configure and deploy. A program implemented in a given environment typically has many implicit dependencies on programs, libraries, and other components present within that environment. As a consequence, a computational workflow constructed in one environment has little chance of running correctly in another environment without significant effort (Garijo et al., 2013). In the past, machine virtualization technology was proposed as an answer to this issue (Howe, 2012; Gent, 2013). However, this approach has some significant disadvantages. Virtual machine images are large (typically several gigabytes) because they require a complete copy of the operating system (OS) files. Even to add or change just a single file, an overall copy of the virtual machine needs to be assembled and deployed. Moreover it is difficult, if not impossible, to reuse pieces of software or data inside a virtual machine. Their content tends to be opaque i.e., not systematically described or accessible with a standard tool/protocol (Hinsen, 2014).
Docker containers technology (http://www.docker.com) has recently received an increasing level of attention throughout the scientific community because it allows applications to run in an isolated, self-contained package that can be efficiently distributed and executed in a portable manner across a wide range of computing platforms (Gerlach et al., 2014; Boettiger, 2015).
The most obvious advantage of this approach is to replace the tedious installation of numerous pieces of software, with complex dependencies, by simply downloading a single pre-built ready-to-run image containing all the software and the required configuration.
Another advantage of Docker is that it runs each process in an isolated container that is created starting from an immutable image. This prevents conflicts with other installed programs in the hosting environment, and guarantees that each process runs in a predictable system configuration that cannot change over time due to misconfigured software, system updates or programming errors.
A container only requires a fraction of a second to start and many instances can run in the same hosting environment. This is possible because it runs as an isolated process in userspace on the host operating system, sharing the kernel with other containers.
A study from IBM Research shows that Docker containers introduce a negligible overhead for CPU and memory performance, and that applications running in a container perform equally or better when compared to traditional virtual machine technology in all tests (Felter et al., 2014).
A question that arises is to what extent the use of Docker containers might affect the performance of a computational workflow when compared to “native” execution. In this work, we assess the impact of Docker containers on the performance of genomic pipelines using a realistic computational biology usage scenario based on the re-computation of selected subsets of the mouse ENCODE analysis. ENCODE, commonly defined as the Encyclopedia of DNA elements, is a large-scale genomic annotation project that aims at characterizing the transcriptome, the regulatory state and a part of the epigenome in a selected set of cell lines (ENCODE Project Consortium, 2012). As a proof of principle, we used our implementation to analyze randomly sampled RNA-Seq reads from two mouse embryo brain samples (CNS), at day 14 and day 18, in two bioreplicates.
Method：
In order to evaluate the impact of Docker usage on the execution performance of bioinformatics tools, we benchmarked three different genomic pipelines. A comparison of the execution times was made running them with and without Docker along with the same dataset. The tests were executed using a cluster node HP BL460c Gen8 with 12 cpus Intel Xeon X5670 (2.93 GHz), 96 GB of RAM and running on Scientific Linux 6.5 (kernel 2.6.32-431.29.2.el6.x86_64).
Tests were executed using Docker 1.0 configured with device mapper as the storage driver. Docker images used for the benchmark were built starting from a Scientific Linux 6.5 base image. The compute node was reserved for the benchmark execution (this means that no other workload was dispatched to it); moreover, to prevent any possible network latencies that could affect the execution times in an unpredictable manner, all tests were executed using the node local disk as main storage.
All three pipelines are developed with Nextflow, a tool that is designed to simplify the deployment of computational pipelines across different platfor
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[596055]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
