舒玨淋 曹楊 遲雪 胥月 何加浪 周豪

關(guān)鍵詞：物聯(lián)網(wǎng)；感知數(shù)據(jù)；大數(shù)據(jù)平臺；通用型

0 引言

大數(shù)據(jù)、物聯(lián)網(wǎng)、移動互聯(lián)網(wǎng)技術(shù)的迅速發(fā)展，促使各行各業(yè)的設(shè)備終端通過網(wǎng)絡(luò)的形式快速的匯聚在一起，這無疑標(biāo)志著萬物互聯(lián)時代的來臨[1，2]。物聯(lián)網(wǎng)傳感器設(shè)備在復(fù)雜多變的應(yīng)用場景中，產(chǎn)生了近乎PB 級規(guī)模的繁雜種類的感知數(shù)據(jù)，海量且結(jié)構(gòu)復(fù)雜的感知數(shù)據(jù)背后蘊藏著無限的數(shù)據(jù)價值，而且大數(shù)據(jù)技術(shù)也擴大了物聯(lián)網(wǎng)的應(yīng)用范圍[3-4]。然而面對海量的物聯(lián)網(wǎng)感知數(shù)據(jù)，其結(jié)構(gòu)復(fù)雜多樣、質(zhì)量低的特點導(dǎo)致大量設(shè)備數(shù)據(jù)無效且難以進(jìn)行統(tǒng)一管理，使得挖掘分析仍然缺乏理論性、準(zhǔn)確性和便利性，造成了無法高效的進(jìn)行價值挖掘。主要體現(xiàn)在①方法簡單，僅僅針對單一的業(yè)務(wù)場景，煙囪式理論的平臺設(shè)計，造成架構(gòu)不同，各個應(yīng)用數(shù)據(jù)難以聯(lián)通；②數(shù)據(jù)平臺的建設(shè)沒有以統(tǒng)一的數(shù)據(jù)規(guī)范標(biāo)準(zhǔn)為基礎(chǔ)進(jìn)行深入挖掘，分析的結(jié)果對于實際業(yè)務(wù)沒有太大的參考性。

目前，在物聯(lián)網(wǎng)大數(shù)據(jù)領(lǐng)域，許多學(xué)者已經(jīng)利用大數(shù)據(jù)技術(shù)去解決一些相應(yīng)的實際問題。如文獻(xiàn)[5]以大數(shù)據(jù)技術(shù)棧建立大數(shù)據(jù)平臺基礎(chǔ)框架，為大數(shù)據(jù)融合分析處理提供基礎(chǔ)數(shù)據(jù)與資源能力，對煤礦數(shù)據(jù)統(tǒng)一標(biāo)準(zhǔn)及規(guī)范化管理，讓數(shù)據(jù)成為了資產(chǎn)，實現(xiàn)數(shù)據(jù)全生命周期管理。文獻(xiàn)[6]針對于物聯(lián)網(wǎng)應(yīng)用設(shè)備與平臺的差異性，以及耦合度高、擴展性差等導(dǎo)致應(yīng)用的碎片化，設(shè)計了一種面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)通用型服務(wù)平臺，便于使用者根據(jù)自己的業(yè)務(wù)需求在平臺上定制服務(wù)，實現(xiàn)數(shù)據(jù)挖掘分析。文獻(xiàn)[7]基于交通能源互聯(lián)網(wǎng)的理念，提出交通能源融合大數(shù)據(jù)平臺架構(gòu)，以應(yīng)對業(yè)務(wù)系統(tǒng)成煙囪式發(fā)展，以及信息分布分散、缺乏統(tǒng)籌規(guī)劃、各系統(tǒng)間數(shù)據(jù)難以兼容的問題。

