“一数一源”怎么真正落地:从 17 家单位主数据整合看标准先行
标签:#数据标准 #数据治理 #主数据 #数据目录 #数据质量
摘要: "一数一源、一源多用"喊了很多年,多数组织停留在口号——源头没人认定、标准各写各的、目录越建越多。胜利油田数据湖标准区的实践给出了一个可拆解的样本:三级标准协同体系、9 大板块企业标准、试点整合 17 家单位数据表结构、唯一数据资源目录、整改 131 万条问题数据,接口交付从 32.3 天压到 2 天。本文拆解这套机制的构成与验收指标。
文章目录
- “一数一源”怎么真正落地:从 17 家单位主数据整合看标准先行
- 一、前言:一数一源为什么喊了十年落不了地
- 二、机制拆解:一数一源的四个构成
-
- 2.1 源头认定:按数据项认定,不按系统认定
- 2.2 标准先行:先立规矩,再动数据
- 三、案例拆解:17 家单位表结构整合的路径
- 四、标准体系怎么分层:国家—行业—企业三级协同
- 五、验收:用什么指标证明做成了
- 六、踩坑清单
- 七、总结
一、前言:一数一源为什么喊了十年落不了地
"一数一源"是数据治理领域普及率最高的口号之一,也是落地率最低的之一。原因不复杂:它不是技术问题,是机制问题——
- 谁来认定"源"?业务部门都想自己是源头,认定权没人敢接;
- 源头认了,标准谁定?同一个"客户编码",三家单位三套规则,改谁的?
- 目录建了一个又一个,每个项目建自己的目录,“唯一目录"变成"又一个目录”。
最近看到的胜利油田数据湖标准区实践,把这些问题给出了成体系的答案:以 GB/T 44109-2024 等国家标准为基础,构建"国家—行业—企业"三级标准协同体系,牵头制定覆盖总则、数据资源目录、元数据、主数据等 9 大核心板块的系列企业标准;统一主数据标准,试点整合 17 家单位的数据表结构,打通跨业务域数据关联壁垒;建立全油田唯一的数据资源目录。成效口径:数据采集时间从 2 小时缩到 0.5 小时,数据更新从 30 分钟到秒级,累计整改问题数据 131 万余条,接口交付周期从 32.3 天压到 2 天。
值得学的不是油田,是"标准先行 + 机制配套"的打法。 本文按机制拆解。
二、机制拆解:一数一源的四个构成
一数一源不是一条原则,是四个机制咬合的系统。缺一个,整条失效:
| 源头认定 | 谁是权威源 | 按数据项逐项认定源系统与源部门,发文明确 | 同一字段多头上报,无人裁决 |
| 标准先行 | 源头按什么规范产数 | 数据标准(编码、格式、字典)先于整合发布 | 整合完发现口径打架,推倒重来 |
| 唯一目录 | 数据从哪找 | 全组织唯一数据资源目录,来源可追溯、使用可监管 | 各项目自建目录,同一资产多处登记 |
| 质量管控 | 源头数据不对怎么办 | 分级管控机制,问题数据闭环整改 | 问题数据长期挂账 |
2.1 源头认定:按数据项认定,不按系统认定
最常见的错误是按"系统"认定源头——宣布"客户主数据以 CRM 为源"。问题是 CRM 里也有从外部采买的字段、也有被其他系统反写的字段。正确粒度是数据项:逐项认定"客户联系方式以 CRM 为源、行业分类以外部数据服务为源、信用等级以风控系统为源"。
认定结果要落成一张源头认定矩阵(数据项 × 源系统 × 源部门 × 认定依据),发文生效。这张矩阵是后面所有争议的裁决依据,也是目录里"来源可追溯"的数据基础。
2.2 标准先行:先立规矩,再动数据
胜利油田案例里最容易忽视的顺序:9 大板块企业标准(总则、目录、元数据、主数据……)先于 17 家单位表结构整合发布。这就是"标准先行"——如果先动手整合,17 家单位的表结构已经摆上桌面,每一家都会为自己的现状辩护,标准永远谈不拢。
企业标准的内容不必贪多,四个部分是底线:编码规则(主数据的唯一编码怎么生成)、字典规范(枚举值统一)、元数据要求(每张表必须登记哪些信息)、接口规范(源头数据怎么对外服务)。
三、案例拆解:17 家单位表结构整合的路径
多单位表结构整合是一数一源最难啃的硬仗。从案例口径还原路径,大致四步:
第一步,选试点域。 不是全部主数据一起上,选一个跨单位争议大但业务价值明确的域打样(案例中是跨业务域关联壁垒最突出的主数据域)。试点成功的标志不是技术打通,是参与单位认可规则——第一个域的规则立住了,后面的域是复制。
第二步,表结构比对与归并。 对 17 家单位的表结构做字段级比对,产出三类清单:可直接归并的(同名同义)、需映射的(同名异义/异名同义)、需新建的(缺项)。映射清单是标准落地的核心产物——它显式记录了"旧结构到新标准"的翻译关系,历史数据迁移靠它。
第三步,迁入共享主题区。 归并后的数据迁入统一的数据湖标准区(共享主题区),先做增量迁入(新数据按标准入),存量按业务节奏逐步补——增量先行是控制风险的常规做法,存量一次性切换的失败率极高。
第四步,下游切换与旧源退役。 157 个应用系统依托标准层运行,前提是下游逐步切换到标准区取数。这里有个铁律:旧源不退役,一数一源就没有真正发生——下游继续从旧源取数,新源头就成了摆设。退役要排计划、给缓冲期、逐个确认。
四、标准体系怎么分层:国家—行业—企业三级协同
单打独斗写企业标准,容易闭门造车;案例的三级协同值得抄:
| 国家标准 | 提供通用框架与术语 | GB/T 44109-2024 等数据治理国标 |
| 行业标准 | 补行业特定口径 | 石油行业数据规范 |
| 企业标准 | 落到可执行的板块规范 | 9 大板块系列标准(总则/目录/元数据/主数据等) |
企业标准不发明原则,只做两件事:选(从国标/行标中选用适用的条款)和填(填行业与企业特有的编码、字典、流程)。这样标准既有权威背书(审计、贯标时直接引用国标条款),又能落地执行(板块级规范细到可开发)。
五、验收:用什么指标证明做成了
一数一源最怕"开完发布会就算落地"。给一组可核验的验收指标(案例口径可参考):
| 采集耗时 | 2 小时 → 0.5 小时 | 重复采集被源头化消除 |
| 更新时效 | 30 分钟 → 秒级 | 源头变更直达标准区 |
| 问题数据整改 | 累计 131 万条 | 质量管控闭环在转 |
| 接口交付周期 | 32.3 天 → 2 天 | 标准化接口免逐个开发 |
| 系统支撑面 | 157 个应用平稳运行 | 下游真实切换,非示范工程 |
前两个指标验"源"是否唯一,后三个验"用"是否畅通。接口交付周期是最硬的一个:从一个月到一个工作日,说明下游取数不再依赖人工开发对接——这是标准区真正被当基础设施用的信号。
六、踩坑清单
| 按系统而非数据项认定源头 | 交叉字段无人认领 | 源头认定矩阵逐项发文 |
| 标准后于整合发布 | 各家为现状辩护,谈不拢 | 标准先行,再动数据 |
| 存量一次性切换 | 迁移失败、业务中断 | 增量先行,存量按节奏补 |
| 旧源不退役 | 一数一源名存实亡 | 退役排计划、给缓冲、逐个确认 |
| 目录多头建设 | 同一资产多处登记 | 唯一目录 + 登记准入 |
| 无验收指标 | 项目变成汇报工程 | 采集/时效/整改/交付四类指标前置定义 |
七、总结
一数一源落地的公式可以概括为:数据项级源头认定 × 标准先行 × 唯一目录 × 质量闭环 × 硬指标验收。五个要素里,最容易被跳过的是"标准先行"和"硬指标验收"——前者省了眼前的会议,后者留了汇报的体面,代价都是机制空转。
三个起步建议:先产出源头认定矩阵(哪怕只覆盖一个主数据域);企业标准从国标里"选"而不是"发明";把接口交付周期设为北极星指标——它一降,说明下游真的在用。
你的一数一源卡在源头认定还是旧源退役?欢迎评论区交流。
推荐阅读:主数据管理(MDM)落地实战:六步法|数据退役与归档治理|数据目录冷启动避坑复盘
网硕互联帮助中心





评论前必须登录!
注册