4. Centrifuge数据库构建：索引方法、计算资源需求归纳总结

说实话，数据库构建这件事，往往是宏基因组分析里最容易被低估的环节。很多人上来就想着怎么把分类器跑快，结果建库这一步就踩了坑。Centrifuge 用的是 FM-index，跟 Kraken2 那个基于 exact k-mer 匹配的思路完全不一样。我在项目中遇到过几次建库卡住的情况，后来发现多半是资源没给够，或者索引参数没调对。

这一节，我就把 Centrifuge 建库的核心方法、索引原理、以及实际落地时的计算资源需求，掰开了讲清楚。

4.1 索引方法：FM-index 与原生 BWT 的差异

Centrifuge 的索引底子是 Burrows-Wheeler Transform（BWT），但它不是像 Bowtie2、BWA 那样直接对单个基因组做 BWT。它做的是 多个基因组的联合 BWT，也叫 FM-index。说白了，就是把所有参考序列拼成一条超长的字符串，然后在这个字符串上建立后缀数组和 BWT 索引。

为什么会这样设计？

因为宏基因组数据库动不动几百个物种，如果每个物种单独建索引，查询时挨个比对，那速度根本没法看。Centrifuge 把参考基因组串在一起，构建一个统一索引，查询时只需要在索引里走一遍就能同时比对所有物种。我个人的习惯是：先确认参考基因组总数是否超过 1,000 个，一旦超过，普通 BWT 索引就需要改为更紧凑的分块策略。

下表总结了 Centrifuge 索引与传统 BWT 索引的关键区别：

4.2 建库流程：从参考基因组到索引文件

Centrifuge 的建库工具叫 centrifuge-build，它跟 Bowtie2 的 bowtie2-build 长得很像，但参数完全不同。我最初用的时候，没注意 --conversion-table 这个选项，结果索引建完，分类结果里物种 ID 全是乱的 —— 嗯，那是一个深夜的教训。

规范的建库命令长这样：

centrifuge-build -p 16 \
  --conversion-table seqid2taxid.map \
  --taxonomy-tree nodes.dmp \
  --name-table names.dmp \
  reference_1.fa reference_2.fa ... reference_n.fa \
  centrifuge_db

参数说明：

• -p：线程数，建议不超过物理核心数
• --conversion-table：序列 ID 到 taxID 的映射文件，格式是 序列ID<TAB>taxID
• --taxonomy-tree：NCBI taxonomy 的 nodes.dmp
• --name-table：names.dmp，用于输出时显示物种名称
• 输入文件：支持多个 FASTA，也可以直接传以逗号分隔列表
• 输出前缀：指定索引名称，这里就是 centrifuge_db

建库完成后会生成多个索引文件：

centrifuge_db.1.cf
centrifuge_db.2.cf
centrifuge_db.3.cf
...
centrifuge_db.cfr
centrifuge_db.cfs

其中 .cf 是主索引分片，.cfr 是反向索引，.cfs 是统计信息。这些文件一旦生成就不能改名，否则 centrifuge 会找不到索引报错。

4.3 计算资源需求归纳

这部分我用一个表格来呈现，我实测过几个不同规模的数据库，数据比较真实：

注意这些数据是在机械硬盘上测的。如果你的服务器用 NVMe SSD，建库时间能再缩短 20–30%，但内存是硬瓶颈。我个人不太建议在内存少于 64 GB 的机器上建超过 50 Gb 的库，否则 centrifuge-build 会疯狂写 swap，你想想看，建库时间从几小时变成几天，完全不划算。

4.4 核心流程：从 FASTA 到索引的完整链路

下面这张 SVG 图把上面讲的流程串了起来，也是我每次给团队成员讲解时必画的一张图：

4.5 索引的压缩与分块策略

按我个人的经验，Centrifuge 建库时最耗内存的环节是 后缀数组排序。对于 50 Gb 的参考数据，SA 需要约 200 GB 的临时内存（因为每个碱基 4 字节，加上辅助结构）。为了缓解这个压力，Centrifuge 做了两件事：

1. 自动分块：当总输入超过某个阈值时，会拆成多个 .cf 分片，每个分片单独构建索引，查询时再合并结果。分片大小可在 --chunksize 参数中控制，默认是 500 MB。
2. 压缩 BWT：索引文件采用 run-length encoding 压缩，磁盘占用比原始 SA 小很多。这也是为什么 50 Gb 的 FASTA 建完后只有约 40 GB 的索引。

这里有个坑：分片数太多（比如超过 20 个），查询时会频繁切换文件句柄，IO 反而会成为瓶颈。我建议根据你的物理内存来反推分片大小：内存 64 GB 时，分片大小设 1 GB；内存 128 GB 时，分片大小设 2 GB。这样既不让内存爆掉，又能控制分片数量在个位数。

# 使用 --chunksize 指定分片大小（单位 MB）
centrifuge-build -p 16 --chunksize 1024 --conversion-table seqid2taxid.map \
  --taxonomy-tree nodes.dmp --name-table names.dmp \
  refs.fa centrifuge_db