数据集成技术架构：面向工业物联网的分层设计与落地方案

数据集成技术架构技术架构总览

整体架构图怎么设计

工业物联网项目可采用六层模型：设备接入层、数据层、平台层、服务层、应用层和运维安全层。

设备接入层连接PLC、DCS、SCADA、传感器、机器人、数控机床及能源仪表。

数据层负责采集、清洗、转换、存储和治理，统一处理结构化与非结构化数据。

平台层承载消息队列、规则引擎、任务调度、设备管理、模型计算和数据服务。

服务层通过API、事件订阅、文件交换和数据库同步，为业务系统提供标准接口。

应用层面向生产、质量、能源、设备和经营分析，形成可被业务人员直接使用的功能。

运维安全层覆盖身份认证、访问控制、日志审计、监控告警、备份和容灾。

企业绘制架构图时，不应只画产品名称，还要标出数据方向、协议边界和安全域。

一张可用于项目实施的架构图，至少需要表达以下内容：

数据从哪些设备和系统产生；
数据通过什么协议进入平台；
实时链路与离线链路如何划分；
数据保存在哪里，保存多长时间；
哪些系统能够查询、订阅或修改数据；
单点故障发生后如何恢复。

架构图的价值不是展示技术数量，而是明确数据责任和系统边界。

各层职责如何划分

设备接入层不承载复杂业务规则，重点解决协议适配、连接管理和边缘缓冲。

数据层不直接实现生产业务，重点保证数据完整、一致、可追踪和可查询。

平台层不绑定某个前端应用，而是提供通用能力，减少MES、EAM和能源系统重复建设。

应用层应通过标准接口取数，不建议直接连接生产数据库或设备控制网络。

运维层需要横跨所有组件，统一采集指标、日志、链路追踪和安全事件。

如果层与层之间没有明确边界，项目后期常会出现接口重复、数据口径冲突等问题。

例如，同一台设备的状态判断被写在采集程序、数据库和MES中，修改一次要改三处。

更合理的做法是把状态计算放入规则服务，并通过事件和API向业务系统输出。

技术选型遵循哪些原则

选型不能只看功能清单，还要核对吞吐量、延迟、协议数量和运维成本。

工业现场可重点评估以下指标：

单节点每秒可接收的数据点数量；
断网后边缘侧可缓存的数据时长；
消息重复、乱序和丢失时如何处理；
集群扩容是否需要停止生产；
是否支持国产操作系统和国产数据库；
协议驱动升级会不会影响现有连接；
软件授权按节点、设备还是数据点收费。

实时控制数据通常要求毫秒级响应，不宜跨公网进入中心平台后再执行控制。

生产分析和经营报表可接受秒级或分钟级延迟，更适合采用中心化处理。

控制闭环留在边缘，分析计算放在中心，是工厂常用的责任划分。

技术栈也不宜过度复杂。中型项目没有必要同时引入多套消息队列和三种数据库。

每增加一个基础组件，都意味着新增安装、升级、备份、监控和人才成本。

采购经理问“多少钱”时，不能只计算许可证，还要加入服务器、实施和三年运维费用。

实时与离线链路如何协同

实时链路适合设备告警、状态变化、质量异常和能源越限等事件。

数据通常经过边缘网关、消息中间件、流计算服务，再写入时序库或推送应用。

离线链路适合日报、月报、历史追溯、模型训练和跨系统经营分析。

数据可按小时或天进入数据湖，通过批处理任务完成清洗、聚合与主题建模。

两条链路不能各自维护一套口径。设备编码、时间标准和指标公式需要统一管理。

可以建立公共数据模型，让实时服务和离线任务引用同一份元数据。

事件时间应以设备实际产生时间为准，平台接收时间用于判断网络和处理延迟。

对乱序事件，可设置30秒、2分钟或更长的等待窗口，具体取决于现场网络质量。

—

数据集成技术架构数据层架构

数据采集方案

工业数据采集要同时处理设备协议、业务数据库、文件和第三方接口。

设备侧常见协议包括OPC UA、Modbus TCP、PROFINET、EtherNet/IP和MQTT。

业务系统常通过JDBC、REST API、Web Service、CSV或消息队列交换数据。

采集架构可以分为边缘采集、中心采集和混合采集三种模式。

边缘采集把协议驱动部署在车间，可降低网络中断对生产数据的影响。

中心采集便于统一管理，但跨厂区网络异常时容易出现数据缺口。

混合模式在边缘完成协议转换和缓存，在中心完成治理、存储和服务发布。

多工厂项目优先采用边缘加中心的两级采集结构。

