第1章：RNA-seq与可重复性挑战

RNA-seq 分析，说白了你就是在做一件事：把细胞里那些 RNA 分子「数」清楚。但听我一句，这事远比你想象的要复杂。我从 2015 年开始接触 RNA-seq，踩过的坑能写一本小册子。今天我把最核心的几个问题给你拆开讲讲。

1.1 RNA-seq 实验设计——从一开始就别走偏

很多人在拿到测序数据后才开始想「怎么分析」，这其实是本末倒置。我个人习惯，在实验设计阶段就要把下游分析的坑先填上。你想想看，如果一开始生物学重复数量不够，后期再牛的统计方法也救不回来。

实验设计的核心，就三个问题：

  • 你的比较目的是什么？是看某个基因在两组间的差异表达，还是要发现新的转录本？不同的目的决定你该用哪种文库制备方案。
  • 生物学重复做几个？我建议至少 3 个，严谨点 6 个。我曾经接过一个项目，人家只做了 2 个重复，结果差异基因表里一半是假的，那叫一个闹心。
  • 测序深度怎么定？如果你只关心高表达的管家基因，10M reads 可能就够了；但你要找低丰度的转录本，30M 起步。这里我给你一个经验表格：
应用场景推荐测序深度（million reads）说明
基因差异表达（高表达基因）10–20基本够用，但低表达基因偏少
基因差异表达（全基因范围）25–40我个人的黄金区间
新转录本发现 / 可变剪接60–100深度不够，剪接事件根本检测不到
单细胞 RNA-seq（每个细胞）50k–200k细胞数量多，单细胞深度低但总量很大
小提示：不要只盯着测序深度。片段化方式、文库插入片段长度、比对率这些参数会影响最终结果。我习惯在实验前先用几个公开数据集做一轮模拟分析，这样心里有个底。

1.2 RNA-seq 数据特点——大、乱、且带有系统偏差

RNA-seq 数据不是普通的数字。它有三个让人头疼的特点：

  • 计数数据，且过分散。每个基因的 read counts 服从负二项分布，不能用常规的 t 检验。这就是为什么 DESeq2 和 edgeR 这类专门工具是必须的。
  • 批次效应如影随形。你分别在周一和周三提取两份样本，用的试剂盒可能来自不同批次，这就产生了批次效应。我见过最夸张的一个案例：同一个实验室、同一个操作员，只是换了另一个品牌的纯化柱，差异基因列表就重了不到 30%。
  • 比对困难。真核生物的剪切机制导致同一个基因能产生上百种转录本。比对时多了一个外显子跳跃，你就可能把它当成一个新基因。

为什么会这样？核心原因是 RNA-seq 测量的是「相对丰度」，而不是绝对数量。你今天测 20M reads，明天测 30M reads，基因表达量的绝对数值没法直接比较。必须做标准化。常用的标准化方法有 TPM、FPKM、RPKM，但各有各的坑。我建议你记住一条：FPKM 不建议用，它跨样本比较时会产生偏差。

1.3 可重复性的挑战——你昨天跑出来的结果，今天还能重现吗？

可重复性是 RNA-seq 分析的老大难。学术界有个著名的安慰剂效应：2016 年有人拿同一个 RNA-seq 数据集给 12 个不同的分析团队，结果每个团队报告差异基因列表的重叠率不到 30%。我当时看到这个研究，后背一凉——我自己的管道是不是也存在同样的问题？

问题出在哪儿？我列举几个最常见的「杀手」：

挑战典型表现后果
软件版本变化HTSeq 0.6.1 和 0.7.0 统计结果不一致差异基因列表出现 10% 以上变动
参数依赖STAR --outFilterMultimapNmax 默认值不同比对率相差 3%–5%
参考基因组版本GRCh37 与 GRCh38基因注释差异 > 20,000 条
计算环境飘移CentOS 和 Ubuntu 上 R 的浮点运算精度差异极个别基因的 p-value 会变
随机种子缺失降采样、重抽样步骤没有固定种子结果每次都不一样
曾经我踩过一个坑：我在一台高性能服务器上跑完了整个 RNA-seq 流程，生成了一份漂亮的差异基因表。三个月后，合作方要重现结果，我用同样的代码和同样的输入数据，换了一台服务器重新跑——结果比对率低了 1.2%，差异基因减少了 8%。排查了两天，发现是两台机器上 STAR 的默认线程数不同，导致输出有细微差异。从那以后，我所有工作流强制固定线程数、随机种子和软件版本。

所以你看，光靠「记下你用了什么步骤」是不够的。你必须把整个环境——从操作系统到每个工具的版本，到参数配置——全部固化下来。这就是为什么我选择 Nextflow。它能帮你把管道变成一部「可重复的脚本」，在任何机器上都能重现同一份输出。

1.4 一张图看懂 RNA-seq 可重复性挑战

下面这张图总结了从原始测序数据到差异基因列表的过程中，哪些环节最容易引入不可重复性。图上每个节点代表一个关键步骤，红色的「不可重复因素」标出了最需要警惕的地方。

RNA-seq 可重复性挑战概览 原始测序数据 (FASTQ) 质控 & 过滤 比对 (STAR / HISAT2) 定量 (HTSeq / FeatureCounts) 差异表达分析 (DESeq2 / edgeR) 软件版本不一致 参考基因组版本 比对参数不固定 定量方法选择 统计模型 + 随机种子 不可重复因素 红色节点 = 高发风险点 每个环节都可能引入变化 Nextflow 解决方案 容器化 → 固化软件版本 配置文件 → 参数可追踪

1.5 为什么选择 Nextflow 来解决可重复性？

说了这么多问题，总得有个解法。我个人认为 Nextflow 是目前处理 RNA-seq 可重复性最优雅的方案，没有之一。它不是简单的脚本语言，而是一个 工作流管理系统。核心能力有三条：

  1. 容器化执行 —— 每个步骤都跑在 Docker 或 Singularity 容器里。你本地用的什么版本，换到服务器还是那个版本，连底层依赖都一模一样。
  2. 自动追踪依赖 —— 当你定义一个 process 时，输入、输出、参数都被记录下来。跑完一次后，只要输入没变，Nextflow 就能跳过已完成的步骤，保证结果一致。
  3. 架构无关 —— 你可以在笔记本上写管道，然后直接提交到 HPC 集群或云上，不用改一行代码。这是怎么做到的？全靠 -profile 配置文件切换运行后端。
核心观点：RNA-seq 分析的可重复性不是靠「写文档」能解决的，必须有工具来强制执行。Nextflow 就是那个「强制执行」的工具。从第一章开始，我们就要养成一个好习惯：把每一步分析都用容器+工作流语言描述出来，再也不用手动在终端里敲命令。

好了，这一章我们主要理清了 RNA-seq 的痛点：实验设计不能马虎、数据本身带偏差、可重复性面临软件版本、参数、环境等全方位挑战。你心里先有个底，后面每章我会带着你用 Nextflow 一步步把这些坑填平。记住，可重复不是追求完美，而是让结果可以被验证、被信任。嗯，这一点比写出漂亮的差异基因表重要多了。

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