多源维度合并是什么
同一个客户在主数据系统、CRM、ERP 里各有自己的编码，入仓时必须合成一条维度记录，否则按客户做的统计会把人拆成三个人。标准做法是以主数据系统为基准，建立交叉引用表（xref）保存各源编码到统一代理键的映射，维度行上保留各源编码列，下游按自己手里的编码就能关联到同一个人。
基本信息
| 基准 | 主数据系统（MDM）或指定权威源 |
|---|---|
| 映射设施 | xref 交叉引用表：统一代理键 ↔ 各源编码 |
| 维度结构 | 一行保留 mdm_code、crm_code、erp_code 等列 |
| 匹配手段 | 优先强标识（证件、手机），再模糊匹配（姓名+生日） |
| 维护归属 | xref 是公共设施，需专人或专门作业维护 |
典型使用场景
- 集团多系统整合：并购后两家公司的客户编码需要归一
- 线上线下一体：门店会员卡号与 App 账号指向同一个人
- 主数据落地：MDM 下发统一编码，维表补齐各业务系统编码列
- 跨域分析：按客户维度汇总订单、服务工单与财务结算
- 新增来源接入：新系统上线时先建映射再导数据
- 合并排查：发现同一人被拆成多行时，回溯 xref 的匹配结果
交叉引用与合并
交叉引用与合并
-- 1) 按各源编码都能查到同一个代理键
SELECT user_sk, mdm_code, crm_code, erp_code
FROM dim_user_xref
WHERE mdm_code = 'U10086';
-- 2) 维度行保留各源编码，下游按手里的编码关联
SELECT f.order_id, d.user_name
FROM fact_order f
JOIN dim_user d ON f.user_sk = d.user_sk
WHERE f.crm_code = 'C-8899'; -- 业务方只知道 CRM 编码也能查
-- 3) 未匹配清单：进了事实但 xref 里找不到的编码
SELECT DISTINCT o.crm_code
FROM fact_order o
LEFT JOIN dim_user_xref x ON o.crm_code = x.crm_code
WHERE x.user_sk IS NULL;匹配手段对照
| 手段 | 适用 | 风险 |
|---|---|---|
| 证件号、统一社会信用代码 | 强标识，命中即确认 | 敏感信息需脱敏存储，缺失时不可用 |
| 手机号 | 命中率高 | 换号与共用号会误并 |
| 邮箱 | B 端客户常用 | 一人多邮箱会漏并 |
| 姓名 + 生日 | 强标识缺失时的备选 | 同名同生日会误并，须人工复核 |
| 地址 + 名称近似 | 兜底 | 误并率高，只做候选不做自动合并 |
自动匹配只用于生成候选，正式合并要保留可回退记录：误并把两个真实客户合成一个，会直接导致收入、应收与信用额度算错，且拆回来比合并更麻烦。合并与拆分都必须写审计日志。