Cromwell引擎分析
如果有兴趣，可以跟我联系交流：这里
[toc]
一、Cromwell简介
Cromwell是由Broad Institute开发的一个workflow引擎，一般在科研领域用的比较多，尤其是基因组学流行起来之后，生物信息工程师们跑分析流程经常会用到。Cromwell官方对介绍是“Cromwell is a Workflow Management System geared towards scientific workflows.“。当前AWS和阿里云对Cromwell都进行了支持，这也代表行业内对Cromwell的一种认可。
二、架构解析
Cromwell的架构说起来也比较简单，如上图，
- 客户编写Script来定义一个流程中的每个步骤分别是什么，他们是怎么一步一步相互依赖执行的。Script的语言规范有好几种，Cromwell支持WDL和CWL两种语法。参考：Language Support - Cromwell
- Cromewell Server接收到这个Script后就会解析它，然后根据里面的定义去拆分每个子任务，然后提交到后端的计算资源池去执行。Cromwell称其为Backend，不同的backend实现不同的计算方式。
- Backend计算完毕后将执行结果通知给Cromwell Server。一个流程就完成了。
向Cromwell Server提交任务有两种方式
- 通过命令行工具（Command Line Tool）进行提交。参考：CommandLine - Cromwell
- 通过Cromwell Server的Restful API进行提交。参考：RESTAPI - Cromwell
Cromwell最值得的了解的就是它的backend
- Local模式，就是在运行在Cromwell Server同一台服务器上，该模式的缺点就是：整个计算资源只是当前这台服务器。如果你所需的计算资源本来也多，那么这种模式是很好的，而且容易调试问题。参考：Local - Cromwell
- AWS和阿里云的Batch Compute服务，Google的Google Genomics Pipelines，这几个服务本质上都是一样的。这几个厂商实现了一个基于云的计算服务，你只要将任务提交进去就可以了，而不用操心服务器运维和计算资源不够用的问题，你用多少资源就付多少钱。参考：AWS Batch Backend - Cromwell，BCS - Cromwell，Google - Cromwell。这里还要提一点，既然使用了云厂商的批处理的计算服务，那么存储服务当然也得用他们的，比如你用了AWS的BatchCompute就得搭配用它的S3对象存储服务，你用了阿里云的BatchCompute服务就得用它的OSS对象存储服务。
- 基于Kubernetes集群的模式，有 Volcano - Cromwell 和 TESK
- 基于Spark的模式，而Spark也有两种部署方法，即 单机模式和集群模式，参考：Spark - Cromwell
- HPC集群模式，HPC - Cromwell
Local模式简单易懂，BatchCompute模式是云厂商现成的，直接阅读他们的手册即可，下面分别介绍后面3种模式。
三、基于Kubernetes集群的模式
基于kubernetes来组建集群是当前互联网公司经常选择的一种方式，因为有很好的性能和扩展性，还有庞大的开源社区，文档丰富，遇到问题解决起来也方便。
Volcano
Volcano 是华为开源的一个基于 kubernetes 的编排引擎。团队开发Volcano的目的是为了弥补Kubernetes在深度学习、大数据计算场景下的不足而增强了其在计算任务批量处理方面的功能，比如计算任务的批量创建及生命周期管理、批量调度等。目前Volcano已经支持如TensorFlow、MXNet、PaddlePaddle这几个主流的深度学习框架，目前华为、蘑菇街、VIVO、百度、菜鸟、京东等公司在使用。
通过他的架构图了解到，他是基于kubernetes中的CRD实现了对Job的抽象和控制，这一点跟Argo项目倒是非常像。但是通过对Volcano的Document和examples的研究发现他跟workflow没有太大的关系，如果你非要用它来实现一个workflow可能生硬一点麻烦一点也可以做到，但是人家不是专门为了跑workflow而开发的。
TESK
我们先来看 TES，全称是：Task Execution Scheme (TES) ，是 GA4GH组织（ Global Alliance for Genomics and Health）为批处理任务执行系统定义的一套规范。该规范定义了，一个任务由一系列输入文件 + 一系列docker镜像与命令 + 一系列输出文件 + 一些日志和元数据 组成。TES的规范定义example可以参考这里。
{
"inputs": [
{
"url": "http://adresss/to/input_file",
"path": "/container/input"
}
],
"outputs" : [
{
"url" : "file://path/to/output_file",
"path" : "/container/output"
}
],
"executors" : [
{
"image" : "ubuntu",
"command" : ["md5sum", "/container/input"],
"stdout" : "/container/output"
}
]
}
GA4GH组织一共提出过4个规范
- the Data Object Service (DOS),
- Tool Registration Service (TRS),
- Workflow Execution Service (WES)
- the Task Execution Service (TES)
实现TES规范的产品有
再来看TESK，全称是：Task Execution Service on Kubernetes，是一个TES标准的具体实现，是一个运行在kubernetes架构之上的任务执行引擎。
TESK项目由3个project组成
- https://github.com/EMBL-EBI-TSI/TESK：文档和部署文件
- https://github.com/EMBL-EBI-TSI/tesk-api：API
- https://github.com/EMBL-EBI-TSI/tesk-core：执行workflow的核心逻辑代码
通过其官方的说明和架构图，task-core的源代码，我们可以了解到
- API pod是一个常驻型的pod，负责接收任务请求，然后给kubernetes创建job。
- 每次创建job的时候，都会启动一个taskmaster pod，这个pod来负责运行executor来处理input file，然后输出output file。这里，如果有多个executor的话，每个executor都是按照顺序一个一个执行的。整个workflow执行完毕后，PVC和Taskmaster都被销毁。
- 每个job都会有自己独立的taskmaster和PVC。
代码：executor的执行逻辑：
for executor in data['executors']:
run_executor(executor, args.namespace, pvc)
整体来看，这个架构很简单，容易掌控，可以处理一些简单的任务流程。缺点也很明显，worklow太简单，只能one-by-one，中间无法实现任务并行，不能实现更加复杂灵活的调度策略，无法充分利用服务器的性能。在github上TESK项目的star和fork都很少，也说明了它在行业里并不流行。
Argo
Cromwell官方文档里没有提Argo，但是这里要简单介绍一下这个引擎，因为这个引擎是专门设计用来跑workflow的，而且所使用的技术栈跟Volcano有类似之处。
Argo是一个基于kubernetes的workflow引擎，它是美国的软件巨头Intuit带头开发的开源软件，通过Argo可以跑CI和CD，可以跑workflow或者Pipeline，有Adobe、阿里云、蚂蚁金服、特斯拉、Redhat等大公司都在用。
从v2.5开始，Argo支持“local”和“hosted”两种部署模式，v2.5之前只能是Hosted这种模式。
我们使用Argo-Cli命令行或者调用Kubernetes的RestfulAPI来创建workflow任务。其他关于argo架构的信息参考这里。
这里有非常多的workflow的语法例子：argo/README.md at master · argoproj/argo
之前，为了让Argo在执行完workflow之后自动删除Pods我给项目提交过一个PR。
然而，官方Cromwell是不支持Argo作为backend的，甚至Argo和Cromwell在功能上是有重叠的，例如 都支持接受workflow的提交然后生成Job，然后交给自己的Backend进行执行，Cromwell的Backend上面已经提到了，而Argo的Backend其实就是Kubernetes。所以，Cromwell和Argo两个框架选择其一即可，我公司的情况是基于Argo做了一些简单的二次开发对接到公司自己的业务流程里去了。针对Argo我还会单独开一片文章来讲解。
四、基于Spark的模式
稍后待续
五、HPC集群模式
稍后待续