基于 DolphinDB 的 MES 实时数据处理与分析解决方案

MES 整体架构说明

整体方案采用"数据源层—接入层—存储层—计算层—服务层—接口层—应用层"的七层架构。其中，数据源层与应用层为企业现有系统，DolphinDB 负责中间五层（接入层、存储层、计算层、服务层、接口层）的能力建设。

1）数据源层

负责产生现场工业实时数据与业务系统数据，主要包括 PLC、机器人、SCADA、测试设备等工业设备产生的时序数据，以及 MES、ERP、QMS 等业务系统中的工单、产品、质量等业务数据。同时支持 MQTT、Kafka 等消息中间件产生的实时流式数据，为上层分析提供统一数据来源。

2）数据接入层

负责多源异构工业数据的统一接入与标准化处理。DolphinDB 支持 Kafka、MQTT、OPC UA、TCPSocket、httpClient、API、JDBC、文件采集及边缘网关等多种工业协议与接入方式，实现设备数据、业务数据与消息流数据的统一汇聚。在接入过程中可同步完成协议解析、数据清洗、时间对齐、标签映射、异常过滤、单位换算、标准化编码等，从而降低传统 ETL 与中间缓存系统带来的架构复杂度。

3）存储层

基于 DolphinDB 多模态统一存储引擎，构建工业实时数据底座，对设备状态、工艺参数、能耗数据、报警事件、质量检测及工单批次等数据进行统一存储与分区管理。存储引擎结合实时过程数据、业务维度数据与事件明细数据，形成面向 MES 场景的统一工业数据模型，为实时计算与历史分析提供统一的数据基础。

4）计算分析层

基于 DolphinDB 流计算引擎与多模态存储引擎，分别支撑两类计算场景：流计算负责实时指标统计、窗口聚合与异常检测，实现核心数据秒级可见；批计算负责历史数据关联查询、多维聚合与复杂统计分析，满足大规模数据分析需求。

5）服务层

封装面向 MES 业务场景的统一数据服务，包括数据订阅、数据查询、指标计算及告警推送。将原本分散在 ETL、报表及中间表中的业务逻辑统一收敛，形成可复用的数据服务能力，避免各应用重复开发。

6）接口层

将服务层能力以标准化技术协议对外暴露，支持 Python/Java API、JDBC/ODBC 及 Web 接口等多种接入方式，满足 MES、ERP、QMS 及报表、移动端、第三方应用的对接需求。接口层屏蔽底层服务的实现细节，保证上下游系统在协议、格式与权限层面的标准化对接。

7）应用层

承载 MES 实时看板、设备监控、质量追溯、异常预警、OEE 分析、生产运营分析等具体业务应用。应用层基于服务层与接口层提供的统一数据能力，专注于业务逻辑呈现与现场交互，无需关心底层数据处理与存储细节。

针对 2.3 节所述的多源数据分散接入、链路冗长问题，DolphinDB 在接入与存储层提供一体化的数据汇聚与建模能力。

在数据接入层，数据接入过程中，DolphinDB 插件可同步完成协议解析、字段映射、时间对齐、异常值过滤、单位换算、标签标准化及数据清洗等处理，使原始工业数据在进入存储层前完成标准化，降低多系统维护与数据同步带来的复杂度，同时提升高频工业数据的实时写入、长期存储及历史分析能力。

在数据存储层，DolphinDB 基于多模态存储引擎，针对不同数据特征采用差异化建模策略：

• 高频时序数据（设备状态、工艺参数、能耗、报警事件、检测结果等）：按时间、产线、设备、工位等维度进行分区设计，兼顾写入吞吐与查询效率。

• 业务维度数据（工单、产品、设备台账等）：结合维度表与关系型数据模型进行管理，支撑后续多维关联分析。

两类数据在同一平台内完成建模与关联，MES 中原本分散在多个系统与中间表中的设备数据、生产数据和质量数据，可直接在平台内完成跨域查询与关联分析，企业无需在采集、存储、加工各环节维护多套异构组件，即可获得一套稳定的工业实时数据底座，为后续实时计算、质量追溯及历史趋势分析提供稳定的数据基础。

基于 DolphinDB 的流计算、向量化计算及多模态存储能力，平台能够在数据接入过程中同步完成实时指标计算，将原始设备流、事件流及过程数据直接转化为业务统计结果，减少传统多级处理链路。

平台可围绕班次产量、小时产量、合格（OK）/ 不合格（NG）数量、设备状态、停机时长、活动告警及关键工艺参数等核心指标，持续进行实时聚合、窗口计算与状态分析；同时结合时间分区裁剪、列式存储及向量化聚合能力，实现海量历史数据场景下的高性能统计分析与历史查询。

