第1章 Nextflow 简介与核心概念

Nextflow 是什么？说白了，它是一个数据驱动的并行计算框架。你写一个脚本，它能帮你把任务分发到各种计算环境——本地、SLURM、AWS Batch、Kubernetes。我最早接触时觉得它就是个包装 shell 的工具，后来才发现它真正解决的是 流程的可复现 和 依赖管理。

讲个真事。之前团队有个 RNA-seq 分析流程，总共 20 多个步骤，每个人跑出来结果都不一样。有的用了不同软件版本，有的中间文件没清理干净。最后我换成 Nextflow，把每个步骤封装成 process，输入输出用 channel 串起来——从此再没出过版本冲突。嗯，今天就带你看看它的核心套路。

1.1 为什么需要 Nextflow

传统流程管理你肯定遇到过：Shell 脚本串行、Makefile 容易出错、手动清理临时文件。尤其当你需要跑大规模数据时，并行、重试、缓存这些事儿能把你逼疯。

  • 可复现性：环境用容器或 Conda 锁定，任何人任何机器跑结果一致。
  • 并行计算：自动拆分任务，不管你用本地多核还是 HPC 集群。
  • 缓存机制：只重跑发生变化的步骤，省时间省经费。
  • 模块化：每个 process 独立，能单独测试、复用。

我习惯把 Nextflow 看作一个“管道工”——它把原始数据、中间文件、日志、容器全部串联起来，你只需要定义每一段做什么。

1.2 核心概念速览

讲概念之前，先看一个最小例子跑起来。你装好 Nextflow 之后，创建一个 hello.nf：

#!/usr/bin/env nextflow

process sayHello {
    exec """
        echo "Hello, Nextflow!"
    """
}

workflow {
    sayHello()
}

运行 nextflow run hello.nf，就能看到输出。这看起来很简单，但背后的概念已经全部到场了。我们来拆解。

Process（进程）

一个 process 就是一个独立计算单元。它定义输入、输出、脚本和资源需求。每个 process 默认会在自己的工作目录跑，互不干扰。我个人觉得，写 process 最舒服的地方是——你只管写命令，Nextflow 帮你处理临时文件和并发。

我曾经把一个 300 行的 shell 脚本拆成 10 个 process，每个 process 只干一件事。结果调试时定位问题只需要看一个 process 的日志，效率翻倍。

Channel（通道）

Channel 是 Nextflow 的“血管”。数据从一个 process 流向另一个 process 全靠它。你可以把 channel 理解为 异步队列——它发出数据后，不阻塞其他任务。

ch = channel.fromPath("*.fastq")
// ch 会逐个发射文件名给下游 process

Channel 有几种常见类型：value（单值）、queue（队列）、list（列表）。你想想看，如果你的输入是几百个文件，用 fromPath 自动匹配，比写在脚本里硬编码好用多了。

Workflow（工作流）

Workflow 块是编排的地方。它定义 process 的调用顺序、channel 的连接方式、以及参数传递。通常一个 workflow{} 就是一张 DAG（有向无环图）。

workflow {
    input_ch = channel.fromPath(params.input)
    process1(input_ch)
    process1.out |> process2
    process2.out |> view
}

这个语法有点像管道 |，但 Nextflow 用的是 |>（channel 操作符）。我刚开始老写错，后来习惯把每个 process 的输出都显式地用 .out 取出来，再连到下一个。

Operator（操作符）

Operator 是对 channel 做变换的小工具。比如 .map、.filter、.branch、.groupTuple。它们让你不用写额外 process 就能处理数据流。

ch.map { it -> "$it.processed" }
ch.branch {
    large: it.size > 1MB
    small: true
}

说实话，branch 操作符是我最喜欢的一个——它能把同一份数据按条件分流到不同处理路径，特别适合分样本类型或分质控结果。

缓存与复用

Nextflow 默认给每个 process 打一个哈希值（包含输入文件、参数、脚本内容等）。如果下次运行哈希没变，它就跳过该 process，直接复用上一次的结果。这就是缓存复用的本质。

注意：缓存只对 文件路径和文件内容 有效。如果你修改了 process 里的参数但没改脚本字符串，缓存可能不会触发更新。我建议把关键参数通过 @params 注入，这样参数变化会反映到哈希里。

1.3 参数优化的意义

参数优化表面上是为了调出更好的结果（比如 BLAST 的 E-value、比对工具的错配率）。但在 Nextflow 中，参数优化还涉及 如何让缓存更聪明。比如你想尝试不同的 k-mer 大小，如果每次改参数都全重跑，那你就没法复用之前的中间结果。我经历过一个项目，跑全流程需要 3 天，参数试了 10 次，后来发现只要用 param.something 控制 process 的输入，再配合 cache: "deep" 策略，重复运行只花了 20% 的时间。

后面几章我们会深入讲参数传递、缓存命中策略、以及如何用 publishDir 管理输出——但今天先把概念框架搭好。

1.4 核心概念关系图

下面这张 SVG 图帮助你一眼看清这些概念之间的层次和流动。

Nextflow 核心概念关系图 Workflow Process Channel Input Script Output Operator 缓存 / 复用 参数优化 → 命中缓存 → 节省时间 💡 核心思想 每个 Process 独立运行， 通过 Channel 串连。 缓存基于输入和脚本哈希。

1.5 核心概念一览表

概念 作用 个人常用场景
Process 独立计算单元 封装比对、质控、统计等单步任务
Channel 数据流管道 把输入文件列表推给 process
Workflow 流程编排 定义 process 顺序、分支、合并
Operator 数据变换 map/filter/branch 操作 channel
缓存 避免重复计算 参数调优时保留已跑过的中间结果
刚上手 Nextflow 最常犯的错误：在 process 里用绝对路径读写文件。正确的做法是把所有输入输出都通过 channel 传递，这样 Nextflow 才能追踪缓存。

1.6 小结

这一章我们把 Nextflow 的核心骨架搭起来了。你只要记住四个词：Process、Channel、Workflow、Cache。后面的章节会一一深入，包括如何用 DSL2 模块化、如何配置 executor、如何精准控制缓存命中等。但我建议你先动手跑一下 hello.nf，感受一下 process 是怎么执行的——亲眼看到 .nextflow 目录下生成的缓存文件，比看多少文档都管用。

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