📚 课程目录第3章 GxP在生物信息学中的重要性

3. GxP在生物信息学中的重要性：数据完整性、可追溯性、可重复性

好，咱们进入这一章的核心。做生物信息学分析，最怕什么？你辛辛苦苦跑完的 pipeline，回头 FDA 审计官问你：这个中间结果怎么来的？那个参数谁改的？你答不上来，那就麻烦了。说白了，GxP 在生信领域强调的三座大山——数据完整性、可追溯性、可重复性，就是帮你把这些坑提前填上。我个人习惯把这三点比作“三角凳”，少一条腿都站不稳。

3.1 数据完整性：生物信息学分析的基石

数据完整性，翻译成人话就是：原始数据从产生到归档，中间没被改过、没丢失、没损坏。我记得早期在一个项目里，同事直接把 fastq 文件从测序仪拷到本地硬盘，没做校验。三个月后重新跑分析，发现有两个样本的 reads 数对不上。一查，拷贝过程中文件损坏了。从那以后，我要求所有原始数据落地后必须立刻计算 MD5 校验和。

✅ 数据完整性最低要求：

原始数据（FASTQ/BCL/BAM）只读存储，禁止直接修改
所有文件落地后生成并保留校验和（MD5/SHA256）
传输过程使用校验协议（如 rsync -c、scp 后比对 checksum）
存储介质定期巡检，RAID 或对象存储带版本控制

实际项目中，我习惯在每一次数据落地后跑一个检查脚本：

# 数据完整性检查示例
# 计算所有 fastq.gz 的 MD5，并与官方校验文件对比
cd /data/raw/2025_project
find . -name "*.fastq.gz" -exec md5sum {} \; > checksums.md5
md5sum -c checksums.md5 > verification.log 2>&1
if grep -q "FAILED" verification.log; then
    echo "数据完整性校验失败，请检查对应文件"
fi

嗯，这里要注意：校验文件本身也要纳入版本控制，最好和原始数据放在同一个只读存储区。否则你光有校验值，文件已经坏了，等于白做。

为什么会这样？很多团队觉得“我们用的集群自带了副本冗余”，就懒得做校验。但冗余只防硬件坏，不防软件写错、意外覆盖、甚至恶意篡改。GxP 审计时，你能拿出的证据不是“我的存储很可靠”，而是“这里有 md5 记录，每次数据落地我都签了名”。

3.2 可追溯性：从原始数据到最终报告的链条

可追溯性，说白了就是每一步都能问清楚：谁、什么时间、用什么参数、对哪个文件做了什么。我在项目中遇到过最典型的案例：一个老同事用的脚本叫 run_v1.sh，过了半年他自己都忘了里面具体参数。审计官要求重现，他花了三天才拼出来当时的命令。

所以现在我的原则是：分析环境、代码、参数、输入、输出、日志，全部要记录并归档。 这听起来很重，但你可以用容器和 Workflow 管理系统来简化。

可追溯要素	具体做法	常见翻车点
分析环境	Docker/Singularity 镜像，并保存构建文件	只记了 image tag，没保存 Dockerfile，镜像已被覆盖
代码和参数	Git 提交，参数文件（YAML/JSON）与 commit 关联	参数写死在脚本里，没说改过哪个值
输入输出清单	Workflow 生成的 manifest 含每个文件的 checksum	输出文件名太随意，找不到对应 pipeline 运行编号
运行日志	标准输出和标准错误重定向到单独日志文件	日志和输出混在一起，审计时翻半天

我个人喜欢用 Nextflow 或 Snakemake，它们默认会生成运行记录，包括每一步的容器、命令、时间戳。下面是一个 Nextflow 运行后的 trace 文件片段：

task_id	process	tag	hash	status	exit	submit	start	complete	duration
1	TRIM	Sample01	abc123	COMPLETED	0	2025-03-10T14:00:00	2025-03-10T14:01:20	2025-03-10T14:02:10	50s
2	ALIGN	Sample01	def456	COMPLETED	0	2025-03-10T14:02:10	2025-03-10T14:03:00	2025-03-10T14:05:30	2m30s
3	QC	Sample01	ghi789	COMPLETED	0	2025-03-10T14:05:30	2025-03-10T14:05:31	2025-03-10T14:06:00	29s

