2. 工作流抽象模型对照

迁移工作流时，最容易踩的坑不是语法不熟，而是把 Snakemake 的思维直接翻译成 Nextflow 的写法。两者虽然都能描述“先做什么、后做什么”，但底层抽象完全不同：Snakemake 以规则（rule）为基本单元，通过文件名匹配隐式构建依赖图（DAG）；Nextflow 以进程（process）为执行单元，通过通道（channel）显式传递数据。理解这一层差异，才能判断哪些代码可以直译、哪些必须重构。

Snakemake：以文件为契约的隐式 DAG

在 Snakemake 中，一条 rule 的核心是输入文件、输出文件和执行命令。依赖关系不写在代码里，而是由“某条规则的输出恰好是另一条规则的输入”这一文件名匹配关系自动推导出来。例如：

rule trim:
    input:  "raw/{sample}.fastq.gz"
    output: "trimmed/{sample}.fastq.gz"
    shell:  "fastp -i {input} -o {output}"

rule align:
    input:  "trimmed/{sample}.fastq.gz"
    output: "bam/{sample}.sorted.bam"
    shell:  "bwa mem ref.fa {input} | samtools sort -o {output}"

这里 trim 的输出路径与 align 的输入路径完全一致，Snakemake 据此建立一条有向边。通配符 {sample} 在运行时被具体值替换，形成多个独立的任务实例。整个 DAG 是隐式的：你声明的是“文件长什么样”，调度器负责推导“谁先谁后”。这种设计让局部修改很自然——改一个输出路径，依赖关系自动重连。

但隐式依赖也有代价。当规则数量增长到几十条、通配符出现嵌套或约束时，DAG 的推导会变得难以预测；调试时往往需要 --dry-run 或 --dag 才能看清实际执行顺序。此外，Snakemake 的并行度由可用核心数和 DAG 拓扑共同决定，数据在规则之间以文件形式落盘，中间产物会占用大量磁盘 I/O。

Nextflow：以通道为骨架的显式数据流

Nextflow 把“数据”和“计算”分开描述。process 定义一段计算逻辑，channel 定义数据的来源、流向和组合方式。依赖关系通过通道的输入输出显式连接：

process TRIM {
    input:  path reads
    output: path "trimmed/*.fastq.gz"
    script:
    """
    fastp -i ${reads} -o trimmed/${reads.baseName}.fastq.gz
    """
}

process ALIGN {
    input:  path trimmed
    output: path "bam/*.sorted.bam"
    script:
    """
    bwa mem ref.fa ${trimmed} | samtools sort -o bam/${trimmed.baseName}.sorted.bam
    """
}

workflow {
    Channel.fromPath("raw/*.fastq.gz")
        | TRIM
        | ALIGN
}

这里 | 操作符把 TRIM 的输出通道接到 ALIGN 的输入通道，形成一条数据流水线。每个 process 的实例数由输入通道中的元素个数决定，而不是由文件名匹配推导。通道可以是队列通道（每个元素独立处理）、值通道（单值广播）或组合通道（笛卡尔积、join、groupTuple 等）。这种显式模型让数据流一目了然，也更容易做条件分支、并行拆分和结果聚合。

Nextflow 的中间结果默认不落盘，而是通过通道在进程间传递（实际仍可能经过临时文件或内存队列，取决于执行器和配置）。这减少了磁盘压力，但也意味着调试时不能像 Snakemake 那样直接去目录里找中间文件，需要借助 -with-trace、-with-report 或 view 操作符观察通道内容。

核心对照：依赖表达与数据传递

Snakemake：rule + 文件匹配 隐式 DAG（由文件名推导） rule trim out: trimmed/{s}.fq rule align in: trimmed/{s}.fq 文件名匹配 中间结果落盘 → 磁盘 I/O 较大 Nextflow：process + channel 显式数据流（由通道连接） process TRIM input: path process ALIGN input: path | 通道连接 中间结果走通道 → 减少落盘 迁移时的关键映射关系 Snakemake 概念 Nextflow 对应 迁移注意点 rule + input/output process + input/output 输出需显式 emit 通配符 {sample} Channel.fromPath / fromFilePairs 通道元素即实例 文件名匹配依赖 | 操作符连接通道 依赖显式化，需重构

迁移中的实际判断

把上述对照落到具体迁移动作上，可以按以下顺序判断：

  • 先识别数据入口。Snakemake 的 input 中哪些是通配符展开的样本列表？在 Nextflow 中对应 Channel.fromPath 或 Channel.fromFilePairs。如果样本有配对关系（如 R1/R2），用 fromFilePairs 比手动拼路径更可靠。
  • 再判断依赖是“文件级”还是“数据级”。如果两条规则之间只靠文件名匹配，且中间文件需要保留，迁移时可以在 process 中显式输出文件并让通道传递路径；如果中间文件只是过渡，考虑用 | 直接串联，减少落盘。
  • 处理聚合与分支。Snakemake 中常用 expand 或 lambda 生成输入列表，Nextflow 中对应 combine、join、groupTuple 等操作符。例如把多个样本的 BAM 合并成一个 VCF 输入，需要用 groupTuple 按样本分组后再送入变异检测 process。
  • 检查资源与执行器。Snakemake 的 threads、mem_mb 等资源声明，在 Nextflow 中对应 process 的 cpus、memory 指令。注意 Nextflow 的资源是“每个任务实例”的，而 Snakemake 的 threads 也是按规则实例计算，两者语义接近，但 Nextflow 需要配合 executor 配置才能生效。
迁移时不要追求“一行对一行”的翻译。Snakemake 的隐式 DAG 在 Nextflow 中往往需要拆成“通道构建 + process 定义 + 工作流连接”三段。先画出数据从原始文件到最终结果的通道流向，再逐个填充 process，比直接改写 rule 更不容易遗漏依赖。

最后需要留意一个常见误区：Nextflow 的 process 并不是“自动并行”的，并行度取决于通道中元素的数量和执行器的可用资源。如果输入通道只有一个元素，即使 process 内部可以拆分，也不会自动产生多个任务实例。这一点与 Snakemake 中通配符自动展开多个 job 的行为不同，迁移时需要显式地用 split、flatten 或按样本构建通道来保证并行粒度。

← 上一章 📖 返回目录 下一章 →