← 返回知识库

# 沈阳顺义数据项目建设方案解读报告

## 1. 项目概述

深度分析 工程指南 调研研究

本报告对 `沈阳顺义-数据-项目建设方案` 目录下的两份文档进行深度解读：

- V1 建设方案（88页，2026年4月）— 系统故障预测与健康管理数据应用平台的完整技术设计文档
- 新增需求 — 项目的任务组成、功能要求（17项）与技术指标（13项），包含审查意见及修改状态

核心定位：该项目研制的平台位于「多源异构数据网关」之上、「故障诊断/虚拟仿真/数字孪生」等上层数据应用之下，构成承上启下的数据治理与供给中枢。不是业务应用系统，而是数据基础设施。

## 2. 实际建设内容拆解

方案包含 两大交付物：

#### 交付物一：数据应用平台软件

B/S 架构的分布式数据服务平台，包含完整的后端微服务、前端页面、数据存储与接口体系。采用 Spring Cloud + Vue3 技术栈，Docker 容器化部署。

#### 交付物二：管理终端（1台）

硬件设备，规格：CPU ≥4核、内存 ≥16G、存储 ≥512G。用于平台管理和运维操作。

### 2.1 软件功能模块（12+3个模块）

模块 | 核心功能点 | 关键技术
--- | --- | ---
系统管理 | 用户管理、组织架构、角色权限（业务角色/管理角色分离）、数据字典 | RBAC 权限模型
服务器监控 | 硬件监控（CPU/内存/磁盘/网络）、服务监控（微服务/数据库）、趋势分析（小时/日/月/年报表） | Node Exporter + cAdvisor + Actuator + SkyWalking
日志管理 | 操作日志（安全审计）、系统日志（运行事件）、日志配置（差异化归档周期+MinIO存储） | Filebeat + Elasticsearch + Spring Scheduler
备份与恢复 | 时序库增量备份、关系库全量+增量、备份校验（大小+MD5）、异地存储（主备双写+年度归档10年） | Spring Cloud Task
系统自检 | 服务自检（API/数据库/缓存/消息中间件）、链路自检（边-云/端-边/端-边-云全链路）、自检报告 | 分布式探针
监测大屏 | 波形实时展示（100路 × 10kHz）、通道状态（100通道在线/断开/异常）、采集数据实时值+统计值 | HTML5 + WebSocket，刷新率 ≤200ms
配置管理 | 设备台账管理、通道配置（频率/量程/类型/节点）、采集配置（启停/动态调频/原始数据预览） |
数据溯源 | 状态数据溯源、故障数据溯源 | 全链路追踪
模型管理 | 模型上传（物理机理/ML/数字孪生）、版本控制（记录/回滚/对比/归档） | MinIO 存储模型文件
任务管理 | 用户数据管理接口、任务编排（DAG可视化）、定时任务（Cron）、第三方接口调用配置 |
数据驾驶舱 | 设备统计、采集统计、故障统计、资源统计（CPU/内存/磁盘）、任务统计 | ECharts 二维图表
数据服务 | 数据资源管理（目录/表/文件/主题/标签）、数据治理（标准/元数据/质量/清洗）、数据开发（SQL工作台）、服务管理（API目录/发布/监控/日志/血缘） | RESTful API + WebSocket

### 2.2 数据存储体系

存储类型 | 存储内容 | 技术选型
--- | --- | ---
时序数据库 | 状态数据、实时监测指标、历史趋势数据 | 涛思 TDengine / KaiWuDB
关系型数据库 | 设备信息、测点信息、用户权限、接口配置、数据集信息 | 达梦 / 庚顿 / KaiWuDB
对象存储 | 故障波形文件、特征数据、仿真模型、音视频、文档资料 | MinIO
缓存服务 | 热点数据、实时快照、临时查询结果 | Redis 7.2.3
检索服务 | 数据标签、关键字、故障类型、任务编号 | Elasticsearch

### 2.3 数据接入层

数据类型 | 协议 | 语言 | 特点
--- | --- | --- | ---
高频时序数据 | ZeroMQ（发布-订阅） | C++ | 高性能、低时延、端到端、无中间代理
低频业务数据 | MQTT | Java | 轻量级、异步连接、消息持久化、断点续传

### 2.4 技术架构要点