這些研究較少涉及通用型物聯(lián)網(wǎng)大數(shù)據(jù)平臺。因此，本文提出一種面向物聯(lián)網(wǎng)應(yīng)用的通用型大數(shù)據(jù)平臺設(shè)計。首先以O(shè)neData 和OneService 方法理論作為整個大數(shù)據(jù)平臺的設(shè)計思路，其次以大數(shù)據(jù)技術(shù)棧作為有力的技術(shù)支撐建設(shè)大數(shù)據(jù)平臺，并與傳統(tǒng)方案進(jìn)行性能比較，最后以落地的實際場景為例，闡述了面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)平臺的實際應(yīng)用，實現(xiàn)了對于物聯(lián)網(wǎng)感知數(shù)據(jù)的科學(xué)合理管理以及挖掘分析數(shù)據(jù)價值，為智慧城市的物聯(lián)網(wǎng)多源數(shù)據(jù)管理和便捷應(yīng)用賦能。

1 大數(shù)據(jù)平臺設(shè)計理論

1.1 OneData

OneData 是基于大數(shù)據(jù)存儲和計算為載體，是數(shù)據(jù)整合及管理的方法體系。在這一體系下，期望構(gòu)建統(tǒng)一、規(guī)范、可共享的全域數(shù)據(jù)體系，避免數(shù)據(jù)的冗余和重復(fù)建設(shè)，規(guī)避數(shù)據(jù)煙囪和不一致性，從而，快速響應(yīng)需求，對外提供高質(zhì)量服務(wù)[8]。本文根據(jù)OneData 的數(shù)據(jù)管理體系，考慮到物聯(lián)網(wǎng)感知數(shù)據(jù)的不同業(yè)務(wù)場景，在進(jìn)行數(shù)據(jù)挖掘時候，是需要提前進(jìn)行規(guī)劃，因此把OneData 核心思想定義數(shù)據(jù)只加工一次。

1.2 OneService

OnService 即服務(wù)，強調(diào)通過API 接口對數(shù)據(jù)平臺里的數(shù)據(jù)進(jìn)行訪問。數(shù)據(jù)通過OneData 體系進(jìn)行整合規(guī)范化之后，需要提供給其他部門進(jìn)行使用，為了更好的性能和體驗，構(gòu)建數(shù)據(jù)服務(wù)層，以統(tǒng)一API 接口方式對外提供數(shù)據(jù)服務(wù)[9]。本文根據(jù)OneService 理論，建設(shè)數(shù)據(jù)API 接口服務(wù)化，提高數(shù)據(jù)的共享能力，讓數(shù)據(jù)的使用更加便利。

2 面向物聯(lián)網(wǎng)大數(shù)據(jù)平臺架構(gòu)

2.1 大數(shù)據(jù)平臺業(yè)務(wù)流程

面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)平臺核心功能是對數(shù)據(jù)進(jìn)行統(tǒng)一信息化建設(shè)管理，提供物聯(lián)網(wǎng)應(yīng)用不同業(yè)務(wù)以通用型的數(shù)據(jù)平臺進(jìn)行數(shù)據(jù)管控。對物聯(lián)網(wǎng)感知數(shù)據(jù)資源（結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)）的集成，并利用OneData 和OneService 體系對數(shù)倉數(shù)據(jù)進(jìn)行規(guī)范化管理，建立數(shù)據(jù)應(yīng)用模型，提供模型的復(fù)用能力，對外以Api 接口方式訪問，提供數(shù)據(jù)的共享能力。有效地挖掘數(shù)據(jù)的價值，實現(xiàn)企業(yè)數(shù)據(jù)資源的“共享、共用、共贏”[10]。其業(yè)務(wù)流程主要為：數(shù)據(jù)源、數(shù)據(jù)采集、數(shù)據(jù)存儲、數(shù)據(jù)清洗、數(shù)據(jù)分析、數(shù)據(jù)展示。設(shè)計流程圖如圖1 所示。

如圖1 所示，本文以此為業(yè)務(wù)流程，研究并設(shè)計通用型物聯(lián)網(wǎng)大數(shù)據(jù)平臺，在滿足于業(yè)務(wù)需求的同時，解決了物聯(lián)網(wǎng)感知數(shù)據(jù)因規(guī)模大，類型雜、質(zhì)量低的特點導(dǎo)致大量設(shè)備數(shù)據(jù)無效，難以管理，同時克服了單一數(shù)據(jù)平臺面臨的問題。

