实时与离线统一架构

引言

在工厂数据平台总体架构的设计中，实时处理与离线分析的统一是一个核心命题。生产现场需要秒级的设备状态监控和告警，经营管理需要天级的趋势分析和报表。如何在同一套数据平台中兼顾这两种截然不同的需求，是现代工厂数据架构设计的关键挑战。

三种架构范式

Lambda架构

Lambda架构是经典的双路径设计，同时维护实时层和批处理层：

数据源 → [实时层] 流处理引擎(Flink/Storm) → 实时视图
       → [批处理层] 批处理引擎(Spark) → 批处理视图
                                           ↓
                              [服务层] 合并两个视图 → 查询结果

优势：

• 容错性好，批处理层可以修正实时层的错误
• 数据准确性与时效性兼顾
• 技术成熟度高

劣势：

• 代码重复：同一业务逻辑需要在实时和离线两套系统中实现
• 运维成本高：需要同时维护两套计算引擎
• 结果合并复杂：服务层需要处理实时数据与批处理数据的合并逻辑

Kappa架构

Kappa架构主张”一切皆流”，只保留一套流处理引擎：

数据源 → 消息总线(Kafka) → 流处理引擎(Flink) → 服务层

优势：

• 单一计算引擎，无代码重复
• 架构简洁，运维成本低
• 统一的编程模型

劣势：

• 历史数据处理需要通过消息重放实现
• 对流处理引擎的容错和状态管理能力要求极高
• 大规模历史重计算的效率不如批处理

湖仓一体（Data Lakehouse）

湖仓一体是近年兴起的架构范式，试图在数据湖上构建数据仓库的能力：

数据源 → 消息总线 → 开放表格式(Iceberg/Paimon/Hudi)
                              ↓
                    Flink(实时读写) / Spark(批量分析)
                              ↓
                        OLAP引擎(Doris)

优势：

• 统一存储，消除数据冗余
• 支持ACID事务，数据一致性有保障
• 同时支持流式和批量读写
• 开放格式，不绑定特定引擎

劣势：

• 技术成熟度相对较低
• 实时性能不及纯流架构
• 对运维团队要求较高

工厂场景的架构选择

纯实时场景选择Kappa

以下工厂场景适合采用Kappa架构的纯流处理：

• 实时告警：设备参数超限、异常振动、质量异常等
• 实时OEE-设备综合效率计算：基于设备状态流的实时OEE计算
• 实时看板：产线状态、产量进度、质量趋势的秒级刷新
• SCADA-数据采集与监视数据流：设备状态数据的实时流转

这些场景的数据量可控，计算逻辑明确，对延迟敏感，Kappa架构的简洁性是最大优势。

纯离线场景选择Lambda的批处理层

以下场景仍然需要传统的批处理模式：

• 月度/季度经营报表：需要跨多个系统的大规模数据关联
• 历史趋势分析：长周期的产能趋势、质量趋势分析
• 模型训练：基于大量历史数据训练预测模型
• 数据对账：不同系统间的数据一致性校验

混合架构：工厂的最优解

综合工厂场景的实际需求，推荐采用Kappa为主、批处理为辅、湖仓一体为基座的混合架构：

                    ┌─── 实时告警(Flink CEP) ──→ 通知系统
                    │
设备数据 → Kafka ───┼─── 实时指标(Flink SQL) ──→ Doris(OLAP) ──→ 看板
                    │
                    ├─── 实时同步(Flink) ──→ Iceberg(数据湖)
                    │                              ↓
                    └─── 批处理(Spark) ──→ Iceberg ←─┘
                                                      ↓
                                              Doris ──→ 报表/分析

湖仓一体的工厂落地

核心技术栈

Apache Iceberg 作为数据湖格式：

• 支持ACID事务，保证数据一致性
• 支持时间旅行（Time Travel），可查询任意历史时刻的数据
• 支持Schema Evolution，适应工厂数据结构变化
• 支持增量读取，Flink可以增量消费Iceberg数据

