扬尘在线监测平台接入了设备数据，为什么曲线还是会出现毛刺、长时间不变、数据重复，甚至同一时段出现多个不同数值？
问题未必出在可视化层。很多时候，真正需要检查的是数据从设备上报到平台入库的整个链路。
对于扬尘监测系统而言，数据处理至少要面对四类问题：
- **传输问题：**断网、重连、重复上报和延迟补传。
- **时序问题：**设备时间不一致、消息乱序和历史数据晚到。
- **质量问题：**量程异常、突变、长时间卡值和设备漂移。
- **审计问题：**人工补录、数据修订和异常剔除缺少完整记录。
如果这些问题没有在数据链路中得到处理，平台即使能够正常展示曲线，也不代表数据已经具备可靠的统计和分析条件。
本文从通用物联网数据架构出发，拆解扬尘在线监测的数据接入、异常清洗、质量控制与审计设计。文中的代码用于说明实现思路，不代表特定厂商 SDK 的实际接口。
一、先拆解数据入库链路
一个相对清晰的扬尘数据处理链路，可以划分为四层：
text
监测设备
│
▼
接入层：MQTT / HTTP / 协议适配
│
▼
原始数据层：原文保存、接收时间记录
│
▼
清洗与质控层：去重、时序检查、异常标记
│
▼
标准数据层：统一字段、质量状态、版本管理
│
├──► 时序查询与趋势分析
├──► 统计报表与数据导出
└──► 异常告警与运维审计这里有一个重要原则：原始数据、质控结果和最终统计结果不应混为一层。
原始数据用于还原设备上报内容；质控结果用于描述数据是否存在异常及异常类型；统计层则根据明确的业务规则，决定哪些数据可以进入相应统计。
例如，一条 PM10 数据被标记为"疑似突变"，并不意味着它一定错误。土方作业、车辆集中进出等情况也可能造成真实的短时变化。因此，异常识别应该先产生质量标记，再根据规则决定是否纳入特定统计，而不是直接删除原始记录。
二、接入层：处理重复上报、断网补传和消息乱序
1. 为什么消息去重不能只看接收时间？
假设某个监测点在 10:00 上报了一条数据，由于网络中断，设备在恢复连接后又补传了同一条记录。
如果平台每收到一次报文就直接插入数据库，曲线和统计结果就可能重复计数。
但如果只根据平台接收时间去重，也可能把同一条历史数据当成不同记录，因为两次报文的接收时间并不相同。
更合理的做法是区分两个时间字段：
| 字段 | 含义 | 用途 |
|---|---|---|
| event_time | 设备采样或记录发生的时间 | 数据排序、时间序列分析 |
| ingest_time | 平台接收到数据的时间 | 延迟分析、补传监控 |
| device_id | 设备标识 | 设备维度追踪 |
| point_id | 监测点位标识 | 点位维度统计 |
| metric | 监测指标 | 区分 PM10、PM2.5 等指标 |
| message_id | 消息唯一标识（如设备支持） | 识别重复报文 |
| payload_hash | 原始报文摘要 | 辅助识别重复内容和内容冲突 |
实际项目中，应优先使用设备提供的稳定消息标识。如果设备不提供消息 ID，可以根据点位、设备、指标、采样时间及原始报文摘要设计幂等策略。
需要注意：同一个时间戳如果出现不同数值，不应该直接把后到数据覆盖前一条。系统应先记录冲突，再依据设备协议、数据修订规则和质控结果处理。
2. 断点补传与乱序处理
断网补传后，平台收到的数据不一定按采样时间排列。例如，先收到 10:05 的记录，再收到 10:02 的历史记录。
因此，处理逻辑需要区分"消息到达顺序"和"数据发生顺序"。
可采用以下策略：
- 原始报文先落库，并记录平台接收时间。
- 根据采样时间和业务主键执行幂等处理。
- 对延迟到达的数据进行时间窗重排或增量修正。
- 对超出正常补传窗口的数据单独标记，触发历史数据校验。
- 对重复、冲突和无法解析的报文保留处理记录。
MQTT QoS 1 可以提高消息至少送达一次的可靠性，但并不保证消息只送达一次，因此消费端仍然需要幂等设计。HTTP 接口同样需要考虑客户端重试造成的重复请求。
三、清洗层：异常识别不等于直接删除
扬尘监测数据常见的异常包括乱序、突变、卡值和超量程。它们的判断条件不同，不适合用一套简单规则统一剔除。
1. 常见异常及处理方式
| 异常类型 | 可能原因 | 建议处理 |
|---|---|---|
| 时间乱序 | 断网补传、消息延迟 | 按采样时间排序，并记录迟到状态 |
| 短时突变 | 真实施工扬尘、设备异常、通信或解析问题 | 结合变化幅度、时间间隔和现场信息标记 |
| 长时间卡值 | 探头异常、设备故障、环境变化或数据重复 | 标记疑似卡值，检查设备状态和原始报文 |
| 超量程 | 真实高浓度、单位错误或设备异常 | 标记量程异常并核查设备量程配置 |
| 数据缺失 | 断网、设备离线、采集失败 | 明确标记缺失原因，不直接用插值掩盖缺口 |
| 数据冲突 | 同一时间收到不同数值 | 保留原始记录，进入冲突处理流程 |
其中，卡值检测尤其需要谨慎。连续多次上报相同数值，可能意味着设备异常，也可能只是测量分辨率有限或现场环境比较稳定。
因此，卡值规则最好结合持续时间、设备状态、采样频率和其他运行信息，而不是简单地将"数值不变"认定为故障。
2. 一个通用的 Python 质控示例
下面用简化代码演示如何给数据添加质量标记。它不是可直接用于生产的完整处理程序，量程、变化阈值和卡值持续时间均应按实际设备及业务规范配置。
python
from datetime import datetime, timedelta
def check_record(record, config, previous=None):
"""
通用质控示例：
保留原始值，返回质量标记，不直接删除记录。
"""
flags = []
value = record["value"]
event_time = record["event_time"]
# 1. 基础字段检查
if value is None or event_time is None:
flags.append("MISSING_FIELD")
return {
**record,
"quality_flags": flags,
}
# 2. 量程检查：范围需按设备及指标配置
lower = config["valid_min"]
upper = config["valid_max"]
if not lower <= value <= upper:
flags.append("OUT_OF_RANGE")
# 3. 突变检查：阈值需考虑时间间隔及点位特征
if previous is not None:
delta_time = (
event_time - previous["event_time"]
).total_seconds()
if delta_time > 0:
max_delta = (
config["max_change_per_second"] * delta_time
)
if abs(value - previous["value"]) > max_delta:
flags.append("SUSPECT_JUMP")
# 4. 卡值检测需要连续历史记录和持续时间窗口，
# 此处不使用单条记录直接判定。
return {
**record,
"quality_flags": flags,
}这段代码有意没有把突变数据直接过滤掉。原因很简单：监测数据出现突变，不等于数据错误。
在实际工程中，还需要补充时间戳格式校验、时区处理、数据类型检查、设备状态关联、连续卡值判断、异常规则版本以及异常处理结果的持久化。
此外，变化阈值不宜直接写死为一个固定数字。不同设备、不同监测指标、不同采样间隔的变化特征可能不同。可以利用历史数据分析确定初始规则，再结合现场核查结果持续调整。
四、质控层：把设备状态与数据可信度关联起来
仅凭数据值本身，很难判断一条记录是否可靠。质控时还应关注设备运行状态、维护记录和标定信息。
建议至少维护以下配置：
- 设备型号、监测指标及有效量程；
- 设备与监测点位的关联关系；
- 维护、检修和标定记录；
- 数据采样时间及设备状态；
- 质控规则版本和规则生效时间。
例如，设备标定信息已经过期时，可以将相关记录标记为"标定状态待核查"，并提示运维人员处理。但是否降低统计权重、排除出某类报表，必须依据适用规范和项目规则确定，不能由程序任意决定。
同样，发现数据漂移时，应先进行设备核查和必要的现场比对。不能仅凭两个点位的数值不同，就直接判定其中一个点位存在漂移，因为点位环境和实际浓度也可能不同。
一个更稳妥的设计是：质控层输出质量状态及原因，业务统计层根据明确的规则使用数据。 这样既能保留完整记录，也能避免算法规则直接改变原始监测结果。
五、入库设计：原始表、标准表和审计表分开
如果把原始报文、清洗后的数据和人工修订结果全部放在一张表里，后续很难判断一条数据是设备原始上报、算法处理结果，还是人工修改后的版本。
可以根据业务规模采用分层存储。下面是一个简化的 SQL 结构示例，字段和索引需要根据所用数据库调整。
1. 原始数据表
sql
CREATE TABLE dust_raw (
id BIGINT PRIMARY KEY,
point_id VARCHAR(64) NOT NULL,
device_id VARCHAR(64) NOT NULL,
metric VARCHAR(32) NOT NULL,
event_time TIMESTAMP NOT NULL,
ingest_time TIMESTAMP NOT NULL,
value DOUBLE PRECISION,
message_id VARCHAR(128),
payload_hash VARCHAR(128),
payload_json TEXT,
source_type VARCHAR(32) NOT NULL
);原始表主要用于保存接收到的数据及必要的来源信息。生产环境中，还应结合数据库类型、数据规模和查询方式设计索引、分区及保留策略。
2. 标准数据表
sql
CREATE TABLE dust_measurement (
id BIGINT PRIMARY KEY,
point_id VARCHAR(64) NOT NULL,
device_id VARCHAR(64) NOT NULL,
metric VARCHAR(32) NOT NULL,
event_time TIMESTAMP NOT NULL,
value DOUBLE PRECISION,
quality_status VARCHAR(32) NOT NULL,
quality_flags TEXT,
rule_version VARCHAR(64),
source_raw_id BIGINT,
created_at TIMESTAMP NOT NULL
);这里的 source_raw_id 用于关联原始记录，quality_flags 用于保存异常标记，rule_version 用于追踪数据经过哪一版规则处理。
如果业务要求同一设备、同一指标、同一采样时刻只能存在一条当前有效记录，还需要明确唯一键和冲突处理策略。不能在未定义数据修订规则的情况下，简单地用后到记录覆盖先到记录。
3. 审计记录表
sql
CREATE TABLE dust_data_audit (
id BIGINT PRIMARY KEY,
record_id BIGINT NOT NULL,
action_type VARCHAR(32) NOT NULL,
before_value DOUBLE PRECISION,
after_value DOUBLE PRECISION,
reason TEXT,
operator_id VARCHAR(64),
rule_version VARCHAR(64),
created_at TIMESTAMP NOT NULL
);审计记录用于描述数据被补录、修订、标记或排除的原因，以及操作人和处理时间。
如果需要更强的审计能力，还可以增加审批记录、请求来源、关联工单、操作前后状态以及日志完整性校验机制。审计日志的保留期限应按适用规范和项目要求配置，不宜笼统设定为永久保存。
六、数据缺失、人工补录与统计口径如何处理？
数据缺失不一定需要补齐，关键在于区分真实观测、设备补传和人工补录。
| 数据来源 | 建议处理方式 |
|---|---|
| 设备缓存补传 | 核验采样时间、设备标识及重复情况后入库 |
| 人工补录 | 单独标记来源，记录操作人、原因和审核结果 |
| 算法修订 | 保留原始值、修订结果、规则版本及修订原因 |
| 无法恢复的数据缺口 | 明确记录缺失时段，不伪造观测值 |
| 存在冲突的数据 | 保留原始记录，按明确规则核查和处理 |
对于报表和考核统计，应根据适用规则确定哪些记录有效、哪些记录需要复核、哪些时段属于数据缺失。不能把人工补录一律认定为无效，也不能将补录值直接与设备原始观测混为一谈。
如果需要使用插值进行趋势分析，应明确其为估算值，并与实际观测值区分。估算结果不能冒充设备真实采样数据。
七、生产环境落地时，还要注意什么？
1. 不要让清洗规则掩盖真实异常
突变检测的目的是发现需要核查的记录，而不是让曲线变得平滑。尤其在土方施工、车辆密集进出等场景中，短时浓度上升可能是真实发生的。
2. 不要只看入库成功率
数据接入成功，只能说明消息进入了处理链路。还应持续观察设备在线率、数据延迟、重复报文率、异常数据比例、补传完成情况和数据缺失时长。
3. 不要把数据质控等同于执法认定
质控状态反映的是数据处理系统发现的问题，不自动等同于监测结果无效或现场行为违规。涉及正式考核和监管应用时，应依据适用标准、设备要求和属地规则确定数据使用口径。
4. 不要让审计日志成为摆设
补录、修订、规则调整和异常排除，都应保留可追溯记录。关键日志可以通过权限隔离、追加写入、定期备份和完整性校验等方式降低被篡改的风险。
结语
扬尘在线监测的数据质量，不是靠一个去重函数或一条异常过滤规则就能保证的。它取决于接入协议、时间处理、原始数据保存、质控规则、入库模型和审计机制能否形成完整链路。
对于荆棘鸟科技涉及的扬尘监测与智能化监管场景，具体的数据接入方式、设备接口和质控流程，也应结合实际产品能力、项目部署条件及属地要求进行设计。
从工程实现角度看，最重要的原则有三条：原始记录可追溯，异常处理有依据，统计口径可解释。
先把数据的来源、状态和处理过程交代清楚，后续的趋势分析、异常告警和监管应用才有可靠基础。