信息速览
MGnify — 微生物组序列分析平台 AI-Ready Wikipedia
INFOBOX
| 数据集名称 | MGnify |
| 英文全称 | MGnify (Microbiome Sequence Data Analysis Resource) |
| 别名/简称 | MGnify、原 EBI Metagenomics、mgnify.ac.uk |
| 疾病分类 | 非疾病专用数据集：微生物组与人类多系统疾病研究相关（ICD-11 关联示例：1A00 霍乱等感染性疾病、DD90 炎症性肠病、6A70 单次发作抑郁障碍等研究中常作菌群暴露变量） |
| SNOMED CT | 不适用（微生物组序列资源无统一 SNOMED 概念；相关上位概念为 364533000 Metagenomic sequencing） |
| 数据模态 | 高通量测序（扩增子标记基因、鸟枪法宏基因组、宏转录组、组装基因组）及派生的分类学与功能注释表 |
| AI 任务类型 | 物种分类注释、功能通路预测、MAG 二值化与物种聚类、蛋白家族搜索、生物群落分类、跨研究元分析、微生物-宿主表型关联建模 |
| 样本总数 | 近 50 万次分析（NAR 2023 论文口径）；官网 studies 数按 INSDC accession 动态增长 |
| 数据大小 | 按需下载（无单一总包）；蛋白数据库按日期版本化发布，最新版目录含约 57 亿条非冗余蛋白序列 |
| 数据格式 | JSON:API（REST）、TSV、FASTA、GFF、JSON；基因组目录另提供 catalogue 打包下载 |
| 许可证 | 蛋白数据库为 CC0 1.0 Universal；分析结果页与原始数据分别适用 INSDC/ENA 条款与 EMBL-EBI Terms of Use；官方未披露覆盖全站分析结果的单一 CC 许可 |
| 访问级别 | 开放（浏览与下载无需注册；提交数据需注册 MGnify submitter account） |
| DUO 标签 | GRU, NPUNCU（微生物组与宏基因组公共服务数据；具体结果页限制以官方条款为准） |
| 语言 | 英文 |
| 首发日期 | 2017（EBI Metagenomics 服务期早于此，2018 年正式更名 MGnify） |
| 最后更新 | 持续更新（流水线 v6.0 已发布；蛋白数据库最新版本目录 2026_07） |
| 发布机构 | EMBL-EBI（欧洲分子生物学实验室-欧洲生物信息学研究所） |
| 官方主页 | https://www.ebi.ac.uk/metagenomics/ |
| 下载地址 | https://ftp.ebi.ac.uk/pub/databases/metagenomics/ |
| DOI | 10.1093/nar/gkac1080（NAR 2023 平台论文）/ 10.1016/j.jmb.2023.168016（基因组目录论文） |
| 引用次数 | 460+（Google Scholar，截至 2026-09，指 NAR 2023 平台论文） |
| AI 就绪度评分 | ⭐⭐⭐（3/5）— API 与 FTP 完备、注释体系规范；扣分项：无官方 train/val/test 划分、跨流水线版本结果不可直接合并、无统一全站许可、需自行完成格式转换 |
| 页面状态 | published |
§0 E-E-A-T 信任声明与免责声明
医学审核者：千方病案医学编辑部交叉审核：§2 医学背景（微生物组与疾病关联的 ICD-11/SNOMED CT 映射、生物群落分类与临床任务定义）、§7 偏倚分析。
数据工程审核者：千方病案医学编辑部交叉审核：§4 DAIMS 数据字典（MGYA/MGYG/MGYP accession 体系）、§5 数据划分策略、§6 预处理 Pipeline 和坑点。
审核日期：2026-09-05
审核方式：交叉审核
利益冲突声明：千方病案医数集与 EMBL-EBI、Newcastle University、Durham University 及 MGnify 开发团队无任何商业利益关联。本页面不销售 MGnify 的任何数据或服务，仅提供 AI 就绪指南与学术信息服务。编辑者未接受上述机构的任何形式资助。
医疗免责声明：本页面提供的医学信息仅供研究和教育目的，不构成医疗建议、诊断或治疗方案。数据集的医学描述基于公开发表的文献，未经逐一临床验证。任何基于该数据集训练的 AI 模型在应用于临床决策前，必须经过独立的临床验证和监管审批。
技术免责声明：本页面的代码示例、预处理建议和基准性能数据基于公开资料整理，不保证在特定环境下的准确性和适用性。使用者应自行验证代码安全性和数据预处理流程的正确性。千方病案医数集不对因使用本页面信息而导致的任何直接或间接损失承担责任。
数据使用合规：使用本页面描述的数据集前，请务必阅读并遵守数据集原始许可协议。MGnify 的分析结果与基因组目录分别适用 EMBL-EBI 通用服务条款、原始 INSDC/ENA 记录条款以及各版本目录随附的许可证（蛋白数据库为 CC0 1.0）。使用前请核对目标版本目录内随附的许可证文件。DUO 标签仅供参考，具体使用限制以数据集官方协议为准。
§1 数据集概览
§1.0 30 秒速览
这是什么？ MGnify 是 EMBL-EBI 维护的一个"微生物组数据加工厂"。科学家把测序得到的微生物 DNA 原始读长提交到国际核酸序列数据库（INSDC，欧洲侧由 ENA 承接），MGnify 就用一套标准化的自动化流水线把这些原始数据加工成可比较的分类学组成表、功能注释表和组装基因组。加工成果按 MGYA 编号公开挂出，任何人不用注册就能下载。它的前身叫 EBI Metagenomics，2018 年改名为 MGnify。
为什么重要？ 微生物组研究的最大痛点不是测不出序列，而是"测出来了也没法比"。同样的肠道样本，A 实验室用 QIIME、B 实验室用 mothur、C 实验室用自研脚本，得到的物种丰度表放在一起就是三套数字。MGnify 的价值在于用同一套流水线、同一个参考数据库版本处理几十万个样本，把"可比性"这件事一次性解决。它同时是 MGnify Genomes 基因组目录的宿主——从全球各生物群落的宏基因组中重建出 30 万个以上的微生物基因组，填补了传统培养方法无法覆盖的"微生物暗物质"。
我能用它做什么？ 你可以按 MGYA 编号直接下载某次分析的全套结果做下游建模；可以用 REST API 按生物群落、研究编号批量抓取分类学与功能谱，构建数百个样本的元分析矩阵；可以直接下载人类肠道或海洋的基因组目录，把 MGYG 基因组当作参考序列做读长比对与丰度估计；也可以用 HMMER 在线搜索把你的蛋白序列比对到 MGnify 蛋白数据库。如果你的研究需要"统一处理过的、跨研究可比的微生物组数据"，MGnify 基本是唯一现成的公共选项。
§1.1 摘要
MGnify 的技术路径可以概括为"提交—归档—标准化分析—公开结果"四段式。数据入口有两条：一条是研究者先把原始读长提交到 ENA，再由 MGnify 抓取分析；另一条是通过 MGnify 自身的 submitter 通道提交，数据最终同样落到 ENA/INSDC 永久归档。这种分工决定了 MGnify 的定位——它是衍生分析资源而非原始数据仓库，原始读长的权威副本始终在 INSDC，MGnify 保存的是加工产物。
加工环节按数据类型分为三条主流水线。第一条是扩增子流水线，处理 16S rRNA、18S rRNA 与 ITS 标记基因测序，用 MAPseq 与 Infernal/Rfam 做分类注释，参考库按标记选择 SILVA（16S/18S）、ITSoneDB 与 UNITE（ITS）。第二条处理原始读长层面的宏基因组与宏转录组，用 mOTUs2 做标记基因物种定量，用 FragGeneScan 或 Prodigal 预测基因，再经 InterProScan、eggNOG-mapper、KOfam 与 antiSMASH 完成功能与次级代谢产物注释。第三条是组装流水线，用 metaSPAdes 对宏基因组做从头组装，输出重叠群与预测蛋白。
v5.0 的三条流水线用 CWL（Common Workflow Language）定义，代码托管在 GitHub 的 EBI-Metagenomics/pipeline-v5 仓库，Apache-2.0 许可。v6.0 已经发布并改用 Nextflow 重写，拆分为扩增子分析、组装分析、miassembler、基因组目录构建、mettannotator、VIRify、BioSIFTR、PIMENTO、EukCC 等多个独立子流程。v5.0 的历史结果不会下线，仍可通过 API、网站与 FTP 访问，但新旧版本的结果数值不具可比性，这是使用 MGnify 时最需要警惕的一点。
MGnify Genomes 是平台内相对独立的一条产品线。它不分析单个样本，而是按生物群落（如人类肠道、海洋、土壤、牲畜、食品）聚合来自全球的宏基因组，先组装再分箱得到 MAG，然后用 CheckM 评估完整度与污染度，最后按 95% ANI 加 30% 比对比例的阈值聚成物种簇。NAR 2023 平台论文记录平台累计完成"近 50 万次分析"；JMB 2023 的基因组目录论文记录当时为 7 个目录、301,808 个基因组、11,048 个物种代表。截至 2026-09，官网基因组浏览页的目录数已扩展到约 21 个，其中人类肠道目录单目录即含 4,744 个物种、289,232 个基因组。
§1.2 战略价值
价值一：把"可比性"变成公共服务。 微生物组领域长期受困于方法学异质性。同一份粪便样本在不同实验室、不同引物、不同注释库下，物种列表可以差出 30% 以上。MGnify 的应对方式是用固定版本的软件与参考库（v5.0 中如 SILVA 132、UNITE 8.0、Rfam 13.0、UniRef90 2019_11）批量处理所有提交，使得跨研究、跨地域、跨年份的样本至少在同一分析口径下可比。这不是学术上最先进的做法，但它是工程上最有价值的选择——它让"用 500 篇论文的数据做一个元分析"从一个需要数月人工协调的项目变成了几天 API 抓取就能完成的任务。对任何做微生物组元分析的团队，这是成本结构的根本改变。
价值二：微生物暗物质的规模化编目。 环境样本中可培养的微生物不足 1%，传统基因组学研究严重依赖分离培养。MGnify Genomes 反其道而行：直接用宏基因组分箱从环境里"捞"基因组，再按生物群落发布目录。JMB 2023 论文报告了 36 个此前未培养的类群获得了首个参考基因组。这些目录的实际用途是读长比对参考——做宏基因组定量时，用群落特异的目录替代通用参考库，能显著提升低丰度物种与近缘种的检出率。对人类肠道微生物组研究、海洋生态学、土壤微生物与农业微生物组应用而言，这是一条绕过培养瓶颈的捷径。
价值三：蛋白数据库作为功能搜索的通用底座。 MGnify 蛋白数据库把所有分析中预测出的蛋白序列去冗余后发布，最新版本目录（2026_07）含约 57 亿条非冗余序列，此前 2024-04 版本约为 24 亿条。它采用 CC0 1.0 Universal 许可，同时托管在 Google Cloud Public Datasets 上支持 BigQuery SQL 查询——这意味着一个研究者可以在几分钟内用 SQL 把自研蛋白家族在数亿条环境蛋白序列中筛一遍，全部免费且无需处理许可问题。对于蛋白质家族挖掘、酶发现与生物技术筛选，这是一个被严重低估的资源。
§1.3 同类资源横向对比
| 资源 | 运营方 | 数据性质 | 规模口径 | 分析自动化 | 主要差异化 |
|---|---|---|---|---|---|
| MGnify | EMBL-EBI | 衍生分析结果 + 基因组目录 + 蛋白库 | 近 50 万次分析；301,808 个基因组（2023 论文口径） | 平台侧统一流水线，全套免费 | 唯一提供跨研究可比的批量标准化分析结果 |
| ENA | EMBL-EBI | 原始序列归档（INSDC 欧洲节点） | 存储量为 EB 级 | 不提供分析，只归档 | MGnify 的原始数据上游；两者是分工关系而非竞品 |
| NCBI SRA | NCBI | 原始序列归档（INSDC 美国节点） | 存储量为 EB 级 | 不提供分析 | 与 ENA 同属 INSDC 三节点，数据互通 |
| Qiita / QIIME 2 生态 | 社区与学术团队 | 用户自行运行的分析平台 | 依用户提交而定 | 需用户自备算力运行 | 灵活度最高，但结果无跨研究统一口径 |
| MG-RAST | 早期社区项目 | 衍生分析结果 | 累计分析量与 MGnify 同一量级的历史项目 | 曾有统一流水线 | 更新与维护活跃度低于 MGnify，新版流程支持有限 |
| UniRef 等通用参考蛋白库 | UniProt 联盟 | 序列聚类集合 | 依版本而定 | 不提供样本级分析 | 通用而非环境特异；MGnify 蛋白库是其环境宏基因组的补充 |
需要强调：MGnify 与 ENA、UniProt 同属 EMBL-EBI 的数据资源体系，三者是上下游与互补关系。MGnify 的数据规模不是由其自身决定，而是由 ENA 中可分析的公开数据量间接决定——这也是为什么 MGnify 的样本数会随全球提交量自然增长。
§1.4 版本时间轴
| 时间 | 事件 | 影响 |
|---|---|---|
| 2011 前后 | EBI Metagenomics 服务上线 | 早期宏基因组分析服务，规模与分析类型有限 |
| 2018 | 正式更名为 MGnify | 官方文档表述为 “re-branded in 2018”；官方博客标题为 “EBI Metagenomics becomes MGnify”，博文本身未标年份 |
| 2020 | NAR 2020 平台论文发表 | 确立 MGnify 作为 EMBL-EBI 微生物组分析资源的学术定位 |
| 2021-2022 | 基因组目录产品线推出 | MGnify Genomes 按生物群落发布 MAG 目录 |
| 2023-01 | NAR 2023 平台论文发表 | 记录累计"近 50 万次分析"的规模口径 |
| 2023 | JMB 基因组目录论文发表 | 记录 7 个目录、301,808 个基因组、11,048 个物种代表、36 个未培养类群 |
| 2024-04 | 蛋白数据库版本 | 约 24 亿条非冗余蛋白序列 |
| 2024-2025 | 流水线 v6.0 发布 | 改用 Nextflow 重写并拆分为多个独立子流程；v5.0 结果继续保留访问 |
| 2026-07 | 蛋白数据库最新版本 | 约 57 亿条非冗余蛋白序列（官方博客披露；EMBL-EBI 相关新闻稿另给出 24.5 亿的旧版口径，使用时请核对具体版本目录） |
| 2026-09 | 官网基因组目录扩展 | 浏览页显示约 21 个目录，含 marine-eukaryotes-vbeta 真核 beta 目录 |
§1.5 典型应用场景
- 跨研究微生物组元分析：用 API 按生物群落批量拉取数百个研究的分类学丰度表，构建统一矩阵后做大规模关联分析或机器学习建模，避免逐篇论文手工提取数据的巨大成本。
- 菌群-表型关联建模：以人类肠道相关研究的物种谱与功能谱为特征，结合文献中公开的表型信息，训练疾病风险分层或疗效响应的探索性模型（须注意 MGnify 本身不含临床表型字段，需外部链接）。
- MAG 目录驱动的基因发现：下载特定生物群落的基因组目录，用 MGYG 序列做读长比对参考，或在其预测蛋白集中搜索目标酶家族、生物合成基因簇（antiSMASH 注释结果可直接获得）。
- 新物种与未培养类群的参考基因组获取：研究某个尚未培养的类群时，可先在 MGnify Genomes 中查找是否已有其物种代表基因组，避免重复组装。
- 分类器与注释工具基准测试：以 MGnify 统一流水线的输出作为参照标准，评估自研或第三方分类注释工具在真实环境样本上的表现。
§1.6 阅读导航
本文按"先理解平台，再动手使用"组织：§2 说明它与疾病研究的关联方式以及它不是临床队列；§3 给出规格与版本抉择矩阵（只想知道用哪个版本，直接跳 §3.0）；§4 拆解 accession 体系与目录树，这是正确拼接 API 与 FTP 路径的前提；§5 讨论划分策略与泄漏风险；§6 是全篇最实战的部分，含可运行代码与 8 个真实坑点；§7 给出 DAIMS 质量评估；§8 汇总工具与论文生态。
§2 医学背景
§2.1 微生物组在人类疾病中的定位
MGnify 不是疾病队列数据集，它不存储患者诊断、不提供表型标签。但微生物组作为暴露变量或中介变量，与大量人类疾病存在经过同行评审的关联。下表列出 MGnify 数据在文献中最常被用于研究的疾病方向及其 ICD-11 编码，供构建研究问题时参考。这些编码描述的是研究应用领域，不是 MGnify 数据集自带的标签。
| 疾病方向 | ICD-11 编码 | 中文名 | MGnify 数据在该研究中的角色 |
|---|---|---|---|
| 炎症性肠病 | DD90 | 炎症性肠病 | 肠道菌群失调作为疾病标志物与潜在致病因素 |
| 结直肠癌 | 2B91 | 结肠恶性肿瘤 | 菌群组成差异与肿瘤分期、免疫治疗响应的关联 |
| 2 型糖尿病 | 5A11 | 2 型糖尿病 | 肠道菌群与胰岛素抵抗、代谢通路的关联 |
| 肥胖症 | 5B81 | 肥胖 | 菌群多样性与能量摄取假说 |
| 感染性腹泻 | 1A00-1A40 | 细菌性肠道感染 | 病原体检测与群落恢复动态 |
| 肝硬化 | DB93 | 肝硬化 | 肠道菌群-肝轴、细菌易位与并发症 |
| 哮喘与过敏 | CA23 / 4A80 | 哮喘 / 过敏性鼻炎 | 卫生假说下的早期菌群暴露 |
| 单次发作抑郁障碍 | 6A70 | 单次发作抑郁障碍 | 微生物-肠-脑轴研究方向 |
§2.1b SNOMED CT 映射
| 研究标签 | ICD-11 | SNOMED CT 码 | 术语 |
|---|---|---|---|
| 宏基因组测序 | — | 364533000 | Metagenomic sequencing |
| 16S rRNA 基因测序 | — | 446589001 | Sequencing of 16S ribosomal RNA gene |
| 肠道微生物组检测 | — | 87612003 | Examination of intestinal microbiome |
| 炎症性肠病 | DD90 | 24526004 | Inflammatory bowel disease |
| 2 型糖尿病 | 5A11 | 44054006 | Type 2 diabetes mellitus |
| 肥胖 | 5B81 | 414915002 | Obese |
| 结直肠恶性肿瘤 | 2B91 | 363406005 | Malignant tumor of colon |
| 菌群失调 | — | 1240608006 | Dysbiosis |
§2.2 微生物组研究的技术背景
微生物组研究的核心逻辑是"不培养、直接测"。传统微生物学必须先分离培养单个菌株才能研究，而环境与人体样本中绝大多数微生物无法在实验室培养。高通量测序绕过了这一限制：把样本中所有微生物的 DNA 一起提取、一起测序，再通过计算方法把混合的序列"拆解"回物种与功能。
主流技术路线有两条。第一条是扩增子测序，也称标记基因测序，最常用的是 16S rRNA 基因——这段基因在所有细菌与古菌中都存在，但包含若干高度可变的区域（V1-V9），可变区序列差异可以用于推断物种归属。它的优点是成本低、可覆盖大量样本，缺点是分辨率只到属水平（部分可到种）、无法提供功能信息。第二条是鸟枪法宏基因组测序，把样本中所有 DNA 直接打碎测序，理论上可以重建完整的物种组成与基因功能谱，甚至可以组装出完整基因组，代价是成本高、计算量大、对低丰度物种不敏感。
两条路线各有标准化的分析范式。扩增子路线通常包括：质控去接头、去嵌合体、按相似度聚类成 OTU 或按精确序列生成 ASV、比对参考数据库得到分类注释、构建丰度表。宏基因组路线通常包括：质控、去宿主序列、从头组装或直接比对、基因预测、功能数据库注释、物种定量。MGnify 的贡献是把这两条路线的全部步骤固化成可复现的流水线，并对全球公开数据批量执行。
需要理解的一个关键点：MGnify 输出的分类学结果依赖于它使用的参考数据库版本。同一个 16S 序列，在 SILVA 132 与更新版 SILVA 中的分类注释可能不同，因为数据库本身在扩充与修订。这使得"数据库版本"成为解释 MGnify 历史结果时必须记录的关键元数据，也是跨版本合并数据时的首要风险来源。
§2.3 临床与科研任务定义
MGnify 数据能够支撑的计算任务可分为研究级与临床级两类，两者的证据要求相差极大。
| 层级 | 任务 | 典型做法 | 证据成熟度 |
|---|---|---|---|
| 研究级 | 群落结构描述 | 计算 alpha/beta 多样性、物种丰度矩阵 | 成熟，标准化程度高 |
| 研究级 | 差异丰度分析 | 比较病例组与对照组物种或功能丰度 | 成熟但易受组成性数据偏倚影响 |
| 研究级 | 功能通路推断 | 由物种组成或基因注释推断代谢通路 | 中等，依赖数据库完整性 |
| 研究级 | 生物标志物筛选 | 用机器学习从菌群谱中筛特征 | 中等，跨队列复现率普遍偏低 |
| 研究级 | MAG 重建与新物种发现 | 组装分箱、物种聚类、参考基因组构建 | 成熟，MGnify Genomes 即此产物 |
| 临床级 | 病原体检测与鉴定 | 宏基因组测序直接检测病原 | 部分场景已进入临床验证，但主要依赖专用临床流程而非 MGnify |
| 临床级 | 疾病诊断分类器 | 用菌群特征做诊断 | 尚不成熟，跨人群泛化失败率高，不构成诊断依据 |
| 临床级 | 治疗响应预测 | 预测免疫治疗或药物响应 | 探索阶段，队列间结论不一致 |
必须明确的边界：MGnify 本身不提供任何临床级工具或诊断输出。它是一个研究基础设施，把公开数据加工成可复用形式。任何声称"用 MGnify 做诊断"的工作，其临床有效性完全取决于研究者自己构建的模型与验证流程，与 MGnify 无关。
§2.4 样本来源与人群构成
MGnify 的数据来源是 INSDC/ENA 的公开提交，因此其"人群"构成实际上反映的是全球微生物组研究的取样偏好，而非某种抽样设计。下表给出主要的生物群落类别及其在文献中的代表性。
| 类群来源 | 典型环境 | 时间范围 | 宿主与年龄特征 | 地理集中度 | 在 MGnify 中的角色 |
|---|---|---|---|---|---|
| 人类肠道 | 粪便、结肠黏膜 | 随提交持续更新 | 覆盖全年龄段，成人为主 | 欧洲、北美、东亚集中 | 扩增子数据占比最高的类群之一 |
| 人类其他部位 | 口腔、皮肤、阴道、呼吸道 | 随提交持续更新 | 全年龄段 | 同上 | 数量少于肠道，但多部位研究增长快 |
| 海洋 | 水体、沉积物、深海 | 随提交持续更新 | 不适用 | 北大西洋、地中海、极地集中 | 基因组目录的重要来源 |
| 土壤 | 农田、森林、根际 | 随提交持续更新 | 不适用 | 北美、欧洲、中国 | 目录物种多样性最高 |
| 淡水 | 河流、湖泊 | 随提交持续更新 | 不适用 | 全球分散 | 相对小规模 |
| 牲畜与食品 | 瘤胃、发酵食品 | 随提交持续更新 | 依宿主而定 | 欧洲、大洋洲 | 应用导向研究 |
| 极端环境 | 热泉、盐湖、酸性矿排水 | 随提交持续更新 | 不适用 | 全球分散 | 新颖类群的主要发现地 |
因 MGnify 不做抽样设计而只聚合既有提交，其样本分布存在明显的"研究热点偏倚"——被研究得多的环境就有更多数据，这不等于该环境在自然中更重要。这一偏倚在 §7.1 会进一步量化讨论。
§2.5 临床与科研价值
MGnify 的价值不在于单个样本的深度，而在于横向的广度与口径的一致性。对于临床研究团队，它主要解决三类问题。第一类是对照数据的获取：做小规模临床菌群研究时，研究者往往缺乏足够的公开对照；MGnify 提供的按生物群落索引的大规模样本谱可以直接用作外部对照或人群基线参考。第二类是方法学验证：在把自研分析流程用于临床样本前，可先在 MGnify 的标准化结果上比对，确认自己的流程没有系统性偏倚。第三类是假设生成：通过跨数百个研究检索特定物种或功能的分布，快速判断某个假设是否值得投入资源做前瞻研究。
对基础与应用微生物学团队，价值集中在基因组目录与蛋白库。基因组目录提供了绕过培养的参考序列来源；蛋白库提供了环境蛋白序列的功能搜索底座，且以 CC0 许可发布，解除了商业应用与再分发的法律障碍。这两项资源在酶工程、天然产物发现、合成生物学与农业微生物组领域已经产生实际产出。
§2.6 金标准与参照体系
MGnify 的分析结果本身在微生物组领域被广泛用作参照标准，因此有必要明确"什么是它的金标准"。
| 环节 | 参照体系 | 性质 | 说明 |
|---|---|---|---|
| 物种分类注释（16S/18S） | SILVA 132 | 人工审编的 rRNA 数据库 | MGnify v5.0 扩增子流程使用 |
| ITS 分类注释 | ITSoneDB 1.138 / UNITE 8.0 | 人工审编的真菌 ITS 数据库 | 两库结合提升真菌覆盖率 |
| 物种定量（宏转录组） | mOTUs2 2.5.1 | 标记基因方法 | 不依赖完整组装即可定量 |
| 蛋白结构域注释 | InterProScan 75.0 + Rfam 13.0 | 模型驱动的注释体系 | 结构域与 RNA 家族注释标准 |
| 蛋白功能分类 | eggNOG-mapper / KOfam | 直系同源群与 KEGG 通路 | 通路层面的功能解读 |
| 次级代谢产物 | antiSMASH 4.2.0 | 生物合成基因簇规则库 | 预测 BGC |
| 基因组质量 | CheckM v1.0.11 | 单拷贝标记基因法 | 评估完整度与污染度 |
| 基因组分类 | GTDB | 基因组水平的分类体系 | 相较 16S 体系更稳定 |
| 基因组质量标准 | MIMAG medium | 社区共识标准 | 完整度与污染度阈值 |
| MAG 去冗余 | dRep v2.2.4（95% ANI / 30% AF） | 聚类算法 | 物种簇划分标准 |
需要说明的是，上述工具链为 v5.0 版本口径。v6.0 已改用 Nextflow 重写并更新了部分工具的版本，两者的具体版本号不通用。引用 MGnify 结果时，必须同时记录流水线版本与参考数据库版本，否则结果的复现性无法保证。
§3 数据集规格
§3.0 版本抉择矩阵
MGnify 提供了多条并行的版本线，选错会让后续所有工作白做。先对号入座：
| 你的需求 | 推荐版本 | 规模 | 理由 |
|---|---|---|---|
| 复现某篇已发表论文的分析结果 | 与论文中记录的 pipeline 版本一致（多数 2023-2024 论文为 v5.0） | 按 MGYA 单次分析 | 跨版本数值不可比，必须对齐版本 |
| 使用最新分类学与功能注释能力 | pipeline v6.0 产出的新分析 | 按 MGYA 单次分析 | v6.0 含 VIRify、改进的真核支持与更新参考库 |
| 做跨数百研究的元分析 | v5.0 历史结果集合 | 近 50 万次分析中的目标子集 | v5.0 存量最大且注释口径统一，v6.0 覆盖仍在增长 |
| 构建人类肠道物种丰度参考 | human-gut 目录（最新版 v2.0.2） | 4,744 species / 289,232 genomes | 单目录物种与基因组量最大，肠道研究首选 |
| 海洋微生物组研究 | marine 目录（含真核 beta 版） | 按目录版本 | 海洋特有类群覆盖优于通用库 |
| 真菌 ITS 分析 | 扩增子流程（ITS 分区 + UNITE/ITSoneDB） | 按 MGYA | 需选择 ITS1 或 ITS2 分区策略 |
| 病毒与移动元件研究 | v6.0 的 VIRify 输出 | 按分析 | v5.0 无同等能力的病毒注释模块 |
| 蛋白家族大规模搜索 | 蛋白数据库最新日期版本（2026_07） | 约 57 亿条非冗余序列 | 序列数量最大；但注意在线 HMMER 搜索的实现版本可能滞后于 FTP 最新版 |
| 教学与流程演练 | 任意小规模 MGYA 分析结果 | 单次分析数 MB 至数 GB | 无需下载全库，取单个 accession 即可完整走通流程 |
核心原则：先确定"要对齐的版本"，再下载数据。MGnify 的 FTP 目录结构中版本是路径的一部分，事后补记版本的成本远高于一开始就记录。
§3.1 模态详情
| 模态 | 内容 | 产出粒度 | 典型文件 |
|---|---|---|---|
| 扩增子（16S/18S/ITS） | 标记基因序列的分类注释与丰度 | 每次分析一份分类谱 | 分类学丰度 TSV、OTU/ASV 表、代表序列 FASTA |
| 宏基因组（原始读长） | 直接比对得到的物种与功能谱 | 每次分析一份物种谱与功能谱 | 物种丰度 TSV、InterPro/GO/KEGG 注释 TSV |
| 宏转录组 | 表达层面的物种与功能活性谱 | 每次分析一份表达谱 | 功能丰度 TSV、mOTUs2 定量表 |
| 组装 | 宏基因组从头组装的序列与基因 | 每次分析一组 contig 与预测基因 | contig FASTA、GFF、预测蛋白 FASTA |
| 基因组目录（MGYG） | 按生物群落发布的 MAG 与分离株基因组 | 每个目录含数千至数十万基因组 | 基因组 FASTA、目录清单 TSV、系统发育树文件 |
| 蛋白数据库 | 全平台预测蛋白去冗余集合 | 每个日期版本一个全集 | FASTA 序列文件、聚类映射文件、LICENCE.txt |
§3.2 规模与子集分布
| 子集 | 规模口径 | 数据来源 | 说明 |
|---|---|---|---|
| 全平台分析总数 | 近 50 万次（NAR 2023 论文口径） | 10.1093/nar/gkac1080 | 累计完成的标准化流水线运行次数 |
| 分析结果 FTP 目录 | 按 INSDC accession 与 pipeline 版本分目录 | ftp.ebi.ac.uk/pub/databases/metagenomics/mgnify_results/ | 单次分析结果体积从数 MB 到数 GB 不等 |
| 基因组目录（2023 论文） | 7 个 catalogues / 301,808 genomes / 11,048 species reps | 10.1016/j.jmb.2023.168016 | 2023 年快照，已被后续版本超越 |
| 基因组目录（2026-09 官网） | 约 21 个目录 | ebi.ac.uk/metagenomics/browse/genomes | 含 marine-eukaryotes-vbeta 真核 beta |
| 最大单目录 | human-gut v2.0.2：4,744 species / 289,232 genomes | ebi.ac.uk/metagenomics/browse/genomes | 人类肠道研究首选参考 |
| 未培养类群覆盖 | 36 个此前未培养类群获首个参考基因组 | 10.1016/j.jmb.2023.168016 | 2023 年论文口径 |
| 蛋白数据库（2026_07） | 约 57 亿条非冗余蛋白序列 | 官方博客与 FTP 版本目录 | 上一版本 2024-04 约 24 亿条；EMBL-EBI 相关新闻稿曾给出 24.5 亿的数值，使用时须核对具体版本 |
| 站内访问规模 | 2025 年官网约 60,000 次访问、约 94,000 次搜索、约 15,000 注册用户 | 10.1093/nar/gkae1089 | 平台使用活跃度的官方口径 |
§3.3 格式与编码规范
| 数据类别 | 主格式 | 编码 | 备注 |
|---|---|---|---|
| API 响应 | JSON | UTF-8 | 遵循 JSON:API 规范，含分页链接与关系链接 |
| 分类学丰度表 | TSV | UTF-8 | 列含 taxonomy 谱系与相对丰度或计数 |
| 功能注释表 | TSV | UTF-8 | 列含 InterPro ID、GO term、KEGG 通路、eggNOG 群 |
| 序列数据 | FASTA | ASCII | contig、预测蛋白、基因组序列 |
| 基因结构 | GFF3 | ASCII | 基因坐标与类型标注 |
| 基因组目录 | FASTA + TSV + Newick | 混合 | 目录打包下载含清单与系统发育树 |
| 蛋白数据库 | FASTA（可压缩） | ASCII | 随附 LICENCE.txt（CC0 1.0） |
§3.4 存储与传输
MGnify 没有"全库下载"这一选项，体量按需索取。参考量级：单次扩增子分析结果为数十 MB 至数百 MB；单次宏基因组组装分析可达数 GB；一个完整生物群落基因组目录从数十 GB 到数百 GB；蛋白数据库全量下载为数百 GB 级并需考虑解压后空间。建议先通过 API 用 accession 精确定位目标再下载所需文件，避免盲目拉取整个 FTP 目录。FTP 站点同时支持标准 FTP 与 HTTPS 访问，大批量下载建议使用 wget 或 aria2 并配合断点续传。
§3.5 标注方式
| 标注维度 | 方式 | 自动化程度 | 可靠度说明 |
|---|---|---|---|
| 物种分类注释 | 数据库比对（SILVA/UNITE/ITSoneDB/GTDB） | 全自动 | 依赖参考库完整度；属水平较可靠，种水平不确定性大 |
| 功能注释 | 模型与同源比对（InterProScan/eggNOG/KOfam） | 全自动 | 结构域注释可靠；通路推断存在误差传递 |
| 基因预测 | 从头预测（Prodigal/FragGeneScan） | 全自动 | 短读长样本的基因片段可能不完整 |
| 组装 | 从头组装（metaSPAdes） | 全自动 | 重复区域与低丰度物种组装质量受限 |
| MAG 质量 | 标记基因法（CheckM） | 全自动 | 仅为估计值，非真实完整度 |
| MAG 分箱与聚类 | 算法聚类（dRep，95% ANI / 30% AF） | 全自动 | 阈值设定是人为约定，物种边界存在争议 |
| 基因组分类 | 基因组分类体系（GTDB） | 全自动 | 相较 16S 体系更稳定，但仍在持续修订 |
| 生物群落标签 | 提交者自行填写 | 无自动校验 | 最大的元数据质量风险点，粒度不一致 |
最后一行需要特别强调：MGnify 的 biome 字段来自提交者在 ENA 提交时填写的环境分类信息，MGnify 不做自动校验。因此按 biome 过滤数据时，可能会因为提交者填写习惯不同而漏掉或误纳样本。§6.5 的坑点 2 会给出具体的应对方法。
§3.6 标注者资质与一致性
MGnify 的注释链路中没有人工标注者，全部由流水线自动完成。因此"标注者一致性"这一维度不适用传统含义，取而代之的是流水线版本一致性与参考数据库一致性。同一份原始数据在 v5.0 与 v6.0 下分析会得到数值不同的结果；同一份数据在不同参考数据库版本下分析也会得到不同的分类注释。这意味着结果的"一致"只在同版本内成立。研究者做跨研究比较时，若目标数据来自不同版本，必须先确认版本分布，必要时对关键结论做版本敏感性分析。
§3.7 采集与更新周期
MGnify 的数据更新没有固定发布周期，是随提交量持续增量的过程。基因组目录与蛋白数据库则采用版本化发布：基因组目录按目录名加版本号（如 human-gut v2.0.2），蛋白数据库按日期目录（如 2024_04、2026_07）。做时间敏感性研究时，记录数据获取日期是必要的，因为同一个 accession 的结果可能在版本升级后被重新计算。
§3.8 地理覆盖
数据地理分布由 INSDC 提交量决定，明显集中于欧洲、北美与东亚的研究机构。平台已加入 EEZ（专属经济区）地理信息支持，用于标识采样是否位于某国专属经济区内，帮助使用者判断是否存在主权与惠益分享相关的合规约束。这一功能对海洋微生物组研究尤其重要，海洋样本的采样许可与数据使用可能受《生物多样性公约》及其名古屋议定书约束。
§3.9 技术规格与依赖
| 环节 | 相关技术规格 | 说明 |
|---|---|---|
| 测序平台 | Illumina 各代平台为主；长读长平台支持已加入 | 长读长数据在 v6.0 中受支持程度更好 |
| 读长类型 | 单端与双端；扩增子含 16S/18S/ITS1/ITS2 | 分区选择影响可比性 |
| 组装工具 | metaSPAdes 3.13（v5.0） | 内存需求高，大规模样本需高内存节点 |
| 序列搜索 | HMMER（蛋白在线搜索）；BIGSI 与 Sourmash（核酸搜索） | Sourmash 结果服务器仅保留 30 天 |
| 分析框架 | CWL（v5.0）→ Nextflow（v6.0） | 两条技术栈并存 |
| 云查询 | Google Cloud Public Datasets + BigQuery | 蛋白库可 SQL 直查，免下载 |
§3.10 溯源链
完整的 MGnify 数据溯源链为：样本采集 → 测序 → 提交至 ENA（获取 INSDC accession，如 ERR/SRR/DRR）→ MGnify 抓取或接收提交 → 执行特定版本流水线 → 生成 MGYA 分析 accession → 结果挂出至网站、FTP 与 API。组装与分箱环节额外产生 contig 与 MAG；MAG 经质量过滤与聚类后进入 MGYS 目录集合，个体基因组获得 MGYG accession；预测蛋白获得 MGYP accession 并汇入蛋白数据库。任何使用时点想复现结果，都需要沿这条链回溯并记录每一级的版本信息。
§4 数据结构
§4.0 目录树
MGnify 的分析结果 FTP 目录按"结果类型 → INSDC accession → 流水线版本 → 具体文件"组织。下面是下载一个分析结果后的典型结构预览：
mgnify_results/
├── ERR1234567/ # 按 INSDC run accession 命名的一级目录
│ └── version_5.0/ # 流水线版本子目录（版本是路径的一部分）
│ ├── ERR1234567_FASTQ/ # 质控后的读长（可能因提交设置而省略）
│ ├── taxonomy/ # 分类学分析结果
│ │ ├── SILVA-ssu/ # 按参考库分子类型分目录
│ │ │ ├── taxonomy.tsv # 分类注释与丰度主表
│ │ │ ├── otu_table.tsv # OTU/ASV 丰度矩阵
│ │ │ └── reference.fasta # 代表序列
│ │ └── UNITE-its/ # 真菌 ITS 结果（若适用）
│ ├── functional-analysis/ # 功能分析结果
│ │ ├── InterProScan.tsv # 蛋白结构域注释
│ │ ├── GO.tsv # Gene Ontology 注释
│ │ ├── KEGG.tsv # KEGG 通路注释
│ │ └── eggNOG.tsv # eggNOG 直系同源群
│ ├── assembly/ # 组装结果（仅组装型流水线）
│ │ ├── contigs.fasta
│ │ ├── contigs.gff
│ │ └── predicted_proteins.fasta
│ └── analysis_summary.json # 本次分析的元数据汇总
└── ...
mgnify_genomes/
├── human-gut/
│ └── v2.0.2/ # 目录名 + 版本号
│ ├── genome-list.tsv # MGYG 基因组清单（含质量指标）
│ ├── species_catalogue/ # 按物种组织的目录结构
│ │ ├── species_name/
│ │ │ ├── MGYG000000001.fna # 基因组序列
│ │ │ ├── MGYG000000001.gff # 基因结构
│ │ │ └── MGYG000000001.faa # 预测蛋白
│ ├── phylogenetic_trees/ # 系统发育树文件
│ └── catalogue_metadata.json
└── ...
peptide_database/
├── 2024_04/ # 按日期版本化
│ ├── mgnify_peptides.fasta
│ ├── mgnify_peptides_clusters.tsv
│ └── LICENCE.txt # CC0 1.0 Universal
└── 2026_07/
├── mgnify_peptides.fasta
├── mgnify_peptides_clusters.tsv
└── LICENCE.txt
理解这个结构的两个要点：第一，版本号是路径的一部分，不在文件名里，因此只保存文件而不保存路径会丢失版本信息；第二，分析结果的目录层级比基因组目录深，因为分析结果需要同时区分参考库或分析类型。
§4.1 DAIMS 字段字典
MGnify 的"数据表"并非单一文件，而是跨 API、TSV 与目录清单的一套字段体系。下表以核心实体为行，描述其关键字段。类型与示例值基于官方 API 文档与公开输出文件结构。
| 字段名 | 类型 | 说明 | 示例值 | AI 用途 | 观测误差 | 信息性缺失编码 | 取值范围 |
|---|---|---|---|---|---|---|---|
| analysis_accession | Text | MGYA 分析编号，一次流水线运行的唯一标识 | MGYA00000001 | 主键，用于去重与关联下载 | 无 | 不适用（必填） | MGYA 加 8 位数字 |
| run_accession | Text | INSDC/ENA 原始读长编号 | ERR1234567 | 回溯原始数据 | 无 | 不适用 | ERR/SRR/DRR 加数字 |
| pipeline_version | Text | 分析所用流水线版本 | 5.0 | 决定结果可比性，必须作为分组变量 | 无 | 不适用 | 5.0 / 6.0 等 |
| analysis_type | Text | 流水线类型 | amplicon / metagenomic / metatranscriptomic / assembly | 决定可用字段集合 | 无 | 不适用 | 见左 |
| biome | Text | 生物群落分类谱系（提交者填写） | root:Host-associated:Human:Digestive system | 分组与分层采样依据 | 高（无自动校验） | 缺失时归入 unclassified | GOLD 风格层级 |
| experiment_type | Text | 实验类型 | amplicon / assembly / raw reads | 与 analysis_type 配合使用 | 低 | 不适用 | 见左 |
| taxonomy_lineage | Text | 分类学谱系（如门、纲、目、科、属、种） | d__Bacteria;p__Bacillota;… | 特征工程的主要来源 | 中（依赖参考库版本） | unclassified / unassigned | 分级字符串 |
| count_abundance | Float | 该分类单元或功能的计数或相对丰度 | 1234 / 0.0234 | 建模输入特征 | 中（受测序深度影响） | 0 表示未检出，与真缺失不同 | 大于等于 0 |
| interpro_id | Text | InterPro 条目编号 | IPR000001 | 蛋白功能特征 | 低 | 无注释时整行缺失 | IPR 加 6 位数字 |
| go_term | Text | Gene Ontology 术语 | GO:0008150 | 功能富集分析 | 低 | 同上 | GO: 加 7 位数字 |
| kegg_pathway | Text | KEGG 通路编号 | ko00010 | 通路层面分析 | 中（注释覆盖率有限） | 同上 | ko 加 5 位数字 |
| genome_accession | Text | MGYG 基因组编号 | MGYG000000001 | 基因组目录主键 | 无 | 不适用 | MGYG 加 9 位数字 |
| catalogue_accession | Text | MGYS 目录集合编号与版本 | human-gut v2.0.2 | 版本追踪 | 无 | 不适用 | 名称加版本号 |
| completeness | Float | CheckM 估计的基因组完整度（%） | 98.5 | 质量过滤阈值 | 中（为估计值） | 无法计算时缺失 | 0-100 |
| contamination | Float | CheckM 估计的基因组污染度（%） | 1.2 | 质量过滤阈值（不超过 5%） | 中（为估计值） | 无法计算时缺失 | 0-100 |
| species_rep | Integer | 是否为物种代表基因组的标记 | 1 | 构造去冗余训练集 | 无 | 不适用 | 0 / 1 |
| latitude_longitude | Float | 采样点坐标（若提交者提供） | 52.1 / 0.1 | 空间分析 | 高（常见缺失或粗化） | 缺失即无坐标 | -90~90 / -180~180 |
关于"信息性缺失"最重要的一条：丰度表中的 0 与"未检出"不等价。0 可能意味着该分类单元在样本中确实不存在，也可能意味着测序深度不足未能检出。做差异丰度分析时若不处理这一点，会系统性地高估稀有类群的组间差异。§6.5 的坑点 3 专门讨论这一问题。
§4.2 标签与分布
MGnify 的"标签"分两个层面。第一层是分类学标签，即物种、属、科等分类单元，其分布是典型的长尾——少数高丰度类群占据大部分读数，大量低丰度类群各占极小比例。这种分布在建模时会导致严重的类别不平衡。第二层是元数据标签，如 biome、analysis_type、宿主类型等，其分布取决于全球提交量，人类肠道相关样本占比明显偏高。
| 标签维度 | 类别数 | 分布特征 | 建模注意事项 |
|---|---|---|---|
| 分类单元（种水平） | 数千至数万 | 极度长尾 | 需要稀有类群合并或存在性二值化 |
| 分类单元（属水平） | 数百至数千 | 长尾 | 常用工作层级，平衡了分辨率与稳定性 |
| 功能通路（KEGG） | 数百 | 中长尾 | 覆盖率受限，注意未注释比例 |
| biome | 数十至数百（粒度不一） | 高度不均 | 建议归并到 1-2 层大类别 |
| analysis_type | 4 | 相对均衡但扩增子偏多 | 跨类型混合建模需谨慎 |
§4.3 关键统计
| 统计项 | 数值 | 来源 |
|---|---|---|
| 累计分析次数 | 近 50 万次 | NAR 2023 论文 |
| 基因组目录数（2023 论文） | 7 个 | JMB 2023 论文 |
| 基因组总数（2023 论文） | 301,808 个 | JMB 2023 论文 |
| 物种代表数（2023 论文） | 11,048 个 | JMB 2023 论文 |
| 未培养类群首次参考基因组 | 36 个 | JMB 2023 论文 |
| 基因组目录数（2026-09 官网） | 约 21 个 | 官网浏览页 |
| 最大单目录基因组数 | 289,232 个（human-gut v2.0.2） | 官网浏览页 |
| 最大单目录物种数 | 4,744 个（human-gut v2.0.2） | 官网浏览页 |
| 蛋白数据库序列数（2026_07） | 约 57 亿条非冗余序列 | 官方博客与 FTP 版本目录 |
| 蛋白数据库序列数（2024_04） | 约 24 亿条非冗余序列 | FTP 版本目录 |
| 2025 年官网访问次数 | 约 60,000 次 | EMBL-EBI 2024-25 报告 |
| 2025 年站内搜索次数 | 约 94,000 次 | EMBL-EBI 2024-25 报告 |
| 注册用户数 | 约 15,000 人 | EMBL-EBI 2024-25 报告 |
§4.4 数据层级关系
MGnify 的实体关系可以理解为五层结构。第一层是项目或研究，对应 ENA 的 study accession，代表一次完整的实验设计。第二层是样本，对应 ENA 的 sample accession，代表一个物理样本及其环境元数据。第三层是运行，对应 ENA 的 run accession，代表一次测序产生的读长数据。第四层是分析，对应 MGYA accession，代表流水线对某次运行执行的一次计算，这里是 MGnify 实际贡献的层级。第五层是分析产物，包括分类谱、功能谱、组装序列与预测蛋白（MGYP）。
基因组目录线是相对独立的支线：多份同生物群落的宏基因组经组装与分箱产生 MAG，MAG 经质量过滤与聚类后，个体进入 MGYG，集合进入 MGYS 目录。这两条支线在蛋白数据库处汇合——分析产物的预测蛋白与基因组目录的预测蛋白共同经去冗余后构成 MGnify 蛋白数据库。
关联键的使用要点：用 run accession 可以把 MGnify 分析结果关联回 ENA 的原始数据与环境元数据；用 biome 字段可以把不同研究的样本聚合；用 catalogue accession 可以追踪基因组属于哪个目录的哪个版本。任何一步关联都可能因为元数据缺失而失败，这是大规模元分析中最常见的工程障碍。
§4.5 缺失值处理
| 缺失情形 | 含义 | 是否信息性 | 建议处理 |
|---|---|---|---|
| biome 字段为空或归入 unclassified | 提交者未填写环境信息 | 是（反映提交质量） | 归入 unknown 类别，不要删除样本 |
| 分类注释为 unclassified | 序列无法匹配参考库任何已知类群 | 是（可能代表新类群） | 保留为独立类别，不要当作缺失 |
| 功能注释整行为空 | 该蛋白未匹配任何功能数据库 | 是（可能为未知功能） | 计入未注释比例，作为质控指标 |
| 丰度值为 0 | 未检出，可能真实不存在或深度不足 | 否（非信息性） | 需做零膨胀处理或使用存在性二值化 |
| 经纬度缺失 | 提交者未提供坐标或已粗化 | 是（可能出于隐私保护） | 空间分析时单独设 unknown 组 |
| 基因组完整度为空 | CheckM 无法计算 | 否 | 该基因组通常不会进入目录，若出现则剔除 |
§5 划分与使用建议
§5.1 官方划分情况
MGnify 不提供官方的训练集、验证集与测试集划分。 这一点必须在任何论文与模型卡中明确说明，避免误导读者以为存在标准划分。平台提供的是分析结果与元数据，划分策略完全由使用者自行设计。这直接影响 AI 就绪度评分——§INFOBOX 中给出 3/5，扣分主因即在此。
§5.2 社区惯例划分
由于没有官方划分，社区实践中形成了若干常见做法。第一种是按研究划分，即整篇研究的样本全部归入同一子集，避免同一研究内部的批次效应泄漏到验证集。第二种是按生物群落划分，用于评估跨环境泛化能力，例如在人类肠道数据上训练、在土壤数据上测试。第三种是按地理区域划分，用于评估地理泛化。第四种是按时间划分，用较早提交的数据训练、较晚的数据测试，模拟真实部署场景。第四种做法在 MGnify 上尤其值得推荐，因为提交时间与测序技术、分析版本的变化有相关性，能更真实地反映部署风险。
§5.3 泄漏风险
MGnify 的泄漏风险与常规数据集不同，主要来自三个方向。
第一，同一研究的多个运行被分到不同子集。 一个研究项目往往包含数十到数百个样本，它们在同一实验室、同一批次、同一测序仪上处理，技术特征高度相似。如果按 sample 或 run 随机划分，训练集与测试集之间会存在强烈的批次相关性，导致测试性能虚高。正确做法是按 study accession 分组划分。
第二，同一生物样本的多次测序或多次分析。 部分样本存在技术重复或多次提交，同一 accession 也可能因流水线升级而有多个版本的结果。若不去重，同一份数据会同时出现在训练与测试中。正确做法是在划分前去重，按 run accession 唯一化，并固定单一 pipeline 版本。
第三，参考数据库泄漏。 当你用 MGnify 的物种谱做特征、又以同一批数据构建的基因组目录作为参考时，存在信息闭环。例如用 human-gut 目录做读长比对得到丰度，再用这些丰度预测在该目录中存在与否相关的属性，本质上是在测试集上训练。正确做法是明确区分"用于生成特征的外部资源"与"被评估的目标"，避免同一数据同时扮演两个角色。
§5.4 划分策略建议
| 策略 | 适用场景 | 实现要点 | 风险 |
|---|---|---|---|
| 按 study 分组划分 | 通用默认选择 | 用 study accession 作为 GroupKFold 的分组键 | 若单个 study 样本量极大，可能导致组间不平衡 |
| 按 biome 分层划分 | 需要保持类别比例 | 先按 biome 分层，再在层内按 study 分组 | biome 标签粒度不一，需先归并 |
| 按地理留一划分 | 评估地理泛化 | 按提交国家或区域留一 | 部分区域样本极少，留一后无数据 |
| 按时间前向划分 | 模拟真实部署 | 按提交年份切分，早训练晚测试 | 需确保时间字段可从 ENA 获取 |
| 按 pipeline 版本对齐 | 跨版本一致性研究 | 筛选单一版本结果作为子集 | 会显著减少可用样本量 |
推荐组合：主实验采用"按 study 分组加按 biome 分层"的双重约束，另设一个"按时间前向划分"的补充实验评估部署稳健性。两组结果同时报告，能显著提升结论可信度。
§5.5 交叉验证建议
由于样本在多个层级上相关（study → sample → run），普通 K 折交叉验证会高估性能。建议使用分组交叉验证：分组键取 study accession（首选）；折数 5 折起步，若 study 数量少于 20，考虑留一研究法；在分组的前提下按目标标签分层，避免极端不平衡；至少重复 3 次不同的随机分组，报告均值与标准差，单次结果不足以说明问题。
§5.6 外部验证建议
内部交叉验证无法回答"模型换个数据集还灵不灵"。MGnify 因其跨研究聚合特性，天然适合做外部验证设计：可以在 MGnify 内部按 biome 做留一验证（在人肠道上训练、在口腔上测试），也可以跨资源验证（在 MGnify 上训练、在独立研究中测试）。建议在任何模型报告中至少包含一个完全独立的外部验证结果，并明确记录训练集与外部验证集的 pipeline 版本与参考数据库版本是否一致——若不一致，性能变化中会混入版本差异的影响，需要单独分析。
§6 AI 就绪指南
这是全篇最核心的章节。以下代码在 Python 3.11 环境下编写，依赖 requests、pandas、numpy、scikit-learn、torch。所有示例只访问公开接口，不需要 API key。
§6.0 环境准备
# 建议使用虚拟环境，避免依赖污染
python3.11 -m venv mgnify-env
source mgnify-env/bin/activate
# 核心依赖：API 访问、数据处理、建模
pip install requests pandas numpy scikit-learn
# 深度学习（仅 §6.4 需要）
pip install torch
# 可选：官方 Python SDK
pip install mgnipy
MGnify 的 REST API 不需要认证，但官方建议对批量请求设置合理的请求间隔，避免对公共服务造成压力。下面所有示例都包含基本的重试与限速逻辑。
§6.1 快速上手
以下代码预期的工作目录结构如下，data_root 是所有本地数据的根目录，后续所有路径都基于它拼接：
project_root/
├── data_root/ # 所有 MGnify 本地数据的根目录
│ ├── api_cache/ # API 响应缓存（避免重复请求）
│ ├── analyses/ # 按 MGYA 下载的分析结果
│ │ └── MGYA00000001/
│ └── genomes/ # 下载的基因组目录
│ └── human-gut/v2.0.2/
└── notebooks/
最小可用子集建议：先取单个生物群落下的 5 至 10 个 study、每个 study 取 2 至 3 个 run，总样本量 20 至 30 个，跑通完整流程后再扩展到全量。这能让你在几分钟内验证数据格式理解是否正确，而不是在下载数百 GB 数据后才发现字段含义搞错了。
# 最小可用示例：抓取人类肠道相关的分析列表并查看结构
# 目录约定：本示例不写文件，仅打印结构；缓存目录见 §6.3
import json
import time
import requests
API_BASE = "https://www.ebi.ac.uk/metagenomics/api/v1"
# 官方 API 无需认证；设置合理的 User-Agent 便于服务方识别流量来源
HEADERS = {"User-Agent": "mgnify-tutorial/1.0 (research use)"}
def api_get(path, params=None, retries=3):
"""带重试的 API 请求封装：MGnify 偶发 5xx，重试可显著提升稳定性"""
url = f"{API_BASE}/{path.lstrip('/')}"
for attempt in range(retries):
try:
resp = requests.get(url, params=params, headers=HEADERS, timeout=30)
if resp.status_code == 200:
return resp.json()
# 429 表示触发限速，需要退避
if resp.status_code == 429:
time.sleep(2 ** attempt)
continue
except requests.RequestException:
time.sleep(2 ** attempt)
raise RuntimeError(f"API 请求失败：{url}")
# 第一步：拉取人类肠道相关的研究列表（分页）
page = api_get("studies", params={"biome_name": "root:Host-associated:Human:Digestive system",
"page_size": 5})
print("返回研究数：", len(page["data"]))
for study in page["data"]:
attrs = study["attributes"]
print(study["id"], "|", attrs.get("biome", {}).get("biome_name"), "|", attrs.get("study-name"))
§6.2 数据获取
MGnify 提供四种主要访问方式，适用场景不同：
| 方式 | 适用场景 | 优点 | 限制 |
|---|---|---|---|
| REST API | 按条件筛选、程序化批量获取元数据与部分结果 | 结构化、支持分页与过滤 | 不适合拉取大文件 |
| FTP | 下载完整分析结果、基因组目录、蛋白库 | 无速率限制、支持断点续传 | 需要自行解析目录结构 |
| Jupyter Notebook Server | 交互式探索、教学 | 开箱即用、预装依赖 | 有会话时长与资源限制 |
| BigQuery | 蛋白库的大规模 SQL 查询 | 无需下载即可聚合 | 需 Google Cloud 账号 |
# FTP 批量下载示例：先列出目标 accession 目录，再按需下载
# 说明：FTP 路径中版本号是目录的一部分，务必保留完整路径以保留版本信息
BASE_FTP="https://ftp.ebi.ac.uk/pub/databases/metagenomics/mgnify_results"
# 1) 查看某个 run 下有哪些可用版本
curl -s "${BASE_FTP}/ERR1234567/" | head -20
# 2) 只下载分类学结果目录（避免拉取整个分析）
wget -r -np -nH --cut-dirs=6 -R "index.html*" \
"${BASE_FTP}/ERR1234567/version_5.0/taxonomy/"
# 3) 下载基因组目录中的基因组清单（先看清单再决定下不下序列）
wget -q "https://ftp.ebi.ac.uk/pub/databases/metagenomics/mgnify_genomes/human-gut/v2.0.2/genome-list.tsv"
# API 批量抓取分析结果的结构化元数据（适合构建样本级元数据表）
import pandas as pd
def fetch_analyses(biome_lineage, max_records=200):
"""按生物群落抓取分析记录，返回 DataFrame；内含分页与限速处理"""
records, url = [], f"{API_BASE}/analyses"
params = {"biome_name": biome_lineage, "page_size": 100}
while url and len(records) < max_records:
payload = api_get(url.replace(f"{API_BASE}/", ""), params=params if records == [] else None)
for item in payload["data"]:
a = item["attributes"]
records.append({
"analysis_accession": item["id"], # MGYA 编号
"pipeline_version": a.get("pipeline-version"), # 结果可比性的关键字段
"analysis_type": a.get("experiment-type"),
"biome": (a.get("biome") or {}).get("biome_name"),
"run_accession": (a.get("run") or {}).get("accession"),
})
url = (payload.get("links") or {}).get("next") # 跟随分页链接
time.sleep(0.5) # 温和限速，避免给公共服务加压
return pd.DataFrame(records)
df = fetch_analyses("root:Host-associated:Human:Digestive system", max_records=100)
print(df["pipeline_version"].value_counts()) # 先看版本分布，再决定是否可用
获取前必做的一步是检查 pipeline_version 的分布。 如果目标数据跨越 5.0 与 6.0 两个版本，直接合并会产生不可解释的差异。
§6.3 预处理全流程
MGnify 的预处理重点是"对齐"而非"清洗"——原始数据已经过标准化流水线处理，你面对的是注释表，主要工作是过滤低质量记录、统一分类层级、处理零膨胀。
# 完整预处理管线：TSV 读取 → 质量过滤 → 层级归并 → 零膨胀处理 → 特征矩阵
import numpy as np
import pandas as pd
# ---------- 步骤 1：读取分类学丰度表 ----------
# 预期文件来自 FTP 下载：.../version_5.0/taxonomy/SILVA-ssu/taxonomy.tsv
def load_taxonomy_table(path):
"""读取 MGnify 分类学 TSV；sep 用制表符，低内存模式避免大表 OOM"""
df = pd.read_csv(path, sep="\t", low_memory=False)
# 统一列名大小写，避免不同版本列名差异导致 KeyError
df.columns = [c.strip().lower().replace(" ", "_") for c in df.columns]
return df
# ---------- 步骤 2：过滤低置信度与低丰度记录 ----------
def filter_low_quality(df, abundance_col="count", min_abundance=10):
"""过滤低丰度记录：低于阈值的条目受测序噪声影响大，保留会引入虚假信号"""
before = len(df)
df = df[df[abundance_col] >= min_abundance].copy()
print(f"低丰度过滤：{before} → {len(df)} 行（移除 {before - len(df)}）")
# 剔除明确无法归类的条目；注意：unclassified 是信息性的，这里只剔除全空行
df = df.dropna(subset=["taxonomy"])
return df
# ---------- 步骤 3：分类层级归并（种 → 属）----------
def collapse_to_genus(df, lineage_col="taxonomy", abundance_col="count"):
"""把种水平谱系归并到属水平，缓解极度长尾与注释不稳定性"""
# MGnify 谱系格式形如 d__Bacteria;p__Bacillota;...;g__Bacteroides;s__...
def genus_of(lineage):
if not isinstance(lineage, str):
return "unclassified"
parts = [p for p in lineage.split(";") if p.strip().startswith("g__")]
if not parts:
return "unclassified"
return parts[-1].strip()
df = df.copy()
df["genus"] = df[lineage_col].map(genus_of)
grouped = df.groupby("genus", as_index=False)[abundance_col].sum()
return grouped.sort_values(abundance_col, ascending=False)
# ---------- 步骤 4：构建样本 × 特征矩阵（处理零膨胀）----------
def build_feature_matrix(long_df, sample_col="run_accession",
feature_col="genus", value_col="count",
min_prevalence=0.1):
"""长表转宽表；按出现频率过滤稀有特征，并做相对丰度归一化"""
wide = long_df.pivot_table(index=sample_col, columns=feature_col,
values=value_col, aggfunc="sum", fill_value=0)
# 过滤在样本中出现频率过低的特征：这些特征在交叉验证中极不稳定
prevalence = (wide > 0).mean(axis=0)
wide = wide.loc[:, prevalence >= min_prevalence]
# 相对丰度归一化：消除测序深度差异，是微生物组分析的标准做法
wide = wide.div(wide.sum(axis=1).replace(0, np.nan), axis=0).fillna(0)
return wide
# 组装流程（示意，实际运行时替换为真实路径）
# raw = load_taxonomy_table("data_root/analyses/ERR1234567/version_5.0/taxonomy/SILVA-ssu/taxonomy.tsv")
# clean = filter_low_quality(raw)
# genus_level = collapse_to_genus(clean)
# matrix = build_feature_matrix(genus_level)
预处理的三个决策点需要根据研究目标调整：最小丰度阈值（本例 10 条读数，高深度样本可提高）、归并层级（属水平较稳健，种水平信息量大但噪声也大）、最小流行率（本例 10%，用于剔除只在个别样本出现的稀有特征）。
§6.4 PyTorch DataLoader
# 完整可运行的 PyTorch 数据管线：从相对丰度矩阵到 DataLoader
# 预期输入：build_feature_matrix 产出的 DataFrame（索引=样本，列=属，值=相对丰度）
import numpy as np
import pandas as pd
import torch
from torch.utils.data import Dataset, DataLoader
from sklearn.model_selection import GroupKFold
class MicrobiomeDataset(Dataset):
"""把样本 × 属丰度矩阵包装为 PyTorch Dataset
参数：
features: ndarray，形状 (n_samples, n_genera)，已做相对丰度归一化
labels: ndarray，形状 (n_samples,)，整型分类标签
transform: 可选，对单样本特征做的增强（微生物组不建议做随机扰动，见 §6.6）
"""
def __init__(self, features, labels, transform=None):
assert features.shape[0] == len(labels), "特征与标签数量不一致"
# 转为 float32 以匹配 PyTorch 默认精度；标签转 int64
self.features = torch.as_tensor(features, dtype=torch.float32)
self.labels = torch.as_tensor(labels, dtype=torch.long)
self.transform = transform
def __len__(self):
return self.features.shape[0]
def __getitem__(self, idx):
x = self.features[idx]
if self.transform is not None:
x = self.transform(x)
return x, self.labels[idx]
def make_grouped_loaders(matrix, labels, groups, n_splits=5, batch_size=32):
"""按 study 分组做 GroupKFold 划分，避免同研究样本泄漏到不同折
groups 应为 study accession 的编码结果，长度与样本数一致。
返回第一个折的 (train_loader, val_loader)，其余折可循环获取。
"""
gkf = GroupKFold(n_splits=n_splits)
splits = list(gkf.split(matrix.values, labels, groups=groups))
train_idx, val_idx = splits[0]
X, y = matrix.values, np.asarray(labels)
train_ds = MicrobiomeDataset(X[train_idx], y[train_idx])
val_ds = MicrobiomeDataset(X[val_idx], y[val_idx])
train_loader = DataLoader(train_ds, batch_size=batch_size, shuffle=True,
num_workers=0, drop_last=False)
# 验证集不 shuffle：保证评估结果可复现
val_loader = DataLoader(val_ds, batch_size=batch_size, shuffle=False,
num_workers=0)
return train_loader, val_loader
# 使用示意（matrix 来自 §6.3 的 build_feature_matrix）
# labels = pd.factorize(meta.loc[matrix.index, "label"])[0]
# groups = meta.loc[matrix.index, "study_accession"].values
# train_loader, val_loader = make_grouped_loaders(matrix, labels, groups)
# for batch_x, batch_y in train_loader:
# print(batch_x.shape, batch_y.shape) # 预期 (B, n_genera) 与 (B,)
# break
§6.5 八个坑点
⚠️ 坑点 1：跨流水线版本合并结果导致数值不可解释（分类：预处理陷阱）
问题：把 pipeline v5.0 与 v6.0 的分类学丰度表直接拼成一张矩阵做下游分析。两个版本使用不同的参考数据库版本与不同的处理流程，同一份原始读长在版本间会得到不同的物种分配与不同的丰度值，合并后产生的差异无法归因于生物学因素。
症状：模型在同一队列内表现正常，但跨版本子集比较时出现无法解释的系统性偏移；批次效应分析显示"批次"与"流水线版本"完全共线；复现他人结果时数值对不上。
解决：
- 简单方法：在合并前先按 pipeline_version 分组统计样本量，若某一版本占比低于 10% 则直接剔除该部分数据，只用单一版本。
- 进阶方法：把版本作为一个显式的批次协变量纳入模型（如 ComBat 类方法或直接在模型中加版本哑变量），并在报告中给出"版本内"与"跨版本"两组性能，明确版本带来的性能损失幅度。
- SOTA 方法：不做数值合并，改为在特征层面只保留"存在性"二值化特征（某分类单元是否检出），大幅降低版本间数值差异的影响；或在新版本下重新分析目标数据，从源头保证口径一致。
参考：MGnify 官方文档明确说明不同流水线版本的输出格式与分析内容存在差异，v5.0 结果被保留访问以支持历史复现——https://docs.mgnify.org/ ，以及 NAR 2023 平台论文（10.1093/nar/gkac1080）。
⚠️ 坑点 2：把 biome 标签当作可靠的分组变量（分类：标签理解）
问题：biome 字段来自提交者在提交时的自行填写，MGnify 不做自动校验。同一类样本可能被填成 “root:Host-associated:Human:Digestive system” 或其任意粒度变体，也可能填成完全不同的层级。直接按字符串精确匹配过滤会同时漏掉样本与误纳样本。
症状：按 biome_name 精确过滤后得到的样本量远少于预期；同一研究的部分样本出现在结果中、部分消失；不同研究间的"同一生物群落"样本量差异巨大且不合常理。
解决：
- 简单方法：改用前缀匹配而非精确匹配，例如用 biome_name 的前两层（root:Host-associated:Human）作为过滤条件，放宽粒度。
- 进阶方法：拉取目标研究全部样本的 biome 字段后手工审计，建立映射表把各种变体归一到大类，再按归一类过滤。这一步通常只需处理几十个变体就能覆盖绝大多数样本。
- SOTA 方法：不依赖 biome 字段，改用更客观的来源特征——如宿主物种（从样本元数据获取）、研究标题关键词、或直接从分类学谱推断环境类型（如海洋样本富含 SAR11 类群），用数据驱动方式替代人工标签。
参考：MGnify 官方文档关于 biome 分类的说明与 GOLD 风格谱系约定——https://docs.mgnify.org/
⚠️ 坑点 3：把丰度表中的 0 当作真实缺失（分类：预处理陷阱）
问题：微生物组丰度矩阵中大量为 0，这些 0 混合了两种含义——该分类单元确实不存在，或测序深度不足以检出。直接把 0 参与差异分析或距离计算，会系统性地放大稀有类群的组间差异，产生大量假阳性。
症状：差异丰度分析结果中出现大量低丰度"显著"类群；用不同测序深度的样本比较时，深度低的样本富集出大量假阳性特征；组成性数据分析工具报出大量无法重复的关联。
解决：
- 简单方法：按测序深度过滤样本（剔除深度低于全体中位数一半的样本），并对特征做最小流行率过滤（如要求在一半以上样本中检出）。
- 进阶方法：改用组成性数据专用方法，如 CLR（中心化对数比）变换后再做统计检验，这类方法对零膨胀与组成性约束有专门处理；或使用零膨胀混合模型。
- SOTA 方法：使用专门为微生物组设计的差异丰度工具（如考虑零膨胀与组成性的贝叶斯方法），并在报告中同时给出效应量与置信区间；把所有结果在独立的留出研究上复现验证一遍再下结论。
参考：MGnify 官方文档关于丰度表解释的建议——https://docs.mgnify.org/
⚠️ 坑点 4：按样本随机划分导致同研究样本泄漏（分类：数据泄漏）
问题：MGnify 没有官方划分，很多使用者直接对样本做随机 train/test 划分。但一个研究项目的样本来自同一实验室、同一批次、同一测序仪，技术上高度相似。随机划分会让训练集与测试集之间存在强批次相关性，测试性能被严重高估。
症状：交叉验证 AUC 达到 0.95 以上，但换一个独立研究的数据测试时骤降至 0.6 附近；测试集与训练集的 biome 分布几乎完全重合；模型学到的实际是"这是哪个研究"而非"这是什么表型"。
解决：
- 简单方法：用 GroupKFold 并以 study accession 为分组键，保证同一研究的样本不会跨折。
- 进阶方法：在分组基础上叠加生物群落分层与时间前向划分，分别报告三种划分下的性能，差距越小说明泛化越可靠。
- SOTA 方法：设计"跨资源外部验证"——在 MGnify 数据上训练，在完全独立的公开研究数据上测试，并做批次效应可视化（如 PCoA 图中训练与测试样本是否可分）；若可分，说明模型仍在依赖技术特征。
参考：MGnify 不提供官方划分这一事实见官方文档与 NAR 2023 论文；分组划分的必要性见微生物组机器学习方法学文献。
⚠️ 坑点 5：用 HMMER 在线搜索结果替代完整蛋白库下载（分类：工程陷阱）
问题：MGnify 蛋白数据库有两个访问面——FTP 上按日期发布的完整版本，以及网站上的在线 HMMER 序列搜索。官方提示搜索结果所依据的版本可能与 FTP 上最新发布版本不同步，且在线搜索有查询长度与结果数量限制。用在线搜索做"我的蛋白家族在 MGnify 中的全部命中"这类结论会产生系统性偏差。
症状：在线搜索返回的命中数明显少于用完整库本地比对得到的数量；两次相同查询在不同时间得到不同结果；论文审稿人要求提供完整搜索证据时无法复现。
解决：
- 简单方法：任何用于定量结论的搜索，都改为下载对应日期版本的蛋白库文件到本地，用 HMMER 或 DIAMOND 本地运行，并在方法中写明所用版本目录名。
- 进阶方法：用 BigQuery 对蛋白库做 SQL 层面的预筛选（如按长度、按注释字段），缩小候选集后再本地精细比对，兼顾成本与完整性。
- SOTA 方法：把搜索流程完全版本化——记录库版本、工具版本、参数与运行日期，随论文一并发布可复现的脚本；对关键结论额外在上一版本库上重跑一遍，报告版本敏感性。
参考：MGnify 官方文档关于蛋白数据库版本与序列搜索的说明——https://docs.mgnify.org/ 与 https://ftp.ebi.ac.uk/pub/databases/metagenomics/peptide_database/
⚠️ 坑点 6：忽视基因组目录版本变化导致溯源断裂（分类：工程陷阱）
问题：MGnify Genomes 的目录会持续更新版本（如 human-gut 从早期版本演进到 v2.0.2），新版本中基因组的编号、物种聚类结果与质量过滤结果都可能变化。若论文中只写"使用 MGnify human-gut 目录"而不写版本号，后续无法复现；若混用不同版本的 MGYG 编号，会出现同一编号指向不同基因组的情况。
症状：合作者按论文描述下载目录后无法找到相同的 MGYG 编号；同一编号在两次下载中对应的序列长度不同；物种代表数量在不同时间下载的"同一目录"中不一致。
解决：
- 简单方法：在方法学部分与代码中始终使用完整路径（含版本号），并在数据可用性声明中写出下载日期。
- 进阶方法：把目录清单文件（genome-list.tsv）与其校验和一并归档到自己的数据仓库，作为分析输入的不可变快照。
- SOTA 方法：用工作流管理系统（如 Nextflow 或 Snakemake）固定数据版本与工具版本，把下载步骤也纳入可复现流程，配合容器镜像实现端到端复现。
参考：MGnify Genomes 官方浏览页与基因组目录论文（10.1016/j.jmb.2023.168016）——https://www.ebi.ac.uk/metagenomics/browse/genomes
⚠️ 坑点 7：把 MAG 的完整度估计值当作真实完整度（分类：评估误用）
问题：基因组目录中的 completeness 与 contamination 是 CheckM 基于单拷贝标记基因给出的估计值，不是基因组的真实完整度。一个显示 95% 完整度的 MAG 可能仍缺失整个代谢通路，也可能包含未被标记基因捕捉到的污染。直接用完整度数值做质量加权会引入未量化的偏差。
症状：用高完整度 MAG 构建的系统发育树出现位置异常的类群；基于高完整度 MAG 推断的代谢能力与实验验证不符；同一 MAG 在不同 CheckM 版本下质量评分差异明显。
解决：
- 简单方法：把完整度与污染度当作筛选门槛而非连续权重——只用满足 MIMAG medium 标准（完整度与污染度组合达标）的基因组，不做质量加权。
- 进阶方法：组合质量分数 QS = completeness − 5 × contamination 并按 QS 分档（如不低于 50、不低于 70、不低于 90）分别分析，观察结论是否随质量档变化。若变化显著，说明结论由低质量基因组驱动。
- SOTA 方法：对关键基因组做额外验证——检查是否存在预期中的必需基因集、核对 16S 序列与基因组分类是否一致、用多个质量评估工具交叉验证；对代谢通路结论使用通路完整性指标（如是否全部基因齐备）而非单基因存在性。
参考：MGnify Genomes 的质量控制标准见 JMB 2023 论文（10.1016/j.jmb.2023.168016）；MIMAG 标准见社区共识文献。
⚠️ 坑点 8：假设全站数据适用单一许可（分类：偏倚陷阱）
问题：MGnify 的分析结果页、基因组目录与蛋白数据库分别适用不同的许可安排。蛋白数据库随附的文件明确为 CC0 1.0 Universal，但分析结果与基因组目录并未统一声明为同一 CC 协议，其使用还涉及原始 INSDC/ENA 记录与 EMBL-EBI 通用服务条款。默认"MGnify 全部数据都是 CC0"会在商业应用或再分发时产生合规风险。
症状：论文或产品中声称"数据以 CC0 发布"但被要求提供依据时无法举证；再分发后收到权利方质询；商业产品中的数据使用被法务判定为授权不足。
解决：
- 简单方法：按数据类型分别核对——使用蛋白数据库时引用其随附 LICENCE.txt；使用分析结果或基因组目录时，查阅目标版本目录内是否随附许可证文件，并同时核对原始 INSDC 记录的条款。
- 进阶方法：在项目内建立"数据来源、许可、条款链接"的登记表，把每个用到的 MGnify 资源的许可依据留档；对不确定的部分主动联系 EMBL-EBI 支持渠道确认。
- SOTA 方法：把许可元数据纳入数据治理流程，用机器可读的许可声明（如 DUO 或 SPDX 标识）记录每个数据资产的使用条件，并在数据管线的出入口做自动化校验，避免合规信息在传递中丢失。
参考：MGnify 蛋白数据库随附许可证文件——https://ftp.ebi.ac.uk/pub/databases/metagenomics/peptide_database/ ；EMBL-EBI 通用服务条款见官网。
§6.6 数据增强
微生物组数据的增强与图像领域完全不同——样本中每个特征的物理含义明确，不能做任意的数值扰动。以下分类依据"是否保持数据的生物学可解释性"。
| 操作 | 安全性 | 说明 |
|---|---|---|
| 按测序深度重采样（rarefaction） | ✅ 安全 | 模拟不同测序深度下的群落观测，属于真实存在的技术变异 |
| 相对丰度归一化 | ✅ 安全 | 消除深度差异，标准流程 |
| 组成性数据变换（CLR / ILR） | ✅ 安全 | 保持组成性约束的数学变换 |
| 分类层级归并（种到属到科） | ✅ 安全 | 模拟不同分类分辨率的观测，可用于多尺度训练 |
| 特征丢弃（模拟未检出） | ✅ 安全 | 随机将部分低丰度特征置零，模拟检测灵敏度差异，但需谨慎控制比例 |
| 对丰度值加高斯噪声 | ⚠️ 谨慎 | 微生物组丰度不是连续测量值，噪声模型缺乏物理依据 |
| 样本间特征随机交换 | ❌ 危险 | 破坏群落内部的相关结构，产生自然界不存在的组合 |
| 人为构造稀有类群富集 | ❌ 危险 | 直接改变标签相关的信号分布，会导致乐观偏倚 |
| 跨 biome 混合样本 | ❌ 危险 | 破坏环境一致性，模型会学到无意义的组合模式 |
| 对丰度矩阵做图像式翻转裁剪 | ❌ 危险 | 微生物组特征无空间结构，此类操作无意义 |
实践建议：把"增强"理解为对技术变异的模拟而非对数据量的扩充。真正有价值的做法是对同一份数据生成多个分类分辨率或多个深度下的版本，用于评估模型对观测条件的稳健性，而不是试图凭空增加样本量。
§6.7 模型推荐
| 任务 | 推荐方法 | 理由 | 注意事项 |
|---|---|---|---|
| 样本分组分类（如疾病与对照） | 随机森林 / 梯度提升树 | 对高维稀疏长尾特征稳健，可输出特征重要性 | 必须用分组交叉验证，否则性能虚高 |
| 高维稀疏特征分类 | 带 L1/L2 正则的线性模型 | 可解释性强，适合特征数远大于样本数 | 需先做 CLR 变换处理组成性 |
| 群落结构聚类 | 基于距离的聚类（Bray-Curtis + PCoA） | 生态学标准方法，结果易解释 | 距离度量选择影响结论，需报告敏感性 |
| 功能通路预测 | 多标签分类 / 集成模型 | 通路间存在相关性 | 注意未注释比例对评估的干扰 |
| 序列层面分类注释 | 专用序列模型（基于 k-mer 或深度学习分类器） | 直接处理序列，不依赖注释表 | 需与数据库比对法做基准对照 |
| 基因组质量预测 | 回归模型（完整度与污染度估计） | 标记基因方法可互补 | 不以 CheckM 输出作为唯一真值 |
| 跨研究泛化建模 | 域适应 / 批次校正加分类器 | 显式处理研究间差异 | 校正后仍需外部验证 |
对于绝大多数微生物组表型预测任务，随机森林或梯度提升树在中小规模数据上的表现不逊于深度学习模型，且训练成本低、可解释性好。只有在样本量达到数万级、或需要直接处理序列而非注释表时，深度学习方法才体现出明显优势。
§6.8 硬件需求
| 任务 | 最低配置 | 推荐配置 | 说明 |
|---|---|---|---|
| API 批量元数据抓取 | 2 核 / 4 GB | 4 核 / 8 GB | 瓶颈在网络与限速，不在算力 |
| 单个分析结果预处理 | 2 核 / 8 GB | 4 核 / 16 GB | 单个分类学表通常数万行 |
| 千样本级丰度矩阵建模 | 4 核 / 16 GB | 8 核 / 32 GB | 随机森林类方法内存敏感度高 |
| 基因组目录本地比对参考 | 8 核 / 32 GB | 16 核 / 64 GB | 目录含数万基因组，索引体积大 |
| 蛋白库本地 HMMER 搜索 | 16 核 / 64 GB | 32 核 / 128 GB 以上 | 全库数百 GB 级，建议先用 BigQuery 预筛 |
| 宏基因组从头组装 | 16 核 / 64 GB | 32 核 / 256 GB | 组装内存需求随样本复杂度急剧上升 |
存储规划：单个分析结果从数 MB 到数 GB；一个完整基因组目录从数十 GB 到数百 GB；蛋白数据库全量为数百 GB 级。建议预留至少 2 TB 可用空间用于中等规模研究。
§6.9 评估指标
# 微生物组建模的评估指标：分类性能 + 生态学相似度
import numpy as np
from sklearn.metrics import (roc_auc_score, f1_score, balanced_accuracy_score,
average_precision_score)
def classification_metrics(y_true, y_prob, threshold=0.5):
"""分类任务评估：类别不平衡时 AUC 与 AP 比准确率更可靠"""
y_pred = (np.asarray(y_prob) >= threshold).astype(int)
return {
"auc": roc_auc_score(y_true, y_prob), # 阈值无关的排序能力
"average_precision": average_precision_score(y_true, y_prob), # 正类稀有时的关键指标
"f1": f1_score(y_true, y_pred), # 需与类别分布一同解读
"balanced_accuracy": balanced_accuracy_score(y_true, y_pred), # 对不平衡更稳健
}
def bray_curtis(u, v):
"""Bray-Curtis 相异度：生态学中最常用的群落差异度量
取值范围 0（完全相同）到 1（完全不同）；对丰度差异敏感"""
u, v = np.asarray(u, dtype=float), np.asarray(v, dtype=float)
denom = u.sum() + v.sum()
if denom == 0:
return 0.0
return float(np.abs(u - v).sum() / denom)
def jaccard_presence(u, v):
"""基于存在性的 Jaccard 相似度：只比较有没有，忽略有多少
对测序深度差异不敏感，适合跨深度比较"""
u, v = np.asarray(u) > 0, np.asarray(v) > 0
union = (u | v).sum()
return float((u & v).sum() / union) if union else 0.0
def shannon_diversity(counts):
"""Shannon 多样性：群落 alpha 多样性的标准度量，单位通常记为 nats"""
p = np.asarray(counts, dtype=float)
p = p[p > 0]
p = p / p.sum()
return float(-(p * np.log(p)).sum())
评估微生物组模型时，必须同时报告分类性能指标与生态学相似度指标。只看 AUC 会掩盖模型是否真正学到了群落结构；只看 Bray-Curtis 又会失去与临床终点挂钩的能力。两套指标并报，是这一领域的标准做法。
§6.10 MLOps 与工程笔记
MGnify 数据在工程上有三个特殊之处需要在 MLOps 设计中考虑。第一是版本耦合：模型性能与所使用的流水线版本、目录版本强相关，应在模型元数据中记录这些版本号，并作为模型卡的必要字段。第二是元数据不一致：biome 等字段的填写粒度不一，建议在数据入口处建立标准化的映射层，把外部元数据归一到内部约定，避免下游代码重复处理。第三是公共服务使用礼仪：MGnify 是免费公共资源，批量请求应设置合理间隔（示例代码中为 0.5 秒），大规模抓取优先使用 FTP 而非 API，并考虑把结果缓存在本地以避免重复请求。缓存策略上，API 响应建议按 URL 哈希缓存并记录抓取日期；FTP 下载文件建议保存校验和；所有缓存都应标注对应的数据版本与抓取时间，避免"缓存了旧版本却以为是新版"的问题。
§7 质量评估与局限性
§7.1 已知偏倚
| 偏倚类型 | 描述 | 严重程度 | 缓解方法 |
|---|---|---|---|
| 地理偏倚 | 数据集中于欧洲、北美与东亚，反映全球研究投入分布而非自然分布 | 高 | 在模型报告中对地理来源分层评估；避免声称全球泛化 |
| 生物群落不平衡 | 人类肠道相关样本占比明显偏高，其他群落数据量少 | 高 | 按群落分层采样；跨群落任务需显式做域适应 |
| 研究热点偏倚 | 被研究得多的环境（如肠道、海洋）数据丰富，冷门环境稀缺 | 中高 | 明确研究结论的适用范围；冷门环境结论标注样本量 |
| 技术批次偏倚 | 不同实验室的测序平台、建库方法、引物选择不同 | 高 | 按 study 分组划分；显式建模批次效应 |
| 参考数据库偏倚 | 分类注释依赖 SILVA、UNITE、GTDB 等库的收录偏向 | 中 | 记录数据库版本；对注释不确定的分类单元谨慎解读 |
| 培养偏倚残留 | 基因组目录虽优先纳入 MAG，但仍有部分来自分离株 | 中 | 在分析中区分 isolate 与 MAG 来源 |
| 提交质量偏倚 | biome 等元数据由提交者填写，质量参差 | 中 | 建立元数据归一映射；对关键字段做人工审计 |
| 深度偏倚 | 不同样本测序深度差异大，影响稀有类群检出 | 中高 | 深度过滤加相对丰度归一化加存在性特征 |
| 版本碎片化 | 结果分散在多个流水线版本，跨版本合并产生额外差异 | 中高 | 固定单一版本分析；做版本敏感性测试 |
§7.2 注释质量评估
MGnify 的注释质量受制于三个环节的固有不确定性。其一是参考数据库的覆盖度——环境样本中相当大比例的序列无法匹配到已知类群，会被标注为 unclassified，这部分比例本身就是重要的质量指标。其二是分类分辨率的限制——16S 扩增子通常只能可靠到属水平，种水平注释需要额外证据。其三是功能注释的误差传递——从基因预测到结构域注释再到通路推断，每一级都可能引入误差，且通路层面的推断错误率高于单基因层面。
实践中建议关注三个质量信号：unclassified 比例（过高说明参考库不匹配或样本含大量新类群）、功能注释覆盖率（过低说明预测基因质量或数据库覆盖有问题）、以及可重复性（同一生物群落在不同研究中的作用注释谱是否一致）。
§7.3 泛化性风险
| 场景 | 失效风险 | 证据 |
|---|---|---|
| 跨地理区域迁移 | 高：不同区域人群的菌群基线差异显著 | 微生物组研究中跨队列复现率普遍偏低是领域共识 |
| 跨生物群落迁移 | 极高：肠道模型用于土壤或海洋样本基本无效 | 群落组成与生态过程差异过大 |
| 跨测序平台迁移 | 中高：平台差异影响物种检出与丰度估计 | 不同平台读长与错误模式的差异是已知问题 |
| 跨流水线版本迁移 | 中高：版本间数值差异可观 | 官方明确提示不同版本输出存在差异 |
| 跨时间迁移 | 中：测序技术与参考库持续演进 | 版本时间轴显示数据库与流水线多次更新 |
| 临床场景直接部署 | 极高：MGnify 非临床级资源 | 平台本身不提供临床验证或诊断输出 |
§7.4 伦理与合规
使用 MGnify 数据需关注三类伦理问题。第一是人类样本的隐私边界：平台不存储原始人类读长，但人类相关宏基因组可能存在宿主序列残留，过度的再识别尝试（如从菌群谱推断个体身份）会触及隐私红线，此类研究需伦理审查。第二是地理与主权问题：海洋与土壤样本可能位于特定国家管辖范围，平台的 EEZ 标识可辅助判断，涉及生物遗传资源的研究需遵守《生物多样性公约》与名古屋议定书关于惠益分享的要求。第三是利益归属：数据来自全球研究者免费提交，商业性使用时应考虑回馈社区。
§7.5 公平性考量
微生物组研究的公平性问题主要体现在人群代表性上。现有数据以欧洲、北美与东亚人群为主，非洲、南美与南亚部分区域的数据明显偏少，这使得基于 MGnify 训练的菌群相关模型在这些人群上的适用性未经检验。若研究目标涉及临床应用，必须明确说明训练数据的人群构成，并在目标人群上做专门验证。此外，不同地区的饮食习惯、抗生素使用模式、卫生条件都会显著影响菌群组成，这些因素与地理区域高度混杂，模型学到的"区域特征"可能实际反映的是生活方式差异。
§7.6 数据漂移
MGnify 是持续增量更新的资源，这带来双向影响。积极的一面是数据规模不断增长、参考数据库持续改进；消极的一面是任何固定时间点构建的模型都面临数据漂移。漂移来源有四种：新样本加入改变了群落分布（特别是新研究热点出现时）；参考数据库升级改变了分类注释；流水线版本升级改变了处理方式；测序技术进步改变了数据特征。应对策略是记录模型训练时的数据快照信息（抓取日期、版本分布），并定期在新数据上重评估性能，把"性能随时间的变化"作为持续监控指标而非一次性结论。
§7.7 DAIMS 24 项评估
| # | 检查项 | 状态 | 说明 |
|---|---|---|---|
| 1 | 宽格式 | ✅ | API 与 FTP 均提供宽格式样本 × 特征矩阵，可直接用于建模 |
| 2 | 唯一标识 | ✅ | MGYA / MGYG / MGYS / MGYP 四类 accession 体系清晰，INSDC accession 可回溯原始数据 |
| 3 | 特殊字符 | ✅ | 分类谱系使用分号分隔的标准前缀格式，TSV 结构无歧义 |
| 4 | 重复行 | ⚠️ | 同一 run 可能在不同 pipeline 版本下产生多条分析记录，需按版本去重 |
| 5 | 缺失编码 | ⚠️ | 丰度表用 0 同时表示不存在与未检出，无独立缺失编码 |
| 6 | 标签标识 | ⚠️ | 无独立标签列；表型标签需外部链接，MGnify 不提供 |
| 7 | 罕见类群分组 | ⚠️ | 长尾分布显著，官方未提供稀有类群合并后的分组，需自行归并 |
| 8 | 偏倚评估 | ✅ | 官方论文与文档对地理、群落与技术偏倚有明确说明 |
| 9 | 数据字典 | ⚠️ | API 文档完整，但无统一发布的字段字典文件，需自行整理 |
| 10 | 信息性缺失解释 | ⚠️ | unclassified 与未注释为信息性缺失，但官方未统一编码，需自行区分 |
| 11 | 设备记录 | ✅ | 测序平台与实验类型可在 ENA 元数据中查到 |
| 12 | 共线性 | ⚠️ | 分类单元丰度存在组成性约束（总和固定），天然共线，需专门变换 |
| 13 | 编码映射 | ✅ | 分类采用标准谱系前缀，功能采用 InterPro/GO/KEGG 标准编码 |
| 14 | 时间戳处理 | ⚠️ | 提交时间可从 ENA 获取，但分析时间与版本时间未统一暴露为字段 |
| 15 | 划分建议 | ❌ | 官方未提供任何划分建议，需完全自行设计 |
| 16 | 泄漏讨论 | ⚠️ | 官方文档未专门讨论划分泄漏，同研究样本泄漏风险需使用者自行识别 |
| 17 | 标签分布 | ⚠️ | 分类学标签分布极度长尾，官方未提供分布统计，需自行计算 |
| 18 | 测量偏倚 | ✅ | 测序深度、平台、引物等测量层面的影响因素在文档中有说明 |
| 19 | 外部验证建议 | ⚠️ | 官方未提供外部验证指南，但跨研究聚合特性支持外部验证设计 |
| 20 | 版本记录 | ✅ | FTP 路径与 API 字段均包含 pipeline 版本；目录按版本号发布 |
| 21 | 预处理脚本 | ⚠️ | 官方提供流水线代码（GitHub），但无面向下游 AI 建模的预处理脚本 |
| 22 | 合规要求 | ⚠️ | 蛋白库明确为 CC0，但全站分析结果无统一许可声明，需逐项核对 |
| 23 | 多模态对齐 | ⚠️ | 可对齐分类学与功能谱，但与表型数据的对齐需外部完成 |
| 24 | 去标识化 | ✅ | 不存储直接标识符；人类相关样本的宿主序列由提交者负责去除 |
DAIMS 评分：14 / 24
评分解读：MGnify 在标识体系、版本记录、编码标准与偏倚披露上表现优秀（第 1、2、3、8、11、13、18、20、24 项），这符合一个成熟生物信息学基础设施的定位——它把"数据可追溯、可复现"做到了高标准。扣分集中在面向机器学习使用的就绪度上：没有官方划分（第 15 项）、没有面向 AI 的预处理脚本（第 21 项）、没有统一的全站许可（第 22 项）、以及若干与微生物组数据本质相关的结构性缺口（零膨胀缺失编码、组成性共线、长尾标签分布）。需要指出的是，这些缺口中的第 5、7、12、17 项并非 MGnify 的疏漏，而是微生物组数据类型本身的固有特征——任何微生物组资源都面临同样的问题。真正属于"可以做得更好但没有做"的是第 15 与第 21 项。
对你意味着什么：把这份评分翻译成行动清单——第一，你必须自己设计数据划分，并且必须用 study accession 分组，这一点没有任何官方兜底，做错了不会有人提醒你（对应第 15、16 项）。第二，你必须自己处理零膨胀与组成性，丰度表中的 0 不能直接当数值用，需要相对丰度归一化、CLR 变换或存在性二值化（对应第 5、12 项）。第三，你必须自己在项目内维护字段字典与元数据归一映射，尤其是 biome 字段（对应第 6、9、10 项）。第四，你必须自己写预处理脚本并版本化，官方只提供上游分析流水线，从 MGYA 结果到训练矩阵之间的这段路是空白（对应第 21 项）。第五，许可需要逐项核对，不要假设全站统一（对应第 22 项）。把这五件事做扎实，MGnify 就是一个非常好用的数据源；跳过其中任何一件，都会在后期以难以排查的问题形式还回来。
§7.8 外部验证参考
| 外部场景 | 来源机构 | 评估任务 | 性能指标 | 相对内部变化 | 关键发现 |
|---|---|---|---|---|---|
| 跨生物群落基因组目录应用 | EMBL-EBI（MGnify Genomes） | 用群落特异目录做读长比对参考 | 检出率与注释率 | 相对通用参考库提升 | 群落特异目录对低丰度与近缘种的区分能力优于通用库 |
| 未培养类群参考基因组获取 | EMBL-EBI（MGnify Genomes） | 为无培养代表的类群提供参考基因组 | 获得首个参考基因组的类群数 | 不可比 | 2023 年论文报告 36 个此前未培养类群获得参考基因组 |
| 标准化流水线跨研究一致性 | EMBL-EBI | 同口径处理不同来源样本的可比性 | 注释一致性与可比性 | 相对各研究自建流程显著提升 | 统一流水线是跨研究元分析可行性的基础 |
| 蛋白库大规模功能搜索 | EMBL-EBI 与 Google Cloud | 环境蛋白序列的功能家族挖掘 | 搜索覆盖度与成本 | 相对本地全库搜索成本大幅下降 | BigQuery 托管使数亿序列级查询成为常规操作 |
| 平台使用活跃度 | EMBL-EBI 2024-25 报告 | 服务使用量统计 | 访问与用户数 | 同比增加 21%（访问量） | 平台被广泛用于研究与教学，社区活跃 |
需要说明：MGnify 社区尚未形成统一的模型排行榜，因此本表记录的是资源级外部验证场景而非模型级性能对比。任何数值都不可与不同版本、不同参考库或不同评估协议的结果直接比较。
§8 生态与工具链
§8.1 相关工具与资源
| 工具/资源 | 类型 | 用途 | 获取方式 |
|---|---|---|---|
| MGnify REST API | Web API | 程序化查询分析结果与元数据 | https://www.ebi.ac.uk/metagenomics/api/v1/ |
| MGnify FTP | 文件服务 | 下载分析结果、基因组目录与蛋白库 | https://ftp.ebi.ac.uk/pub/databases/metagenomics/ |
| MGnify Jupyter Notebook Server | 交互环境 | 在线探索数据与教学 | https://notebooks.mgnify.org/ |
| MGnifyR | R 包 | R 语言访问 MGnify API | CRAN 与 GitHub |
| mgnipy | Python SDK | Python 语言访问 MGnify API | PyPI |
| pipeline-v5（CWL） | 分析流水线 | 复现 v5.0 分析结果 | GitHub: EBI-Metagenomics/pipeline-v5 |
| v6.0 系列流水线（Nextflow） | 分析流水线 | 使用最新分析能力 | GitHub: EBI-Metagenomics |
| VIRify | 病毒注释模块 | 从宏基因组中识别病毒与移动元件 | GitHub: EBI-Metagenomics/VIRify |
| mettannotator | 注释模块 | MAG 的功能注释 | GitHub: EBI-Metagenomics |
| EukCC | 真核基因组质量评估 | 真核 MAG 质量估计 | GitHub: EBI-Metagenomics |
§8.2 关键论文
- Richardson L, Allen B, Baldi G, et al. (2023). MGnify: the microbiome sequence data analysis resource in 2023. Nucleic Acids Research 51(D1):D753-D759. DOI: 10.1093/nar/gkac1080 — MGnify 平台的核心引用文献，记录"近 50 万次分析"的规模口径与平台架构。
- Gurbich TA, Almeida A, Beracochea M, et al. (2023). MGnify Genomes: A Resource for Biome-specific Microbial Genome Catalogues. Journal of Molecular Biology 435(14):168016. DOI: 10.1016/j.jmb.2023.168016 — 基因组目录的核心引用文献，记录 7 个目录、301,808 个基因组、11,048 个物种代表与质量控制标准。
- Mitchell AL, Almeida A, Beracochea M, et al. (2020). MGnify: the microbiome analysis resource in 2020. Nucleic Acids Research 48(D1):D570-D578. DOI: 10.1093/nar/gkz1035 — 平台中期版本的引用文献，含早期架构与分析规模。
- EMBL-EBI 年度报告（2024-25）。Nucleic Acids Research 53(D1):D10. DOI: 10.1093/nar/gkae1089 — 记录 MGnify 的使用量统计（2025 年约 60,000 次访问、约 94,000 次搜索、约 15,000 注册用户）与 ELIXIR Core Data Resource 认定。
- Almeida A, Nayfach S, Boland M, et al. (2021). A unified catalog of 204,938 reference genomes from the human gut microbiome. Nature Biotechnology 39:105-114. DOI: 10.1038/s41587-020-0603-3 — 人类肠道基因组目录的方法学基础，MGnify Genomes 人类肠道目录的学术前身。
- Sunagawa S, Coelho LP, Chaffron S, et al. (2015). Ocean plankton: Structure and function of the global ocean microbiome. Science 348:1261359. DOI: 10.1126/science.1261359 — 海洋微生物组大规模取样的代表性工作，其数据是海洋目录的重要来源。
- Thompson LR, Sanders JG, McDonald D, et al. (2017). A communal catalogue reveals Earth’s multiscale microbial diversity. Nature 551:457-463. DOI: 10.1038/nature24621 — Earth Microbiome Project，全球微生物组取样的标志性工作。
- Parks DH, Chuvochina M, Waite DW, et al. (2018). A standardized bacterial taxonomy based on genome phylogeny. Nature Biotechnology 36:996-1004. DOI: 10.1038/nbt.4229 — GTDB 基因组分类体系的原始文献，MGnify 基因组分类的基础。
- Parks DH, Imelfort M, Skennerton CT, et al. (2015). CheckM: assessing the quality of microbial genomes recovered from isolates, single cells, and metagenomes. Genome Research 25:1043-1055. DOI: 10.1101/gr.186072.114 — CheckM 的原始文献，MGnify 基因组质量评估的核心工具。
- Bowers RM, Kyrpides NC, Stepanauskas R, et al. (2017). Minimum information about a single amplified genome (MISAG) and a metagenome-assembled genome (MIMAG) of bacteria and archaea. Nature Biotechnology 35:725-731. DOI: 10.1038/nbt.3893 — MIMAG 质量标准原始文献，MGnify 基因组入目录的阈值依据。
§8.3 评测与使用的协议建议
尽管 MGnify 没有官方基准，仍建议在论文中遵循以下协议以保证结果可比。第一，明确记录数据获取日期、使用的 pipeline 版本与参考数据库版本。第二，明确说明划分方式并给出分组键（如 study accession），报告至少 3 次不同随机种子的结果。第三，同时报告分类性能指标与生态学相似度指标。第四，至少包含一个外部验证结果，并说明外部数据与训练数据在版本与来源上的关系。第五，报告类别分布与样本量，避免在不平衡数据上仅报告准确率。第六，公开预处理脚本与随机种子，确保结果可复现。
§8.4 社区活跃度
MGnify 的社区活跃度可从几个侧面观察：流水线仓库持续更新，v6.0 系列已拆分为多个独立项目并有活跃的问题跟踪；官方提供 Jupyter Notebook Server 与 Python、R 双语言 SDK，降低使用门槛；EMBL-EBI 在年度报告中跟踪平台使用量，2025 年官网访问量同比增长 21%；平台被认定为 ELIXIR Core Data Resource。这些信号说明它是一个有稳定维护的资源，适合作为长期研究项目的数据基础。
§8.5 生态快照
| 资源 | 类型 | 链接 | 状态（截至 2026-09） | 推荐理由 |
|---|---|---|---|---|
| MGnify 主站 | 门户 | https://www.ebi.ac.uk/metagenomics/ | 持续更新 | 分析结果浏览与检索的入口 |
| MGnify REST API | API | https://www.ebi.ac.uk/metagenomics/api/v1/ | 稳定服务 | 程序化批量获取元数据的首选 |
| MGnify FTP | 文件服务 | https://ftp.ebi.ac.uk/pub/databases/metagenomics/ | 持续更新 | 大文件下载的唯一途径 |
| MGnify 官方文档 | 文档 | https://docs.mgnify.org/ | 持续维护 | 流水线与数据结构的第一手说明 |
| 基因组目录浏览页 | 门户 | https://www.ebi.ac.uk/metagenomics/browse/genomes | 约 21 个目录（2026-09） | 选择基因组参考的入口 |
| pipeline-v5（GitHub） | 代码 | https://github.com/EBI-Metagenomics/pipeline-v5 | 维护中（历史版本） | 复现 v5.0 分析结果的唯一来源 |
| v6.0 流水线系列 | 代码 | https://github.com/EBI-Metagenomics | 活跃开发 | 使用最新分析能力 |
| Jupyter Notebook Server | 交互环境 | https://notebooks.mgnify.org/ | 可用 | 零配置上手与教学 |
§9 相关资源与引用
§9.1 官方资源
| 资源 | 地址 | 说明 |
|---|---|---|
| 官方主页 | https://www.ebi.ac.uk/metagenomics/ | 平台入口，含最新研究列表与公告 |
| 官方文档 | https://docs.mgnify.org/ | 流水线说明、数据结构、API 使用指南 |
| REST API 根节点 | https://www.ebi.ac.uk/metagenomics/api/v1/ | 可浏览的 API 界面 |
| 分析结果 FTP | https://ftp.ebi.ac.uk/pub/databases/metagenomics/mgnify_results/ | 按 accession 与版本组织的分析结果 |
| 基因组目录 FTP | https://ftp.ebi.ac.uk/pub/databases/metagenomics/mgnify_genomes/ | 按生物群落与版本组织的基因组目录 |
| 蛋白数据库 FTP | https://ftp.ebi.ac.uk/pub/databases/metagenomics/peptide_database/ | 按日期版本化的蛋白序列集合 |
| 基因组浏览页 | https://www.ebi.ac.uk/metagenomics/browse/genomes | 目录与物种清单的可视化检索 |
| Jupyter 服务 | https://notebooks.mgnify.org/ | 在线交互分析环境 |
| 流水线代码 | https://github.com/EBI-Metagenomics | v5.0（CWL）与 v6.0（Nextflow）系列 |
§9.2 引用指南
引用 MGnify 时应遵循分场景原则。引用平台整体时使用 NAR 2023 论文（10.1093/nar/gkac1080）。引用基因组目录时同时引用 JMB 2023 论文（10.1016/j.jmb.2023.168016）与所使用的具体目录版本。引用具体分析结果时提供 MGYA accession。引用原始数据时引用对应的 INSDC/ENA accession。仅引用论文而不提供 accession 与版本号，会使结果无法被复现，这是审稿中最常被指出的问题。
§9.3 BibTeX 引用块
@article{richardson2023mgnify,
title = {MGnify: the microbiome sequence data analysis resource in 2023},
author = {Richardson, Lorna and Allen, Ben and Baldi, Germana and
Beracochea, Martin and Bileschi, Maxwell L and Burdett, Tony and
Burgin, Josephine and Caballero-Perez, Juan and Cochrane, Guy and
Colwell, Lucy J and others},
journal = {Nucleic Acids Research},
volume = {51},
number = {D1},
pages = {D753--D759},
year = {2023},
doi = {10.1093/nar/gkac1080}
}
@article{gurbich2023mgnifygenomes,
title = {MGnify Genomes: A Resource for Biome-specific Microbial Genome Catalogues},
author = {Gurbich, Tatiana A and Almeida, Alexandre and Beracochea, Martin and
Burdett, Tony and Burgin, Josephine and Cochrane, Guy and
Finn, Robert D and Richardson, Lorna J},
journal = {Journal of Molecular Biology},
volume = {435},
number = {14},
pages = {168016},
year = {2023},
doi = {10.1016/j.jmb.2023.168016}
}
@article{mitchell2020mgnify,
title = {MGnify: the microbiome analysis resource in 2020},
author = {Mitchell, Alex L and Almeida, Alexandre and Beracochea, Martin and
Boland, Miguel and Burgin, Josephine and Cochrane, Guy and
Cruz, Michael and others},
journal = {Nucleic Acids Research},
volume = {48},
number = {D1},
pages = {D570--D578},
year = {2020},
doi = {10.1093/nar/gkz1035}
}
@article{emblEbi2024resources,
title = {EMBL-EBI data resources in 2025},
author = {{EMBL-EBI}},
journal = {Nucleic Acids Research},
volume = {53},
number = {D1},
pages = {D10},
year = {2024},
doi = {10.1093/nar/gkae1089}
}
@article{parks2015checkm,
title = {CheckM: assessing the quality of microbial genomes recovered from
isolates, single cells, and metagenomes},
author = {Parks, Donovan H and Imelfort, Michael and Skennerton, Connor T and
Hugenholtz, Philip and Tyson, Gene W},
journal = {Genome Research},
volume = {25},
number = {7},
pages = {1043--1055},
year = {2015},
doi = {10.1101/gr.186072.114}
}
§10 AI 使用声明卡
§10.1 AI 模型列表
| 环节 | AI 模型 | 用途 |
|---|---|---|
| 资料检索与整理 | 通用大语言模型（联网检索） | 检索 MGnify 官方文档、NAR 与 JMB 论文、FTP 与 API 说明 |
| 初稿撰写 | 通用大语言模型 | 依据检索材料生成章节初稿 |
| 代码示例生成 | 通用大语言模型 | 生成 API 访问、预处理、DataLoader 与评估指标代码 |
| 格式规范校验 | 通用大语言模型配合脚本 | 执行 G1/G2/G3 排版规范与结构完整性检查 |
§10.2 AI 参与范围
AI 在本页面的工作中负责：(1) 从官方文档、NAR 2023 与 JMB 2023 论文、EMBL-EBI 年度报告及 FTP 说明中整理结构化信息；(2) 生成 §6 代码示例；(3) 组织 §6.5 八个坑点与 §7.1 偏倚表；(4) 执行 G1/G2/G3 排版规范与全角标点标准化检查；(5) 构建 §C 统一 JSON-LD @graph。所有规模数字、版本号与引用信息均来自可核查的公开来源。
§10.3 输入来源列表
- MGnify 官方主页 — https://www.ebi.ac.uk/metagenomics/
- MGnify 官方文档（关于页面与流水线说明）— https://docs.mgnify.org/
- Richardson L, Allen B, Baldi G, et al. (2023). MGnify: the microbiome sequence data analysis resource in 2023. Nucleic Acids Research 51(D1):D753-D759. DOI: 10.1093/nar/gkac1080
- Gurbich TA, Almeida A, Beracochea M, et al. (2023). MGnify Genomes: A Resource for Biome-specific Microbial Genome Catalogues. Journal of Molecular Biology 435(14):168016. DOI: 10.1016/j.jmb.2023.168016
- Mitchell AL, Almeida A, Beracochea M, et al. (2020). MGnify: the microbiome analysis resource in 2020. Nucleic Acids Research 48(D1):D570-D578. DOI: 10.1093/nar/gkz1035
- EMBL-EBI 年度报告（2024-25）— Nucleic Acids Research 53(D1):D10. DOI: 10.1093/nar/gkae1089
- MGnify REST API 根节点与文档 — https://www.ebi.ac.uk/metagenomics/api/v1/
- MGnify FTP 站点（mgnify_results、mgnify_genomes、peptide_database 三个子目录）— https://ftp.ebi.ac.uk/pub/databases/metagenomics/
- MGnify 基因组目录浏览页 — https://www.ebi.ac.uk/metagenomics/browse/genomes
- MGnify 流水线代码仓库（pipeline-v5 与 v6.0 系列）— https://github.com/EBI-Metagenomics
- Parks DH, Imelfort M, Skennerton CT, et al. (2015). CheckM. Genome Research 25:1043-1055. DOI: 10.1101/gr.186072.114
- Bowers RM, Kyrpides NC, Stepanauskas R, et al. (2017). MIMAG 标准. Nature Biotechnology 35:725-731. DOI: 10.1038/nbt.3893
- Parks DH, Chuvochina M, Waite DW, et al. (2018). GTDB 分类体系. Nature Biotechnology 36:996-1004. DOI: 10.1038/nbt.4229
- Almeida A, Nayfach S, Boland M, et al. (2021). A unified catalog of 204,938 reference genomes from the human gut microbiome. Nature Biotechnology 39:105-114. DOI: 10.1038/s41587-020-0603-3
- Thompson LR, Sanders JG, McDonald D, et al. (2017). Earth Microbiome Project. Nature 551:457-463. DOI: 10.1038/nature24621
- Google Scholar 引用快照（截至 2026-09，用于 NAR 2023 论文引用计数）
§10.4 人工校验表
| 内容模块 | 审核者 | 审核方式 | 审核状态 |
|---|---|---|---|
| §2 医学背景（ICD-11 映射、生物群落分类、金标准体系） | 千方病案医学编辑部 | 交叉审核 | ✅ 已通过 |
| §3 数据集规格（版本矩阵、规模口径、工具链版本） | 千方病案医学编辑部 | 与 NAR 2023、JMB 2023 论文及官方文档交叉比对 | ✅ 已验证 |
| §4 数据结构（accession 体系、DAIMS 字段字典、目录树） | 千方病案医学编辑部 | 与官方 API 文档及 FTP 目录说明交叉比对 | ✅ 已验证 |
| §5 数据划分策略与泄漏风险分析 | 千方病案医学编辑部 | 交叉审核 | ✅ 已通过 |
| §6 代码示例与八个坑点 | 千方病案医学编辑部 | 逻辑审查与官方文档比对 | ✅ 已通过 |
| §7 质量评估与 DAIMS 评分 | 千方病案医学编辑部 | 交叉审核 | ✅ 已通过 |
| §8 生态工具与关键论文引用 | 千方病案医学编辑部 | 与原文 DOI 及官方仓库交叉比对 | ✅ 已验证 |
| §C JSON-LD @graph | 千方病案医学编辑部 | Schema 字段逐项校验 | ✅ 已通过 |
§10.5 AI 生成章节标注
以下章节由 AI 生成初稿并经人工审核：§1.0 30 秒速览、§2.2 微生物组研究的技术背景、§3.0 版本抉择矩阵、§6.0 至 §6.4 代码示例、§6.5 八个坑点、§6.9 评估指标代码、§7.7 DAIMS 评估表与评分、§8.5 生态快照、§C JSON-LD。
§10.6 最后审核
最后一次人工审核日期：2026-09-05
页面状态：published（全部内容已完成审核并发布）
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- hmp — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- curatedmetagenomicdata — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- american-gut-project — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- gnomad — 共享标签：基因组学与多组学 / 测序数据
- uniprot — 共享标签：基因组学与多组学 / 测序数据
- 1000-genomes — 共享标签：基因组学与多组学 / 测序数据
- encode — 共享标签：基因组学与多组学 / 测序数据
- geo — 共享标签：基因组学与多组学 / 测序数据
- dbsnp — 共享标签：基因组学与多组学 / 测序数据
- ega — 共享标签：基因组学与多组学 / 测序数据
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
