贻鉴遗传全外显子开源分析平台发布
2025 年底,我在年终总结里立了个 Flag:用 2026 年业余时间做出一套全外显子分析平台和一套肿瘤分析平台。
当时规划得很满,想搞工业化、做云原生。但真正做起来才发现,业余时间根本不够两头烧,再加上算力波动和合规问题,中间推翻重来了好几次,最后只能一路做减法。
今天,这个做了一整年的项目总算是发布了——贻鉴(YiJian)。
这是一套专为实验室内网自部署设计的遗传全外显子(WES)分析平台,代码完全开源。样本登记、数据入库、任务调度、变异过滤、IGV 核对、AI 辅助解读到报告生成,都在自己的服务器上完成,数据不出内网。
- 部署文档:https://www.schema-bio.com/en/docs/yijian/deployment
- 使用文档:https://www.schema-bio.com/en/docs/yijian/user-guide
这一年,我都做了哪些减法?
回看这一年的开发进度,中间有几次关键的收缩和转向:
1. 砍掉肿瘤平台,把精力收敛到遗传外显子
立项时我设想的是“双轮驱动”:既做遗传全外,又做实体瘤大 Panel(知几)。但在实际推进中,肿瘤体细胞分析的复杂度很快露出了獠牙——各大机构的 Panel 过于碎片化,目标区域、捕获探针、测序深度各不相同,上游数据波动的剧烈程度远超预期。 在业余时间极度有限的情况下,试图同时维护两套重度系统,结果大概率是两头不讨好。今年 6 月,我果断做出了破坏性调整:砍掉肿瘤 SaaS 计划,不再分心,将所有算力和时间收拢到“遗传全外显子”这一条线上,专注把一个标准化的品类从头到尾彻底做透。
2. 放弃 GPU 幻觉,拥抱 CPU 的确定性
在早期的性能测试中,我曾迷恋过 GPU 加速(Parabricks),单样本 10GB WES 压缩到 30 分钟确实很诱人。但在云端实例的实际监控中,我发现广州、北京等节点的 GPU 竞价资源极不稳定,常常大面积缺货。 对实际使用来说,能明确知道多久跑完,比碰运气抢卡重要得多。4 月份我决定彻底放弃 GPU 方案,转向纯 CPU 架构。经过多线程和 IO 优化,在标准 32C 实例上跑满一条 WES 的耗时稳定可控。
3. 告别 Nextflow 的灵活,拥抱 WDL 的“所见即所得”
原本流程引擎定的是 Nextflow,但其基于 Groovy 的 DSL2 随着版本迭代带来了过多的语法糖与隐式机制,调试复杂流程的心智负担极大。后来我全面迁移到了 WDL(Workflow Description Language),声明式的结构让流程逻辑回归清晰直白。 针对中小规模部署,官方的 Cromwell 太过庞大笨重,我选择了轻量的 miniwdl。面对 miniwdl 没有现成 Web 管理接口的问题,我采用“控制反转”思路手搓了一套 Server + Agent 架构——计算节点上的探针(Sepiida)主动向调度中心(Octopus)心跳上报状态,既不需要暴露计算节点端口,又能实时掌握任务动态。
4. 合规带来的“逆向开源”
一般商业系统都是付费版功能最全,开源版做功能阉割。但在人类遗传数据合规的要求下,情况反过来了。 为了合规,商业 SaaS 版必须做成“阅后即焚、不存数据、不签发临床报告”的纯计算管道;反而在本地自部署的开源版本中,因为数据完全属于用户自己、不出内网,报告生成系统、家系(Trio)联动分析、变异详情卡片等完整能力,全留在了开源代码里。
开源了什么
贻鉴平台采用完全解耦的模块化设计,每一个核心组件都在 GitHub 上开源:
| 模块 | 仓库 | 许可协议 | 说明 |
|---|---|---|---|
| 前端界面 | YiJian | Apache-2.0 | 现代 Web 前端,基于 Next.js 与现代化设计规范构建 |
| 后端调度 | Octopus | MIT | 调度中枢大脑,负责任务状态机、用户权限与数据流转 |
| 生信流程 | schema-germline | MIT | 基于 WDL 的高标准遗传全外分析流水线 |
| 状态采集 | Sepiida | MIT | 计算节点守护探针,定时采集 miniwdl 运行指标并主动上报 |
| AI 辅助 | SepiLens | Apache-2.0 | 面向变异位点证据检索与 ACMG 分级评估的 AI 辅助插件 |
在运行架构上,前端、数据库与支撑服务封装在轻量 Docker 容器内运行;Octopus 和 MiniWDL 直接驻留在宿主机上负责全局调度,具体的计算步骤按需拉取 GATK、DeepVariant、VEP 等标准容器镜像。这种模式彻底避开了 Docker-in-Docker 脆弱的文件路径与挂载问题,同时也为未来平滑对接 HPC 集群(如 Slurm / LSF)预留了充足空间。
一条样本的完整旅程
贻鉴的操作逻辑从临床一线的使用直觉出发,全中文界面,使用说明可参考 用户指南。
1. 样本登记与数据入库
在录入样本元信息后,系统分配唯一内部编号。测序数据(FASTQ)支持通过浏览器直接上传;对于 GB 级的大体量数据,更推荐在数据中心直接登记挂载盘的绝对路径,后台自动执行秒级软链接或拷贝。 当测序数据还在传输过程中时,你就可以提前创建分析任务,系统侦测到数据就位后会自动触发执行流水线。