此外，平台还可将实时指标与分析逻辑以函数视图或标准接口方式统一沉淀，为 MES 看板、设备监控、报表系统及移动端应用提供统一的数据服务，避免传统模式下“每个页面单独统计、每个模块重复开发”的问题。

该方案的核心价值在于：通过统一的实时计算平台，实现核心生产指标的实时聚合与秒级响应，帮助企业提升生产监控、异常预警及运营分析的实时性。

基于 DolphinDB 的多模态存储引擎，平台可将产品 SN、批次、工单、设备状态、工艺参数、报警事件及检测结果等数据统一汇聚，并基于时间主线建立全过程关联关系，实现生产全过程数据的统一留存与快速回溯。

依托分布式存储、时间分区裁剪及向量化分析能力，平台能够快速完成产品、批次及工单维度下的历史数据关联分析，实现从“结果”到“过程”的秒级追溯，支撑质量复盘、工艺优化、报警分析及长期趋势分析等典型场景。

相比传统依赖复杂 SQL、离线脚本及多系统导出的实现方式，DolphinDB 能够在统一平台内完成历史数据查询与全过程关联分析，降低跨系统数据处理复杂度，同时提升海量历史工业数据场景下的查询效率与分析能力。

该方案的核心价值在于：通过统一的全过程数据关联能力，实现生产数据、设备数据与质量数据的快速追溯与历史分析，帮助企业提升问题定位效率与质量分析能力。

在本方案的整体架构中，DolphinDB 与现有 MES 系统形成“MES 管业务流程，DolphinDB 管实时数据”的协同模式。MES 继续负责工单执行、工艺管理、作业控制及业务闭环，而 DolphinDB 则统一承接高频工业数据接入、实时指标计算、质量追溯及历史分析等能力，实现数据处理与业务流程的解耦。

在系统协同层面，DolphinDB 可通过 Python/Java API、JDBC/ODBC 及 Web 接口等方式，对 MES 看板、设备监控、报表系统、移动端应用及周边业务系统提供统一的数据服务能力，避免传统模式下多个系统分别建设数据链路、重复加工数据的问题。

同时，平台支持渐进式改造方式。企业无需一次性重构现有 MES 架构，而是可以优先将实时看板、慢查询、报警分析、质量追溯等性能瓶颈场景逐步迁移至 DolphinDB 平台，在降低项目实施风险的同时，实现系统实时能力的持续升级。

相比传统分散式架构，该方案能够将原本分散在数据库、报表系统及中间处理程序中的统计与分析逻辑统一收敛至 DolphinDB 平台，降低系统复杂度与后续运维成本。

该方案的核心价值在于：在保留现有 MES 业务体系的基础上，逐步构建统一的数据服务与分析能力，实现系统实时能力的持续升级，并降低整体架构复杂度与运维成本。

班次产量统计是 MES 中最高频的核心查询之一，需要按班次维度对生产记录进行实时聚合，支撑生产看板、班次交接报表及车间日常运营。

原有方案瓶颈

原有关系型数据库架构下，班次产量统计需对生产记录表进行大量聚合与关联计算。随着历史数据持续积累，单次查询的扫描与聚合开销显著上升，在 5,000 万条数据规模下查询响应已达秒级，难以支撑实时刷新场景。

DolphinDB 优化方案

针对该场景，DolphinDB 采用 生产日期（WorkDate）+ 产线编码（LineCode） 复合分区策略。由于班次统计具备明确的时间范围与产线过滤条件，可通过分区剪枝快速定位目标数据，避免全表扫描；同时 SUM、COUNT 等聚合属于典型向量化场景，能够充分发挥 DolphinDB 列式存储与批量计算的性能优势。

改造后，在约 5,000 万条生产记录数据规模下，班次产量统计查询实测性能对比如下：

测试结果表明，在班次产量这类强时间过滤 + 标准聚合的场景下，DolphinDB 凭借按生产日期与产线的复合分区策略，能够将查询响应稳定控制在百毫秒级，相比传统关系型方案具备明显优势，可有效支撑实时生产看板等高频刷新场景。

小时产量统计需要基于生产时间窗口对合格（OK）/ 不合格（NG）数据进行分桶聚合，同时关联工单、设备及班次等业务信息，是 MES 统计分析中典型的多维关联 + 时间窗口聚合场景。

原有方案瓶颈

与班次产量统计的单一时间维度聚合不同，小时产量统计涉及更细粒度的时间窗口切分与多维业务关联。原有关系型数据库架构下，随着数据规模增长，时间窗口分桶、排序及多表关联的开销叠加，复杂聚合查询逐渐成为高频性能瓶颈。

