一、数据质量概述
大家好，我是老张。做数据这行十几年了，踩过的坑比走过的路还多。今天咱们聊聊数据质量——这个听起来基础、但真正做好的人不多的领域。
数据质量是什么？说白了，就是数据能不能用、好不好用。我见过太多项目，数据量堆得跟山一样，结果一跑报表全是错的。嗯，那种感觉，就像你花大价钱买了块名表，结果发现它走时不准——还不如一块电子表实在。
1.1 什么是数据质量
数据质量，指的是数据满足业务需求的程度。它不是一个非黑即白的概念，而是一个相对值。同样的数据，在A场景下是高质量的，在B场景下可能就是垃圾。
举个例子。我曾在某电商平台做数据治理，他们的用户地址数据，对物流部门来说质量很高——精确到门牌号。但对市场部来说，这些数据质量就很差——因为很多用户填的是公司地址，根本看不出居住区域。你看，同一个数据，不同视角，评价完全不同。
核心观点：数据质量不是的，而是相对于使用场景的。脱离业务场景谈数据质量，就是耍流氓。
1.2 数据质量的重要性
数据质量差，后果有多严重？我给大家说几个真实案例。
- 决策失误：某零售企业因为库存数据不准，多采购了30%的货，最后只能打折清仓，损失上千万。
- 合规风险：某银行因为客户身份信息不完整，被监管罚款500万。说白了，数据质量就是钱。
- 效率低下：我见过一个团队，70%的时间花在清洗数据上，只有30%的时间在做真正的分析。这合理吗？
- 信任崩塌：数据不准，业务部门就不信你。一旦信任没了，数据团队的价值就归零了。
为什么会这样？因为数据质量是数据价值的基石。你想想看，如果地基是歪的，上面盖再高的楼也是危房。
| 数据质量问题 | 业务影响 | 我见过的真实案例 |
|---|---|---|
| 数据缺失 | 分析结果偏差 | 某保险公司理赔分析，30%的保单缺少赔付金额字段 |
| 数据重复 | 统计失真 | 某CRM系统，同一个客户被录入了5次 |
| 数据错误 | 决策误导 | 某工厂传感器数据漂移，导致产线误停机 |
| 数据延迟 | 错过时机 | 某风控系统，数据延迟2小时，欺诈交易已经完成 |
避坑指南：我曾经接手过一个项目，业务方说"数据质量没问题"，结果一检查，30%的字段是空的。记住：不要相信任何未经校验的数据质量声明。信任，但要验证。
1.3 数据质量六大维度
数据质量怎么衡量？业界公认的框架是六大维度。我习惯把它们分成两组：前三项是"数据本身的质量"，后三项是"数据使用的质量"。
下面这张图，是我在多个项目中反复使用的框架，建议大家收藏。
1.3.1 准确性
准确性，就是数据反映真实世界的程度。这是最基础、也最容易被忽视的维度。
我遇到过最离谱的事：某系统里用户年龄字段，居然有300岁的记录。你说这数据准不准？显然不准。但更可怕的是，这种明显错误的数据，居然在系统里躺了两年没人发现。
实战技巧：准确性校验，我习惯用"三明治法则"——先做格式校验（比如年龄必须是数字），再做范围校验（比如年龄0-150），最后做业务逻辑校验（比如出生日期早于入职日期）。三层过滤，基本能挡住90%的错误。
1.3.2 完整性
完整性，说白了就是数据缺不缺胳膊少腿。一个客户记录，如果手机号是空的，那这个记录对营销部门来说就是废的。
完整性有两个层面：
- 字段完整性：某个字段是否有空值。比如订单表中的收货地址，不能为空。
- 记录完整性：一条记录是否包含了所有必要字段。比如一条交易记录，必须同时有交易时间、金额、双方账号。
我记得有个项目，业务方说"我们的数据很完整"。我随手抽了1000条记录，结果发现23%的邮箱字段是空的。嗯，从那以后，我再也不信"很完整"这种话了。
1.3.3 一致性
一致性，就是不同地方的数据能不能对得上。这是数据治理中最头疼的问题之一。
举个例子。同一个客户，CRM系统里叫"张三"，订单系统里叫"张先生"，财务系统里叫"Zhang San"。你说这是同一个人吗？大概率是。但系统不认啊，它觉得这是三个不同的客户。
为什么会这样？因为不同系统对同一事物的定义不同。我见过最夸张的案例：同一个"订单状态"，在三个系统里有五种不同的枚举值。你说这数据怎么用？
避坑指南：我曾经因为没做一致性校验，导致月报数据差了2000万。后来查出来，是数据仓库和业务系统的"活跃用户"定义差了24小时。从那以后，我定了一条铁律：跨系统数据必须先做一致性校验，再谈分析。
1.3.4 及时性
及时性，就是数据能不能在需要的时候出现。数据再准，如果来晚了，也是废的。
我做过一个实时风控项目，要求数据延迟不超过5秒。结果上游系统经常延迟10分钟。你想想看，10分钟，够黑客转走多少钱了？
及时性不是越快越好，而是"刚刚好"。不同场景对及时性的要求不同：
- 实时风控：秒级
- 运营报表：小时级
- 战略分析：天级甚至周级
1.3.5 唯一性
唯一性，就是数据有没有重复。这个维度看起来简单，做起来特别难。
我见过一个CRM系统，同一个客户被录入了7次。为什么？因为每次客户打电话来，客服都以为是新客户，就新建一条记录。结果这个客户在系统里有7个ID，7个不同的联系方式，7个不同的地址。
唯一性校验的核心是"去重"。但去重不是简单的"字段相等"，而是"业务上是否代表同一个实体"。这需要设计合理的匹配规则。
1.3.6 有效性
有效性，就是数据是否符合业务规则。这个维度经常和准确性搞混，其实不一样。
准确性是"数据对不对"，有效性是"数据能不能用"。举个例子：
- 手机号"13800138000"——这个号码是准确的（真实存在）
- 但如果你只做中国大陆业务，这个号码是有效的（符合11位、13开头等规则）
- 如果业务规则要求必须是"139"开头的VIP客户，那这个号码就无效了
你看，同一个数据，在不同业务规则下，有效性完全不同。
| 维度 | 核心问题 | 校验方法 | 我常用的工具 |
|---|---|---|---|
| 准确性 | 数据对吗？ | 交叉验证、源系统比对 | Great Expectations |
| 完整性 | 数据全吗？ | 空值检查、字段覆盖率统计 | SQL COUNT + CASE WHEN |
| 一致性 | 数据矛盾吗？ | 跨系统比对、枚举值校验 | dbt test |
| 及时性 | 数据及时吗？ | 时间戳监控、SLA告警 | Prometheus + Alertmanager |
| 唯一性 | 数据重复吗？ | 主键校验、去重规则 | Dedupe 库 |
| 有效性 | 数据合规吗？ | 业务规则引擎、正则校验 | 自定义规则脚本 |
核心观点：六大维度不是孤立的，它们相互影响。比如，数据不完整（完整性差）可能导致去重失败（唯一性差），进而影响统计准确性（准确性差）。所以，数据质量治理要系统性地考虑，不能头痛医头、脚痛医脚。
好了，这一章的内容就到这里。数据质量的概念和六大维度，是后续所有校验体系搭建的基础。我个人建议，你可以先拿自己手头的一个数据集，用这六个维度做个快速评估，看看哪个维度问题最多。相信我，结果可能会让你大吃一惊。