1、数据质量概述

各位同学，咱们今天聊聊数据质量。说实话，我做了十几年数据架构，见过太多因为数据质量问题翻车的项目。有的上线当天就崩，有的跑了一个月才发现报表全是错的。嗯，数据质量这事儿，真不是小事。

什么是数据质量

数据质量，说白了就是数据能不能用、好不好用。你想想看，如果一份数据连基本准确都做不到，那它还有什么价值？

我个人习惯把数据质量定义为：数据满足业务使用需求的程度。这个定义很关键——它告诉我们，数据质量不是的，而是相对的。同样的数据，在A场景下可能质量很高，换到B场景可能就不及格了。

我在项目中遇到过一件事：某次做用户画像系统，数据团队说数据质量99.9%，结果业务部门一用就炸了——用户性别字段有30%是空的。技术上看，空值不算错；业务上看，这数据根本没法用。所以，数据质量必须从业务视角出发。

数据质量六大维度

业界公认的数据质量框架，一般包含六个维度。我一个个说，每个都带点实战经验。

维度	定义	常见问题
准确性	数据是否真实反映客观事实	金额算错、地址写错、时间戳偏差
完整性	数据是否缺失必要字段或记录	必填字段为空、记录丢失、关联断裂
一致性	不同系统间的数据是否相互吻合	用户ID不统一、状态码定义冲突
及时性	数据是否在预期时间内可用	延迟到达、过期数据未清理
唯一性	数据实体是否被重复记录	重复订单、重复用户、主键冲突
有效性	数据是否符合定义的格式和规则	手机号格式错误、枚举值越界

准确性

准确性是最直观的维度。数据错了，后面全白搭。我曾经接手过一个订单系统，里面有个字段叫「订单金额」，结果发现同一笔订单在数据库里存的是分，在缓存里存的是元，在日志里存的是厘。你说这数据谁敢信？

完整性

完整性分两种：字段完整性和记录完整性。字段完整性是说必填项不能为空；记录完整性是说该有的数据不能少。

我记得有一次做数据迁移，源库有100万用户，目标库只迁了80万。查了半天，发现是某个分片的数据因为网络超时被跳过了，但没有任何报错。这就是记录完整性出了问题。

一致性

一致性在微服务架构里尤其重要。不同服务各自维护数据，很容易出现「同一个用户，不同ID」的尴尬局面。

举个例子：订单服务里用户ID是UUID，用户服务里用户ID是自增整数，日志服务里用户ID又是手机号。三个服务的数据对不上，你根本没法做关联分析。

及时性

及时性很多人容易忽略。数据再准再全，如果来得太晚，也等于没用。

我之前做过一个风控系统，要求交易发生后100毫秒内完成风险判断。结果数据从API到消息队列再到计算引擎，一路延迟了2秒。等风控结果出来，钱早就转走了。这就是及时性没达标。

唯一性

唯一性就是不能有重复。听起来简单，做起来难。

我见过最离谱的案例：一个电商平台，用户下单时因为前端按钮没做防抖，用户点了两次，结果生成了两笔一模一样的订单。好在API层有幂等校验，否则财务对账的时候得疯。

有效性

有效性是格式和规则的合规性。比如手机号必须是11位数字，邮箱必须包含@符号，状态码必须在枚举范围内。

嗯，这里要注意：有效性校验最好在API入口就做，不要等到数据落库了才发现格式不对。那样不仅浪费存储，还污染数据。

数据质量在微服务架构中的重要性

微服务架构下，数据质量的重要性被放大了好几倍。为什么？

因为数据在服务之间频繁流转。一个服务输出的脏数据，会像病毒一样传染给所有下游服务。而且，微服务架构下数据源分散，问题定位比单体架构难得多。

微服务架构对数据质量提出了三个新要求：

• 契约化：服务间接口必须有明确的数据契约，包括字段类型、取值范围、是否必填等
• 自动化：数据质量检查不能靠人工，必须嵌入CI/CD流水线
• 可追溯：每条数据从哪来、经过哪些服务、被谁修改过，都要能查清楚

说白了，在微服务架构里，数据质量不是锦上添花，而是生存底线。没有数据质量，微服务就是一堆互相甩锅的孤岛。

下面这张图，是我自己总结的数据质量在微服务架构中的核心逻辑：

从这张图能看出来，API层是数据质量的第一道防线，也是最后一道防线。数据源再乱，只要API层把校验做好，下游服务就能拿到干净数据。反过来，如果API层放水，那整个微服务体系都会被污染。