2.2 大數(shù)據(jù)平臺架構(gòu)設(shè)計

面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)平臺是基于Hadoop 架構(gòu)進(jìn)行設(shè)計，整個架構(gòu)自下而上主要包括數(shù)據(jù)源管理層、數(shù)據(jù)資源池管理層、數(shù)據(jù)處理層、數(shù)據(jù)服務(wù)層等。架構(gòu)設(shè)計如圖2 所示。

如圖2 所示，大數(shù)據(jù)平臺總體架構(gòu)，主要針對物聯(lián)網(wǎng)感知數(shù)據(jù)的接入與存儲，數(shù)據(jù)資源池及數(shù)據(jù)服務(wù)系統(tǒng)進(jìn)行搭建，從而建立面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)平臺基礎(chǔ)框架。

⑴ 數(shù)據(jù)源管理，數(shù)據(jù)源的特征決定了數(shù)據(jù)采集功能的實現(xiàn)方式。因此根據(jù)物聯(lián)網(wǎng)感知數(shù)據(jù)結(jié)構(gòu)多樣性的特征，本文數(shù)據(jù)源管理設(shè)計為數(shù)據(jù)源接入、數(shù)據(jù)采集兩個步驟，將各類不同數(shù)據(jù)源的物聯(lián)網(wǎng)感知數(shù)據(jù)匯入數(shù)據(jù)資源池中進(jìn)行統(tǒng)一管理。

⑵ 數(shù)據(jù)資源池，數(shù)據(jù)資源池是數(shù)據(jù)統(tǒng)一集中管理的位置，將數(shù)據(jù)分為主題應(yīng)用數(shù)據(jù)、感知熱數(shù)據(jù)、感知冷數(shù)據(jù)、感知元數(shù)據(jù)、設(shè)備數(shù)據(jù)以及感知數(shù)據(jù)消息隊列等部分，通過集成了時序數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫的系統(tǒng)架構(gòu)，將數(shù)據(jù)進(jìn)行匯聚與調(diào)度。

⑶ 數(shù)據(jù)處理，將已匯入數(shù)據(jù)資源池中物聯(lián)網(wǎng)感知數(shù)據(jù)數(shù)據(jù)按照數(shù)據(jù)類別，分別通過可視化界面，以拖拽的方式進(jìn)行離線數(shù)據(jù)處理和實時數(shù)據(jù)處理，提供對大批量數(shù)據(jù)的計算能力，并對數(shù)據(jù)處理任務(wù)進(jìn)行調(diào)度與監(jiān)控。

⑷ 數(shù)據(jù)治理，數(shù)據(jù)治理是對整個大數(shù)據(jù)平臺，最大化保障整個數(shù)據(jù)研發(fā)鏈路，將物聯(lián)網(wǎng)感知數(shù)據(jù)的采集、存儲、計算和使用過程可控和可追溯。設(shè)計上，對數(shù)據(jù)資源池中數(shù)據(jù)構(gòu)建數(shù)據(jù)資源目錄，并進(jìn)行質(zhì)量巡檢以監(jiān)督數(shù)據(jù)質(zhì)量，使數(shù)據(jù)成為資產(chǎn)。

⑸ 數(shù)據(jù)服務(wù)，數(shù)據(jù)處理與數(shù)據(jù)治理的結(jié)果數(shù)據(jù)也將存入數(shù)據(jù)資源池中，數(shù)據(jù)服務(wù)則主要提供了數(shù)據(jù)主動推送、數(shù)據(jù)API 接口獲取、數(shù)據(jù)加載和數(shù)據(jù)快速查詢等四類數(shù)據(jù)服務(wù)，以實現(xiàn)數(shù)據(jù)管理中的數(shù)據(jù)應(yīng)用。

2.3 大數(shù)據(jù)平臺技術(shù)架構(gòu)設(shè)計

