大數(shù)據(jù)技術(shù)在CIMS監(jiān)測和分析海量工業(yè)數(shù)據(jù)中的應(yīng)用

【摘要】 為解決現(xiàn)有工業(yè)數(shù)據(jù)處理方案的不足，將大數(shù)據(jù)技術(shù)引入到CIMS的監(jiān)測和分析中；借助消息中間件完成HDFS分布式環(huán)境下的可靠通信，并利用Hadoop的MapReduce框架保證監(jiān)測和分析的實時性。另外，還借助系統(tǒng)動力學(xué)方法對要建立的CIMS監(jiān)測和分析平臺進行建模，以分析監(jiān)測和分析平臺的瓶頸，提高監(jiān)測和分析性能。

【關(guān)鍵詞】 大數(shù)據(jù) HDFS MapReduce CIMS

一、研究背景

工業(yè)化和計算機技術(shù)的發(fā)展，使制造系統(tǒng)每天產(chǎn)生的數(shù)據(jù)量不斷增加，整個制造業(yè)產(chǎn)生的數(shù)據(jù)量遠(yuǎn)高于其他行業(yè)[1]。面對日益復(fù)雜的制造業(yè)生產(chǎn)系統(tǒng)，通過保存其運行過程中的中間數(shù)據(jù)，并對數(shù)據(jù)進行研究，能夠解決當(dāng)前的系統(tǒng)建模手段無法解決的問題。傳統(tǒng)的數(shù)據(jù)分析方案一般先將數(shù)據(jù)保存到關(guān)系型數(shù)據(jù)庫中，然后借助聯(lián)機分析、處理等手段為決策提供支持[2]。

當(dāng)面對制造業(yè)的海量數(shù)據(jù)時，可能會有如下缺陷[3]：

（1）數(shù)據(jù)來自不同地區(qū)的工作站、傳感器等，而且數(shù)據(jù)格式不統(tǒng)一，既有結(jié)構(gòu)化數(shù)據(jù)，也有非結(jié)構(gòu)化數(shù)據(jù)，不利于處理；

（2）聯(lián)機分析處理過程中會有大量的數(shù)據(jù)移動操作，當(dāng)數(shù)據(jù)量達(dá)到PB級時，大量數(shù)據(jù)移動造成的開銷變得難以接受。

因此，有必要研究并實現(xiàn)一個能夠合并存儲異構(gòu)數(shù)據(jù)、并且可以完成基于大數(shù)據(jù)的CIMS數(shù)據(jù)分析處理的平臺。本文將Hadoop大數(shù)據(jù)技術(shù)引入到CIMS海量工業(yè)數(shù)據(jù)的監(jiān)測和分析中。

二、研究現(xiàn)狀

范劍青[4]闡述了大數(shù)據(jù)獨有的特點，說明大數(shù)據(jù)提供的海量數(shù)據(jù)給統(tǒng)計、處理以及統(tǒng)計估算和檢驗帶來的問題。Jiang 等人[5]對電子商務(wù)網(wǎng)站的大量商品數(shù)據(jù)進行分析處理，提出了基于Hadoop的協(xié)同過濾算法。

Duke能源公司模擬大數(shù)據(jù)解決方案，使維護專家遠(yuǎn)程觀看設(shè)備和記錄異常指數(shù)，甚至可以及時采取糾正操作，但還不能真正實現(xiàn)大數(shù)據(jù)分析和處理平臺。通用電氣（GE）于2013年推出其大數(shù)據(jù)分析平臺，用以將云平臺中的工業(yè)機器產(chǎn)生的海量數(shù)據(jù)轉(zhuǎn)化為實時信息，此平臺可以認(rèn)為是第一個能夠真正管理工業(yè)海量數(shù)據(jù)的平臺，但是難以處理來自多個數(shù)據(jù)源的數(shù)據(jù)。美國國家儀器公司和IBM聯(lián)手推出InfoSphereStreams大數(shù)據(jù)解決方案，能夠以很高的數(shù)據(jù)吞吐率分析來自多個數(shù)據(jù)源的信息，但其處理帶有一定的數(shù)據(jù)延時，實時性不佳。

為解決海量數(shù)據(jù)處理時的實時性問題，本文擬采用開源的Storm流處理技術(shù)，并借助類SQL和Piglatin等過程化語言擴展，以實時監(jiān)控整個大數(shù)據(jù)平臺。

三、大數(shù)據(jù)技術(shù)在CIMS監(jiān)測與分析平臺中的設(shè)計

