1. 数据质量概述：什么是数据质量、数据质量的重要性、数据质量维度
大家好，我是老张。做数据这行十几年了，踩过的坑比走过的路还多。今天咱们聊聊数据质量——这个听起来基础、但真正做好的团队少之又少的话题。
说实话，我刚入行那会儿，觉得数据质量就是个“锦上添花”的事。数据能跑通、报表能出来，不就完了吗？直到有一次，因为一个字段的空值率没控制好，导致整个用户画像模型跑偏，业务方拿着错误的数据做了大促预算……嗯，那次之后，我再也不敢小看数据质量了。
1.1 什么是数据质量？
数据质量，说白了就是数据“靠谱不靠谱”。它衡量的是数据在多大程度上能满足使用需求。
你想想看，如果一份数据告诉你“昨天销售额100万”，但实际只有80万，那这份数据就是有问题的。数据质量不是绝对的“对与错”，而是相对的“够不够用”。
核心定义：数据质量 = 数据满足特定业务场景使用要求的程度。
举个例子：电商的订单数据，对财务来说必须精确到分；但对运营做趋势分析，精确到元就够了。同一个数据，在不同场景下，质量要求是不一样的。
1.2 数据质量的重要性
我经常跟团队说一句话：“垃圾进，垃圾出”。数据质量不好，后面所有的分析、模型、决策都是空中楼阁。
具体来说，数据质量差会带来哪些问题？我列几个亲身经历过的：
- 决策失误：我曾经接手过一个项目，业务方根据一份有重复记录的用户数据做了营销活动，结果同一个用户收到了3次优惠券，白白浪费了预算。
- 成本浪费：数据清洗、修复、重跑ETL，这些都是在烧钱。我见过一个团队，每个月花40%的时间在修数据上，真正做分析的时间少得可怜。
- 信任崩塌：这是最可怕的。一旦业务方发现数据不准，他们就不再信任数据团队。我有个朋友的公司，因为连续出了几次数据事故，业务方直接自己拉Excel表做分析了——数据团队彻底被边缘化。
- 合规风险：金融、医疗行业尤其敏感。数据不完整或不准确，可能导致监管处罚。
我的经验：数据质量不是“一次性”搞定的。它需要持续监控、持续改进。我建议每个团队在数据仓库建成的那一刻，就要同步建立数据质量监控体系。别等出了问题再补，那时候成本至少翻3倍。
1.3 数据质量五大维度
做数据质量监控，不能眉毛胡子一把抓。业界公认的五大维度，我一个个说。
1.3.1 准确性
准确性，就是数据“对不对”。比如用户年龄字段，填的是“150岁”，这明显不对。
我在项目中遇到过最典型的场景：某电商平台的订单金额字段，因为上游系统的一个bug，导致部分订单金额被乘以了100倍。要不是我们做了准确性校验（跟支付系统的对账），这个错误可能要到月底结算才能发现。
常见监控手段：
- 字段值域校验（年龄0-120，金额非负）
- 跨系统对账（订单系统 vs 支付系统）
- 统计分布异常检测（均值、标准差突变）
1.3.2 完整性
完整性，就是数据“全不全”。关键字段不能为空，记录不能缺失。
我曾经遇到过一个坑：某数据管道因为网络抖动，丢失了凌晨2点到3点的所有日志数据。第二天早上看报表，发现那个小时的用户活跃度是0——这明显不对。幸好我们做了完整性监控，及时发现了数据缺口，重新补跑了数据。
注意：完整性不是要求所有字段都非空。有些字段本来就是可选的。关键是要识别出“业务必须字段”。比如订单表的“订单ID”、“用户ID”、“金额”这三个字段，绝对不能为空。
常见监控手段：
- 必填字段空值率检查
- 数据量波动监控（跟历史同期对比）
- 时间序列连续性检查
1.3.3 一致性
一致性，就是数据“统不统一”。同一个业务含义，在不同系统里应该保持一致。
举个例子：用户状态字段，在CRM系统里叫“status”，取值是“active/inactive”；在订单系统里叫“user_state”，取值是“1/0”。如果不做映射和校验，这两个系统对同一个用户的描述可能完全相反。
我建议：建立统一的元数据字典，所有系统都按这个标准来。做不到统一？那就做好映射关系，并定期校验。
常见监控手段：
- 跨系统字段值一致性校验
- 枚举值域一致性检查
- 数据格式一致性检查（日期格式、编码格式等）
1.3.4 及时性
及时性，就是数据“快不快”。数据产生到可用，这个时间差能不能满足业务需求。
我记得有个实时风控项目，要求数据延迟不超过5秒。结果因为Kafka消费端处理不过来，延迟飙到了30秒。等风控模型跑出来，用户都已经完成交易了——这个监控就失去了意义。
及时性没有绝对标准，完全看业务场景：
| 业务场景 | 可接受延迟 | 监控指标 |
|---|---|---|
| 实时风控 | < 5秒 | 端到端延迟 |
| 实时大屏 | < 1分钟 | 数据新鲜度 |
| T+1报表 | < 8小时 | 任务完成时间 |
| 离线分析 | < 24小时 | 数据产出时间 |
1.3.5 唯一性
唯一性，就是数据“重不重”。同一个实体，在数据集中只能出现一次。
这是最容易出问题的一个维度。我见过最夸张的情况：一个用户表里，同一个用户ID出现了17次。原因是上游系统在更新用户信息时，没有做幂等处理，每次更新都插入了一条新记录。
唯一性问题会导致什么后果？聚合计算翻倍、用户画像失真、营销成本虚高……
常见监控手段：
- 主键唯一性校验
- 业务主键重复率监控
- 去重前后数据量对比
1.4 知识体系总览
说了这么多，我画了一张图，把数据质量的核心知识串起来。你看完应该能有个整体印象。
1.5 小结
数据质量这件事，说难不难，说简单也不简单。核心就一句话：把数据当产品来做。
你想想看，一个产品上线前要做测试、上线后要监控、出问题要修复。数据也是一样的。别等到业务方投诉了才去修，那时候已经晚了。
我个人习惯是：在数据接入的第一天，就把质量监控规则定好。哪怕一开始规则简单点，也比没有强。后面再逐步完善，总比亡羊补牢好。
给新手的建议：如果你刚开始做数据质量，别想着一步到位。先抓住最核心的维度——准确性和完整性。这两个维度搞定了，80%的问题就解决了。剩下的20%，慢慢来。
公众号:蓝海资料掘金营，微信deep3321