Apache Flink 作为统一计算引擎：

• 流批一体，同一套SQL既支持流也支持批
• 状态管理能力强，支持大规模状态后端（RocksDB）
• Checkpoint机制保障Exactly-Once语义

Apache Doris 作为OLAP引擎：

• 毫秒级查询响应，支撑实时看板
• 多表Join能力强，支撑多维度分析
• 物化视图自动维护，支撑预聚合

关键设计决策

1. 数据写入策略

Kafka → Flink → Iceberg（批量提交，每1-5分钟一个数据文件）
Kafka → Flink → Doris（实时写入，Stream Load）

Iceberg的写入采用微批模式（Mini-batch），平衡写入延迟与文件数量。Doris的写入采用Stream Load，实现秒级可见。

2. 数据合并策略

Iceberg中的小文件需要定期合并（Compaction），避免查询性能下降：

• 合并频率：每10分钟或文件数达到阈值时触发
• 合并策略：合并同一时间分区内的数据文件
• 并行度：根据集群资源动态调整

3. 数据一致性保障

• 实时路径：Flink Checkpoint + Kafka Offset管理，保证At-Least-Once
• 离线路径：Iceberg的ACID事务保证批处理写入的原子性
• 跨路径对账：定期比对实时结果与离线结果，发现并修正偏差

数据新鲜度分级

工厂中不同应用对数据新鲜度的要求差异巨大，架构设计需要分级保障：

新鲜度级别	延迟目标	典型场景	技术路径
秒级	< 5秒	设备状态看板、安全监控	Flink → Doris → Grafana
分钟级	< 5分钟	异常告警、质量预警	Flink CEP → 告警引擎
小时级	< 1小时	班组产量报表、能耗统计	Spark/Iceberg → Doris
天级	T+1	日报、趋势分析、经营报表	Spark → Iceberg → 报表服务

数据新鲜度的SLA设计

每个新鲜度级别需要定义明确的服务等级协议（SLA）：

秒级服务：可用性99.95%，延迟P99 < 5秒
分钟级服务：可用性99.9%，延迟P99 < 5分钟
小时级服务：可用性99.5%，延迟 < 1小时
天级服务：可用性99%，每日8:00前完成

SLA的设计直接影响技术架构的冗余度和监控告警的配置。

架构演进路径

阶段一：Kappa先行

建设初期以Kappa架构为主，聚焦实时场景：

• 搭建Kafka消息总线
• 部署Flink集群，实现实时数据流水线
• 对接Doris，支撑实时看板

阶段二：引入数据湖

随着数据积累，引入湖仓一体：

• 部署Iceberg数据湖
• Flink实时写入Iceberg，实现历史数据归档
• 引入Spark进行离线分析

阶段三：全面统一

最终实现实时与离线的全面统一：

• Iceberg作为统一存储基座
• Flink/Spark共享Iceberg数据
• Doris作为统一查询引擎
• 工厂数据仓库建模提供统一数据模型

常见陷阱

1. 过度追求实时：并非所有场景都需要秒级数据，过度实时化会增加系统复杂度和成本
2. 忽视数据质量：实时数据的清洗和校验比离线更困难，需要在数据采集层架构做好前置处理
3. Lambda的代码重复：如果采用Lambda架构，务必抽象共享逻辑层，避免双倍维护成本
4. 小文件问题：湖仓一体架构中，小文件问题是性能杀手，必须有完善的Compaction策略

总结

在工厂场景中，实时与离线统一架构的选择应遵循”需求驱动、务实选择、渐进演进”的原则。Kappa架构适合实时场景，Lambda的批处理层适合大规模分析，湖仓一体提供了未来统一的技术基座。通过数据新鲜度分级策略，可以在一套架构中优雅地满足从秒级监控到天级分析的全频谱需求，最终服务于工厂数据平台总体架构的整体目标。