一、药物图谱概述
药物图谱到底是什么？
这个问题我被人问过很多次。说白了，它就是一个巨大的知识网络——把药物、疾病、基因、靶点、副作用这些生物医学数据串起来。你可以把它看成一张「超级关系图」。
举个例子，你查出某款药会抑制某个靶点，而这个靶点又跟某种基因突变有关，那个基因突变刚好导致一种罕见病……嗯，药物图谱就是帮你把这些「间接关联」可视化出来的工具。
1.1 核心定义
药物图谱（Drug Knowledge Graph）是一种基于图结构的医学知识组织方式。它用节点代表实体（比如阿司匹林、COX-2酶、炎症），用边代表关系（比如「抑制」「激活」「治疗」）。
我在项目里见过很多团队把数据堆在关系型数据库里，查一个多跳关系要写五六个 JOIN，查完人已经疯了。图结构天生适合这种场景——你想想看，从「药物A」走到「副作用B」再到「替代药物C」，在图里可能就是两三次跳转。
1.2 应用场景
药物图谱能做的事，远比你想的多。我个人习惯把它分成四个层次：
| 层次 | 典型场景 | 实际例子 |
|---|---|---|
| 药物发现 | 老药新用、靶点预测 | 从已知药物推测对另一疾病的有效性 |
| 临床试验优化 | 患者分层、不良反应预警 | 识别高风险的基因型人群，提前排除 |
| 个性化医疗 | 治疗方案推荐、用药禁忌检查 | 根据患者基因谱匹配合适的靶向药 |
| 知识检索 | 文献挖掘、问答系统 | 「这个药和那个药一起吃会不会打架？」 |
我记得有一次帮一家药企做项目，他们想查某个老药在文献中是否有被报道能够治疗新适应症。用传统搜索跑了三天，结果还是一团乱麻。换成药物图谱以后，从「药物→靶点→通路→疾病」这条路径一查，两小时出结果。避坑指南？嗯，提前把数据清洗干净，不然查出来的全是假阳性。
1.3 技术选型
到这里问题就来了：用什么技术搭这个图？
我先说图的存储层。目前主流的选择是图数据库，我个人习惯用 Neo4j，社区活跃，Cypher 查询语言也好上手。如果你追求高性能与分布式，可以考虑 JanusGraph，但运维成本会高一些。下面是几个常见选项对比：
| 图数据库 | 优点 | 缺点 |
|---|---|---|
| Neo4j | 上手快、生态好、支持 ACID | 单机性能有限，集群部署略复杂 |
| JanusGraph | 可扩展、支持多后端（HBase、Cassandra） | 配置繁琐，社区相对小 |
| ArangoDB | 多模型支持（图+文档+键值） | 图查询性能不如专有图库 |
| Amazon Neptune | 托管服务、免运维 | 贵，定制空间小 |
以上是存储层。再往上，知识抽取这块我建议用 NLP 工具+人工审核——我曾经踩过全自动抽取的坑，结果抽出一堆「药物-食物」这种毫无意义的边，那叫一个头大。最好是用预训练模型（比如 BioBERT）先粗抽，再用规则做精修。
部署层面呢？这个课程的核心就是 Docker。为什么选 Docker？你想想看，药物图谱涉及的东西太多了：图数据库、知识抽取管道、前端可视化、API 服务……每一样都得单独装环境。用 Docker 打包以后，不管在本地还是服务器，一个 docker-compose up 就能跑起来。我在好几个项目里都用这个套路，省去了百分之九十的「本地能跑、线上崩了」的烦恼。
最后，我用这张图来总结本章的核心逻辑：
从上往下走：先搞清楚药物图谱是什么，再看它能用在哪儿，然后决定用什么技术搭，最后通过 Docker 把这些技术统一部署起来。本章把前三步讲清楚，后面所有章节都会围绕「Docker 部署」这最后一层展开。
好了，这就是第一章的概况。接下来，我们会一步步走进 Docker 的世界，把药物图谱真正跑起来。