重复实体怎么归并
多源系统常出现同一实体多条成员：同一个客户在 CRM 与订单系统各有一个编号。合并策略是先按确定性规则自动归并（证件号、统一社会信用代码），剩余灰名单交人工评审；合并必须保留来源标记与旧键映射，否则下游无法把历史数据挂到合并后的成员上。
基本信息
| 自动规则 | 证件号、统一编码等确定性键优先 |
|---|---|
| 人工评审 | 灰名单（姓名加生日等弱匹配）人工确认 |
| 映射表 | 旧自然键到合并后代理键的对应关系，带生效区间 |
| 可逆性 | 保留合并记录，支持后续拆分 |
| 影响范围 | 合并会改变历史归属，需要重刷受影响事实 |
典型使用场景
- 多系统客户合并：CRM、订单与客服系统里的同一客户归并
- 供应商主数据治理：同一供应商的多个编码统一
- 商品重复清理：不同渠道录入的同一商品合并
- 口径统一：合并后客户数、复购率等指标才有意义
- 审计追溯：证明某个历史编号现在指向哪个成员
旧键映射表
旧键映射表
-- 保留旧键映射：合并后旧自然键仍可解析到同一代理键
CREATE TABLE dim_customer_keymap (
source_sys string COMMENT '来源系统',
natural_key string COMMENT '旧自然键',
customer_sk bigint COMMENT '合并后代理键',
start_date date COMMENT '生效起始日期',
end_date date COMMENT '生效结束日期'
) STORED AS ORC;匹配依据与处理
| 匹配依据 | 强度 | 处理方式 |
|---|---|---|
| 证件号与统一编码 | 强 | 自动合并 |
| 手机号与邮箱 | 中 | 需要二次确认 |
| 姓名加生日 | 弱 | 人工评审 |
| 地址与名称相似 | 弱 | 仅作线索，不自动合并 |
合并动作会改变历史归属：要么重刷受影响的事实表，要么明确接受按当时键的历史口径，两者选其一并写进规范，不能模糊处理。
自动合并规则过宽会误并真实不同的实体：误并之后拆分成本极高，因此弱匹配一律走人工评审，宁可漏并不可错并。