生信工作流框架搭建 | 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是这三者中风格最优雅的，但还是忍痛放弃了）

测试目标 分别使用WDL、nextflow编写流程，实现qc去宿主+组装这两个步骤，并行处理两个样本
测试环境 AWS EC2实例 CPU：AMD EPYC 7R32 32vcpu 16cores，3.3GHz 内存：64G 硬盘：1T
输入 两组双端测序病毒样本，随机抽样10000，形如 SRR10680511_1.fastq.gz SRR10680511_2.fastq.gz ，方便输入直接生成列表
目标输出 1k.contigs
其他指标 错误处理、任务复现、运行时间
测试的时候其实我对nextflow已经比较熟练了，本地运行没有任何问题。wdl则是问题频发。

测试结果 WDL nextflow
目标输出 由于使用docker，只能在Cromwell执行目录下输出 可以使用publishDir功能输出到外部文件夹（且支持软链接输出）
输出路径 /home/zhengyuning/cromwell/cromwell-executions/virus/31f19b63-2429-4d29-abef-801ca1d7f491/call-assembly/shard-0/execution/out/02.assembly/SRR10680511/1k.contigs.gz /home/ec2-user/nftest(任意文件夹)/02.assembly/SRR10680511/1k.contigs.gz
错误处理 有，支持两种故障模式：NoNewCalls (default) Cromwell不会在作业失败时开始任何新作业。Cromwell仍将监视其余的作业，直到它们完成（无论成功与否）。ContinueWhilePossible尝试运行尽可能多的作业，直到无法启动更多作业。完成所有正在运行的作业后，工作流将失败。 有。errorStrategy指令定义进程如何管理错误条件。有四种策略：默认情况下，当执行的脚本返回错误状态，进程立即停止。这反过来又迫使整个流程终止。Finish：在引发错误条件时启动有序的流程关闭，等待任何已提交作业的完成。Ignore：不会在错误条件下停止，它只是报告一条消息，通知错误事件。Retry：允许重新提交流程以执行返回错误条件，失败进程重新执行的次数由maxRetries和maxErrors指令定义；更复杂的策略，具体取决于任务退出状态，可以使用动态定义其他参数值
任务复现 未实现（docker摘要查找失败，无法缓存） 可实现
运行时间 4m15s 1m39s
其他 无法随时中止运行！有时出现，前台终止，但后台docker仍然在执行命令的情况 Ctrl+C随时中止
一开始，wdl跑这样的流程需要接近一个小时，观察发现，真正在docker容器跑的程序只需要几分钟。
因此很可能耗时在文件传输上。

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

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

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

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

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