基于物聯網的大數據采集與存儲技術解決方案

秦 磊 林希佳 周 軒 郭 磊 王 路 吳成慶 王 娜

（江蘇金陵智造研究院有限公司，江蘇 南京 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 設備實例，使用模具狀態監控設備作為物模型，進行設備連接數以及設備消息處理速度壓力測試。

4.2 測試結果

4.2.1 10W 設備連接，1000 并發請求連接，總計10W 連接，第一次CPU 平均使用率44%，JVM內存4.58G；第二次CPU 平均使用率72%，JVM內存4.89G；

4.2.2 30W 設備連接，1000 并發請求連接，總計30W 連接，第一次CPU 平均使用率64%，JVM內存5.42G，第二次CPU 平均使用率78%，JVM內存4.99G；

4.2.3 50W 設備連接，1000 并發請求連接，總計50W 連接，第一次CPU 平均使用率59%，JVM內存5.46G，第二次CPU 平均使用率83%，JVM內存7.92G。

5 模具狀態監控設備接入管理

設備接入流程如圖9 所示，本文以模具狀態監控設備為例，描述其接入流程。

5.1 協議開發

模具狀態監控設備使用TCP 協議進行數據傳輸，因此針對TCP 報文類型進行自定義解析協議開發，解析完成打成jar 包導入平臺端，創建產品基本信息即可完成數據展示，部分核心代碼如圖10 所示。

5.2 數據展示

模具狀態監控設備根據TCP 協議報文創建對應的實例信息并進行數據展示，如圖11 所示。

圖11 模具狀態監控設備

6 結論

本文為滿足多類型、大數據量設備數據采集存儲，設計并實現了一套大數據采集的架構，在進行數據采集的基礎上增加了可行的緩存機制，實現了大數據實時監控以及設備數據穩定存儲的功能，為智能智造領域及智慧園區相關大數據分析和設備監控提供了重要的數據依據，也為以后的信息化建設鋪平了道路。