![图数据库识别](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-30.png)

一张供应商准入表，通常十二三个字段。营业执照、开户许可证、业绩合同、体系认证、财务报表、授权委托书——八九个字段是供应商自己填、自己盖章的。审核员能核的是“材料齐不齐、有没有过期、章盖得对不对”，核不了“这家公司和上一轮那四家投标人是不是一伙的”。后面这件事，表格做不到，[图数据库](https://yueshu.com.cn/what-is-graph)做得到。

这就是准入环节的真实困境：审核动作全部指向“这家公司自身合不合格”，而采购风险的大部分来自“这家公司和谁在一起”。前者是资质问题，可以逐项打勾；后者是关系问题，一张表装不下。要把关系装进来，靠的不是更严的表格，而是把供应商放进一张能连起来的关系网里——这正是图数据库在准入环节的位置：不是替代审核，而是把审核员看不见的那一层关系摊开。

# 一、准入核的是材料，材料证明不了关系

把准入材料按“能证明什么、不能证明什么”排一遍，问题就很清楚。

| 材料       | 能证明什么                 | 核不了什么                         |
| ---------- | -------------------------- | ---------------------------------- |
| 营业执照   | 主体真实存在、经营范围匹配 | 与另一家投标人是否同一批人控制     |
| 业绩合同   | 有同类项目经验             | 业绩是否由关联方互相“喂”出来       |
| 体系认证   | 管理流程达到标准           | 实际产能与交付是否由同一套班子完成 |
| 财务报表   | 规模与偿债能力             | 关联方之间是否存在资金空转         |
| 授权委托书 | 经办人有代理权             | 两家供应商的经办人是否为同一人     |

材料审核擅长排除“不合格”，不擅长排除“不合适”。一家注册资本 500 万、有三年同类业绩、证书齐全的供应商，完全可能和另外三家一起围同一个标段——每家单看都合格，放在一起才看得出问题。

这个缺口不是审核员不认真造成的，是数据形态决定的。资质是属性，一条一条挂在主体上；关联是关系，只在主体之间才存在。用属性字段去承载关系，怎么设计都会有漏。

# 二、隐性关联的六种形态，四种在纸面上看不出来

真正需要拦的关联，多数不写在股权结构里，而藏在共用的人、共用的标识、同步的动作里。

| 形态               | 数据从哪来                       | 在图上的样子                     |
| ------------------ | -------------------------------- | -------------------------------- |
| 同址同电话         | 工商登记、投标文件、发票抬头     | 两家供应商指向同一个地址点       |
| 共用财务或社保代缴 | 社保代缴记录、代理记账合同       | 同一自然人或同一中介同时连向多家 |
| 股东高管交叉       | 工商股权与任职信息               | 两条持股边或任职边汇于同一人     |
| 法定代表人亲属     | 户籍、婚姻、诉讼文书             | 两个自然人之间的亲属边           |
| 投标文件同源       | 电子投标文件的作者、创建机器、IP | 多家投标人连向同一设备或同一 IP  |
| 保证金同源         | 银行流水、保函开立行             | 多家投标人的保证金来自同一账户   |

前四种是“静态关联”，靠工商和公开数据就能建；后两种是“行为关联”，只有把投标动作本身记录成边才看得见。

行为关联的价值在于它绕不过去。《招标投标法实施条例》第四十条把六种情形直接视为串通投标：投标文件由同一单位或个人编制、委托同一单位或个人办理投标事宜、投标文件载明的项目管理成员为同一人、投标文件异常一致或报价呈规律性差异、投标文件相互混装、不同投标人的投标保证金从同一单位或个人账户转出。这六条里有五条本质上是“关系证据”，不是“资质证据”。用资质审核去查这五条，方向就错了。供应链场景里做风险预警的整体思路，可参考[图数据库与大模型如何实现智能风险预警](/posts/suppply-chain-database)，本篇只落在准入这一道关口。

拿报价规律举例。四家投标人报价 486 万、512 万、538 万、564 万，两两相差 26 万，整齐得不像市场竞争。单看每一份报价单都挑不出毛病，把四份放在一条数轴上，规律立刻显形。这个规律在人眼里要摆开看，在图里则是一条可以直接查询的模式。电子投标还多一层线索：文档属性里往往留着作者名、创建机器和最后保存人，纸质标书时代不存在的痕迹，现在一条条都在文件里。这些字段单独看毫无意义，按供应商归并之后，同名作者出现在四家投标人的文件里，就成了很难解释的事。

# 三、建模：四类点、三类边，标识点是关键

准入场景的图不用建得很大，四类点就够：供应商、自然人、标识、项目。自然人不只是股东，还包括高管、经办人、财务负责人、评标专家；标识包括地址、电话、银行账户、邮箱、IP、设备指纹；项目是招标包或标段。

边分三类。股权与任职边描述静态结构，投标边描述动作，付款边描述履约。三类边的更新时间完全不同——工商信息按季度变，投标行为按次产生，付款按月发生。混在一张表里就会互相拖累，分开建、按需关联才跑得动。

```
MATCH (s:supplier {sid: $supplier})-[:located_at|uses_phone|uses_account]->(id:identifier)
MATCH (id)<-[:located_at|uses_phone|uses_account]-(peer:supplier)
WHERE peer.sid != s.sid
RETURN peer.sid, count(DISTINCT id) AS shared_idents
ORDER BY shared_idents DESC
```

这条查询问的是：这家供应商的地址、电话、账户，还被哪些供应商共用。共享一个标识可能是巧合——同一个产业园、同一家代理记账公司；共享三个以上，基本可以认定不是巧合。

标识点是整个建模的关键。它把“看不出来的关系”翻译成“看得见的边”：两家公司名称毫无相似之处，股权上也没有交集，但它们把保证金从同一个账户转出、投标文件在同一台电脑上生成、留的联系电话是同一个号码——三条标识边一并，关系就成立了。没有标识点，这三条线索永远躺在三张不同的表里。

# 四、判定：三条路径，分级处置

关联识别不能一票否决，也不能只做提示。可执行的做法是三条路径分别打分，按命中数量分级。输出形态也要克制：不要给审核员一张几千节点的关系图，而是一句话结论加上可展开的证据链——这一包七家投标人分成三个关联簇，其中三家的保证金来自同一账户，点击可以逐条看原始凭证。审核员要的是判断依据，不是图谱。

| 路径     | 典型证据                                     | 证据强度 | 处置动作               |
| -------- | -------------------------------------------- | -------- | ---------------------- |
| 股权关联 | 同一实控人、交叉持股、母子公司同标段         | 强       | 直接不予准入           |
| 人员关联 | 同一经办人、同一财务负责人、法定代表人为亲属 | 强至中   | 两家取一或要求书面说明 |
| 行为关联 | 保证金同源、投标文件同源、报价呈规律性差异   | 强       | 移交合规核查           |
| 标识重合 | 同址、同电话、同邮箱，且无合理解释           | 中至弱   | 列入重点观察，加审     |

分级的意义在于避免两种错误。一种是只凭同址就判死——同一个产业园里几十家公司共用门牌，代理记账公司一个地址挂上百家客户，这类误伤会让采购部门很快不信任系统。另一种是只提示不处置——把关联线索做成一张漂亮的关系图，却没有对应的准入动作，图就成了展示品。

建议的判据是：任一路径命中两条以上独立证据，不予准入；命中一条强证据，要求书面说明并加审；只有标识重合而无其他证据，列入观察名单，在下一次投标时重点比对。三条路径都跑完才出结论，跑一半就下判断，比不跑更容易出错。风控体系里这套判定的完整位置，[供应链金融风控体系图数据库分析](/posts/supply-chain-finance-risk-control-cystem-map-database-analysis)讲得更系统。

# 五、悦数图数据库的核心能力支撑

准入场景的图有两个特点：点不多但边很杂，且要求实时。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，供应商与标识之间的多跳关联可以沿边直接遍历，不必把工商、投标、流水三套数据反复 JOIN；动态 Schema 支持不停机新增设备指纹、保函编号等标识类型，招标规则变化时不必重建模型；内置连通子图与社区发现算法，能把一批投标人自动切成若干关联簇；配合 Text2nGQL，采购人员用自然语言就能发起“这批投标人里有没有共用账户的”这类查询。产品 100% 自主可控。

# 六、入库不是终点：动态年审与两个误区

关联是长出来的，不是天生的。一家供应商入库时干干净净，两年后可能因为法人变更、股东新增、地址迁移，和另一家成了关联方。只做准入不做年审，等于只在门口查一次证件。

| 阶段         | 目标           | 核心工作                                                     | 参考周期 |
| ------------ | -------------- | ------------------------------------------------------------ | -------- |
| 一、标识库   | 先把标识收齐   | 归集工商、投标、流水三类数据中的地址、电话、账户、设备，做实体解析去重 | 4~6 周   |
| 二、行为入图 | 让投标动作可查 | 电子投标文件的作者与设备信息、保证金账户、报价序列入图       | 6~8 周   |
| 三、准入判定 | 关联进流程     | 三条路径接入准入系统，输出关联簇与分级处置建议，先并行不阻断 | 4~6 周   |
| 四、年审监测 | 关联变化可预警 | 增量监听工商变更与新增投标，命中关联规则即触发复审           | 持续     |

第一个误区是把同址同电话直接判死。园区注册、代理记账、虚拟办公地址，这三种情况在中小企业里极其普遍，一刀切会把大量正常供应商挡在门外。正确做法是把标识重合当作线索而不是结论，必须叠加人员关联或行为关联才处置。

第二个误区是只建供应商、不建人。关联的载体是人——股东、高管、经办人、财务。只把供应商建成点，人和标识都存成字段，那么“两家公司共用同一个财务”这条最重要的线索，永远无法被查询到。人必须是点，标识也必须是点。

供应商准入的本质，是把“这家公司合不合格”这一个问题，加上“这家公司和谁是一伙的”这第二个问题。第一个问题靠材料，第二个问题只能靠图。

**相关阅读**

- [如何用图数据库解决供应链金融风控问题？](/posts/supply-chain-finance-risk-control-problems-with-graph-databases)
- [基于图数据库的客户关联网络风险洞察](/posts/associative-network)
- [图数据库在业务风控中的应用](/posts/application-of-graph-database-in-business-risk-control)
- [图数据库常见算法有哪些？](/posts/what-are-the-common-algorithms-ingraph-databases)

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：供应商准入与悦数图数据库是什么关系？**

A：准入环节要判断的是供应商之间的关联，而关联只能沿边查。悦数把供应商、自然人、地址电话账户等标识建成点，把持股、任职、投标建成边，多跳关联一次遍历即可得出；千亿点万亿边规模下点边精确查询 1 秒内、5 度关系 5 秒内，让关联核查能在准入评审的时限内跑完。

**Q3：悦数图数据库在落地行业与场景方面有哪些积累？**

A：悦数已在金融风控、供应链管理、政务与公共安全等领域落地，覆盖反欺诈、反洗钱、企业关联关系分析、N 级供应商风险穿透等场景，中国移动用其支撑 9 亿用户规模的数据分析。按 IDC 2024 年中国图数据库市场份额报告，悦数位列第二，并连续两年入选信通院图数据库“领航者”。

供应商准入审不出问题，往往不是材料不齐，而是材料全是自证的：营业执照、业绩合同、体系认证，能证明这家公司合格，证明不了它和另外三家是不是一伙的。图数据库把供应商、经办人、地址电话账户这些标识建成点，把投标行为建成边，隐性关联才从纸面背后浮出来。

供应商准入怎么审？图数据库识别隐性关联与控制关系的路径

![股权穿透查询图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-29.png)

一家有限合伙企业，普通合伙人出资 0.8%，有限合伙人出资 62%，剩下是十几个跟投的自然人。按出资比例连乘往上穿，穿到顶是那位 62% 的 LP；按谁在合伙协议里执行事务、谁签得了字往上穿，穿到顶是那位 0.8% 的 GP。两套算法、两个答案，而[图数据库](https://yueshu.com.cn/database)要解决的第一件事，是让这两套算法能在同一张关系网上各跑一遍。

同一家公司，两个“实际控制人”。

这不是数据错误，是口径问题。工商登记、监管报送、银行尽调三张表之所以经常对不上，原因往往不是谁填错了，而是三家用的算法根本不是同一个：一家算出资，一家算表决权，一家算实际支配。要把三个答案收成一个，先得把“股权穿透”这个词拆开——图数据库在这里的价值，不是把递归查询跑得更快，而是让这三种算法各有各的载体，能分开算、也能一起算。

# 一、先分清三个问题：谁持股、谁表决、谁说了算

穿透查询看着是一件事，其实是三件。第一件是经济权益：某个自然人对目标公司最终享有多少比例的出资份额，用来算并表、算关联交易、算受益所有人。第二件是表决权：这个人在股东会上能投出多少票，用来判断控股与重大事项能否通过。第三件是实际支配：即便一股不持，能不能决定董事会人选、财务负责人、经营方向。

三件事的输入不同，答案自然可以不同。一个持股 13.2% 的自然人可能是实际控制人，一个持股 51% 的股东也可能只是代持通道。把三者混成一个“穿透比例”，后面所有的判断都会跟着错。

| 口径         | 输入是什么                       | 能回答的问题         | 什么时候失效                   |
| ------------ | -------------------------------- | -------------------- | ------------------------------ |
| 出资比例连乘 | 各层持股比例                     | 最终享有多少经济权益 | 有代持、同股不同权、分层架构时 |
| 表决权比例   | 章程约定的表决权、委托、一致行动 | 股东会能不能通过     | 表决权分散、无一致行动时       |
| 实际支配     | 董事会席位、人事财务权、协议控制 | 谁真正说了算         | 仅有股权关系、无支配证据时     |

判断标准可以先定下来：三种口径算出的答案若一致，结论最稳；若不一致，以实际支配为准，表决权次之，出资比例最后。这条顺序不是偏好，是监管口径的一贯逻辑——实际控制人的定义本身就落在“能够实际支配公司行为”上，而不是落在持股数字上。

# 二、建模：点分三类，边要带五个属性

很多穿透项目失败在建模的第一步：把“股东”存成了企业节点的一个字段。字段化的后果是，超过三层就穿不动，因为第四层的股东在系统里根本不是一个能被继续追溯的实体。关联关系全景画像怎么建，[股东穿透与实际控制人识别](/posts/shareholder-penetration)给过一套场景视角的拆解，本篇只谈建模与判定口径。

正确的做法是把持股主体全部拆成点，分成三类。企业法人，包括境内有限公司、股份公司和境外主体；自然人；以及合伙企业、资管计划、信托这类持股载体。第三类最容易被漏掉，也最容易出错——有限合伙里的普通合伙人与有限合伙人，权利结构完全不同，把它压成一个“股东”点，控制关系就丢了。

边比点更重要。一条持股边至少要带五个属性，缺一个就会在某一类结构上算出错答案。

| 边属性           | 含义                       | 为什么必须单列                    | 缺失的后果             |
| ---------------- | -------------------------- | --------------------------------- | ---------------------- |
| 出资比例         | 认缴出资占注册资本比重     | 算经济权益的基础                  | 并表与关联交易判断失真 |
| 实缴比例         | 实际到位资金占比           | 影响偿债与真实权益                | 空壳股东被当成实力股东 |
| 表决权比例       | 章程或协议约定的投票权     | 同股不同权、AB 股、委托投票都靠它 | 控制权判断整体失效     |
| 生效区间         | 起止日期                   | 股权是时点状态，历史追溯需要      | 只能看现在，查不了当时 |
| 数据来源与更新日 | 工商、年报、公告、内部录入 | 冲突时要能判断谁更新              | 多源冲突无法裁决       |

除了持股边，还要留两类独立边：代持边和表决权委托边。它们不改登记比例，但改真实归属，混进持股边里就再也分不出来。合伙企业则要单独建“执行事务合伙人”边，因为这条边承载的控制权与出资比例无关。

# 三、连乘在这四类结构上必然算错

出资比例连乘是最直观的算法，也是最容易出错的一个。它在简单树状结构上没问题，一碰到下面四类结构就失真。

| 结构                         | 连乘会算出什么                     | 正确的处理口径                           |
| ---------------------------- | ---------------------------------- | ---------------------------------------- |
| 循环持股（A 持 B、B 持 A）   | 递归不收敛，或被人为截断层数       | 先识别环，按环内最小比例折算后再向外展开 |
| 交叉持股（同一股东多条路径） | 多条路径比例相加，可能超过 100%    | 按最终股东合并去重，取控制链而非求和     |
| 有限合伙（GP 出资极少）      | GP 比例接近 0，被判定为无控制      | 以执行事务合伙人身份判定控制，不看比例   |
| 代持与表决权委托             | 登记比例与实际归属一致，看不出差异 | 走代持边与委托边，单独计算实际表决权     |

拿一条三层链算一遍就清楚了。A 持 B 60%，B 持 C 55%，C 持 D 40%。连乘得 60% × 55% × 40% = 13.2%，低于受益所有人常用 25% 的判定线，很多系统到这里就把 A 排除了。但看控制关系：每一层都过了半数，A 对 B 绝对控股，B 对 C 绝对控股，C 是 D 的第一大股东且能实际支配——控制是一层一层传下来的，不是乘出来的。经济权益 13.2%，控制权接近 100%，这两个数字都真实，只是回答的问题不同。

这也是为什么受益所有人的判定标准写的是“直接或间接拥有超过 25% 股权或表决权”，后面还要跟一句“或虽未超过但能实际控制”。前半句交给连乘，后半句交给控制链，两条都算完才算穿透完。

# 四、实控人怎么算：三条判定路径与剪枝规则

实控人识别不是一次查询，是三条路径分别跑、结果合并。

第一条是股权链。沿持股边向上枚举路径，边比例相乘，达到阈值即标记。常用阈值有三个：25% 对应受益所有人判定，50% 对应绝对控股，三分之一对应重大事项否决权。三个阈值对应三种业务用途，不要只留一个。

第二条是表决权支配。把一致行动协议、表决权委托、AB 股安排、章程特别约定一并计入表决权比例。这条路径经常被跳过，因为它的数据不在工商登记里，而在公告、协议和内部档案里。

第三条是实际支配。董事会席位是否过半、财务负责人与总经理能否任免、公章与账户由谁控制、是否存在协议控制安排——这类证据大多是文本，需要与大模型或多模检索配合，从公告和合同里抽出来挂到边上。这类实体与证据的组织方式，在[企业风险知识图谱的构建及应用](/posts/enterprise-risk-kg)里有更完整的讨论。

# 五、悦数图数据库的核心能力支撑

多层穿透的难点在深度与并发：一条十层链要逐层展开，同时还有成千上万条链在并行计算。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，路径枚举与连通性计算可以沿边直接遍历，不必用递归 JOIN 反复回表；动态 Schema 支持不停机新增境外主体、资管计划等点类型与表决权委托边，历史股权按时点区间存储，能查当下也能查当时；内置最短路径与连通子图算法，配合 Text2nGQL 让业务人员用自然语言直接发起穿透查询。产品 100% 自主可控。

# 六、验收：用已知答案回测，两个误区

穿透系统上线前，最有效的一次验收不是压测，是回测。取一批监管已披露实际控制人的上市公司或公开发债主体，把系统跑出来的结论与披露口径逐家比对，差异逐条归类：是数据缺失、是结构没建模，还是判定路径没跑。

| 验收项     | 检验方法                       | 合格参考                               |
| ---------- | ------------------------------ | -------------------------------------- |
| 回测命中率 | 取 200 家已知实控人的主体比对  | 一致率是唯一硬指标，差异必须能逐条解释 |
| 路径可解释 | 结论能否给出完整的链与每层比例 | 只给结论不给链的，一律不通过           |
| 深层响应   | 八至十层穿透的单次耗时         | 交互式查询应在百毫秒至秒级             |
| 数据新鲜度 | 工商变更后多久反映到图里       | 决定穿透结论是否可用                   |
| 口径一致性 | 与监管报送口径是否一致         | 三处答案必须能对齐，否则等于没做       |

第一个误区是把工商登记的股东当成全部。合伙企业、资管计划、境外主体、代持安排，这四类在登记信息里都表现为一个普通股东名称，看不出差别。不单独建模，穿透到第三层就断了。

第二个误区是用最短路径代替控制链。最短的那条链往往不是控制链——A 和 D 之间可能有一条两跳的 0.1% 搭桥路径，而真正的控制链要走五层、每层都过半。按跳数排序必然选错，按表决权乘积排序才对。

股权穿透的本质，是把“谁持股”这一个问题，拆成“谁表决”和“谁说了算”两个问题。三个答案能对齐，穿透才叫穿透；只有一个数字，那只是乘法。

**相关阅读**

- [公司风控管理为什么要使用图数据库](/posts/company-risk-management-with-graph-database)
- [图数据库在业务风控中的应用](/posts/application-of-graph-database-in-business-risk-control)
- [图数据库赋能企业数据资产管理：从关系图谱构建到风险穿透](/posts/iso-gql-louvain)
- [图数据库常见算法有哪些？](/posts/what-are-the-common-algorithms-ingraph-databases)

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：股权穿透查询与悦数图数据库是什么关系？**

A：股权穿透的核心是沿持股边做多层路径枚举与比例计算，这正是图数据库的原生查询形态。悦数在千亿点万亿边规模下做到点边精确查询 1 秒内、5 度关系 5 秒内，支持按时点存储历史股权与动态新增主体类型，是十层穿透能做成交互式查询的前提。

**Q3：悦数图数据库在国产化适配与权威认证方面有哪些进展？**

A：悦数已完成统信、麒麟、中科可控等国产软硬件适配，产品 100% 自主可控，累计 60 余项国家发明专利；2024 年 11 月全球首发原生支持 ISO-GQL，2024 年 6 月成为国内首家通过信通院“可信数据库”图数据库性能测试的产品，并连续两年入选信通院图数据库“领航者”。

股权穿透算不准，多半不是数据缺，而是把“谁持股”当成了“谁说了算”。出资比例连乘得出的 13.2%，和层层过半形成的 100% 控制权，是两个答案。图数据库把企业、自然人、合伙企业建成点，把持股比例与表决权比例拆成两条属性，再沿控制链判定，答案才对得上工商与监管口径。

股权穿透查询怎么做？图数据库多层持股与实控人识别的建模方法

![可疑交易图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-28.png)

风控部门每季度要开一次阈值评审会。这次议题很简单：把可疑交易的金额阈值从 5 万提到 8 万。理由也充分——上季度人工复核队列积压 1.7 万条，单条平均处置 6 分钟，两个人全职干不完。调完之后报送量掉了四成，会开得挺顺。会议室里没人提另一件事：这套规则逐笔看账户，而[图数据库](https://yueshu.com.cn/database)擅长的恰恰是账户之间的关系。

纪要第三页有一行小字没人追问：阈值上调后新增的漏报，抽样复核结果是多少。不是不想算，是算不出来。漏报没有队列、没有工单、没有人在事后去捞那些本该报却没报的交易。误报看得见，漏报看不见，于是每一次调参都朝同一个方向走：阈值越来越高，队列越来越短，模型越来越安静。

真正的问题不在阈值的位置。一笔 4.8 万的分拆转账，和一笔 4.8 万的连锁门店日结，在规则引擎眼里是同一个东西——金额、时间、对手方三个字段凑出来的一个分数。它们唯一的区别在于所处的关系结构，而这个维度在逐笔评分里根本不存在。这正是图数据库要补的那一环。

# 一、误报的根源：一个团伙被拆成两百多笔孤立打分

传统甄别链路的输入单位是“一笔交易”。规则读金额、时点、频次、名单；模型读同一组字段再加一点历史行为；输出的是一条告警和一个置信度。整条链路里，没有任何一个环节回答过“这笔钱的主人，和上一笔告警的主人是不是同一个人”。

某股份行内部复盘过一个跑分团伙：4 天内把 460 万分拆到 18 个账户，每笔 2 万上下。规则侧的表现几乎是完美的“沉默”——单笔 5 万的大额阈值不触发，单账户日累计 20 万的阈值不触发（每户日均远低于此），唯一命中是“夜间时段 + 对手方开户不足 30 天”这条弱规则，置信度 0.58，低于 0.7 的自动报送线，全部落到人工复核。

230 条告警，单条 6 分钟，合计 23 小时，三个复核员一天半的产能。而真正有价值的结论只有一句：这 18 个账户属于同一个操作团伙。这句话埋在第 187 条告警后面——等复核员翻到那里，当天队列已经排到第二天上午。

误报的成本不只是人力。更隐蔽的代价是排序：真正该报的那一条，和被误报淹没的两百多条，在同一个队列里按时间先后排队，没有优先级。队列一旦排满，风险就从“没被发现”变成“来不及发现”。

| 维度                  | 规则逐笔判定             | 模型逐笔评分           | 结构归并 + 逐笔评分                |
| --------------------- | ------------------------ | ---------------------- | ---------------------------------- |
| 评估单位              | 一笔交易                 | 一笔交易               | 一个连通组（含若干笔明细）         |
| 主要输入              | 金额、时点、对手方、频次 | 同上，加历史行为       | 同上，加度数、社群、闭环、共享标识 |
| 18 账户团伙产生的告警 | 230 条                   | 180~230 条，视分数切分 | 1 组，附 230 笔明细                |
| 人工处置工作量        | 约 23 小时               | 约 18~23 小时          | 约 0.7 小时（组级复核）            |
| 主要失效方式          | 阈值上下都能绕           | 分布漂移后召回骤降     | 图不完整时归并失效                 |

# 二、五类高误报模式，指向同一个缺失维度

把近两年的复核结论归堆，误报并不均匀分布，而是集中在五种形态上。它们的共同点不是“金额没调好”，而是判断时缺了关系这一维。

| 形态                               | 规则为什么报                 | 关系视角下怎么判                                         | 误报密度 |
| ---------------------------------- | ---------------------------- | -------------------------------------------------------- | -------- |
| 分拆转账（多户小额）               | 单笔贴合阈值下沿             | 组内共享设备或 IP、7 日内闭环则升级；无共享标识则降级    | 高       |
| 商业集中结算（门店日结、平台二清） | 固定时点、整齐金额、集中转入 | 转出方为同一集团主体、金额与门店流水匹配、无闭环则排除   | 极高     |
| 代发工资与批量报销                 | 一对多、金额整齐             | 付款方为用人单位、收款方历史稳定、按月重复则排除         | 极高     |
| 跨境贸易多对手方                   | 对手方分散、金额不整         | 有合同、报关、物流三条链对应则排除；缺链且资金回流则升级 | 中       |
| 亲属代持与借名账户                 | 户主与实际操作人分离         | 登录设备与户主不一致、资金最终归集到同一节点则升级       | 中       |

循环转账最能说明问题。A 转 B、B 转 C、C 转 A，逐笔看是三笔正常个人转账，金额都不大，都发生在工作时段，渠道也没异常。只有把三笔连起来，闭环才浮出来。反过来，一条真实供应链的结算在图上可能是一棵很深的树，但没有任何环——环的有无，是最便宜也最有效的判别信号之一。

同一台设备登录 37 个账户、每户每天只转 2 万，这个形态在逐笔视角下 37 笔全部正常，在关系视角下它是一个标准的星形结构。规则看不出星形，因为它一次只盯一个点。资金链路排查的工程细节可参考[银行反洗钱资金链路深度排查](https://yueshu.com.cn/posts/anti-money-laundering)，本篇关注的是告警的口径而不是链路的深度。

# 三、把告警的单位从笔换成组

建图不必从全量开始。有效的做法是从告警出发反向建图：以告警涉及的账户为种子，向外扩两跳，把共享标识（设备、IP、手机号、银行卡）、交易对手、受益所有人一并拉进来，形成局部子图。种子有多少，图就有多大，增量更新只跟着新告警走。这套建模在关联网络场景里已经比较成熟，[基于图数据库的客户关联网络风险洞察](https://yueshu.com.cn/posts/associative-network) 给过一套银行侧的落地口径，本篇只借用其中的归并部分。

点分成三类：主体（账户、客户、商户）、标识（设备指纹、IP、手机号、卡号）、关系人（受益所有人、经办人）。边带方向与时间：转账带金额和渠道，登录带设备与时刻，绑定带生效区间，任职与控股带持股比例。资金流向必须是有向边，“谁给谁钱”和“谁和谁有往来”在甄别里是两件事。

归并规则可以写得很朴素：7 日内共享设备、或两跳内存在资金闭环、或受益所有人相同的告警，归入同一连通分量；每个分量生成一个组级案件，附全部明细与关系截图。复核对象从“这一笔为什么可疑”变成“这一组是不是一个团伙”，判断难度下降，处置效率上升。组级复核通常 40 分钟出结论，同样的信息量逐笔复核要 23 小时。

考核指标也随之改变。不再只看单笔告警准确率，而看组级命中率与每组平均告警数。后一个数字很说明问题：平均每组 1.2 条，说明归并没生效；平均每组 30 条以上，多半是把一个正常商圈误连成了一团。两个极端都指向同一件事——图建得不对。

# 四、结构特征怎么进模型：给规则装一个上下文开关

结构特征不是替换规则，而是给规则加一个“看上下文”的开关。同一笔 4.8 万，落在什么结构里，结论完全相反。

| 特征           | 计算方式             | 业务含义           | 模型里的用法                   |
| -------------- | -------------------- | ------------------ | ------------------------------ |
| 度数           | 一度邻居计数         | 账户活跃广度       | 孤立点降权，超高连接升权       |
| 二跳规模       | 两跳内去重账户数     | 风险波及半径       | 超阈值触发组级复核             |
| 社群规模与密度 | Louvain 社区发现     | 是否成团、团有多大 | 团内告警密度高则升级           |
| 闭环数量       | 3~6 跳环检测         | 资金是否回流       | 存在闭环直接升权               |
| 路径长度分布   | 最短路径统计         | 资金过了几层       | 层数多且金额递减，疑似分层转移 |
| 共享标识数     | 设备、IP、手机号交集 | 是否同一操作人     | 达 3 个以上视为同组            |
| 时间节律同步性 | 组内交易时间方差     | 是否脚本化操作     | 方差极小，疑似程序控制         |

有一条判据可以直接写进制度，不必等模型上线：同组账户共享 3 个以上标识、组内 7 日内存在闭环、组内交易时间方差低于 5 分钟——三项中两项成立，即升级为组级案件。用这条口径回测历史样本，误报剔除率通常能到一半以上，同时不牺牲召回。

图算法在这里各司其职。Louvain 把资金网络切成团，连通子图把分拆合并成一案，环检测负责找回流，PageRank 与节点重要度负责找归集账户——团伙里那个总闸往往度数不高，中心性却极高，因为所有支流都从它这里过。这些算法在悦数图数据库里是内置的，不必把子图导出到外部计算框架再算一遍；导出这一步本身就是实时甄别里最贵的一环。

# 五、悦数图数据库的核心能力支撑

实时甄别要求结构特征必须在线算。悦数图数据库采用存算分离与 Shared-Nothing 架构，在千亿点万亿边规模下，点边精确查询 1 秒内返回、5 度关系查询 5 秒内返回，动态 Schema 支持不停机新增设备指纹、受益所有人等点边类型，业务迭代不必等排期；内置 Louvain、连通子图、最短路径等图算法，配合 Text2nGQL 让风控人员用自然语言直接生成查询；原生多模融合检索把图、向量、全文放在同一引擎，便于交易结构与文本线索一起召回。产品 100% 自主可控。

# 六、从告警出发反向建图：四阶段与两个误区

| 阶段               | 目标             | 核心工作                                                     | 参考周期 |
| ------------------ | ---------------- | ------------------------------------------------------------ | -------- |
| 一、告警归并       | 处置单位从笔变组 | 接入告警源与账户、设备、IP 映射，按 7 日窗口跑连通分量，并行运行不改原有流程 | 3~4 周   |
| 二、结构特征入库   | 特征可在线取     | 把度数、二跳规模、闭环数、共享标识数落成可查特征，接现有模型做影子打分 | 4~6 周   |
| 三、组级模型与阈值 | 组级命中率可考核 | 用已结案样本回标，定下三项判据的阈值，替换单笔阈值考核       | 6~8 周   |
| 四、反馈闭环       | 结论回流图谱     | 复核结论作为标签写回关系边，形成可迭代的监督信号             | 持续     |

第一个误区是先建全量图谱、再谈甄别。图谱建设周期以季度计，而误报是每天都在发生的成本。从告警出发反向建图，第一周就能拿到归并结果，图的边界随告警自然生长，反而更容易覆盖真正有风险的区域。

第二个误区是把图当特征库用，只取度数。只看一度邻居，等于把团伙问题降级成“这个账户往来多不多”。一个 12 人的团伙，每个人的度数可能都只有 3，靠度数永远排不进前列；靠社群与闭环，它们才成形。

可疑交易甄别的准确率上限，不取决于模型多复杂，而取决于告警的单位是笔还是组。把这个问题换掉，阈值才有讨论的意义。

**相关阅读**

- [骗保团伙：同一家修理厂为何反复出现在事故现场？图数据库解谜](https://yueshu.com.cn/posts/insurance-fraud-ring)
- [图数据库如何赋能金融风控体系](https://yueshu.com.cn/posts/graph-database-empower-financial-risk-control-system)
- [图数据库常见算法有哪些？](https://yueshu.com.cn/posts/what-are-the-common-algorithms-ingraph-databases)
- [区块链与图数据库结合：金融交易透明化与合规审计新范式](https://yueshu.com.cn/posts/transaction-transparency)

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的分布式图数据库，面向千亿点万亿边规模的关系数据存储与查询，采用存算分离与 Shared-Nothing 架构，支持动态 Schema、内置图算法与原生多模融合检索，产品 100% 自主可控，已获 60 余项国家发明专利。

**Q2：可疑交易甄别与悦数图数据库是什么关系？**

A：图数据库承担的是甄别链路里“关系”这一层：把账户、设备、受益所有人连成图，让告警按连通分量归并成组，把度数、社群、闭环等结构特征实时供给评分模型。悦数在千亿点万亿边规模下做到点边精确查询 1 秒内、5 度关系 5 秒内，是这一层能在线跑的前提。

**Q3：金融客户对部署形态与权限控制有硬要求，悦数图数据库怎么满足？**

A：支持公有云、私有化与一体机多种部署形态，提供多租户隔离、加密通信与细粒度权限控制，并已完成统信、麒麟、中科可控等国产化适配。按 IDC 2024 年中国图数据库市场份额报告，悦数位列第二，并连续两年入选信通院图数据库“领航者”。

可疑交易甄别误报多，根源不在阈值高低，而在评估单位：每笔交易被单独打分，模型看不见这笔钱处在什么结构里。同一团伙的两百多笔分拆，在系统里是两百多条互不相关的告警。图数据库补的正是这一环——把告警从笔归并成组，让结构特征进入评分。

可疑交易甄别为什么误报多？图数据库能补上哪一环

![图数据库反欺诈图谱](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-27.png)

一个[反欺诈图谱](https://www.yueshu.com.cn/solutions/finance-risk)项目验收那天，两份清单都签了字。数据团队交付的清单上写着：图数据库里节点 3.1 亿，边 12.4 亿，日增边 400 万，导入延迟低于 15 分钟。风控团队的清单上写着：查询响应达标，可视化可用，两个场景已接通。

半年后复盘，由这个图谱直接产出的团伙线索一共 7 条，其中被立案的 2 条。

两份验收清单都没有说谎，问题在于中间的缺口不在任何一方的清单上。数据团队验收的是「边够不够多」，风控团队验收的是「系统能不能用」，而真正决定成败的那个指标——一条线索能不能从图上被推出来——谁都没有列。

这就是反欺诈图谱最常见的失败形态：不宕机、不报错、性能指标漂亮，只是不出结果。把这条链路拆开看，它由接入、建模、特征、拦截四段组成，每一段都有一个不容易被发现的断点。

# 一、接入段：搬进来的是流水，不是关系

绝大多数反欺诈图谱的第一处断裂发生在接入环节，而且原因出奇地一致：把交易流水原样搬进了图。

流水是事件，不是关系。一条交易记录包含金额、时间、付款方、收款方，这四个字段装进任何数据库都能存。但反欺诈真正要回答的问题不在这一条记录里，而在多条记录之间的共享——哪些账户在同一个设备上登录过，哪些商户的收款码被同一批人反复扫，哪些身份要素在不同主体之间来回出现。

**这些共享关系在原始数据里并不存在，必须由共现算出来。**一笔交易本身只提供两个端点，而围绕这一笔交易可以派生出三五条甚至更多条关系边：设备与账户的绑定、账户与账户的资金对手关系、身份要素的共用、收款码的归属。只搬流水不派生边，图上就只有一堆孤立的点。

| 关系边类型   | 数据来源             | 时间窗设定         | 噪声控制要点                 | 典型欺诈信号               |
| ------------ | -------------------- | ------------------ | ---------------------------- | -------------------------- |
| 设备共现     | 设备指纹、登录日志   | 7~30 天滚动        | 剔除门店公用终端、公司 IP 段 | 一台设备短时登录多个新开户 |
| 资金对手     | 交易流水对手方字段   | 按笔，保留时序     | 剔除平台内部清算与自身划转   | 双向对敲、整数金额往返     |
| 身份要素共用 | 手机号、证件号、地址 | 永久，带首末次时间 | 剔除亲属关系已知白名单       | 新户与黑名单户共用联系人   |
| 收款码归属   | 收单系统、商户档案   | 永久               | 剔除同一连锁主体的多码       | 多商户共用同一结算账户     |

这张表里最容易被跳过的是时间窗和噪声控制。没有时间窗，三年前共用过一次设备的关系和昨天共用的关系权重一样，图会被历史关系填满；没有噪声控制，一个商场 WiFi 就能把所有到店顾客连成一个大团。

**接入段的验收信号**不是边的总数，而是两个比值：一笔交易平均派生几条边，以及这些边里落在活跃时间窗内的比例。如果边数约等于交易笔数，说明关系根本没被算出来，后面三段做得再好也无从发挥。

# 二、建模段：实体没拆成点，等于没建图

第二处断裂比第一处更隐蔽，因为它发生在看起来完全正确的地方——表结构照搬。

举个具体的例子。账户表里有一列 phone，存着绑定的手机号。要查「这个账户用的号码还绑过哪些账户」，写一条自连接语句就能查出来，数据也对。所以很多团队在这一步就认为建模完成了。

问题出在下一步。查到那三个关联账户之后，如果要继续问「这三个账户各自还用过哪些设备、这些设备又绑过哪些账户」，自连接就要再套一层，代价随数据量快速上升；问到第四跳，多数团队会改成离线预计算。而团伙识别的价值恰恰集中在三到五跳。

| 建模方式               | 能回答的问题             | 回答不了的问题       | 跳数扩展成本             |
| ---------------------- | ------------------------ | -------------------- | ------------------------ |
| 手机号作为账户表的一列 | 这个号码绑了哪些账户     | 这些账户还共用过什么 | 每加一跳，自连接多套一层 |
| 手机号作为独立节点     | 从号码出发遍历到任意深度 | ——                   | 与全表规模基本无关       |
| 设备作为账户表的一列   | 这台设备登录过哪些账户   | 设备与设备之间的关联 | 同上                     |
| 设备作为独立节点       | 设备、账户、号码三层交叉 | ——                   | 同上                     |

差别不在于能不能查，而在于**能不能继续往下跳**。属性是值，节点才是可以继续延伸的端点。把手机号、设备号、证件号、地址这些高复用实体留在属性里，图谱的上限在建模那天就被锁死了。

建模段还有两个必做项。一是边要带时间和来源：first_seen、last_seen 两个字段没有，追溯时说不清某条关系当时是否已经存在，模型审计会卡在这里。二是要能加类型不能停机，欺诈手法迭代的速度快过版本发布周期，新的收款方式和新的账号体系随时会出现，动态 Schema 让新增节点与边类型不必中断服务，这一条在悦数图数据库里是原生支持的。如果还在比较不同存储方案在深路径上的表现，[图数据库的四种存储路线](https://www.yueshu.com.cn/posts/graph-database-storage-methods)把差别讲得更细。

**建模段的验收信号**是能否用一条查询回答这个问句：从任意一个账户出发，五跳之内能到达的全部主体及其关系路径。答不上来，就还在用图数据库存关系表。

# 三、特征段：只做一跳，团伙永远是孤岛

到了第三段，图建对了，特征却往往还在沿用规则引擎的思路。

规则引擎的特征是单点特征：这个账户近 30 天交易笔数、单笔最大金额、夜间交易占比、是否首次登录即大额转出。这些特征描述的是「这一个账户像不像坏人」，做得再精细也回答不了「这一群人像不像一个团伙」。

团伙的本质是结构，不是个体。一个人可能每一笔交易都正常，但当他与另外十七个账户共用同一台设备、在同一个小区登录、资金在四十八小时内绕一圈回到原账户，这个结构本身就是异常。

| 图能力              | 对应的欺诈问题           | 输出物                         | 使用时要注意                                   |
| ------------------- | ------------------------ | ------------------------------ | ---------------------------------------------- |
| 社区发现（Louvain） | 这堆人是不是一伙的       | 社区编号、社区规模、内部边密度 | 社区过大时要继续拆分，别把半个城市算作一个团伙 |
| 连通子图            | 从已知黑点能炸出多大范围 | 受影响主体集合                 | 起点选错会把整张图连成一片                     |
| 中心性（PageRank）  | 谁是中介、谁是号商       | 节点重要性排序                 | 先剔除超级节点，否则排名只反映度数             |
| 最短路径            | 两笔钱之间怎么走的       | 路径与跳数                     | 四跳以上解释力衰减，不必无限追                 |

这张表里，社区发现和连通子图承担了团伙识别的主要工作，中心性用来找中介，最短路径用来做链路还原。四类能力在悦数图数据库里都是内置算法，不需要把数据导出到外部计算框架再算一遍。

**特征段的验收信号**是告警的构成比：如果九成以上的告警仍然是单点告警，说明图只被当成了一张查询表，群体特征根本没有进模型。一个健康的反欺诈图谱，告警里应该有相当比例是「一个群体」而不是「一个账户」。

# 四、拦截段：离线算得准，决策窗口早关了

最后一段的断裂最直接，也最容易被误解为产品性能问题。

离线跑批能做出很漂亮的模型。全量数据、复杂特征、图算法跑几轮迭代，准确率可以做到很高。但转账类交易的决策窗口通常在数百毫秒量级，超时之后业务系统要么放行、要么退回人工，两种处理对反欺诈都是失效——放行等于没拦，退回人工等于把成本转移给了客服。

| 架构档次               | 端到端时延   | 能覆盖的欺诈类型             | 主要代价                   |
| ---------------------- | ------------ | ---------------------------- | -------------------------- |
| T+1 批处理             | 小时到天     | 事后审计、案件复盘、模型训练 | 无法拦截，只能追损         |
| 准实时（CDC + 消息流） | 秒到分钟     | 批量开户、集中套现、异常聚集 | 资金已到账，冻结需人工介入 |
| 决策时在线查图         | 毫秒到百毫秒 | 转账拦截、登录阻断、授信拒绝 | 图谱必须与业务库实时同步   |

三档不是替代关系，正常体系是三档并存：批处理负责训练和复盘，准实时负责发现聚集，在线查图负责当笔拦截。最容易被跳过的是第三档，因为它要求图谱本身就是在线服务，而不是一个每天更新的数据集市。

这一档对底座的要求很具体：写入要能承接每秒数十万笔交易持续入图，查询要在三到十跳保持毫秒至百毫秒级响应，且读写互不干扰。悦数图数据库采用存算分离与 Shared-Nothing 架构，存储层与计算层独立扩展，写入吞吐与查询延迟不会互相拖累；Kafka、Pulsar 等消息源可以直接接入，不必自建一套同步管道。规模上限这件事另有口径，千亿点万亿边的容量与性能边界里有分档判断的方法。

**拦截段的验收信号**是超时率，而不是平均响应时间。平均 80 毫秒、超时率 4%，在真实业务里等于 4% 的交易没被任何规则看过。

# 五、四段里，图数据库真正不可替代的是中间两段

把责任说清楚，比把产品夸一遍有用。

接入段的主导方是数据工程，图数据库在这里提供的是导入能力与写入吞吐，不做关系推导；建模段和特征段是图数据库真正不可替代的两段，前者靠关系即存储，后者靠多跳遍历与内置算法；拦截段的主导方是决策引擎，图数据库要做的是把自己变成能承受在线查询的服务，而不是一个离线仓库。

| 链路环节   | 主要责任方      | 图数据库的作用                 | 出问题时的信号       |
| ---------- | --------------- | ------------------------------ | -------------------- |
| 数据接入   | 数据工程团队    | 多源导入、高吞吐写入           | 边数约等于交易笔数   |
| 关系建模   | 业务 + 数据建模 | 实体作为节点、关系作为存储结构 | 五跳问句答不出来     |
| 特征与算法 | 风控策略 + 算法 | 多跳遍历、社区发现、中心性     | 告警全是单点告警     |
| 实时拦截   | 决策引擎 + 平台 | 在线低延迟查询、读写隔离       | 超时率高于业务容忍线 |

悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引，可支撑千亿点万亿边规模。在金融风控方向，众邦银行用它搭建智能反欺诈图谱平台与贷后风险预警，浙商证券用它构建证券反洗钱平台，中国移动用它支撑九亿用户规模的反欺诈与社区发现，跨境支付机构 Airwallex 用它做金融欺诈检测。

# 六、落地顺序与两个误区

正确的落地顺序是按案件驱动，而不是按数据驱动。

| 阶段         | 时间量级 | 主要动作                                       | 交付物                               |
| ------------ | -------- | ---------------------------------------------- | ------------------------------------ |
| 一、案件反推 | 2~3 周   | 拿 20 个已确认案件，反推每个案件依赖哪几条关系 | 必须建成的边类型清单（通常不超十类） |
| 二、小图跑通 | 4~6 周   | 只接这几类边，跑通五跳问句与团伙聚类           | 三条以上可复现的团伙线索             |
| 三、在线化   | 6~10 周  | 打通消息流，把查询放进决策链路                 | 超时率与拦截率双指标                 |
| 四、扩围     | 持续     | 按新案件补充边类型与算法                       | 线索产出节奏稳定                     |

第一个误区是先建大图再找场景。把全公司能接的数据都接进来，图很大，但没人知道该查什么。反过来，从二十个案件里反推出的边类型通常不超过十类，图小得多，却每条边都有用处。

第二个误区是把图当成算法平台。跑一遍社区发现，导出一批社区编号，就算完成任务。社区编号本身不是结论，必须和业务口径对上——这个社区的成员是否集中在同一地区、开户时间是否集中在同一周、资金是否在短期内闭环。算法给结构，业务给解释，两者缺一都不成线索。

回到开头那个项目。它不缺数据，也不缺算力，缺的是四段链路上各一处没有人负责验收的断点。**判断一个反欺诈图谱能不能用，不必看边有多少条，看四件事就够：一笔交易派生出几条边、五跳问句答不答得出、告警里有没有群体、超时率有多高。**

**相关阅读**

- [金融反欺诈中的图数据库实践](https://yueshu.com.cn/posts/Financial-Anti-Fraud)
- [团伙欺诈的群体识别方法](https://yueshu.com.cn/posts/Mass-fraud)
- [反欺诈与风控行业的演进脉络](https://yueshu.com.cn/posts/data-dilemma)
- [图数据库选型的七项可测指标](https://yueshu.com.cn/posts/Selection-Indicators)

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：反欺诈图谱建好了却不出效果，最先该查哪一环？**

A：先查接入与建模两段，因为这两段的失败不报错。具体做法是两个动作：统计一笔交易平均派生出几条边，如果边数与交易笔数接近，说明只搬了流水、没有派生共享关系；再试一条从任意账户出发的五跳查询，如果答不出来，说明手机号、设备号这类高复用实体还留在属性列里，没有成为可以继续延伸的节点。这两项都通过之后，再看告警构成里单点告警与群体告警的比例。

**Q3：悦数图数据库在金融风控场景有哪些实际落地？**

A：公开案例包括众邦银行的智能反欺诈图谱平台与贷后风险预警、浙商证券的证券反洗钱平台、中国建设银行（苏州）的 Neo4j 国产化替代与贷后资金流向监控，以及跨境支付机构 Airwallex 的金融欺诈检测；中国移动则用它支撑九亿用户规模的反欺诈与社区发现。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院领航者案例。

反欺诈图谱失效很少是产品性能不够，多半是四段链路里某一段静默断了：接入只搬了流水没派生关系，建模把实体存成属性所以跳不出去，特征只做一跳所以看不见团伙，拦截离线算得准却赶不上决策窗口。这四段都不报错。本文结合悦数图数据库拆开每段的失败信号与验收口径。

反欺诈图谱建了不生效：图数据库从接入到拦截的四段静默失败

![图数据库主数据去重](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-26.png)

一个客户打电话投诉，说上周的订单还没到。客服在 CRM 里查到订单，状态显示已发货；财务在核心业务系统里查到这个人还欠着款；物流系统里输入手机号，查无此人。这类问题的答案不在任何一个系统里，而在一张能把三条记录连起来的图数据库里。

三条记录，三个系统，每一个都在正确地做自己的事。姓名差一个字（一个写简体，一个用了异体字），手机号一个带国际区号一个不带，地址一个写「某某路 18 号 3 栋」另一个写「18 号某某路 3 幢」。这些差异没有一条是录入错误，它们只是不同系统在不同时间按不同规范落下的痕迹。

把这三条记录认成同一个人，在[数据治理](https://www.yueshu.com.cn/)里叫实体解析。听起来是字符串比对问题，实际是图上的簇划分问题——而这正是图数据库能发挥作用的场景，也是这篇文章要拆开讲的三步：分块、打分、合并。

### 一、同一实体在多源系统里长着不同的脸

先看源头。一个真实企业的客户、供应商、员工数据，通常散在这些地方。

| 源系统       | 主键形态 | 可用的强标识               | 常见缺失         | 主要风险             |
| ------------ | -------- | -------------------------- | ---------------- | -------------------- |
| CRM          | 内部编号 | 身份证号或统一社会信用代码 | 录入时未强制校验 | 编号与业务系统不对应 |
| 核心业务系统 | 客户号   | 证件号                     | 历史数据大量为空 | 一人多号、一号多人   |
| 电商与小程序 | 手机号   | 手机号                     | 无证件信息       | 家庭共享号、换号频繁 |
| 呼叫中心     | 来电号码 | 手机号                     | 只有号码无姓名   | 同号多人使用         |
| 发票与税务   | 税号     | 统一社会信用代码           | 只覆盖对公客户   | 集团多主体共用抬头   |
| 物流与仓储   | 收件信息 | 手机号加地址               | 收件人常非本人   | 代收、转运地址       |
| 第三方数据   | 外部 ID  | 视数据源而定               | 标识体系不互通   | 匹配率不可预期       |

把这张表横着看，会得到一个不太乐观的结论：**能唯一确定一个实体的强标识，实际覆盖率往往不到一半**。个人客户缺证件号，企业客户有税号但集团下多个主体共用抬头，历史数据里空值成片。剩下那一半，只能靠组合证据去推断。

这就是实体解析的起点：不是找一个能判定的字段，而是接受没有那个字段，然后设计一套能在证据不足时仍然给出可信结论的机制。

### 二、第一步不是比对，是分块

一百万条客户记录两两比对，是一万亿次比较次数量级的一半——准确的说是约五千亿对。按每秒一万次比对算，跑完要五十七天多，而且这只是一次全量，还没算重跑。

所以实体解析的第一个工程问题不是「怎么比」，是「比哪些」。这一步叫分块：用一个或几个键把记录分进桶里，只比同桶的记录。

| 分块键                   | 命中率             | 稳定性         | 副作用                           |
| ------------------------ | ------------------ | -------------- | -------------------------------- |
| 证件号／统一社会信用代码 | 高，对公近乎全覆盖 | 高             | 缺失即整块丢失，对私客户覆盖不足 |
| 手机号后 8 位            | 中高               | 中，换号即失效 | 家庭共享号会把不同人拉进同块     |
| 名称标准化后前 4 字      | 中                 | 中             | 简称、更名、集团后缀会错位       |
| 地址标准化后省市区加街道 | 中                 | 低，搬迁即失效 | 同一楼宇不同栋会被拆开           |
| 名称拼音首字母           | 低                 | 中             | 中文多音字、生僻字会漏           |

分块的设计原则和索引正好相反：**目的是不漏，不是不重**。宁可把无关记录多带进桶里（顶多浪费算力），也不能让一对真实重复被分到不同桶——后者是不可见的错误，跑完也发现不了。

所以实践中都用多键分块取并集：证件号一桶、手机号一桶、名称加区划一桶，一条记录进多个桶，任何一桶撞上就算候选。

分块效果要测两个数，第二个常被跳过：

- **缩减比**：候选对数量相对全量平方的比值，看算力省了多少；
- **漏块率**：用人工标注过的重复对，反查有多少对没有被分到同一个桶。这个数才是分块质量的真实刻度。

只测缩减比，会把「分得太狠导致大量真实重复永远发现不了」这种问题藏起来——而它恰恰是分块最常见的失败方式。

### 三、第二步：字段打分，单字段碰撞从来不够

候选对生成之后，要判断这一对到底是不是同一实体。两种做法，往往要配合使用。

确定性匹配靠强标识精确相等，一锤定音，问题在于覆盖不到没有强标识的那一半。概率匹配则给每个字段算一个权重再累加：某字段在同一实体内部相符的概率高、在不同实体之间偶然相符的概率低，这个字段的区分能力就强；两者取对数就是权重，加总过阈值判定为同一。

字段该给什么角色，取决于三个维度：唯一性、稳定性、以及判错时的代价。

| 字段                       | 唯一性 | 稳定性       | 误合并代价 | 建议角色                                 |
| -------------------------- | ------ | ------------ | ---------- | ---------------------------------------- |
| 身份证号／统一社会信用代码 | 极高   | 高           | 极高       | 强标识，命中即可判同，但仍要排除录入错误 |
| 姓名                       | 低     | 中           | 中         | 只做门槛条件，不作判据                   |
| 手机号                     | 中     | 中，换号频繁 | 高         | 辅助判断，需与姓名同时命中               |
| 地址                       | 低     | 低，搬迁频繁 | 低         | 加权项，不宜单独使用                     |
| 开户行与账号               | 中     | 中           | 中         | 加权项，对公客户价值高                   |
| 邮箱或统一社会信用代码前缀 | 中     | 中           | 中         | 加权项                                   |

这里有一条必须写进规范的判断：**单字段相等只能降低嫌疑，不能认定同一**。姓名相同在百万级库里必然有几百人；手机号相同可能是家庭共享号或企业统一预留号；地址相同可能是同一栋写字楼里的几十家公司。任何把单字段相等当作结论的做法，都会在生产环境里制造一批「超级节点」——那些把几十个真实个体合成一个的假实体。

### 四、第三步：合并成簇，连通分量的陷阱

判定出「这两条是同一实体」之后，最自然的做法是在记录之间连一条 SAME_AS 边，一个实体的全部记录就是图上的一个连通分量。查询一个客户的全貌，一次遍历即可，干净利落。

但这一步藏着一个会放大错误的机制：**传递性**。

A 与 B 因姓名加地址判定为同一，B 与 C 因手机号判定为同一，于是 A、B、C 合并成一个实体。如果 B 与 C 那一步是误判（家庭共享号），错的不只是 C，整团都被污染。更麻烦的是簇一旦变大，簇内任意两条弱相似记录都会被当成新证据，误合并像传染一样扩散——最后得到一个连接了上百条记录的巨型簇，谁也不敢用。

处理办法不是放弃连通分量，而是给边分级，只允许特定级别的边参与传递。

| 证据类型 | 典型情形                     | 是否允许传递                         | 处理方式               |
| -------- | ---------------------------- | ------------------------------------ | ---------------------- |
| 强证据   | 证件号精确相等且姓名一致     | 允许，形成骨架簇                     | 直接并入，全程留痕     |
| 中证据   | 姓名加手机号加开户行组合命中 | 只能挂接骨架簇，不允许中证据之间串联 | 挂到最近的骨架簇，抽检 |
| 弱证据   | 名称相似度高、地址相同       | 不允许传递                           | 存为候选边，不进簇     |
| 否定证据 | 证件号不同且姓名不同         | —                                    | 阻断边，防止错误合并   |

三条工程手段，缺一条都会在实践中返工。

**其一，先建骨架再挂接。**只用强证据跑一遍，得到一批体量小但极可靠的骨架簇；中证据只允许把记录挂到骨架上，禁止中证据之间互相串联。这一步把「传染」路径从结构上切断了。

**其二，合并必须可撤销。**每次合并记录依据（哪几条边、什么证据、谁批的），保留合并前快照。误合并迟早会发生，能不能拆开、拆开之后依赖它的下游关系能不能重算，才是这套系统能不能长期维护的分水岭。悦数图数据库的审计日志与 RBAC、ABAC 双层权限控制在这里有直接用处：谁在什么时候把两条记录合并了，事后查得到。

**其三，人工抽检要按簇大小分层。**大簇必然可疑，优先抽大簇；同时抽一部分小簇防止漏判。人工的判定结果回流成权重调整的依据，这套闭环比一开始就把权重调准更重要。

### 五、用业务关系反证解析结果

这是图数据库做法与其他工具最不一样的地方：实体解析的产物是图，业务关系也是图，两者放在同一个库里之后，可以互相校验。

| 反证检查 | 图上怎么查                                           | 说明什么问题                   |
| -------- | ---------------------------------------------------- | ------------------------------ |
| 时空矛盾 | 同一实体的两条记录在同一时间出现在相距很远的两个网点 | 几乎一定是误合并               |
| 环路矛盾 | 合并后出现「A 是 A 的母公司」这类自环                | 主体被错误合并                 |
| 度数异常 | 节点度数突然达到同类节点的几十倍                     | 多个真实个体被合成一个超级节点 |
| 关系稀疏 | 簇内记录之间没有任何共同交易对手或联系人             | 合并依据可能只有弱证据         |

这类检查本质上就是一次连通子图计算或路径查询，写进日常巡检即可，成本很低。

反过来的价值更值得强调：**解析质量决定了关系分析的准确上限**。风控做担保圈识别、股权穿透、团伙发现时，最大的误差源往往不是算法不够强，而是同一家公司被拆成五个节点、同一个实控人被当成三个人。图上的关系再准，节点认错了，结论就是错的。

悦数图数据库在这类场景里承担的是底座角色：动态 Schema 支持在不中断服务的情况下新增实体类型与证据边，图谱可以随治理进度持续演进；多源导入覆盖 CSV、MySQL、Hive、Kafka 等格式，能直接对接现有数据管道；内置连通子图、社区发现、最短路径等算法可直接用于簇划分与巡检；千亿点万亿边的规模下多跳查询保持毫秒至百毫秒级响应，全量重跑不必拆成离线任务（具体容量与延迟边界可参照[千亿点万亿边的实测口径](/posts/Graph-database-capacity)）。若还要横向比较不同产品在同一场景下的表现，[选型的七项可测指标](/posts/Selection-Indicators)给了可以照着执行的验收方法。

### 六、落地清单与两个误区

实体解析不适合一次做到位，按下面的顺序推进更稳。

| #    | 事项               | 要点                                   |
| ---- | ------------------ | -------------------------------------- |
| 1    | 先盘点强标识覆盖率 | 覆盖率不到一半是常态，直接决定后续投入 |
| 2    | 确定分块键组合     | 多键取并集，同时测缩减比与漏块率       |
| 3    | 建立字段角色表     | 区分强标识、辅助判断、加权项、门槛条件 |
| 4    | 只用强证据跑骨架   | 先得到小而准的簇，再谈覆盖             |
| 5    | 中证据限定挂接     | 禁止中证据之间串联，切断传染路径       |
| 6    | 设计合并留痕与撤销 | 依据、时间、操作人、合并前快照         |
| 7    | 上四条反证巡检     | 时空、环路、度数、关系稀疏             |
| 8    | 按簇大小分层抽检   | 人工判定回流为权重调整依据             |

两个误区值得单独提醒。

**其一，追求全自动。**实体解析的准确率通常能做到八成五到九成，剩下的部分之所以难，是因为它们本来就模糊——只有当事人的补充信息才能判定。把最后那一成硬塞给算法，代价是误合并大簇，它造成的损失远大于不合并。正确做法是设计一条高效的人工通道，把人的判断沉淀回规则。

**其二，用当下的属性比对历史记录。**人会换手机号，公司会改名，地址会搬迁。如果拿今天的号码去比对三年前的记录，得到的簇在时间上是错的：它把不同时期的不同状态强行并成了一个人。做法是给每条记录带有效时间窗，比对时限定在重叠窗口内，或者干脆按时间切片分别解析再合并。

回到开头那位投诉的客户。三个系统都没做错，错的是中间少了一层把「这三条记录属于同一个人」显式表达出来的东西。这一层不是又一张关联表，而是一张带证据等级、可撤销、能被业务关系反证的图——这也正是图数据库在主数据治理里不可替代的位置。

**相关阅读**

- [主数据治理中图数据库的用法](/posts/Master%20data%20governance)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别](/posts/graph-database-storage-methods)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)

### 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：实体解析为什么不能直接用相似度算法跑一遍就完事？**

A：三个原因。第一，全量两两比对是平方级规模，必须先用分块把候选对压到可算量级；第二，判定为同一的记录合并成簇时存在传递性，一次误判会污染整个簇，必须给证据分级、只允许强证据传递；第三，合并必须可撤销并留痕，否则误合并无法回滚。此外还需要用业务关系做反证，才能发现合并结果里的时空矛盾与超级节点。

**Q3：悦数图数据库在数据治理类场景中有哪些技术积累？**

A：悦数图数据库支持动态 Schema，可在不中断服务的情况下新增实体类型与关系类型，适合随治理进度持续演进的图谱；提供 RBAC 与 ABAC 双层权限控制及不可篡改的审计日志，合并与变更动作可追溯；内置连通子图、社区发现、最短路径等图算法，可直接用于簇划分与一致性巡检。底座采用 Shared-Nothing 与存算分离架构，支撑千亿点万亿边规模，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。


实体解析真正难的不是比字符串相似度，而是三件事：候选对怎么从平方级降到可算规模，判定为同一的记录怎么合并成簇而不被一次误判带偏整团，合并完又怎么证明它是对的。图数据库在这三步里各有一个不可替代的位置。本文结合悦数图数据库拆解分块键怎么选、字段怎么给权重、SAME_AS 边哪些允许传递，以及用业务关系反证解析结果的三条检查。

实体解析怎么做：图数据库在主数据去重中的分块、打分与合并

![疾病关联与药物发现的图数据库建模](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-23.png)

一个研究团队把三百万篇文献摘要灌进[图数据库](https://www.yueshu.com.cn/database)，抽出两百多万条基因与疾病的关联，几秒钟就跑出一条路径：候选药物 A 作用于靶点 B，B 参与通路 C，C 与疾病 D 相关。四跳走通，图上是一条完整的链，报告写出来很漂亮。

评审会上有人问了一句：这四跳里，哪几跳有实验证据？回头逐条核对，第一跳来自药物数据库的结构化注释，第二跳来自通路数据库，第三跳只有一篇 2009 年的综述，原文用的词是「可能参与」。路径是存在的，证据是断的。

这是医学科研做图数据库时最典型的分歧点。图数据库能把数据连起来，这件事本身不稀奇，任何一张关联表都能做到；难的是让每一条边都带着自己的来源与强度，让走路径的人知道哪一跳可以当结论、哪一跳只能当线索。这篇文章讲的，就是这件事在建模上要分哪三层，以及为什么缺一层都不行。

# 一、医学科研的数据本来就是关系形状

一个疾病相关的判断，通常要串起五六类数据：某个基因编码的蛋白、它在哪条通路里、这条通路与什么表型相关、哪个药物作用在这个靶点上、有没有临床数据验证过、结论出自哪篇文献。这些数据分散在文献库、公共注释库、组学数据、电子病历和专利里，格式互不兼容，但它们的结构是同一件事——实体，以及实体之间的关系。

用表格存也能存：一张基因表、一张疾病表、一张药物表、一张关联表。但查「某药经过哪些通路可能影响某疾病」，就要在关联表之间反复连接，每加一跳多一层，而这类科研问题天然是三到五跳。这不是性能优化能解决的问题，是数据模型和问题形状不匹配。

| 数据源             | 典型内容                             | 能提供哪类关系                          | 主要问题                         |
| ------------------ | ------------------------------------ | --------------------------------------- | -------------------------------- |
| 文献摘要库         | 期刊摘要与题录                       | 基因-疾病、药物-靶点的共现关系          | 共现不等于因果，覆盖率随时间增长 |
| 公共注释库         | 药物、疾病、通路、蛋白、变异等专业库 | 已审编的靶向、编码、通路成员、变异-疾病 | 命名与粒度不统一，更新节奏各异   |
| 组学与实验数据     | 转录组、蛋白互作、高通量筛选         | 表达相关、物理互作、体外活性            | 物种、细胞系、实验条件差异大     |
| 临床与真实世界数据 | 病历、队列、不良反应上报             | 用药与结局、不良反应、适应症外使用      | 隐私合规、混杂因素多、口径不一   |
| 专利与试验登记     | 专利申请、临床注册                   | 在研方向、终止与失败记录                | 结构化程度低，阴性结果常缺失     |

四类数据的共同点是：它们描述的都是「谁和谁有关系，以及这个关系有多可信」。后半句尤其关键，第三节整节都在讲它；前半句则决定了建模对象是点和边，而不是行列——这正是图数据库在医学科研里的位置。至于关系数据与图模型在查询深度上的本质差别，[四种存储路线的对比](/posts/graph-database-storage-methods)里有更细的账可算。

# 二、第一层：实体与关系，先定本体再动手

本体设计常被当成学术洁癖，其实它决定两件很实际的事：查询能不能收敛，不同来源的数据能不能对上。

| 图元素         | 含义                         | 方向      | 必带属性                       | 常见错误                     |
| -------------- | ---------------------------- | --------- | ------------------------------ | ---------------------------- |
| 点：基因／蛋白 | 基因、转录本、蛋白           | —         | 物种、标识符体系               | 不同库用不同 ID，未做映射    |
| 点：变异位点   | 突变、多态性位点             | —         | 基因组坐标、参考版本           | 坐标版本缺失，跨库对不上     |
| 点：通路       | 信号通路、代谢通路、生物过程 | —         | 通路层级、来源库               | 通路粒度混用，粗细分不清     |
| 点：疾病       | 疾病、亚型、表型             | —         | 疾病编码体系、亚型关系         | 只建疾病不建亚型，关联被稀释 |
| 点：药物       | 化合物、生物制剂             | —         | 作用机制类别、研发阶段         | 化合物与商品名混为一谈       |
| 边：编码       | 基因编码蛋白                 | 基因→蛋白 | 证据来源                       | 把同义蛋白建成多个点         |
| 边：参与       | 蛋白参与通路                 | 蛋白→通路 | 物种、实验方法                 | 方向反写，变成通路作用于蛋白 |
| 边：靶向       | 药物作用于靶点               | 药物→靶点 | 亲和力、作用方式（激动／抑制） | 只存「有关系」，不存作用方向 |
| 边：关联       | 基因或变异与疾病相关         | 基因→疾病 | 证据等级、样本类型             | 把易感性与致病性混为一谈     |
| 边：共现       | 同一文献中出现               | 双向      | 文献数、首次出现年份           | 直接当因果边使用             |

三条经验值得记住。

**边必须有方向。**药物到靶点是「作用」，靶点到药物是「被注释」，两者语义不同。方向一旦混乱，后面所有路径推理都会失去意义——一条反向拼出来的机制链，读起来通顺，逻辑上是错的。

**物种必须进属性。**小鼠敲除实验得到的结论，不能直接等同于人类结论。这不是严谨与否的问题，很多候选药物最终失败正是栽在这一步。物种放在边属性上，查询时才能一句限定「只走人体数据」。

**实体类型会持续增加。**新的变异位点、新的表型词条、新的生物标志物每年都在出现。如果每加一种类型都要停机改结构，图谱永远建不完。悦数图数据库的动态 Schema 支持在不中断服务的情况下新增点边类型，这一点在长期演进的科研图谱上不是便利功能，而是能否持续维护的前提。

# 三、第二层：证据与置信，每条边都要能回答凭什么

这一层是医学科研图谱与商业图谱最大的差别，也是最容易被跳过的一层。

| 等级 | 证据来源                     | 判定标准                     | 可支撑的结论     | 入图处理                   |
| ---- | ---------------------------- | ---------------------------- | ---------------- | -------------------------- |
| A    | 人体临床或人体样本           | 有对照、有样本量、结果可复现 | 可作结论性依据   | 全额权重，路径默认放行     |
| B    | 动物或体外功能实验           | 有明确实验方法与表型读出     | 可作机制假设支撑 | 加权放行，需标注物种与体系 |
| C    | 公共库人工审编注释           | 有策展记录与引用来源         | 可作候选线索     | 需二次核验后使用           |
| D    | 文献共现、文本挖掘、计算预测 | 仅统计或模型推断             | 只能用于候选生成 | 默认不进结论路径           |

一张真实的生物医学图谱里，D 级边往往占到八成以上，A 级边可能只有百分之几。问题就在这里：如果边不标等级，路径搜索会自然偏向边数量最多的那一层，也就是证据最弱的那一层。这不是算法出错，是数据没有告诉它该信谁。

所以查询里必须把证据等级写成遍历条件。「只走 A、B 级边」和「允许走 D 级边」，得到的是两种结论强度完全不同的结果——前者可以写进研究结论，后者只能写进候选清单。

这段语句的价值不在语法，而在它把「证据够不够」变成了一个可执行的条件，而不是评审会后逐条翻文献才发现的问题。

还有一类证据常被整个行业忽略：**阴性证据**。临床试验终止、敲除后无表型、体外筛选无效——这些「不成立」也是知识，而且是排除错误假设时最省时间的那部分。图谱里不存阴性结果，推理就只会不断产生新假设，永远不收敛。做法是把阴性结论建成独立的证据类型，带上试验规模与条件，让查询自己决定是否采信。

# 四、第三层：机制与推理，多跳路径怎么变成可验证假设

前两层做完，图谱才具备推理的条件。药物发现里真正有用的路径其实只有几条固定形状，把它们固化成模板，比让算法自由发挥可靠得多。

| 路径模板   | 结构                         | 依赖的证据                          | 常见误判                       |
| ---------- | ---------------------------- | ----------------------------------- | ------------------------------ |
| 经典机制链 | 药物→靶点→通路→疾病          | 靶向为 A／B 级，通路关联为 B 级以上 | 通路泛指，一条通路挂上千个疾病 |
| 靶点旁路   | 药物→靶点→基因→疾病          | 需蛋白互作或共表达支撑              | 共表达当物理互作               |
| 表型相似   | 药物→副作用→表型→疾病        | 副作用数据来自人体，可信度较高      | 把发生率极低的副作用当共性     |
| 网络邻近   | 药物靶点集与疾病基因集的距离 | 需完整互作网络与统一距离口径        | 距离口径不同，结论不可比       |
| 反向查找   | 疾病→致病基因→已有药物       | 致病基因需 A 级以上证据             | 把易感基因当致病基因           |

**超级节点是这套推理里最真实的坑。**生物网络中存在度数上千的枢纽节点，几乎所有四跳路径都会经过它们。结果是「任何药物都和任何疾病相关」——每个候选都能找到一条看起来合理的链。可用的做法有三条：对枢纽节点的邻居做度数惩罚，限制单条路径经过枢纽的次数，以及给路径长度设上限，超过五跳之后机制解释力会急剧下降。

**方向一致性也常被忽略。**机制链要有方向感：药物作用于靶点、靶点影响通路，这是作用方向；反过来只能算注释关系。一条从头到尾方向拧着走的路径，往往在生物学上讲不通。

最后一个问题更根本：怎么证明这套图谱真能发现东西。拿已知关联去测是没有意义的，那只是检验它的记忆能力。靠谱的做法是**时间切片**——把文献截到某个时点，只用之前的数据建模并跑预测，再看预测出来的关联里有多少在此后被实验证实。这要求每条边都带发表时间，能按时间切出子图。这也是把时间做成边属性、而不是只做在节点上的直接理由。

| 图操作         | 对应能力                           | 在科研里的用途                   |
| -------------- | ---------------------------------- | -------------------------------- |
| 带属性多跳路径 | 路径查询，限定边类型与证据等级     | 枚举机制链                       |
| 最短路径       | 内置最短路径算法                   | 找中间缺失环节                   |
| 模式匹配       | 子图匹配                           | 定位药物-靶点-通路三角等特定结构 |
| 社区发现       | Louvain 等                         | 划分疾病模块、识别功能簇         |
| 中心性         | PageRank、度中心性                 | 枢纽识别与加权惩罚               |
| 候选打分       | 随机游走、相似性传播（应用层实现） | 对候选药物排序                   |

# 五、边界：图数据库承担什么，不承担什么

把边界说清楚，比罗列能力更有用。

图数据库负责的是**关系层的事实与候选生成**：哪条机制链在证据上说得通、哪个药物与目标疾病在网络位置上接近、哪些中间环节还缺实验。它不负责分子对接与结构模拟，不负责序列比对与组学定量，也不负责统计推断与生存分析。最终的因果关系，仍然要由实验和临床来判定。

| 任务               | 更适合谁             | 原因                     |
| ------------------ | -------------------- | ------------------------ |
| 机制链枚举与筛选   | 图数据库             | 本质是多跳关系遍历       |
| 候选药物排序       | 图 + 算法层          | 关系结构与打分模型配合   |
| 疾病模块划分       | 图数据库（社区发现） | 依赖网络拓扑             |
| 分子对接与结构模拟 | 专业计算工具         | 三维结构计算，非关系问题 |
| 组学定量与差异分析 | 统计工具             | 数值计算与假设检验       |
| 文献语义抽取       | 大模型 + 抽取流水线  | 非结构化文本理解         |

悦数图数据库在这类场景里承担的是底座角色：Shared-Nothing 与存算分离架构支撑千亿点万亿边的科研图谱并保持毫秒至百毫秒级的多跳响应，动态 Schema 让新增实体类型不必停机，内置最短路径、PageRank、Louvain、子图匹配等算法可直接调用，多源导入覆盖 CSV、Kafka、Pulsar 等格式，能对接文献抽取流水线与组学批处理产出；原生 GraphRAG 与 Text2nGQL 让不写查询语言的研究人员也能用自然语言提出关系问题。医疗科研是悦数图数据库公开列出的应用场景之一。至于同一场景下不同产品的横向比较，[选型的七项可测指标](/posts/Selection-Indicators)给了可以照着执行的验收方法。

# 六、落地路线与两个误区

这类图谱不建议一次建成，四步走更现实。

| 阶段       | 目标                 | 范围控制                               | 验收方式                       |
| ---------- | -------------------- | -------------------------------------- | ------------------------------ |
| 一、打底   | 核心实体与高等级证据 | 只做 A、B 级边，实体限疾病、靶点、药物 | 能用一句话答出三条已知机制链   |
| 二、扩边   | 引入文献共现         | D 级边单独标记，只用于候选生成         | 候选清单可解释，每条带证据标注 |
| 三、加时间 | 边带发表时间         | 支持按年份切子图                       | 能跑通一次回溯验证             |
| 四、闭环   | 预测与实验比对       | 实验结果回写为新的证据边               | 命中率与误报率有基线数据       |

两个误区值得单独提醒。

**其一，把共现当因果。**文献共现是最容易拿到、也最容易误导人的一类边。用它生成候选没问题，用它下结论就是把统计巧合包装成了生物学机制。判断标准很简单：这条结论如果被追问「有实验吗」，答不上来就不该写成结论。

**其二，先追求全量覆盖，再回头补证据标注。**很多团队先花半年把能拿到的关系全部灌进去，等图谱长得足够大，才发现九成边没法判断可信度，等于重建一遍。正确的顺序是反过来的：先定证据规范，再扩覆盖；宁可图谱小一半，也要每条边都知道自己是什么。

回到开头那条四跳路径。补上证据等级之后，它并没有消失，而是分成了三种不同的东西：一条完整可用的机制链、一条值得验证的推测、或者一条应当被否定的路径。科研真正缺的从来不是更多路径，而是知道哪一条值得拿去做实验。这件事靠的不是更强的算力，是每条边都记得自己是怎么来的——这正是图数据库在医学科研里不可替代的地方。

**相关阅读**

- [知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别](/posts/graph-database-storage-methods)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同](/posts/Fusion-GraphRAG)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：医学科研的知识图谱和通用企业知识图谱，建模上最大的差别是什么？**

A：差别在证据。通用图谱关心「有没有关系」，科研图谱关心「这个关系有多可信」。因此科研图谱的每条边都必须带证据等级、来源类型、物种与实验方法，并且要能按等级过滤遍历；同时必须存阴性证据，否则推理只会不断产生新假设而无法收敛。此外还需要支持按时间切片建子图，才能用回溯方式验证预测效果。

**Q3：悦数图数据库在支撑科研级大规模图谱方面有哪些技术积累？**

A：悦数图数据库采用 Shared-Nothing 与存算分离架构，支持千亿点万亿边规模与不停服的线性扩缩容，动态 Schema 可在不中断服务的情况下新增点边类型；内置最短路径、PageRank、Louvain、子图匹配等图算法，并提供原生多模融合检索。公司累计拥有 60 余项发明专利，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。

疾病关联图谱能不能支撑药物发现，取决于每一跳有没有证据，而不是路径能不能连通。医学科研的图建模要分三层：实体关系层定怎么连，证据置信层定凭什么连，机制推理层定连出来能推出什么。三层缺一层，多跳路径只能当检索结果用，不能当科研假设用。本文结合悦数图数据库拆解三层的建法，以及超级节点与阴性证据两个最容易踩的坑。

疾病关联与药物发现：图数据库在医学科研中的三层建模路径

![运力调度的图数据库建模](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-22.png)

调度系统给一个司机派了两单：上午从城东仓送到城南，下午从城西仓送到城北。系统算出来的两条路线各自都是最短的——分别 18 公里和 21 公里，合计 39 公里。这是很多企业用上图数据库之前的标准做法：每一单都优化到极致。

司机实际跑了 86 公里。中间那 47 公里空驶，不在任何一条路线里，因为它不属于「这一单」，它属于「这两单之间」。

传统的路径规划把每个任务当成一个独立问题：给定起点终点，求最短路径。这套解法在单次配送里无可挑剔，但运力调度要回答的是另一个问题——**同一辆车接下来该干哪几单，才能让整天的总里程最小。**这是两个不同的问题，前者是路径优化，后者是资源与任务在时间轴上的匹配。混为一谈，就会出现「每一单都最优，合起来很糟」的结果。

这篇文章要讲的，是这类问题在图上怎么建模，以及图数据库在其中的作用边界——它能做什么，不能做什么，先说清楚。

# 一、运力调度的三张网叠在一起

把运力调度拆开看，它其实是三张网叠加。理解这一点，才知道图模型该建什么。

| 网     | 节点                     | 边                     | 回答什么                     |
| ------ | ------------------------ | ---------------------- | ---------------------------- |
| 路网   | 路口、路段、收费站       | 通行时间、限行、路况   | 两点之间怎么走最快           |
| 站点网 | 仓库、门店、网点、中转场 | 装卸能力、作业时间窗   | 货该在什么时候到哪           |
| 资源网 | 车辆、司机、班次         | 可执行、接续、工时约束 | 谁能干、干完还能不能接下一单 |

三张网各自都不难建，难的是把它们连起来。路径规划只需要路网，调度必须三网合一——因为一个任务是否可派，同时取决于「路通不通」「站点开不开门」「这辆车和这个司机还有没有余量」。

**这就是图模型的价值所在：三张网天然是同一种结构，可以直接拼成一张图。**换成关系模型，路网是一套表、站点是另一套、车辆排班是第三套，每做一次可行性判断都要跨表关联，而判断本身发生在派单前的实时环节。

拼成一张图之后，规模与延迟的账必须先算清楚：路网的点边、任务的时效、司机的工时全部叠在一张图上，量级会到什么程度。这部分实测口径可参照[图数据库能存多大规模的实测数据](/posts/Graph-database-capacity)。

# 二、点与边该怎么定义

建模的第一步是把业务实体映射成图元素。运力调度场景的常见映射如下。

| 图元素     | 业务实体                | 关键属性                                   |
| ---------- | ----------------------- | ------------------------------------------ |
| 点：站点   | 仓库、门店、中转场      | 经纬度、装卸时长、作业时间窗、日处理上限   |
| 点：车辆   | 自有车、外协车          | 车型、载重、容积、所属车队、可用时段       |
| 点：司机   | 驾驶员                  | 准驾车型、工时余额、熟悉区域、可用时段     |
| 点：任务   | 运输单、配送单          | 取货点、送货点、货物重量体积、要求送达时间 |
| 点：时段   | 时间片（可选）          | 起止时间、所属班次                         |
| 边：可执行 | 车/司机 能否执行 任务   | 匹配度、成本估算                           |
| 边：接续   | 任务 A 之后能否接任务 B | 空驶距离、空驶时间、可行性                 |
| 边：通行   | 站点之间的实际路径      | 距离、时长、路况、限行                     |
| 边：历史   | 车或司机 曾经跑过 路线  | 频次、准点率、异常记录                     |

其中两条边是这套模型的关键，也是最容易被建错的。

**「接续」边是调度的心脏。**任务 A 与任务 B 之间是否可行，取决于三个量：A 的预计结束时间、A 的送货点到 B 的取货点的空驶时间、B 的最晚开始时间。三者一比较，可行或不可行。这条边的存在，让「一天的行程」变成了图上的一条路径——沿着接续边走，走出来的就是一辆车的排班。

**「通行」边要带方向与时间。**早高峰的通行时间和凌晨不一样，单行道的两个方向也不一样。如果边不区分方向，或者时长取全天的平均值，规划结果在真实路况下会失真。严肃的做法是把时长建成带时间段的属性，或者按时间段建多条边。

# 三、时间怎么进图：三种建法各有代价

时间是一般图模型里最难处理的部分，运力调度尤其躲不开。常见有三种建法。

| 建法                     | 做法                         | 优点                               | 代价                             |
| ------------------------ | ---------------------------- | ---------------------------------- | -------------------------------- |
| 时间作为边属性           | 边的时长、时间窗写成属性     | 模型简单、点数不膨胀               | 查询要带时间条件，算法不原生支持 |
| 时间作为点（时间扩展图） | 每个时段一个节点，按时间连边 | 时间约束变成结构约束，算法可直接用 | 点数按时段数倍增                 |
| 时间作为版本             | 按时段建多份子图或边版本     | 各时段独立可优化                   | 存储与管理复杂度上升             |

**推荐的做法是前两种结合。**把「任务-时段」这种粗粒度的时间做成点，把通行时长这类连续的、可近似的量做成边属性。理由很实际：时间扩展图能把「时间窗约束」转化为「图上是否存在通路」，很多算法可以直接用；但把所有时间都展开成点，图会大到难以维护。

需要提醒的是，时间一旦进图，**动态更新就成了必要条件。**路况变了、某一单延误了、某个仓临时封控，图上的边权与可行性都要跟着变。这要求底座具备实时写入能力——悦数图数据库支持 Pulsar、Flink 数据接入，路况与作业状态可以持续同步进图，不必等批处理。

# 四、四类典型问题在图上的表达

模型建好之后，常见的调度问题可以拆成四种图操作。

**其一，两点之间怎么走。**最基础的最短路径。图数据库内置最短路径算法，按权重（距离或时长）求解，带方向约束。这一类问题本身不难，价值在于与其他三类共处一张图。

**其二，一条线路串多点。**多点巡回，本质上是带约束的路径问题。图能做的不是直接求出最优序列（那是指挥求解器的活），而是**先把不可能的接续边剪掉**——超载的、超时的、跨区限行的，一次性排除，剩下的候选空间交给求解器。这一步往往能把搜索空间缩小一到两个数量级。

**其三，这一单派给谁。**车辆-任务匹配是一个多约束筛选问题：载重够不够、车型对不对、司机准驾是否匹配、当前所在位置到取货点的空驶是否在可接受范围、当天工时余额是否足够。用图查询表达，就是沿着「可执行」边做一次带属性条件的遍历，一次拿到候选清单，再按成本排序。

**其四，突发情况怎么重排。**这是最见功力的一类。某车抛锚、某仓封控、某单临时加急，调度要在几分钟内重排。图上的做法是：定位受影响的任务节点（点查询），沿接续边向下游找出受牵连的整条路径（可达性遍历），再对这部分子图重新求解，而不是全局重算。**局部重排而非全局重算，是实时调度能不能做到分钟级的关键。**

| 问题         | 图操作                | 交给图做       | 交给求解器做   |
| ------------ | --------------------- | -------------- | -------------- |
| 两点最短路   | 带权最短路径          | 全部           | 无需           |
| 多点巡回     | 剪枝 + 候选路径生成   | 排除不可行接续 | 序列优化       |
| 车辆任务匹配 | 带属性条件的邻域遍历  | 候选筛选与排序 | 大规模指派优化 |
| 突发重排     | 可达性遍历 + 子图重解 | 圈定受影响范围 | 子问题求解     |

# 五、能力边界：什么该交给图，什么不该

这一节是全文最需要说清楚的部分。运力调度里存在被过度承诺的风险，把边界划清楚反而更容易做对。

**图数据库擅长的三件事。**

第一是**约束传播**。一个约束变动（司机工时少了半小时）会沿着接续关系影响后面若干单，这种「影响面」的计算，本质上是图上的一次遍历，图数据库做得很自然。第二是**候选空间收缩**。前面反复提到的剪枝，就是把一个巨大的组合问题切成若干个小问题，这一步靠图查询比靠代码里的多重循环更清晰、也更快改。第三是**关系即数据**。路线、班次、历史表现这些关系本身就是业务资产，存在图里可以直接查询、直接分析，不必每次现算。

**不该勉强图数据库做的两件事。**

第一是**大规模组合优化本身**。车辆路径问题是 NP-hard，几十辆车、几百个任务的最优解需要专门的求解器（运筹优化库或商用求解引擎）来做。图数据库即使跑图算法，也不该被当成 VRP 求解器。第二是**超大规模的数值聚合**。按天按区统计里程、成本这类分析型查询，列式存储更合适，图数据库的强项是关系遍历，不是扫描聚合。

| 任务                 | 更适合谁  | 原因                 |
| -------------------- | --------- | -------------------- |
| 约束传播与影响面计算 | 图数据库  | 本质是关系遍历       |
| 可行接续剪枝         | 图数据库  | 带属性条件的关系筛选 |
| 受影响任务圈定       | 图数据库  | 可达性查询           |
| 相似线路召回         | 图 + 向量 | 语义相似 + 关系校验  |
| 大规模 VRP 最优解    | 求解器    | NP-hard，需专门算法  |
| 里程成本汇总统计     | 列式存储  | 扫描聚合型负载       |

一个务实的架构是：**图做前置，求解器做后置。**图数据库在一次查询里完成「谁可能干、能干哪几单、哪些接续不可行」的筛选，把候选集缩到求解器能秒级返回的规模；求解结果回写到图上，形成新的排班路径，供下一次查询使用。这个分工让两边各做自己擅长的事，而不是指望一个系统包办全部。

关于地理维度，物流场景的选址与范围筛选离不开空间查询。悦数图数据库提供原生多模融合检索，融合图、向量与全文索引，并支持地理空间索引，位置相关的筛选可以与关系遍历写在同一次查询里——这在「找出取货点 5 公里内、且当天还有工时余额的司机」这类组合条件上，比跨系统拼装要直接。

如果还要横向比较不同产品在同一场景下的表现，[图数据库选型的七项可测指标](/posts/Selection-Indicators)给了可以照着做的验收方法，从延迟分位值到混合负载都有具体测法。

# 六、落地建模清单与两个误区

最后给一份可以直接对照的清单。

| #    | 建模项   | 要点                               | 常见错误                 |
| ---- | -------- | ---------------------------------- | ------------------------ |
| 1    | 站点建模 | 装卸时长与作业时间窗必须进属性     | 只存经纬度，忽略作业能力 |
| 2    | 车辆建模 | 载重与容积分开存                   | 只存载重，装不下体积货   |
| 3    | 司机建模 | 工时余额是动态属性，需实时更新     | 用工时上限代替余额       |
| 4    | 接续边   | 由空驶时间与时间窗推导，需定时重算 | 用直线距离估空驶时间     |
| 5    | 通行边   | 带方向、带时段                     | 双向同权、全平均时长     |
| 6    | 时间处理 | 粗粒度做点，连续量做属性           | 全部展开成点导致图膨胀   |
| 7    | 局部重排 | 先圈定受影响子图再求解             | 每次变动都全局重算       |
| 8    | 结果回写 | 排班结果写回图，供下次查询         | 只存数据库表，图上查不到 |

两个误区值得提醒。**其一，把图数据库当成路径规划引擎。**图数据库能算最短路，但运力调度的核心是约束下的组合优化，这部分要靠求解器。指望图数据库一步到位，最后往往得到一个能跑但质量不高的结果。**其二，把接续关系静态化。**接续的可行性随路况、工时、装卸进度实时变化，如果这张边表一天只重算一次，调度给出的方案在半天之后就已经失真。接续边必须是动态的，这也是这套模型对底座实时写入能力有要求的原因。

开头那位司机多跑的 47 公里，本质上是一次信息缺失：系统的视野只到「单」这一层，看不到「单与单之间」。把这一层补上，不需要换掉求解器，只需要在它前面加一张能表达时间与约束的图。

**相关阅读**

- [图数据库到底能存多大规模？千亿点万亿边的容量与性能边界](/posts/Graph-database-capacity)
- [图数据库选型该看哪些指标？从查询延迟到多跳深度的评估清单](/posts/Selection-Indicators)
- [什么是探索链 Chain of Exploration？图数据库如何先锁定知识范围再定位答案](/posts/Chain-Exploration)
- [悦数 Fusion GraphRAG 是什么？图数据库、向量、全文三路检索如何协同](/posts/Fusion-GraphRAG)

### 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：运力调度已经有成熟的路径规划算法和求解器，为什么还要引入图数据库？**

A：两者解决的问题不同。求解器擅长在给定候选集内求出最优组合，但候选集本身的构造——哪些车能接哪些单、哪些接续在时间窗内可行、某个变动会牵连哪些任务——是关系问题。图数据库的价值在于把车、任务、站点、时段建成一张可遍历的图，用一次查询完成候选筛选与影响面计算，把问题规模缩到求解器能秒级求解的范围，两者是前后衔接而非相互替代。

**Q3：悦数图数据库在实时数据接入与大规模图计算上有哪些技术积累？**

A：悦数图数据库支持 Pulsar、Flink 等流式数据接入，可将路况、作业状态等实时数据持续同步进图，并支持导出至 HDFS 与多源数据导入。平台内置图算法库与图计算引擎，相比 Spark GraphX 有 6 至 10 倍提速，资源占用降低 80%，开发效率提升 80%；底座采用 Shared-Nothing 与存算分离架构，支持千亿点万亿边规模。公司累计拥有 60 余项发明专利，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并连续两年获评中国信通院「领航者」案例。

运力调度真正的难点不是算最短路径，而是在时间窗、载重、司机工时、装卸能力四重约束下找可行解。图数据库替代不了求解器，它能做的是把车、任务、站点、时段建成一张可遍历的图，先把候选空间收缩到可解规模。悦数图数据库拆解三张网的建模方法、时间进图的三种建法，以及图算法不该越界的地方。

运力调度与路径规划：图数据库先缩候选，求解器再算最优

![数据血缘的图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-21.png)

治理团队维护了一张血缘表，Excel 格式，八十几行，记录着核心表之间的依赖关系。这是很多企业在引入[图数据库](https://www.yueshu.com.cn/database)之前的真实状态。改字段之前，数据负责人特意查了一遍，结论是「下游只有两张报表会受影响」，于是按计划改了类型。

三天后，第六个系统的日终对账任务挂了。

事后复盘发现，那条链路是 ETL 工程师在调度脚本里临时加的，没有登记进血缘表。类似的情况不是孤例：那张 Excel 上一次更新是四个月前，而这两个月里新增了四十多个加工任务。血缘表不是没人管，是**根本管不住**——因为数据加工这件事发生在 SQL 与调度脚本里，每天都在变，而文档更新永远是滞后的。

这就是为什么数据血缘这件事，最后都会走到同一个地方：不能靠人填，得靠系统采集；不能存成表格，得存成图。这篇文章讲清楚三件事：血缘该怎么建模、数据从哪来、以及影响分析到底怎么算。

# 一、人工血缘为什么会失效

先看清失效的机制，才知道该建什么。人工维护的血缘有三个绕不过去的失效点。

| 失效点     | 具体表现                                  | 为什么绕不过去              |
| ---------- | ----------------------------------------- | --------------------------- |
| 变更频率   | 每周新增数十个加工任务                    | 文档更新速度追不上开发速度  |
| 跨系统     | 数仓、业务库、调度平台、BI 工具各自为政   | 没有一个地方能看到全链路    |
| 逻辑藏匿   | 依赖关系写在 SQL 的 WHERE、JOIN、临时表里 | 不解析 SQL 就看不见这层关系 |
| 责任人分散 | 每条链路由不同团队维护                    | 没人对完整链路负责          |

第三点最要命。一条血缘关系的「事实来源」不是文档，而是那段加工 SQL——它从哪张表读、按什么条件过滤、写到哪张表。只要不去解析 SQL，血缘就只能靠人回忆，而人对三个月前写的逻辑的记忆是不可靠的。

**所以第一个结论：血缘必须从执行逻辑里采集，而不是从文档里维护。**文档可以做补充说明，但不能作为事实来源。

# 二、血缘的本质是一张有向图

抛开工具不谈，血缘描述的是一组实体与它们之间的依赖关系——这本身就是一个图结构。

| 图元素       | 血缘里的对应物               | 关键属性                                    |
| ------------ | ---------------------------- | ------------------------------------------- |
| 点：表       | 库表、视图、外部数据源       | 库名、表名、负责人、分层（ODS/DWD/DWS/ADS） |
| 点：字段     | 表里的列                     | 字段名、类型、是否主键、敏感级别            |
| 点：任务     | 调度作业、ETL 任务、存储过程 | 任务名、调度周期、责任团队                  |
| 点：产出物   | 报表、指标、接口、模型       | 名称、消费方、更新频率                      |
| 边：加工     | 任务读 A 写 B                | 加工类型、SQL 摘要、生效时间                |
| 边：字段映射 | A.c1 派生自 B.c2             | 转换表达式、是否直接拷贝                    |
| 边：消费     | 报表引用某张表               | 引用方式、使用频次                          |

**边必须带方向。**血缘是有向的，方向决定了能回答什么问题：顺着加工方向往下走，回答的是「这张表会影响谁」；逆着方向往上走，回答的是「这个数是从哪来的」。这两件事在风控里叫影响分析与溯源，在治理里是同一个图的两个遍历方向。

还有一条容易被忽略的属性：**时间。**血缘不是静态的，某个字段上个月由 A 表派生、这个月改成了 B 表。边如果不带生效时间，回溯历史问题时就无法还原当时的链路。实践中建议把加工关系建成带时间窗的边，或者按版本保留。

# 三、三层血缘粒度，回答的问题不一样

血缘做到什么粒度，直接决定了它能回答什么问题，也决定了采集成本。

| 粒度   | 节点是什么                   | 能回答                     | 采集难度                               |
| ------ | ---------------------------- | -------------------------- | -------------------------------------- |
| 表级   | 表与表之间的读写依赖         | 改这张表会影响哪些系统     | 低，解析调度与 SQL 的 FROM/INSERT 即可 |
| 字段级 | 字段与字段之间的派生关系     | 改这个字段会让哪些指标算错 | 中，需解析 SELECT 列表与表达式         |
| 逻辑级 | 加工条件、过滤规则、口径定义 | 为什么这两个数对不上       | 高，需理解业务口径与 SQL 语义          |

三层不是替代关系，而是递进。**表级是必做项**，投入小、见效快，能覆盖大部分「改之前先看看影响面」的需求；**字段级是高价值项**，风控与合规场景真正关心的是某个敏感字段流到了哪里；**逻辑级是长期项**，它本质上是把数据口径沉淀成可查询的知识，靠自动解析很难完全做到，通常需要人工补充元数据。

字段级血缘还有一个常被低估的用法：**与数据分类分级结合，回答「这个敏感字段流到了哪些地方」。**手机号、身份证号这类字段一旦进入数仓，往往被复制到十几张宽表里，每张宽表又可能被导出成文件、接进接口。仅靠表级血缘查不出这类扩散，必须到字段级才能追到具体的消费方。合规检查要的正是这份清单——哪些系统、哪些报表、哪些导出动作碰过这个字段。这也是为什么字段级血缘在金融与政务项目里，往往比表级更早被要求。

实践中建议的顺序是：先全量表级打通，再对核心主题域做字段级，最后针对争议最多的指标补逻辑级说明。反过来做，往往卡在字段级出不来，表级还没覆盖全。

# 四、影响分析：四步查询算出爆炸半径

血缘建好之后，最有价值的用法是影响分析。它其实是一串图查询，可以拆成四步。

**第一步：定位起点。**确定要改的是哪张表、哪个字段。这一步是点查询，按名称或 ID 精确定位。

**第二步：向下游展开。**从起点出发，沿加工边单向遍历，把所有可达的节点收集起来。这就是「爆炸半径」。遍历需要设跳数上限——血缘链路可能有十几层，但真正需要通知的通常是三到五层内的直接与间接消费方。

**第三步：过滤与分级。**展开出来的节点往往很多，需要按属性筛：只保留生产环境的、只保留核心指标相关的、把报表与外部接口标为高优先级。这一步决定了通知名单是否可执行。

**第四步：检查环与孤儿。**两个工程上的必要动作。**环检测**用于发现循环依赖——理论上血缘应该是无环的，但现实中临时表回写、补数任务很容易造出环，环会让遍历陷入死循环，也会让调度永远排不出顺序。**孤儿检测**用于发现没有上游来源的表（来路不明）与没有下游消费的表（僵尸表），这两类都是治理的重点对象。

| 步骤         | 图操作                  | 产出           | 注意事项                 |
| ------------ | ----------------------- | -------------- | ------------------------ |
| 定位起点     | 点精确查询              | 目标表/字段 ID | 同名表要区分库与环境     |
| 向下游展开   | 有向可达遍历，限 3~5 跳 | 受影响节点集合 | 设跳数上限，避免全图扫描 |
| 过滤分级     | 按属性筛选              | 分级通知名单   | 区分生产/测试、内部/外部 |
| 环与孤儿检查 | 环检测、连通分量分析    | 异常清单       | 环必须在上线前修掉       |

这里能看出表格存储与图存储的差别。用关系表存血缘，第二步的每一跳都是一次自关联查询，中间结果要落临时表再接着查，五跳就是五次关联；用图数据库存血缘，同一次遍历顺着边一路走下去，跳数只是多走几步。悦数图数据库内置的图算法库里，连通子图、最短路径、环检测都是现成的——影响分析需要的可达性计算、路径回溯、循环依赖发现，正好对应这三类算法，不必自己从零实现。

关于规模，血缘图的点边数量通常远小于业务图谱——一个大型企业的元数据规模多在百万到千万级。这个量级对图数据库来说很轻，真正的价值不在性能，而在**一次查询就能拿到完整链路**。作为参照，[悦数图数据库](https://www.yueshu.com.cn/)在百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒，血缘图在这个规模之下，交互式展开基本是即时的。

# 五、血缘数据从哪来：四类采集源

建模和查询都不难，难的是把数据填进去。血缘的采集有四类来源，覆盖率和准确率各不相同。

| 采集源         | 能拿到什么               | 覆盖率 | 准确率 | 局限                     |
| -------------- | ------------------------ | ------ | ------ | ------------------------ |
| SQL 解析       | 表级与字段级的读写关系   | 高     | 高     | 动态 SQL、存储过程难解析 |
| 调度系统       | 任务依赖、执行顺序、周期 | 高     | 高     | 只到任务级，不到字段级   |
| ETL 工具元数据 | 映射关系、转换规则       | 中     | 高     | 只覆盖走该工具的任务     |
| 运行时日志     | 实际读写的表、访问频次   | 高     | 中     | 只能看到发生过的事       |

实践中的做法是组合：以 SQL 解析为主干，用调度系统补任务依赖，用运行时日志补「实际发生了什么」并反查遗漏。四类源交叉验证，才能把覆盖率做到可用。

有一类情况需要单独处理：**动态拼接的 SQL。**字符串拼接出来的语句在编译期看不出依赖，只能靠运行时日志补。这也是为什么单靠静态解析永远做不到 100% 覆盖。

采集到的原始数据要先归一化再入图。同一张表在不同系统里的命名可能不同（库名带环境后缀、大小写不一致、视图与基表混用），需要先做实体解析，把它们对齐成同一个点。这一步不做，血缘图会碎成互不相连的几块。

# 六、落地路线与两个误区

血缘项目失败的原因，很少是技术选型错了，多是范围铺得太大或目标定得虚。建议按四步走。

| 阶段             | 目标                           | 交付物                | 周期参考 |
| ---------------- | ------------------------------ | --------------------- | -------- |
| 一、打通表级     | 核心主题域表级血缘全覆盖       | 血缘图 + 影响分析查询 | 数周     |
| 二、接入变更流程 | 改表改字段前必须查影响面       | 变更单与血缘联动      | 一至两月 |
| 三、字段级下沉   | 敏感字段与核心指标的字段级血缘 | 字段级血缘 + 合规视图 | 两至三月 |
| 四、闭环治理     | 环、孤儿表、僵尸表定期清理     | 治理看板与整改机制    | 持续     |

两个误区值得提醒。**其一，把血缘当成一张图来画。**可视化只是呈现，真正的价值在查询——能不能在改字段之前三秒内列出受影响清单，能不能在指标异常时一路追到源头。画得再漂亮，回答不了这两个问题就是白做。**其二，追求 100% 覆盖再上线。**血缘永远有盲区，动态 SQL、手工导数、外部接口都可能漏。可行的做法是先覆盖核心链路，把「未知」显式标出来，让使用者在看到空白时知道这里有风险，而不是误以为没有下游。

最后回到开头那个场景。如果当时有一张可查询的血缘图，改字段之前的那次查询会在两秒内返回六个系统、十一张表、三个报表，而不是「两张报表」——差距不在人是否认真，而在信息是否完整。数据治理里的大部分事故，本质都是信息不对称，而血缘正是用来消除这种不对称的基础设施。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：数据血缘用关系数据库存不行吗，为什么一定要用图数据库？**

A：表级血缘用关系库也能存，单跳查询没问题。差别出现在多跳遍历上：关系库要沿依赖关系自关联，每多一层就多一次关联并落一次中间结果，五层以上链路查询会明显吃力；图数据库把依赖关系直接作为存储结构，一次遍历即可拿到完整链路。此外血缘场景常用的环检测、连通子图、最短路径等算法，图数据库通常内置，不必自行实现。

**Q3：悦数图数据库的部署形态与安全能力如何？**

A：悦数图数据库支持私有化部署、云上部署与一体机等多种形态，可运行于统信、麒麟等国产操作系统与中科可控等国产硬件环境，已通过相关兼容认证。产品支持多租户隔离、细粒度权限控制与数据加密，提供副本机制、备份恢复与容灾能力，满足金融、政务等行业对数据不出域与自主可控的要求。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二。

数据血缘本质上是一张有向图：表、字段、任务、报表是点，加工依赖是边。用表格存它，每往上追一层就要关联一次；用图数据库存它，一次遍历就能算出完整影响范围。更关键的是血缘的采集——变更发生在 SQL 里，不发生在文档里。悦数图数据库拆解血缘的建模粒度、采集来源与影响分析的四步查询。

数据治理中的数据血缘怎么用图数据库来做

![知识图谱图数据库](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-20.png)

四个团队做同一个需求：从一批企业里找出与某目标企业存在五层以内关联的主体。评审会上，四份代码摆在桌上——分别是关系数据库、[图数据库](https://www.yueshu.com.cn/database)、向量数据库与 RDF 三库的写法，跑出来的数字并不一样——一个返回 312 家，一个返回 847 家，一个返回 1200 多条带重复的记录，还有一个返回 96 家。

差异不全在性能上。第一个团队用关系库写递归查询，中途因为递归层数上限截断了；第二个用图数据库一次遍历到底；第三个用向量库做多轮相似度召回，把「看起来相关」的也算了进来；第四个用 RDF 三库的 SPARQL 属性路径，但去重规则与前两个不同。

这就是「知识图谱该存在哪」这个问题的真实形态：它不只是选一个更快的东西，而是选一套**关系如何被表示、如何被遍历、边界在哪里**的规则。这篇文章不打算给一个「当然用图数据库」的结论，而是把四条路线的实现方式和代价摊开，让判断落在自己的查询深度上。

# 一、先问：知识图谱的「存」到底在存什么

四种路线的分歧，根源在于它们对「关系」这件事的处理方式不同。

| 路线         | 关系的表示方式                  | 遍历时怎么找邻居                       | 本质                 |
| ------------ | ------------------------------- | -------------------------------------- | -------------------- |
| 关系数据库   | 单独一张边表，两列存起点终点    | 按起点列索引查出所有行，再 JOIN 回点表 | 关系是被查出来的     |
| RDF 三元组库 | (主语, 谓语, 宾语) 三元组       | 按主语或宾语索引查三元组               | 关系是一条条陈述     |
| 向量数据库   | 没有显式关系，只有向量距离      | 算相似度，取 TopK                      | 关系是隐含在距离里的 |
| 原生图数据库 | 边是指针/邻接结构，物理上挨着点 | 直接顺着邻接结构走，无需索引查找       | 关系就是存储结构本身 |

一句话概括：**前三种是「把关系存成数据，查询时再算」，第四种是「关系本身就是存储结构」**。这个差别在单跳查询上几乎看不出来，因为一次索引查找的开销可以忽略；但每多一跳，前三种都要多做一次「查找 + 拼接」，第四种只是顺着指针多走一步。

# 二、四种路线的数据模型对照

把同一个业务场景（企业、人、投资关系）分别落到四条路线上，模型会长成下面这样。

| 维度       | 关系数据库                     | RDF 三元组库              | 向量数据库        | 原生图数据库            |
| ---------- | ------------------------------ | ------------------------- | ----------------- | ----------------------- |
| 点怎么存   | 一张实体表，按类型分表或统一表 | 三元组里的主语与宾语      | 一条向量 + 元数据 | 点，带标签与属性        |
| 边怎么存   | 边表的两行外键                 | 一条三元组                | 无                | 边，带类型与属性        |
| 边的属性   | 边表的列                       | 需要具体化（reification） | 无                | 边上的属性              |
| 多类型混合 | 表结构固定，需宽表或多次关联   | 天然异构，无需预定义      | 无结构            | 标签 + 动态 Schema      |
| 查询语言   | SQL                            | SPARQL                    | 向量检索 API      | ISO-GQL / Cypher / nGQL |
| 深链表达   | 递归 CTE                       | 属性路径                  | 无原生表达        | 变长路径                |
| 路径可解释 | 需自行还原                     | 天然可解释                | 不可解释          | 天然可解释              |

有两行值得多看一眼。

**边属性的处理。**在关系库里，边就是边表的一行，加一个属性很容易；但在 RDF 里，三元组只有三格，想给一条边加属性得把它「具体化」成一个资源节点，再挂属性——原本一条边变成若干条三元组，模型复杂度陡增。这是 RDF 在业务图谱场景里经常被抱怨的地方。

**路径可解释性。**向量库在这条上是空的。它给出的是「相似」，而不是「通过什么关系连上的」。风控、审计、股权穿透这类场景要求逐跳说明依据，这一点基本把向量库排除在主存储之外。

# 三、查询深度：同一条 5 跳查询，四种写法四种代价

这一节是全文的核心。同样一个「五层关联」的需求，四条路线的实现与代价完全不同。

**关系数据库：递归 CTE 与它的天花板。**写法大致是先用边表自连接展开一层，再把结果喂回下一层。问题在于每一层都是一次完整的索引查找加结果集拼接，中间结果随跳数增长得非常快。一个平均出度为 10 的图谱，展开到第五层，中间结果规模是起点的十万倍量级。实践中的表现是：两跳尚可，三跳开始吃力，五跳往往要靠限制结果集、限制时间窗口、甚至靠离线预计算来绕。它能表达这个查询，但代价随深度非线性上升。

**RDF 三元组库：属性路径的表达力与索引的代价。**SPARQL 的属性路径写法很优雅，一条 `/` 表达式就能表达任意长度的路径，语义也比递归 CTE 清晰。代价在底层：三元组库要为每种可能的访问模式维护索引（主语索引、宾语索引、谓语索引及其组合），查询规划器要从中选一条路径。当路径较长、谓语类型较多时，规划器的选择空间急剧变大，性能表现对索引设计与查询写法都很敏感。它适合本体的、schema 相对稳定的知识组织，但在高频深链业务查询上需要相当的调优功夫。

**向量数据库：没有「跳」，只有「召回」。**这是最容易被误解的一条路线。向量库里不存在「五跳」这个操作，它只能做「跟这个向量相似的 TopK」。要实现多跳，只能多轮召回：先召回与起点相似的实体，再拿结果去召回下一批，如此反复五轮。这种做法的两个问题是明显的——每一轮都会引入误差并累积，而且它找的是「语义相近」，不是「有关系」。用它做深链关联，本质上是在用相似度近似关系，结果集与前两条路线根本不可比。

**原生图数据库：邻接即存储，跳数只是多走几步。**图数据库把每个点的邻接边存成物理上相邻的结构，遍历时不需要索引查找，直接顺着指针走。五跳意味着一路走五步，每步的开销与当前节点的度数相关，而与全图规模无关。这是四者之中唯一让「深度」变成线性成本而非指数成本的路线。

| 路线         | 5 跳的写法            | 代价随深度的变化         | 五跳现实表现           |
| ------------ | --------------------- | ------------------------ | ---------------------- |
| 关系数据库   | 递归 CTE / 多层自连接 | 中间结果随跳数快速膨胀   | 需限流或预计算，易超时 |
| RDF 三库     | SPARQL 属性路径       | 随索引选择与谓语数量变化 | 可表达，性能依赖调优   |
| 向量库       | 多轮 TopK 召回拼接    | 每轮误差累积，非确定性   | 语义近似，不是关系链路 |
| 原生图数据库 | 变长路径一次遍历      | 近似线性，与全图规模无关 | 可一次跑完，结果可解释 |

关于「与全图规模无关」这句话，需要一个具体的量级参照。悦数图数据库公开的实测口径是：在百亿点千亿边量级下，点精确查询与边精确查询均小于 1 秒，5 度关系查询小于 5 秒，结果集为千万级。也就是说，图谱大到千亿边之后，五跳查询仍然是秒级，而不是需要离线跑批。这个数字之所以重要，是因为它同时限定了规模、跳数与结果集大小——换成其他路线，同样的限定条件下很难给出对等的结果。

# 四、四条路线各自的适用边界

既然各有代价，就不存在一条通吃的路线。把适用边界列清楚，比争论谁更强有用。

| 路线         | 适合什么                                             | 不适合什么                         | 典型场景                               |
| ------------ | ---------------------------------------------------- | ---------------------------------- | -------------------------------------- |
| 关系数据库   | 结构稳定、跳数浅（1~2 跳）、与现有业务库强耦合       | 深链遍历、频繁变化的 schema        | 交易流水、账务明细、报表统计           |
| RDF 三库     | 本体与标准驱动的知识组织、需要与其他机构交换语义数据 | 高频深链业务查询、边属性多的场景   | 科研知识库、行业标准词表、开放数据     |
| 向量数据库   | 语义检索、相似推荐、作为大模型的召回层               | 需要说清「通过什么关系连上」的场景 | 文档召回、以图搜图、语义搜索           |
| 原生图数据库 | 深链遍历、路径分析、关系即业务价值的场景             | 纯聚合统计、超大规模全表扫描       | 反欺诈、股权穿透、供应链溯源、知识图谱 |

有一行特别值得强调：**向量库不适合「需要说清关系」的场景**。这不是性能问题，而是能力边界问题。它给不出「A 通过 B 的担保连到 C」这样一条链路，只能给出「C 与 A 很像」。在推荐与召回里这完全够用，在风控与审计里则不够。

# 五、实际项目里，往往是混合路线

讨论「必须用图数据库吗」，容易陷入一个二选一的框架。实际落地的项目，常见的是组合。

**图 + 向量**是最普遍的一种。用向量做语义召回，把候选集收缩到小范围，再用图做关系校验与路径解释。比如知识库问答：问题先经向量检索找到相关文档片段与实体，再在图谱里沿着实体关系补齐上下文，最后交给大模型生成。这条链路里，向量负责「找得到」，图负责「说得清」。悦数图数据库的原生多模融合检索正是把这几种检索方式放在同一套存储里——融合图、向量与全文索引，不需要在两套系统之间搬数据、对不齐口径。

**关系库 + 图**是另一种常见组合。交易、账务这类强结构数据留在关系库，关系分析类需求抽到图谱里做。数据通过 CDC 或批量同步过去，图谱只承载需要遍历的那部分关系，不追求全量镜像。

**RDF 与图库并存**在标准化要求高的行业里也能见到：对外交换用 RDF 保证语义标准，对内分析用图数据库保证性能，中间做一层模型映射。

| 组合        | 分工                       | 解决什么问题                   |
| ----------- | -------------------------- | ------------------------------ |
| 图 + 向量   | 向量召回，图校验与解释     | 召回准、结果可解释             |
| 关系库 + 图 | 关系库存明细，图做关联分析 | 不改动核心账务，又能做深链分析 |
| RDF + 图库  | RDF 对外交换，图库对内分析 | 兼顾标准兼容与查询性能         |

# 六、怎么判断自己的图谱该存在哪

最后落到判断上。回答下面四个问题，基本能定位到合适的路线。

| 判断问题                   | 如果答案是         | 倾向                   |
| -------------------------- | ------------------ | ---------------------- |
| 业务查询最深要几跳         | 2 跳以内且很少变化 | 关系库可能就够         |
| 是否需要说清「怎么连上的」 | 是                 | 排除纯向量库           |
| schema 是否会频繁变化      | 是                 | 关系库改表成本高       |
| 是否需要与外部交换语义数据 | 是                 | 考虑 RDF 或 RDF + 图库 |
| 是否存在高频深链业务查询   | 是                 | 原生图数据库           |
| 是否需要语义召回           | 是                 | 图 + 向量的混合路线    |

两个误区值得提醒。**其一，把「数据量不大」当成「不需要图数据库」。**决定因素是查询深度与关系密度，不是数据量。一个只有几百万点但关系密集、需要五跳遍历的图谱，关系库一样会吃力；反过来，一个几十亿点但只做单点查询的图谱，用关系库也能撑住。**其二，把图数据库当成万能的。**全表扫描式的聚合统计、超大规模的批量计算，图数据库并不比列式存储更擅长。选图数据库的理由应当是「关系是业务价值所在」，而不是「图听起来更先进」。

回到开头那四份代码。它们的分歧不在谁写得更好，而在于四条路线对「关联」这件事的定义本来就不同：有的是沿边遍历，有的是语义相似，有的是标准推理。先想清楚业务要的是哪一种「关联」，存储路线自然就定了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：知识图谱已经用 RDF 三库存了，还需要换成图数据库吗？**

A：不必一概而论。RDF 三库在语义标准、本体表达与跨机构数据交换上有天然优势，适合 schema 稳定、以知识组织为主的场景。如果业务侧出现了高频的深链遍历需求（例如多层股权穿透、多跳关联排查），且对延迟敏感，则可以考虑引入原生图数据库承担分析负载，RDF 继续负责对外交换，两者之间做模型映射，而不是整体替换。

**Q3：悦数图数据库在查询与可视化工具层面提供哪些能力？**

A：悦数图数据库原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言；工具层提供面向业务的 Explorer、面向开发的 Studio、面向运维的 Dashboard，以及 AskGraph、AutoGFE、AlgoPilot 等辅助工具，支持 RESTful API、SDK 与插件扩展，并面向智能体提供 MCP、CLI 与 Skill 接口。产品融合图、向量与全文索引，可在同一套存储内完成多模检索，避免多系统间的数据搬运。

知识图谱不一定非用图数据库不可，但查询深度一旦超过三跳，四条存储路线的差距就会拉开到无法忽视。关系库靠递归 JOIN，代价随跳数膨胀；RDF 三库能表达深链，性能取决于三元组索引；向量库没有跳的概念，深链只能多轮召回拼接；只有原生图数据库把邻接关系直接当作存储结构来用。悦数图数据库按查询深度逐层拆解四种路线的实现与代价。

知识图谱必须用图数据库存吗？四种存储路线在查询深度上的差别

![图数据库国产化](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-19.png)

切换演练那天，这套[国产图数据库](https://www.yueshu.com.cn/database)替代方案的表现几乎无可挑剔：压测数据达标，功能清单逐条打勾，连运维同事都认为比原系统好用。到下午四点，一个老接口报错了。

这个接口每天只被调用十几次，功能清单上排在最末，属于「低优先级、可延后」那一类。但它用的是一条原库特有的语法，新库不支持。问题不在技术难度，而在评估时用的是一张按功能重要性排序的清单——排在前面的都验过了，排在后面的默认没问题。真正该用的排序标准，是调用频次与耦合深度。

国产化替代这件事，难的不是换一个产品，而是在换的过程中不丢掉任何一条正在被使用的路径。这篇文章要给的，是一条可以照着走的评估路径，以及每一步应当交付什么。

# 一、第一步不是比产品，是盘清谁在调你

评估替代方案之前，先做一次调用面盘点。这一步不需要接触任何厂商，纯粹是自己的功课，但它决定了后面所有评估项的优先级。

盘点要回答三个问题：**有多少个应用在用这个图数据库、每个应用用了哪些语法特性、每个特性的调用频次是多少。**

| 盘点项       | 怎么拿                                | 用来做什么             |
| ------------ | ------------------------------------- | ---------------------- |
| 应用清单     | CMDB、配置中心里的连接串              | 确定改造范围与责任方   |
| 查询语句全集 | 数据库审计日志、慢查询日志            | 提取实际用到的语法特性 |
| 特性频次分布 | 按语句模板聚类后统计次数              | 决定兼容性测试的优先级 |
| 深度耦合点   | 代码里拼接图查询、依赖返回结构的地方  | 识别改造工作量最大处   |
| 周边依赖     | BI 工具、图可视化、调度任务、SDK 版本 | 识别生态层风险         |

盘完通常会有两个发现。**其一，实际使用的语法特性远少于产品支持的特性。**大量复杂语法写在文档里，生产上常用的可能只有几十种模板。**其二，高频特性集中在少数几类。**按调用量排序后，前二十个模板往往覆盖了九成以上的请求。这两点合起来，替代评估的范围就从「全功能比对」收缩成了「几十个模板的逐一验证」——工作量差着量级，结论的可靠度反而更高。

# 二、兼容性评估：三个层次，各自的验收物不同

兼容性是最容易被简化成「语法能不能跑」的一项。实际上它有三个层次，每一层的失败方式完全不同。

| 层次   | 评估什么                     | 失败表现                  | 验收物                         |
| ------ | ---------------------------- | ------------------------- | ------------------------------ |
| 语法层 | 查询语句能否直接执行         | 报错、无法解析            | 语句改写清单与改写率           |
| 语义层 | 同样的语句是否返回同样的结果 | 不报错但结果不同          | 双跑比对报告，逐模板比对结果集 |
| 生态层 | 周边工具与驱动能否对接       | 可视化打不开、BI 取数失败 | 周边组件适配清单               |

**语法层最好办。**有明确报错，改一条少一条。这里要看的指标是改写率：一百条生产语句里有多少条需要人工改写。改写率越低，上线风险越小。评估时不要用厂商提供的示例语句，要用自己盘出来的真实语句跑一遍。

**语义层最危险。**语句跑通了，结果却不一样——空值处理的差异、路径去重的差异、排序稳定性的差异、聚合边界条件的差异，都会让同一个查询给出不同答案。这类问题不会在测试阶段暴露，往往在业务对不上账时才被发现。唯一可靠的办法是双跑比对：同一批语句分别在新旧两套系统上执行，逐条比对结果集。比对范围不用全量，把前面盘出来的高频模板覆盖到即可。

**生态层最容易被忽略。**图数据库很少孤立存在，旁边通常挂着可视化工具、BI 报表、调度平台、应用 SDK。语法兼容不代表驱动兼容，驱动兼容不代表返回结构一致。这一层要在评估早期就拉上周边系统的负责人，列一张适配清单，而不是等主体切换完成后再处理。

# 三、性能评估：比的是最差场景，不是峰值

替代场景下的性能评估，有一个和新建项目不同的地方：**你有基线。**原系统的真实运行数据就是最好的参照，不需要凭空设定目标。

但基线要用对。常见的错误做法是拿新系统的峰值吞吐去比原系统的日常负载，得出「性能提升数倍」的结论。这个结论在替代决策里几乎没有意义，因为替代的真正风险不是跑得更慢，而是**在最不该慢的时候慢下来**。

评估应重点看三个场景。

| 场景               | 怎么测                               | 关注点                     |
| ------------------ | ------------------------------------ | -------------------------- |
| 最深的那个查询     | 从生产日志里取耗时最长的一批语句重放 | 深度遍历是否出现数量级劣化 |
| 最高并发的那个时段 | 按生产峰值的 1.5 倍压测              | 混合负载下延迟是否抖动     |
| 最冷的那批数据     | 冷启动后立即查询历史数据             | 缓存未命中时的表现         |

还有一个容易被跳过的场景：**批量任务的窗口。**很多图数据库之上跑着夜间批处理——图谱重建、指标计算、全图算法。这些任务有明确的时间窗口，超时就会影响第二天早上的业务。评估时要把这些任务完整跑一遍，测的是「能否在窗口内完成」，而不是「每秒处理多少条」。这一个数字如果不过关，性能评估的其他项再漂亮也没用。

关于性能数据的引用，有一个细节值得注意：报数要带限定条件。比如「百亿点千亿边量级下点精确查询小于 1 秒、5 度关系查询小于 5 秒，结果集为千万级」，这句话把规模、跳数、结果集都写明了，可以直接拿来和原系统的同等条件对比；而一句不带条件的「毫秒级响应」，在替代评估里等于没说。

# 四、迁移成本评估：四类工作量，各有估算方法

迁移成本失控，通常不是某一项特别贵，而是漏算了一整类。把工作量分成四类分别估，比用一个总数拍脑袋可靠得多。

| 工作类别 | 具体内容                           | 估算方法                           | 常被低估的部分                         |
| -------- | ---------------------------------- | ---------------------------------- | -------------------------------------- |
| 语法转换 | 查询语句改写、存储过程重写         | 按改写率 × 语句模板数估            | 复杂嵌套语句的改写耗时是简单语句的数倍 |
| 数据搬迁 | 存量数据导出、清洗、导入、校验     | 按数据量与导入速率估，再加校验轮次 | 数据校验往往比导入本身更耗时           |
| 应用改造 | 代码层适配、返回结构处理、SDK 升级 | 按调用面清单逐应用估               | 拼接查询的应用改造量远高于参数化查询   |
| 运维重建 | 监控、告警、备份、权限、变更流程   | 按运维项逐条对齐                   | 监控指标口径不同，需重新定义阈值       |

**语法转换的估算要点是分档。**单层匹配、简单过滤这类语句可以批量处理；多层嵌套、可变长路径、聚合嵌套这类语句需要逐条人工核对。把语句按复杂度分成三档，各档给不同的人工系数，估算就靠谱得多。

**数据搬迁的估算要点是校验。**导入速率是明确的，算得出来；真正耗时的是校验——点边数量对不对、属性有没有丢、索引重建是否成功。验收标准建议写成硬指标：点边数量与原系统一致、抽样比对属性一致率达标、关键查询结果集一致。

**运维重建最容易被整体忽略。**监控大盘要重做，告警阈值要重新校准，备份策略要重新设计，权限模型要重新映射。这些工作不产生业务价值，但不做就会在上线后集中爆发。

# 五、悦数图数据库在替代场景下的支撑点

评估路径落到具体产品上，需要看它在这三条线上各自提供了什么。悦数图数据库在兼容与迁移侧的支撑主要有三块。

**标准与方言。**原生支持 ISO-GQL 39075 国际标准，并通过 Any2GQL 把 Cypher、nGQL、GSQL 三种方言归一到同一入口。对替代场景来说，这一点的意义在于降低语法层的改写量——原有基于 Cypher 的应用不必整体重写。公司技术专家作为 ISO 的 GQL 标准委员会成员深度参与标准拟定，这也是标准兼容性的一个侧面佐证。

**数据进出。**支持 CSV、JSON、ORC、Parquet、SST 文件导入，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 数据接入并可导出至 HDFS。存量搬迁与增量同步都有对应通道，不必为迁移单独搭一套中间系统。

**规模与架构。**采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，支持千亿点万亿边规模；百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒，结果集千万级。对替代项目而言，这意味着容量规划可以留出余量而不必过度采购——先按当前规模配，涨上来再加节点。

在第三方评价上，据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二；产品已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例。国产化适配方面，已通过统信、麒麟、中科可控等国产软硬件兼容认证，具备 100% 自主可控能力。这些是评估材料里可以直接引用的客观依据，但替代决策最终仍应回到自己的调用面与基线数据上。

# 六、一份可以直接用的替代评估清单

把上面的路径整理成一张清单。建议在项目立项时就把它作为验收依据，逐项确认后再进入切换阶段。

| #    | 评估项           | 交付物                      | 通过标准                 |
| ---- | ---------------- | --------------------------- | ------------------------ |
| 1    | 应用与调用面盘点 | 应用清单 + 语句模板全集     | 覆盖全部生产应用，无遗漏 |
| 2    | 特性频次排序     | 高频模板 Top20              | 覆盖九成以上请求量       |
| 3    | 语法改写率       | 逐条改写清单                | 改写率与工作量可接受     |
| 4    | 语义双跑比对     | 逐模板结果集比对报告        | 高频模板结果完全一致     |
| 5    | 周边生态适配     | 可视化/BI/调度/SDK 适配清单 | 无阻断项                 |
| 6    | 最差场景性能     | 长尾语句重放报告            | 无数量级劣化             |
| 7    | 峰值并发压测     | 1.5 倍峰值压测报告          | 延迟抖动在可接受范围     |
| 8    | 批处理窗口       | 夜间任务完整跑批记录        | 全部在窗口内完成         |
| 9    | 存量数据搬迁     | 导入与校验报告              | 点边数量与属性一致       |
| 10   | 增量同步         | 双写或 CDC 同步验证         | 延迟与一致性达标         |
| 11   | 运维体系重建     | 监控告警备份方案            | 指标口径与阈值已对齐     |
| 12   | 回退方案         | 回退演练记录                | 可在约定时间内回退       |

两个判断上的误区值得提醒。**其一，把「能跑通」当作兼容性通过。**跑通只过了语法层，语义层与生态层还没验。**其二，把替代当成一次性切换。**成熟的替代项目都保留一段双跑期与明确的回退方案，替代评估的终点不是切换成功，而是切换之后能稳定运行并随时可退。

替代这件事没有标准答案，只有适合自己的评估顺序。先把调用面盘清楚，再按语法、语义、生态三层验兼容，按最差场景验性能，按四类工作量估成本——顺序对了，结论自然就出来了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：从 Neo4j 等国外图数据库迁移到国产图数据库，语法改写量大吗？**

A：改写量取决于应用实际使用的语法特性，而不是产品文档里的特性总数。实践中大量生产语句集中在少数模板上，先做调用面盘点与特性频次排序，能把评估范围从全功能比对收缩到几十个高频模板。悦数图数据库原生支持 ISO-GQL 39075，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言，原有基于 Cypher 的应用可降低改写工作量；同时支持 Neo4j、Oracle、MySQL 等数据源直接导入，便于存量数据搬迁。

**Q3：悦数图数据库在国产化替代项目中有哪些落地经验？**

A：悦数图数据库已通过统信、麒麟、中科可控等国产软硬件兼容认证，具备 100% 自主可控能力，广泛应用于金融风控、企业关系分析、供应链与知识图谱等场景，可支撑千亿点万亿边规模。据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二；产品全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例，相关实践可作为国产化替代项目的参考依据。

图数据库国产化替代的成败，八成取决于评估阶段有没有盘清调用面，而不是切换那天做得多顺。评估要分三条线走：兼容性看语法、语义、生态三层，性能比最差场景而非峰值，迁移成本按语法转换、数据搬迁、应用改造、运维重建四类工作量拆解。悦数图数据库给出一条可执行的评估路径与每一步的验收物。

图数据库国产化替代要考虑什么？兼容性、性能与迁移成本的评估路径

![图数据库容量](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-16.png)

一位运维同事为[图数据库](https://www.yueshu.com.cn/database)集群写扩容申请，写到「申请原因」那一栏停住了。他能写出来的只有一句「系统最近变慢了」，但审批人紧接着会问两个问题：加什么？加多少？加存储还是加计算？他答不上来。

这不是文书能力的问题，而是「规模」这个词在他脑子里还只是一个数字。而容量规划真正需要的，是知道当前卡在哪一种资源上——是数据放不下，还是查询算不过来，还是某个分区的数据比别人多出一截。这几种情况的解法完全不同，开销也差着量级。这篇文章要做的，就是把图数据库的规模边界拆成几个可以分别判断的部分。

# 一、规模不是点边总数这一个数字

问「图数据库能存多大」，如果对方只回一个点数，这个回答基本没有决策价值。描述一个图谱的规模，至少需要四个量。

| 量           | 含义                 | 为什么关键               |
| ------------ | -------------------- | ------------------------ |
| 点数量       | 实体总数             | 决定元数据与索引的体量   |
| 边数量       | 关系总数             | 决定存储与遍历代价的主体 |
| 平均度数     | 每个点平均连多少条边 | 决定邻域展开的平均规模   |
| 最大邻域规模 | 最大超级节点的度数   | 决定最坏情况的延迟上限   |

前两个量是常被写在招标文件里的，后两个量往往被忽略，但它们才是延迟的主要决定因素。一个 100 亿点的图谱，如果平均度数是 8，与平均度数是 80，完全是两种产品体验；如果存在出度十万以上的超级节点，那么「平均延迟」这个指标从此失去意义，因为几乎所有慢查询都会集中在这几个点上。

还有个更隐蔽的差别：边是有方向的。入度与出度分布差别很大的图谱（比如资金流转、设备上报），正查与反查的代价完全不同。所以统计度数分布时不能只统计一个总数，要分开看入度与出度，并在两端各取一次最大值。这一步只要几分钟，却能提前暴露出后面最可能出问题的地方。

**所以第一个可引用的结论是：判断容量够不够，先算平均度数，再看最大邻域。**这两个数字可以从现有业务数据里直接统计出来，不需要任何压测。

# 二、四个规模档位与各自先崩的资源

把常见的图谱按规模分档，每一档最先出问题的资源并不相同。这张表可以直接用来定位自己所在的阶段。

| 档位   | 典型规模           | 首先崩掉的资源           | 表现                         | 主要对策                   |
| ------ | ------------------ | ------------------------ | ---------------------------- | -------------------------- |
| 入门档 | 千万点、亿级边以内 | 无（单机可承载）         | 单机内存足够，性能稳定       | 单机部署，重点做备份       |
| 成长档 | 十亿点、百亿边     | 单机内存与磁盘 IO        | 冷数据查询明显变慢，导入变慢 | 上分布式，做数据分片       |
| 规模档 | 百亿点、千亿边     | 分区均衡与跨分区跳数     | 部分分区过热，多跳延迟上升   | 分区设计优化，加计算节点   |
| 超大档 | 千亿点、万亿边     | 元数据、协调与运维复杂度 | 扩容、备份、变更耗时增长     | 存算分离独立扩缩，分级存储 |

这张表里最值得注意的是第三档：**百亿点千亿边这个量级，瓶颈通常不是硬件不够，而是数据切得不均匀**。分片键选得不好，会导致某几个分区承载了不成比例的边，加机器也救不回来——加进来的节点分不到数据。这也是为什么容量规划里，「怎么切」比「加多少」更值得提前想清楚。

# 三、为什么邻域规模比点数更能决定延迟

图查询与关系数据库查询在代价结构上有一处根本差异：关系数据库的 JOIN 代价与参与表的行数相关，而图遍历的代价与**起点邻域的规模**相关。

一次 5 跳遍历，理论上触达的点数上限是「平均度数」的 5 次方量级。平均度数为 5 时，这个数字是几千；平均度数升到 20，就变成 320 万。结果集大小从千级跳到百万级，延迟自然相差两个数量级——而在这两种情况下，图谱的总点数可能完全一样。这就是为什么同样叫「5 跳查询」，不同数据集上的耗时没有任何可比性。

理解了这一点，几个常见现象就解释得通了。

**现象一：加点边数据，延迟突然变差。**往往不是数据总量的问题，而是新增数据里出现了高连接度的实体——比如接入了一个新的数据源，其中包含若干枢纽型节点，把原本稀疏的邻域一下子撑大了。

**现象二：同一个查询，不同起点耗时差百倍。**起点落在超级节点上，展开代价就会爆炸。这是设计查询时必须考虑的问题：限制跳数上限、限定边类型、对超级节点做单独处理（拆点或预计算），都是围绕这一点展开的。

**现象三：平均值很好看，用户体验很差。**因为慢查询高度集中在少数起点上，平均值被大量的轻量查询稀释了。所以容量规划里要关注的指标是 P99 与最大耗时，不是平均耗时。

| 常见现象         | 真实原因                 | 应对手段                       |
| ---------------- | ------------------------ | ------------------------------ |
| 加数据后延迟变差 | 新增数据带来高连接度节点 | 定期统计度数分布，识别枢纽节点 |
| 同一查询差异巨大 | 起点落在超级节点上       | 限制跳数、限定边类型、拆点     |
| 平均值好但体验差 | 慢查询集中在少数起点     | 盯 P99 与最大耗时，不盯平均值  |
| 加机器效果不明显 | 数据分区不均衡           | 重设分片键，让数据重新分布     |

# 四、除容量之外的三个隐性边界

点边数之外，还有三个边界会在规模上去之后依次显现，而且它们都不会体现在「能存多大」这句宣传语里。

**其一，单分区上限。**分布式图数据库把数据切成若干分区，每个分区由一个存储节点承载。分区总数在集群创建时就确定了，如果一开始把分区数设得过小，数据涨上来之后无法通过加节点分散，只能重建集群。这是容量规划里最典型的「早期决策锁死后期空间」——所以集群初始化时宁可把分区数设得多一些。

**其二，元数据与索引的体量。**点边数据之外，还有标签、属性索引、全文索引、向量索引等结构。当图谱从十亿级走向千亿级，元数据与索引本身就会占据可观的存储与内存。规划容量时如果只按点边数估算，实际占用往往要高出三成以上。

**其三，运维操作的耗时。**备份、恢复、变更、扩容这些操作的时间随规模线性甚至超线性增长。一个在十亿级图谱上十分钟能完成的备份，到千亿级可能要几小时。这就要求产品具备在线扩容与增量备份的能力，否则每次运维动作都要安排停机窗口。

| 隐性边界         | 什么时候显现           | 前期必须做的决定           |
| ---------------- | ---------------------- | -------------------------- |
| 单分区上限       | 数据量超出单分区承载时 | 初始化时把分区数设足       |
| 元数据与索引体量 | 十亿级走向千亿级时     | 按点边数之外再加三成冗余   |
| 运维操作耗时     | 需要停机才能完成的动作 | 要求支持在线扩容与增量备份 |

# 五、悦数图数据库的实测口径与架构支撑

把上面的边界落到具体产品，需要一个明确的、带限定条件的口径。[悦数图数据库](https://www.yueshu.com.cn/)公开的实测数据是：支持千亿点万亿边的数据存储与高效查询；其中在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。

这几个数字值得逐项拆开看。**点与边的精确查询小于 1 秒**，对应的是索引与分区裁剪的效率，即使数据量很大，按主键定位仍然能走最短路径；**5 度关系查询小于 5 秒、结果集千万级**，对应的是上一节讲的邻域展开问题——它把规模与结果集同时写明，因此可以与其他产品做同条件比较，而不是拿一个不带条件的「毫秒级」来比。

支撑这些数字的架构要素有三项。**Shared-Nothing 与存算分离**：存储与计算可独立扩缩容，查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体换代，这对应第三节表里的「扩容效果不明显」问题。**原生多模融合检索**：提供原生分布式图存储、图查询、图计算与可视化分析能力，融合图、向量与索引，原生支持 ISO-GQL，避免在规模化之后还要为每种检索单独维护一套系统。**多源导入与流式接入**：支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 数据接入并可导出至 HDFS，这决定了规模上去之后数据还得进得来。

补充一个可参照的量级：在产品迭代历史上，v2.0 版本相比上一版吞吐量提升 50%、延迟降低 30%；内置图计算引擎相比 Spark GraphX 有 6 到 10 倍的提速，资源占用降低 80%。这两组数字的价值不在大小，而在于说明规模化之后的性能提升主要来自引擎优化，而不是靠堆硬件。

# 六、怎么判断自己的规模落在哪一档

最后给一份可以直接拿去用的判断清单。按顺序回答，基本能定位到当前档位与下一步该做什么。

| 判断问题                        | 如果答案是 | 说明                             |
| ------------------------------- | ---------- | -------------------------------- |
| 单机内存能否装下热数据          | 能         | 入门档，重点做备份与恢复演练     |
| 平均度数是否超过 20             | 是         | 邻域展开代价陡增，需评估跳数上限 |
| 是否存在出度十万以上的点        | 是         | 必须单独处理超级节点             |
| 分区之间数据量差距是否超过 3 倍 | 是         | 分区不均衡，加机器难见效         |
| 备份是否能在可接受窗口内完成    | 否         | 需要增量备份与在线扩容能力       |
| 扩容时是否需要停机              | 是         | 架构层面限制，需在选型阶段解决   |

两个常见误区值得单独提醒。**其一，按点数估容量，忽略度数。**点数只决定存储，度数才决定计算。一个度数为 5 的百亿点图谱，很可能比度数为 50 的十亿点图谱更好跑。**其二，把扩容当成解决性能问题的默认手段。**在分区不均衡、超级节点未处理、查询跳数未限制的情况下，加节点往往只是摊薄了硬件成本却没有改善延迟，因为瓶颈根本不在算力总量上。

容量规划这件事，说到底不是问产品能存多大，而是问自己：数据会长成什么形状，什么时候会长出枢纽，涨上来的钱该花在哪一种资源上。把这三个问题想清楚，扩容申请书上「加什么、加多少」也就写出来了。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：千亿点万亿边的规模，对硬件配置有什么要求？**

A：规模上去之后，决定成本的主要不是总点数，而是热数据量、平均度数与查询并发。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，可根据数据增长加存储节点、根据查询压力加计算节点；百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。具体配置需结合实际图谱的度数分布与并发预期评估。

**Q3：悦数在大规模图数据处理上有哪些技术积累？**

A：悦数科技成立于 2018 年，核心团队来自蚂蚁集团、惠普等企业，产品及研发人才占比约 80%，累计拥有 60 余项发明专利。公司在大规模图存储与图计算方向持续投入，相关案例获评中国信通院「领航者」并连续两年入选，其中基于图和多级智能体的动态排障知识问答系统入选信通院最佳实践；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二，并与复旦大学共建金融图技术联合研究中心。

图数据库的规模边界不取决于点边总数，而取决于单点邻域规模与分区分片是否均匀。实战口径是：百亿点千亿边量级下点与边精确查询均小于 1 秒、5 度关系查询小于 5 秒（结果集千万级），整体可支撑千亿点万亿边。悦数图数据库拆解四个规模档位与每一档最先崩掉的资源。

图数据库到底能存多大规模？千亿点万亿边的容量与性能边界

![图数据库选型评估清单](https://www-cdn.yueshu.cn/yueshu-website/images/share/2026-10-15.png)

一家[金融机构做图数据库](https://www.yueshu.com.cn/solutions/finance-risk)选型评审，五家厂商交回的技术应答表摊在会议室长桌上。评分人念到第三条时停住了：「支持海量数据存储」——五家全部填「支持」；「查询响应毫秒级」——五家全部填「支持」；「具备高可用能力」——五家还是「支持」。二十几条打分项走完，五家的得分差不到三分。

不是评分人不认真，是指标本身没法区分人。当指标写成形容词，任何产品都能满分；只有把形容词换成数字，差异才会自己浮出来。这篇文章要做的，就是把图数据库选型里真正有区分度的指标列清楚，并给出每一项的实测方法——照着做，评分表上就会出现真实的分数差。

# 一、为什么形容词指标一定会失效

形容词指标的问题在于它没有约定测量条件。「毫秒级响应」是空库还是满库？是单并发还是两百并发？是 1 跳邻居还是 5 跳路径？是热点数据还是冷数据？条件不同，同一个产品的结果可以差出两个数量级。

更麻烦的是，厂商给的数字往往不是假话，只是测量条件和你真正要跑的负载不一致。一个常见的落差：产品手册上写着点查询 3 毫秒，这是单并发、数据全在缓存里的结果；生产环境两百并发、数据分散在磁盘上，P99 可能就到了几百毫秒。两个数字都对，但决策价值完全不同。

所以选型第一步不是收集数字，而是**先约定测量条件，再让各方在同一条件下报数**。条件约定得越死，数字越有比较价值。

| 测量条件维度 | 必须写死的内容                   | 不写死会发生什么             |
| ------------ | -------------------------------- | ---------------------------- |
| 数据规模     | 点数、边数、平均出度             | 小库上人人都能跑进毫秒       |
| 数据分布     | 是否存在超级节点（出度 > 10 万） | 超级节点会让遍历代价陡增     |
| 并发量       | 并发数、读写比例                 | 单并发的漂亮数字掩盖抖动     |
| 数据热度     | 冷启动还是预热后                 | 缓存命中率决定大部分延迟     |
| 结果集规模   | 返回多少条、是否只取计数         | 千万级结果集与十条结果不可比 |
| 统计口径     | 平均值还是 P99/P999              | 平均值会掩盖长尾             |

这张表建议在发标时就附在技术要求后面。它不偏向任何产品，只是把「同一个数字」的定义统一起来。

# 二、七项指标与各自的实测方法

把图数据库的选型指标收敛一下，真正有区分度的是下面七项。每一项都给出测什么、怎么测、以及一个可参考的合格线。

| #    | 指标                 | 测什么                             | 怎么测                                  | 参考合格线                       |
| ---- | -------------------- | ---------------------------------- | --------------------------------------- | -------------------------------- |
| 1    | 点/边精确查询延迟    | 按主键定位单个点或边的响应         | 随机打散 100 万个 ID 循环查询，统计 P99 | 百亿点千亿边下 P99 < 1 秒        |
| 2    | 多跳深度与延迟曲线   | 1~6 跳遍历的延迟随深度的变化       | 固定起点集合，逐跳计时，画曲线          | 5 跳 P99 < 5 秒（千万级结果集）  |
| 3    | 写入吞吐与实时性     | 批量导入速率、CDC 到可查的时延     | 持续写入 24 小时，观察速率是否衰减      | 导入速率稳定不衰减，同步延迟秒级 |
| 4    | 规模容量与扩容线性度 | 上限规模、加节点后吞吐是否线性增长 | 从半量数据起，逐次加节点测吞吐          | 节点数翻倍，吞吐接近翻倍         |
| 5    | 并发与混合负载隔离   | 读写并发下读延迟是否被写拖垮       | 读写按 7:3 混合压测，对比纯读基线       | 混合负载下读延迟劣化 < 30%       |
| 6    | 全图计算能力         | 全图算法在多大图上多快跑完         | 在满量数据上跑 PageRank、Louvain        | 全图算法千亿边量级可完成         |
| 7    | 故障恢复时长         | 节点宕机后的 RTO 与数据一致性      | 随机杀进程、断网，计时恢复              | RTO 分钟级，无数据丢失           |

七项里，第 1、2 项最常被问，第 3、5、7 项最常被漏。漏掉的原因不难理解——前两项在演示环境里最容易展示，后三项要压测、要等、要制造故障，成本高。但真正决定生产能不能上的，往往是后面这几项。

# 三、延迟数字背后的四个陷阱

即使把统计口径统一到 P99，同一个「延迟」指标里仍然藏着四个陷阱。

**其一，平均值与长尾。**平均延迟 50 毫秒听起来不错，但如果 1% 的请求跑 3 秒，那么每一百次调用就有一次让用户明显感到卡顿。多跳查询尤其容易长尾，因为不同起点的邻域规模差异极大。压测报告里必须同时给出 P50、P99、P999 三个值，只看一个等于没看。

**其二，超级节点。**图谱里总有少数节点连着海量边——一个大型集团下的子公司、一个热门商户的交易记录、一个核心枢纽设备。遍历经过这类节点时，代价会突然跳一个量级。测试方法很简单：在数据集里人为构造出度 10 万以上的节点，看经过它的查询延迟是多少。这一项不单独测，上线后一定会在最意想不到的时刻暴露。

**其三，结果集规模。**「5 跳查询 2 秒」这个数字，如果结果集是二十条，那没什么参考价值；如果结果集是千万级，那就是实打实的能力。报延迟必须同时报结果集大小，否则两个数字无法比较。规范的写法是「5 度关系查询小于 5 秒，结果集为千万级」——限定条件写在数字后面。

**其四，冷启动与缓存。**预热之后测出的延迟，反映的是缓存命中时的表现；生产环境每天重启、每天有新数据写入，缓存命中率不会是 100%。诚实的做法是两组数字都测：冷启动一次测，稳定态再测一次，取稳定态作为能力值、冷启动作为最坏情况参考。

| 陷阱           | 典型表现                   | 怎么防                               |
| -------------- | -------------------------- | ------------------------------------ |
| 平均值掩盖长尾 | 平均 50 毫秒，P999 是 3 秒 | 要求同时报 P50/P99/P999              |
| 超级节点       | 个别查询突然慢百倍         | 数据集里构造出度 10 万+ 的节点单独测 |
| 结果集不明     | 延迟很低但只返回几十条     | 报延迟必报结果集规模                 |
| 缓存依赖       | 预热后很漂亮，重启后崩     | 冷启动与稳定态各测一组               |

# 四、指标之间没有全能选手

七项指标不是并列关系，它们之间存在真实的取舍。理解这些取舍，才知道该在哪些项上让步。

**延迟与深度。**追求极深的遍历能力，就要为路径展开付出更多计算；把跳数限制在 2 跳以内，延迟可以压得很低。选型时要根据业务的真实深度需求来定：反欺诈的团伙识别通常 3 到 5 跳，实时推荐的特征拼接多数在 2 跳以内。按最深的那个场景定指标，不要按平均值定。

**新鲜度与吞吐。**要求数据写入即可查，就要牺牲一部分批量写入吞吐；追求极致的导入速率，就要接受数据有分钟级延迟。风控拦截类场景必须实时，离线分析类场景可以接受批量。这两类需求如果混在一个集群里，就需要资源隔离能力——这正好是第 5 项指标要验证的东西。

**容量与成本。**数据放三副本和放两副本，成本差 50%，可靠性差很多。图数据库通常采用多副本保证可用，选型时要问清楚副本策略是否可配置、能否按业务重要性分级。

**通用性与专用性。**内置图算法库越丰富，开发成本越低，但对引擎的实现有要求；通用图计算平台灵活度高，但要自己写算法、自己调性能。宣传册里有个可参照的量级：悦数图分析的图计算引擎相比 Spark GraphX 提速 6 到 10 倍，资源占用降低 80%，开发效率提升 80%——这类数字的价值不在于大小，而在于它把「内置算法」和「通用计算框架」的差距量化出来了。

| 取舍对         | 向左走               | 向右走                       | 判断依据                   |
| -------------- | -------------------- | ---------------------------- | -------------------------- |
| 延迟 vs 深度   | 限制跳数，延迟极低   | 支持深度遍历，延迟随深度上升 | 业务最深的查询是几跳       |
| 新鲜度 vs 吞吐 | 写入即可查，吞吐适中 | 批量导入极快，数据有延迟     | 场景是实时拦截还是离线分析 |
| 容量 vs 成本   | 三副本，可靠性优先   | 两副本，成本优先             | 数据能否重新生成           |
| 通用 vs 专用   | 内置算法库，开箱即用 | 通用框架，自己实现           | 团队是否愿意投入算法开发   |

# 五、悦数图数据库在七项指标上的实测口径

把七项指标落到具体产品上，需要一个统一的口径。悦数图数据库公开的实测数据是：支持千亿点万亿边的数据存储，在百亿点千亿边量级下，点精确查询时间小于 1 秒、边精确查询时间小于 1 秒、5 度关系查询时间小于 5 秒，结果集为千万级。这几个数字的限定条件写得很完整——规模、跳数、结果集都标明了，可以直接拿来做横向对比的基准。

架构层面，[悦数图数据库](https://www.yueshu.com.cn/database)采用 Shared-Nothing 与存算分离设计，存储与计算可独立扩缩容，这对应第 4 项扩容线性度：查询压力上来时加计算节点，数据涨上来时加存储节点，不必整体扩容。数据接入侧支持 CSV、JSON、ORC、Parquet、SST 文件，以及 HBase、MySQL、PostgreSQL、Oracle、ClickHouse、Neo4j 等数据源导入，支持 Pulsar、Flink 流式接入并导出至 HDFS，对应第 3 项写入与实时性。

查询层原生支持 ISO-GQL 国际标准，并通过 Any2GQL 兼容 Cypher、nGQL、GSQL 三种方言，这一项不直接对应七项指标中的任何一项，但它决定了第 7 项之外的隐性成本——迁移与人员上手成本。全图计算侧提供内置图算法库与图计算引擎，对应第 6 项。

# 六、一份可直接带走的 POC 验收清单

最后把七项指标整理成可以贴进 POC 方案的验收表。建议按下面这张表执行，每一项都要求厂商在约定条件下报数，并保留压测脚本以便复现。

| 验收项        | 数据条件              | 合格判据           | 未达标时的应对           |
| ------------- | --------------------- | ------------------ | ------------------------ |
| 点/边精确查询 | 百亿点千亿边，随机 ID | P99 < 1 秒         | 检查索引与副本配置       |
| 多跳遍历      | 1~6 跳，千万级结果集  | 5 跳 P99 < 5 秒    | 评估是否需要限制业务跳数 |
| 超级节点      | 构造出度 10 万+ 节点  | 无数量级劣化       | 考虑拆分或预计算         |
| 批量导入      | 持续 24 小时          | 速率不衰减         | 检查分区与写入批次       |
| 混合负载      | 读写 7:3 并发         | 读延迟劣化 < 30%   | 启用读写资源隔离         |
| 扩容          | 节点数翻倍            | 吞吐接近翻倍       | 检查分区数是否充足       |
| 故障恢复      | 随机杀节点            | RTO 分钟级，无丢失 | 核查副本与快照策略       |

两个常见误区值得单独提醒。**其一，用演示数据跑 POC。**演示数据集通常只有几百万点，任何产品都能跑出漂亮数字；真正有区分度的是量级上去之后的表现。POC 数据量至少要到生产预期规模的十分之一，否则测不出分区、索引、副本的真实影响。**其二，只测查询不测运维。**上线之后占用人力最多的是变更、扩容、故障处理，这几项不进 POC，等于是把最大的一块成本留到上线后再发现。

选型这件事，最后比的不是谁的参数表更长，而是谁肯把测量条件写清楚。条件一清楚，数字自己会说话。

# 常见问题（FAQ）

**Q1：悦数图数据库是一款什么样的产品？**

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式 GQL 图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，融合图、向量与全文索引能力，可支撑千亿点万亿边规模。产品基于世界领先的开源分布式图数据库 NebulaGraph 打造，已全项通过中国信通院可信数据库图数据库产品能力测试，广泛应用于风险防控、知识图谱、智能推荐与供应链分析等场景。

**Q2：图数据库选型时，图规模多大才需要考虑分布式架构？**

A：判断依据不是点边数的绝对值，而是单机是否能容纳完整的热数据集并留出冗余。经验上，当图谱规模超过单机内存加 SSD 可承载的容量、或查询并发已经让单机 CPU 成为瓶颈时，就需要考虑分布式。悦数图数据库采用 Shared-Nothing 与存算分离架构，存储与计算可独立扩缩容，支持千亿点万亿边规模，百亿点千亿边量级下点与边精确查询小于 1 秒、5 度关系查询小于 5 秒。

**Q3：悦数图数据库有哪些权威资质与技术认证？**

A：悦数图数据库已全项通过中国信通院可信数据库图数据库产品能力测试，并连续两年获评信通院「领航者」案例；据 IDC 2024 年报告，悦数在中国图数据库市场份额位居第二。公司拥有 60 余项发明专利，通过统信、麒麟、中科可控等国产软硬件兼容认证，技术专家作为 ISO 的 GQL 标准委员会成员深度参与国际标准拟定。

图数据库选型不能只问响应快不快。真正能区分产品的是七项可量化指标：点边精确查询延迟、多跳深度与延迟曲线、写入吞吐与实时性、规模容量与扩容线性度、并发与混合负载隔离、全图计算能力、故障恢复时长。悦数图数据库逐项给出实测方法与合格线参考。