2026-06-21||Source

DiVo BioData Scrubbing: 让生物计算的数据入口告别"随手脚本"

日期: 2026-06-21

生物计算项目中，数据获取是最基础也是最混乱的环节。

工程师们习惯随手写个 shell 脚本下载 PDB、临时调个 API 抓 MSA、手动 scp 同步远端文件——这些脚本散落在各个工作空间里，没有复用、没有缓存、没有审计。

DiVo BioData Scrubbing 解决的就是这个问题：把数据获取从"临时脚本"升级为"确定性基础设施"。

一、问题：数据获取的"隐性成本"

生物计算项目的数据获取需求看似简单，实际上有大量隐性成本：

数据源碎片化。PDB 结构文件走 FTP，UniProt 序列走 REST API，NCBI 分类信息走 datasets 工具，PRIDE 质谱数据走 Aspera 高速传输，MSA 搜索走 ColabFold 的 MMseqs2 API。每个数据源有独立的协议、认证方式、速率限制和错误处理逻辑。

脚本随意散布。每个项目的工作空间里都躺着几个 run_download_msa.sh、sync_pdb.py、fetch_uniprot.py。这些脚本是工程师花 10 分钟随手写的，没有错误处理、没有重试逻辑、没有缓存，下次换个项目又要重写一遍。

重复下载浪费。同一份 Swiss-Prot 数据库（~570MB）、同一组 GPCR 家族的 MSA 结果，在三个不同项目中被反复下载。带宽和时间白白浪费，而本地磁盘上明明已经有这些数据。

跨节点路径混乱。本地工作站和云端 GPU 服务器之间的文件同步靠手动 scp/rsync。哪台机器上有什么数据、路径是什么、版本是否一致——全靠记忆和约定。

这些"隐性成本"加起来，每个项目在数据获取上浪费的时间远超想象。更关键的是，随手脚本缺乏确定性——同一条命令在不同时间、不同机器上执行，可能得到不同结果，导致下游计算结果不可复现。

二、思路：从"临时脚本"到"数据处理集散中心"

BioData Scrubbing 的核心理念是：把数据获取从项目的临时操作，升级为团队的基础设施。

它不是一个大而全的"万能下载器"，而是一个数据处理集散中心——数据在这里汇聚，按规则分发，按层级缓存，用完后自动归档。

2.1 三层缓存：本地有就读本地，没有才下载

这是整个设计中最核心的决策。数据获取不是每次都从远端拉取，而是经过三层检查：

请求 accession "P12345"
  │
  ├─ 第一层: 项目工作空间缓存
  │    "这个项目之前下载过吗？" → 有就直接用
  │
  ├─ 第二层: 本地永久数据镜像
  │    "其他项目下载过，存在本地公共区吗？" → 有就拷贝过来用
  │
  └─ 第三层: 远端数据源
       "本地没有，去网上下载"
       └─ 下载完成后，自动落盘到本地永久镜像，下次别的项目就能直接从第二层命中

三层缓存的本质是把"下载"变成"命中"。第一次下载 Swiss-Prot 需要 5 分钟，之后所有项目、所有工程师都只需要毫秒级的本地读取。

缓存层级的关键设计：

层级	性质	特点
工作空间缓存	项目级临时缓存	项目独有，项目结束后可清理
本地永久镜像	团队级公共数据	只增不减，跨项目共享
远端数据源	数据的最终来源	按需访问，结果自动落盘

一个重要细节：只有公共数据才落盘到永久镜像。MSA 搜索结果、序列文件、结构文件——这些是通用数据，值得永久保存。项目特定的计算中间产物（如某一轮实验的临时结果）只保留在工作空间缓存中，不会污染公共镜像。

2.2 Provider 注册表：自动路由，无需记忆

用户不需要知道"PXD005573 应该去 PRIDE FTP 下载"、"P12345 应该调 UniProt REST API"。系统根据 accession 的模式自动识别数据源并路由到对应的处理器。

每个数据源封装为一个独立的 Provider 模块，内部对接对应的开源工具（如 PRIDE 官方客户端、NCBI 的 datasets 工具），对外提供统一的检索语义。新增数据源只需实现 Provider 接口，注册到路由表即可。