- 后端：Spring Cloud 微服务架构，服务包括数据接收、数据资源、数据集、文件资源、算法任务、大屏数据项、接口服务、权限认证、日志审计、运行监控
- 前端：Vue3 + Element Plus + ECharts
- 网关：Nginx 1.25.0 统一反向代理
- 消息中间件：EMQX 5.1.6（MQTT Broker）
- 部署：Docker 24.0.7 容器化，支持离线安装；未来可扩展至 Kubernetes
- 国产化：X86 + ARM 双架构，麒麟 v10 操作系统，达梦/涛思/庚顿/KaiWuDB 国产数据库

## 3. 新增需求详细分析

### 3.1 任务组成（新增需求文件明确）

新增需求文件明确了项目包含两个独立交付物，这在 V1 方案中没有显式拆分：

- 某系统故障预测与健康管理数据应用平台软件 — 核心软件产品
- 某系统故障预测与健康管理数据应用平台管理终端 — 配套硬件（1台，CPU≥4核/内存≥16G/存储≥512G）

### 3.2 功能要求分析（17项，标注▲/★区分优先级）

编号 | 优先级 | 需求内容 | V1覆盖情况
--- | --- | --- | ---
(1) | ▲ | 大屏集中展示各应用系统运行状态与关键参数，跨系统统一监测 | 已覆盖（3.6 监测大屏）
(2) | ▲ | 为故障诊断系统提供设备及监测数据管理服务、故障波形与特征数据管理服务 | 已覆盖（3.7配置管理 + 3.12数据服务）
(3) | ▲ | 为虚拟仿真系统提供仿真模型管理、工况数据管理、虚实数据归集及仿真结果管理 | 已覆盖（3.9模型管理 + 3.12数据服务）
(4) | ★ | 实时监测/故障诊断/虚拟仿真大屏的数据项管理服务，支持数据项清单导入与维护及调用地址管理 | 已覆盖（建设思路(8) 大屏数据项管理），但 V1 软件功能目录中缺少独立章节
(5) | ★ | 为故障诊断/虚拟仿真/数字孪生系统提供数据集抽取、管理、标记、导入、实时/历史数据查看；状态/事件/音视频/文档数据的统一组织、属性标注、可视化展示；可扩展存储+快速检索；在线数据服务接口，支持订阅分发 | 部分覆盖（建设思路(5) 提到数据集管理，但 V1 软件功能目录中缺少独立章节，仅在 3.12 数据服务的子模块中涉及）
(6) | ★ | 算法资源管理、任务配置、计算任务管理，支持算法上传与复用、运行任务编排，可视化调度与监控 | 部分覆盖（3.9 模型管理 + 3.10 任务管理有涉及，但算法管理与模型管理的关系不够清晰）
(7) | ★ | 数据采集和建模服务：事件/状态/音视频数据采集建模；采集装置通讯协议集成；工况数据/结果数据文件接入；原始数据赋予业务语义；流式+批数据处理 | 部分覆盖（V1 有配置管理章节，但缺少边端数据处理协同内容——审查意见第1条明确指出此问题）
(8) | ★ | 服务器监控、日志管理、备份恢复、系统自检 | 已完全覆盖（3.2~3.5）
(9) | 普通 | 用户管理、组织架构、角色权限、数据字典 | 已完全覆盖（3.1）
(10) | ★ | B/S 架构分布式系统，支持横向扩展和服务高可用 | 已覆盖（2.2.3 技术架构）
(11) | 普通 | Docker 容器化部署，支持本地离线安装 | 已覆盖（4.4 软件版本）
(12) | ★ | 跨平台支持 X86 + ARM + Windows/Linux | 已覆盖（2.2.2.4 国产化适配）
(13) | ★ | 支持国产操作系统 + 国产 CPU + 国产数据库 | 已覆盖（2.2.2.4 国产化适配）
(14) | ★ | 松耦合设计，支持高低频/音视频/外部文档数据采集接入，未来可扩展复用 | 已覆盖（2.2.1.3 高并发接入 + 2.1.4 弹性扩展）
(15) | 普通 | 良好的数据服务并发能力 | 已覆盖（2.2.3.4 高并发支撑）
(16) | ★ | 支持国产 CPU 并兼容 X86 | 已覆盖（重复(12)(13)的硬件要求）
(17) | ★ | 支持国产麒麟操作系统 | 已覆盖（重复(13)的操作系统要求）

### 3.3 技术指标分析（13项）

