数据质量与分析验证：两道门守住不同的风险

Tue, 13 Oct 2026 00:00:00 +0000

一张表没有空值、没有重复，分析就能放心发吗？

未必。数据全对，也可能算错；算得对，也可能比较错了，或者把相关性写成了因果。这三类失败发生在不同的环节，需要用不同的检查去拦。

Data Analytics Skills 把它们分成两个 Skill：Analyze Data Quality 检查数据，Validate Data 检查分析。两道门分别守住不同的风险，缺任何一道都会漏。

先问数据适不适合这次用途

Analyze Data Quality 的起点不是数据本身，而是用途和粒度：一行是用户、订单、订单明细，还是事件？

这个问题决定了后面所有检查是否有意义。订单号重复，不一定是脏数据，也可能是合法的明细行。如果粒度判断错了，去重反而会删掉有效记录，把一个正确的数据源变成错误的分析输入。

原文要求先确认：数据集代表什么、预期粒度、主键或候选键、重要日期列、时区假设、领域规则、允许取值和业务阈值。缺失的上下文应当谨慎推断并标注为假设，而不是默默补齐。

确认粒度之后，再选择高价值检查。原文给出的默认覆盖面是完整性、唯一性、有效性、一致性、完整性约束、时效性、体量与形态。

它也按数据形态给出不同的重点：

数据形态	典型检查
事件数据	重复事件 ID、未来时间戳、会话或用户覆盖缺口、发布后事件结构突变
维度表	非唯一业务键、孤儿代理键、状态变化缺少时间戳、参考值异常流失
事实表	混合粒度、不可能的量值（负收入）、Join 膨胀、迟到或部分加载的分区
特征与评分表	结果字段泄漏、特征稀疏度突增、模型变更后的分布漂移、标签漂移
实验数据	重复分流、分组不均衡、有曝光无分流、分流时间戳之前的事件

一条重要的方法论：比较比例，而不只是计数。1,000 条空值在一个亿级表里和在十万级表里，意义完全不同。同时按时间、来源、国家、平台、模型版本等维度分组，才能区分真实问题和预期波动。

“发现空值”只是检查结果，不是质量报告。

更有用的写法是：哪些日期、来源和人群受影响；会不会改变分母；会不会造成关联丢行；会不会让看板滞后。原文要求把每项发现与下游风险绑定：破坏可信分析、造成有偏决策、打断 Join、让看板过期、让实验失效、让模型特征不可靠，或者让细分结论失真。

每项发现应带证据、风险、严重度、置信度和最小修复建议，并保留 SQL 或 Notebook。原文对自动化的态度是克制的：稳定规则适合做成自动化测试，波动较大的指标不宜套死阈值。

粒度之外，还有一类问题最容易被漏掉：时间维度上的完整性。

当用户说“从某天开始”“突然”“最近才出现”时，原文要求优先做时间诊断：首次出现日期、最后出现日期、每日或每周的空值率趋势、重复率趋势、行数趋势、类别份额变化、分布漂移，以及发布、迁移、事故、模型变更和回填前后的变化点。

这类检查之所以重要，是因为很多“业务变化”其实是采集或管道变化。把它们当成业务问题去解释，会浪费大量时间，还会得出错误结论。

Validate Data 的对象是分析、图表、报告和建议——不是数据表。

它先提取关键主张：主要问题、受众、决定、头条数字、数据来源、时间窗口、人群、过滤、比较基线和已声明的限制。然后核对方法：人群、资格规则、排除项、抽样、指标定义、公式、单位、分母、时区、队列、比较期和基线，是否与这个决定匹配。

原文特别点出几类隐藏问题：隐藏的排除项、不一致的定义、部分周期比较，以及缺少实验或可靠因果证据的因果措辞。

Validate Data 要求独立重算影响最大的数字，检查粒度、小计、分母、非零分母、比率基数、环比基数、加权平均、单位、币种、时区处理，以及互斥类别是否加总到总数。

对 SQL，还要检查 Join 类型、Group By 粒度、过滤、去重计数，以及 Join 前后的行数变化。

教学示例：A 渠道 9 次转化、10 次访问，转化率 90%；B 渠道 50 次转化、100 次访问，转化率 50%。两组率直接平均是 70%，但整体应为 59 ÷ 110 ≈ 53.6%。记录没错，平均方式错了。