3. 任务编排与调度的基本概念

在生物数据分析中，一个看似简单的“比对—去重—变异检测”流程，背后往往涉及几十个命令、上百 GB 中间文件、不同规格的计算节点以及若干外部数据库。要让这些环节在正确的时间、正确的机器上、以正确的依赖顺序执行，就需要一套清晰的概念体系来支撑。本节围绕 DAG、工作流、任务、作业、资源、调度器、执行器与编排引擎这八个核心概念展开，厘清它们各自的职责与相互关系。

一、从 DAG 到工作流：描述“做什么”

DAG（有向无环图）是任务编排的数学基础。它由节点和有向边组成：节点代表一个计算单元，有向边代表依赖关系，即“先做 A 才能做 B”。之所以要求“无环”，是因为一旦出现循环依赖，流程将永远无法启动——例如“比对结果依赖去重结果，去重结果又依赖比对结果”，调度器无法找到合法的执行起点。在生物信息流程中，DAG 的典型形态是：原始 FASTQ 经过质控、比对、排序、去重、变异检测，最终生成 VCF，每一步都指向下一步，没有回边。

工作流（Workflow）是 DAG 在具体业务场景中的实例化。它不仅包含依赖结构，还绑定了具体的工具、参数、输入输出路径和运行环境。例如，一个 RNA-seq 工作流会明确指定：质控用 fastp，比对用 STAR，定量用 featureCounts，参考基因组用 GRCh38，线程数用 8。工作流回答的是“用什么做、按什么顺序做”。

二、任务与作业：描述“做一次”

任务（Task）是工作流中的最小可执行单元，通常对应一条命令或一个脚本。例如“用 STAR 将 sampleA_R1.fq 和 sampleA_R2.fq 比对到 GRCh38”就是一个任务。任务具有明确的输入、输出、参数和资源需求。

作业（Job）是任务在调度系统中的一次具体提交。同一个任务在不同样本上运行，会产生多个作业。例如，10 个样本的比对任务会生成 10 个作业，每个作业有独立的作业 ID、状态（等待、运行、成功、失败）和日志。任务定义“怎么做”，作业记录“这一次做得怎么样”。

三、资源：描述“需要什么”

资源（Resource）是任务运行所需的计算条件，主要包括 CPU 核数、内存、GPU、磁盘空间、运行时限以及特定软件环境。在生物数据场景中，资源需求差异极大：fastp 质控可能只需 4 核 8 GB，而全基因组比对可能需要 32 核 128 GB。调度器必须知道每个任务的资源需求，才能把它放到合适的节点上。资源声明不准确会导致两种典型故障：声明过小，任务被系统杀死（OOM）；声明过大，节点利用率低下，排队时间变长。

四、调度器、执行器与编排引擎：描述“怎么跑起来”

调度器（Scheduler）负责决定“哪个作业在什么时候、在哪台机器上运行”。它维护作业队列，监控节点资源，处理依赖关系，并在作业失败时按策略重试。常见的调度器包括 Slurm、PBS、SGE 以及 Kubernetes 的调度组件。调度器的核心能力是：依赖满足后触发、资源匹配后分配、失败后按策略处理。

执行器（Executor）是真正在目标节点上启动进程、运行命令、收集退出码和日志的组件。它接收调度器分配的任务，准备运行环境（如容器、conda 环境），执行命令，并把结果状态回传给调度器。执行器关注的是“这一条命令有没有跑完、跑对”。

编排引擎（Orchestration Engine）是更高层的协调者，它把工作流定义解析成 DAG，生成任务和作业，提交给调度器，并跟踪整个流程的进度。Nextflow、Snakemake、Cromwell、Argo Workflows 都属于编排引擎。编排引擎通常还负责输入输出管理、参数传递、失败重试、日志聚合和断点续跑。

五、八个概念如何协同：一次 RNA-seq 流程的完整链路

假设我们要处理 10 个 RNA-seq 样本，参考基因组为 GRCh38，流程为 fastp 质控、STAR 比对、featureCounts 定量。用 Nextflow 编写工作流后，编排引擎会做以下事情：

1. 解析工作流脚本，构建 DAG：每个样本的 fastp 节点指向该样本的 STAR 节点，STAR 节点指向 featureCounts 节点，10 个样本的 featureCounts 节点汇聚到最终汇总节点。
2. 为每个节点生成任务，并实例化为 30 个作业（10 样本 × 3 步）。每个作业携带资源声明，例如 STAR 作业声明 8 CPU、32 GB 内存、2 小时时限。
3. 将作业提交给调度器（如 Slurm）。调度器检查依赖：样本 A 的 STAR 作业必须等样本 A 的 fastp 作业成功后才能进入就绪队列。
4. 调度器根据节点空闲资源，把就绪作业分配到满足 8 CPU、32 GB 的节点上。
5. 执行器在目标节点上加载 STAR 的 conda 环境或容器镜像，执行比对命令，捕获标准输出和错误日志，返回退出码。
6. 编排引擎收到成功状态后，解锁下游 featureCounts 作业；若失败，则按重试策略重新提交，或标记流程失败并保留中间结果以便断点续跑。

在这个链路中，DAG 决定“顺序”，工作流决定“内容”，任务和作业决定“粒度”，资源决定“门槛”，调度器决定“位置和时机”，执行器决定“落地执行”，编排引擎决定“全局协调”。任何一个环节定义不清，都会导致流程卡住、资源浪费或结果不可复现。

六、常见误区与判断依据

初学者容易把“任务”和“作业”混为一谈，导致日志排查时无法定位是定义问题还是某次运行的环境问题。判断方法很简单：如果修改的是命令、参数或依赖关系，那是在改任务定义；如果只是重新提交、换节点、改资源，那是在操作作业。另一个常见误区是忽略资源声明的准确性。建议在正式跑全量数据前，先用 1～2 个样本做资源画像：记录实际峰值内存和运行时间，再按 1.5～2 倍余量声明。这样既能避免 OOM，又不会让作业长期排队。

理解这八个概念之后，后续选择编排工具、设计流程结构、排查调度故障时，就能快速判断问题出在哪一层：是 DAG 设计有环，是资源声明不足，是调度器队列拥堵，还是执行器环境缺失。这种分层定位能力，是生物数据任务编排与调度工程中最基础也最实用的技能。