一张表没有空值、没有重复，分析就能放心发吗？
未必。数据全对，也可能算错；算得对，也可能比较错了，或者把相关性写成了因果。这三类失败发生在不同的环节，需要用不同的检查去拦。
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%。记录没错，平均方式错了。
这个错误之所以常见，是因为每一行单独看都对。只有把汇总口径写下来，才能发现它。
图表也是被验证对象
原文把视觉呈现纳入验证范围：图表类型、尺度、坐标轴、区间、标题、标签、单位、排序、注释、颜色和精度。
要检查的是“快速浏览的读者会不会带走一个错误印象”，尤其是截断坐标轴、双轴、3D 效果、不一致的时间间隔、缺失的日期范围，以及夸大数据的标题。
对已经渲染的报告、看板、幻灯片、文档或 HTML，还要检查实际输出：图表是否破损、表格是否缺失、文字是否被裁切、格式是否错乱、是否残留占位内容。
验证结果决定怎么交付
原文给出三档结论：可分享、带限制说明分享、需要修正。
关键数字、分母、Join、时间窗口、人群、比较或结论存在实质不可靠时，应阻塞分享；小润色问题不必阻塞。未运行的检查、缺失来源、未完成的渲染步骤、未解决的数据质量风险、缺少负责人确认，应当作为交接阻塞项单独记录，而不是混进注意事项。
如果验证用了 SQL、Python、Notebook 或电子表格，应记录产物路径、查询链接或标签页，让检查可复现。
两道门的顺序
在实践中，两道门的顺序通常是：先质量，后验证。因为如果输入数据本身不可用，后续所有复算都只是在精确地计算错误。
但也有反向情况：当分析已经完成、结果可疑时，先做 Validate Data 的主张提取，往往能更快定位应该回头检查哪张表、哪个口径。
第一关证明数据适合这次用途，第二关证明分析支持这项决定。可信交付，需要两层证据。