📚 课程目录第1章 RNA-seq审计追踪概述

RNA-seq 审计追踪概述

说到 RNA-seq 分析，我最怕听到的一句话就是：“你上次跑的那个结果，还能完全复现出来吗？” 说实话，在我刚入行那几年，这种问题十次有八次让我心虚。不是数据丢了，就是软件版本不记得了，再就是参数改完忘了记下来。嗯，这就是我们今天要聊的核心——审计追踪。

为什么生物信息学需要审计追踪？

审计追踪，说白了就是一本“流水账”。它记录了你从原始数据到最终结果之间，每一步做了什么、用什么做的、为什么这么做。你想想看，一篇 RNA-seq 论文，如果 reviewer 问“FPKM 还是 TPM？比对用的哪个版本的 STAR？”，你能几秒钟翻出来吗？

我个人的习惯是：只要项目启动，第一件事不是跑分析，而是搭审计框架。为什么这么重视？因为生物信息学分析本质上是一个多步、多参数、多工具的复杂流水线。任何一个环节的缺失，都可能导致结果不可复现。

  审计追踪的核心价值：
  可复现性 —— 让六个月后的自己还能跑出一样的结果
可追溯性 —— 出了异常能快速定位是在哪一步翻的车
合规性 —— 很多临床或药企项目，审计追踪是法规硬要求
协作效率 —— 队友接手你的项目，不用从头猜你的操作

RNA-seq 数据可重复性挑战

RNA-seq 看起来就是“建库→测序→比对→定量→差异表达”，但实际坑多着呢。我遇到过最离谱的一次：同一个公共数据，两个团队用了不同版本的 kallisto 和不同参考转录本，差异表达基因列表重合度不到 40%。

常见的挑战我整理了一张表，大家看着更清楚：

挑战类别	具体问题	影响程度
软件版本	STAR 2.7.10 和 2.7.9 的比对结果可能不同	高
参考基因组版本	GRCh38.p13 和 p14 的基因注释有差异	中
参数选择	`--outFilterMultimapNmax` 默认值和自定义值	高
环境差异	Linux glibc 版本、Python 包依赖不一致	中
批次效应	不同批次测序数据混入分析	高
随机种子	某些工具使用了默认随机种子	低-中

我曾经踩过的坑： 接手一个旧项目，发现 STAR 的版本号写在了 README 里，但实际运行日志里是另一个版本。两个人用了不同的 conda 环境，结果谁都没发现。从那以后我强制要求每次运行都记录 conda list 快照。

Nextflow 在管理审计线索中的角色

搞过 Snakemake 或 CWL 的朋友都知道，工作流管理器能帮我们管一部分审计信息。但 Nextflow 在这方面做得尤其到位，它不是事后补记录，而是在运行过程中自动生成审计线索。

我给你列几个 Nextflow 的审计“硬实力”：

流程定义即文档：main.nf 本身就是一份可执行的实验记录，输入、输出、参数一目了然
自动日志系统: .nextflow.log 记录每个进程的启动、完成、失败，精确到秒
Trace 报告：trace.txt 记载每个任务的 CPU、内存、耗时、状态
Execution Report：HTML 报告可视化整个流水线的资源消耗和故障点
Caching 机制：通过输入文件 hash 判断是否需要重跑，变相记录了数据状态
环境隔离：配合 Conda/Docker/Singularity，每个进程的环境快照可复现

我个人的做法是：在 nextflow.config 里打开所有审计相关开关：

// nextflow.config —— 审计追踪推荐配置
params {
    outdir = "./results"
    reads  = "data/*_R{1,2}.fastq.gz"
}

process {
    // 每次都生成 .command.sh 和 .command.run，保留完整命令行
    cache = 'deep'
    // 记录环境变量快照
    envWhitelist = 'PATH,HOME,CONDA_DEFAULT_ENV'
}

report {
    enabled = true
    file    = "${params.outdir}/report.html"
}

trace {
    enabled = true
    fields  = 'task_id,hash,status,native_id,process,tag,name,realtime,queue,submit,start,complete,duration,exit,rss,peak_rss,read_bytes,write_bytes,%cpu,%mem'
    file    = "${params.outdir}/trace.tsv"
}

dag {
    enabled = true
    file    = "${params.outdir}/dag.dot"
}

manifest {
    author = '你的名字'
    version = '1.0.0'
    nextflowVersion = '>=23.04.0'
}

你看到 cache = 'deep' 了吗？它会让 Nextflow 不仅看输入文件名，还计算文件内容的 hash。这样一来，哪怕你悄悄改了一行脚本，它也能感知到并重新跑那个进程。这就是审计追踪的颗粒度。

小技巧： 每次跑完流水线，把 .nextflow.log、report.html、trace.tsv 和 nextflow.config 打包丢到一个 audit/ 目录里。半年后你想重现结果，只要解压这个包，核对 config 和 trace，就能知道当初到底发生了什么。

审计追踪与 Nextflow 工作流的关系

下面这张 SVG 图是我自己常用来给团队培训的框架，它清晰地展示了审计追踪如何嵌入 Nextflow 的执行流程：

从这张图你能看到：原始数据、参数配置、软件环境三者共同输入 Nextflow 引擎；引擎运行过程中自动产生中间产物的缓存、执行脚本和审计报告；最终输出不仅是生物学结果，还有一个完整的“审计包”。

说白了，如果你把 RNA-seq 分析比作做菜，那 Nextflow 就是那个会主动录像、记配料、写烹饪日志的智能厨房——你只管下锅，它帮你把每一步都记下来。嗯，这个习惯养成了，以后再也不用对着“我到底用没用这个参数”发愁了。