📚 课程目录第4章实时数据管道工程

4. 实时数据管道工程

MOM（制造运营管理）监控系统的实时性，本质上不取决于前端看板刷新多快，而取决于数据从设备产生到进入分析链路所经过的每一段管道。车间现场存在三类典型数据源：PLC/DCS 等控制系统通过 OPC UA 暴露结构化过程量；传感器、AGV、仪表等通过 MQTT 上报轻量遥测；MES、WMS、SCADA 等系统则通过数据库或消息中间件输出业务事件。把这三类数据统一、可靠、低延迟地汇聚到监控平台，就是实时数据管道工程要解决的问题。

一、四类组件的职责边界

选型前必须先厘清各组件的定位，避免“用 Kafka 做设备接入”或“用 MQTT 做跨车间汇聚”这类错配。

OPC UA：面向设备与控制层的语义化协议，提供地址空间、类型系统和订阅机制（Subscription/MonitoredItem）。适合采集 PLC 变量、报警、设备状态，天然带时间戳和质量码（Quality）。
MQTT：轻量发布/订阅协议，基于 Broker 的 Topic 树，支持 QoS 0/1/2、遗嘱消息和保留消息。适合带宽受限、连接数多、数据量小的边缘遥测。
Kafka：分布式持久化日志，按 Partition 提供顺序性和并行消费，支持多消费者组回放。适合作为监控平台的“中枢总线”，承接高吞吐、需回溯、多下游订阅的数据。
边缘网关：部署在车间侧的协议转换与预处理节点，负责 OPC UA/MQTT/Modbus 采集、边缘计算（过滤、聚合、去抖）、断网缓存与上行转发。

二、选型判断：按数据特征而非技术偏好

选型的核心是匹配数据特征。以下判断表可作为工程决策依据（参数为示例性建议值，需按现场实测调整）：

数据特征	推荐接入方式	理由
采集点 < 5000，变化频率 < 10 Hz，需语义与质量码	OPC UA 订阅	类型安全、支持死区（Deadband）上报，减少无效流量
移动设备/无线传感器，连接数 > 1000，单包 < 1 KB	MQTT QoS1	长连接开销小，Topic 分层便于按产线订阅
需多下游消费、需回放、吞吐 > 10 万条/秒	Kafka	持久化 + 消费者组，支持重放与水平扩展
现场网络不稳定、需本地缓存	边缘网关 + 本地磁盘队列	断网续传，避免数据丢失

一个常见误区是把 MQTT Broker 直接当作 Kafka 使用。MQTT 的 QoS1 只保证“至少一次”，且 Broker 通常不长期保存历史消息，无法满足监控回溯需求。正确做法是：边缘网关以 MQTT 接入设备，再以 Kafka Producer 将数据写入 Kafka，由 Kafka 承担持久化与分发。

三、部署拓扑与数据流

下图展示了一个典型的车间—中心两级管道：边缘网关在车间侧完成协议转换与预处理，通过 MQTT 上行到边缘 Broker，再由桥接器写入中心 Kafka；OPC UA 采集器直接订阅 PLC，经边缘计算后同样汇入 Kafka；流处理引擎消费 Kafka 做窗口聚合与异常检测，结果分别写入时序库和告警通道。

四、关键配置与实现要点

以边缘网关向 Kafka 写入为例，核心配置包括 Topic 命名、分区键选择和序列化格式。Topic 建议按“域.实体.类型”命名，如 mom.telemetry.line1；分区键使用设备 ID，保证同一设备数据有序；消息体采用 JSON 或 Avro，并携带 event_time 与 ingest_time 两个时间戳，便于流处理区分事件时间与处理时间。

# 边缘网关 Kafka Producer 示例配置（示意）
bootstrap.servers: kafka-center:9092
acks: all
enable.idempotence: true
compression.type: lz4
linger.ms: 20
batch.size: 65536
key.serializer: org.apache.kafka.common.serialization.StringSerializer
value.serializer: io.confluent.kafka.serializers.KafkaAvroSerializer

# 消息体示例
{
  "device_id": "CNC-07",
  "metric": "spindle_speed",
  "value": 8420,
  "unit": "rpm",
  "quality": "good",
  "event_time": "2025-03-18T09:12:33.421Z",
  "ingest_time": "2025-03-18T09:12:33.587Z"
}

流处理侧的关键是处理乱序与重复。OPC UA 订阅和 MQTT QoS1 都可能产生重复消息，需在流处理中按 device_id + metric + event_time 做去重；对于乱序，设置 Watermark 延迟阈值（示例：5 秒），超过阈值的迟到数据进入侧输出流单独处理，避免阻塞主窗口。

边缘网关的本地缓存建议至少保留 30 分钟数据量。以单条消息 500 字节、每秒 2000 条计算，30 分钟约 1.8 GB，需预留相应磁盘空间并配置环形覆盖策略。

五、部署验证与结果判断

管道部署完成后，需从三个维度验证：端到端延迟、数据完整性、故障恢复能力。端到端延迟可通过在边缘注入带时间戳的测试消息，在流处理输出端计算 ingest_time - event_time 的 P99 值，示例目标为小于 2 秒。数据完整性通过对比边缘发送计数与 Kafka 消费计数，差值应小于 0.01%。故障恢复则模拟断开上行链路 5 分钟，恢复后检查 Kafka 是否收到缓存补发的数据，且顺序基本正确。

常见排障点：若 Kafka 消费延迟持续增长，优先检查 Partition 数量是否与消费者线程数匹配；若边缘网关 CPU 占用过高，检查是否对高频点位未设置死区过滤，导致无效数据占满上行带宽。

综上，实时数据管道的选型不是“选一个最好的协议”，而是让 OPC UA、MQTT、Kafka 和边缘网关各司其职：OPC UA 解决设备语义接入，MQTT 解决海量轻量连接，边缘网关解决现场预处理与断网续传，Kafka 解决持久化与多下游分发，流处理解决实时计算与异常判断。只有这条链路每一段都匹配数据特征，MOM 监控才能真正做到“实时可用”。