看，每一行都告诉你哪个样本、哪个步骤、用了多久、状态如何。审计官最喜欢这种级别的透明度。我曾经在一个项目里，审计官直接要求提供每一个样本从原始 FASTQ 到 VCF 的完整 DAG 图，因为我们用了 Nextflow，直接拿 trace 文件生成出来，对方很满意。

💡 避坑建议： 文件命名上一定要包含项目代号、样本 ID、分析步骤、运行版本。例如 P2025_001_Sample01_trim_v2.1.fastq.gz。别用 output.fastq，过一个月你自己都分不清。

3.3 可重复性：GxP合规的核心要求

可重复性，说白了就是：换个人、换个时间、换个机器，用同样的数据和代码，能拿到一模一样的结果。这件事在生物信息学里特别难，因为软件版本、系统库、随机种子都会影响输出。

我记得有一次，两个同事分别用同一套 pipeline 跑同一个样本，结果突变列表不一样。一查，一个用了 BWA 0.7.17，另一个用了 0.7.18，因为改了默认的比对参数。你说谁对？审计官只看你能不能复现，而不是哪个版本更好。

所以我的原则是：锁定一切。 包括操作系统版本、工具版本、库版本、甚至随机种子。

⚠️ 不可重复的常见原因（我踩过的坑）：

依赖隐式安装，没写入容器或 conda 环境文件
用了 --threads auto，多线程数影响中间随机分箱结果
Python 脚本里 random.seed() 没固定
软件版本号没写死，用了 latest tag
参考基因组版本更新了，但 pipeline 没改引用的路径

下面是一个能最大程度保证可重复性的环境定义方式（conda 环境文件 + Dockerfile 片段）：

# environment.yml
name: gxp_bioinfo_v2.1
channels:
  - conda-forge
  - bioconda
dependencies:
  - python=3.9.18
  - fastp=0.23.4
  - bwa=0.7.17
  - samtools=1.18
  - bcftools=1.18
  - picard=3.1.1
  - r-base=4.3.2
  - r-tidyverse=2.0.0

# Dockerfile
FROM continuumio/miniconda3:23.11.0-0
COPY environment.yml /tmp/
RUN conda env create -f /tmp/environment.yml
RUN echo "source activate gxp_bioinfo_v2.1" > ~/.bashrc
ENV PATH /opt/conda/envs/gxp_bioinfo_v2.1/bin:$PATH

嗯，这里要注意：conda 的版本锁定是固定的，但 pip 依赖往往没有。如果你用了 pip 包，最好也写死版本号，或者用 pip freeze 导出 lock 文件。

3.4 三者之间的关系与实战整合

数据完整性、可追溯性、可重复性，它们不是独立的。你想想看：没有完整性，追溯出来的文件也是坏的；没有追溯，你根本不知道拿什么去复现；没有可重复性，完整性再高也没用，因为别人没法验证你的结果对不对。

在实际项目中，我一般按这个顺序搭框架：

第一步，环境封装： 用 Docker/ Singularity 锁定整个分析栈，配合 conda 环境文件一起归档。
第二步，数据校验： 原始数据落地就做 MD5，并将校验值存入数据库或单独文件，和原始数据一起只读备份。
第三步，Workflow 编排： 选一个支持 provenance 的工具（Nextflow / Snakemake / CWL），确保每次运行都能导出完整的执行记录。
第四步，结果归档： 最终报告、中间文件（包括日志和 trace）打包，生成校验和，放入长期存储。建议用 tar 加时间戳打包，方便翻阅。

✅ 审计检查清单（我内部用的）：

原始数据校验和存在吗？与文件本身分离存储吗？
分析所用的容器/镜像文件是否可复现？（有 Dockerfile / 构建记录吗？）
每一步的输入输出是否记录在 manifest 中？
参数文件是否与运行结果关联？是否有版本号？
能否在全新环境中完整复现一次分析并得到完全一致的输出？

最后说个真实案例。我帮一个客户过 FDA 预审，对方审计官要求演示可重复性。我们现场从原始数据开始，用 Git 拉代码，用 Docker 起环境，跑了一遍 pipeline，结果和归档的报告完全一致——连哈希值都一样。审计官当场说了句“This is what we want to see”。事后我跟团队说，三角凳稳了，审计自然稳。希望你们也能做到这个程度。