4、数据质量评估：完整性检查、一致性检查、准确性评估、时效性判断、数据质量报告生成
数据清洗之前，你得先知道数据到底有多「脏」。
我见过不少团队，上来就写清洗脚本，结果洗了半天发现数据根本没法用——缺失率超过80%，时间戳全是乱的。白忙活一场。
所以我的习惯是：先评估，再动手。数据质量评估，说白了就是给数据做个「体检」。体检报告出来了，你才知道该治哪、怎么治。
核心要点：数据质量评估不是一次性工作。在边缘场景下，数据源、网络、传感器都可能随时出问题。我建议把它做成一个持续运行的监控任务，每批数据进来先过一遍评估。
4.1 完整性检查
完整性检查，就是看数据有没有「缺胳膊少腿」。
最常见的场景：传感器某段时间没上报数据，或者上报的数据字段不全。比如一个温度传感器，本应上报 device_id, timestamp, temperature, humidity 四个字段，结果只来了三个。
我一般分两步走：
- 记录级完整性：检查有没有整条记录缺失。比如每分钟应该有一条数据，结果某分钟没有。这通常用时间序列的「断点检测」来做。
- 字段级完整性：检查单条记录里有没有空值。比如温度字段是 null，或者 humidity 字段是空字符串。
举个例子，我在一个工业项目里遇到过：振动传感器每隔100ms上报一次数据，但现场的网络偶尔会抖动，导致丢包。我们用完整性检查发现，每天大约有0.3%的数据包丢失。虽然比例不高，但累积下来会影响故障预测的准确率。
我的小技巧：完整性检查的阈值要动态调整。比如白天数据量大，丢几个包无所谓；但夜间数据量小，丢一个包可能就影响分析。我习惯按时间段设置不同的容忍度。
4.2 一致性检查
一致性检查，说白了就是看数据「讲不讲逻辑」。
举个例子：一个设备上报了「温度=25°C，湿度=90%」。从物理常识看，温度25°C时湿度90%虽然可能，但概率很低。再比如，同一个设备在同一时间戳上报了两条不同的温度值——这就明显不一致了。
我常用的检查手段：
- 跨字段一致性：比如风速和风向的关系，温度和湿度的关系。可以建一个简单的规则引擎来校验。
- 跨时间一致性：同一个设备的数值不应该突变。比如上一秒温度20°C，下一秒跳到80°C，这肯定有问题。
- 跨设备一致性：相邻的两个传感器，读数应该相近。如果差距过大，说明至少有一个设备出问题了。
我曾经踩过一个坑：某次做空气质量监测，两个PM2.5传感器放在同一个位置，一个报35μg/m³，一个报120μg/m³。我一开始以为是设备故障，后来发现是其中一个传感器的滤网堵了。一致性检查帮我提前发现了这个问题。
注意：一致性检查的规则不能太死板。比如「温度不能突变」这条规则，在设备重启或校准的时候就不适用。我建议给规则加上「豁免窗口」，比如设备重启后30秒内不检查一致性。
4.3 准确性评估
准确性评估，是判断数据「准不准」。
这其实是最难的一步。因为很多时候你根本不知道真实值是多少。比如一个温度传感器报25°C，它到底准不准？除非你拿一个校准过的标准温度计去对比。
在边缘场景下，我通常用这几种方法：
- 统计分布法：看数据是否符合历史分布。比如过去一周的温度都在20-30°C之间，突然出现一个-10°C的值，那大概率是错的。
- 多源交叉验证：如果有多个同类传感器，可以用它们的平均值或中位数作为参考。偏离太远的，标记为可疑。
- 物理约束法：根据物理规律判断。比如一个电机的电流不可能超过额定值的2倍，超过了就是异常。
我记得有个项目是做冷链物流的，冷藏车的温度传感器偶尔会漂移。我们用多源交叉验证——车厢里装了3个传感器，取中位数作为参考值。任何一个传感器偏离中位数超过2°C，就触发告警。这个方法简单有效，帮客户省了不少冷链损耗。
核心原则：准确性评估不需要100%精确。在边缘场景下，我们追求的是「足够好」——能识别出明显异常的数据就够了。剩下的交给云端做更精细的分析。
4.4 时效性判断
时效性判断，就是看数据「来得及不及时」。
边缘计算的一个特点就是实时性要求高。如果数据延迟太久，那它再准确也没用。比如自动驾驶的障碍物检测，延迟100ms可能就撞上了。
我一般关注两个指标：
- 数据延迟：从数据产生到到达处理节点的时间差。比如传感器在10:00:00采集的数据，10:00:05才到达边缘网关，那延迟就是5秒。
- 数据新鲜度：数据的时间戳与当前时间的差值。如果一条数据的时间戳是1小时前的，那它基本就是「过期」的了。
你想想看，在工业场景里，设备状态数据如果延迟超过30秒，那告警基本就没意义了。所以我习惯在数据入口处加一个「时间戳校验器」——任何延迟超过阈值的数据，直接丢弃或打上过期标签。
我的经验：时效性阈值要分场景设置。比如设备状态监控，延迟5秒以内可以接受；但交易类数据，延迟超过1秒就不行。我一般会在配置中心里维护一个「时效性策略表」，不同数据流用不同的阈值。
4.5 数据质量报告生成
评估完了，得有个报告。不然你光知道数据有问题，但说不清问题在哪、有多严重。
我习惯生成一份结构化的质量报告，包含以下内容：
| 维度 | 指标 | 说明 |
|---|---|---|
| 完整性 | 缺失率、空值率 | 每条记录、每个字段的缺失情况 |
| 一致性 | 冲突记录数、异常比例 | 违反规则的数据条数 |
| 准确性 | 异常值比例、偏差分布 | 偏离正常范围的数据占比 |
| 时效性 | 平均延迟、最大延迟、过期率 | 数据到达的及时程度 |
| 综合评分 | 质量得分（0-100） | 各维度加权后的总分 |
报告最好能可视化。我一般用柱状图展示各维度的得分，用热力图展示不同时间段的质量变化。这样一眼就能看出问题集中在哪里。
下面是我画的一张数据质量评估流程图，帮你理清整体逻辑：
报告生成之后，我一般会做两件事：
- 自动触发清洗：如果某个维度的得分低于阈值，自动启动对应的清洗流程。比如缺失率超过10%，就触发补值策略。
- 人工介入告警：如果综合评分低于60分，或者某个维度出现严重问题（比如一致性冲突率超过50%），就发告警给运维人员。
避坑指南：我曾经犯过一个错误——把质量报告做得太复杂，几十个指标堆在一起，结果没人看得懂。后来我学乖了：报告只保留5-7个核心指标，其他的放在附录里。记住，报告是给人看的，不是用来炫技的。
好了，数据质量评估这块就聊到这儿。你想想看，如果每次数据进来都能自动跑一遍这个流程，是不是能省下很多排查问题的时间？嗯，这就是我为什么一直强调「先评估再清洗」的原因。
最后一个小建议：质量评估的规则和阈值，最好能做成可配置的。因为不同场景、不同阶段，对数据质量的要求是不一样的。我习惯把规则存在一个JSON配置文件里，改起来方便，不用动代码。
公众号:蓝海资料掘金营，微信deep3321