📚 课程目录第1章 Nextflow基础回顾

一、Nextflow基础回顾：工作流概念、核心特性与DSL2语法

大家好，我们先从最基础的东西聊起。别急着跳到失败重试的细节——我个人习惯是先把地基打牢，后面讲那些高级特性才不会心虚。Nextflow这东西，说白了就是一个帮你把各种计算任务串起来、跑起来、管起来的框架。

1.1 工作流到底是个啥？

你想想看，生物信息学里的分析流程，一般都是一步接一步的：比对、排序、去重、变异检测……每步都有输入和输出。以前我写Shell脚本硬串这些步骤，跑起来看着还行，可一旦某步中间崩了，或者换了数据重跑，那叫一个痛苦。

工作流引擎就是干这个的。它帮你定义清楚：

每步干什么（哪个工具、什么参数）
输入从哪来、输出往哪去
哪些步骤可以并行跑
失败怎么办

Nextflow就是这类工具里，我个人用得最顺手的。它的核心思路其实就是把复杂流程画成一张有向无环图（DAG），节点是一个个进程，边是数据的流向。

核心要点： 工作流 = 进程 + 数据流 + 调度策略。Nextflow把这三样东西用一种很简洁的语法封装起来，让你专注于「做什么」，而不是「怎么调度」。

1.2 Nextflow的核心特性

我当年第一次接触Nextflow，最吸引我的是这几个点：

特性	它解决了什么问题
DSL语法	用流程化的方式定义计算步骤，比写一堆Bash脚本清晰得多
数据流模型	自动追踪输入输出依赖，不需要手动管理中间文件
可移植性	本机能跑、集群能跑、云端也能跑，切环境几乎不用改代码
容器化支持	Docker/Singularity原生集成，再也不怕环境不一致
失败重试	这是咱们这门课的核心——自动处理失败任务，不用人肉盯着
资源管理	每个进程可以单独指定CPU、内存，调度器帮你合理分配

说真的，我做过的项目里，但凡用了Nextflow的，后期维护成本都低了一大截。特别是容器化那部分——我曾经在三个不同集群上部署同一套流程，配置文件几乎不用改，这体验真的是爽。

一个小建议：刚开始学Nextflow，别急着搞太复杂的配置。先在本机跑通一个最简单的Hello World，感受一下它的数据流是怎么走的。我当年就是从这一小步开始的。

1.3 DSL2语法简介

Nextflow有两大语法版本：DSL1和DSL2。现在官方推荐用DSL2，也是我们这个课程用的版本。DSL2最大的变化，就是把流程定义变得更模块化。

一个标准的DSL2工作流大概长这样：

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

// 定义一个进程
process ALIGN {
    input:
        path reads
    output:
        path "aligned.bam"
    script:
        """
        bwa mem ref.fa $reads > aligned.sam
        samtools view -bS aligned.sam > aligned.bam
        """
}

// 定义工作流
workflow {
    ALIGN( Channel.fromPath("*.fastq") )
}

这段代码里，几个关键点我提一下：

process：核心单元。每个进程定义了一个计算任务，包括输入、输出和执行脚本
workflow：流程主干。在这里把各个进程串起来，Nextflow自动管理依赖
Channel：数据通道。输入数据都通过Channel来传递，支持队列、值等多种模式

DSL2相比DSL1，最明显的好处是：

流程定义更清晰：workflow块一目了然
模块复用：可以用include导入外部模块
参数传递更灵活：支持命名参数和默认值

举个我在项目中用过的例子，模块化之后代码真的清爽很多：

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

include { ALIGN; SORT; CALL_VARIANTS } from './modules'

workflow {
    reads_ch = Channel.fromPath(params.reads)
    bams = ALIGN(reads_ch)
    sorted_bams = SORT(bams)
    CALL_VARIANTS(sorted_bams)
}

// modules.nf
process ALIGN {
    input:
        path reads
    output:
        path "aligned.bam"
    script:
        """
        bwa mem ref.fa $reads > aligned.bam
        """
}

process SORT {
    input:
        path bam
    output:
        path "sorted.bam"
    script:
        """
        samtools sort $bam -o sorted.bam
        """
}

process CALL_VARIANTS {
    input:
        path bam
    output:
        path "variants.vcf"
    script:
        """
        bcftools mpileup -f ref.fa $bam | bcftools call -mv -o variants.vcf
        """
}

你看，这样模块化之后，每个进程都可以单独测试、单独复用。我经常跟团队说：写Nextflow流程就像搭积木，好的模块设计能省下一大半后期改bug的时间。

1.4 本章小结——一张图看懂

好，前面说的内容有点多，我画了一张图帮你把基础框架串起来。这张图就是Nextflow工作流的基本骨架，后面的所有高级特性都是在这个骨架上叠加上去的。

这张图展示了一个典型Nextflow工作流的全貌：输入数据通过Channel进入，经过多个进程的串行或并行处理，中间数据自动流转，最终输出结果。这里面每一个环节你都得搞清楚，因为后面讲的失败重试逻辑，就是在这些节点上做文章。

我踩过的坑：刚开始学DSL2时，我老是把nextflow.enable.dsl=2这条声明写在文件最下面，结果报错百思不得解。记住，这条声明必须写在文件第一行、shebang之后。不然Nextflow会默认用DSL1解析，然后各种不兼容。

好，基础就回顾到这里。有些朋友可能觉得这些东西太简单——嗯，别急。后面几章我们就会扎进失败重试的具体实现，从最简单的errorStrategy 'retry'到自定义重试逻辑、动态延迟、并发控制……一点一点吃透。我保证，等你学完这30章，任何崩溃的流程在你手里都能被调教得服服帖帖。