📚 课程目录第4章数据收集与预处理

数据收集与预处理：不同批次数据的获取归纳总结

做生信项目，数据收集看着是最没技术含量的一步。你想想看，无非就是下载文件、改个名、扔进文件夹。但说实话，批次效应的根，往往就埋在这个阶段。我经手过不下二十个多批次整合项目，九成以上的注释矛盾，追到最后都能在数据收集环节找到线索。

批次数据的三大来源

咱们先理清批次数据从哪来。不同来源，风险点完全不一样。

来源类型	典型场景	批次风险等级	我遇到过的坑
公共数据库	GEO / SRA / ENA 下载	⭐⭐⭐⭐	同个项目不同样本来自不同测序平台
合作实验室	跨课题组共享数据	⭐⭐⭐⭐⭐	双方使用的参考基因组版本不一致
历史项目数据	自家实验室前期结果	⭐⭐⭐	旧数据的命名规则跟现在不兼容
商业测序服务	外包给第三方公司	⭐⭐⭐	不同批次用的试剂盒版本不同

这里我想多说一句。公共数据库看起来最省事，但其实最容易埋雷。我几年前从GEO下载过一个RNA-seq项目，10个样本，下载完才发现其中4个是Illumina HiSeq 2000跑的，另外6个是NovaSeq 6000。你想想，这两个平台的读长分布、碱基质量特征都不一样，合并之后差异表达基因里一大半是批次效应。

数据收集阶段的两条铁律

经历过几次"血的教训"之后，我给自己定了两条规矩。现在每次带新人做项目，也是先让他们背下来。

先看元数据，再碰原始文件——元数据不完整，数据直接不要收。
收数据的同时，写批次日志——别信"等收完再补"这种鬼话。

⚠ 避坑指南
我曾经花了两周时间，把一套来自三个实验室的ATAC-seq数据整合好，跑完差异分析才发现，其中一个实验室的样本用了双端测序，另外两个是单端。就因为当时没在批次日志里记这个字段，排查到崩溃。从那以后，我规定所有数据入库前必须填写技术参数清单，少一项都不给过。

元数据——批次效应的第一道防线

元数据是什么？说白了就是"数据的数据"。但很多分析人员只关心表达矩阵，不关心元数据。我个人习惯是：元数据表的优先级比表达量矩阵还高。

一份合格的批次相关元数据，至少包含以下几类信息：

样本基本信息：样本ID、组织类型、处理条件、生物学重复编号
实验技术参数：建库日期、试剂盒版本、文库片段大小、PCR循环数
测序参数：平台型号、测序模式（SE/PE）、读长、测序深度
生物信息学参数：比对工具及版本、参考基因组版本、注释文件版本
批次关联字段：批次ID、样本来源、操作人、数据接收日期

💡 一个小技巧
我习惯在项目启动时就建好一个metadata_template.xlsx，把上述字段全部列好，收一个样本填一行。别等数据全到了再一起填，那时候很多细节已经记不清了。

文件组织与命名规范

文件命名看起来是小事，但混乱的命名会让批次效应排查变得异常困难。我在项目中常用的规则是这样的：

项目名_批次ID_样本ID_数据类型_版本号.ext

# 示例
CRC_Batch01_S001_R1.fastq.gz
CRC_Batch01_S001_R2.fastq.gz
CRC_Batch01_S002_R1.fastq.gz
CRC_Batch02_S001_R1.fastq.gz

为什么一定要把批次ID写进文件名？因为你做多批次整合时，很多时候是从文件名直接筛选样本的。如果批次信息只藏在元数据表里，后期脚本处理容易出错。

  🔑 关键原则

  文件命名要做到「见名知批」——任何一个人拿到这个文件，不需要查表就知道它属于哪个批次。

数据收集的标准化流程

我目前团队用的流程，经过多次迭代，基本定型成这样：

接收数据前：发送元数据模板给数据提供方，要求填完再发数据
数据到达时：校验文件完整性（md5sum），检查命名规范
入库登记：在批次管理表中记录接收日期、来源、文件路径
格式统一：将不同来源的格式统一为项目标准格式（比如统一用压缩的FASTQ）
批次预检：运行质量检查工具，记录每个样本的质量指标，初步判断是否存在平台差异
生成批次注释表：汇总所有元数据，形成后续分析用的批次信息文件

这个流程看着啰嗦，但能拦住八成的批次问题。我做过对比：走完整流程的项目，后期因为批次效应导致分析返工的概率降低了至少60%。

  📋 批次管理表示例

  这是我常用的批次信息记录结构，每次项目开始前就建好这个表：

批次ID	样本数	测序平台	建库日期	数据来源	参考基因组	质量状态
Batch01	12	HiSeq X Ten	2023-03-15	合作方A	GRCh38.p13	✅ 通过
Batch02	8	NovaSeq 6000	2023-06-20	公共数据库	GRCh38.p13	⚠ 注意GC偏差
Batch03	15	DNBSEQ-T7	2023-09-01	合作方B	GRCh38.p13	✅ 通过
Batch04	6	HiSeq 2000	2022-11-10	历史项目	GRCh37	❌ 需重新比对

看到上面Batch04的问题了吗？参考基因组版本不一致，这种批次差异在整合时如果不处理，注释冲突几乎是必然的。

一个真实的收集阶段失误案例

说个让我印象特别深的事。之前做胃癌多组学项目，三个批次的RNA-seq数据，分别来自三个合作医院。数据收齐后我让组里一个同学去做整合。他跑完差异分析，发现有2000多个基因显著差异，结果一查——三个批次用的基因注释文件版本不一样。

一个用Ensembl v95，一个用v102，还有一个用了GENCODE v29。你想想，不同版本的基因ID对应关系有出入，一些基因在旧版本里是"蛋白编码"，在新版本里被重新分类成了"假基因"。注释都打架了，下游分析还有什么意义？

如果当时在数据收集阶段就要求各家统一注释版本，或者在批次表里标记清楚，后面至少能省两周的纠错时间。

本章知识结构

下面这张图，把数据收集与预处理阶段的核心逻辑串起来了。我做这个项目时，就贴在工位旁边，每次收新批次都扫一眼，提醒自己别漏步骤。

这个流程看起来步骤多，但每一步都是在"排雷"。尤其是元数据收集和批次标注这两个环节，我建议你多花点时间。我在项目里吃过最狠的亏，就是跳过了元数据核对，直接拿数据跑分析。结果呢？注释矛盾查了两个月，最后发现是不同批次用的参考基因组版本不一样。

数据收集阶段多留个心眼，后面分析阶段的麻烦能少一大半。别嫌啰嗦，这都是拿时间和头发换来的经验。