基于物联网的大数据采集与存储技术解决方案

2021-12-02林希佳吴成庆

科学技术创新 2021年32期

秦磊林希佳周轩郭磊王路吴成庆王娜

（江苏金陵智造研究院有限公司，江苏南京 210001）

近年来，随着信息化水平的不断提升，不同类型的智能设备已经广泛应用于智能制造领域、智慧园区领域中，企业管理者对这两大领域内现场状况的掌控要求越来越高。尤其是随着工业互联网、大数据及物联网的蓬勃发展，迫切要求生产车间、工业园区提升信息化管理水平，为管理者掌控现场综合情况提供助益。以工业园区为例，园区内设备种类较多，但缺乏人与物、物与物间的智能联动，且分散在各个地方，缺乏有效的状态数据采集渠道，用户无法直接与园区进行交互，缺乏有效的用户体验反馈渠道。对于工业园区行业的管理者来说，如何快速定位设备位置，如何查看设备使用情况，设备故障后如何快速定位设备故障点从而第一时间进行维修等，这些问题的深入研究及解决方法都需要以从设备采集大量实时数据为基础。

工业园区现场，一般都会有来自不同厂商品牌的设备，且设备类型多元化，例如有各类传感器、摄像头、巡检小车等等，通信方式各不相同，各种因素给园区信息化之路带来不小的阻力。

针对这一现状，本文研究探讨一种多源设备大数据量实时数据采集存储的方法。该方法结合我司项目实际情况开展，借助于互联网，实现物联网平台与数千台设备间的通信，设备大多数为模具状态监控设备，另含一部分传感器、摄像头及小车，远程采集设备的相关坐标位置、耗电量、故障信息等数据，并实现数据的实时稳定存储，为后续借助互联网平台实现大数据分析提供数据支撑。

1 物联网平台数据采集方式

物联网平台类型繁多，主要包括以下四类：第一类是提供连接性管理的物联网平台；第二类是以提供云服务为主的应用开发平台；第三类是以接入智能装置为主的应用开发平台；第四类是以大数据分析和机器学习为主的物联网平台。基于本文研究的实际情况，以第三类物联网平台为依托，接入多源设备进行实时采集存储，为大数据分析提供数据支撑。数据采集方式主要分为以下两类。

1.1 间接接入。现场设备种类较多时，使用工业数据采集网关将设备按适配协议接入，网关使用Mqtt 服务进行数据传输，物联网平台端启用Mqtt 服务端组件读取网关传输的数据，数据流如图1 所示。

图1 间接接入方式

1.2 直接接入。直接接入方法使用现场设备通讯协议比较简单且单一的情况，现场设备与物联网平台通过网线连接，以以太网方式传输数据至平台端，平台端开启通信协议服务组件接收设备传递的数据，并利用Kafka 进行数据接收处理，数据流如图2 所示。

图2 直接接入方式

2 数据采集内容与要求

2.1 数据实时性、准确性、稳定性及安全性

对于实时采集的数据，以1s 的采集周期采集所需数据。对于更新速率较慢的数据，例如设备耗电量等数据，可采用15min的采集周期。

采集的数据确保与实际状态数据一一对应，保证传输数据的准确性；稳定性方面，采集的数据日丢失率不高于0.1%；安全性方面，通过链路加密协议等确保数据的安全。

2.2 采集的数据内容

多类型设备数据采集，主要采集的设备类型如下所述：

2.2.1 国标/非国标摄像头；

2.2.2 传感器，例如温湿度、压力传感器等；

2.2.3 其他类型设备，例如巡检小车、模具状态监控设备等。

2.3 数据存储要求及方式

支持PB 级以上数据存储，可使用非关系型数据库进行设备实时消息存储，该类数据库且支持行列混合存储。

3 数据采集架构设计

为满足大数据实时采集、存储，本文使用一种响应式编程框架，提升数据采集性能，具体技术架构如图3 所示。采集到的数据通过网关进行接收、推送、实时处理，最终存储至数据库中，数据库采用redis+Elasticsearch+mysql 相结合的方式进行。

图3 技术架构图

