深度分析 工程指南 调研研究
本报告对 沈阳顺义-数据-项目建设方案 目录下的两份文档进行深度解读：
方案包含 两大交付物：
B/S 架构的分布式数据服务平台，包含完整的后端微服务、前端页面、数据存储与接口体系。采用 Spring Cloud + Vue3 技术栈，Docker 容器化部署。
硬件设备，规格：CPU ≥4核、内存 ≥16G、存储 ≥512G。用于平台管理和运维操作。
| 模块 | 核心功能点 | 关键技术 |
|---|---|---|
| 系统管理 | 用户管理、组织架构、角色权限（业务角色/管理角色分离）、数据字典 | 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 |
| 存储类型 | 存储内容 | 技术选型 |
|---|---|---|
| 时序数据库 | 状态数据、实时监测指标、历史趋势数据 | 涛思 TDengine / KaiWuDB |
| 关系型数据库 | 设备信息、测点信息、用户权限、接口配置、数据集信息 | 达梦 / 庚顿 / KaiWuDB |
| 对象存储 | 故障波形文件、特征数据、仿真模型、音视频、文档资料 | MinIO |
| 缓存服务 | 热点数据、实时快照、临时查询结果 | Redis 7.2.3 |
| 检索服务 | 数据标签、关键字、故障类型、任务编号 | Elasticsearch |
| 数据类型 | 协议 | 语言 | 特点 |
|---|---|---|---|
| 高频时序数据 | ZeroMQ（发布-订阅） | C++ | 高性能、低时延、端到端、无中间代理 |
| 低频业务数据 | MQTT | Java | 轻量级、异步连接、消息持久化、断点续传 |
| 编号 | 优先级 | 需求内容 | 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)的操作系统要求） |
| 编号 | 指标 | 具体要求 | 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 一致） |
V1 建设方案文档中包含 20+ 条审查意见（标注为 [ 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 数据驾驶舱 | 改为"数据可视化" | 已修改 | 术语调整 |
| 交叉领域 | 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）与新增需求一致，但需要明确"管理终端"的独立交付身份 |
| 新增点 | 来源 | 详细解读 |
|---|---|---|
| 边端数据处理协同 | 审查意见#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 端设备参数中有类似规格，但没有以"交付物"角度明确管理终端的独立身份。 |
前端层: 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 双架构兼容
| 指标项 | 要求 | 对应技术 |
|---|---|---|
| 可视化刷新率 | ≤200ms | WebSocket 全双工 + Redis 缓存 |
| 数据查询并发 | ≥200 QPS | Redis 缓存 + 分类型存储 |
| 时序数据采集 | ≥100路 × 10kHz | ZeroMQ + C++ 高频采集模块 |
| 数据生命周期 | ≥10年或20TB | 时序库压缩 + MinIO对象存储 |
| 日志追溯 | ≥3年 | ES存储 + 差异化归档策略 |
| 算法类别 | ≥4类（时序/音频/图像/文本） | 算法任务服务 + 容器化执行 |
| SDK协议集成 | ≥2种采集装置SDK | 待补充实现 |
V1 建设方案在数据接入、存储、服务、微服务架构、国产化适配等方面已有较完整的设计，审查意见大部分已修改到位。核心问题在于：