2、数据质量维度详解：完整性、准确性、一致性、及时性、唯一性、有效性
聊数据质量，绕不开这六个维度。很多刚入行的朋友喜欢背定义，但说实话，背得再熟，到了实际项目里照样踩坑。我做了这么多年数据治理，最深的体会是——这六个维度不是理论框架，而是六把手术刀。你得知道什么时候用哪一把，怎么切，切多深。
下面我一个个拆开讲。每个维度我都会说清楚：它到底在衡量什么？我在项目中踩过哪些坑？以及怎么落地？
2.1 完整性：数据有没有缺胳膊少腿？
完整性衡量的是数据缺失的程度。说白了，就是该有的字段有没有？该有的记录有没有？
我记得刚带团队时，有个同事跑过来跟我说："老大，用户表完整性100%，一个空值都没有。"我一看，好家伙，整张表就三个字段，user_id、user_name、phone，全填满了。但问题是，这个表应该还有email、address、register_time，当初建表时就没建这些字段。这叫什么完整性？这叫掩耳盗铃。
完整性要分两层看：
- 表结构完整性：该有的字段有没有？字段类型对不对？
- 记录完整性：该有的数据有没有？关键字段是否为空？
我在一个电商项目中遇到过真实案例。订单表的"收货地址"字段，业务上要求必填，但数据库设计时没加NOT NULL约束。结果呢？有3%的订单地址为空，导致物流系统无法发货。排查下来，是前端页面改版时漏掉了地址校验。
2.2 准确性：数据是不是对的？
完整性解决了"有没有"的问题，准确性解决的是"对不对"的问题。
你想想看，数据是完整的，但全是错的，那比没有数据更可怕。没有数据你至少知道自己不知道，错误数据会让你做出错误决策。
准确性监控，我一般分三个层次：
- 字段级准确性：单个字段的值是否在合理范围内？比如年龄不能超过150，订单金额不能为负数。
- 记录级准确性：同一记录内字段间逻辑是否自洽？比如"下单时间"必须早于"支付时间"。
- 统计级准确性：汇总数据是否合理？比如日订单量突然暴涨1000%，大概率是数据重复或计算逻辑出问题了。
我曾经帮一家金融公司做数据治理。他们的交易金额字段，有个别记录存的是科学计数法（比如1.23E+5），ETL解析时直接变成了123.0，少了两个数量级。要不是我习惯性地跑了一个"金额分布检查"，这个bug可能要等到月底对账才能发现。
2.3 一致性：不同地方的数据能不能对上？
一致性，说白了就是同一个东西，在不同系统、不同表、不同时间点，值是不是一样的。
举个例子。用户"张三"在CRM系统里叫"张三"，在订单系统里叫"张先生"，在财务系统里叫"Zhang San"。三个系统数据都是完整的，也都是"准确"的，但合在一起就是一团浆糊。这就是一致性问题。
一致性监控常见的场景：
| 场景 | 说明 | 监控方式 |
|---|---|---|
| 跨系统一致性 | 同一实体在不同系统中的值是否一致 | 定期对账，比对关键字段 |
| 跨表一致性 | 同一数据库内，关联表之间的外键关系是否成立 | 外键约束 + 定期扫描 |
| 时间一致性 | 同一指标在不同时间点的统计口径是否一致 | 口径文档 + 变更日志 |
| 格式一致性 | 同一字段在不同系统中的格式是否统一 | 元数据管理 + 格式校验 |
我记得有个项目，数据仓库的"用户活跃度"指标，业务部门说是按"7天内登录次数"算的，技术部门是按"7天内登录天数"算的。两边数据差了30%，吵了两个月才发现是口径不一致。从那以后，我要求所有核心指标必须在元数据系统里登记计算公式，变更必须走审批流程。
2.4 及时性：数据来得够不够快？
及时性衡量的是数据从产生到可用之间的时间差。
你想想看，一个实时风控系统，数据延迟5分钟，可能已经损失了几十万。一个日报，第二天下午才出，运营团队早就凭感觉做决策了。
及时性监控，我一般关注三个指标：
- 数据产生时间：业务系统中数据实际生成的时间戳。
- 数据到达时间：数据进入数据平台的时间戳。
- 数据可用时间：数据完成清洗、转换、加载，可供下游使用的时间戳。
这三个时间戳的差值，就是数据延迟。我习惯把延迟分为三个等级：
- 秒级延迟：实时场景（风控、推荐、监控大屏）
- 分钟级延迟：近实时场景（运营看板、实时报表）
- 小时/天级延迟：离线场景（日报、周报、月报）
我曾经遇到一个坑：某数据管道监控显示延迟只有5分钟，但业务方一直抱怨数据不准。排查后发现，数据源系统的时间戳是业务日期（比如2024-01-01），但数据实际产生时间是2024-01-02凌晨2点。也就是说，数据延迟了26个小时，但监控系统只看到了管道传输的5分钟。所以，及时性监控一定要从数据源开始算起，不能只看管道内部。
2.5 唯一性：数据有没有重复？
唯一性，顾名思义，就是同一实体在数据集中是否只出现一次。
重复数据的问题，比你想象的要严重得多。一个用户被重复计算，营销费用就多花一份；一笔订单被重复记录，财务报表就多一笔收入。我见过最夸张的案例，某公司的客户表，同一个客户因为录入时姓名多了个空格，被当成两个客户维护了三年。
唯一性监控的核心手段：
- 主键/唯一键约束：数据库层面的硬约束，从源头防止重复。
- 业务去重规则：有些重复不是简单的字段重复，而是业务含义重复。比如"张三"和"张先生"可能是同一个人，需要业务规则来判断。
- 定期重复扫描：对历史数据定期扫描，发现重复记录并合并。
2.6 有效性：数据符不符合规则？
有效性，也叫合规性，衡量的是数据是否符合预定义的格式、类型、取值范围等规则。
举个例子。手机号字段，存的是"13800138000"，这是有效的。存的是"1380013800a"或者"123456"，这就是无效的。虽然数据是完整的（不为空），也是"准确"的（确实是用户填的），但不符合业务规则，没法用。
有效性监控的常见规则：
| 规则类型 | 示例 | 监控方式 |
|---|---|---|
| 格式校验 | 邮箱必须包含@，手机号必须11位数字 | 正则表达式 |
| 取值范围校验 | 年龄0-150，金额≥0 | 边界值检查 |
| 枚举值校验 | 性别只能是男/女/未知 | 值域检查 |
| 业务规则校验 | 折扣率不能超过50% | 业务逻辑脚本 |
我记得有个项目，数据仓库里的"订单状态"字段，业务上只有5种状态（待支付、已支付、已发货、已完成、已取消），但实际数据里出现了"已退款"这个状态。排查下来，是业务系统升级时新增了状态，但数据仓库的映射规则没更新。这就是典型的有效性监控缺失。
2.7 六个维度的协同监控
讲完六个维度，你可能会问：实际项目中，怎么把这六个维度串起来？
我的做法是分层监控 + 交叉验证。
举个例子，一条订单数据进入数据平台：
- 第一层（完整性）：检查所有必填字段是否都有值。
- 第二层（有效性）：检查字段格式和取值范围是否正确。
- 第三层（唯一性）：检查这条订单是否已经存在。
- 第四层（准确性）：检查字段间的逻辑关系是否自洽。
- 第五层（一致性）：检查这条数据与其他系统的数据是否一致。
- 第六层（及时性）：检查数据从产生到入库的时间是否在SLA范围内。
这六层不是串行的，而是并行监控 + 逐级告警。每一层发现问题，都记录到数据质量日志中，并根据严重程度触发不同的告警策略。
好了，六个维度就讲到这里。记住，这些维度不是孤立的技术指标，而是你与业务方沟通的共同语言。下次业务方说"数据不准"时，你可以追问一句："你说的不准，是完整性、准确性、一致性、及时性、唯一性、有效性中的哪一个？"——相信我，这一问，就能把模糊的问题变成可执行的任务。