边缘节点需要配置本地缓存。缓存容量可按点位数、频率和断网时长计算。

例如，2万个点位每秒采集一次，每条记录按100字节估算。

一天原始数据量约为172.8GB，考虑索引和副本后还需预留更多空间。

并非所有点位都要每秒上报。温度可每5秒采集，开关状态可采用变化上报。

高频振动数据可在边缘提取均方根、峰值和频谱特征，避免原始波形全部上传。

采集程序应支持断点续传、批量补传、限速和优先级队列。

告警事件的优先级应高于普通遥测数据，防止网络拥塞时关键事件排队。

采集质量控制

采集不是把数据写入数据库就完成了，还需要判断数据是否可信。

平台可对每个数据点附加质量码，标记正常、超时、无效、补传和人工修改。

对超出物理范围的数据，可拒绝写入，也可保留原值并增加异常标记。

对长时间不变化的数据，需要区分设备稳定运行和传感器卡死。

判断逻辑可结合设备运行状态、相邻传感器数值和历史变化率。

时间戳要统一到毫秒或微秒，并明确采用UTC还是工厂本地时区。

跨国工厂应统一保存UTC时间，展示时再转换为当地时间。

设备时钟偏差超过设定阈值时，平台应告警，而不是静默修正所有记录。

数据存储设计

工业平台很难依靠一种数据库处理全部场景，通常需要多类型存储协同。

时序数据库保存设备遥测数据，关系数据库保存配置、工单和主数据。

对象存储适合图片、视频、波形文件、模型文件和长期归档数据。

搜索引擎适合全文检索、日志查询和复杂条件筛选。

数据湖可保存原始数据、清洗数据和主题数据，为算法训练提供历史样本。

存储选型要根据写入速度、查询方式、压缩率、保留周期和恢复目标决定。

每秒数十万条写入的遥测数据，不应直接写入传统业务数据库的单张明细表。

可采用时间分区、设备分片和冷热分层，控制单表规模与查询扫描范围。

热数据保存最近7天或30天，放在高性能存储中。

温数据保存3个月至1年，可降低副本数量或迁移到成本更低的磁盘。

冷数据进入对象存储，按工厂、产线、设备和日期组织目录。

保留周期必须与追溯要求、法规要求和存储预算一起确定。

数据模型与编码体系

设备编码是数据关联的基础，不能由各项目组自行命名。

建议采用“集团—工厂—车间—产线—设备—部件—测点”的层级模型。

设备编码应保持稳定，设备更名或移动位置时不宜重新生成唯一标识。

物理位置、业务名称和唯一编码应分开保存，避免名称变化破坏历史关联。

测点模型至少包含单位、数据类型、采样频率、精度和上下限。

同一类设备可建立模板，新设备接入时复用测点定义和告警规则。

模型版本需要保留生效时间，便于解释历史数据为何采用不同计算口径。

数据治理策略

数据治理应落到元数据、主数据、质量规则、血缘和责任人五个对象。

元数据说明字段含义、来源系统、更新时间和使用限制。

主数据统一设备、物料、组织、人员和供应商编码。

质量规则检查完整率、及时率、唯一性、准确性和一致性。

血缘关系记录数据从设备到报表经历了哪些转换和计算。

每个核心数据对象都应指定业务负责人和技术负责人。

业务负责人确认指标含义，技术负责人保障采集、存储和服务稳定。

平台可以设置质量评分，例如完整率低于99%时自动创建治理任务。

治理结果应进入采购和验收指标，不能只在方案文件中描述。

—

数据集成技术架构平台层架构

微服务架构设计

平台层可按业务能力拆分为设备、连接、规则、数据、告警和用户等服务。

每个微服务拥有清晰的接口和数据责任，避免多个服务直接修改同一张表。

设备服务维护设备模型、属性和生命周期。

连接服务管理采集通道、会话、心跳和协议参数。

规则服务处理阈值、组合条件、状态机和事件联动。

数据服务提供查询、聚合、订阅和导出能力。

告警服务负责告警生成、确认、升级、关闭和通知。

服务拆分不应追求数量。十人团队维护上百个微服务，成本通常会失控。

可以先采用模块化单体，再把高并发或独立扩容的模块拆成微服务。

拆分依据是变化频率、负载差异和故障边界，而不是代码行数。

服务间同步调用可使用REST或gRPC，异步协作可使用事件总线。

同步链路不宜过长。一个请求连续调用五个服务，任一环节超时都会影响结果。

可设置统一超时、重试和熔断策略，防止局部故障扩散到整个平台。