2. 多类型变异分类判读
任务完成后,系统提供结构化的变异汇总看板。除了常规的 SNP / InDel 之外,平台原生支持了 区域/外显子级 CNV、动态突变(STR)、移动元件插入(MEI)、线粒体变异、单亲二倍体(UPD) 以及 纯合片段(ROH) 的检出与分类分栏展示。你可以挂载靶向基因列表(Gene List)进行极速筛选过滤。

3. 嵌入式 IGV Reads 核对
做生信分析的人都知道,“没看过 BAM 的位点都是虚的”。在变异列表中点击任一位点坐标,页面右侧或弹窗可一键拉起内嵌的 IGV 视图,直观核对局部比对深度、错配情况以及剪切信号,省去了在本地 IGV 里来回导入几十 GB BAM 文件的繁琐。

4. 报告解耦与家系联动
贻鉴在设计之初就坚持报告不写死在平台内核中。流程中心提供了可插拔的报告接口配置,解读完成后可调取外部独立服务渲染个性化报告。同时支持在页面内一键将核心结果、注释表格和质控指标打成轻量压缩包下载。 此外,家系分析(Trio / Duo)已深度整合进同一套体系:分别登记先证者与父母亲样本后,在家系管理中建立亲缘映射,即可一键投递家系联合分析流程。

(注:系统内置的 CNV 基线基于 GIAB 公共数据集构建,不同实验室自身的探针捕获和测序特征差异较大,正式用于内部生产前建议按照文档制作专属的 Baseline。)
如何在自己的服务器部署
建议配置:一台 Linux 实体机或高性能虚拟机,推荐 32 核 CPU、64 GB 内存 起步,并配备高速本地 NVMe SSD 数据盘。
平台提供了开箱即用的自动化部署脚本:
# 1. 克隆发布分支
git clone --depth 1 --branch v0.3.0 https://github.com/SchemaBio/Octopus.git
cd Octopus/deploy
# 2. 初始化环境配置
bash ./deploy.sh init
init 会生成初始 .env 配置文件与安全凭证。将配置文件中的 DATA_ROOT 指向你的大容量数据盘(如 /mnt/data),随后执行环境检测与拉起:
# 3. 依赖巡检与容器安装
bash ./deploy.sh check
bash ./deploy.sh install
服务启动后,使用浏览器访问 http://localhost:3000 即可进入登录界面。通过执行 bash ./deploy.sh credentials 可打印初始管理员账户与口令,首次登录后请立即修改密码。
部署小贴士:
- WSL2 适合作为本地功能体验或界面预览,但不建议用于生产分析。Windows 宿主与 WSL2 之间的跨文件系统小文件 IO 性能损耗严重,容易触发文件锁超时。
- 由于涉及前后端容器、Python 依赖库、生信参考基因组与 VEP 注释库的挂载配置,强烈建议把部署文档链接丢给你常用的终端 AI Agent(如 Claude Code、Cursor、Windsurf 等),授权它在测试机上协助完成拉取与环境配置,排查依赖报错会极其轻松。
使用边界与免责声明
- 软件性质:贻鉴(YiJian)为纯粹的生物信息计算与数据分析工具,代码基于开源协议公开发布。
- 职责划分:部署方与使用者须完全自主决定使用场景、数据保管周期以及分析结果用途,并对测序数据的合法授权、数据安全隐私、伦理合规复核承担全部责任。
- 科研定位:本软件输出的所有分析报表、位点注释与 AI 评估参考,均不构成直接的临床医疗诊断结论,亦不得替代持牌专业医师的独立医学判断。
写在最后
从 2025 年底立项到现在,整整折腾了一年。
虽然当初吹下的“外显子 + 肿瘤”双平台最后只兑现了外显子这一套,但至少把它完整做完并且开源放出来了。从前端、调度、流程到部署脚本,每块都能跑通。
如果你手头有闲置机器或者有 WES 分析需求,欢迎部署跑跑看。遇到 Bug 或者有改进建议,直接在 GitHub 提 Issue。