為了降低研發(fā)成本，大數(shù)據(jù)平臺在技術(shù)架構(gòu)設(shè)計上使用的是開源并且穩(wěn)定版本的大數(shù)據(jù)組件。通過技術(shù)架構(gòu)中組件的整合，可實現(xiàn)數(shù)據(jù)集成、數(shù)據(jù)加工處理、數(shù)據(jù)存儲、數(shù)據(jù)治理、數(shù)據(jù)分析、數(shù)據(jù)可視化。技術(shù)架構(gòu)如圖3 所示。

2.3.1 數(shù)據(jù)層

根據(jù)物聯(lián)網(wǎng)感知數(shù)據(jù)的結(jié)構(gòu)多樣性，采用多種不同數(shù)據(jù)存儲模式相結(jié)合的方式，集成關(guān)系型數(shù)據(jù)庫與時序數(shù)據(jù)庫，將業(yè)務(wù)數(shù)據(jù)、主題應(yīng)用數(shù)據(jù)此類結(jié)構(gòu)化存儲于MySQL 數(shù)據(jù)庫中文件數(shù)據(jù)依據(jù)文件大小，以HDFS 和FastDFS 的方式進(jìn)行存儲，同時則基于技術(shù)成熟的Kafka 和redis 集群構(gòu)建，提供系統(tǒng)內(nèi)數(shù)據(jù)總線及緩存功能；將元數(shù)據(jù)、設(shè)備數(shù)據(jù)等存儲于MongoDB中；對于物聯(lián)網(wǎng)的感知數(shù)據(jù)，億級以上大規(guī)模數(shù)據(jù)量，則需要使用依賴于Hadoop 的Hbase 存儲感知冷數(shù)據(jù)，使用依賴于Hbase 的openTSDB 存儲感知熱數(shù)據(jù)，該架構(gòu)可滿足億級以上的數(shù)據(jù)量存儲需求。

2.3.2 計算層

基于業(yè)內(nèi)廣泛使用的Hadoop/Flink 生態(tài)圈軟件構(gòu)建，提供分布式計算服務(wù)，采用Flink 和Hive 相結(jié)合的方式，提供實時數(shù)據(jù)計算和離線數(shù)據(jù)計算服務(wù)。在離線批處理階段，以拖拽組件的方式進(jìn)行數(shù)據(jù)處理，每個組件功能都以HiveSql 進(jìn)行封裝，其底層為MapReduce 大數(shù)據(jù)計算框架，能分布式的處理海量的物聯(lián)網(wǎng)感知數(shù)據(jù)，提供了一個海量數(shù)據(jù)的處理能力。在實時處理階段，采用Flink 計算引擎，其是一個高吞吐、低延遲、高性能分布式流式數(shù)據(jù)處理框架[11]。

2.3.3 數(shù)據(jù)引擎

基于業(yè)內(nèi)廣泛引用的數(shù)據(jù)調(diào)度和任務(wù)調(diào)度架構(gòu)，采用Datax 作為數(shù)據(jù)調(diào)度引擎，Airflow 作為任務(wù)調(diào)度引擎，對數(shù)據(jù)資源池和數(shù)據(jù)處理、數(shù)據(jù)治理任務(wù)進(jìn)行相應(yīng)調(diào)度，以解決場景下多個任務(wù)的依賴問題。Datax為了解決異構(gòu)數(shù)據(jù)源同步問題，它將復(fù)雜的網(wǎng)狀的同步鏈路變成了星型數(shù)據(jù)鏈路，作為中間傳輸載體負(fù)責(zé)連接各種數(shù)據(jù)源，只需要將數(shù)據(jù)源對接到Datax，便能跟已有的數(shù)據(jù)源做到無縫數(shù)據(jù)同步[12]。

2.3.4 應(yīng)用層

