4. 报警数据预处理实战

综合监控系统（ISCS）每天从车站BAS、FAS、PSCADA、ATS等子系统汇聚数万条报警记录。这些原始数据在进入报警统计、故障分析和指标计算之前，必须先经过预处理。未经清洗的报警数据往往存在字段缺失、时间戳格式不统一、重复上报、抖动刷屏等问题，直接用于分析会得出错误结论。本节以一段真实结构的地铁报警样本为对象，完整走一遍预处理任务，重点讲清楚每一步"为什么做、怎么做、结果怎么判断"。

一、样本结构与问题诊断

假设我们从某线路中心级ISCS历史库导出一份报警表，字段包括：alarm_id（报警唯一编号）、station（车站）、device_code（设备编码）、point_desc（点表描述）、alarm_level（报警级别）、occur_time（发生时间）、clear_time（恢复时间）、ack_time（确认时间）、subsystem（所属子系统）。导出样本约2000行，覆盖3个车站、5个子系统。初步检查发现四类典型问题：

• 缺失值：部分记录clear_time为空（报警尚未恢复或数据丢失），少数device_code为空。
• 时间不一致：occur_time存在两种格式，一种为2024-03-11 08:15:22，另一种为Unix毫秒时间戳；且不同子系统的时钟存在秒级偏差。
• 重复记录：同一设备同一报警点在数秒内被重复写入多条，alarm_id不同但内容几乎一致。
• 异常值：存在clear_time早于occur_time的记录，以及单点单日报警次数异常偏高（疑似抖动刷屏）。

下图给出本节完整的预处理流水线，以及每一步的输入、处理动作与输出判断，可作为整个任务的执行地图。

二、缺失值处理：区分"未恢复"与"数据丢失"

缺失值不能一律删除或一律填充。clear_time为空有两种含义：报警真实存在且尚未恢复，或数据在传输/入库环节丢失。判断方法是结合occur_time与当前时间：若报警发生已超过24小时仍无恢复时间，且该设备在后续时段无对应恢复记录，则标记为"未恢复"状态，保留记录并将clear_time置为特殊值（如NULL并新增status='active'字段），而不是简单填0或填当前时间——填当前时间会人为缩短报警持续时长，污染后续的MTTR（平均修复时间）统计。

对于device_code缺失，优先用point_desc在点表配置中反查设备编码回填；若点表也查不到，说明该记录来源异常，应剔除并计入质量报告。示例中约1.2%的记录属于此类，剔除后不影响整体分析。

三、时间对齐：统一格式与校正偏差

时间字段是报警分析的主键之一，格式不统一会导致排序、窗口计算全部失效。处理分两步：先做格式归一，再做偏差校正。格式归一用脚本将Unix毫秒时间戳统一转换为yyyy-MM-dd HH:mm:ss（按UTC+8时区），例如1710116122000转换为2024-03-11 08:15:22。偏差校正则针对不同子系统时钟不同步的问题：以中心级NTP时间为基准，若某子系统报警时间与关联事件（如同一故障引发的BAS与FAS报警）偏差超过2秒，则对该子系统整批记录打上"时钟可疑"标签，在跨系统关联分析时排除，但不修改原始时间值，保证可追溯。

# 时间格式归一示例（Python/pandas）
df['occur_time'] = df['occur_time'].apply(
    lambda x: pd.to_datetime(int(x), unit='ms', utc=True)
              .tz_convert('Asia/Shanghai')
              .strftime('%Y-%m-%d %H:%M:%S')
    if str(x).isdigit() else pd.to_datetime(x).strftime('%Y-%m-%d %H:%M:%S')
)

四、去重：窗口合并而非简单删行

重复报警的根源是采集端重发或网络抖动导致同一事件被多次写入。简单按全字段去重会漏掉alarm_id不同的重复记录。正确做法是按业务键分组：以station + device_code + point_desc为分组键，按occur_time排序，若相邻两条记录时间间隔不超过5秒，则视为同一次报警的重复上报，保留首条，并在新增字段repeat_count中累加重复次数。这样既消除了冗余，又保留了"该报警被重复上报了几次"这一有价值的信息——重复次数异常高本身可能就是采集链路故障的信号。

五、异常值检测：逻辑校验与频次校验

异常值检测分两类规则。第一类是逻辑校验：clear_time必须晚于occur_time，ack_time应介于两者之间；违反者标记为逻辑错误，移入隔离区。第二类是频次校验：统计每个"车站+设备+报警点"单日报警次数，超过阈值（示例取50次）判定为抖动刷屏。这类记录不应直接删除，因为抖动本身反映设备或采集问题，应打标is_flapping=1后保留，供后续设备健康分析使用。示例数据中检出逻辑错误17条、抖动点3个，均进入隔离区待人工复核。

六、清洗流程设计与质量报告

将上述步骤固化为可重复执行的流水线，顺序为：缺失值处理 → 时间对齐 → 去重 → 异常检测 → 输出。顺序不能随意调换：若先去重再对齐时间，格式不一致会导致窗口判断失效；若先检测异常再处理缺失，空值会干扰逻辑校验。每批次运行后生成质量报告，记录总行数、各步骤处理行数、保留率、隔离原因分布。示例批次处理后保留率约93.5%，满足≥90%的验收要求，隔离区记录逐条附原因码，可追溯到原始alarm_id。

完成预处理后，得到的有效报警表才具备进入报警统计、故障关联和指标计算的条件。建议将本节的五步流程封装为固定脚本或调度任务，按日或按班次自动运行，并把质量报告纳入日常运维巡检内容，使数据质量本身也成为可监控的对象。