3.1 Project Reactor 技术简介

Project Reactor 是一个运行在JVM上的反应式编程基础库，以“背压”的形式管理数据处理，提供了可组合的异步序列API Flux 和Mono。Reactor 大大降低了异步编码难度，Reactor 反应库拥有如下特点：

3.1.1 可组合性和可读性；

3.1.2 以流的形式进行数据处理，为流中每个节点提供了丰富的操作性；

3.1.3 在Subscribe 之前，不会有任何事情发生；

3.1.4 支持背压，消费者可以向生产者发出信号表面排放率过高；

3.1.5 支持两种反应序列：hot 和cold。

3.2 数据采集框架设计

多源化设备接入及大数据量设备消息实时采集、存储是本课题实现的核心，业务框架如图4 所示。

图4 业务架构设计图

使用网络组件管理各种网络服务（MQTT、TCP 等），只负责接收/发送报文，不处理逻辑；使用接口协议进行自定义消息解析，处理报文数据；使用设备网关将设备接入，并将设备消息推送至事件总线；使用事件总线进行进程内的数据转发，可将数据转发至数据库或进行微信等消息推送。

3.3 自定义接口协议开发设计

协议主要由认证器（Authenticator）、消息编解码器（DeviceMessageCodec）、消息发送拦截器（DeviceMessageSenderInt erceptor）组成。

3.3.1 认证器

不同网络协议使用不同认证器，主要用于设备认证，接口定义如图5 所示。

图5 认证器接口设计

3.3.2 消息编解码器

设备网关从网络组件中接收到报文后，会调用对应协议包的消息编解码器进行处理，接口定义如图6 所示。

图6 编解码器接口设计

3.3.3 消息发送拦截器

使用拦截器拦截消息发送和返回的动作，通过修改参数等操作实现自定义逻辑，如：当设备离线时，将消息缓存到设备配置中，等设备上线时再重发，如图7 所示。

图7 消息发送拦截器接口设计

3.4 ReactorQL 实时数据处理

本课题利用一套使用SQL 进行实时数据处理的工具包，通过将SQL 翻译为reactor 来进行数据处理，主要应用场景包括处理实时数据、聚合计算实时数据及跨数据源联合数据处理。

例如，处理多个型号的设备数据，如图8 所示。

图8 数据处理

3.5 数据库设计

本课题使用关系型及非关系型数据库结合的方式进行实时大数据采集存储，其中关系型数据库MySQL 中存储设备基础信息，非关系型数据库Elasticsearch 存储设备消息，缓存及热点数据存储于redis。

3.5.1 MySQL 数据库设计

其中设备实例信息存储在dev_device_instance，设备产品存储在dev_product，协议存储在dev_protocal，设备网关存储在device_gateway，网络组件配置存储在network_config。

3.5.2 Elasticsearch 数据库设计

本课题提供两种Elasticsearch 存储方案，默认使用行式存储方案。

方案一：使用elasticsearch 行式存储方案存储设备数据，设备每一个属性值都保存为一条索引记录，其典型应用场景是设备每次只会上报一部分属性，同时支持读取部分属性数据的时候，优点在于几乎满足任意场景下的属性数据存储，缺点在于设备属性个数较多时，数据量指数增长，可能会影响性能。

方案二：使用elasticsearch 列式存储方案存储设备数据，一个属性作为一列，一条属性消息作为一条索引记录进行存储，适合设备每次都上报所有的属性值的场景，优点是在属性个数较多，且设备每次都会上报全部属性时，系统性能更高，缺点是设备必须上报全部属性。

4 设备数据采集管理

本课题接入多源设备，采集各类型设备数据，并监控设备接入量对系统性能的影响以及内存消耗情况。

4.1 测试准备

通过使用两个本地Linux 虚拟机，一个作为服务端，另一个作为压力测试客户端，服务器选用ThinkSystem ST558，64G 内存；服务器虚拟机：6 核30G 内存，centOS；客户端虚拟机：4 核10G 内存，centOS；初始数据：200W 设备实例，使用模具状态监控设备作为物模型，进行设备连接数以及设备消息处理速度压力测试。