数据质量六大维度：从理论到实战
聊数据质量，绕不开这六个维度。完整性、准确性、一致性、及时性、唯一性、有效性。说白了，它们就是衡量数据「好不好」的六把尺子。
我在做数据架构的这些年，见过太多团队一上来就搞复杂规则引擎，结果连最基本的完整性都没守住。嗯，咱们今天就把这六个维度掰开揉碎，结合Lakehouse的场景，讲讲怎么落地。
核心观点：六个维度不是孤立存在的。一个字段可能同时违反完整性和准确性。监控时要有优先级，先保完整性，再谈准确性。
1. 完整性：数据有没有「缺胳膊少腿」
完整性是最基础的维度。它问的是：该有的数据有没有？
举个例子，用户表中「手机号」字段是必填的。如果某条记录的手机号是NULL，那就是完整性违规。
我在项目中遇到过最典型的场景：某电商平台的订单表，每天有3%的订单缺少「收货地址」。数据分析团队基于这个数据做区域销售报告，结果偏差巨大。后来一查，是前端页面在弱网环境下跳过了地址填写步骤。
我的习惯：在Lakehouse里，我会用Delta Lake的NOT NULL约束来强制完整性。但要注意，这只能拦截写入时的空值。对于历史数据中的空值，需要跑批量的完整性扫描任务。
完整性监控的常见指标：
- 字段空值率：NULL值占比，超过阈值报警
- 记录缺失率：比如上游表本该有1000条，实际只有980条
- 引用完整性：外键关联是否存在孤儿记录
2. 准确性：数据是不是「对的」
完整性只保证数据存在，但不保证数据正确。准确性就是干这个的。
你想想看，用户年龄填的是「-5岁」，这数据完整吗？完整。准确吗？显然不。
我曾经帮一家金融客户做数据治理。他们的交易表中有一笔金额是9,999,999,999.00元。完整性检查通过了，但明显不合理——这家公司日均交易额才200万。后来发现是某个批处理脚本的数值溢出导致的。
避坑指南：准确性监控不能只靠简单的范围校验。我曾经见过一个系统，只检查金额是否大于0，结果负数金额全被放过。要结合业务语义设计校验规则。
准确性监控的常用手段：
- 业务规则校验：年龄0-120岁，金额不超过单日交易上限
- 统计分布检测：均值、标准差突变可能意味着数据异常
- 交叉验证：用两个独立数据源互相核对
3. 一致性：数据之间「打架」了吗
一致性关注的是：同一份数据在不同地方是不是对得上。
典型的场景：CRM系统里客户叫「张三」，但数据仓库里同一个客户叫「张3」。这就是不一致。
在Lakehouse架构中，一致性尤其重要。因为数据会从多个源头流入，经过多层ETL，最终服务于不同业务。任何一个环节的转换逻辑不一致，都会导致数据「打架」。
| 不一致类型 | 示例 | Lakehouse中的应对 |
|---|---|---|
| 命名不一致 | 同一字段在A表叫user_id，在B表叫uid | 建立统一的数据字典，用Spark做字段映射校验 |
| 格式不一致 | 日期格式：2024-01-01 vs 01/01/2024 | 在Bronze层统一标准化 |
| 逻辑不一致 | 订单状态：A系统用0/1，B系统用pending/completed | 定义枚举映射表，用Delta Lake的CHECK约束 |
| 汇总不一致 | 明细表求和与汇总表对不上 | 定期跑对账任务，用Spark SQL做聚合比对 |
个人经验：一致性监控最容易出问题的地方是跨系统数据同步。我建议在Silver层做一次「一致性快照」，把来自不同源的数据做一次全量比对，记录差异明细。
4. 及时性：数据「迟到」了吗
及时性衡量的是：数据从产生到可用，花了多长时间。
为什么重要？你想想看，一个实时风控系统，如果数据延迟了10分钟，那笔欺诈交易可能已经完成了。
在Lakehouse场景下，及时性通常用SLA来定义。比如：「订单数据必须在事件发生后5分钟内入湖」。监控就是检查这个SLA的达标率。
我记得有一次，某个批处理任务因为资源竞争，从原来的30分钟跑完变成了2小时。下游的实时报表全部延迟。后来我们在监控里加了「数据新鲜度」指标，一旦某个分区的数据超过预定时间未更新，立刻告警。
我的建议：及时性监控要分层次。对于流式数据，监控每条记录的延迟；对于批处理，监控分区数据的写入时间戳。在Delta Lake里，可以用DESCRIBE HISTORY查看每次写入的时间。
及时性监控的关键指标：
- 数据延迟：事件时间 vs 处理时间
- SLA达标率：按时完成的数据批次占比
- 最大延迟：最晚的那条数据迟到了多久
5. 唯一性：数据「重复」了吗
唯一性很简单：同一份数据不应该出现两条一模一样的记录。
但实际中，重复数据太常见了。用户重复注册、订单重复提交、日志重复采集……
我曾经处理过一个案例：某广告平台的点击日志，因为Kafka重试机制，导致约0.5%的点击记录重复。这0.5%的重复，让广告主多付了几十万的投放费用。
避坑指南：唯一性监控不能只依赖数据库的主键约束。很多重复数据是在ETL过程中产生的，比如多次读取同一文件。我建议在数据入湖时，用Delta Lake的MERGE操作做去重，同时记录重复率指标。
唯一性监控的常见方法：
- 主键重复检测：检查业务主键是否有重复值
- 指纹去重：对关键字段做MD5，检查哈希值是否重复
- 滑动窗口去重：在时间窗口内检查是否有相似记录
6. 有效性：数据「合规」吗
有效性是最后一个维度，也是最容易被忽略的。它问的是：数据是否符合业务定义的格式和取值范围。
举个例子，性别字段只能填「男」或「女」，如果填了「其他」，完整性没问题，准确性也说得通，但有效性违规了——因为业务规则只允许这两个值。
有效性监控通常依赖枚举值和正则表达式。比如：
- 邮箱格式必须包含@和域名
- 手机号必须是11位数字
- 状态码必须在预定义的枚举列表中
实战要点：有效性规则要跟业务方一起定义。我见过一个项目，技术团队自己定义了「性别」的有效值集合，结果漏掉了业务方后来新增的「未知」选项，导致大量数据被标记为无效。
在Lakehouse中，有效性监控可以借助Delta Lake的CHECK约束来实现：
-- 在Delta表上添加有效性约束
ALTER TABLE orders
ADD CONSTRAINT valid_status
CHECK (status IN ('pending', 'processing', 'shipped', 'delivered', 'cancelled'));
-- 查看所有约束
SHOW TBLPROPERTIES orders ('delta.constraints');这六个维度，每个都有它的侧重点。但在实际项目中，它们往往是交织在一起的。一条数据可能同时违反多个维度。我的建议是：先搭好完整性的底线，再逐步完善其他维度的监控。别想一口吃成胖子。