基于業(yè)內(nèi)使用最為廣泛、功能最為齊全的Springcloud 框架開發(fā)，搭建微服務(wù)集群，且能夠根據(jù)需要水平擴展，并構(gòu)建服務(wù)接口，支持高并發(fā)訪問。其中內(nèi)部接口使用Springcloud 的Rpc 接口，對外提供RestfulAPI 接口和Restful 推送接口，把數(shù)據(jù)提供給展現(xiàn)層進(jìn)行可視化顯示。

2.3.5 展現(xiàn)層

采用前端主流的React/Vue 框架，使用Fusion 或ElementUI 成熟的前端控件，構(gòu)建Web 界面，提供圖形化操作頁面?？梢园呀?jīng)過平臺處理的數(shù)據(jù)，生成的業(yè)務(wù)指標(biāo)進(jìn)行可視化，提供給管理層人員作為決策依據(jù)。

2.4 大數(shù)據(jù)平臺數(shù)據(jù)流程設(shè)計

本文設(shè)計的大數(shù)據(jù)平臺采用Lamda 的架構(gòu)設(shè)計，數(shù)據(jù)流程以離線批處理和實時處理兩條線進(jìn)行數(shù)據(jù)的挖掘處理，最后以數(shù)據(jù)Api 的方式提供服務(wù)及數(shù)據(jù)共享。

如圖4 所示，首先，外部物聯(lián)網(wǎng)感知數(shù)據(jù)需要被數(shù)據(jù)采集組件采集到大數(shù)據(jù)平臺，最終離線數(shù)據(jù)存于對應(yīng)的數(shù)據(jù)倉庫，而事實數(shù)據(jù)則以Kafka 為數(shù)倉進(jìn)行存儲。之后在實時處理和批處理兩條通道上對存儲于對應(yīng)的數(shù)據(jù)倉庫里的感知數(shù)據(jù)進(jìn)行一系列的加工處理操作。實時處理的計算結(jié)果通常會寫入一個NoSQL 數(shù)據(jù)庫，以便后續(xù)實時查詢，批處理的計算結(jié)果往往寫回分布式文件系統(tǒng)。其次，實時處理和批處理在計算之后得到的數(shù)據(jù)會注冊到數(shù)據(jù)資源池，成為資產(chǎn)。通過數(shù)據(jù)治理中的數(shù)據(jù)質(zhì)量管理功能對數(shù)據(jù)進(jìn)行管控。最后，經(jīng)過處理得到的資產(chǎn)數(shù)據(jù)以Api 接口的方式接受訪問，提高數(shù)據(jù)的共享能力。

3 物聯(lián)網(wǎng)大數(shù)據(jù)平臺性能測試分析

在完成物聯(lián)網(wǎng)大數(shù)據(jù)平臺部署后，應(yīng)該測試其性能，以驗證本文設(shè)計的物聯(lián)網(wǎng)大數(shù)據(jù)平臺性能更優(yōu)。表1 為本文設(shè)計的大數(shù)據(jù)平臺數(shù)據(jù)處理方案與傳統(tǒng)Java數(shù)據(jù)處理方案效率對比。其中第一組有服務(wù)器3臺，某農(nóng)業(yè)物聯(lián)網(wǎng)感知數(shù)據(jù)100 萬條；第二組有服務(wù)器3 臺，某農(nóng)業(yè)物聯(lián)網(wǎng)感知數(shù)據(jù)500 萬條左右；第三組也是一樣的服務(wù)器臺數(shù)，查詢數(shù)據(jù)量1000 萬條。對比結(jié)果如表1 所示。

由表1 可知，基于Hadoop 框架的物聯(lián)網(wǎng)大數(shù)據(jù)平臺對農(nóng)業(yè)物聯(lián)網(wǎng)生產(chǎn)的感知數(shù)據(jù)加載查詢速度要比傳統(tǒng)方案快很多，工作效率在數(shù)據(jù)量越大的情況下效率越高。在有千萬條數(shù)據(jù)的情況下，該框架只需要10 分鐘左右就可以完成工作，傳統(tǒng)框架需要花費1 個小時左右。這一數(shù)據(jù)差異體現(xiàn)出了本文所設(shè)計的物聯(lián)網(wǎng)大數(shù)據(jù)平臺在海量數(shù)據(jù)方面的優(yōu)勢。

