1. 宏基因组分类学概述：Kraken2与Centrifuge简介
宏基因组测序，说白了就是把环境样本（比如肠道菌群、土壤、海水）里所有微生物的 DNA 混在一起读一遍。
接着问题就来了——我们怎么从几千万条短读段里，快速搞清楚「这里面到底有哪些物种」？这就是宏基因组物种分类学的核心任务。
我刚入行那会儿，用的还是基于 BLAST 逐条比对的老路子。跑一个中等规模的肠道菌群样本，能等好几天。直到后来接触了基于 k-mer 的方法——Kraken2 和 Centrifuge，我才真正觉得这件事可以被放到生产线上跑。
一句话总结：Kraken2 和 Centrifuge 是目前最主流的两个基于 k-mer 索引 + 精确比对 的快速分类工具。
1.1 宏基因组物种分类到底在干什么？
我给你拆解一下整个过程。你拿到的数据通常是这样的：
@SEQ_ID
GATCTCAGAGATTCGAGAGAAGGTCAGAGATTCGCTCAGAGATTCGAGATTC
+
IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
核心步骤只有三步：
- 建库：把参考基因组（细菌、真菌、病毒等）拆成短片段存进索引。
- 比对：把测序读段跟索引里的 k-mer 精确匹配。
- 分类：统计每个读段命中了哪些物种，输出一个物种丰度表。
听起来很简单是吗？嗯，真正的魔鬼在索引结构里。Kraken2 和 Centrifuge 的索引设计思路截然不同，这也是为什么我建议你两个都要了解。
1.2 Kraken2 是什么？
Kraken2 用了一个非常直接的办法：把所有参考基因组里所有长度为 k 的子串（k-mer）都存下来，然后给每个 k-mer 打上它所属的「最低公共祖先」标签（LCA）。
查询一条读段的时候，Kraken2 会挨个切割出 k-mer，在哈希表里查它的 LCA，然后取所有命中 k-mer 里「最具体的那个分类节点」作为最终分类。
我在项目中遇到过这种情况：一个读段同时命中了多个近缘菌株的 k-mer，Kraken2 会自动把它们归到「属」这个层级，而不是随便挑一个种名。这种保守策略虽然损失了一些分辨率，但假阳性率非常低。
建库命令长这样（以标准库为例）：
kraken2-build --standard --db kraken2_db
kraken2-build --download-taxonomy --db kraken2_db
kraken2-build --build --db kraken2_db
跑一条读段：
kraken2 --db kraken2_db --threads 8 --report report.txt sample.fastq
我的经验：Kraken2 的建库时间其实挺长的（全库可能需要几十个小时），但建完之后查询极快，每秒能处理百万条读段。非常适合做大样本的批量筛查。
1.3 Centrifuge 又是什么？
Centrifuge 的思路更巧妙一些。它不存所有 k-mer，而是用 FM-index（一种基于 BWT 的压缩全文本索引） 来存储参考基因组。
这样做的好处是什么？简单说，索引文件体积小太多了。
同样是全库，Kraken2 的索引可能动辄 100 G，而 Centrifuge 可以压缩到 10 G 左右。我印象很深——以前在内存只有 64 G 的服务器上，Kraken2 跑全库需要开 swap，换成 Centrifuge 就能流畅跑起来。
Centrifuge 的分类是通过对读段做「精确比对 + 最小唯一子串」的查找来实现的。它会报出一个置信度比较高的分类结果，并且给出每个分类的 p-value。这个跟我之前用 BLAST 的体验很像，Centrifuge 天生就能处理多对多映射的歧义问题。
建库命令示例：
centrifuge-download -o library -m -d "bacteria,archaea,viral" refseq
centrifuge-build -p 8 --conversion-table seqid2taxid.map \
--taxonomy-tree nodes.dmp --name-table names.dmp \
library/all_seqs.fna centrifuge_db
分类命令：
centrifuge -x centrifuge_db -U sample.fastq -S result.tsv --report report.txt
注意：Centrifuge 的 FM-index 对短读段（比如 100 bp）的敏感度略低于 Kraken2，我曾经就因为读段长度太短导致低丰度物种漏检。建议读段长度 ≥ 150 bp 时再用它做全库搜索。
1.4 两个工具的核心差异
我把两者的关键区别整理成一张表，方便你对照：
| 对比维度 | Kraken2 | Centrifuge |
|---|---|---|
| 算法基础 | k-mer 哈希表 + LCA 映射 | FM-index（BWT） |
| 建库耗时 | 长（几十小时） | 短（几小时） |
| 索引大小 | 大（全库 100 G+） | 小（全库 10 G 左右） |
| 查询速度 | 极快（M reads/min） | 快（接近 Kraken2） |
| 查询精度 | 高（但低层级保守） | 高（区分度好） |
| 对短读段友好度 | 优（50 bp 也能用） | 良（建议 ≥ 150 bp） |
| 软件维护活跃度 | 活跃（持续更新） | 维护较少（近年更新慢） |
| 新物种/变体检测 | 较弱（过度依赖库） | 较强（FM-index 可查询未建库片段） |
1.5 用一张图理解流程差异
下面是我画的一张流程图，把两个工具的流程差异直接放在一起对比。
1.6 我什么时候选 Kraken2，什么时候选 Centrifuge？
说实话，没有哪个工具是绝对完美的。我个人的选择逻辑是这样：
- 优先用 Kraken2：测序读段长度在 100 bp 以下、样本量很大（几百个）、服务器内存足够（≥ 128 G）。它的精准度和速度都是顶级的。
- 考虑 Centrifuge：读段质量高（≥ 150 bp）、内存受限、需要更好的新物种检测能力。FM-index 的索引压缩效果非常明显。
- 两者都跑：正式分析前，用小样本跑两个工具做交叉验证。我之前在肠道菌群项目中同时跑两个，发现 Kraken2 漏检的某些低丰度种 在 Centrifuge 结果里有微弱信号，反过来也成立。
我个人建议：把这个章节作为你入门的第一步——先去官方的 GitHub 分别装好 Kraken2 v2.1.3+ 和 Centrifuge v1.0.4+，然后用一个几万条读段的小测试文件跑一遍。亲眼看到输出表格落地，你才会有真实感。
好了，这一章就到这里。工具选型的基础我讲清楚了，下章大家将会深入技术细节——索引怎么建，参数怎么调，以及我最头疼的那些「坑」。