编号 | 指标 | 具体要求 | V1覆盖情况
--- | --- | --- | ---
(1) | 可视化刷新率 | ≤200ms | 已覆盖（3.6 监测大屏提及 200ms）
(2) | 数据生命周期 | ≥10年或20TB追溯；支持自定义同步分发（全量/部分/异构库/文件） | 已覆盖（3.4 备份恢复 + 2.2.1.2 存储）
(3) | 算法类别 | ≥4类：时序、音频、图像、文本算法管理与调度 | 部分覆盖 — V1 仅泛泛提及算法管理，未明确支持4类算法
(4) | 数据格式支持 | ≥2种采集装置SDK协议集成；PDF/Word/Excel导入；XML/CSV/JSON/自定义二进制导入 | 部分覆盖 — V1 提及多协议接入但未明确SDK集成数量和文件格式清单
(5) | 日志追溯 | ≥3年日志记录追溯查询 | 已覆盖（3.3.3 日志配置，操作日志30天归档+90天清理，系统日志15天+MinIO 180天）
(6) | 架构扩展 | B/S架构，横向扩展能力 | 已覆盖（2.2.3 微服务架构）
(7) | 部署方式 | 容器化 + 本地离线部署 | 已覆盖（4.4 Docker 24.0.7）
(8) | OS/硬件 | Windows/Linux + X86/ARM | 已覆盖
(9) | 国产化 | 麒麟OS + 达梦/涛思/庚顿/KaiWuDB | 已覆盖
(10) | 采集能力 | ≥100路 × 10kHz 时序数据持续采集 | 已覆盖（3.6.1 波形实时展示）
(11) | 并发查询 | ≥200QPS 数据查询请求 | 已覆盖（2.2.3.4 高并发支撑）
(12) | 管理终端 | 1台，CPU≥4核/内存≥16G/存储≥512G | 已覆盖（4.1~4.3 设备参数）
(13) | 大屏刷新 | 运行状态数据刷新频率 ≥每秒一次 | 已覆盖（与指标(1) 200ms 一致）

## 4. 审查意见与修改分析

V1 建设方案文档中包含 20+ 条审查意见（标注为 `[ 1:...][已修改]` 格式），以下是关键意见分类分析：

### 4.1 结构性修改意见

位置 | 审查意见 | 修改状态 | 影响分析
--- | --- | --- | ---
目录 | 缺少边端数据处理协同内容，软件设计章节专门功能章节补充 | 待补充 | 核心缺失 — 边端协同是"云-边-端"架构的关键环节，V1 虽有 2.2.1.1/2.2.2.1/2.4.4 提及，但缺乏独立的软件功能章节
目录 | 补充"二次开发支持"章节，特别是算法/模型软件模块的适配开发内容 | 待补充 | 核心缺失 — 平台需要支持外部算法接入和二次开发，但 V1 无任何章节覆盖
1.2 建设原则 | 重新编写，按工程技术类风格实事求是写 | 已修改 | 避免了空洞口号式写法
1.4 建设思路 | 思路统一放到前面讲，这里主要讲具体设计与实现 | 已修改 | 将思路性内容前置，后续章节聚焦具体实现
1.4(5) | 这块内容与前面有很多类似重复，全文认真梳理 | 已修改 | 消除了数据集管理在多处重复描述的问题
2.2.1 总体架构 | 前面已有"架构设计"，又需要"总体架构"？把各层级架构细化描述清晰 | 已修改 | 明确了"架构设计"（原则层）与"总体架构"（实现层）的区别
2.1.5 微服务化设计 | 需要详细说明交互点和交互场景，细化到微服务内部 | 已修改 | 增强了微服务设计的具体性
2.2.2.2 业务数据存储 | 哪里来的设计输入？ | 已修改 | 补充了数据存储设计依据
2.4.4 云边端协同 | 云边端协同的定义技术手段需要补充 | 已修改 | 补充了协同机制的技术细节
3.11 数据服务 | 统一概念，不要一个冒号一个说法，统一为"数据治理" | 已修改 | 规范了术语使用
4.x 硬件要求 | 现在简化，细化到位 | 已修改 | 精简了硬件规格表
2.4.2 业务架构图 | 图按黑白灰色为主重构，提供Visio可编辑版本 | 待提供 | 需要补充Visio源文件
2.2.1.2 数据处理与存储 | 国产化支持列中标注为"?"未填 | 待确认 | 表格中的国产化支持状态未明确
2.5 建设思路 | 不过分夸大功能效果 | 已修改 | 避免了过度承诺
3.4 备份与恢复 | 虽然是之前按照合同规范写的，但应符合企业实际场景未真正开展过 | 待确认 | 备份恢复方案是否经过实际验证
3.11 数据驾驶舱 | 改为"数据可视化" | 已修改 | 术语调整

