主数据项目上线前做数据摸底，客户表 12 万条，去重后剩 9 万多。同一个人留了三四条：手机号一个带区号一个不带，地址一条写「XX路 18 号」一条写「XX路十八号」，更新时间相差两年。业务方只问一句，报表按哪条算。这就是黄金数据要解决的问题。

它解决的是同一实体在多个系统里打架

黄金数据指同一客户、商品或供应商在多个源系统里冲突时，经过比对、合并、存活规则处理后留下的唯一主记录。它不追求字段最全，追求每个字段都能追到来源、更新时间、置信度。名字好听，本质是一份带血缘的主记录。

合并规则要写死在配置里

常见做法是按字段排优先级，不按系统整体排：CRM 的手机号最准，ERP 的开票地址最准，官网留资只做补充。规则落到字段级，比如手机号取最近一次验证通过的值，地址取最近 180 天内有订单的那条。规则定完跑一遍，冲突率通常能从十几个百分点降到个位数。

落地时最容易踩的三个坑

  • 只去重不合并：删掉重复行就收工，结果丢掉大半字段，过两周还得回捞原始数据。
  • 没有黄金 ID：合并后要生成稳定主键，各源系统的 ID 全挂到映射表，否则下次增量同步又裂成两条。
  • 不记录血缘：字段来自哪张表、哪次合并、谁手工改过，都要留痕，对账出问题才查得动。

一套能跑起来的最小流程

先做标准化，手机号去空格、地址补省市；再分块比对，按手机号和证件号做 blocking，避免全表两两比对；然后算相似度，编辑距离加权字段权重；合并生成黄金记录，回写映射表。9 万条数据在普通四核机器上用 pandas 跑，分块做好半小时内出结果。

工具别一上来就买平台

字段十来个、源系统三五个，SQL 加脚本完全够用，规则写在配置表里，业务改一次不用找你发版。源系统过了十个、合并规则要业务自己调，再考虑主数据平台，否则光建模型和配置流程就得折腾几个月，数据还没洗干净。

值不值得建这套流程，看下游有多少系统在读这份数据。只有一张报表用，人工核对更快；五个系统各维护一份客户信息、口径天天吵，那就早点建。