📚 课程目录第3章 DSL2核心概念

DSL2 核心三剑客：Process、Channel、Workflow

说实话，我第一次接触 Nextflow 的 DSL2 时，第一个感觉就是「清爽」。之前用 DSL1 写 pipeline，总有一种在写脚本的感觉——全局变量满天飞，流程逻辑和参数传递混在一起，改个输入还得翻半天代码。

DSL2 把这事儿彻底理清了。核心就三个概念：process、channel、workflow。你只要搞懂这三个东西怎么配合，几乎能应付 90% 的日常质控场景。

Process：最小的执行单元

Process 就是 pipeline 里真正干活的「工人」。我自己的理解，它就是一个黑盒子——给它输入，它跑脚本，然后吐出输出。至于里面是跑 FastQC、MultiQC 还是 cutadapt，process 都不关心，它只负责「执行」。我们在项目中一般把每个质控步骤单独封装成一个 process，这样哪个步骤出问题了，单独修那个 process 就行，不会牵连其他模块。

一个典型的 process 长得像这样：

process FASTQC {
    input:
    path read_file

    output:
    path "${read_file.baseName}_fastqc.{zip,html}"

    script:
    """
    fastqc -o ./ ${read_file}
    """
}

嗯，这里要注意：input 和 output 声明是 DSL2 的命根子。输入声明告诉 Nextflow 「我需要什么」，输出声明告诉 Nextflow 「我生产什么」。上下游的依赖关系，全靠这两句话串联，不需要你手动写 any→anything 那种隐晦桥接。

有什么技巧？ 我个人习惯在 process 的 input 里，把原始数据路径和元数据分开。比如把样本名、批次号塞到一个 tuple 里传给 process，这样下游处理时能灵活按样本或批次切片，不用事后 grep 文件路径里的字符串。

Channel：数据流的动脉

Channel 你可以把它想象成一条「传送带」。上游 process 产生的文件、元数据、数值，全都要通过 channel 往下游送。DSL2 里 channel 的创建方式非常直观：

// 从文件列表创建 channel
ch_fastq = Channel.fromPath("data/*.fastq.gz")

// 从值创建 channel
ch_params = Channel.value("human")

// 组合 channel
ch_combined = ch_fastq.combine(ch_params)

我在项目中遇到过最经典的一个坑，就是 channel 的「一次性消费」特性。这个特别重要——DSL2 的 channel 默认是只消费一次的。你没法把它当作一个全局变量来反复读取。如果你在一个 workflow 里两次使用了同一个 channel，第二次会拿到空的。

避坑指南： 我曾经写过这样一段代码：在 workflow 里两次调用同一个 process，参数都是同一个 channel，结果第二次调用时 process 压根没启动。因为 channel 里的数据已经在第一次被消耗完了。解决办法很简单：用 .view() 或者 .branch() 做多路分发，或者用 .set{ ch_xxx } 赋值给一个带名字的 channel 变量，这样能反复引用。

DSL2 的 channel 操作符非常丰富。我个人最常用的是 .map、.filter、.combine 和 .groupTuple。有了它们，你几乎可以用 channel 完成所有数据的预处理、转换、分组，不需要额外写 Python 或 R 脚本去整理文件清单。

Workflow：流程的骨架

Workflow 就是 DSL2 里把 process 和 channel 组装起来的「蓝图」。它定义了一个 pipeline 的执行顺序和数据流向。在 DSL1 里，这种关系是通过 process 名称和 params 的隐式连接实现的；DSL2 则把流程逻辑显式地写在了 workflow 块里。

看一个最简单的 workflow：

workflow {
    // 定义输入 channel
    ch_reads = Channel.fromFilePairs("data/*_{R1,R2}.fastq.gz")

    // 调用 process
    FASTQC(ch_reads)
    ch_fastqc_res = FASTQC.out

    // 数据汇总
    MULTIQC(ch_fastqc_res.collect())
}

这个结构我特别喜欢——它把「数据从哪里来」和「数据到哪里去」写得清清楚楚。你看，workflow 内部就是一个数据流图，每个 process 的输入输出都通过 channel 变量显式传递，不会出现「我到底引用了哪个变量」这种疑惑。

  核心差异： DSL2 的 workflow 是 模块化可嵌套 的。你可以把一个复杂的质控流程拆分成几个子 workflow，比如 workflow PRE_QC、workflow CORE_QC、workflow POST_QC，然后在一个顶层 workflow 里组合它们。这种可组合性是 DSL1 完全不具备的。

DSL2 与传统 DSL 的核心差异

很多人问我：DSL2 到底比 DSL1 好在哪？我用一个表格总结一下。这些差异都是我切身体会：

对比维度	DSL1（传统）	DSL2
模块化	不支持，所有 process 和全局变量混在一起	支持，workflow 可嵌套、process 可导入
数据流	隐式传递，常使用 .from / .into 桥接	显式传递，通过 channel 变量直连
作用域	无模块作用域，所有变量全局可见	有作用域，process 内部变量外部不可见
输入输出	process 内使用 input: / output:，但无强制校验	强类型输入输出声明，Nextflow 在编译期检查一致性
复用性	低，需复制粘贴代码实现复用	高，可像函数一样调用已定义的 workflow 或 process
调试难度	高，隐式依赖关系导致排查困难	低，数据流图和 channel 变量可追溯
适配现代架构	较难，局限于单层流程	天然适配分布式、容器化、Kubernetes

你想想看，在 DSL1 里，如果有一天你改了某个 process 的输入名称，你得全局搜索所有引用了这个 process 的地方，一个一个改。DSL2 呢？只要在 workflow 块里调整一下 channel 的绑定关系就好了，process 内部完全不受影响。这就是「显式依赖」带来的维护红利。

一张图看懂 DSL2 核心关系

我把 process、channel、workflow 这三者的关系画成了一张结构图。它清晰地展示了数据从输入开始，如何通过 channel 流入 process，再通过 channel 流出，最终汇聚到 workflow 的出口。

看明白了吧？这张图表达的就是：数据从外部流入 Channel → Channel 驱动 Process 执行 → Process 产生新数据进入新的 Channel → 最终流向输出。整个循环被 Workflow 作用域包裹，DSL2 负责调度和编排，你只需要关注各个节点的逻辑即可。

一个小技巧： 在开始写一个大 pipeline 之前，我习惯先画一张类似上面的数据流草图（甚至在白板上画）。哪些数据需要 channel 承载，哪些 process 是串行的、哪些是并行的，画完心里就有底了。DSL2 的代码结构天然地映射这种流程图，不会出现「画出来是一回事，写出来是另一回事」的情况。

DSL2 的模块复用：像搭乐高

DSL2 最让我觉得痛快的一点，就是模块的复用。你可以把 process 和 workflow 定义在单独的 .nf 文件里，然后在主入口用 include 导入。比如：

// lib/FastQC.nf
process FASTQC {
    input:
    path read_file

    output:
    path "${read_file.baseName}_fastqc.{zip,html}"

    script:
    """
    fastqc -o ./ ${read_file}
    """
}

// 主 pipeline
include { FASTQC } from './lib/FastQC'

workflow {
    Channel.fromPath("data/*.fastq.gz")
           | FASTQC
           | view
}

这么做的好处很明显：你可以建立一个公司内部的「质控模块仓库」，每个模块独立维护版本。换了新版 FastQC，只要改一个文件，所有引用了这个模块的 pipeline 都会受益。我主导的一个项目里，团队就是靠这种模块化拆分，把一个原本 800 行的单一 .nf 文件拆成了 10 个模块，每人负责 2-3 个，协作效率提升了不止一倍。