关键待办项：

- 边端数据处理协同 — 软件功能设计缺少独立章节（审查意见#1）
- 二次开发支持 — 缺少算法/模型适配开发内容（审查意见#2）
- Visio源文件 — 所有架构图需提供可编辑版本
- 国产化支持确认 — 存储选型表中的"?"需要填写
- 4类算法管理 — 技术指标(3)要求时序/音频/图像/文本，V1未细化
- SDK协议集成 — 技术指标(4)要求≥2种采集装置SDK，V1未明确

## 5. 交叉点与新增点识别

### 5.1 交叉点（V1方案与新增需求的重叠与差异）

交叉领域 | V1方案描述 | 新增需求描述 | 差异分析
--- | --- | --- | ---
数据集管理 | 建设思路(5)中提及，但未在软件功能目录中设独立章节 | 功能(5)明确要求：数据集抽取、管理、标记、导入、实时/历史查看、属性标注、可视化展示、订阅分发 | 新增需求更具体，V1只有概念性描述，缺少功能设计细节
算法管理 | 建设思路(8)提及算法资源管理；3.9模型管理与算法有关联但概念混杂 | 功能(6)明确：算法资源管理、任务配置、计算任务管理、算法上传与复用、任务编排、可视化调度监控；技术指标(3)要求支持4类算法 | 模型管理 vs 算法管理边界模糊，V1 中算法相关功能散落在模型管理和任务管理中
大屏数据项管理 | 建设思路(8)详细描述了大屏数据项配置化管理 | 功能(4)作为★项要求数据项管理服务，支持清单导入、调用地址管理 | V1 有描述但缺少独立软件功能章节，需要在软件功能设计中补充独立章节
数据采集 | 2.2.1.3 描述ZeroMQ+MQTT双协议接入；3.7配置管理涉及设备/通道/采集配置 | 功能(7)要求：事件/状态/音视频采集建模、SDK协议集成、工况/结果文件接入、原始数据赋予业务语义、流式+批处理 | 新增需求强调边端协同和SDK集成，V1侧重云端接收，缺少边端处理流程
数据治理 | 3.12 数据服务下有完整的数据治理管理子模块（标准/元数据/质量/清洗） | 任务组成明确平台核心功能之一是"数据治理构建标准化、可信可复用的业务数据资产" | V1 已有完整覆盖，术语已统一为"数据治理"（审查修改后）
管理终端 | 4.1~4.3 有端/边/云设备参数要求，但侧重服务器 | 技术指标(12)明确要求提供1台管理终端（CPU≥4核/内存≥16G/存储≥512G） | V1 的设备参数表中端设备要求（4核/16G/512G）与新增需求一致，但需要明确"管理终端"的独立交付身份

### 5.2 新增点（仅在新增需求中出现，V1未覆盖的内容）

新增点 | 来源 | 详细解读
--- | --- | ---
边端数据处理协同 | 审查意见#1 + 功能(7) | V1 的 2.4.4 云边端工作协同只讲了架构概念，缺少软件功能层面的实现。需要在软件功能设计章节中补充：边缘侧数据预处理、边云任务协同调度、边缘算法部署与更新、边端数据缓存与断网续传等功能。
二次开发支持 | 审查意见#2 | 平台需要提供 SDK/API 供外部开发者接入自定义算法和模型。包括：算法接入规范、模型适配指南、二次开发文档、示例代码、调试工具等。特别是算法/模型软件模块的适配开发内容需详细给出。
4类算法管理与调度 | 技术指标(3) | V1 仅泛泛提及算法管理，未明确支持哪些算法类型。新增需求明确要求：时序算法、音频算法、图像算法、文本算法，至少4类。每类算法的上传、注册、版本管理、任务编排、执行监控需要差异化设计。
采集装置SDK协议集成 | 技术指标(4) | 明确要求 ≥2 种数据采集装置的 SDK 协议集成。V1 只提到 ZeroMQ 和 MQTT 两种传输协议，但未提及具体采集硬件的 SDK 集成。
数据同步分发能力 | 技术指标(2) | 支持数据的自定义同步分发，包括：全量分发、部分分发、异构数据库分发、文件分发。V1 未提及此能力。
原始数据赋予业务语义 | 功能(7) | 采集的原始数据需要映射为有业务含义的结构化数据（如测点编号→设备部位→监测指标→故障类型）。V1 的 3.1.4 数据字典有基础支撑，但缺少完整的业务语义映射功能设计。
管理终端独立交付 | 技术指标(12) | 明确要求提供1台管理终端硬件。V1 虽在 4.1 端设备参数中有类似规格，但没有以"交付物"角度明确管理终端的独立身份。

