2. 数据质量六大维度
聊数据质量，绕不开这六个维度。我做了这么多年数据治理，每次跟业务方吵架，最后都得回到这六个词上。说白了，它们是衡量数据好坏的六把尺子。
你想想看，如果连数据质量好坏的标准都没定清楚，那监控体系建得再漂亮也是空中楼阁。所以这一章，咱们把这六个维度的定义和业务含义彻底掰扯清楚。
核心观点：数据质量六大维度不是学术概念，是业务语言。每个维度背后都对应着真金白银的损失或风险。
1. 完整性
定义：数据记录是否齐全，关键字段是否有缺失。说白了，就是该有的数据有没有。
业务含义：完整性出问题，最直接的影响就是算不准。我记得有一次帮一家电商公司做数据治理，他们的订单表里「收货地址」字段缺失率高达15%。结果呢？双十一大促之后，有几千单因为地址不全发不了货，客服被打爆了。
完整性可以从两个层面看：
- 记录完整性：该有的行有没有少。比如每天应该导入100万条交易记录，实际只到了95万条。
- 字段完整性：该有的列有没有空。比如用户注册时「手机号」是必填项，但数据库里允许为空。
我的经验：完整性监控最好从源头做起。在数据接入层就设置非空校验，比事后补数省事十倍。我曾经帮一个团队在ETL入口加了完整性检查，数据质量问题减少了60%。
2. 准确性
定义：数据是否真实反映客观事实。数据值是否正确，精度是否达标。
业务含义：准确性是数据质量的命门。数据不准，分析结论就是错的，决策就是瞎蒙。
我遇到过最典型的案例：某银行的风控系统，因为客户「年收入」字段被错误地多录了一个零，系统把高风险客户判定成了低风险，直接放贷了200万。后来追查发现，是前端录入时格式校验没做好。
准确性常见问题：
- 数值错误：金额多一位少一位，小数点位置不对
- 单位错误：元写成万元，公斤写成斤
- 精度丢失：浮点数截断，四舍五入误差累积
- 引用错误：关联了错误的主表数据
避坑指南：我曾经见过一个团队，为了追求「数据完整」把缺失值全部填充为0。结果准确性一塌糊涂——「0」和「缺失」在业务上完全是两码事。千万别为了完整性牺牲准确性。
3. 一致性
定义：同一数据在不同系统、不同时间点、不同数据源之间是否保持一致，没有矛盾。
业务含义：一致性出问题，业务方会陷入「不知道该信谁」的困境。你想想看，CRM系统里客户叫「张三」，订单系统里同一个客户叫「张先生」，财务系统里叫「Zhang San」——这到底是不是同一个人？
我参与过一个大型零售集团的数据治理项目，他们的会员数据分散在6个系统中。同一个会员的积分，在不同系统里能差出三倍。最后搞了半年才把数据对齐，期间会员投诉率飙升了40%。
一致性检查要点：
| 检查类型 | 说明 | 典型场景 |
|---|---|---|
| 跨系统一致性 | 同一实体在不同系统中的数据一致 | CRM与ERP中的客户名称 |
| 时间一致性 | 历史数据与当前数据逻辑自洽 | 上月余额+本月流水=本月余额 |
| 格式一致性 | 同一字段的编码、格式统一 | 日期格式统一为YYYY-MM-DD |
| 逻辑一致性 | 数据间业务逻辑关系成立 | 订单金额=商品单价×数量 |
4. 及时性
定义：数据从产生到可被使用的时间延迟是否在可接受范围内。
业务含义：数据是有保质期的。过了时间窗口，再准确的数据也失去了价值。
举个例子：实时风控系统要求交易数据延迟不超过5秒。如果延迟到了30秒，骗子早就把钱转走了。我做过一个物流调度项目，车辆GPS数据延迟超过10分钟，调度系统给出的路线建议全是错的——车都已经开过那个路口了。
及时性指标：
- 数据延迟：从业务发生到数据入库的时间差
- 处理时效：ETL作业的执行时长
- 报表产出时间：日报、月报的生成时间是否满足业务要求
- 数据新鲜度：数据仓库中最晚更新的数据时间戳
我的建议：及时性标准一定要跟业务方一起定。别自己拍脑袋定个「1小时」，结果业务说「我们只要5分钟内的数据」。反过来，也别定得太严，增加不必要的技术成本。我一般会问业务方一个问题：「数据晚到多久，你会做出错误决策？」这个时间点就是及时性的底线。
5. 唯一性
定义：数据实体在数据集中是否被唯一标识，是否存在重复记录。
业务含义：唯一性出问题，最直接的结果就是「数不对」。同一个客户被统计了两次，同一个订单被算了两次金额，报表数据直接翻倍。
我印象最深的一次：某SaaS公司做用户活跃度分析，发现月活用户数突然暴涨了30%。老板高兴坏了，以为产品爆发了。结果一查，是数据管道出了bug，同一批用户被重复上报了三次。嗯，那个月白高兴一场。
唯一性常见问题：
- 主键重复：同一张表里出现了相同的主键值
- 业务实体重复：同一个客户在系统里存在多条记录
- 数据合并重复：多源数据合并时，同一实体未被去重
- ETL重复抽取：同一批数据被重复拉取多次
避坑指南：我曾经接手过一个项目，他们的「用户唯一标识」用的是手机号。结果一个用户换了手机号，系统里就多了一条新记录。后来我们改用「身份证号+手机号」组合键，才真正解决了唯一性问题。选主键一定要考虑业务场景，别想当然。
6. 有效性
定义：数据是否符合预定义的格式、范围、规则和业务约束。
业务含义：有效性是数据的「合规性」检查。数据格式不对、值域超限、违反业务规则，这些数据就是无效的，不能用于分析和决策。
有效性检查范围很广：
| 检查维度 | 规则示例 | 违规数据 |
|---|---|---|
| 格式校验 | 邮箱必须包含@符号 | "zhangsan"（缺少@） |
| 值域校验 | 年龄在0-150之间 | 年龄=200 |
| 枚举校验 | 性别只能是男/女/未知 | 性别="其他" |
| 长度校验 | 手机号11位 | 手机号="1380013800"（10位） |
| 业务规则 | 折扣率不能大于100% | 折扣率=150% |
我做过一个医疗数据项目，患者的「诊断日期」字段里居然有「1900-01-01」这种值。一看就是系统默认值没处理好。这种数据如果进了分析模型，所有时间相关的统计都会出问题。
注意：有效性规则不是越多越好。规则太严，会把一些「边缘但合理」的数据误杀。比如国际电话号码长度就不止11位。我一般建议：先做核心字段的强校验，其他字段先做告警，等积累足够经验后再逐步收紧。
六个维度怎么用？
讲完定义，说说实际怎么落地。我个人习惯把这六个维度分成三组：
- 基础组（完整+准确）：这是数据质量的底线。数据不全不准，其他都白搭。监控优先级最高。
- 关系组（一致+唯一）：多系统、多数据源场景下的核心问题。数据治理的硬骨头大多在这里。
- 时效组（及时+有效）：关注数据的「可用性」。数据再好，来得太晚或者格式不对，业务也用不上。
实际项目中，我建议先从「完整性」和「准确性」入手。把这两个维度监控起来，就能挡住80%的数据质量问题。然后再逐步扩展到其他维度。
一句话总结：数据质量六大维度，不是选择题，是必答题。每个维度都对应着具体的业务风险。监控体系建得好不好，就看你能不能把这六个维度都管起来。