工業(yè)應(yīng)用數(shù)據(jù)在數(shù)據(jù)量上遠(yuǎn)超普通應(yīng)用，其海量數(shù)據(jù)存儲的要求超過了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的存儲能力。另外，工業(yè)應(yīng)用數(shù)據(jù)也由傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)擴展到結(jié)構(gòu)化、半結(jié)構(gòu)化以及非結(jié)構(gòu)化數(shù)據(jù)并存，對這些數(shù)據(jù)格式以及數(shù)據(jù)類型都存在不同的工業(yè)數(shù)據(jù)進行采集、分析和處理的方式有別于傳統(tǒng)方式，因此需要對監(jiān)測和分析平臺進行設(shè)計，從軟件結(jié)構(gòu)、通信方式以及數(shù)據(jù)存儲方式等各個方面進行分析。

3.1 CIMS海量數(shù)據(jù)監(jiān)測與分析平臺的設(shè)計

在將大數(shù)據(jù)技術(shù)應(yīng)用于CIMS海量數(shù)據(jù)的監(jiān)測與分析時，海量的工業(yè)數(shù)據(jù)不再存放在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，而是存放到HDFS分布式文件系統(tǒng)上。因此，軟件結(jié)構(gòu)設(shè)計要與Hadoop的HDFS文件系統(tǒng)相對應(yīng)。

3.1.1 軟件結(jié)構(gòu)

本文設(shè)計的CIMS海量工業(yè)數(shù)據(jù)監(jiān)測和分析平臺（以下簡稱“平臺”）采用Master-slave主從架構(gòu)，Hadoop集群的NameNode節(jié)點作為監(jiān)測和分析平臺的管理節(jié)點，完成數(shù)據(jù)采集、數(shù)據(jù)分析等各功能的功能模塊是工作節(jié)點。管理節(jié)點管理整個集群的相關(guān)信息，并維護包括節(jié)點的主機名、IP地址等機器狀態(tài)。工作節(jié)點可以根據(jù)工業(yè)應(yīng)用的需求進行靈活的配置，也可以動態(tài)增加或減少。

平臺主要分為如下部分[6]：客戶端、消息中間件、數(shù)據(jù)查詢模塊、數(shù)據(jù)分析模塊、數(shù)據(jù)采集模塊以及Hadoop集群。客戶端接收用戶請求，向平臺發(fā)出任務(wù)請求；數(shù)據(jù)采集模塊、數(shù)據(jù)查詢模塊以及數(shù)據(jù)分析模塊是平臺的功能組件，分別提供工業(yè)大數(shù)據(jù)分析流程中的對應(yīng)功能[7]：數(shù)據(jù)采集模塊對外提供數(shù)據(jù)的訪問接口，其功能是從不同的數(shù)據(jù)源獲取數(shù)據(jù)，并將這些數(shù)據(jù)存儲到Hadoop的HDFS文件系統(tǒng)上。

數(shù)據(jù)查詢模塊從HDFS文件系統(tǒng)中查詢數(shù)據(jù)的存儲索引，并返回給數(shù)據(jù)分析模塊；數(shù)據(jù)分析模塊中實現(xiàn)不同的數(shù)據(jù)分析配置方法，并交由MapReduce框架分布式地實現(xiàn)數(shù)據(jù)分析任務(wù)。

3.1.2 系統(tǒng)功能模塊

平臺中監(jiān)測和分析的數(shù)據(jù)一般都是離散數(shù)據(jù)，所以選擇消息中間件作為通信管理模塊，消息中間件實現(xiàn)平臺中各個模塊間的通信。

以功能節(jié)點上線為例，由于管理節(jié)點存儲了所有節(jié)點的狀態(tài)信息，所以為保證整個集群信息的一致性，功能節(jié)點上線時需要先向管理節(jié)點注冊其信息，管理節(jié)點會向消息中間件訂閱“注冊”這一主題，消息中間件接收到訂閱請求后會創(chuàng)建相應(yīng)的隊列，并持續(xù)監(jiān)聽此隊列的消息情況。消息隊列中的消息是以文本格式存在的，本文的消息傳遞方式采用XML。平臺中的操作請求都會發(fā)送給任務(wù)管理模塊，由其解析后，再發(fā)送給相應(yīng)的功能模塊執(zhí)行。

