JRY's digital garden

实时数据流水线

9 min read

实时数据流水线

实时数据流水线是工厂数据平台总体架构中”实时侧”的核心组件，负责将数据采集层架构中采集到的海量时序数据在秒级~分钟级内转化为业务可用的指标、告警和看板数据。与离线批处理数仓互补，实时流水线解决的是”现在正在发生什么”的问题。

技术选型概述

工厂数据实时流水线的典型技术栈：

组件推荐选型角色
消息队列Apache Kafka数据缓冲与解耦
流计算引擎Apache Flink实时计算与处理
实时存储Apache Doris / MatrixDB实时OLAP查询
可视化Grafana / 自研看板实时数据展示

数据流向为：设备/PLC → 数据采集层架构(MQTT/OPC UA) → Kafka → Flink → Doris/时序数据库选型 → 看板/告警。

Flink在工厂的核心应用场景

实时OEE计算

OEE-设备综合效率是工厂最重要的实时指标之一，其计算需要实时消费设备状态数据流：

数据流设计：

  1. 设备状态流：每台设备每秒上报状态（运行/待机/故障/调试）和计数
  2. Flink消费Kafka中的设备状态Topic
  3. 按设备ID分组，使用滑动窗口（如5分钟窗口，1分钟滑动）计算：
    • 可用率 = 实际运行时间 / 计划生产时间
    • 性能率 = 实际产量 / 理论产量（基于设备节拍）
    • 质量率 = 合格品数 / 总产出数
    • OEE = 可用率 × 性能率 × 质量率
  4. 结果写入Doris，供看板实时查询

关键实现细节：

  • 使用Flink的事件时间（Event Time）语义，避免数据乱序导致计算偏差
  • 设置合理的水位线（Watermark）策略，允许一定的迟到数据
  • 状态后端使用RocksDB，支持大状态的容错

实时告警系统

工厂告警分为两个层次：

规则引擎告警（简单阈值）：

  • 设备温度超过上限 → 温度告警
  • 生产线停机超过N分钟 → 停机告警
  • OEE低于目标值 → 效率告警
  • 实现方式：Flink中的ProcessFunction，维护每个测点的阈值配置

CEP复杂事件处理：

  • 设备振动值连续3次递增且温度升高 → 预警设备可能故障
  • 某工序连续N个产品参数超标 → 触发质量预警
  • 多台设备同时停机 → 触发系统性异常告警
  • 实现方式：Flink CEP的Pattern API，定义事件模式序列

告警分级与分发：

  • 一级（紧急）：设备故障、安全风险 → 立即推送短信/APP
  • 二级（重要）：质量异常、效率下降 → 推送消息+工单
  • 三级（提示）：参数偏移、趋势预警 → 记录+日报汇总

实时看板

实时看板是工厂管理层和车间操作人员获取实时生产状态的主要窗口：

数据流：Flink → Doris → Grafana/自研看板

典型看板内容：

  • 全厂OEE实时值及趋势（分钟级刷新）
  • 各产线实时产量与目标对比
  • 设备状态地图（运行/待机/故障的实时分布）
  • 质量实时合格率及缺陷分布
  • 告警列表及处理状态

技术要点：

  • Doris支持实时数据写入和高并发查询，适合看板场景
  • Grafana通过SQL查询Doris，设置自动刷新间隔（10s~60s）
  • 自研看板可使用React + ECharts，通过数据服务与API层的WebSocket接口推送

Kafka在工厂的角色

Kafka在实时流水线中承担数据总线的作用：

Topic规划：

  • device-status-raw：设备原始状态数据（高频，每设备每秒1条）
  • device-status-parsed：经解析和清洗后的设备状态数据
  • production-event：生产事件（报工、换型、停机原因）
  • quality-inspection：质检结果数据
  • oee-minute：OEE分钟级计算结果
  • alarm-event：告警事件

分区策略：

  • 按设备ID或产线ID分区，保证同一设备的消息有序
  • 预估吞吐量：1000台设备 × 1条/秒 = 1000条/秒，Kafka轻松应对
  • 保留策略：原始数据保留7天，计算结果保留30天

Flink作业管理

作业拓扑

一个典型的工厂实时计算Flink作业包含多个算子链：

Kafka Source → 反序列化 → 数据清洗 → 设备状态解析 
                                    ↓
                        OEE计算 → Doris Sink
                                    ↓
                        告警检测 → 告警分发
                                    ↓
                        聚合统计 → Redis/Doris Sink

容错与状态管理

  • 启用Flink的Checkpoint机制（间隔60秒），保证Exactly-Once语义
  • 状态后端使用RocksDB，支持增量Checkpoint
  • 设置重启策略：固定延迟重启，最多3次
  • 告警状态使用TTL，避免状态无限增长

部署模式

  • Session集群：多个作业共享一个Flink集群，资源利用率高
  • Per-Job模式：每个作业独立集群，隔离性好
  • K8s部署：推荐方式，便于弹性伸缩和资源管理

实时与离线的统一

实时流水线产出的数据最终需要与实时与离线统一架构中的离线数仓对齐：

  1. Lambda架构：实时层（Flink）+ 批处理层（Spark），通过Serving层统一查询
  2. Kappa架构：全部通过Flink流处理，简化架构但复杂度高
  3. 推荐方案：实时层负责分钟级指标和告警，离线层负责T+1的精确汇总和报表，两者在工厂数据仓库建模的ADS层统一对外服务

实施建议

  1. 从OEE开始：实时OEE是工厂最有价值的实时场景，投入产出比最高
  2. 渐进式建设：先单产线验证 → 全厂推广 → 高级分析场景
  3. 关注数据质量：实时流水线对数据质量更敏感，需要在源头数据采集层架构做好质量控制
  4. 监控自己的监控：Flink作业本身的健康监控同样重要，包括反压、延迟、Checkpoint耗时等指标
  5. 合理设计窗口：窗口太短数据抖动大，窗口太长实时性差，需根据业务场景平衡

实时数据流水线的建设是一个系统工程，需要时序数据库选型、流计算引擎、存储引擎和可视化工具的协同配合。在智能制造概述与工业4.0的背景下，实时数据处理能力已经成为智能工厂的核心竞争力之一。

Graph View

Backlinks