重试必须考虑幂等性。创建工单接口重复调用时，不能生成多张相同工单。

服务注册与配置管理

微服务集群需要服务注册、健康检查和配置中心。

服务启动后注册地址，调用方通过服务名称发现可用实例。

健康检查应覆盖进程、端口、数据库连接和消息队列连接。

只检查进程存活并不够，进程存在也可能无法正常提供服务。

配置中心统一保存连接参数、阈值和功能开关，减少人工修改配置文件。

敏感配置不能明文保存，数据库密码和证书私钥应加密或托管在密钥系统中。

配置变更需要审批、版本记录和回滚能力。

生产环境禁止未经审核的自动刷新，关键配置可安排维护窗口生效。

消息中间件选型

消息中间件连接采集、计算、存储和应用，是实时链路的关键组件。

选型时要比较吞吐量、顺序性、可靠性、延迟、积压能力和运维难度。

MQTT适合设备连接，支持轻量发布订阅和不同服务质量等级。

Kafka适合大吞吐数据流、日志流和历史消息回放。

RabbitMQ适合复杂路由、任务队列和业务事件分发。

企业可在设备侧使用MQTT，在平台内部使用Kafka，但要控制组件数量。

关键事件应配置持久化、副本和确认机制，普通遥测可采用更高吞吐策略。

消息主题要制定命名规范，不应由开发人员临时创建。

主题可包含环境、工厂、业务域和事件类型，但不宜包含设备唯一编号。

设备数量达到十万级时，按设备创建主题会增加管理和元数据压力。

事件模型与一致性

平台内部应建立统一事件结构，包括事件编号、来源、类型和发生时间。

事件还应带有数据版本、追踪编号和载荷格式，便于定位处理链路。

同一消息可能因网络重试被消费多次，消费者需要基于事件编号去重。

跨服务事务可采用本地事务加事件表，或采用Saga模式进行补偿。

工业业务不宜轻易采用强一致分布式事务，否则延迟和故障处理会更复杂。

设备状态、实时看板允许秒级最终一致，财务结算则需要更严格的校验。

一致性等级要按业务风险定义，不能对所有数据采用同一种方案。

缓存与性能优化

缓存适合设备基础信息、字典、权限、热点指标和短时间聚合结果。

不建议缓存频繁变化且要求强一致的数据，否则失效策略会变得复杂。

Redis可用于分布式缓存、限流、会话和短期状态保存。

缓存键需要包含租户和业务域，防止不同工厂的数据相互覆盖。

可设置5分钟、30分钟或1小时过期时间，并根据访问频率动态调整。

高频查询接口应限制时间范围和返回数量，避免一次读取数亿条明细。

趋势图不需要返回每个原始点，可按像素宽度进行降采样。

例如，图表宽度为1200像素，返回2000至5000个点通常已经足够。

数据库可通过分区、索引、预聚合、读写分离和连接池提升性能。

索引不是越多越好。每增加一个索引，写入和存储成本都会上升。

性能测试应模拟真实点位数、查询范围、并发用户和消息积压。

验收指标要写成数字，例如每秒写入20万点、接口P95低于500毫秒。

任务调度与计算引擎

批量同步、数据修复、日报生成和模型训练需要统一任务调度。

调度平台应支持依赖关系、失败重试、超时终止和补数操作。

任务状态要可视化，不能依靠运维人员登录服务器查脚本日志。

流计算用于实时窗口聚合、异常检测和事件关联。

批计算用于长周期统计、历史回算和大范围数据清洗。

同一指标应共享计算定义，避免流任务和批任务计算出不同结果。

大规模补算应设置资源配额，防止占满CPU和存储带宽。

—

数据集成技术架构应用层架构

前端技术方案

应用层前端通常包括管理后台、生产看板、移动端和大屏。

管理后台适合采用Vue或React，便于组件化开发和长期维护。

生产看板要控制刷新频率，不能每秒对数据库发起数百次查询。

更合理的方式是通过WebSocket或服务端推送增量数据。

趋势图应支持时间选择、缩放、对比和数据质量标记。

设备拓扑图要与设备模型关联，不能把点位名称直接写死在页面代码中。

大屏分辨率和显示距离需要提前确认，避免上线后文字无法看清。

移动端适合告警确认、巡检和工单处理，不宜复制全部桌面功能。

弱网环境下应支持本地草稿、断点上传和数据同步。

前端只负责展示与交互，业务规则应放在后端服务。

应用模块如何解耦

生产、设备、质量和能源应用可能使用同一批设备数据。

各应用不应分别建设采集链路，而应通过统一数据服务获取。