為了進(jìn)一步說明，物聯(lián)網(wǎng)大數(shù)據(jù)平臺的高性能，本文將利用物聯(lián)網(wǎng)大數(shù)據(jù)平臺的數(shù)據(jù)采集功能與文獻(xiàn)[13]的傳統(tǒng)方案HDFS-File-Oracle 進(jìn)行對比，其結(jié)果如表2 所示。

由表２ 可知， 在數(shù)據(jù)量較小的情況下，采用Datax 方案的物聯(lián)網(wǎng)大數(shù)據(jù)平臺和傳統(tǒng)方案并沒有明顯的差別，但是在數(shù)據(jù)量較大的情況下，Datax 方案就會越發(fā)凸顯出自身的優(yōu)勢。從上述的數(shù)據(jù)可以得出該方案對于海量數(shù)據(jù)條件下和傳統(tǒng)方案相比有絕對的優(yōu)勢，因此在本文的研究之中使用Datax 數(shù)據(jù)遷移方案作為異構(gòu)數(shù)據(jù)源傳輸紐帶是可行的。

4 物聯(lián)網(wǎng)大數(shù)據(jù)平臺應(yīng)用案例

基于本文所設(shè)計的面向物聯(lián)網(wǎng)的大數(shù)據(jù)平臺，目前正在試點進(jìn)行建設(shè)與工程實踐。項目在設(shè)計階段對于數(shù)據(jù)的全生命周期管理進(jìn)行了統(tǒng)一管理，以數(shù)據(jù)源、數(shù)據(jù)資源池、數(shù)據(jù)處理、數(shù)據(jù)治理、數(shù)據(jù)服務(wù)為核心，完成物聯(lián)網(wǎng)感知數(shù)據(jù)的研發(fā)鏈路。

當(dāng)前項目、平臺建設(shè)還在初步擴展與完善中，在前期的建設(shè)過程中已在安全風(fēng)險預(yù)控、工作面狀態(tài)評價、生產(chǎn)效率、綜合管理等方面取得顯著成效。試點部署的物聯(lián)網(wǎng)大數(shù)據(jù)平臺可視化圖如圖5 所示。

5 結(jié)束語

本文針對物聯(lián)網(wǎng)感知數(shù)據(jù)的特點問題以及單一大數(shù)據(jù)平臺的局限性進(jìn)行詳細(xì)的分析，研究設(shè)計了面向物聯(lián)網(wǎng)應(yīng)用的大數(shù)據(jù)平臺，并且通過性能測試以及應(yīng)用案例進(jìn)行了驗證，得出如下結(jié)論：

⑴ 解決了因物聯(lián)網(wǎng)感知數(shù)據(jù)規(guī)模大，類型雜、質(zhì)量低而導(dǎo)致的大量設(shè)備數(shù)據(jù)無效且難以統(tǒng)一管理的問題。并且通過OneData 和OneService 理論來應(yīng)對業(yè)務(wù)系統(tǒng)成煙囪式發(fā)展，以及數(shù)據(jù)分布分散、缺乏統(tǒng)籌規(guī)劃和各系統(tǒng)間的數(shù)據(jù)難以兼容的問題。

⑵ 該平臺能夠滿足于通用的物聯(lián)網(wǎng)業(yè)務(wù)場景，不局限于單一的業(yè)務(wù)。針對不同的業(yè)務(wù)，在數(shù)據(jù)倉庫里建立不同的模型，得到需要的指標(biāo)，進(jìn)行可視化，提供給管理人員進(jìn)行業(yè)務(wù)分析挖掘。

⑶ 平臺測試以及試驗結(jié)果證明，在物聯(lián)網(wǎng)應(yīng)用所產(chǎn)生的海量感知數(shù)據(jù)中應(yīng)用基于大數(shù)據(jù)組件技術(shù)方案，是十分可行的。