數(shù)據(jù)采集模塊從基于HDFS文件系統(tǒng)的Hbase數(shù)據(jù)庫中獲取來自客戶端的數(shù)據(jù)，由于工業(yè)數(shù)據(jù)的采集并發(fā)量可能比較大，因此要在采集端部署大量數(shù)據(jù)庫；除此之外，ETL工具負(fù)責(zé)將異構(gòu)數(shù)據(jù)源的數(shù)據(jù)抽取處理進行數(shù)據(jù)清洗。Hadoop上的數(shù)據(jù)分析模塊能夠完成多維分析，由于MapReduce的具備很強的并行處理能力，因此分析維度的增加并不會使數(shù)據(jù)分析的開銷顯著增加，這無疑是傳統(tǒng)的數(shù)據(jù)分析平臺所無可比擬的。

3.1.3 數(shù)據(jù)存儲方式

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫不能很好的支持結(jié)構(gòu)化和半結(jié)構(gòu)化的數(shù)據(jù)，HDFS分布式文件系統(tǒng)克服了這一缺陷，將非結(jié)構(gòu)化數(shù)據(jù)和結(jié)構(gòu)化數(shù)據(jù)都以文件形式存放，實現(xiàn)了廉價而又可靠數(shù)據(jù)存儲。

工業(yè)數(shù)據(jù)可能來自多個不同的數(shù)據(jù)源，平臺借助中間件屏蔽了它們之間的異構(gòu)性，然后將這些原本異構(gòu)的數(shù)據(jù)存儲到HDFS文件系統(tǒng)中。這種異構(gòu)數(shù)據(jù)存儲方式不需要昂貴的存儲設(shè)備，廉價的服務(wù)器即可組成可靠的存儲集群；另外，存儲集群節(jié)點同時還是Hadoop集群的工作節(jié)點，提高了數(shù)據(jù)存儲節(jié)點的利用率[8]。

四、大數(shù)據(jù)技術(shù)在CIMS監(jiān)測與分析平臺的性能優(yōu)化

軟件工程思想中，不能只設(shè)計軟件的結(jié)構(gòu)，同時要對軟件進行不斷優(yōu)化。平臺集中了多個數(shù)據(jù)來源的數(shù)據(jù)，因此平臺間的數(shù)據(jù)傳遞吞吐量比較大；另外，平臺各個組件間的網(wǎng)絡(luò)依賴關(guān)系比較復(fù)雜，合理分配網(wǎng)絡(luò)資源對提升平臺性能有重要的影響。

系統(tǒng)動力學(xué)研究復(fù)雜系統(tǒng)的結(jié)構(gòu)、功能以及動態(tài)行為模式，可以利用系統(tǒng)動力學(xué)的相關(guān)原理和方法，對本文設(shè)計的平臺進行模擬仿真研究。

在進行實際的大數(shù)據(jù)平臺仿真分析時，為搭建Hadoop集群本文配置4臺服務(wù)器，其中一臺作為NameNode，其他服務(wù)器作為DataNode。具體的配置信息如表1所示：

系統(tǒng)動力學(xué)分析軟件系統(tǒng)的基本思路是把與系統(tǒng)相關(guān)的網(wǎng)絡(luò)變量轉(zhuǎn)換為因果圖及流圖，因果圖表征了變量間的相互影響關(guān)系，流圖說明了變量的反饋積累；然后利用DYNAMO方程描述變量間的關(guān)系。因果圖反應(yīng)了平臺中的反饋回路的正負(fù)極性，表示出系統(tǒng)元素間基本的相互影響關(guān)系。

基于以上分析，對本文設(shè)計的平臺進行系統(tǒng)動力學(xué)分析如下：由于平臺是一個非線性時變系統(tǒng)，影響其性能的因素不僅包括管理節(jié)點、消息中間件、Hadoop集群等，還包含網(wǎng)絡(luò)帶寬、服務(wù)器配置等客觀因素。根據(jù)系統(tǒng)建模目的，可以知道系統(tǒng)邊界應(yīng)該包括如下因素：用戶請求數(shù)目、數(shù)據(jù)采集模塊采集到的輸入數(shù)據(jù)、消息中間件隊列中的消息數(shù)量、消息中間件路由消息的延遲、Hadoop集群的性能等。

平臺的系統(tǒng)邊界確定后，接下來需要分析系統(tǒng)邊界內(nèi)的元素間的影響關(guān)系，以及它們之間是否有因果關(guān)系。經(jīng)分析可知，用戶請求的增加會導(dǎo)致消息中間件隊列中的消息增加，而消息中間件路由消息的延遲降低會降低系統(tǒng)中消息傳遞的整體時延。

