1. Nextflow 简介：什么是 Nextflow、可重复性理念、批次质控场景概述

做生信分析的朋友，一定都经历过这种场景：跑完一个批量质控流程，换了台服务器或者换了个人重跑，结果对不上。日志丢了、路径写死了、软件版本不一致……最后只能在群里问“谁还记得上次用的什么参数？”

说白了，这就是可重复性没做好。

我在实际项目里踩过不少这样的坑。后来接触了 Nextflow，发现它把「可重复性」这个理念直接做进了框架里。今天我就带你从根源上理解 Nextflow 是什么，它的可重复性设计思路，以及为什么批次质控场景特别适合用它。

1.1 什么是 Nextflow

Nextflow 是一个数据驱动的并行计算框架。你不需要手动管理任务调度、中间文件传递、集群提交脚本——你只需要定义好流程，剩下的交给它。

它用 Groovy 语言写脚本，但运行在 JVM 上。我个人习惯用 .nf 文件来组织流程，看起来有点像 DSL（领域特定语言）但实际上就是 Groovy。

核心点：Nextflow 把每个计算步骤抽象成一个 process，通过 channel 传递数据，自动追踪输入、输出、参数和执行环境。

一个简单的 Nextflow 脚本长这样：

#!/usr/bin/env nextflow
nextflow.enable.dsl=2

params.reads = "data/*.fastq.gz"

process FASTQC {
    input:
    path reads_file

    output:
    path "fastqc_report.html"

    script:
    """
    fastqc ${reads_file}
    """
}

workflow {
    read_ch = Channel.fromPath(params.reads)
    FASTQC(read_ch)
}

看到没？你只需要声明输入、输出、要执行的命令，Nextflow 自动帮你并行化、调度、收集结果。我在第一次运行时最大的感受是——不用再手写 PBS/Slurm 脚本了，太爽了。

1.2 可重复性理念：为什么 Nextflow 能做到“一次构建，到处运行”

很多工具说自己是可重复的，但真正做起来往往缺三样东西：环境锁定、流程版本控制、数据来源追踪。

Nextflow 在这三个维度上都做了设计：

  1. 容器化运行 — 每个 process 都可以指定一个 Docker/Singularity 镜像，彻底锁定软件版本。
  2. 工作流 DSL2 — 模块化、版本化管理子流程，支持 Git 仓库引用。
  3. Trace / Report — 自动记录每次运行的资源消耗、执行时长、错误信息，甚至可以导出为 HTML 报告。
可重复性要素 传统方式 Nextflow
软件环境 手动安装，容易遗漏 容器封装，一行搞定
执行参数 写在脚本里，难以回溯 记录在 .nextflow.log 和 report 中
数据路径 硬编码，换机器就崩 Channel 抽象，自动解析
并行调度 手动分配资源 自动根据输入分片并行

小技巧：我建议你从一开始就为每个流程准备一个 nextflow.config 文件，里面写死容器镜像地址和执行环境。这样即使过了一年，拉回来重新跑，结果丝毫不差。

为什么批次质控尤其需要这种可重复性？因为质控流程通常包含 FastQC、Trimmomatic、MultiQC、BamQC 等好几个工具，每个工具的版本、参数、参考文件都可能影响后继分析。你想想看，如果今天出一套结果，明天换了个环境又出一套，你信哪一套？

1.3 批次质控场景概述

批次质控，简单来说就是对一大批样本进行标准化质量评估。比如一个测序项目送来 100 个样本，你不可能手动一个个跑 FastQC——你肯定需要一个自动化流程。

在这个课程里，我会带你构建的流程大致包含这几个步骤：

  • 数据输入 — 支持 FastQ、BAM 等格式，自动从文件夹或 CSV 清单读取
  • FastQC — 原始序列的基本质量统计
  • MultiQC — 把所有样本的 FastQC 报告合并成一份交互式 HTML
  • 质控过滤 — 可选，Trimmomatic / fastp 进行修剪
  • 再次质检 — 验证过滤后的质量提升
  • 报告生成 — 输出汇总表格和可视化图表

这个流程看起来是线性的，但实际运行中会涉及并行处理大量样本、资源分配差异化（比如 QC 工具对内存需求低，但对 CPU 需求高）。我曾经遇到过直接在一台 16 核机器上硬跑 200 个样本的 QC，结果内存爆了——教训就是：一定要让流程知道自己的资源上限。

Nextflow 的优势在这里就体现出来了：你只需要在配置里写 cpus = 4、memory = '8GB'，它就能自动为每个样本分配资源，甚至可以在不同集群间动态切换。

注意：批次质控中，样本命名混乱是一大坑。我建议你在输入环节统一进行文件名规范化，比如将 Sample_1_R1.fastq.gz 统一为 SAMPLE_1_R1.fastq.gz，否则 MultiQC 合并时会因为大小写或分隔符不一致而产生重复条目。

下面这张图帮你快速理解本章的知识体系：

Nextflow可重复批次质控知识体系 Nextflow 可重复批次质控知识体系 Nextflow 是什么 数据驱动并行框架 可重复性理念 一次构建，到处运行 批次质控场景 标准化批量质量评估 DSL2 模块化 process + channel 自动并行调度 无需手动管理 容器环境锁定 Docker/Singularity 运行历史追踪 Trace + Report 标准工具链 FastQC → MultiQC 资源差异化配置 CPU/内存可调 课程覆盖核心：从流程设计到实际部署 实践为主，每章都有可运行的代码示例 场景：临床测序 / 大规模队列 / 工业质控 工具：Nextflow + Docker + FastQC + MultiQC

嗯，其实这张图也告诉你了本章的核心：往下我们会先搞清楚 Nextflow 的基础概念，再深入理解它的可重复性设计，最后落到具体的批次质控实战。每一步我都会结合自己踩过的坑来讲。

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