## 6. 技术栈与关键指标总览

### 6.1 完整技术栈

    前端层:  Vue3 + Element Plus + ECharts (B/S架构)
    网关层:  Nginx 1.25.0 (反向代理 + 负载均衡)
    微服务:  Spring Cloud (JDK 11.0.13)
      ├─ 数据接收服务    ├─ 数据资源服务    ├─ 数据集服务
      ├─ 文件资源服务    ├─ 算法任务服务    ├─ 大屏数据项服务
      ├─ 接口服务        ├─ 权限认证服务    ├─ 日志审计服务
      └─ 运行监控服务

    数据存储:
      ├─ 时序库:  涛思 TDengine / KaiWuDB 3.2.0
      ├─ 关系库:  达梦 8.1.3.140+ / 庚顿 / KaiWuDB
      ├─ 对象存储: MinIO
      ├─ 缓存:    Redis 7.2.3
      └─ 检索:    Elasticsearch

    消息中间件:
      ├─ ZeroMQ 4.3.2 (高频时序数据, C++端)
      └─ EMQX 5.1.6 (MQTT Broker, 低频业务数据)

    运维监控:
      ├─ Node Exporter (硬件指标采集)
      ├─ cAdvisor (Docker容器监控)
      ├─ Actuator + Micrometer (微服务健康端点)
      ├─ SkyWalking (分布式链路追踪)
      └─ Filebeat → Elasticsearch (日志采集与存储)

    部署: Docker 24.0.7 + Docker Compose (离线安装)
    系统: Ubuntu 20.04/22.04 LTS / 麒麟 v10
    架构: X86 / ARM 双架构兼容

### 6.2 关键性能指标

指标项 | 要求 | 对应技术
--- | --- | ---
可视化刷新率 | ≤200ms | WebSocket 全双工 + Redis 缓存
数据查询并发 | ≥200 QPS | Redis 缓存 + 分类型存储
时序数据采集 | ≥100路 × 10kHz | ZeroMQ + C++ 高频采集模块
数据生命周期 | ≥10年或20TB | 时序库压缩 + MinIO对象存储
日志追溯 | ≥3年 | ES存储 + 差异化归档策略
算法类别 | ≥4类（时序/音频/图像/文本） | 算法任务服务 + 容器化执行
SDK协议集成 | ≥2种采集装置SDK | 待补充实现

## 7. 总结与后续建议

### 7.1 方案整体评价

V1 建设方案在数据接入、存储、服务、微服务架构、国产化适配等方面已有较完整的设计，审查意见大部分已修改到位。核心问题在于：

1. 边端协同缺失 — 作为"云-边-端"架构平台，缺少边端数据处理协同的独立功能章节
2. 二次开发空白 — 没有算法/模型二次开发支持的章节内容
3. 概念与实现混淆 — 部分"建设思路"中的功能点（数据集管理、大屏数据项管理、算法管理）未在软件功能设计中落地为独立章节
4. 硬件交付物未明确 — 管理终端作为独立交付物需要单独说明

### 7.2 建议后续动作

- 补充边端协同章节 — 在软件功能设计第3章新增"边端协同管理"小节，覆盖边缘数据预处理、边云任务调度、边缘算法部署
- 新增二次开发支持章节 — 作为附录或独立文件，详细描述算法/模型适配开发的 SDK 规范、接入流程、调试工具
- 将"建设思路"功能点落地 — 数据集管理、大屏数据项管理、算法资源管理应从建设思路下沉到软件功能设计章节
- 明确管理终端交付 — 在交付物清单中明确管理终端的规格、用途和验收标准
- 提供Visio源文件 — 所有架构图按黑白灰配色重构后提供可编辑版本
- 填写国产化支持表 — 存储选型表中的"?"标记需要补充确认

报告生成日期：2026-05-12 | 基于 V1 建设方案（2026年4月）+ 新增需求文档分析