数据质量与排错：缺失、重复、异常

前六讲教你把数据处理出来，这一讲教你在交出去之前先自己查一遍。顺带把「读懂报错日志」这件事讲透 – 会看日志的人才不需要别人帮忙。

20 分钟预计用时

3 类交付前必查

3 段报错日志怎么读

开始之前

这一讲接着第 6 讲往下做。前面几讲的节点这里都会用到，但用法不同 – 之前是拿它们处理数据，这一讲是拿它们检查数据。

翻三页看着都对，不等于数据没问题

节点全绿、字段齐全、抽样看几行也正常 – 然后你把表交出去了。两周后对方发现有两百多条记录的日期是 1900 年。

数据质量检查要解决的就是这件事：用固定的方法，把「看起来正常」变成「确认正常」。交付前查三样：缺失、重复、异常。

统计信息节点一次算完所有列：每列的缺失值个数、唯一值个数、最大最小值。不用一列一列翻，一张表就能看出哪几列有问题。

演示会自动播放。鼠标移上去暂停，点任意按钮转为手动，点右上角可以全屏投影。

看什么	发现什么
缺失值个数	哪几列不完整，缺得多不多
唯一值个数	唯一值等于行数 = 这列可以当 key；唯一值只有 1 = 这列全是同一个值，没用
最大 / 最小	数值列有没有负数、有没有大得离谱的；日期列有没有 1900 或 2099

缺失率决定处理方式。低于 5% 可以在流程里补或筛；超过 30% 就别在这里补了 – 那不是数据质量问题，是上游取数就错了，补多少都是错的。

建议把统计信息挂成一条支线：从主流程拉一条线接过去，不影响主流程往下走。一个节点的成本，换每月重跑时自动体检一次。

「有重复」是两件完全不同的事，处理方式也完全不同。

整行完全重复多半是导数据时重复导入了。没有信息量，直接去掉不会丢东西。

只有 key 重复同一台设备的多条登记记录。这是真实数据，删之前必须想清楚留哪一条。

按 key 去重之前必须先排序。不排序的话，「保留第一条」留下的是哪一条是不确定的 – 同一份数据跑两次可能得到不同结果，而且不报错。先按日期排序，再去重，这一对动作不能拆。

还有第三种做法：不删，只加一列标记。审计场景下这个更合适 – 你要能向别人证明你发现了重复并做了判断，而不是悄悄处理掉。行数不变，该删该留交给业务决定。

数量是 -2、原值是 0、日期是 1900 年 – 这些值本身都合法，所以前面每一步都不会报错，它们会一路走到最终报表里。

逻辑不可能。数量为负、结束日期早于开始日期。这类一定是错的，但系统不会拦。
业务不合理。原值为 0、单台设备九千九百万。不一定错，但需要人来确认。
哨兵值。1900-01-01、2099-12-31、99999 这类占位值，是源系统在「没有数据」时填进去的。它比空值更危险 – 空值你看得见，哨兵值混在真实数据里参与计算，结果全是错的。

删掉之后你就没法回答「删了多少条、为什么删」。打标签保留全部原始数据：想筛的时候用行过滤一步就能筛，要交代的时候数字随时拿得出来。

打完标签，用第 6 讲的分组聚合按标记计数，就得到一张现成的数据质量报告：

「我处理了 12,486 条，其中 273 条有问题，明细如下」 – 这比「数据都清干净了」有说服力得多，而且成本只是多两个节点。

红灯带感叹号的时候，新手最常见的动作是回去翻配置。那是在猜。答案已经写在控制台里了。

红灯有两种，别混。红灯带感叹号是执行出错，控制台里有日志；红灯不带感叹号只是还没配置好，翻日志是找不到东西的。这是第 1 讲讲过的，到这里应该已经变成本能。

读日志三十秒，猜配置三十分钟。这个顺序建立起来，你就不需要别人帮你看流程了。

接一个统计信息节点，看看缺失值和最大最小。多数人第一次做都会有意外发现。