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

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

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

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

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

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

源系统	主键形态	可用的强标识	常见缺失	主要风险
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 等格式，能直接对接现有数据管道；内置连通子图、社区发现、最短路径等算法可直接用于簇划分与巡检；千亿点万亿边的规模下多跳查询保持毫秒至百毫秒级响应，全量重跑不必拆成离线任务（具体容量与延迟边界可参照千亿点万亿边的实测口径）。若还要横向比较不同产品在同一场景下的表现，选型的七项可测指标给了可以照着执行的验收方法。

六、落地清单与两个误区

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

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

两个误区值得单独提醒。

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

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

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

相关阅读

常见问题（FAQ）

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

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

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

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

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

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