生信工作流框架搭建 | 01-nextflow、snakemake、wdl 对比测试

本篇为biodoge《生信工作流框架搭建》系列笔记的第2篇，该系列将持续更新。

前情提要

上回说到五大流派华山论剑、各显神通，指标衡量下，方才有三大主流框架脱颖而出：
基于groovy的nextflow、基于Python的snakemake、搭配引擎Cromwell的wdl。
这三员大将拥簇众多，各有长处，本文就将这三个工作流框架进行简单介绍，并在实际测试中对比分析，一较高下。
请注意，测试和结论将是主观的。对了，多说一句，无论是哪种框架，都有坑，区别就是大坑和小坑，做好踩坑的心理准备。

主流框架

1、nextflow

Nextflow是一个生物信息学工作流程管理器，能够开发可移植和可重复的工作流程。
nextflow和snakemake都可以基于通配符规则来读取文件。

核心：进程，通道和工作流（Processes, channels, and workflows）

进程描述要运行的任务。进程脚本可以用 Linux 平台(Bash、 Perl、 Ruby、 Python 等)执行的任何脚本语言来编写。进程为每个完整的输入集生成一个任务。每个任务都是独立执行的，不能与另一个任务交互。在进程任务之间传递数据的唯一方式是通过称为通道的异步队列。
进程定义任务的输入和输出。然后使用通道来操作从一个进程到下一个进程的数据流。然后，进程之间的交互，以及最终管道执行流本身，将在工作流部分中隐式定义。

图示：我们有一个包含三个元素的通道，例如，3个数据文件。我们有一个将通道作为输入的进程。由于通道有三个元素，所以该进程的三个独立实例(任务)并行运行。每个任务生成一个输出，该输出被传递到另一个通道，并用作下一个进程的输入。

了解更多：

https://github.com/nextflow-io/nextflow
nextflow官方文档 内容是多了点，好在逻辑很清楚
nextflow patterns ，一些常用范式
白墨石的系列教程
如果你不喜欢造轮子的话，这有一堆现成的（现有流程社区）：nfcore

2、snakemake

snakemake 是基于 Python 的一款工具，所以它也继承了 Python 语言简单易读、逻辑清晰、便于维护的特点，同时它还支持 Python 语法，非常适合新手用户。
snakemake 的基本组成单位叫“规则”，即 rule；每个 rule 里面又有多个元素（input、output、run等）。它的执行逻辑就是将各个 rule 利用 input/output 连接起来，形成一个完整的工作流，当检测到 input，就执行相应 rule；检测到 output，就跳过相应rule，根据这一规则，snakemake 还可以实现断点续投。

第一条规则（“all”）指明想要生成的文件；接下来软件会利用其他规则确定如何生成。加州大学戴维斯分校的生物信息学家Titus Brown解释说，这就好像先决定晚餐吃什么，然后往回思考一步一步该怎么做：想要吃番茄酱意面，就要先做蕃茄酱；要做蕃茄酱，就要烧番茄和洋葱，诸如此类。

图示：Snakemake语法的一个简短而全面的演示。(a) 工作流程的定义；(b) 工作的有向无环图（DAG），工作节点的颜色反映了工作流程定义中的规则颜色。(c ) 脚本 plot-hist.py 的内容来自规则 plot_histogram。(d) 按语句类别对可读性的知识要求。这个例子的工作流程下载了数据，绘制了给定国家列表中城市人口的直方图，将这些数据从SVG转换为PDF格式。
从这张官方paper里面的图就可以看出他们文档做得多好。

了解更多：

https://snakemake.github.io/
snakemake官方文档 他们教程好到什么地步呢，会让你产生，哇好简单我一学就会的错觉。
snakemake应该是这三种里人气最高的，教程/范例很多：
snakemake–我最喜欢的流程管理工具
用Snakemake跑pipeline到底有多么优雅
计算流程组织-Snakemake

3、wdl/Cromwell

WDL全称是Workflow Description Language，是Broad Institute专门开发用来跑流程的语言。

WDL基本元件有5个，分别是定义总流程的workflow、定义单个任务的task、运行任务的call、定义任务中命令的command以及输出output。

写wdl脚本并不难，需要注意的是版本、输入要写到json里。真正要运行还需要Cromwell这个引擎，由图可知用途就是给WDL这只蠢猪加上火箭一飞冲天。（这个绝妙的比喻来自一个博主）
关于对各种云计算和HPC的支持，其实是Cromwell实现的。

但我要说的是，本地运行，这家伙的控制台输出也太恐怖了。

了解更多：

https://github.com/openwdl/wdl
Cromwell官方文档 写得一般，很多重要信息隐藏在分支目录下，不知道怎么想的
wdl语法规范 官方文档写得很糟，很遗憾，语法不得不学，但是我建议先看看下面这些。
标准流程描述语言 WDL 阿里云最佳实践 阿里云的文章强烈推荐，图文并茂展现了wdl的基础教程，并提供了Cromwell在阿里云上的部署原理和案例，简单易懂、代码清晰。
WDL学习笔记 非常简洁明了的教程，且总能切中要害，帮你避雷。

对比测试

首先推荐一个简单对比这三者的GitHub项目
我的指标稍微复杂一些

我以宏基因组部分分析为例，进行测试，分别写了三者的脚本，实际运行两个。（运行snakemake时，才发现不支持集成docker，他们只支持singularity。这种坑就是实际踩了才能发现，虽然snakemake是这三者中风格最优雅的，但还是忍痛放弃了）

测试的时候其实我对nextflow已经比较熟练了，本地运行没有任何问题。wdl则是问题频发。

一开始，wdl跑这样的流程需要接近一个小时，观察发现，真正在docker容器跑的程序只需要几分钟。
因此很可能耗时在文件传输上。

“文件传输原理”当Cromwell运行一个工作流时，它首先创建一个目录/。这被称为workflow_root，它是该工作流程中所有活动的根目录。每个调用都有自己的子目录。一个调用的任何输入文件都需要被本地化到/inputs目录中。Cromwell将尝试三种不同的本地化策略，直到其中一个成功：硬链接、软链接、复制。硬链接在不同的物理磁盘之间不起作用，软链接在docker中不起作用。如果众多任务使用相同输入，那么复制就会使用大量空间（且耗时）。
但是Nextflow支持docker中使用软链接，速度更快、空间更省。另外在AWS batch上，可以直接挂载数据库，就支持写入索引、数据库文件的AWS S3路径了。

改进文件传输后（原来数据库是挂载s3，现在直接从本地引用了），虽然不知道为什么硬链接仍然失败，但是本地复制过来快了很多，时间缩短到四分钟左右。

另外，控制台输出差别也很大（实际上是两个动图，wdl的会刷屏）：


Cromwell的server模式我也试了，可视化比较好之外，效率没什么差别。

结论

nextflow的表现比较理想，符合我们的实际情况；并且我们成功在AWS上部署批量计算，跑了200个样本。（关于nextflow，学习成本不低，但是掌握了那些看似复杂的操作符、内置函数后，一切会变得非常轻松；但是其中要踩的坑不少，特别是云计算，互联网基本没有相关教程，讨论也很少，有机会将为大家更新）