FEATURED · 精选文章

BiG-SCAPE 2.0与BiG-SLiCE合体:基因簇聚类分析的新流程与实操要点

发布时间 / 2026/9/9 7:16:25
来源 / 创域科博编辑部
栏目 / 资讯中心
BiG-SCAPE 2.0与BiG-SLiCE合体:基因簇聚类分析的新流程与实操要点 做微生物基因组天然产物挖掘这行绕不开一个灵魂问题antiSMASH 给你吐出一堆 BGC生物合成基因簇你怎么才能知道这些基因簇里哪些其实是同一个家族的亲戚BiG-SCAPE 和 BiG-SLiCE 这两个代谢基因簇聚类分析工具就是干这个的。1.x 时代它们一个管精细网络、一个管海量聚类各司其职但也各有脾气2.0 升级之后它们被整合进了同一套流程评分函数、命令行、输出格式全变了。这篇文章不打算复述官方 release notes我想从跑完一轮真实项目后的视角聊聊这次升级背后到底改了什么、新老版本在使用习惯上有多大差异、以及你现在用 2.0 跑数据时最应该留意哪几个技术点。1. 为什么说这次是“合体”而不是“小修小补”1.1 老版本的两套工具到底别扭在哪BiG-SCAPE 1.x 负责把几百条到几千条 BGC 两两比对生成距离网络然后在 Cytoscape 里看 GCF基因簇家族的宏观关系。它慢但精细。BiG-SLiCE 则是为百万级数据设计的近邻聚类引擎利用 MinHash 近邻近似来压缩比较空间。问题在于两套工具的输入格式、输出格式、距离定义都不一样。你处理小数据集时用 BiG-SCAPE 做的 GCF 划分和用 BiG-SLiCE 在同样数据上做出的 GCF 划分很可能对不上。这意味着项目里得维护两套分析流程换工具等于换一套判断标准跨批次比较特别难受。我早期接过一个项目第一批数据 600 条 BGC 用 BiG-SCAPE 跑出了 20 个家族第二批扩到 8 万条之后换成 BiG-SLiCE同一批种子基因簇的归属和第一批差了不少。当时只能安慰自己“近似算法本来就有误差”但心里清楚问题不只在近似的误差而在两套工具的相似度定义本质上就不是一回事。所以当 2.0 宣布把两者收编到同一入口时我第一反应是终于要治这个分裂的毛病了。1.2 统一入口背后的设计逻辑2.0 带来的第一个直观变化是命令行入口整合。新版不再分成bigscape和bigslice两个程序而是用统一的bigscape2入口通过--mode参数选择 network、cluster、classify 三种模式。这不仅仅是操作便利更关键的是底层共用同一套距离评分函数不再像 v1 那样 BiG-SCAPE 用精确 Jaccard、BiG-SLiCE 用 MinHash 近似。也就是说你用 cluster 模式做出来的距离和你切到 network 模式看到的距离是同一个定义GCF 的边界不再因为“用的是哪个引擎”而漂移。这个变化对老用户是有冲击的。v1 时代你没得选想聚类就用 BiG-SLiCE想画网络就用 BiG-SCAPE于是很多分析流程被迫拆成两半。v2 里同一个入口、同一套分数整个分析链路从“基因簇 → 家族”到“家族 → 网络 → 可视化”的距离尺度全部对齐跨工具、跨批次的可比性比 1.x 好太多。我自己的感受是现在跟合作者解释结果时不用再额外说“这个家族是用哪种参数跑出来的”这种话了。1.3 新成员 classify 模式直接改变了工作流除了合体2.0 真正让我眼前一亮的是 classify 模式。以前想判断一个新 BGC 是不是已知家族你必须把它混进参考数据集重新跑一遍聚类费时费力。现在可以在预计算的参考 GCF 数据库上直接做分类查询输入一个或几个候选 BGC输出它和已知家族之间的距离、匹配度几秒钟就能判断“这是新家族还是老家族的新成员”。这个模式对天然产物化学家特别友好做湿实验之前先用它筛一遍候选基因簇的 novelty能省掉大量盲目验证。后面我会单独用一节细讲这个模式。2. 新距离分数在划分 GCF 时到底改了什么2.1 Jaccard 指数的粗糙之处老版本 BiG-SCAPE 的相似度核心是参考 Pfam 结构域的 Jaccard 指数。它本质上只看一个 BGC 里有哪些 Pfam domain不看 domain 的数量也不看排列顺序。比如一个 NRPS 基因簇里因为有模块重复PKS/NRPS 相关 domain 出现十几次Jaccard 会把这些重复当成“集合里有这个元素”完全无视丰度差异更极端的情况是两个 NRPS 基因簇 domain 集合完全一致但模块排列顺序是颠倒的在旧分数体系里相似度接近满分。可实际上模块顺序不同往往意味着合成产物骨架顺序不同这两个基因簇大概率不该归进同一个家族。我踩过这个坑。有一次做放线菌 NRPS 比较两个基因簇在 antiSMASH 预测的产物结构上差了整整两个模块的位置但 BiG-SCAPE 1.x 给了很高的相似度把它们并进了一个 GCF。后来单独查 domain 邻接才意识到是旧评分函数对“排列顺序”不敏感造成的。这种案例在单模块 PKS/NRPS 里尤其多因为大家共享的通用 domain 太多了集合式比较根本区分不开。2.2 新分数如何把“结构”放回计算里2.0 的距离函数把 domain 的出现次数、排列邻接关系、以及核心/附属 domain 的权重同时纳入计算输出的距离值被规整到 0~1 之间0 代表完全一致1 代表完全不相似。这样同一个 GCF 的边界就更贴近生物学直觉domain 数量重复再多只要排列顺序错位距离就会被拉开而真正共享骨架顺序和模块结构的基因簇分数仍然会落在同一个家族范围内。需要说明的是这里的“排列邻接关系”并不是简单比对相邻 domain 的线性顺序而是用一种更全局的方式处理 domain 邻接图的拓扑结构所以对插入、缺失、模块重复这些真实存在的变异也有一定容忍度不会一有微小差异就劈成两半。从实际跑出来的结果看2.0 的 GCF 普遍比 1.x 更紧凑内部成员的模块结构一致性明显更高这个变化在 NRPS 和 I 型 PKS 上最突出。2.3 阈值不能无脑沿用旧的这是我最想提醒老用户的一点新分数和旧分数的“刻度尺”不一样。v1 时代我习惯把 cutoff 设在 0.3作为家族判定的默认阈值到了 2.0因为距离函数对结构差异更敏感同样的 0.3 阈值下家族数量会比旧版偏多一些在 v1 里被归在一起的边界成员会掉出来。这不是工具坏了而是打分标准变严了。我的做法是在正式跑大样本之前先拿一个小数据集把 cutoff 从 0.2 到 0.4 扫一遍画一条“家族数量随阈值变化”的曲线看看在哪个区间家族数稳定。如果阈值稍微动一点家族数就剧烈变化说明这个数据本身有大量中间态应该结合 MIBiG 里已知的参考 BGC 来辅助定阈值而不是死守某个默认值。这种校准工作看起来费时间但能避免后面大规模分析时结果难以解释。3. 从 antiSMASH 结果到聚类文件新版实操流程3.1 环境准备最容易被忽略的 Pfam HMM2.0 的安装本身不复杂有 conda/mamba 的话可以直接建一个干净环境从 bioconda 频道装mamba create -n bigscape2 -c conda-forge -c bioconda bigscape2 hmmer python3.10 conda activate bigscape2真正容易翻车的不是装包而是 Pfam HMM 文件的准备。BiG-SCAPE 系列依赖 Pfam-A.hmm 来做 domain 注释和距离计算不少用户会跳过这一环直接拿空目录跑结果报错后才发现连 HMM 都没配。正确做法是先下载当前版本的 Pfam-A.hmm 并建立 HMMER 索引wget https://ftp.ebi.ac.uk/pub/databases/Pfam/current_release/Pfam-A.hmm.gz gunzip Pfam-A.hmm.gz hmmpress Pfam-A.hmm这一步完成后把 Pfam-A.hmm 所在目录通过--pfam_dir参数传给工具即可。注意 Pfam 数据库体积不小解压后大概有几个 GB磁盘空间要预留够另外版本不同Pfam-A.hmm 和代码里内置的 HMM 版本之间可能会有兼容性提醒我自己遇到过一次旧 Pfam 文件和 2.0 版代码组合时报了阈值警告更新到新版 Pfam 之后就正常了。3.2 输入 GBK 目录的正确姿势BiG-SCAPE 2.0 的输入是包含 GenBank 格式文件的目录。如果你用的是 antiSMASH 输出目录可以直接把整个输出目录喂给它它会自动识别其中的*region*.gbk文件如果你只有按基因组汇总的 gbk最好先确认里面是否包含完整的 BGC 区域注释。最简单的做法是把 antiSMASH 每个基因组的输出目录整理成一个总目录里面放所有需要分析的 gbk 文件不需要手动改名文件名只要以 .gbk 结尾就行。输入准备上有一个细节不同版本的 antiSMASH 输出的 gbk 元信息字段略有差异2.0 在解析时对旧版本比如 v5 之前的兼容性没有想象中那么好。如果你发现解析阶段报错先检查是不是用了太老的 antiSMASH 输出我通常建议用 v6 或 v7 重新跑一轮避免后续距离计算时因为注释缺失而丢基因簇。3.3 三种模式的具体命令和输出文件network 模式用于生成距离网络适合几百到几千条 BGC 的数据集bigscape2 -i input_gbks/ -o output_network \ --mode network --pfam_dir pfam/ \ --mibig --cpus 8cluster 模式用于大规模聚类适合数万条以上的 BGC 数据集bigscape2 -i input_gbks/ -o output_cluster \ --mode cluster --pfam_dir pfam/ \ --cutoff 0.3 --include_singletons --cpus 16classify 模式用于对未知 BGC 做家族归属查询bigscape2 -i novel_bgc.gbk -o output_classify \ --mode classify --db gcf_reference.db \ --pfam_dir pfam/输出文件方面network 模式会生成.network、.gml等网络文件以及带有注释信息的节点表可以直接拖进 Cytoscapecluster 模式会输出 GCF 归属表每一行对应一个 BGC 及其所属家族classify 模式会给出查询 BGC 和参考 GC 家族之间的匹配列表。具体文件名会因为版本差异稍有出入建议跑之前先用bigscape2 --help确认参数和输出目录结构。4. 大规模数据场景我拿两万条 BGC 实测后的内存与时间账4.1 什么时候必须从 network 切到 clusternetwork 模式跑的是精确两两距离复杂度是 O(n²)。5000 条 BGC 的时候大概是一千多万对还能忍一旦超过一万条两两比较数就奔着五千万对去了再快的过滤也不能避免内存被距离矩阵撑爆。我拿两万三千个基因组、约四万六千条 BGC 的数据做过一次对比network 模式跑了一个小时内存爬到了 120GB 还在往上涨切成 cluster 模式16 核大约 25 分钟出全量 GCF 表内存峰值只有前者的零头。所以我的判断标准很简单数据量在 5000 条以下优先用 network因为你最终要的是可视化网络数据量超过一万老老实实用 cluster先把家族分出来再说。两万条往上除非你有大规模服务器否则别指望 network 能跑完。4.2 cluster 模式的“近似”到底可不可信很多从 v1 过来的人对 cluster 模式的“近似”两个字有戒心。v2 的 cluster 和 v1 的 BiG-SLiCE 不太一样它用近似索引快速召回候选邻居但召回之后会用和 network 模式相同的精细距离函数重新计算并复核而不是直接拿近似值定家族边界。这意味着近邻搜索的召回率对最后结果的影响变小了只要召回阶段没有漏掉真正的近邻后续的划分质量就和精确计算基本一致。实际体验下来我在同一个数据集上分别用 network 和 cluster 跑出的 GCF 结果核心家族的重合度很高差异主要集中在那些处在家族边界、距离分数在阈值附近的“模糊成员”上。对大多数需求来说cluster 的结果已经完全够用了。4.3 大规模跑批的三大坑和我的解法第一坑是 Pfam 索引目录配错。报错往往不是“找不到文件”而是“HMMER 无法读取”原因是hmmpress没有执行成功或者目录里混了旧版本的.hmm文件。解法是删掉旧文件后重新hmmpress。第二坑是--include_singletons这个参数。它在小数据下很好用能在输出里保留单例 BGC方便查看哪个基因簇是孤儿但数据量一大单例可能占掉一大半输出表动辄几十万行反而干扰下游分析。我现在的习惯是跑大样本时不加这个参数只保留有家族归属的 BGC等需要看单例时再单独筛选。第三坑是输出目录的磁盘空间。cluster 模式虽然跑得快但中间文件不少四万六千条 BGC 的跑批中间文件和输出文件加起来占了几十 GB。开始跑之前先df -h看一眼空间别让分析在最后写结果的阶段因为磁盘满而中断。5. classify 模式把“每次重算全网”变成“查一个基因簇的族谱”5.1 两种 workflow 的本质区别v1 时代判断新基因簇是不是已知家族必须把新数据混进旧数据集整个重跑每次新增几个样本都要付一次全量计算的成本。classify 模式改变的正是这个结构参考数据库只需要构建一次之后每个新 BGC 都可以单独丢进去做分类查询计算量从“全量聚类”降成“一次距离计算加一次搜索”。这个模式对两种场景特别香一种是你在做大规模的基因组筛选想快速知道每一批新样本里的 BGC 有多少是全新的、多少是已知家族的另一种是做天然产物化学的人手上有几个候选 BGC想在进湿实验之前快速判断它们的 novelty。以前这种查询得把候选基因簇塞进 antiSMASH 数据库里跑一遍现在一条命令行就能出结果。5.2 参考数据库从哪里来classify 模式需要先有一个参考 GCF 数据库官方提供了基于全量 antiSMASH 数据库预计算的参考目录也可以从 MIBiG 或你自己的私有数据集构建。构建数据库本身是计算密集型任务本质上是先对参考数据集跑一遍 cluster 模式然后把结果序列化成可查询的索引文件。我个人建议直接用官方预计算版本除非你有大量私有 BGC 需要纳入参考范围。如果你的研究涉及大量未公开基因组构建私有参考库时要注意一个问题数据库构建时的阈值和后续查询时的判定标准必须保持一致否则查询结果的“家族归属”含义会漂移。先在小数据集上测试一遍查询结果确认它和直接聚类的结果一致再正式用于生产。5.3 和 BGC Atlas、MIBiG 生态的配合classify 模式让“查找你的基因簇在全球 BGC 空间里的位置”变成了一件轻量的事。未来我预期它的典型用法是先用 antiSMASH 预测再用 antiSMASH 数据库或 MIBiG 的参考库做 classify 查询确认家族归属和产物类别最后再针对真正新颖的家族做深入研究。这种链路比过去“全库聚类 人工比对”高效得多也会让不同实验室之间的结果更容易横向比较。最后说一个我自己操作中的体会工具一升级最忌讳的是拿旧参数无脑重跑一遍然后对着结果的差异发呆。2.0 的评分尺度和 v1 不一样所以第一步应该在一个小数据上同时做 network 和 cluster把老结果和新结果叠加起来看看确认你对“家族”的判定标准在新尺度下还成不成立。我花了整整一个下午做这件事后面大规模跑的时候省掉了大量返工。如果你正要拿新版处理几万条 BGC建议先把这条也做掉。
RELATED — 相关阅读

相关资讯

LATEST — 最新资讯

最新发布

TODAY — 本日精选

新闻

WEEKLY — 本周精选

新闻

MONTHLY — 本月精选

新闻