信息速览
Greengenes2 是一套微生物参考数据库，它的主产品不是序列集合，而是一棵把基因组与 16S 片段挂在同一个拓扑上的系统发育树。树上既有完整基因组，也有全长 16S，还有大量只有几十个碱基的 V4 片段；三者共享同一套枝长与同一个根，因此用同一份样本跑出来的扩增子数据和鸟枪数据，可以落在同一个坐标系里比较。这件事在它之前没有现成的公共资源做到过。
它由加州大学圣地亚哥分校的 Rob Knight 实验室与 biocore 团队维护，Daniel McDonald 主持，2022 年 10 月发布第一版，2024 年 9 月更新到现行版。命名体系来自 GTDB，与 2013 年停更的旧版 Greengenes 没有继承关系：旧版的 OTU 编号与新版的物种名之间不存在映射表，混用会直接断链。许可是 BSD-3，学术与商业同一待遇。
下面按「它要解决什么麻烦、数据长什么样、树与分类怎么来的、怎么接进流程」四段展开，规模数字以 2024.09 版发布目录与论文为准，两处口径不同时会单独标注。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 全称 | Greengenes2（第二代 Greengenes 参考数据库） |
| 维护机构 | UCSD 医学院 Knight 实验室与 biocore 团队 |
| 首发 / 现行版 | 2022 年 10 月 28 日 / 2024.09（2024 年 9 月 26 日） |
| 骨架 | Web of Life 基因组树，15,953 个细菌与古菌基因组 |
| 建树方法 | uDance 插全长 16S，DEPP 放 V4 片段，tax2tree 装饰分类 |
| 序列规模 | 23,467,470 条（含基因组、全长 16S 与 V4 片段） |
| 骨架分类记录 | 337,506 行 |
| 分类层级 | 七级，域至种，命名取自 GTDB |
| 分类类元数 | 2 域 / 132 门 / 333 纲 / 957 目 / 2,107 科 / 8,114 属 / 22,901 种 |
| 文件数 | 25 个数据文件，另附 README、CHANGELOG、LICENSE |
| 格式 | Newick、QIIME 2 QZA、TSV、朴素贝叶斯分类器 |
| 许可 | BSD-3-Clause |
| 官方入口 | http://greengenes2.ucsd.edu/ |
§1 它要解决的具体麻烦
1.1 两条测序路线，两套参照，结论对不上
同一个粪便样本，一份做 16S V4 扩增子，一份做鸟枪宏基因组，两个实验室各跑一遍，属水平的相对丰度经常对不上，有的属差出两三倍。这类差异里有一部分确实是方法学的：引物偏好、拷贝数、DNA 提取效率都会造成偏差。但还有一部分跟生物学和方法学都无关，只跟参照系有关——16S 路线用 16S 参考库分类，鸟枪路线用基因组目录分类，两套库对「什么算一个属」「这个属叫什么」的定义本来就不一样。
更麻烦的是树。UniFrac 这类距离要在树上算，16S 的表在 16S 树上算，鸟枪的表在基因组树上算，两张距离矩阵放在一起做 PCoA，坐标轴的含义都不完全一致。要让两条路线可比，最直接的办法是把它们塞进同一棵树。这正是 Greengenes2 的全部立意。
1.2 它的做法：一棵树，两种叶子
具体做法是把基因组树当骨架。先用 Web of Life 目录里的完整基因组建一棵树，基因组之间的关系就此固定；再把大量全长 16S 序列插到骨架上，让 16S 也有位置；最后把 Qiita 汇集的 V4 片段一条条放到树上。放完之后，一棵树上同时存在三类末端：基因组、全长 16S、V4 片段。
因为共享拓扑，同一批样本的两条路线第一次可以落在同一个坐标系里。论文给出的对照是：用同一棵树算 UniFrac 时，16S 与鸟枪数据的 PCoA 相关系数达到 0.86；换成两边各用各的树，这个数掉到 0.77；改用 Bray-Curtis 不建树，只有 0.57。也就是说，树统一之后，两条路线的一致性接近「换一种距离度量」所能达到的上限。
1.3 三条常见的错误期待
第一条是把它当成旧版 Greengenes 的升级包。它不是。旧版以 97% 相似度聚类的 OTU 为单位，编号形如 OTU1234，分类路径以 k__Bacteria; p__Firmicutes 开头；新版以序列或哈希为末端标识，分类路径是 d__Bacteria; p__Bacillota_A_368345 这种带数字后缀的 GTDB 名字。两套体系之间没有对照表，任何「把旧 OTU 映射到新物种」的脚本都得自己造。
第二条是把它当成一个分类器。分类器只是随包发的副产品，两个朴素贝叶斯模型加起来不到全部分发体积的一小部分。真正的主产品是树与沿树读出的分类表；分类器能覆盖的只是骨架层原位切出的 V4 片段，覆盖面比整棵树小得多。
第三条是把它当成物种鉴定标准。它的种一级大面积留空，属名带数字后缀表示 GTDB 的拆分结果，很多叶子只到科。拿它给一份临床分离株下种级结论，等于把「树上最近的邻居」当成「鉴定结果」。
1.4 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 把 16S 与鸟枪数据放到同一棵树算距离 | 一棵含两类末端的树，UniFrac 可直接跑 | 够，这是它唯一不可替代的一项 |
| 给 V4 ASV 一条谱系 | 沿树读出的七级路径，含空种名 | 多数够，未收录的 ASV 直接留空 |
| 把 V4 片段与全长 16S 放在一起比较 | 两者都是树上的末端，距离可比 | 够 |
| 直接拿来跑的预训练分类器 | V4 与全长两个朴素贝叶斯模型 | 够，但覆盖面限于骨架层 |
| 做功能、通路、耐药基因推断 | 无 | 不够，它一条功能注释都不含 |
| 做丰度、差异、临床关联分析 | 无 | 不够，它不含样本与计数 |
| 与旧版 Greengenes 结果对接 | 无映射 | 不够，两套命名不通用 |
| 给新测的、未沉积的 ASV 分类 | 只能匹配树上已有序列 | 多半不够，这是硬边界 |
1.5 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 同一批样本做了 16S 和鸟枪，想合起来讲一个故事 | 提供同一棵树，两条路线的距离可直接比较 | 先把两边的 feature 都换成同一命名空间，再算 UniFrac |
| 手上是 DADA2 或 Deblur 输出的 ASV 表 | 树的 md5 版叶名与默认输出对得上 | 直接用 md5 那套树与分类表，省掉改名 |
| 从 Qiita 或 redbiom 取的表 | 叶名多半是序列或记录号 | 用 asv 或 id 版，或先跑一次 relabel |
| 要把新旧两批研究放在一起比 | 新版分类更细、与 GTDB 同步 | 旧数据必须重跑一遍注释，不能只换库名 |
| 只想要一个比 SILVA 更贴 GTDB 的 16S 分类器 | 官方 V4 模型与 GTDB 命名一致 | 注意模型只认骨架层片段，覆盖率要事先估 |
| 要做环境样本的广谱多样性 | 树覆盖了大量 Qiita 环境片段 | 未收录类群会留空，需与 SILVA 结果交叉看 |
| 研究细胞器序列 | 分类器含线粒体与叶绿体标签 | 但这些标签不在树里，做不了系统发育比较 |
1.6 一句话判断
如果你的问题是「同一批样本的两条测序路线能不能放在一张图上」，Greengenes2 目前是唯一现成的答案；如果你的问题是「这条序列是什么」，它未必比 SILVA 好用。
1.7 不适合谁：五条边界
第一类不适合的是把参考库当样本库的人。这里没有样本、没有分组、没有时间点，一条记录的身份证是序列或其哈希，不是受试者编号。想拿它做队列分析，第一步就卡住。
第二类不适合的是要功能结论的人。它不含基因、酶、通路、耐药或毒力注释，从一条 16S 谱系推功能，中间要跨过整整一层宏基因组分析，这一步它不提供任何帮助。
第三类不适合的是依赖旧版命名的既有流程。任何写死了 p__Firmicutes 或 OTU 编号的脚本，换到新版都会静默返回空值，而且不报错——这是最费时间的一类故障。
第四类不适合的是想给任意新序列分类的人。它的分类逻辑是「查表」而不是「比对」：序列在树上，就有谱系；不在，就没有。没有近似匹配、没有置信度、没有「最相近物种」这种兜底。要做新序列的近似检索，得回去用 SILVA 或 BLAST。
第五类不适合的是需要精细种级判定的临床场景。种名覆盖率有限，属名还带拆分后缀，用它出鉴定报告不成立。
§2 数据构成与规格
2.1 一次发布是 25 个文件，四类东西
打开 2024.09 的目录，会看到 25 个以版本号开头的文件，外加 3 个说明文件。这 25 个不是 25 种数据，而是同一套内容的四种投影：骨架层、树、序列、分类，每类再按叶名命名空间与容器格式各出一份。
| 类别 | 文件数 | 形态 | 用途 |
|---|---|---|---|
| 骨架层 | 5 | backbone.full-length.fna、backbone.tax、backbone.v4.fna，以及两个 nb 分类器 | 训练分类器、看骨架里有什么 |
| 树 | 6 | phylogeny.{asv,id,md5}.nwk 各一份裸 Newick 与一份 QZA | 算距离、做放置、查位置 |
| 序列 | 2 | seqs.fna.gz 与 seqs.fna.qza | 建库核对、自查序列 |
| 分类 | 12 | taxonomy.{asv,id,md5} × | 查谱系、做注释 |
四类的规模差得很远。序列与分类是全量，各自两三千万条量级；骨架层只有全量的百分之一左右；两个分类器更小，因为只收骨架层原位切出的 V4 与全长序列。下载时如果只按「哪个文件最大就下哪个」来选，多半会拿到一份自己用不上的全树，而错过真正要用的分类器。
2.2 七级分类与各层类元数
分类路径是 GTDB 风格，七级用 d__ 到 s__ 前缀标记，级间用分号加空格分隔。把 2024.09.backbone.tax.qza 里的分类表拆开、按前缀去重计数，得到骨架层的类元数如下。
| 层级 | 前缀 | 唯一名称数 | 备注 |
|---|---|---|---|
| 域 | d__ | 2 | 细菌与古菌，不含真核 |
| 门 | p__ | 132 | 含 GTDB 的拆分门，如 Bacillota_A |
| 纲 | c__ | 333 | |
| 目 | o__ | 957 | |
| 科 | f__ | 2,107 | |
| 属 | g__ | 8,114 | 大量带数字后缀 |
| 种 | s__ | 22,901 | 名字常为「属名 + 种加词」的拼接 |
这张表只统计骨架层的 337,506 行记录，不含 DEPP 放置的两千余万条片段。片段没有自己的新名字，它们的谱系是沿树读出来的，读到的就是骨架层这些名字。所以上表的类元数就是整个库的命名空间，规模不再增加。
有一点容易看错：种一级两万余个名字，并不等于两万余个有基因组支撑的物种。论文给出的口径是，种一级末端中只有 46.5% 有完整基因组覆盖，其余是靠全长 16S 撑起来的。名字的密度和证据的密度不是一回事。
另一处容易看错的是层级的「拥挤程度」。从门到种，类元数大致按每个层级三到八倍的速度扩张，属一级膨胀得最厉害，因为 GTDB 近几版把大量原本笼统的大属拆成了若干小属。这意味着两年前查到的属名，现在可能已经变成两个名字，其中一个带数字后缀。按属名做跨研究汇总时，如果不做归一，同一个生物学实体很容易被统计成两条。
2.3 一条记录的解剖
分类表是两列。第一列是 Feature ID，第二列是 Taxon。下面两行取自骨架层的真实记录，一行有完整的种名，一行的种名是空的。
MJ006-1-barcode39-umi49105bins-ubs-7 d__Bacteria; p__Bacillota_A_368345; c__Clostridia_258483; o__Lachnospirales; f__Lachnospiraceae; g__Eubacterium_G_180878; s__Eubacterium_G_180878 ventriosum
MJ006-1-barcode39-umi51500bins-ubs-7 d__Bacteria; p__Pseudomonadota; c__Gammaproteobacteria; o__Enterobacterales_737866; f__Pasteurellaceae; g__Haemophilus_D_735815; s__
三件事值得注意。第一，Feature ID 是一串组装与分箱流程留下的复合标识，不是登录号，也不是物种名——它标识的是一条序列记录，不是一株菌。第二，属名带 _G_180878 这样的后缀，这是 GTDB 在把一个大属拆开时给新属的编号，跨库比对前必须把这些后缀处理掉，否则同一个属在两套库里永远对不上。第三，第二行的种名是空的但属名有值，这不是数据缺失，而是这条序列在树上没有落到任何一个有种名的枝上。
2.4 叶名的三套命名空间
同一棵树有 6 个文件，拓扑完全一样，差别只在末端怎么称呼。这不是为了好看，而是为了接住上游不同的输出习惯。
| 命名空间 | 叶名长什么样 | 谁会产生这种标识 |
|---|---|---|
| asv | 序列本身，如 TACGGAAGGTCCAGGCG… | Qiita、redbiom 查询结果 |
| md5 | 32 位十六进制哈希 | DADA2、Deblur 的默认输出 |
| id | 内部编号或记录号 | Woltka 处理过的鸟枪数据 |
选错命名空间的后果是静默的：表能读进来，注释也能跑完，但匹配率为零，输出一张全空的分类表。常见的排查顺序是，先看 feature 表里第一条 ID 的形态，再决定下哪个版本。
三套命名空间之间可以互转，官方插件提供了 relabel 方法，靠一份 label map 把一种标识换成另一种。这份 map 不在那 25 个数据文件里，需要按插件文档另行取用，这一点在流程设计时容易被忽略：本地离线环境里如果只下了数据文件，改名这一步就跑不起来。
实践中最省事的做法是不改名，直接下载与上游输出匹配的那一套。DADA2 与 Deblur 的默认输出是 md5，那就下 md5 版的树与分类；从 Qiita 或 redbiom 取的表，叶名通常是序列本身，那就下 asv 版。只有当一张表里混了两种标识时，才需要动 relabel——而这种混表往往出现在把两个时期的数据拼在一起的时候，也正是分类体系已经换过一遍的时候。
2.5 它明确不包含什么
| 不包含 | 具体说明 |
|---|---|
| 功能注释 | 没有基因、酶、KO、通路、耐药或毒力字段 |
| 丰度与计数 | 没有任何样本表，也没有计数矩阵 |
| 样本元数据 | 没有分组、部位、时间、临床变量 |
| 真核序列 | 域一级只有细菌与古菌，18S 与 ITS 一概没有 |
| 大亚基 rRNA | 只做 16S，23S 与 5S 不在范围内 |
| 旧版编号 | 与 13_8 的 OTU 无映射，也没有兼容层 |
| 新序列的近似匹配 | 只有精确匹配，无最近邻、无置信度 |
§3 核心层 A：树是主产品，序列是副产品
3.1 骨架怎么来的
骨架来自 Web of Life 项目。这一版骨架用了近一万六千个细菌与古菌基因组，从 NCBI 的公共基因组里相对均匀地采样，覆盖各个门，避免某个测序热门门类占比过高。基因组之间的关系用 uDance 重建，输入是 380 个全局单拷贝标记基因。这一步的产物是一棵纯基因组的树，树上的每个末端都是一个有完整基因组的菌株。
这棵树是固定不动的。后面所有操作都在它上面做加法，不改基因组之间的相对关系。这个约束很重要：它保证了「基因组之间的拓扑」在整个流程里始终可信，插入 16S 与片段不会把基因组之间的相对位置搅乱。
3.2 全长 16S 怎么插进去
第二步是把全长 16S 插到骨架上。来源有三路：活树计划 LTP 的人工校订全长序列、GTDB 各版本随库发布的全长 16S、以及从细菌操纵子中直接抽取的全长序列。三路合起来约一百七十余万条。插入同样用 uDance，因为它的算法设计就是「在固定骨架下增量插入」，与第一步共用同一套标记基因比对逻辑。
插完之后，树上一部分末端是基因组，一部分是全长 16S。这两类末端之间的相对位置，是后面所有片段放置的参照点：一条 V4 片段落在某个位置，它到底是靠近某个基因组还是靠近某条全长 16S，取决于这一步做得准不准。
3.3 V4 片段怎么放上去
第三步是放片段。数据源是 Qiita 汇集的公共与私有研究，经 redbiom 取出全部 V4 ASV，去重后约两千三百万条，来自数十万份样本。放置工具是 DEPP，一个用深度学习估计放置位置的实现，比传统的最大似然放置快几个数量级，这是能在可接受时间内处理两千万条片段的前提。
除 V4 之外，还放了 SILVA 来源的线粒体与叶绿体全长 16S。这两类序列的归属很特殊：它们被放进了树，但对应的分类标签没有进拓扑。2024.09 的更新说明写得很清楚，这些记录是通过放置进来的，不是拓扑更新带进来的，因此它们出现在朴素贝叶斯模型里，却不在树的命名节点上。
3.4 案例：一条 V4 ASV 在树上的三次出场
官网首页给出三个示例查询，其中一条是一条 63 碱基的 V4 序列（TACGGAAGGTCCAGGCG 开头），以及它的 MD5 a31863de93360b9605d32909706d5a10。这条序列可以把整个流程串起来看。
第一次出场在放置阶段：它作为两千万条片段之一被 DEPP 放到骨架的某条枝上，位置一旦确定就不再变动。第二次出场在命名阶段：因为它落点所在的那条枝挂着一个名字，它继承了这个名字往下到种的整条路径；如果它落在了某个命名节点的父枝上，父枝的名字会被上提一级来覆盖它。第三次出场在查询阶段：用它的 MD5 去查分类表，返回的就是第二次出场时定下的路径；用它的序列去查 asv 版，返回同一行；用它的内部编号去查 id 版，返回的还是同一行。
三次出场说明了一件事：这条序列的分类不是算出来的，是「先放好、再读出来」的。放错了就读错，没放上去就没有。这个案例在 §4.3 讲名字上提时会再回到一次，在 §5.4 讲三套叶名怎么选时还会再回到一次。
3.5 为什么树比序列更重要
如果只看文件体积，序列与分类占了绝大部分，树只占一部分。但从使用价值看，顺序是反的。
序列文件给你的是「库里有什么」，这件事用 BLAST 也能问。分类表给你的是「每条序列叫什么」，这件事用任何分类器也能近似做到。唯有树给你的是「两条序列之间有多远」，而且在同一个坐标系里同时覆盖基因组与片段——这件事没有替代品。用 UniFrac 做 beta 多样性、做样本聚类、做肠型划分，靠的都是这一层。
所以判断一份 Greengenes2 用得对不对，最简单的一条标准是：有没有真的用上那棵树。如果只是拿分类表做注释，然后转头用 Bray-Curtis 算距离，那这套库的一大半价值就没被用上。
3.6 树的结构：三类末端，一套枝长
树上的末端分三类，但枝长的含义是一致的：都是每位点的期望替换数，由建树与放置两步共同给出。这一点很关键，因为它意味着基因组末端与片段末端之间的距离是可以直接比较的，不需要额外校正。
代价是分辨率不齐。基因组的枝长短、位置稳；全长 16S 次之；V4 片段只有几十个碱基，枝长估计的不确定性最大。一条片段与另一条片段之间的距离，可靠性明显低于两个基因组之间的距离。做精细的组间比较时，这个差别会体现为同一批样本在不同子集上的排序不完全一致。
还有一个不太直观的后果：树越大，单条片段的分辨力越依赖它周围的密度。一条落在热门类群中心的片段，周围有成千上万条近亲，它的位置会被这些近亲共同约束住；一条落在冷门类群边缘的片段，周围可能只有几条全长序列，它的位置几乎只由这几条决定。同样是「放在树上」，两类片段的位置可靠性差得很远，而库本身不给任何置信度字段来区分它们。
使用者能拿到的一个间接线索是分类深度：名字读到种，说明这个位置有较长的参照撑着；只读到科属，多半说明它周围只有短片段。想做保守分析，可以把统计限制在种名非空的子集上，代价是丢掉大半数据；想要覆盖广度，就得接受片段层的位置不确定性。
§4 核心层 B：分类怎么来的，边界在哪
4.1 种子分类来自 GTDB，LTP 补位
分类不是从树上聚类出来的，是先有名字再贴上去。构造时先用 Web of Life 到 GTDB 的映射建立一个种子分类，再用 LTP 的信息补充 GTDB 尚未收录的类群。两套来源冲突时优先 GTDB，理由很实际：GTDB 主动维护、版本节奏固定、且保留了多系标签（如把原来的厚壁菌门拆成 Bacillota、Bacillota_A 等多个门）。
装饰工具是 tax2tree。它把分类标签分配到树的节点上，遇到同一层级的多个标签落在同一条枝上时，会按拓扑把标签下推到合适的深度。这样得到的是一棵「每个命名节点都带谱系」的树，而不是一张独立的物种名单。这也是为什么库里的分类表可以按树导出成 Newick 形态——分类与拓扑是同一件事的两种表达。
2024.09 版把种子换成了 GTDB 220 与 LTP 2023 年 8 月版，随之而来的是门一级改名，比如原来的 Firmicutes 体系整体换成 Bacillota 体系。这类改名不是修补，是替换，任何按门名做筛选的脚本都要跟着改。
换名的规模值得单独说一句。GTDB 从 r202 起系统性处理并系群，把一批传统门拆成主门加 _A、_B 后缀的兄弟门；到 r220，这套拆法已经覆盖了厚壁菌、拟杆菌、放线菌等几个最大的门。对一个只做属水平统计的流程，影响不大；对一个按门汇总做跨研究元分析的流程，影响是整表重排。这也是这份库没法当作「稳定的分类字典」使用的根本原因：它是一份跟随上游变化的投影，上游一动，它就得动。
4.2 名字上提：一个容易被忽略的机制
片段放置有个技术后果。一条片段如果落在某个命名节点的父枝上，也就是落在这条枝分叉之前的位置，它就悬在两个兄弟群之间，没有明确归属。这种情况在多样性高的节点上很常见，比如古菌域这个节点本身覆盖的多样性太大，很多片段放上去之后落在它的父枝上。
处理办法是名字上提：如果某个名字对应的枝上出现了多个片段的放置点，说明这些片段比这个名字所代表的类群更「靠外」，于是把这个名字提升到父节点，让这些片段继承它。这个规则简单，效果是让归属尽量保守——宁可给一个更粗的名字，也不给一个错的细名字。
§3.4 的案例里那条序列如果落在这样的位置，它拿到的就会是一个比预期更粗的层级。这是设计使然，不是缺陷。
4.3 与旧版的断裂在哪
断裂有三处，每一处都足以让旧脚本失效。
第一处是标识。旧版以 OTU 为单位，编号是聚类产生的序号；新版以序列或哈希为单位，没有聚类这一步。同一个「OTU」在新版里可能对应几十条不同的 ASV。第二处是命名。旧版的分类路径以 k__ 开头、门名用传统命名；新版以 d__ 开头、门名用 GTDB 命名，还带数字后缀。第三处是树的角色。旧版的树是从 OTU 代表序列建的，只含 16S；新版的树以基因组为骨架，16S 是插进去的。
三处叠加的结果是：新旧两版之间不存在任何自动转换路径。想要对比，唯一可行的办法是把旧数据用新库重跑一遍注释，然后按新名字比较。
4.4 只能分类树上已有的序列
这是最硬的一条边界，也是最多人踩的一条。分类逻辑是查表：输入一个特征，去分类表里找同名的一行，找到就返回谱系，找不到就返回空。整个过程没有比对、没有最近邻、没有置信度阈值。
后果是，任何没有进入 Qiita 的 V4 序列都分不上。新测的样本、私有数据、用不同引物区段扩增的序列，只要不在那两千多万条里，就是空。空的含义是「未收录」，不是「未知物种」，也不是「低置信度」。把空当成后者去做下游统计，会系统性地低估多样性，而且偏差随研究的新旧程度变化——越新的数据，未收录比例越高。
taxonomy-from-features 这个方法名容易让人以为它会比对，其实它做的仍然是查表，只是允许你用序列而不是 ID 去查。
4.5 细胞器序列的特殊位置
线粒体与叶绿体 16S 在 2024.09 里有一处不对称：它们进了两个朴素贝叶斯模型，但没进树的拓扑。更新说明的原话是这些记录通过放置进来、不在拓扑更新范围内。
实践含义有两条。一是用分类器做注释时，宿主线粒体与人源叶绿体读数会被标成对应的细胞器标签，这比标成细菌要准确，做宿主过滤时可以直接按标签剔除。二是用树做距离计算时，这些序列不在树上，会被 filter-features 过滤掉，不会污染 beta 多样性。两条合起来是合理的：细胞器序列本来就该被剔除，但剔除之前得先认出它们。
§5 核心层 C：怎么取下来、接进流程
5.1 目录结构与取数入口
官方下载走 FTP 的 HTTP 镜像，根目录下按版本号分文件夹：2022.7 到 2022.10 的四个候选版、2022.10 正式版、2024.09 现行版，另有 gg_12_8、gg_13_5、gg_13_8_otus 几个旧版目录并列存放。旧版目录的时间戳停在 2013 到 2015 年，这一点本身就是「旧版已停更」的直接证据。
current 是一个指向现行版的软链，写流程时建议锁死版本号而不是用 current，否则某天目录一换，分析就不可复现。
5.2 下载与自查的最小脚本
#-- 建目录并进入
mkdir -p gg2 && cd gg2
BASE=https://ftp.microbio.me/greengenes_release/current
#-- 先取三份说明，确认版本与许可
for f in 00README 00CHANGELOG 00LICENSE; do
curl -sLO "$BASE/$f"
done
head -20 00CHANGELOG
#-- V4 路线的最小集合：序列、分类、树、分类器
for f in 2024.09.seqs.fna.qza \
2024.09.taxonomy.asv.tsv.qza \
2024.09.phylogeny.asv.nwk.qza \
2024.09.backbone.v4.nb.qza; do
curl -sLO "$BASE/$f"
done
ls -lh
5.3 数一遍序列条数
不放心官方数字时，可以直接数。FASTA 的条数就是行首为 > 的行数，边下边数，不必落盘。
BASE=https://ftp.microbio.me/greengenes_release/current
#-- 数全部构建序列的条数
curl -sL "$BASE/2024.09.seqs.fna.gz" | zcat | grep -c "^>"
#-- 数 ASV 分类表的行数（含表头）
curl -sL "$BASE/2024.09.taxonomy.asv.tsv.gz" | zcat | wc -l
两条命令给出的数字应当接近但不完全相同：序列文件收录全部构建用序列，分类表只收有谱系的记录，差出来的部分是没有落到命名枝上的片段与细胞器序列。
这两个数字的用途不同。序列条数用来核对「文件是不是完整下完了」，与 README 的口径对得上就说明没坏；分类表行数用来核对「有多少条能被注释」，它才是匹配率的分母。把两者混为一谈，会在大约万分之几的误差上纠结半天，而真正要看的匹配率其实差着几十个百分点。
顺带一提，这两个数都只能通过下载全量文件才能得到，官网首页不给。目录页给的是文件体积，从体积反推条数没有意义——树文件与分类文件的压缩率差别很大，同样的条数可能差出一个数量级。
5.4 三套叶名怎么选
回到 §3.4 的案例：同一条序列在三个文件里有三种写法。选哪一套，取决于 feature 表里 ID 的形态。
#-- DADA2/Deblur 默认输出 md5，直接把表改写成 md5 命名空间
qiime greengenes2 relabel \
--i-feature-table table.qza \
--i-reference-label-map gg2-2024.09-label_map.qza \
--p-as-md5 \
--o-relabeled-table table-md5.qza
label map 是可选的辅助件，不在那 25 个数据文件里，需要按官方插件文档另行获取。不做改名也可以，直接下 md5 版的树与分类表，效果一样。
5.5 分类与过滤的两条命令
#-- 按表分类：表里每个 feature 都必须在树上
qiime greengenes2 taxonomy-from-table \
--i-reference-taxonomy 2024.09.taxonomy.asv.tsv.qza \
--i-table table.qza \
--o-classification taxonomy.qza
#-- 按代表序列分类：本质仍是查表，不是比对
qiime greengenes2 taxonomy-from-features \
--i-reference-taxonomy 2024.09.taxonomy.asv.tsv.qza \
--i-reads rep-seqs.qza \
--o-classification taxonomy.qza
#-- 过滤：把不在树上的 feature 剔掉，剩下的才能进 UniFrac
qiime greengenes2 filter-features \
--i-feature-table table.qza \
--i-reference 2024.09.phylogeny.asv.nwk.qza \
--o-filtered-table filtered.qza
第三条命令是接 UniFrac 之前必须跑的一步。不过滤直接算，要么报错，要么得到一张稀疏到无法解释的距离矩阵。
5.6 直接读分类表做核对
不想装 QIIME 2 时，qza 就是一个 zip，用标准库就能拆。
import zipfile, collections
#-- qza 是 zip，取里面的 taxonomy.tsv
z = zipfile.ZipFile("2024.09.backbone.tax.qza")
name = [n for n in z.namelist() if n.endswith("data/taxonomy.tsv")][0]
rows = z.read(name).decode("utf-8").splitlines()[1:]
uniq = collections.defaultdict(set)
for line in rows:
tax = line.split("\t")[1]
for part in tax.split(";"):
part = part.strip()
if part:
uniq[part[:3]].add(part)
for rank in ["d__", "p__", "c__", "o__", "f__", "g__", "s__"]:
print(rank, len(uniq[rank]))
这段代码的输出就是 §2.2 那张表。它同时也是最快的版本核对手段：换版本后重跑一次，类元数一变就知道分类动过。
§6 与库内词条的关系
6.1 与 SILVA：并列的两套参照，分工不同
这是最需要说清的一处。两者都是微生物分类参照，但定位不同。
| 维度 | Greengenes2 | SILVA |
|---|---|---|
| 覆盖分子 | 只做 16S（小亚基） | 小亚基 16S/18S 加大亚基 23S/28S |
| 覆盖域 | 细菌与古菌 | 细菌、古菌、真核 |
| 核心资产 | 一棵含基因组的系统发育树 | 带比对坐标与质量分的序列集 |
| 命名来源 | GTDB 优先，LTP 补充 | LPSN 为主，自有树裁决冲突 |
| 能否与宏基因组对齐 | 能，基因组在同一棵树上 | 不能，库内无基因组 |
| 新序列处理 | 查表，未收录即空 | 比对，可给近似与质量分 |
| 更新节奏 | 跟 GTDB 版本走 | 自有版本号，亚基之间不同步 |
一句话概括分工：SILVA 回答「这条序列像谁、有多像」，Greengenes2 回答「这条序列与那份宏基因组数据在不在同一个坐标系里」。做常规 16S 分类，SILVA 覆盖更宽、兜底更好；做多组学整合，只有 Greengenes2 能接。
两者不冲突，很多流程会同时用：用 SILVA 做初筛和嵌合检查，用 Greengenes2 做最终的统一树投影。需要注意的是，两套命名不能混用，SILVA 的 Firmicutes 与 Greengenes2 的 Bacillota 指的不是同一个边界。
还有一层差别在数据结构上。SILVA 的核心是一张序列与比对坐标的表，比对是它的第一等公民；Greengenes2 的核心是一棵树，比对只是构建过程中的中间步骤，最终产物里没有比对列。想拿 Greengenes2 的序列做多序列比对，得自己另跑一遍；反过来，想拿 SILVA 的树做跨组学比较，树上根本没有基因组。这个不对称决定了两者在流程里的位置：SILVA 适合放在前面，负责把序列变成可比对的坐标；Greengenes2 适合放在后面，负责把已经定好名的表投到统一坐标系里。
6.2 与 UHGG：基因组目录对参考树
UHGG 是肠道菌的基因组集合，每条记录是一份组装，带基因与蛋白。Greengenes2 的骨架也来自基因组，但它不提供基因组本身，只提供基因组在树上的位置与一个名字。
关系是上下游：UHGG 回答「这个物种的基因组长什么样」，Greengenes2 回答「这个物种在统一树上站在哪」。要做功能分析，去 UHGG 取基因组；要做群落距离，用 Greengenes2 的树。
6.3 与 MetaSUB、HMP、American Gut：样本对参照
后三个都是样本层面的资源：MetaSUB 是城市表面采样，HMP 是多部位人体基线，American Gut 是公民科学队列。它们的产物是 feature 表与元数据，Greengenes2 的产物是参照。前者需要后者才能把序列变成名字。
这也是为什么 Greengenes2 的数据来源里会出现这些项目：它们的 V4 序列经 Qiita 汇入，成为树上的片段。反过来说，用这些项目的历史数据做分析时，如果当年用的是旧版 Greengenes，直接换成新版会得到不同的结果，必须重跑。
6.4 一张检索路径图
| 你要问的问题 | 该去的库 |
|---|---|
| 这条序列是什么、和谁最像 | SILVA |
| 这批 16S 和那批鸟枪能不能放一张图 | Greengenes2 |
| 这个物种的基因组里有什么基因 | UHGG |
| 这个城市的表面微生物组成 | MetaSUB |
| 健康人五个部位的菌群基线 | HMP |
| 普通人的肠道菌群随饮食怎么变 | American Gut |
| 一段序列的物种归属在 GTDB 体系下叫什么 | Greengenes2 或 GTDB 本体 |
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
评估这类参考库时，最容易犯的错是拿「样本数据集」的标准去量它。样本数据集要问代表性、抽样偏倚、缺失率；参考库要问的是另一组问题：命名体系是否自洽、拓扑是否稳定、边界是否说清、版本是否可追溯。
按 DAIMS 框架（Datasheets for AI and medical datasets）做文档化评估时，这一点尤其明显：DAIMS 的检查清单里有一批条目是关于受试者、伦理、去标识化的，对一份不含人类数据的参考库全部不适用。真正起作用的是数据来源、变换链、限制声明这三块。下面按这个口径打分。
7.1 五维评分
| 维度 | 评分 | 依据 |
|---|---|---|
| 来源可追溯 | 强 | 骨架、全长 16S、片段三段的来源在 README 与论文里逐段写明 |
| 变换链透明 | 强 | uDance 与 DEPP 均为公开工具且有独立论文，脚本开源 |
| 命名自洽 | 中上 | 与 GTDB 一致，但数字后缀造成跨库摩擦 |
| 边界声明 | 强 | 「只分类树上已有序列」在插件文档里明写 |
| 版本可复现 | 中 | 版本号清晰，但 current 软链与 label map 的获取路径不够显眼 |
7.2 三条结构性局限
第一条是覆盖偏倚来自 Qiita。片段的主体是 Qiita 汇集的 V4 数据，Qiita 的样本构成偏向北美与欧洲的人体与土壤研究。这意味着树上片段密度的分布，反映的是研究热度而不是自然界的多样性。落在冷门生境的序列，即使能被放置，周围也缺少近亲，枝长估计会更粗略。
第二条是单区段依赖。整棵树的片段层几乎全是 V4。用 V3–V4、V4–V5 或全长测的数据，能匹配上的只是其中与 V4 重叠的部分，其余部分要么落在骨架的全长序列上，要么匹配不上。这一点在使用说明里没有反复强调，但对多区段混用的团队是实质约束。
第三条是树的单一性。只有一棵树，没有拓扑不确定性估计。多数系统发育分析会给出 bootstrap 或后验概率，这里没有。一条片段的位置是一个点估计，不是一个分布。做敏感性分析时，没有第二棵树可以对照——这是设计上的取舍，不是疏忽，但使用者需要知道。
7.3 已知的、可枚举的偏差
| 偏差 | 表现 | 应对 |
|---|---|---|
| 研究热度偏倚 | 热门生境的片段密度远高于冷门生境 | 按生境分层看匹配率，不要只看总体 |
| 区段偏倚 | 非 V4 数据只能部分匹配 | 事先确认引物区段，必要时换参照 |
| 命名漂移 | GTDB 每版可能改门名与属边界 | 锁版本号，记录每次分析的 GTDB 版本 |
| 数字后缀 | 属名带编号，跨库对不上 | 比对前做名字归一，去掉后缀再匹配 |
| 种级空缺 | 种名覆盖率有限 | 统计做到属一级，种一级只作参考 |
7.4 外部验证
论文给出的验证是同一批样本的两条路线对照：同一棵树下 UniFrac 的 PCoA 相关系数 0.86，分类学层面属水平相关 0.85、种水平 0.65。这些数字说明的是「统一树确实让两条路线靠拢」，不是「分类准确率有多高」。两者不是一回事，引用时别混。
另一组可用的对照是直接从树上读谱系与用朴素贝叶斯分类器比较：前者在精确匹配的前提下更好，后者覆盖面更广但精度略低。这也解释了为什么官方把两条路都留着——一个求准，一个求全。
需要提醒的是，这些相关系数都是在「同一批样本同时做了两条路线」的条件下算的。它证明的是内部一致性，不是外部正确性。一份只有 16S 的数据，用这套库得到的结论与用 SILVA 得到的结论是否一致，论文没有给出对照，也不该从那些数字里推出来。跨库一致性是另一个问题，得自己跑一遍才知道。
7.5 它为何能持续
一个参考库要活下去，得有稳定的数据回流和稳定的维护动机。Greengenes2 的两个条件都比较硬。
回流来自 Qiita：新研究不断沉积，V4 序列持续汇入，树的片段层因此每年都在长，2024.09 相比 2022.10 多放了两百三十万条片段。动机来自生态位：Qiita 生态里需要一个能把 16S 与鸟枪数据对齐的参照，而这个参照没有第二家在做。工具链（uDance、DEPP、tax2tree）都是同一个团队维护的开源件，更新成本可控。
风险也在这里：库的命运与 Qiita 绑定。Qiita 的样本构成变了，树的偏倚就跟着变；团队的维护节奏变了，版本就会停。旧版 Greengenes 在 2013 年之后的十年空白，就是这个模式失效后的样子。
§8 生态位与历史
8.1 历史沿革
旧版 Greengenes 起于 2000 年代中期，由 Lawrence Berkeley 国家实验室的团队维护，最后一版 13_8 发布于 2013 年 8 月，此后十年没有更新。它在 QIIME 1 时代是默认参考库，大量 2010 年代前中期的论文用它做 OTU 聚类与分类，这也是今天还有大量脚本写死旧命名的原因。
空白期里，16S 社区逐渐转向 SILVA 与 RDP，鸟枪社区转向 GTDB 与 NCBI。两条路线各走各的，参照系的裂口就是在这个时期拉开的。
2022 年，Knight 实验室把这个名字接了回来，但做法完全换了：不再做 OTU 聚类，改为以基因组树为骨架、把片段挂上去。2022 年 7 月到 10 月连发四个候选版（最后一版仍挂 2022.10 的名号），10 月 28 日发布正式版，2023 年 7 月论文上线，2024 年 9 月发布第二版。
8.2 版本节奏与它的现实约束
| 版本 | 时间 | 主要变化 |
|---|---|---|
| 2022.7 至 2022.10-rc1 | 2022 年 7–10 月 | 四个候选版，流程迭代 |
| 2022.10 | 2022 年 10 月 28 日 | 首个正式版，确立骨架与分类体系 |
| 2024.09 | 2024 年 9 月 26 日 | 换 GTDB 220 与 LTP 2023-08，加放两百余万条片段，细胞器进分类器 |
节奏不是固定的年度发布，而是跟着上游走：GTDB 出新版、LTP 出新版，这里才动。2024.09 有一点值得单独记：拓扑没有变，只是分类与片段增加。这意味着两次发布之间的树可以直接比较，但分类表不能直接比——同一片叶子可能换了名字。
这种「一半变一半不变」的发布方式，对复现提出了一个具体要求：分析记录里必须同时写清树的版本与分类的版本。多数人只写库名加版本号，觉得够了；但如果有人在 2023 年用 2022.10 的树配了 2024.09 的分类表（理论上可行，因为拓扑兼容），结果就无法用单一的版本号描述。稳妥的做法是把树文件与分类文件的文件名都留档，而不是只记一个版本号。
8.3 生态位：四个参照库的分工
| 库 | 回答的问题 | 记录单位 |
|---|---|---|
| Greengenes2 | 16S 与宏基因组能否同树比较 | 树上的一片叶子 |
| SILVA | 这段 rRNA 属于谁、像谁 | 一段 rRNA 区域 |
| UHGG | 这个物种的基因组里有什么 | 一份基因组组装 |
| GTDB | 这个基因组该叫什么 | 一个基因组 |
四者里 GTDB 与 Greengenes2 关系最近：后者的分类直接来自前者。差别在于 GTDB 只做基因组，Greengenes2 把 16S 也拉了进来。所以可以把 Greengenes2 理解为「GTDB 分类体系在 16S 世界的投影」，这个说法不严谨但抓得住要点。
8.4 从伯克利到圣地亚哥：一次换手
旧版 Greengenes 的维护方在伯克利，新版在圣地亚哥。换手的不只是机构，还有整套方法论：旧版的核心是「聚类 + 代表序列」，新版的核心是「骨架 + 放置」。方法论一换，旧版的资产（OTU 表、代表序列集、分类器）在新版里一样都用不上。
这也是为什么新版虽然沿用了名字，却几乎可以当成一个全新的库来对待。名字的延续带来的是认知上的便利，也带来误解——以为升级就能平滑迁移的人，多半会在第一次跑通之后发现结果全变了。
§9 使用指引
9.1 三种角色的路径
| 角色 | 最短路径 | 注意 |
|---|---|---|
| 只做 16S 分类 | 下 taxonomy.asv 与 backbone.v4.nb，跑分类 | 先估匹配率，低于七成要换参照 |
| 做 16S 与鸟枪整合 | 下树与分类，两边统一命名空间，过滤后算 UniFrac | 必须先 filter-features |
| 建流程或做二次开发 | 下骨架层与全部文件，用 Python 直接读 qza | 锁版本号，别用 current |
9.2 一条最短的可用流程
#-- 1) 确认输入表的 ID 形态
qiime feature-table tabulate-seqs --i-data rep-seqs.qza --o-visualization rep-seqs.qzv
#-- 2) 按形态选一套树与分类（此处假设已是 asv 命名空间）
#-- 3) 过滤掉不在树上的 feature
qiime greengenes2 filter-features \
--i-feature-table table.qza \
--i-reference 2024.09.phylogeny.asv.nwk.qza \
--o-filtered-table filtered.qza
#-- 4) 分类
qiime greengenes2 taxonomy-from-table \
--i-reference-taxonomy 2024.09.taxonomy.asv.tsv.qza \
--i-table filtered.qza \
--o-classification taxonomy.qza
#-- 5) 出可视化，先看匹配率再往下走
qiime metadata tabulate \
--m-input-file taxonomy.qza \
--o-visualization taxonomy.qzv
第五步是关键。匹配率低于预期时，先别急着做统计，回头查 ID 形态与引物区段，问题多半在这两处。
9.3 引用方式
库本身引 2023 年的 Nature Biotechnology 论文；用了 QIIME 2 插件再补引插件；用了建树或放置工具，按对应工具的论文补引 uDance 与 DEPP。引用时必须写清版本号（如 2024.09），笼统写「Greengenes2」不足以复现。
9.4 四类常见故障与判断顺序
| 现象 | 最可能的原因 | 怎么确认 |
|---|---|---|
| 分类结果整列为空 | 命名空间不匹配 | 比对 feature 表首条 ID 的形态与树文件叶名的形态 |
| 匹配率约一半，其余为空 | 扩增区段不是 V4，或数据较新未沉积 | 查引物区段；查这些 ASV 是否在 Qiita 有记录 |
| filter-features 后样本大量消失 | 表里多数 feature 不在树上 | 过滤前后各算一次 feature 数与读数总数 |
| UniFrac 报错或距离矩阵极稀疏 | 跳过了过滤这一步 | 检查是否直接拿原表建了树对象 |
四类的共同点是都不报错、只给空或偏差，因此排查顺序应当是「先看 ID，再看区段，最后看过滤」，而不是反过来从统计结果倒推。§3.4 的案例给出的正是这个顺序的依据：一条序列的归属在放置阶段就定死了，后面所有环节只是读取，读不到就说明它从一开始就不在树上。
§10 AI 使用声明
| 项目 | 说明 |
|---|---|
| 内容生成方式 | 由语言模型依据官方 FTP 发布说明、README、CHANGELOG、许可原文与论文摘要撰写 |
| 数字来源 | 序列条数与分类表行数由下载后逐行计数得到；其余取自官方发布说明与论文 |
| 未核实项 | 未逐条核对全树拓扑；树文件体积以目录列表为准，未逐一解压 |
| 分类学判断 | 不替代分类学专家意见，命名争议以 GTDB 与官方文档为准 |
| 临床适用性 | 不构成鉴定结论，不可用于诊断 |
| 时效性 | 截至 2026 年 10 月 29 日；GTDB 更新后分类可能改名 |
| 修订机制 | 新版本发布后应重核 §2 的规模表与 §7 的偏差表 |
| 责任边界 | 使用本词条造成的分析偏差，由使用者自行承担 |
常见误读（避坑清单）
| 常见说法 | 实际 | 证据 |
|---|---|---|
| Greengenes2 是旧版 Greengenes 的更新 | 名字沿用，方法论与命名体系全部换掉 | 旧版目录停在 2013 年；新版分类为 GTDB 命名 |
| 它就是一个 16S 分类器 | 主产品是树，分类器只覆盖骨架层 | 25 个文件里分类器只占 2 个 |
| 和 SILVA 是竞品，选一个就行 | 定位不同，一个管比对，一个管跨组学对齐 | SILVA 库内无基因组，无法与鸟枪对齐 |
| 我的 ASV 分不上是置信度低 | 是查无此条，未收录就没有输出 | 插件文档写明只分类树上已有序列 |
| 换新版只是多了一批序列 | 2024.09 换了 GTDB 220，门名整体改写 | CHANGELOG 列出 Bacillota 等改名 |
| 三个树文件是三个不同版本 | 拓扑相同，只有叶名命名空间不同 | README 逐个说明 asv/id/md5 |
| 线粒体序列也在树上 | 只进了分类器，不在拓扑里 | 2024.09 更新说明明确写了这一点 |
| 可以拿它做功能推断 | 一条功能注释都没有 | 全部文件只有序列、拓扑、谱系 |
| 树上的距离和比对距离等价 | 片段层枝长不确定性明显更大 | V4 片段仅几十碱基，放置误差大 |
| 下最大的文件总没错 | 全树两个多 GB，多数流程用不上 | 常规注释只需分类表与分类器 |
FAQ
Q1：Greengenes2 与旧版 Greengenes 到底什么关系？
只有名字的关系。旧版 13_8 停在 2013 年，用 97% 聚类的 OTU 与自有命名；新版 2022 年起，用基因组骨架加片段放置，分类来自 GTDB。两者的编号、名字、树都不通用，迁移只能重跑。
Q2：它和 SILVA 该怎么选？
看要不要跨组学。只做 16S 的分类与比对，SILVA 覆盖更宽、还能给近似与质量分；要把同一批样本的 16S 与鸟枪放进同一棵树算距离，只能用 Greengenes2。
Q3：为什么我的匹配率只有一半？
三种常见原因：feature 表用了不同的命名空间（先查 ID 形态）、扩增区段不是 V4（树的主体是 V4 片段）、数据较新未进 Qiita（新版研究沉积有滞后）。
Q4：能给自己测的序列分类吗？
只能分类树上已有的。新序列要么先在 Qiita 沉积并等到下一次版本更新，要么改用 SILVA 做比对式分类。这是设计取舍，不是 bug。
Q5：两个朴素贝叶斯模型选哪个？
V4 模型用于 V4 单区或 V3–V4 拼接后的 V4 段；全长模型用于 Sanger 或长读段的全长 16S。混用会让置信度整体偏低。
Q6：为什么属名后面带数字？
这是 GTDB 在拆分大属时给新属的编号，用来区分同名但不同支的类群。跨库比对前必须去掉后缀，否则同一个属在两套库里永远对不上。
Q7：种名大面积是空的，能补吗？
不能从库里补。种级空缺反映的是树上那个位置没有带种名的参照。要更细的归属，得回到原始序列做比对，或用别的库交叉验证。
Q8：三个树文件能不能混用？
拓扑可以混，叶名不行。用 md5 的表配 asv 的树，匹配率为零。要么统一改名，要么下配套的那一份。
Q9：2024.09 和 2022.10 能直接比较吗？
拓扑没变，可以比较；分类表变了，不能直接比。同一片叶子可能换了名字，跨版本统计前要先把两版的名字对齐。
Q10：许可允许商用吗？
允许。BSD-3 条款，保留版权声明与三条款、不拿作者名做背书即可，商业与学术没有区别。
Q11：为什么树上没有真核生物？
库的范围只到细菌与古菌。真核 18S、ITS、大亚基 rRNA 都不在范围内，需要这些请用 SILVA。
Q12：怎么引用才规范？
库引 2023 年 Nature Biotechnology 论文并注明版本号；用了插件补引插件；用了 uDance 或 DEPP 补引对应工具论文。只写库名不写版本，别人复现不了。
术语表
| 术语 | 含义 |
|---|---|
| 参考树 | 一棵带命名节点的系统发育树，用来给新序列定位 |
| 骨架 | 树中由完整基因组构成、拓扑固定的那一层 |
| uDance | 增量式系统发育重建工具，用于把新序列插入固定骨架 |
| DEPP | 基于深度学习的片段放置工具，把短片段定位到树上 |
| tax2tree | 把分类标签按拓扑装饰到树节点上的工具 |
| 放置 | 把一条序列定位到既有树的某条枝上，不改动原拓扑 |
| 名字上提 | 片段落在命名节点父枝时，把该名字提升一级来覆盖 |
| 叶名命名空间 | 树上末端的称呼方式，分 asv、md5、id 三种 |
| ASV | 扩增子序列变体，去噪后的最小序列单位 |
| V4 | 16S 的第四个可变区，约 250 碱基，是最常用的扩增区段 |
| 全长 16S | 约 1500 碱基的完整 16S 序列 |
| GTDB | 基因组分类数据库，本库命名体系的来源 |
| LTP | 活树计划，提供人工校订的全长 16S 与分类 |
| Web of Life | 基因组系统发育项目，本库骨架的来源 |
| 多系标签 | GTDB 把并系群拆开后的命名，如 Bacillota_A |
| 数字后缀 | 拆分时附在属名后的编号，用于区分同名不同支 |
| 单拷贝标记基因 | 每个基因组只出现一次的基因，用于建树 |
| UniFrac | 基于树的 beta 多样性度量，需要一棵共同的树 |
| PCoA | 主坐标分析，把距离矩阵投影到低维 |
| 查表式分类 | 只在参考表里精确匹配，不做近似比对 |
| 细胞器 16S | 线粒体与叶绿体携带的 16S，常需在分析前剔除 |
| QZA | QIIME 2 的产物容器格式，本质是 zip |
| DAIMS | 面向 AI 与医学数据集的文档化与验证框架，用于评估完备度 |
附录 A：核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 现行版本 | 2024.09 | 下载目录 | 官方页面 |
| 发布日期 | 2024 年 9 月 26 日 | CHANGELOG | 官方页面 |
| 首版日期 | 2022 年 10 月 28 日 | CHANGELOG | 官方页面 |
| 骨架基因组数 | 15,953 | 论文方法 | 论文 |
| 标记基因数 | 380 | 论文方法 | 论文 |
| 全部序列条数 | 23,467,470 | seqs.fna.gz 逐行计数 | 自算 |
| ASV 分类记录 | 23,450,268 | taxonomy.asv.tsv.gz 逐行计数 | 自算 |
| 骨架分类记录 | 337,506 | backbone.tax.qza 逐行计数 | 自算 |
| 物种名数 | 22,901 | 骨架分类表去重 | 自算 |
| 属名数 | 8,114 | 骨架分类表去重 | 自算 |
| 门数 | 132 | 骨架分类表去重 | 自算 |
| 数据文件数 | 25 | README 清单 | 官方页面 |
| 论文报告末端数 | 21,074,442 | 论文摘要 | 论文 |
| 物种末端基因组覆盖 | 46.5% | 论文结果 | 论文 |
| 许可 | BSD-3-Clause | 00LICENSE | 官方页面 |
| 论文 | Nat Biotechnol 42: 715–718 | 官网引用块 | 官方页面 |
附录 B：数字的来源分层
| 层级 | 内容 | 采信方式 |
|---|---|---|
| 官方页面 | 版本号、日期、文件清单、许可、变更说明 | 直接采用 |
| 自算 | 序列条数、分类记录数、各层类元数 | 用公开脚本逐行计数，可复现 |
| 论文 | 骨架规模、标记基因数、末端总数、覆盖比例、一致性相关系数 | 作为背景与佐证，与页面口径冲突时以页面为准 |
| 未核实 | 单个文件的精确字节数、全树拓扑的实际节点数、逐类群的片段分布 | 标注为未核实，不写成结论 |
自算部分与论文数字存在正常差异：论文的末端数取自投稿时的构建，2024.09 又追加了两百余万条片段，所以现行版的序列数高于论文值。两者不是矛盾，是时点不同。
附录 C：完整参考文献
- McDonald D, Jiang Y, Balaban M, 等. Greengenes2 unifies microbial data in a single reference tree. Nature Biotechnology, 2024, 42: 715–718. doi:10.1038/s41587-023-01845-1
- McDonald D, 等. Greengenes2 官方发布说明：2024.09（2024 年 9 月 26 日），https://ftp.microbio.me/greengenes_release/current/00CHANGELOG
- Greengenes2 官方 README，https://ftp.microbio.me/greengenes_release/current/00README
- Greengenes2 数据处理仓库，https://github.com/biocore/greengenes2
- QIIME 2 插件 q2-greengenes2，https://github.com/biocore/q2-greengenes2
- Greengenes2 交互检索服务，http://greengenes2.ucsd.edu/
- Balaban M, 等. uDance：快速增量式系统发育放置. Bioinformatics, 2022.
- Jiang Y, 等. DEPP：基于深度学习的短读段放置. 2022.
- Parks DH, 等. GTDB：基因组分类数据库. Nucleic Acids Research, 2022.
- McDonald D, 等. Greengenes2 许可原文（BSD-3-Clause），https://ftp.microbio.me/greengenes_release/current/00LICENSE
- Gonzalez A, 等. Qiita：面向微生物组的元分析平台. Nature Methods, 2018.
附录 D：版本核对代码
import re, urllib.request
BASE = "https://ftp.microbio.me/greengenes_release/"
PAGE = BASE + "current/"
def fetch(url, limit=200000):
req = urllib.request.Request(url, headers={"User-Agent": "gg2-check/1.0"})
with urllib.request.urlopen(req, timeout=30) as r:
return r.read(limit).decode("utf-8", "ignore")
#-- 列出当前版本目录里的文件名，看版本号是否变过
html = fetch(PAGE)
names = sorted(set(re.findall(r"\d{4}\.\d{2}\.[A-Za-z0-9._-]+", html)))
print("files:", len(names))
for n in names[:8]:
print(" ", n)
#-- 读 CHANGELOG 的前若干行，确认最新一条的日期
log = fetch(PAGE + "00CHANGELOG")
print(log[:400])
这段脚本只负责告诉目录有没有变，不判断变化是否合理。版本是否可信，仍以 CHANGELOG 与 README 的叙述为准。
附录 E：如果只记五件事
| 序号 | 要记住的事 |
|---|---|
| 1 | 主产品是一棵树，不是一份序列集；判断用得对不对，看有没有真的用上那棵树 |
| 2 | 与旧版 Greengenes 只有名字的关系，编号与命名全部不通用，迁移只能重跑 |
| 3 | 只能分类树上已有的序列，分不上就是未收录，不是低置信度 |
| 4 | 与 SILVA 分工：SILVA 管比对与近似，Greengenes2 管跨组学对齐 |
| 5 | 锁版本号：2024.09 换了 GTDB 220，门名与属边界都改过 |
编辑说明
事实基础以 Greengenes2 官方 FTP 的 00README、00CHANGELOG、00LICENSE 与 2024.09 目录清单为主，辅以 2023 年 Nature Biotechnology 论文摘要与两个 GitHub 仓库的说明文档。核验时间为 2026 年 10 月 29 日。
两处口径差异在此说明。其一，论文报告的全树末端数为 21,074,442，而 2024.09 目录里的序列文件实际有 23,467,470 条，差值来自 2024 年版追加放置的片段，本词条同时列出两个数字并注明时点。其二，官网首页的引用块写作 2024 年卷期，论文在线发表时间为 2023 年 7 月，两个日期都正确，分别对应见刊与上线。
未覆盖的内容包括：全树拓扑的实际节点数与深度分布、逐类群的片段密度、各文件解压后的精确体积、朴素贝叶斯模型的分类准确率。这些要么需要下载并解析数 GB 的树文件，要么属于拿到数据后自行评估的范畴，写在这里不增加判断力。
分类学命名以 GTDB 为准，本词条不做独立命名判断。旧版 Greengenes 的停更时间依据 FTP 目录时间戳，未追溯到当年的官方公告。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- uhgg — 共享标签：基因组学与多组学 / 微生物组 / 测序数据 / 变异与注释
- silva — 共享标签：基因组学与多组学 / 微生物组 / 测序数据 / 变异与注释
- gtdb — 共享标签：基因组学与多组学 / 微生物组 / 测序数据 / 变异与注释
- hmp — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- mgnify — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- curatedmetagenomicdata — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- qiita — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
- dbcan-hgm — 共享标签：基因组学与多组学 / 微生物组 / 变异与注释
- dbsnp — 共享标签：基因组学与多组学 / 测序数据 / 变异与注释
- ensembl — 共享标签：基因组学与多组学 / 测序数据 / 变异与注释
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
