4. 多组学数据获取与质量控制

多组学靶点发现的第一步不是建模，而是把数据“拿稳、对齐、可信”。同一批样本往往同时产生转录组、蛋白组、代谢组和临床表型数据，它们来自不同平台、不同批次、不同交付格式。若获取与质控环节松散，后续任何差异分析都可能被批次效应、缺失值和注释漂移污染。本节围绕一条可落地的工程链路展开：数据下载与校验、版本管理、元数据整合、质控流水线，以及四类典型工程问题的处理策略。

一、数据下载：从“能下”到“可复现”

下载阶段的核心目标是可复现与可校验。建议为每个项目建立统一的目录约定，例如 raw/ 存放原始交付文件，meta/ 存放样本表与注释，qc/ 存放质控中间结果，logs/ 存放命令与校验记录。下载方式优先选择支持断点续传与校验的工具，如 wget -c、curl -C - 或对象存储 CLI。对每个文件记录来源 URL、下载时间、文件大小和校验值。

# 示例：下载并生成校验清单（参数为教学示例）
mkdir -p raw meta qc logs
wget -c -P raw https://example.org/omics/transcriptome_counts.tsv.gz
wget -c -P raw https://example.org/omics/proteome_intensity.tsv.gz
md5sum raw/*.gz > logs/md5sum.txt
sha256sum raw/*.gz > logs/sha256sum.txt

校验值必须与数据提供方公布的清单比对；若提供方只给 MD5，也应额外计算 SHA256 作为本地基线。下载完成后不要直接进入分析，先做“完整性检查”：压缩包能否解压、行数是否与交付说明一致、表头字段是否齐全、样本 ID 是否与元数据表可连接。

二、版本管理：让数据、代码与注释同源

多组学项目的版本管理不只是代码 Git，还包括数据版本与注释版本。推荐采用“数据版本号 + 注释版本号 + 代码提交号”三元组。数据版本可用日期或语义化编号，例如 data-v2025.03；注释版本记录基因组版本、蛋白 ID 映射表版本、代谢物库版本；代码提交号来自 Git。三者写入同一份 run_manifest.yaml，任何一次分析结果都能回溯到确切输入。

三、元数据整合：样本 ID 是唯一主线

元数据整合的难点在于“同一批样本在不同组学表中的 ID 不一致”。常见情况：转录组用 S1，蛋白组用 P001，临床表用 SUBJ-001。必须建立一张主样本表（master sample sheet），字段至少包含：subject_id、sample_id、omics_type、batch、group、sex、age、tissue、timepoint、file_path。所有组学表通过 sample_id 与主表连接，禁止在分析脚本中临时改名。

注释不一致还包括基因 ID 版本、蛋白 ID 映射、代谢物命名。处理原则是：先统一到同一参考版本，再记录映射关系。例如转录组 counts 使用 Ensembl ID，而下游需要 Gene Symbol，应保留原始 ID 列并新增 gene_symbol 列，映射失败的行标记为 unmapped，不要直接丢弃。

四、质控流水线：批次、缺失、重复与注释

质控流水线建议按“样本级 → 特征级 → 批次级 → 整合级”四层推进。样本级检查总计数、检出基因数、缺失率、PCA 离群；特征级过滤低表达、低检出、高缺失特征；批次级用 PCA、层次聚类或 ComBat/limma 评估批次效应；整合级检查多组学样本交集与注释一致性。

批次效应处理要避免“先校正后看”。正确顺序是：先做 PCA 或层次聚类观察批次是否主导，再决定是否校正。若批次与分组完全混杂，ComBat 可能把真实生物学差异也校正掉。示例参数：ComBat(dat, batch=batch, mod=model.matrix(~group))，校正后再次 PCA，确认批次分离减弱而分组结构保留。缺失值处理需区分“未检出”与“真零”：蛋白组缺失常为低丰度未检出，可用最小值插补并标记；代谢组缺失需结合检出限判断。样本重复方面，技术重复相关性通常高于 0.98，生物学重复相关性因组织而异；若同一 subject_id 出现多次，应保留 timepoint 并明确是纵向设计还是重复测量。

五、可交付的质控清单

以下清单可直接作为项目质控记录表使用，字段按实际项目增删：