Nextflow能实现可重复的计算工作流程
致编辑：
组学分析的读数复杂性越来越高，这与分析大数据的实验重复性有关。当在分析非常大的数据集时，计算不可重现性的主要来源是关于软件和数据库使用的良好的实践的缺乏。计算平台间的小变化也通过产生数值不稳定而导致计算不可重现，尤其是与通常用在组学研究的高性能计算(HPC)环境相关。我们为这种不稳定提供一个名为Nextflow的解决方案，它是一个工作流管理系统，它使用Docker技术来进行容器计算的多尺度处理。
使用计算机的工作流管理系统是大规模生物分析的一个完整的部分。这些系统可以快速建立和开发结合补充软件包的流程。在基因组学中，像Kallisto和Sleuth这样最简单的流程，结合了RNA-seq量化方法和差异表达模块（补充，图1）。当包括了一个给定分析的所有方面时，复杂性会迅速增加。比如，Sanger Companion流程将39个独立的软件工具和库整合到基因组注释套件中。处理如此多的软件包是一个挑战，其中的一些还可能不兼容。频繁的软件更新和保持原始结果的可重复性的冲突要求提供了另一个不受欢迎的妙计。与这些问题伴随而来，复杂流程的高通量使用也会受到单个工具经常产生的数百个中间文件的影响。这些各类的流程中的硬件波动以及不好的错误处理，可能导致大量的读数不稳定。
Nextflow（http://nextflow.io；补充方法，补充说明和补充代码）旨在解决读数不稳定，高效的并行执行，容错以及执行的起源和可追溯的问题。它是一种特定领域的语言，通过对以任何脚本语言编写的现有流程进行修改而实现流程的快速开发。
我们在表1（参考11）中给出了Nextflow和其他相似的工具之间的定性比较。我们发现多级容器化可以将整个流程、子组件和个人工具整合进他们自己的容器，这对数值稳定性是至关重要的。容器可以由用户或者遵循几个最近提出的标准来特别定制（BioBoxes，Bioshadock和AlgoRun）。Nextflow的另一个主要规范是与软件库（包括Github和BitBucket）的整合和对于云系统的本地支持。这种整合中的一些实际意义与计算重现性有关；Github的影响最近被强调为一种数据共享背后的驱动力。
Nextflow可以让用户运行任何针对任何已发布和妥善保存的分析的当前或更早版本的流程。Github整合允许对于软件修改和版本进行一致的追踪，容器化保证了数值稳定性，云端支持提供了快速的计算和有效的缩放。当使用这个过程时，任何结果，包括表格、图表或是任何种类的数值量化形式，都可以与简单的命令行相关联并根据需要进行引用、更新、复制或改进。Nextflow使用一种功能反应式编程模型，其中每个操作（一般是工作流程任务）在它自己的执行上下文中被隔离。Nextflow中一个操作的输出通过与UNIX流程类似的过程的专用频道流式传输到其他操作。并行化是每个进程的输入和输出被引导到其他进程的方式的一个隐含结果。这种方法为用户提供了执行显式并行策略的需求。Nextflow的另一个好处是它依赖于数据流编程范例，一旦通过输入频道接收到数据，任务就自动开始。
数据流模型优于基于Make-like方法的替代解决方案，比如Snakemake[16]，其中计算包括所有计算依赖性的预先估计，从期望的结果开始直到输入原始数据（表1）。一个Make-like步骤需要一个有向无环图（DAG），它的存储要求对非常大的计算来说是一个限制因素。相反，由于Nextflow使用的自上而下的处理模型遵循数据分析的自然流程，因此不需要DAG。而且，它遍历的图只是附带的，不需要预先计算或者存储，因此保证了高可扩展性[17]。
任务间的通讯通道的使用也使得Nextflow具有计算灵活性和鲁棒性。比如，在Snakemake中，任务执行序列是通过依赖于输入/输出文件名的规则和模式来定义的。这些依赖使得处理多个动态产生的输出文件变得困难，并且经常需要执行低级输出管理程序来处理流程的各个阶段。Nextflow可以使用任何数据结构，并且输出不限于文件，还可以包含内存中的值和数据对象。
Nextflow是专为熟悉编程的生物信息学者特别设计的。这与Galaxy[18]不同，它解决了一个叫做Tool Shed[19]的定制软件包管理器的数值稳定性问题。尽管Galaxy的图形用户界面（GUI）为非专业人员实现de novo流程提供了强大的支持，但是由于任何现有的和经过验证的第三方流程必须使用GUI重新实现和重新参数化，所以它也带来沉重的开发负担。在精心制作的流程中这可能是非常苛刻的，比如用复杂的工具组合构成的Sanger Companion流程。类似的重新实现要求也适用于其他工具，包括Toil[20]。
为了说明Nextflow如何使用，我们首先为一个在Sanger Companion[10]流程中的复杂样本流程确定了数值稳定性问题的大小。我们用它进行Leishmania infantum基因组（补充方法）的基因注释预测。我们的结果显示了不同UNIX平台的变化（图1a，b和补充表1）。这样的不稳定性与在每个独立平台进行的确定性行为形成了对比。由于在Nextflow中使用Companion流程，我们能够确认在三个类UNIX操作系统（图1a）上使用相同的docker化版本的流程的读数稳定性。
基因注释不是影响基因组分析的唯一类型。当使用Kallisto（一个表达式量化工具）和Sleuth差异表达式包[9]的时候，我们发现了类似的问题。在这种情况下，当在两个不同系统（图1c，左面板）上运行这个流程时，观察到了差异表达基因的鉴定的变化。然而，在这些系统（图1c，右面板，补充图2）上运行相同流程的Nextflow docker化版本时，就没有观察到这种差异。最后，当用RanML[21]（补充图3）估计最大似然树时，也观察到了平台相关的影响。当使用相同流程（补充图3）的支持Docker的Nextflow版本时，Nextflow能够有效控制这些变化。所有三个计算实验可以在Github（流程；https://github.com/cbcrg/kallisto-nf-reproduce/tree/nbt-v1.0，https://github.com/cbcrg/raxml-nf/tree/nbt-v1.0，https://github.com/cbcrg/companion）和Zenodo（数据和结果；https://zenodo.org/record/159153#.WMgK52_yvcs）上找到。
在不同的计算平台上使用数据分析流程时，Nextflow是所发生的数值不稳定问题的解决方案。数值不稳定性影响了大多数的计算机分析类型，尽管数值稳定性对最终读数的总体影响可能不大，但迄今为止缺乏有效的解决方案使用户在选择使用哪个平台时面临艰巨的挑战。小心仔细地监控数据库和软件版本是不够的。缺乏数值稳定性可能会在处理实验数据的时候产生问题后果，比如妥协验证和更新之前的结果。例如，在个性化医疗应用中，数值不稳定可能会导致治疗变化，带来无法预料的后果。
数值稳定性可能是一个长期存在的问题。我们今天的报告，使用Nextflow赋予计算机和云的常用集群中的计算工作流以数值稳定性。
表格1：
在与Nextflow类似的几种工作流管理工具中，Bpipe可能是与Nextflow最密切相关的。然而，Bpipe的一个问题就是缺乏对于多级容器化的支持，而Nextflow和其他工作流管理器是支持的，比如Galaxy和Toil。a：每个框架使用的技术和编程语言。b：框架支持本地命令和脚本的执行而不重新实现原始进程的能力。c：对于CWL规范的支持。d：将任务的输入/输出处理为数据流的能力。e：对代码管理和分享平台的支持，比如Github，BitBucket和Gitlab。f：对于模块，子工作流或者工作流组合的支持。g：跟踪流程更改和在任意时间点执行不同版本的能力。h：对于自动错误处理和回复执行机制的支持。i：与流程交互的图形用户界面的实现。j：可视化任务依赖和执行的能力。k：对于Docker容器技术的集成支持。l：对于Singularity容器技术的集成支持。m：管理在分布式/HPC集群或云中多容器实例执行的能力。n：通过集群批处理调度程序生成流程任务的执行，而无需自定义脚本或命令的能力。需要注意的是，尽管这项支持不是Snakemake中内置的，但是它只需要用户提供特定于集群的作业控制命令。o：通过分布式集群产生流程任务执行的能力。p：利用独特的云基础架构功能（比如弹性资源分配和现场实例）部署和运行分布式工作流程的能力。粗体字表示类似的支持的组件和应用的列表。
图1：
Nextflow可以在不同平台上进行稳定的分析。（a）Leishmania infantum克隆JPCM5基因组注释使用了本地或者docker化（Debian Linux）版本的Companion eukaryotic 注释流程。本地和docker化的版本在Mac OSX和Amazon Linux平台上运行。使用注释基因绘制的韦恩图显示了在比较预测的编码基因，未编码的RNA以及假基因的基因组坐标时的小差异。（b）在不同基因组坐标中相同基因的注释存在一些差异。当在Mac OSX或者Amazon Linux平台上使用docker化版本时，得到了完全相同的注释。（c）Kallisto和Sleuth流程的比较，使用了人类肺部成纤维细胞数据，在RNA-seq实验中发现差异表达基因（q-value lt; 0.01），显示了在Mac OSX或者Amazon Linux平台上进行的差异。在部署docker化版本的流程时，两个平台都产生了相同的读数。所有分析都至少进行了两次并且检查了数值稳定性。
对象-业务 流程映射框架：抽象，体系结构和实现
摘要：
企业体系结构和业务流程管理系统（BPMS）之间的集成目前基于低层次的编程接口，这些接口暴露了流程实现中典型的意外复杂性。本文描述了基于映射框架的软件体系结构和BPMS的集成方法。我们的灵感来源于广泛用于保护信息系统免受关系型数据库系统暴露的底层结构影响的对象关系映射（ORM）框架。本文描述了应该由对象-业务进程映射框架（OBPM）提供的中心抽象。我们还提出一个实现OBPM的参考架构和一个叫做Nextflow的具体OBPM实现。我们通过比较同一系统的两种实现来评估我们的方法，一种实现使用Nextflow，另一种实现使用jBPM支持的本地API，一个流行的BPMS。通过使用Nextflow，在实现系统时，我们的代码行数量减少了30%，类的数量减少了35%，引用的声明减少了90%。
索引术语：
业务流程；企业架构；映射框架；对象-业务进程映射框架；业务流程管理系统
一、引言
企业软件开发越来越依赖框架和体系结构去促进复用和提高生产力。特别的，企业体系结构通常分层次组织，以实现特定的关注点。比如，通常有一层响应用户界面问题（表现层），有一层负责持久化（数据源层）[1,2]。业务规范由领域层实现，该层实现与核心业务流程和规范相关的问题。另一方面，伴随着优化流程的持续压力，通常被称为业务流程管理系统（BPMS）的专门的软件基础设施被提出来处理业务流程[3,4,5]。BPMS支持业务流程的定义，执行，注册和控制，就像数据库管理系统（DBMS）处理数据服务一样。
在现在的软件系统中考虑使用BPMS时我们有两种选择。第一种选择要依赖BPMS去实现和部署一个完整的应用程序，可能要使用基于模型或者其他（半）自动化的代码生成技术。然而，使用BPMS作为全面的软件基础设施有着重要的局限性[6]。比如，不太可能从像GUI和基于MVC的应用程序框架这样的现代和广泛使用的框架中获得好处。另一个问题涉及任务的实施，这通常需要在业务流程定义的特定组件中的定义代码，经常使用属性框。第二个选择依赖BPMS支持信息系统架构的领域层所需要的业务流程。因此，第二个选择需要一个BPMS和软件架构的其余组件之间的接口。然而，企业架构组件和当前BPMS之间的集成存在重大的缺陷。例如，一旦BPMS建立了就很难改变了。而且，目前用于访问BPMS的API暴露了几个低级别的抽象，这可能被视为意外的复杂性[7]。例如，开发者不得不操作任务和结点这样的不属于业务语义的元素。
为了解决前述的问题，我们基于映射框架提出一个集成企业架构和BPMS的软件工程解决方案。我们提出这个建议的灵感来源于广泛用于保护信息系统免受关系型数据库系统（RDBMS）提供的底层结构的影响的对象关系映射（ORM）框架。尽管RDBMS和BPMS有着不同的用途，我们认为映射框架可以为使用BPMS的系统带来与ORM框架为使用数据库的系统提供的相同的好处。
在本文中我们做了以下贡献：
我们提出一个叫做对象-业务流程映射（OBPM）框架的映射框架的新类型，用于集成BPMS和现代软件体系结构（第三章）。为了将OBPM从具体的业务流程符号中分离出来，我们建议OBPM应该依赖于一种抽象业务流程模型，该模型只包括操作信息系统业务流程的最低要素。我们还定义了一个映射规则集合，将这个抽象模型提出的元素与面向对象的元素相关联。更具体地说，我们建议OBPM应该提供三个关键抽象：进程界面（客户端用于触发在BPMS中的操作），数据类（为了在信息系统和BPMS间分享数据）以及回调类（用于向业务进程中添加外部语义）。
我们提出一个实现OBPM框架（第四章）的参考架构。这个架构集中在两层。第一层叫做工作流程连接（WFC），它提供了连接抽象模型和具体BPMS实现的方法。第二层叫做对象-工作流映射（OWM），它提供了一个根据面向对象的抽象表示业务流程元素的API。将数据库框架和驱动程序相比较，WFC层为业务流程展示了对于数据库而言JDBC
全文共8462字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[15865]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
