数据质量维度详解：你的数据到底“好不好”

做数据质量，先得搞清楚我们到底在衡量什么。很多人一上来就写代码、跑校验规则，结果查出一堆问题，却不知道怎么分级、怎么推动整改。

我个人习惯，先把六个核心维度记熟。这六条就像体检指标——哪个超标都不好使。

维度	一句话定义	我关心的核心问题
完整性	数据有没有缺胳膊少腿	该有的字段、记录、值是不是全的
准确性	数据和真实世界一致吗	值本身对不对，而不是“有没有”
一致性	跨系统跨表能不能对上	同一个业务概念，各方口径是否统一
及时性	数据更新够不够快	从业务发生到数据就绪，延迟在不在容忍范围内
唯一性	有没有重复的怪东西	每条实体是否只出现一次
有效性	数据格式和规则对不对	值是否在合法范围内，类型是否合规

完整性：数据“缺胳膊少腿”有多严重

完整性，说白了就是该有的不能少。我在项目中遇到过最典型的场景：上游系统的订单表，每天少传几百条记录，结果下游的GMV报表连续三天对不上。

完整性问题分两类：

• 记录级缺失：少行。比如某渠道的日志丢失了半个小时的数据。
• 字段级缺失：少列。比如手机号字段有30%的NULL。

你想想看，如果用户表里的邮箱字段全是NULL，那你的营销系统永远发不了邮件。这不仅仅是数据问题，是业务能力直接打折。

-- 一个简单的完整性检查SQL
SELECT 
    COUNT(*) AS 总行数,
    COUNT(email) AS 有邮箱的行数,
    (COUNT(*) - COUNT(email)) * 100.0 / COUNT(*) AS 邮箱缺失率
FROM users
WHERE dt = '2024-06-01';

准确性：数据“对”还是“不对”

完整性查“有没有”，准确性查“对不对”。这个维度最容易让人踩坑。

举个例子：用户年龄字段，值都是整数，完整性也没问题。但大量用户年龄“180岁”——数据是完整的，但准确吗？不准确。

我以前对接过一家供应商，他们提供的交易金额字段，NULL率只有0.01%，看着挺漂亮。但我抽检发现，其中约5%的金额写反了正负号。退款记录记成了正向收入。这就是准确性灾难。

准确性检查，我主要靠这几招：

• 字段级：阈值检查（年龄0-120）、值域检查（金额>=0）
• 跨表级：汇总对账（SUM求和对比上下游）
• 样本抽检：随机抽100条人工核对

一致性：同一套数据，口径要对齐

一致性，你想想看——同一个“当日活跃用户”，业务系统算出来是100万，数据仓库算出来变成120万，你信谁？

这类问题我见得多了。核心原因就两个：

1. 口径定义不同：有的按登录算，有的按订单算，口径天然不统一。
2. 编码标准不同：A系统的“性别-男=1”，B系统的“性别-男=M”，映射不对就出鬼。

我最头疼的一次，是财务和业务两个部门对“净销售额”的定义差了整整一条会计科目。项目组来回扯皮两周，最后是负责人拍板统一了标准。

-- 一致性检查示例：不同来源的订单状态编码映射
-- 源系统A：0=新建, 1=已支付, 2=已取消
-- 源系统B：N=新建, P=已支付, C=已取消

SELECT 
    a.order_id,
    CASE 
        WHEN a.status = '0' AND b.status = 'N' THEN '一致'
        WHEN a.status = '1' AND b.status = 'P' THEN '一致'
        WHEN a.status = '2' AND b.status = 'C' THEN '一致'
        ELSE '不一致'
    END AS 状态一致性
FROM orders_a a
JOIN orders_b b ON a.order_id = b.order_id;

及时性：数据“迟到”了没

这个维度很多人会忽略，但业务方最敏感。实时报表跑不出来，运营找上门，你就知道什么叫“数据时效性灾难”。

及时性我分两个层次看：

• 近实时场景：秒级～分钟级延迟。比如交易风控、实时大屏。延迟超过30秒就算事故。
• 离线场景：T+1或T+2延迟。比如昨日的报表今天中午还没出，业务就会不爽。

我之前负责过一个实时数仓项目，Kafka到Druid的链路延迟一度达到10分钟。查了一圈，是数据源端批量刷数据，没按流式走。我跟他们磨了三天才改成逐条投递。

-- 检查数据延迟的日志示例
-- 一般我们会记录 data_produce_time 和 data_receive_time
-- 然后计算时间差（单位：秒）

日志行示例：
2024-06-01 14:23:00 [INFO] 表ods_order延迟检查: 最大延迟=452秒, 阈值=300秒, 状态=告警

唯一性：别让数据“重复”了

唯一性，说白了就是一条记录只能有一条。重复数据不仅浪费存储，更致命的是造成结果失真。

我见过最离谱的案子：用户画像系统里，同一个人出现了7次。因为ETL按不同时间戳入库，去重逻辑写漏了。最后推荐系统给这个用户发了7封一模一样的优惠券——被投诉了。

唯一性检查，我主要关注：

1. 主键唯一性：表的主键有没有重复？这个必须100%过。
2. 业务唯一性：比如一个订单号只能有一条核心记录，但关联记录可以有多条。

-- 唯一性检查SQL
SELECT 
    order_id,
    COUNT(*) AS 重复次数
FROM orders
WHERE dt = '2024-06-01'
GROUP BY order_id
HAVING COUNT(*) > 1;

有效性：数据“格式”合规吗

最后一个是有效性，有人也叫“合规性”。它检查的是数据是否符合预先定义的规则。

常见的有效性规则：

• 枚举值必须在合法列表内（比如性别只能是男、女、未知）
• 日期格式必须符合YYYY-MM-DD
• 数值不能为负数（业务不允许的情况下）
• 邮箱必须包含@符号

嗯，有效性跟准确性有点重叠，但侧重点不同。准确性关心“值对不对”，有效性关心“格式和规则对不对”。

我记得有个客户，他们的手机号字段，存进去的数据大部分格式都正确，但有大约2%的记录格式乱七八糟——有的带空格，有的加了“+86”前缀没标准化。这就是典型的有效性问题。

-- 有效性检查正则示例
-- 检查邮箱字段是否合法

SELECT 
    email,
    CASE 
        WHEN email ~ '^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$' 
        THEN '有效' 
        ELSE '无效' 
    END AS 有效性状态
FROM users
WHERE dt = '2024-06-01';

六维全景图：它们之间怎么配合作战

六条维度不是孤立的。比如：一条数据完整性检查通过，但有效性检查不通过；或者准确性通过，但及时性不达标。所以做数据质量，得先分维度，再定优先级。

下面这张图展示了我常用的维度分层逻辑：

我习惯按这个顺序排查问题：先看完整性，再看准确性和有效性，接着查一致性和唯一性，最后关注及时性。这样可以快速定位“数据到底烂在哪一层”。