2.3 确定性流水线：同样的输入，同样的输出

整个检索过程遵循固定的 9 步流水线：验证输入 → 解析缓存 → 获取元数据 → 过滤 → 下载（如需要）→ 校验 → 保存 → 持久化 → 富集结果。

每一步都有明确的输入输出约定，失败时记录具体原因而非静默跳过。每次检索的结果（缓存层级、耗时、文件列表）都记录在案，确保下游计算的可复现性。

三、数据源覆盖

3.1 已实现

数据源	类型	Accession 模式	上游依赖
PRIDE Archive	质谱蛋白质组学	PXD / MSV / JPST / IPX	官方 Python 客户端
NCBI Datasets	基因组与分类学	GCF / GCA / Taxonomy	官方 datasets 工具
UniProt	蛋白质序列与注释	P / Q / O / TrEMBL	官方 REST API

3.2 规划中

数据源	类型	优先级
ColabFold MSA	多序列比对	高（结构预测管线必需）
PDB / mmCIF	蛋白质结构	高（对接与结构分析必需）
IEDB	免疫表位	中（免疫相关项目）
MGnify	宏基因组	中（微生物组项目）
PubMed	文献	低（文献辅助分析）

3.3 与现有脚本的整合

BioData Scrubbing 的设计过程中，我们审计了团队所有工作空间中散落的临时数据获取脚本（包括 /mnt/e/biodb 下的同步脚本和三个项目空间中的 run_msa_*.sh、fetch_*.py 等），梳理出 5 个数据源的重复覆盖。这些脚本的功能全部被整合并标准化到 Provider 体系中，原有脚本逐步退役。

四、差异化：不是"又一个下载器"

4.1 与直接调用 API 的区别

直接调 API 获取数据是"一次性操作"——调完、拿到数据、用完丢弃。BioData Scrubbing 是"基础设施"——调完、缓存、持久化、下次自动命中。

维度	直接调 API / 随手脚本	BioData Scrubbing
缓存	无（或临时文件）	三层自动缓存，跨项目共享
可复现性	不确定（依赖网络状态）	确定性（同一 accession 同一结果）
审计	无	每次检索记录缓存层级和耗时
数据源路由	手动（记 API 端点）	自动（按 accession 模式匹配）
文件校验	依赖开发者自觉	自动 MD5 校验 + 文件大小验证
团队复用	靠复制粘贴脚本	公共镜像自动共享

4.2 与"数据仓库"方案的区别

有人可能会问：为什么不直接建一个数据仓库，把所有数据提前下载好？区别在于：

数据仓库面向"已知数据"：你提前知道需要哪些数据，批量下载。但生物计算中很多数据需求是临时的、突发的——"这个新发现的 GPCR 同源蛋白，帮我拉一下它的序列和同源结构"。
BioData Scrubbing 面向"按需发现"：第一次请求时从远端下载，之后自动进入缓存。它不需要预判数据需求，但能保证"下载过一次就永远不需要再下载"。

五、在团队工具生态中的位置

BioData Scrubbing 是 DiVo Gen²AI 工具链的"数据入口层"：

结构预测 (Protenix)  ←──  MSA 数据
序列分析 (RNALens)    ←──  UniProt 序列
对接管线 (DiVoProtein) ←──  PDB 结构
质谱分析                ←──  PRIDE 数据集
文献辅助                ←──  PubMed 摘要
    ↑                        ↑
    └────────┬───────────────┘
             │
    BioData Scrubbing（统一数据入口）

所有需要外部数据的工具，都通过 BioData Scrubbing 获取数据，而非各自独立调用 API。这确保了：

数据一致性：同一份数据在所有工具中版本一致
资源效率：下载一次，全团队共享
可审计：数据来源和版本可追溯

六、未来方向

短期

完成 MSA 和 PDB 数据源的 Provider 封装
建立缓存统计面板，可视化各层级命中率

中期

支持增量缓存更新（检测上游数据变更）
开发缓存清理策略（自动淘汰过期数据）

长期

多节点分布式缓存共享
集成到 DiVoProtein 管线中作为标准数据入口
开放 Provider 插件接口，支持第三方数据源接入