慎用snakemake的checkpoint模式

背景

最近在用snakemake实现一个病毒的分析流程过程中，遇到了需要根据某个rule的执行结果选择后续分析步骤的情景。根据过去的经验和snakemake官方文档，可以用checkpoint实现，即“数据依赖的条件执行”。

实现分析流程后，进行了测试。虽然总计有998例样本，但是待执行的分析皆为轻量级分析，但是整个流程执行的非常缓慢。推测与checkpoint模式有关（每个执行成功的job都触发DAG的重新评估，造成不必要的算力损耗）。

简单搜索后，找到了Snakemake very slow on large workflow #2354。这个问题是对于大型workflow，snakemake由于需要隐式匹配大量的输入、输出，导致分析速度很慢。根据#2938，可用参数--scheduler更换调度算法。

但上述问题与checkpoint没有明显关系，所以我决定自行探索这个模式的影响。

测试方案、代码及结论

使用轻量级的命令，例如echo来模拟现实世界的分析任务，比较checkpoint、普通模式的区别。整个测试方案、结果见：snakemake-checkpoint-benchmark（https://github.com/conanyangqun/snakemake-checkpoint-benchmark）。

对于3801个任务，普通模式用时1m48s，checkpoint模式用时9min7s，约为4.5倍。

可以预见的是，随着样本数目提升，这种情况会更加恶化。这是重新构建DAG导致的弊端。所以，慎用snakemake的checkpoint。

后续

我接触了OpenWDL、snakemake、nextflow三门流程语言。

WDL最初由broad开发，后转为开源，其本身只是流程语法，具体的执行器有很多，例如cromwell、miniWDL。在我看来，它是融合BT、IT的一种不错的解决方案（相信broad作为顶尖研究锁的能力）。

nextflow的底层为groovy语言（再底层为java），ONT的epi2me平台用的较多。目前我对此语言了解不多，仅限于能看懂分析的地步。但其诸多特性与WDL类似，都是snakemake缺少的。

snakemake扩展了python语法，因此学习曲线平缓。其模仿了makefile的形式，隐式判断rule之间的输入、输出关系。但也正因为这种隐含的关系导致被诟病。EPI2ME有一篇blog介绍了他们为什么选择了nextflow而非snakemake。

于我本人来讲，snakemake可以帮助我快速的搭建原型，适合一些小型、轻量级流程分析。如果从长远来看（流程模块化、长期维护），我必然会迁移到其他流程语言去。好在这些语言的语法都比较简单，学习成本不高。只是目前还没有迁移的必要而已。

另外，没人规定一个人只可以擅长一门语言……