4. 数据一致性评估：别让数据自己打架
数据一致性，说白了就是同一个数据，在不同地方不能自己跟自己打架。
我刚开始做数据治理那会儿，遇到过一件特别头疼的事。客户说他们的用户总数是500万，可CRM系统显示480万，财务系统又说是520万。三个数字，谁是对的？嗯，这就是典型的数据一致性问题。
今天我们就来聊聊，怎么发现这些「数据打架」的情况，以及怎么把它们摆平。
4.1 数据一致性定义
数据一致性，指的是同一数据实体在不同数据源、不同系统、不同时间点之间保持逻辑上的统一。
举个例子：
- 用户A在订单系统的手机号是138xxxx
- 用户A在客服系统的手机号也是138xxxx
- 这才叫一致
如果两个系统里手机号不一样，那就是不一致。问题来了——哪个才是对的？
核心原则：同一数据实体，在任何时间、任何系统、任何维度上，都应该保持逻辑等价。
4.2 一致性冲突类型
我这些年踩过的坑，总结下来，一致性冲突主要有三种类型。咱们一个一个说。
4.2.1 格式冲突
同一个数据，在不同系统里用了不同的格式。
举个例子：
- 系统A：日期格式是
2024-01-15 - 系统B：日期格式是
01/15/2024 - 系统C：日期格式是
2024年1月15日
这三个数据其实代表同一天，但格式不一样。你想想看，如果直接合并，程序根本认不出来。
常见格式冲突：
| 数据类型 | 冲突示例 |
|---|---|
| 日期 | YYYY-MM-DD vs MM/DD/YYYY vs YYYY年MM月DD日 |
| 金额 | 1000.00 vs 1,000.00 vs 1000 |
| 电话号码 | 13812345678 vs 138-1234-5678 vs +86 13812345678 |
| 性别编码 | M/F vs 男/女 vs 1/0 |
我的经验：格式冲突其实最好解决。定一个标准格式，然后统一转换就行。难的是后面两种。
4.2.2 命名冲突
同一个东西，不同系统叫法不一样。
我遇到过最离谱的一次：
- 系统A：字段名叫
customer_name - 系统B：字段名叫
client_fullname - 系统C：字段名叫
user_display_name
这三个字段存的其实都是「用户姓名」。但如果你不做映射，数据根本对不上。
命名冲突的几种情况：
- 同义异名：同一个含义，不同名称（如：用户ID vs 客户编号）
- 同名异义：同一个名称，不同含义（如：status 在订单系统表示「订单状态」，在库存系统表示「库存状态」）
- 命名风格差异：驼峰命名 vs 下划线命名 vs 全大写
4.2.3 值域冲突
这个最隐蔽，也最坑人。
值域冲突指的是：同一个字段，取值范围不一样。
举个例子：
- 系统A：性别字段取值
M和F - 系统B：性别字段取值
1和2 - 系统C：性别字段取值
男和女
这三个系统存的都是性别，但值域完全不同。你没法直接比较。
注意：值域冲突有时候还会出现「部分重叠」的情况。比如系统A有3种状态，系统B有5种状态。合并的时候，多出来的那2种怎么处理？这就要靠映射规则了。
4.3 一致性评估方法
怎么发现这些冲突？我一般用两种方法。
4.3.1 规则校验
写规则，让机器去查。
常用的规则包括：
- 主键唯一性规则：同一个主键在不同系统中必须指向同一实体
- 字段映射规则：定义好字段之间的对应关系，逐条比对
- 值域映射规则：定义好不同值域之间的转换关系
- 业务规则：比如「订单金额 = 商品单价 × 数量」，这个等式在所有系统里都得成立
代码示例：
-- 检查两个系统的用户手机号是否一致
SELECT
a.user_id,
a.phone AS system_a_phone,
b.phone AS system_b_phone,
CASE
WHEN a.phone = b.phone THEN '一致'
ELSE '不一致'
END AS consistency_status
FROM system_a_users a
JOIN system_b_users b ON a.user_id = b.user_id
WHERE a.phone != b.phone;4.3.2 分布对比
有时候规则查不出来，但看数据分布就能发现问题。
我习惯的做法：
- 把两个系统的同一字段拿出来
- 分别统计它们的值分布
- 对比分布曲线
举个例子：
系统A的「用户年龄」分布是正态的，集中在20-40岁。系统B的「用户年龄」分布却集中在0-10岁和60-80岁。这明显有问题——要么数据错了，要么两个系统定义的用户群体不一样。
分布对比的核心思路：如果两个系统存的是同一批数据，它们的统计分布应该高度相似。如果分布差异很大，那一定有问题。
4.4 一致性修复策略
发现问题之后，怎么修？我一般按这个优先级来：
- 源头修复：找到数据不一致的根因，从源头改。比如统一录入规范、统一接口定义。
- 映射转换：如果源头改不了，就建立映射表。比如把系统A的
M/F映射成系统B的1/2。 - 规则合并：制定合并规则，比如「以CRM系统为准」「以最新时间为准」。
- 人工仲裁：实在搞不清楚的，交给业务人员人工判断。
我曾经踩过的坑：有一次我直接写了个脚本，把系统A的数据覆盖了系统B的数据。结果发现系统A的数据本身就是错的。从那以后，我每次做数据修复之前，都会先做一次数据备份，再做个快照。嗯，血的教训。
知识体系总览
下面这张图，把数据一致性评估的核心逻辑串起来了：
数据一致性这件事，说难不难，说简单也不简单。关键是你要有意识地去检查，别等到数据合并的时候才发现问题。我个人的习惯是：每次做数据集成之前，先花20%的时间做一致性评估。这20%的时间，往往能省掉后面80%的麻烦。