📚 课程目录第2章流程自动化部署基础

NGS变异流程自动化部署指南 - 第2节

为什么我们需要自动化部署？

说实话，我刚开始做NGS分析那会儿，整个流程全靠手敲命令。一个变异检测跑下来，少说二三十步。每换一批数据，就得重新敲一遍。出错的概率？你想想看，凌晨三点盯着终端，手一抖把bam文件路径写错，整个分析就得重来。

自动化部署说白了就两个字：解放。把重复劳动交给机器，把精力留给真正的分析。

自动化部署的核心价值：

可重复性 —— 同样的输入，永远得到同样的输出。这是科学计算的底线。
减少人为错误 —— 我见过最离谱的一次，同事把样本标签搞混了，两个肿瘤样本的突变列表完全互换，还好在质控阶段抓出来了。
可追溯性 —— 每个步骤的参数、版本、运行时间都有记录。出了问题，知道从哪查起。
规模化扩展 —— 从10个样本到1000个样本，改个配置就行，不用重新写流程。
团队协作 —— 你写的流程，别人拿过去就能跑。不用“你帮我看看这个报错是什么意思”。

曾经有个项目，需要处理500个肿瘤-正常配对样本。如果手动跑，按每个样本2小时算，连续不断也要1000小时。用了自动化流程，一台机器并行跑，一周就出结果。这就是自动化的威力。

工具选择：这场战役的武器库

市面上能用来做NGS流程自动化的工具不少。我按自己的经验，把它们分成几类。

Shell脚本 —— 最直接的方案

每个人刚入行时都会写。把一串命令写进 .sh 文件，用变量控制输入输出。简单、直接、零学习成本。

#!/bin/bash
# 简单的变异检测流程
INPUT_BAM=$1
OUTPUT_DIR=$2

samtools sort $INPUT_BAM -o $OUTPUT_DIR/sorted.bam
samtools index $OUTPUT_DIR/sorted.bam
freebayes -f reference.fa $OUTPUT_DIR/sorted.bam > $OUTPUT_DIR/variants.vcf

但你会发现，Shell脚本很难处理复杂的依赖关系。如果某一步失败了，重跑时怎么保证只跑失败的步骤？没有内置的解决方案。我在项目里见过有人把每一步的成功标记写在临时文件里，用if判断…嗯，太脆弱了。

适用场景： 快速原型、个人项目、步骤少于10个的简单流程。

Makefile —— 依赖管理的老大哥

Makefile语法有点反人类，但它的依赖追踪机制非常扎实。每个输出文件都对应一条规则，Make会自动判断哪些步骤需要重新执行。

%.sorted.bam: %.bam
    samtools sort $< -o $@

%.vcf: %.sorted.bam
    freebayes -f reference.fa $< > $@

all: sample1.vcf sample2.vcf

我记得第一次用Makefile管理WGS流程时，最大的感受是：再也不用手动删中间文件了。改一下参数，make自动重跑受影响的部分。但Makefile的弱点也很明显——它只认文件时间戳，不认参数变化。你把bwa的种子参数从42改成123，Makefile不会知道需要重新比对。

CWL 与 WDL —— 标准化的野心

CWL（Common Workflow Language）和WDL（Workflow Description Language）都是社区推动的标准化方案。它们的思路类似：用声明式语言描述每个步骤的输入、输出、命令和运行环境。

CWL的一个例子：

class: CommandLineTool
cwlVersion: v1.2
inputs:
  input_bam: File
  reference: File
outputs:
  vcf: stdout
baseCommand: [freebayes, -f]
arguments:
  - $(inputs.reference)
  - $(inputs.input_bam)
stdout: $(inputs.input_bam).variants.vcf

这种方案在大型机构里很受欢迎，因为CWL/WDL定义的流程可以在不同的计算平台间迁移。从本地服务器到云上HPC，改个配置文件就行。但学习曲线确实陡。我刚开始接触CWL时，被它的YAML嵌套搞得晕头转向。

注意： CWL和WDL的调试成本较高。一个小语法错误，可能在运行时才暴露出来。我建议先在小数据集上验证流程定义，再上全量数据。

Nextflow 与 Snakemake —— 新时代的宠儿

这两个是目前NGS领域最主流的流程管理工具。它们都做到了几件事：依赖管理、自动并行、日志记录、容器支持。

Nextflow的DSL2语法很优雅：

process FASTQC {
    input:
    path read

    output:
    path "fastqc_*"

    script:
    """
    fastqc $read
    """
}

workflow {
    FASTQC( channel.fromPath("*.fastq.gz") )
}

Snakemake则继承了Makefile的思想，用Python语法表达规则：

rule fastqc:
    input:
        "sample.fastq.gz"
    output:
        "fastqc/sample_fastqc.html"
    shell:
        "fastqc {input} -o fastqc/"

我个人习惯用Snakemake做中大型项目。它的Python扩展性很强，可以轻松嵌入自定义脚本。但Nextflow的社区生态更活跃，特别是与Docker/Singularity的集成更顺滑。

怎么选？一张表讲清楚

工具	学习成本	依赖管理	并行支持	容器集成	我最推荐的场景
Shell脚本	低	手写	手写	弱	快速原型、步骤<10
Makefile	中	自动（基于文件）	有限	弱	中等规模的文件处理链
CWL/WDL	高	自动	需要配置	强	跨平台标准化流程
Nextflow	中高	自动	内置	内置	需要容器化的复杂流程
Snakemake	中	自动	内置	内置	Python生态友好的团队

选择工具时，我通常会问自己三个问题：
项目规模有多大？团队里别人会不会用？后续要迁移到别的平台吗？
答案明确了，工具自然就选出来了。

这张图我调整了好几次。核心思路是把决策过程可视化——从项目规模出发，沿着不同的需求分支找到最合适的工具。你拿这张图去做技术选型，基本不会跑偏。