Cromwell 简介：这东西到底能干什么？

我第一次接触 Cromwell，是几年前在一个基因组分析项目里。当时团队手上有几十个样本要跑 GATK Best Practices，本地集群排队排到天荒地老。有人提了一句：要不试试 Cromwell？

结果一试就回不去了。

Cromwell 是个开源的工作流管理系统，说白了，它负责「把你写好的工作流跑起来」。你提供 WDL 或 CWL 描述文件，它帮你调度任务、管理依赖、处理失败重试、收集日志。你不需要自己写复杂的 shell 脚本来编排任务，也不用操心哪个任务先跑、哪个任务后跑。

它的核心逻辑很简单：

• 工作流定义：你用 WDL（Workflow Description Language）或 CWL 写清楚每个任务的输入、输出、命令。
• 执行后端：Cromwell 把任务扔给不同的计算环境——可以是本地机器、SLURM 集群、Google Cloud Batch、AWS Batch，或者阿里云的 BatchCompute。
• 状态管理：它会记录每个任务的运行状态，失败后自动重试，甚至支持断点续跑。

举个例子，一个简单的 WDL 工作流大概长这样：

workflow myWorkflow {
    call myTask
}

task myTask {
    input {
        File inFile
    }
    command {
        echo "Hello, Cromwell!" > output.txt
    }
    output {
        File outFile = "output.txt"
    }
}

看着挺清爽吧？但真正用起来，坑可不少。我后面会慢慢讲。

为什么需要混合云执行？

你想想看，如果你的工作流永远跑在本地集群，那闭着眼睛用 Cromwell 就行。但现实是——

• 本地资源有限：高峰期任务排队，一个样本等三天。
• 云端弹性好：突发流量可以一键扩容，用完释放，按量付费。
• 数据合规要求：有些数据必须留在本地，不能上云。
• 成本控制：长周期任务放本地，短期爆发任务放云端，更划算。

混合云执行就是让 Cromwell 同时管理本地和云端的计算资源。任务调度时，你可以指定某些任务在本地跑，某些任务在云端跑，甚至动态决定——比如本地集群忙的时候自动 spill over 到云端。

我曾经帮一家基因检测公司搭过这套架构。本地有 500 核 SLURM 集群，云端接阿里云 BatchCompute。平时日常任务用本地跑，遇到季度大促（批量样本涌入），自动触发云端扩容。系统跑了一年多，算下来节省了 40% 的云资源费用。

适用场景：哪些项目该用混合云？

场景	推荐度	说明
周期性大批量数据分析（如基因组季度分析）	⭐⭐⭐⭐⭐	突发流量靠云，日常靠本地
数据敏感且不能出域	⭐⭐⭐⭐	本地跑核心分析，云端跑脱敏后处理
需要 GPU 但本地 GPU 稀缺	⭐⭐⭐⭐	云端按需租 GPU，用完释放
单次超大计算（如全基因组组装）	⭐⭐⭐	数据上传成本高，需评估
实时线上服务	⭐	Cromwell 不是为实时设计，别硬上

常见误区：我踩过的坑

我刚开始用 Cromwell 做混合云时，犯过不少低级错误。列几个典型的，你千万别再掉进去。

核心知识图谱

下面这张图帮你理清 Cromwell 混合云执行的核心模块。我建议你收藏它，后面章节会反复参考。