4. 生产数据流与实时计算架构

预警要“实时”，钻取要“可回溯”，这两件事对底层链路的要求并不相同。实时预警要求数据在秒级甚至亚秒级内完成采集、判断和推送；钻取分析则要求原始数据、中间状态和判定依据都能被完整保留，并支持按设备、批次、时间窗、异常类型多维下钻。因此，生产数据流架构不能只画一条“采集→入库→报警”的直线，而要把消息队列、流处理引擎、边缘计算和云计算四类角色放在同一条链路上协同：边缘负责低延迟的本地判断与数据预处理，消息队列负责削峰、解耦和可重放，流处理引擎负责窗口计算与规则匹配，云计算负责全局模型、历史存储和钻取服务。

一、四层协同的整体链路

一条典型的生产实时链路可以这样组织：设备侧 PLC、传感器、扫码枪、视觉相机通过 OPC UA、Modbus TCP、MQTT 等协议把原始信号送到边缘网关；边缘网关完成协议解析、单位换算、时间戳对齐和简单阈值判断，把“高频原始点”压缩为“低频事件流”；事件流经 Kafka、Pulsar 或 RocketMQ 等消息队列进入流处理引擎；流处理引擎按时间窗口做聚合、关联和规则匹配，输出预警事件；预警事件一路写入云端的时序库与对象存储，一路推送给看板和工单系统；云端同时保留原始数据副本，供后续钻取分析使用。

二、消息队列：削峰、解耦与可重放

生产现场的数据速率并不均匀。注塑机合模瞬间、视觉检测触发时、扫码枪连续扫描时，瞬时数据量可能是平均值的几十倍。如果边缘网关直接调用云端 API，网络抖动或云端限流就会导致数据丢失。消息队列的核心价值在于把“生产数据”和“消费数据”解耦：边缘只负责往 Topic 写，流处理引擎按自己的节奏读，双方不需要知道对方的存在。

以 Kafka 为例，一个合理的 Topic 设计是按“车间-产线-设备类型”分层，例如 prod/workshop-a/line-01/injection。分区键选择设备编号，保证同一台设备的数据严格有序。关键参数上，acks=all 保证消息不丢，retention.ms=604800（7 天）保证异常发生后有足够时间回溯，compression.type=lz4 降低网络与存储开销。消费端使用手动提交 offset，只有流处理引擎确认处理完成后才提交，避免“消息已消费但计算失败”的静默丢失。

三、流处理引擎：窗口计算与规则匹配

流处理引擎是把“数据流”变成“预警事件”的核心。它需要解决三个问题：时间语义、窗口划分和状态管理。生产数据往往存在乱序，设备时钟与网关时钟可能相差几百毫秒，因此应使用事件时间（Event Time）而非处理时间（Processing Time），并设置合理的 Watermark 延迟，例如 Watermark = 事件时间 - 5s，允许迟到 5 秒内的数据参与计算。

窗口划分要贴合工艺。以注塑机为例，一个成型周期约 25 秒，那么“连续 3 模次保压压力偏低”就应该用“计数窗口”或“滑动窗口”表达，而不是固定 1 分钟窗口。下面是一段 Flink SQL 风格的示例，用于检测“同一设备 5 分钟内温度超标次数 ≥ 3”：

SELECT
  device_id,
  COUNT(*) AS over_temp_cnt,
  MIN(event_time) AS first_ts,
  MAX(event_time) AS last_ts
FROM sensor_stream
WHERE temp_c > 185.0
GROUP BY
  device_id,
  TUMBLE(event_time, INTERVAL '5' MINUTE)
HAVING COUNT(*) >= 3;

这条查询的输出就是一条预警事件，包含设备编号、超标次数、首次和末次时间。它既可以直接推送看板，也可以写入时序库供后续钻取。需要注意的是，阈值 185.0 和次数 3 都是示例参数，实际值应根据工艺文件和设备手册确定。

四、边缘与云的职责边界

边缘计算和云计算不是替代关系，而是分工关系。边缘适合做“低延迟、高频率、本地闭环”的判断，例如安全门未关、急停触发、温度超过硬限值，这类事件必须在 100 毫秒内响应，不能等数据上云。云端适合做“全局、历史、复杂模型”的分析，例如跨产线的质量趋势对比、基于历史数据的预测性维护、按批次追溯的根因分析。

一个实用的边界划分原则是：边缘做“点判断”，云端做“面分析”。边缘只保留最近几分钟的缓存，断网时本地继续报警并缓存数据，网络恢复后按时间顺序补传；云端保留全量数据，负责规则版本管理、模型训练和钻取服务。边缘的规则可以由云端统一下发，但边缘必须保留“断网可用”的降级策略，否则一旦网络中断，预警就会整体失效。

五、支撑钻取分析的数据保留策略

预警只是起点，钻取才是定位根因的关键。为了让“某台设备在 14:32 触发温度预警”这件事可以被完整回溯，链路中至少需要保留三类数据：原始传感器点、流处理中间状态、预警事件本身。原始点用于看趋势，中间状态用于看窗口内到底发生了什么，预警事件用于看当时触发了哪条规则、阈值是多少。

建议采用分层保留：边缘缓存最近 2 小时原始数据，消息队列保留 7 天，云端时序库保留 1 年，对象存储保留 3 年。这样既控制了成本，又保证了从“秒级预警”到“年度复盘”的完整可追溯性。钻取时，用户从预警事件出发，按设备编号和时间窗反查原始点，再结合工艺参数和批次信息，就能判断是设备漂移、原料波动还是操作异常。