消息中間件的工作性能和系統(tǒng)各個模塊的工作時延組成正反饋回路，說明消息中間件和系統(tǒng)模塊是正相關(guān)的，所以平臺整體性能的提升依賴于消息中間件和系統(tǒng)模塊的合理資源配置。

消息中間件的各種配置參數(shù)，比如響應(yīng)速度、吞吐量等參數(shù)對提升平臺的分析性能影響很大，在優(yōu)化消息中間件的各種參數(shù)后，比較本文設(shè)計的基于大數(shù)據(jù)的數(shù)據(jù)分析平臺和傳統(tǒng)的工業(yè)數(shù)據(jù)平臺的性能，在同時對PB級別的工業(yè)數(shù)據(jù)進行分析時，當(dāng)CPU數(shù)目相同時，響應(yīng)速度的結(jié)果如表2所示：

對于不同的數(shù)據(jù)級別，兩種大數(shù)據(jù)平臺的處理效果如表3所示：

由結(jié)果可知，在處理相同的數(shù)據(jù)量時，在響應(yīng)速度的性能上，本文設(shè)計的工業(yè)數(shù)據(jù)分析平臺要優(yōu)于傳統(tǒng)的數(shù)據(jù)分析平臺。

當(dāng)處理不同的數(shù)據(jù)量時，隨著數(shù)據(jù)量的增加，傳統(tǒng)的大數(shù)據(jù)處理平臺的處理時間也呈現(xiàn)顯著增加，而本文設(shè)計的大數(shù)據(jù)處理平臺處理時間是線性的，明顯優(yōu)于傳統(tǒng)大數(shù)據(jù)處理平臺。

五、總結(jié)與展望

本文首先介紹了Hadoop大數(shù)據(jù)技術(shù)，分析了其HDFS文件系統(tǒng)和MapReduce計算框架；

接下來對基于大數(shù)據(jù)技術(shù)的CIMS海量工業(yè)數(shù)據(jù)監(jiān)測和分析平臺進行設(shè)計，從軟件結(jié)構(gòu)、通信方式以及數(shù)據(jù)存儲方式等各個方面進行了分析。最后利用系統(tǒng)動力學(xué)的原理，對影響平臺性能的因素進行了研究。

與Duke能源公司模擬的大數(shù)據(jù)解決方案相比，本文設(shè)計的平臺已經(jīng)能夠采集、分析并處理海量數(shù)據(jù)，真正意義上在工業(yè)領(lǐng)域引入了大數(shù)據(jù)技術(shù)；而且此平臺還能夠處理來自多個數(shù)據(jù)源的數(shù)據(jù)，比通用電氣的大數(shù)據(jù)分析平臺具備一定的優(yōu)勢。

參 考 文 獻(xiàn)

[1] 韓燕波，趙卓峰.面向大規(guī)模感知數(shù)據(jù)的實時數(shù)據(jù)流處理方法及關(guān)鍵技術(shù)[J].計算機集成制造系統(tǒng).2013，19（3）：641-653.

[2] 鄧華鋒，劉云生，肖迎元. 分布式數(shù)據(jù)流處理系統(tǒng)的動態(tài)負(fù)載平衡技術(shù)[J]. 計算機科學(xué). 2007（07）

[3] 胡茂勝.基于數(shù)據(jù)中心模式的分布式異構(gòu)空間數(shù)據(jù)無縫集成技術(shù)研究[D].武漢：中國地質(zhì)大學(xué)，2012.

[4] 楊林青，李湛，牟雁超等.面向大規(guī)模數(shù)據(jù)集的并行化Top-k Skyline查詢算法[J].計算機科學(xué)與探索.2014， 12（26）.

[5] J.Jiang， J. Lu， G. Zhang， and G. Long. Scaling-up item-based collaborative filtering recommendation algorithm based on hadoop. SERVICES， pp. 490 -497， 2011.

[6] 王黎維，黃澤謙，羅敏，彭智勇. 集成對象代理數(shù)據(jù)庫的科學(xué)工作流服務(wù)框架中的數(shù)據(jù)跟蹤[J]. 計算機學(xué)報. 2008（05）

[7] 多雪松，張晶，高強. 基于Hadoop的海量數(shù)據(jù)管理系統(tǒng)[J]. 微計算機信息. 2010（13）

[8] 陳康，鄭緯民. 云計算：系統(tǒng)實例與研究現(xiàn)狀[J]. 軟件學(xué)報. 2009（05）