Kraken2 简介与核心原理

讲 MetaPhlAn 之前，我得先聊聊 Kraken2。这两个工具虽然都做微生物分类，但路子完全不一样。我最早接触 Kraken2 是在一次肠道菌群项目里，当时实验室急着要结果，MetaPhlAn 跑起来太慢，有人推荐试试 Kraken2。嗯，这一试就让我记住了它——快，是真的快，但坑也不少。

说白了，Kraken2 是一个基于 k-mer 精确匹配 的微生物分类工具。它不依赖标记基因，也不做组装，而是直接把测序 reads 切成小片段，去一个预先建好的基因组数据库里比对。匹配上了，就直接给分类学标签。匹配不上？那就扔进 unclassified 里。

一句话概括：Kraken2 的核心哲学是「用空间换时间」——把参考基因组的 k-mer 索引提前建好，分类时只需要查表，不需要实时比对。

核心原理：k-mer 分割 + LCA 分配

Kraken2 的工作流程可以拆成三步。每一步我都踩过坑，咱们一个一个说。

  1. k-mer 分割：把每条 reads 切成固定长度的短串，默认 k=35。这个长度是关键——太短了特异性不够，太长了索引会大得离谱。
  2. 哈希表查找：每个 k-mer 去数据库里查，看它出现在哪些基因组里。Kraken2 用的是一种改进的哈希表，支持快速精确匹配。
  3. LCA 分配：如果一个 k-mer 同时匹配多个物种，Kraken2 会沿着分类树往上找，取最低共同祖先（Lowest Common Ancestor, LCA）作为这个 k-mer 的分类归属。

你想想看，这里有个很微妙的问题：一条 reads 上几十个 k-mer，每个都可能指向不同的分类节点。Kraken2 怎么决定最终标签？它内部做了一个「赢家通吃」——谁匹配的 k-mer 最多，谁就是这条 reads 的分类来源。如果打成平手，那就往父节点上归。

关键指标：Kraken2 的分类置信度取决于「覆盖分数」（covered fraction），即匹配上的 k-mer 数占该 reads 总 k-mer 数的比例。我一般在项目中要求至少 0.5 以上才接受分类结果，否则标记为 unclassified。

数据库构建：这是最磨人的一步

Kraken2 的数据库构建，说白了就是把参考基因组里所有 k-mer 都提取出来，建一个巨大的哈希表。我刚开始用的时候以为跟 BLAST 建库差不多，结果发现完全不是一回事。

# Kraken2 数据库构建命令示例
kraken2-build --download-taxonomy --db mydb
kraken2-build --download-library bacteria --db mydb
kraken2-build --build --db mydb --threads 16

这个流程走下来，有几个现实问题，我一个个说：

  • 存储爆炸：一个标准细菌数据库（含 RefSeq 完整基因组）建下来，索引文件超过 100 GB。我当时在服务器上建库，磁盘直接报警。
  • 内存需求高：Kraken2 的哈希表要全部加载到内存里。标准细菌库大概需要 80-100 GB 内存。你如果没有大内存机器，跑起来会很痛苦。
  • 更新麻烦：新的基因组不断发表，你得定期重建数据库。我见过有人直接下载官方预建库，结果发现里面缺失了最近两年的新菌种。
避坑提醒：我曾经在生产环境中踩过一个坑——用了官方默认的标准库，结果一个已知的肺炎克雷伯菌株完全没被识别，因为那个库的 RefSeq 版本落后了半年。从那以后，我养成了每次建库前先查看 kraken2-inspect 的输出，确认库的覆盖范围。

分类流程：一条 reads 的旅程

为了帮你直观理解 Kraken2 的处理逻辑，我画了一张流程图。这张图把上一节的文字版变成了你能一眼看懂的路径。

Kraken2 核心分类流程 输入测序 Reads k-mer 分割（默认 k=35） 哈希表精确匹配查找 LCA 最低共同祖先分配 分类结果 + 置信度评分 每个 k-mer 独立查表，不走序列比对 内存占用大，但速度极快 一条 reads 的最终标签由 k-mer 投票最多的分类节点决定

注意看，整个流程里没有「比对」这一步。Kraken2 用的是哈希精确匹配，不是 BLAST 那种局部比对。这个设计决策直接决定了它的性能特征——快，但不擅长处理变异和误差。

Kraken2 的特点与局限

我用过 Kraken2 做过的项目大概有七八个，从肠道菌群到环境宏基因组都试过。下面这张表格是我个人的经验总结，不一定跟官方文档一字不差，但都是实际跑出来的体感。

维度 Kraken2 表现 我的经验
分类速度 极快（百万 reads / 分钟） 比 MetaPhlAn 快 10-20 倍，适合大批量样本
内存占用 高（标准库 80-100 GB） 我曾在 128 GB 机器上跑过，勉强够用
数据库大小 大（索引 > 100 GB） 建库一次够用半年，但更新麻烦
分类分辨率 物种级（部分菌株级） 依赖数据库完整性，易漏检新菌种
对变异容忍度 低（精确匹配） 测序错误率高时，分类率明显下降
相对丰度估算 有（Bracken 扩展） Kraken2 本身只做分类，丰度靠 Bracken
一个常见误解：很多人以为 Kraken2 能直接给出丰度。实际上它输出的是「该 reads 被分到哪个物种」，不是丰度。你要做丰度分析，得额外跑 Bracken 或者自己算比例。我曾经在一个报告中直接用了 Kraken2 的 counts 比例当丰度，被 reviewer 怼了回来——因为不同物种的基因组大小不同，直接数 reads 个数会引入偏差。

与 MetaPhlAn 的定位差异

你可能会问：既然 Kraken2 这么快，为什么还要用 MetaPhlAn？这是个好问题。我个人的理解是：Kraken2 适合「广撒网」式的快速筛查，MetaPhlAn 适合「精准定位」式的深度分析。

Kraken2 的数据库包含几千个物种的完整基因组，覆盖广但深度浅。MetaPhlAn 只盯着几百个标记基因，覆盖窄但精度高。举个例子：

  • 如果你想知道「这个样本里有没有沙门氏菌」，Kraken2 一分钟就能给出答案。
  • 如果你想「定量比较两组样本中沙门氏菌的相对丰度差异」，MetaPhlAn 的结果更可靠。

我在实际项目中通常这么做：先用 Kraken2 跑一遍，看整体微生物组成的大致轮廓。然后针对感兴趣的目标物种，再用 MetaPhlAn 做精细定量。这套组合拳帮我躲过不少坑。

我的建议：不要把 Kraken2 和 MetaPhlAn 看成对手，它们更像是「侦察兵」和「狙击手」。先用侦察兵快速摸清战场，再派狙击手定点清除。我目前在三个正式项目里都是这套策略，还没出过问题。

使用场景速查

为了帮你快速判断什么时候该用 Kraken2，我整理了一个 checklist：

  • ✅ 样本量大（>50 个），需要快速出结果 → 选 Kraken2
  • ✅ 关注已知病原体的有无，不要求高精度丰度 → 选 Kraken2
  • ✅ 计算资源充足（内存 > 80 GB）→ 选 Kraken2
  • ❌ 需要菌株级分辨率 → 慎用 Kraken2（数据库通常不支持）
  • ❌ 测序质量差，错误率高 → 慎用 Kraken2（精确匹配吃亏）
  • ❌ 新菌种占比高的环境样本 → 不推荐 Kraken2（容易漏检）
← 上一章 📖 返回目录 下一章 →