公共组件可包括组织树、设备树、时间选择器和告警列表。

业务模块通过配置引用公共组件，减少重复开发和维护。

页面与接口之间可增加BFF层，为不同终端组合所需数据。

BFF不应复制核心业务逻辑，主要负责聚合、裁剪和协议转换。

插件化架构适合多工厂差异场景，但插件边界和升级机制要提前定义。

如果每个工厂都修改主代码，版本最终会分裂，升级成本会快速增加。

API设计规范

API可采用REST、GraphQL或gRPC，具体选择取决于调用对象和数据形式。

对外开放接口通常采用REST，内部高频调用可采用gRPC。

接口路径应包含版本，例如“/api/v1/devices”，避免升级破坏现有应用。

请求和响应字段要采用统一命名规范，并明确时间、单位和空值处理方式。

分页接口需要限制最大页大小，例如每页不超过1000条。

批量接口要设置数量上限，防止单次请求占用过多内存。

错误响应应包含错误码、提示信息和追踪编号。

不能只返回“系统错误”，否则用户和运维人员都无法定位原因。

写入接口应支持幂等键，避免网络重试导致重复工单或重复告警。

接口文档可通过OpenAPI生成，并提供在线调试和示例数据。

外部合作方接入时，应配置调用频率、数据范围和有效期。

数据服务发布

平台不应把底层数据库账号直接提供给业务系统。

数据库直连会绕过权限、审计、限流和数据模型，后续改表也容易影响应用。

标准做法是通过API、订阅、数据产品或受控文件交换发布数据。

实时事件可采用消息订阅，历史明细可采用分页查询或异步导出。

大数据量导出不应在HTTP请求中等待完成，可转为后台任务。

任务完成后生成带有效期的下载地址，并记录下载人和下载时间。

数据产品应说明字段定义、刷新周期、质量等级和责任人。

对外共享前还要完成脱敏，设备参数、人员信息和商业数据应分类处理。

权限与安全机制

权限模型可采用RBAC，并叠加工厂、车间和设备范围控制。

角色决定用户能做什么，数据范围决定用户能看到哪些对象。

集团管理员可以查看多工厂数据，车间人员只能访问本车间设备。

关键操作需要二次确认，例如远程控制、配置下发和告警规则停用。

远程控制指令应经过审批、签名、超时和结果确认。

平台账户应支持统一身份认证、单点登录和多因素认证。

服务间调用可使用短期令牌或双向TLS，不宜共享长期固定密码。

敏感字段应加密保存，传输链路应启用TLS。

日志中不能记录完整密码、令牌、身份证号和其他敏感信息。

安全审计要记录登录、查询、导出、配置修改和权限变更。

工业平台的权限设计要同时保护数据访问和设备操作。

应用验收指标

应用层验收不能只检查页面是否打开，还要验证稳定性和业务闭环。

看板可定义5秒内完成首屏加载，实时数据延迟不超过3秒。

查询接口可定义P95响应时间、最大并发和超时比例。

告警功能需要验证生成、通知、确认、升级和关闭流程。

权限测试要覆盖越权访问，确认低权限用户无法修改高权限数据。

导出功能需要测试百万级数据量下的任务稳定性。

移动端要测试弱网、断网、重复提交和照片上传失败场景。

验收环境的数据规模应接近生产规模，不能只用几百条测试记录。

—

数据集成技术架构部署架构与运维

部署方案选择

部署方式包括本地部署、私有云、公有云和混合云。

涉及生产控制、低延迟和敏感数据的服务，通常部署在工厂或企业私有云。

跨工厂分析、统一运营和算法训练可部署在集团数据中心。

混合部署需要明确哪些数据上传，哪些数据只能留在本地。

容器化适合微服务交付，可统一运行环境、版本和资源限制。

Kubernetes适合节点较多、服务数量较多且需要弹性扩容的项目。

小规模项目如果只有十几个服务，也可采用虚拟机加自动化脚本。

部署方案要匹配团队能力，复杂平台不等于更低运维成本。

生产环境、测试环境和开发环境必须隔离。

测试程序不能连接生产设备，也不能使用生产控制权限。

不同环境的数据库、消息队列、证书和账号应独立配置。

边缘节点可采用双网口，一侧连接设备网络，一侧连接平台网络。

网络策略应限制访问方向，平台不能默认访问所有PLC端口。

跨安全域传输可通过工业防火墙、网闸或受控代理完成。

高可用部署设计

核心服务应避免单节点部署，包括数据库、消息队列和注册中心。

无状态服务可部署两个以上实例，通过负载均衡分配请求。

有状态服务需要配置主从、集群或副本机制。

