同一商品在不同系统SKU都不一样——主数据（MDM）管理怎么落地？

-- 方式1: 基于唯一标识精确匹配（最简单）
-- 商品有全球唯一GTIN/UPC条码
SELECT a.*, b.* FROM erp_product a
JOIN ec_product b ON a.gtin = b.gtin;  -- 一一对应
 
-- 方式2: 基于关键字段模糊匹配
-- 没有共同ID，靠名称+品牌+规格组合
SELECT *
FROM erp_product a JOIN ec_product b
  ON LOWER(TRIM(a.brand)) = LOWER(TRIM(b.brand))
  AND LEVENSHTEIN(a.name, b.name) <= 3  -- 编辑距离
  AND ABS(a.weight_g - b.weight_g) < 5;
 
-- 方式3: 机器学习匹配（大规模数据）
-- 提取多字段特征，训练分类器
-- features: name相似度、brand是否一致、价格差、规格相似度
-- 输出: 是否同一实体的概率

# 黄金记录合成策略
 
# 策略1: 优先级（按数据源可信度）
def golden_by_priority(records):
    sources_priority = {'erp': 1, 'pim': 2, 'ec': 3}  # erp最权威
    return sorted(records, key=lambda r: sources_priority[r.source])[0]
 
# 策略2: 字段级权威源
def golden_by_field(records):
    golden = {}
    golden['gtin'] = pick_from(records, source='erp')      # 条码以erp为准
    golden['name'] = pick_from(records, source='pim')      # 名称以pim为准
    golden['price'] = pick_from(records, source='ec')      # 价格以电商为准
    golden['stock'] = pick_from(records, source='wms')     # 库存以仓储为准
    return golden
 
# 策略3: 投票/最新值
def golden_by_recency(records):
    return max(records, key=lambda r: r.updated_at)

字段级权威源是最实用的方式——不同字段的「权威性」不一样，由各业务域owner来定。我们在出海硬件公司给每个字段标注了权威源，争议也少。

核心三：变更分发（一处变更全域生效）

MDM不仅是「现在对齐」，还要保证「未来一直对齐」。当某个字段变更时，必须通知所有下游系统更新：

# 变更分发架构
 
[业务系统1] 改商品 → [MDM平台] 接收变更
                       ↓
                   [实体识别] 这是哪个全局商品？
                       ↓
                   [黄金记录更新] 更新MDM主数据
                       ↓
                   [变更事件流] Kafka广播到所有订阅方
                       ↓
    [下游系统1] [下游系统2] [数仓] [BI]
    各自消费事件，更新本地数据

MDM落地的关键技术组件

组件	职责	技术选型
主数据存储	存所有黄金记录	Hologres/MySQL/PostgreSQL
映射存储	实体ID映射关系	图数据库（Neo4j）/关系表
实体识别引擎	去重和匹配	Apache Spark MLlib / 自研
变更事件流	广播变更	Kafka / RocketMQ
治理控制台	人工审核+冲突解决	Web UI + 工单系统

MDM和数仓维度建模的关系

MDM和数仓维度（Dimension）有交集但不是一回事：

• MDM：跨业务系统的统一主数据，重点是OLTP系统间的对齐

• 维度建模：数仓内部的分析维度，重点是OLAP查询

最佳实践：MDM作为数仓维度的权威输入源。我们出海硬件公司的dim_product全量从MDM平台同步，保证维度表和业务系统永远对齐。

面试高频追问

追问一：MDM和数据治理是什么关系？

MDM是数据治理的子集（也是核心子集）。数据治理范围更广（含数据质量、元数据、安全、生命周期等），MDM专注「核心实体的一致性」。一般落地顺序：先做元数据管理打底 → 做MDM对齐核心实体 → 做DQC质量监控 → 做血缘和影响分析。MDM在第二步做最有性价比。

追问二：电商场景里SKU/SPU怎么管？

SPU（Standard Product Unit）是「商品概念」（iPhone 15），SKU（Stock Keeping Unit）是「具体规格」（iPhone 15 Pro Max 256G 黑色）。MDM要建立SPU-SKU的层级关系：SPU是父节点，SKU是子节点。分析维度按SPU还是SKU取决于业务问题——「iPhone卖了多少」按SPU，「具体规格的库存」按SKU。我们用图模型存这种层级，比关系表灵活。

追问三：MDM怎么保证不同业务方的Master定义一致？

最难的不是技术是组织。三个机制：①设立数据治理委员会（含各业务方代表），定义有争议的字段；②每个主数据域设立Data Steward（数据管家）负责日常对接；③争议走升级机制：业务团队解决不了的争议升到委员会，委员会解决不了的升到管理层。我在出海硬件公司参与过几次跨部门争论，最终都靠这套机制收敛。

实战踩坑：一次MDM上线导致的全量数据回流

出海硬件公司MDM上线第一天，我们要把所有下游系统的product_id替换成MDM统一ID。当时有个实施细节没考虑到：

数仓里历史10亿条订单数据的product_id还是旧的，新订单用新ID，结果同一个商品在「3月15日之前的销量」用旧ID，「3月15日之后的销量」用新ID，分析师查「过去3个月销量」直接报错——SQL里没法用一个ID关联到全部订单。

解决方案：两个层面修复：

1）建ID映射表：旧ID ↔ 新ID，所有跨期分析都先join映射表

2）历史数据分批回算：把过去2年的事实表product_id字段全部更新成新ID，按月分批跑了两周

-- ID映射表
CREATE TABLE mdm_product_id_mapping (
  legacy_id STRING,
  legacy_source STRING,    -- erp / ec / wms
  global_id STRING,        -- MDM全局ID
  effective_from DATE,
  effective_to DATE
);
 
-- 跨期分析的标准写法
SELECT m.global_id, SUM(o.amount)
FROM dwd_order o
LEFT JOIN mdm_product_id_mapping m
  ON o.product_id = m.legacy_id AND o.source = m.legacy_source
WHERE o.dt BETWEEN '20240101' AND '20240331'
GROUP BY m.global_id;

教训：MDM上线绝对不能只考虑「新数据」，必须有完整的历史数据迁移方案。哪怕短期靠映射表过渡，长期也要把历史数据的ID统一。这是给所有要做MDM的团队的忠告。

总结

MDM三件事：识别+关联+变更分发。三种模式（集中/注册/混合）按现状选。配合实体识别+黄金记录+变更广播。治理是组织活，技术是基础。面试时按模式对比+核心组件+SKU/SPU实例+历史回流故事讲，能体现跨域治理深度。

下一篇聊一个数据治理的核心工具：数据血缘怎么用于质量保障？

你们公司有没有MDM？管哪些主数据域？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长