📚 课程目录第2章历史数据源与事件日志采集

2. 历史数据源与事件日志采集

历史数据回放与事件重建的第一步，不是“把数据读出来”，而是把分散在不同系统、不同格式、不同时间语义下的数据，整理成一条可被统一回放的时间轴。若采集阶段没有解决多源接入、日志规范、时间戳对齐与质量评估，后续回放只会把错误放大：事件顺序错乱、状态跳变、因果链断裂，最终导致复盘结论不可信。因此，本节围绕四个关键问题展开：数据从哪里来、日志如何统一、时间如何对齐、质量如何判断，并给出可执行的采集任务设计方法。

一、多源异构数据接入：先分类，再定接入方式

工业与信息系统中的历史数据通常分为四类。第一类是时序测量数据，如温度、压力、电流、转速，常来自 SCADA、DCS、PLC 或时序数据库，特点是按固定周期采样、数值连续、带质量码。第二类是事件与报警日志，如设备启停、保护动作、操作员确认，常来自报警系统、事件记录器或 MES，特点是离散、带事件类型与优先级。第三类是操作与审计日志，如参数修改、登录、下发指令，常来自 HMI、操作站或业务系统，特点是含操作者、对象、前后值。第四类是外部关联数据，如工单、检修记录、视频片段、气象数据，用于补充上下文。

接入方式上，对支持标准接口的系统优先采用 OPC UA、Modbus TCP、REST API 或数据库直连；对只提供文件导出的系统，采用 CSV/JSON 批量导入；对无法主动推送的老旧设备，采用网关采集或串口转以太网。关键原则是：接入层只做“取回并落地”，不做复杂业务判断，避免采集程序因逻辑过重而丢数。落地时统一写入一个原始层（Raw Layer），保留原始报文、采集时刻和来源标识，为后续清洗与追溯留出空间。

二、日志规范：让每条记录都“自描述”

多源数据最大的障碍是字段含义不一致。例如同样是“时间”，有的系统写本地时间，有的写 UTC；同样是“状态”，有的用 0/1，有的用 ON/OFF，有的用中文“运行/停止”。因此必须定义统一的日志规范。推荐每条事件记录至少包含以下字段：

event_id：全局唯一标识，建议由“来源系统+设备号+序号”组成；
source：数据来源系统或采集通道；
device_id / tag：设备或测点唯一编码；
event_type：事件类型，如 alarm、command、state_change、measurement；
event_time：事件发生时间，统一为 UTC 或带时区偏移的 ISO 8601 格式；
ingest_time：采集入库时间，用于计算延迟；
value / old_value / new_value：数值或状态变化；
quality：质量码，如 good、uncertain、bad；
payload：原始扩展字段，保留未映射内容。

规范落地时，建议维护一份“字段映射表”，把每个来源的原始字段映射到统一字段。例如某 PLC 的 TS_LOCAL 映射为 event_time，POINT 映射为 tag，VAL 映射为 value。映射表应版本化，任何变更都记录生效时间，否则历史回放会出现“同一字段前后含义不同”的隐蔽错误。

三、时间戳对齐：统一时间基准与插值策略

时间戳对齐是采集阶段最容易被低估的环节。不同系统时钟可能相差几十毫秒到数秒，采样周期也不同。对齐的目标不是“让所有时间完全一样”，而是让同一物理事件在不同来源中能被正确关联。操作上分三步：

统一时间基准：所有来源的 event_time 统一转换为 UTC，并保留原始时区信息。若设备只提供本地时间，需记录时区与夏令时规则。
时钟偏差估计：对支持 NTP/PTP 的系统直接同步；对不支持的系统，利用同一事件在多个来源中的出现时刻估计偏差。例如某断路器跳闸在保护装置记录为 10:00:00.120，在 SCADA 记录为 10:00:00.480，则 SCADA 相对保护装置偏差约 +360 ms，可在采集层做补偿。
重采样与插值：对连续测量量，按回放所需的最小时间粒度（如 100 ms）重采样。模拟量可用线性插值或保持前值；开关量必须用“状态保持”而非插值，避免把 0/1 中间值当成有效状态。

注意：插值只适用于回放展示，不应写回原始层。原始层必须保留真实采样点，否则会破坏数据可追溯性。

四、数据质量评估：用指标判断“能不能用”

采集完成后，必须对数据质量做量化评估，而不是凭感觉判断。常用指标包括：

指标	含义	示例阈值
完整率	实际记录数 / 应记录数	≥ 99%
时间偏差	event_time 与基准时间的偏差	≤ 200 ms
重复率	重复 event_id 占比	≤ 0.1%
质量码异常率	bad/uncertain 记录占比	≤ 1%
采集延迟	ingest_time − event_time	≤ 5 s

评估结果应形成一份质量报告，标明每个来源、每个时间段的达标情况。对不达标的数据，要么修复，要么在回放时标记为“低置信度”，避免与正常数据混用。

五、采集任务设计：把上述规则变成可运行的任务

采集任务设计应遵循“按来源拆分、独立失败、幂等写入、可监控”的原则。一个可参考的任务配置如下（以 YAML 示例说明结构，参数为示例值）：

task_id: collect_scada_line1
source: scada_opcua
endpoint: opc.tcp://10.10.1.20:4840
tags:
  - TIC101      # 反应器温度
  - PIC102      # 反应器压力
  - FIC103      # 进料流量
sample_interval_ms: 500
batch_size: 200
time_sync: ntp
timezone: Asia/Shanghai
retry: 3
idempotent_key: event_id
quality_rule:
  stale_timeout_ms: 3000
  bad_if: value is null or quality != good

任务运行时，采集程序按 sample_interval_ms 读取测点，写入原始层，并记录 ingest_time。若某次读取失败，按 retry 重试；重试仍失败则记录失败事件并继续下一周期，避免阻塞其他测点。写入时以 event_id 为幂等键，重复数据直接忽略。监控侧重点看三个量：采集延迟是否超过阈值、单位时间失败次数、待处理积压量。若延迟持续升高，通常说明网络或目标系统响应变慢；若失败集中在某几个 tag，则可能是该测点配置错误或设备离线。

最后需要强调：采集不是一次性工作，而是持续运行的数据管道。建议每次回放前先跑一次质量评估，确认完整率、时间偏差和重复率达标后再进入回放。若质量不达标，应在回放结果中标注数据置信度，而不是直接忽略。只有把“来源可追溯、字段可映射、时间可对齐、质量可量化、任务可监控”这五件事同时做到，历史数据回放与事件重建才有可靠的基础。