高可用不是简单增加服务器，还要验证故障切换是否真的有效。

数据库主节点宕机后，应用连接能否自动切换，需要通过演练确认。

消息节点故障时，未确认消息是否会重发，也要纳入测试。

边缘采集节点可配置主备，但要防止两台同时采集造成数据重复。

可以采用租约、心跳和唯一实例锁控制主节点身份。

监控与日志体系

监控对象应覆盖基础设施、中间件、服务、数据链路和业务指标。

基础设施指标包括CPU、内存、磁盘、网络和温度。

中间件指标包括消息积压、消费延迟、连接数和数据库慢查询。

服务指标包括请求量、错误率、响应时间和线程池使用率。

数据链路指标包括采集点在线率、数据延迟和补传数量。

业务指标包括在线设备数、未处理告警数和工单执行时长。

可采用指标、日志和链路追踪三类信息联合定位问题。

单看日志往往无法判断问题出在哪个服务。

统一追踪编号可以串联接口、消息、数据库和外部系统调用。

日志需要结构化输出，包含时间、服务、实例、级别和追踪编号。

告警要设置分级，避免所有异常都通过短信通知。

P1告警可要求5分钟内响应，P2告警可要求30分钟内处理。

告警规则应设置持续时间，CPU瞬间升高不必立即通知全部人员。

运维流程与发布管理

版本发布需要经过构建、测试、扫描、审批和部署流程。

人工复制安装包容易产生版本不一致，也难以快速回滚。

可建立CI/CD流水线，统一生成镜像、配置清单和变更记录。

生产发布可采用滚动升级、蓝绿发布或金丝雀发布。

采集服务升级时，要评估连接重建和数据丢失风险。

数据库变更应向前兼容，避免新旧服务并行期间字段不一致。

每次发布都要准备回滚条件、回滚步骤和责任人。

发布完成后应检查关键接口、消息积压和设备在线率。

运维手册需要写清服务启动、停止、扩容和故障处理方法。

采购验收时可要求供应商提供架构文档、部署清单和应急预案。

容灾与备份策略

容灾需要明确RPO和RTO，而不是简单写“支持备份”。

RPO表示最多允许丢失多少数据，RTO表示业务多久恢复。

核心生产数据可设定RPO不超过5分钟，RTO不超过30分钟。

普通历史报表可接受更长时间，具体数值由业务损失决定。

数据库可采用全量备份加增量日志，配置每日、每周和每月策略。

对象存储应配置版本控制或跨区域复制，防止误删除。

消息数据是否长期保留，要根据回放和追溯需求确定。

边缘节点断网期间需本地缓存，恢复后按时间顺序补传。

备份文件必须定期恢复验证，能生成备份不代表能够成功恢复。

可每季度执行一次恢复演练，并记录耗时、数据完整率和问题项。

异地容灾要考虑专线中断、区域停电和账号系统不可用等情况。

项目容量与成本测算

服务器数量应从数据规模和可用性目标推算，不能只按当前用户数采购。

容量测算至少需要点位数、采样频率、单条大小、保留周期和副本数。

假设5万个点位每5秒上报一次，每秒约产生1万条记录。

每条记录按100字节计算，每天原始数据约86.4GB。

采用三副本并加入索引后，实际空间可能达到原始量的3至5倍。

压缩率与数据类型有关，采购前应使用真实样本进行测试。

计算资源还要考虑规则数量、查询并发、报表周期和算法任务。

硬件预算之外，还需计算操作系统、数据库和中间件授权。

实施费用通常包括协议开发、数据建模、接口对接和现场调试。

运维费用包括升级、巡检、备件、培训和安全整改。

供应商报价差异较大时，应按相同容量、可用性和服务范围比较。

问“多少钱”之前，先把点位规模、保留周期和容灾等级写清楚。

供应商技术评估要点

企业决策者应要求供应商提供可验证的性能报告，而不是只看演示页面。

报告需要说明测试硬件、数据模型、写入频率、查询范围和并发数量。

协议支持要区分原生驱动、第三方插件和定制开发。

原生支持通常升级更稳定，定制协议则要确认源代码和维护责任。

采购合同可约定接口开放范围，避免后期按接口重复收费。

还要确认数据能否完整导出，防止平台更换时无法迁移。

技术负责人可安排概念验证，用真实设备和真实网络运行2至4周。

测试内容应包括断网补传、节点宕机、消息积压和数据库恢复。

验收标准应数字化，并写入合同附件。

架构可扩展性、数据可迁移性和故障恢复能力，都会影响五年以上成本。

常见问题