DolphinDB 优化方案

针对该场景，DolphinDB 利用 TSDB 时序存储引擎下数据天然有序的特点，在时间窗口聚合时减少排序与临时结果生成开销。同时，由于小时产量统计仅涉及少量字段的聚合计算，列式存储能够进一步降低列扫描成本，避免传统行式存储中读取大量无关字段的 I/O 浪费。

改造后，在约 5,000 万条生产记录数据规模下，小时产量统计查询实测性能对比如下：

测试结果表明，在涉及多时间窗口聚合与多维业务关联的复杂统计场景下，DolphinDB 基于 TSDB 时序引擎的天然有序特性，能够显著降低排序与中间结果开销，无论单产线还是全厂多产线场景均能保持百毫秒级响应，更适合支撑现场实时监控与多维度产量分析需求。

报警与停机统计是 MES 中查询复杂度最高的场景之一，涉及报警起止识别、停机时长计算、跨班次时间分摊及多维度聚合分析，是设备综合效率（OEE）分析与故障根因定位的核心数据基础。

原有方案瓶颈

与前两类场景的聚合计算不同，报警与停机统计的核心难点在于连续状态变化数据的识别与区间计算。传统关系型数据库架构下，需要依赖大量窗口函数、临时表及多层 SQL 嵌套完成报警起止配对、停机区间计算及班次分摊，执行计划复杂度远高于常规聚合查询，且中间结果频繁落盘，随数据规模增长性能衰减尤为明显。

DolphinDB 优化方案

针对该场景的特殊性，DolphinDB 基于时间顺序快速识别状态切换过程，直接完成停机区间计算、报警聚合及班次分摊分析，从而避免传统方案中多层嵌套 SQL 与临时表带来的执行计划膨胀与中间结果开销。这一能力是 DolphinDB 相对前两类场景最显著的差异化优势——不仅是"算得快"，更是"算得简"，将原本需要数十行嵌套 SQL 的复杂逻辑收敛为简洁的时序分析表达。

改造后，在约 5,000 万条报警与设备状态数据规模下，报警与停机统计性能对比如下：

测试结果表明，在涉及连续状态变化识别、停机区间计算及多层业务分摊的高复杂度场景下，DolphinDB 能够避免传统方案中多层嵌套 SQL 与临时表带来的执行开销，将原本需要数十秒的复杂查询压缩至秒级以内。这是三类场景中相对传统架构优化幅度最大的部分，可有力支撑设备综合效率（OEE）分析、故障根因定位等深度应用。

前述 4.2.1–4.2.3 三类场景验证了 DolphinDB 在常规生产数据规模下的查询性能优势。为进一步验证 DolphinDB 在海量工业数据场景下的稳定性与扩展能力，本次测试选取 MES 中最典型的“班次产量统计”场景进行压力验证。测试基于生产过程记录表 MFM_ProcessRecord 进行，该表包含产线、班次、工单、工位、产品、生产时间及过程参数等字段，属于典型的 MES 生产过程明细宽表。

本次测试重点模拟制造业场景下“历史数据持续累积”的真实业务特征。随着 MES 长期运行，生产过程记录、设备状态及报警数据会持续增长，系统需要在海量历史数据基础上完成生产统计、实时看板及历史分析等高频查询。本次测试在保持查询 SQL 与过滤条件不变的情况下，逐步扩大生产过程明细表中的历史累计数据规模，分别构建约 1,000 万、2,000 万、5,000 万及 1 亿条生产记录数据场景。

测试环境配置详见 4.2 节统一说明。

DolphinDB 查询脚本如下：

pt = loadTable("dfs://mes_process_data", "MFM_ProcessRecord")
select
    LineCode,
    ShiftCode,
    WorkDate,
    sum(iif(OrderType == "Normal", 1, 0)) as NormalCount,
    count(ProcessRecordID) as TotalCount
from pt
where WorkDate between 2026.04.14 and 2026.04.23
    and LineCode = "T1"
    and IsFinalInspection == 1
group by LineCode, ShiftCode, WorkDate

测试结果如下：

从测试结果可以看出，在亿级数据规模下，DolphinDB 仍能将核心生产统计查询响应时间稳定控制在秒级以内，且响应时间随数据量呈接近线性的可预期增长，具备良好的长期可扩展性。

综合 4.2.1–4.2.4 的测试结果，DolphinDB 在工业数据场景下，既能应对当前千万至亿级数据规模的高频实时查询，也具备支撑未来数据持续累积增长的能力，可为后续业务扩展提供充足的性能余量。