策略一实践：数据标准落地的五个关键动作

数据标准这件事，说起来简单，做起来全是坑。我见过太多团队，花三个月写出一本厚厚的标准文档，然后……就没有然后了。文档锁在共享盘里，没人看，更没人用。

为什么会这样？因为大家只做了「制定标准」这一步，后面的落地、管理、检查全跳过了。今天我就把这五个动作拆开来讲，每个都是我踩过坑之后总结出来的。

5.1 制定数据标准文档——别写成「天书」

标准文档怎么写？很多人一上来就列几百个字段定义，看得人头晕。我个人习惯是：先定骨架，再填血肉。

文档应该包含四个核心部分：

• 命名规范——表名、字段名、文件名的统一规则。比如：表名用ods_业务域_主题_日期分区，字段名全小写+下划线。
• 数据类型规范——同一字段在不同系统里必须用同一类型。金额字段统一用decimal(18,2)，别一个系统用float，另一个用number。
• 字典值规范——枚举值、状态码、分类标签必须统一。比如性别：0-未知，1-男，2-女，别出现M/F、male/female混用。
• 质量规则——每个字段的完整性、唯一性、格式校验规则。比如手机号必须11位，邮箱必须含@。

5.2 建立数据标准库——把文档变成「活字典」

文档写好了，下一步就是把它从Word里搬出来，变成一个可查询、可维护的标准库。说白了，就是给标准一个「家」。

标准库应该具备三个能力：

• 在线查询——支持按表名、字段名、业务域搜索。我建议用Data Catalog工具，或者自己搭一个简单的Web页面。
• 版本追溯——每次修改都要留记录，谁改的、什么时候改的、改了什么。这个后面会细讲。
• 自动同步——标准库能跟数据建模工具、ETL工具打通。比如你在标准库里改了字段类型，建模工具能自动收到通知。

我记得有一次，业务部门要求新增一个「客户等级」字段，标准库里没有定义。结果三个系统各自定义了自己的枚举值：A系统用1/2/3，B系统用VIP/普通/潜在，C系统用高/中/低。最后做数据汇总时，完全对不上。如果当时有标准库，这种事根本不会发生。

5.3 标准落地执行——最难的一步

标准有了，库也建了，但怎么让所有人遵守？这是整个策略里最难的一环。我见过最典型的场景：标准文档挂在墙上，开发同学写代码时该咋写还咋写。

我的做法是「三管齐下」：

1. 工具强制——在数据建模工具里预置标准模板。新建表时，字段类型、命名规则直接套用标准，想改都改不了。
2. 流程卡点——在数据上线流程中增加「标准审核」环节。没有通过标准检查的数据表，不允许进入生产环境。
3. 自动化检查——写一个脚本，每天扫描所有新增和变更的表，自动比对标准库，生成合规报告。

5.4 标准版本管理——标准也会「长大」

数据标准不是一成不变的。业务在变，系统在变，标准也得跟着变。但怎么变，是个技术活。

版本管理要遵循三个原则：

举个例子：我们曾经把「订单状态」的枚举值从5个扩展到8个。如果直接全量发布，所有下游系统都得跟着改，工作量巨大。后来我们用了灰度发布，先让两个报表系统适配新版本，跑了一个月没问题，再通知所有系统升级。整个过程用了三个月，但零事故。

5.5 标准合规检查——没有检查，等于没有标准

最后一步，也是很多人忽略的一步：检查。标准定得再好，如果不检查，很快就会被人「遗忘」。

合规检查应该做成「常态化」：

• 每日扫描——自动检查所有新增数据表，是否遵循命名规范、类型规范。
• 每周报告——生成合规率趋势图，发给各团队负责人。
• 每月评审——召开标准合规评审会，讨论不合规项的整改方案。

-- 检查表名是否遵循命名规范
SELECT table_name,
       CASE 
         WHEN table_name ~ '^ods_\w+_\d{8}$' THEN '合规'
         ELSE '不合规'
       END AS 合规状态
FROM information_schema.tables
WHERE table_schema = 'public';

核心逻辑一览

下面这张图，把这五个动作的关系画清楚了。你可以把它当作团队落地数据标准的「路线图」。

这五个动作，环环相扣。少了任何一个，标准都落不了地。我个人建议：先从「制定文档」和「合规检查」两个动作开始，跑通闭环之后，再逐步引入标准库和版本管理。别想一口吃成胖子，数据治理是个持久战。