胡偉英

（山西焦煤集團霍州煤電集團店坪煤礦，山西 方山 041600）

在店坪煤礦井下設(shè)備較多且分布雜亂，收集數(shù)據(jù)的種類較多且較為離散，將數(shù)據(jù)集中記錄以及集中處理的難度較大，同時對于數(shù)據(jù)中心的維護比較困難，容易出現(xiàn)信息孤島問題。為了方便煤礦的數(shù)據(jù)管理，本文依托大數(shù)據(jù)技術(shù)進行數(shù)據(jù)管理平臺的設(shè)計[1-4]，旨在順利完成數(shù)據(jù)的存儲與管理，同時實現(xiàn)企業(yè)化的分布式數(shù)據(jù)管理。

1 Hadoop 設(shè)備運行狀態(tài)管理平臺需求分析

1.1 Hadoop 平臺數(shù)據(jù)源分析

在大數(shù)據(jù)技術(shù)上設(shè)備運行狀態(tài)管理數(shù)據(jù)平臺中，數(shù)據(jù)主要來源如下所示：

1）機電設(shè)備的基礎(chǔ)信息。主要是圍繞井下各大系統(tǒng)包括供電、通風、壓風、排水等系統(tǒng)中各個關(guān)鍵設(shè)備，通過其基礎(chǔ)信息包括型號、額定參數(shù)等錄入，管理員可以通過系統(tǒng)對所有設(shè)備的基礎(chǔ)信息進行查閱，確保工作的高效進行。

2）設(shè)備的運維以及檢修信息。由于井下環(huán)境的特殊性，井下很多設(shè)備需要進行定期維護與檢修，通過供應商提供的壽命標準，要按期進行零部件的更換，嚴控設(shè)備的檢修，保證井下生產(chǎn)的安全。

1.2 Hadoop 平臺需求功能分析

井下設(shè)備運行狀態(tài)管理平臺是一個集成化的系統(tǒng)，由很多設(shè)備管理小部門組合而成。為保證管理平臺的正常運轉(zhuǎn)，其下的小部門需要在同一個平臺上進行工作的協(xié)調(diào)，在相同的服務器下進行記錄以及查詢工作，確保值班人員在進行交班前，下一個值班人員能通過平臺數(shù)據(jù)記錄了解設(shè)備的運行狀態(tài)與記錄的相符性。為了實現(xiàn)上述功能，數(shù)據(jù)平臺的功能需求如下：

1）數(shù)據(jù)在線錄入。首先在進行設(shè)備的檢查以及日常維護時，工作人員能夠通過平臺的在線功能，進行在線錄入，主要包括排班信息、設(shè)備運行狀態(tài)信息、故障信息以及故障排查信息等。

2）數(shù)據(jù)在線檢索。在平臺中存儲有海量的信息，需要定位查找，難度較大，需要有在線檢索功能，通過查詢，可以直接找到想要的信息。

3）數(shù)據(jù)導出功能。在線錄入的信息，可以按照時間的排序，實時存儲在Excel 中，通過平臺的導出功能實現(xiàn)數(shù)據(jù)的下載導出打印，方便查詢等。

除了上述的平臺功能要求，還有一定的非功能性的需求。其中就有數(shù)據(jù)一致性的要求，確保平臺中數(shù)據(jù)的準確性以及實時性；海量的存儲空間要求，設(shè)備信息以及人員信息較多，對于存儲空間的要求較大，要保證空間足夠；讀寫延遲小，平臺信息更新頻次多、頻率快，對讀寫功能有一定的要求。

2 大數(shù)據(jù)技術(shù)下Hadoop 平臺設(shè)計

礦井機電信息由三部分組成，包括運行數(shù)據(jù)、監(jiān)控數(shù)據(jù)以及信息文檔。為了將信息簡化，需要對信息進行轉(zhuǎn)換，將數(shù)據(jù)統(tǒng)一為XML 文本格式。為確保平臺數(shù)據(jù)精確集成，平臺需要讀取各個站點的運行信息以及圖紙信息，保證數(shù)據(jù)管理的有序開展。這樣一來，數(shù)據(jù)平臺就有實時監(jiān)控、數(shù)據(jù)管理以及運行監(jiān)控等功能。為確保數(shù)據(jù)平臺快速存儲以及快速處理等功能，需要將站內(nèi)的各個網(wǎng)絡接口進行連接。目前由于數(shù)據(jù)平臺越來越完整，搭建的標準也越來越高。數(shù)據(jù)管理平臺的設(shè)計是以Hadoop 平臺為基礎(chǔ)，在最大程度保留原有平臺的基礎(chǔ)上，配備集群部署計算機，同時在目標計算機上搭建虛擬機。通過結(jié)合大數(shù)據(jù)技術(shù)，Hadoop 平臺擁有強大的計算能力，同時擁有高容量的存儲能力。圖1 為Hadoop平臺設(shè)備運行狀態(tài)數(shù)據(jù)管理平臺總體設(shè)計結(jié)構(gòu)圖。

圖1 總體設(shè)計結(jié)構(gòu)圖

從圖1 可以看出，Hadoop 數(shù)據(jù)管理平臺可以分為四大部分，包括數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)存儲、數(shù)據(jù)分析。數(shù)據(jù)采集主要是通過井下各個設(shè)備上的傳感器完成信息的采集，包括溫度、濕度、轉(zhuǎn)速等，再通過PLC 以及以太網(wǎng)組合完成采集數(shù)據(jù)的上傳工作，將數(shù)據(jù)傳輸?shù)降孛婀芾碇行?。?shù)據(jù)轉(zhuǎn)換是將數(shù)據(jù)通過XML文本格式的媒介進行數(shù)據(jù)的規(guī)范化處理，避免了數(shù)據(jù)各自孤立的問題存在。數(shù)據(jù)存儲是將轉(zhuǎn)換完成的數(shù)據(jù)進行指定位置的存儲，存儲過程分為兩部分，一部分是通過Redis 將實時數(shù)據(jù)進行傳輸同時將其暫時儲存在內(nèi)存中便于上層實時顯示數(shù)據(jù)；另一部分是將以往數(shù)據(jù)通過文件系統(tǒng)保存在HBase各節(jié)點容器中，方便數(shù)據(jù)的讀取。在遠程服務器中需要實時顯示各煤礦的信息，也是從Redis 直接調(diào)取。平臺的最后工作是數(shù)據(jù)的分析，同時根據(jù)分析結(jié)果作出判斷與決策。通過數(shù)據(jù)分析掌控井下的運轉(zhuǎn)情況，還可以實現(xiàn)異常數(shù)據(jù)的排除，同時在大數(shù)據(jù)技術(shù)的基礎(chǔ)上進行數(shù)據(jù)對比分析、故障診斷等。

3 Hadoop 平臺子系統(tǒng)的設(shè)計

3.1 OPC UA 協(xié)議基礎(chǔ)數(shù)據(jù)采集系統(tǒng)設(shè)計

為了實現(xiàn)井下的機電設(shè)備數(shù)據(jù)采集驅(qū)動標準一致，能夠通過傳感器將反饋的數(shù)據(jù)進行統(tǒng)一的處理，因此基于OPC UA 協(xié)議搭建了每組數(shù)據(jù)的存儲地址，按照一致的采集協(xié)議實現(xiàn)各個設(shè)備之間信息的交互，同時也能夠解決現(xiàn)在由于遠程集成系統(tǒng)導致的數(shù)據(jù)不通的問題。

數(shù)據(jù)采集系統(tǒng)的結(jié)構(gòu)組成如圖2。

圖2 采集系統(tǒng)結(jié)構(gòu)組成圖

采集系統(tǒng)中本地服務器通過以太網(wǎng)與工業(yè)網(wǎng)絡相連接，同時以網(wǎng)絡為路徑，將本地服務器PC 作為客戶端，形成C/S 形式的本地數(shù)據(jù)采集系統(tǒng)。在對各個設(shè)備進行數(shù)據(jù)采集時，通過多線程的模式，實現(xiàn)同時采集。采集結(jié)束后將數(shù)據(jù)進行解析封裝之后傳遞到相應的地址空間，再上傳到云服務器中，完成數(shù)據(jù)的存儲，為后續(xù)的分析處理做準備。

3.2 MapReduce 特征的數(shù)據(jù)提取

在Hadoop 平臺中，集群批處理框架被稱為MapReduce，依靠框架本身的分布式計算環(huán)境來提供相應的計算模式。其計算模式主要來源于框架的兩大功能，即Map 和Reduce。其代表的是兩種函數(shù)，分別是映射函數(shù)Mapper 和歸約函數(shù)Reducer。在數(shù)據(jù)處理過程中首先在Map 中進行篩選以及轉(zhuǎn)換，之后數(shù)據(jù)會進行Reduce 歸約，完成數(shù)據(jù)規(guī)模收縮，再通過Reducer 聚合功能來獲得最終的結(jié)果。圖3為MapReduce 結(jié)構(gòu)圖。

圖3 MapReduce 結(jié)構(gòu)圖

在完成數(shù)據(jù)采集存儲之后，需要對特征數(shù)據(jù)完成提取，方便后續(xù)的分析。數(shù)據(jù)提取流程如圖4。

圖4 特征數(shù)據(jù)提取過程

3.3 Redis 技術(shù)下的數(shù)據(jù)傳輸架構(gòu)

Redis 技術(shù)下的數(shù)據(jù)傳輸層作為連接采集層與上機監(jiān)管端之間的橋梁，在Hadoop 平臺下，起著關(guān)鍵的作用。Redis 技術(shù)具有數(shù)據(jù)讀寫快、數(shù)據(jù)緩存持久、交互模式多等特點，可以通過發(fā)布以及訂閱兩種模式將數(shù)據(jù)進行傳輸，實現(xiàn)了數(shù)據(jù)從客戶端到服務端的傳輸，極大地縮短了數(shù)據(jù)的傳輸時間。由于其內(nèi)部的分布式緩存功能，可以將解析的數(shù)據(jù)暫存在Redis 數(shù)據(jù)庫中，減小了數(shù)據(jù)丟失的問題。圖5 為Redis 的兩種模式。

圖5 Redis 發(fā)布/訂閱模式

3.4 HBase 技術(shù)下的數(shù)據(jù)存儲

圖6 為HBase 技術(shù)下數(shù)據(jù)存儲流程圖。在整個過程中，首先通過OPC 服務器來獲取設(shè)備的實時狀態(tài)數(shù)據(jù)，將數(shù)據(jù)進行XML 文檔格式的轉(zhuǎn)換，后到達用戶界面終端對設(shè)備數(shù)據(jù)進行操作。一旦數(shù)據(jù)中心收到終端查詢指令后，平臺內(nèi)Yarn 實物調(diào)動引擎將會對指派的任務進行分解。對于實時類數(shù)據(jù)存儲，會根據(jù)業(yè)務規(guī)則完成數(shù)據(jù)的計算，將計算結(jié)果歸納到存儲區(qū)內(nèi)，再按照多個數(shù)據(jù)完成節(jié)點來進行數(shù)據(jù)存儲；對于文檔類文件，將會根據(jù)屬性自動識別為標準格式進行存儲。根據(jù)數(shù)據(jù)節(jié)點完成的緩存，將會按照Yam 指令程序分解任務進行逐一完成：首先實時數(shù)據(jù)到達緩存區(qū)，按照時間的先后順序?qū)?shù)據(jù)進行接收排序；隨后數(shù)據(jù)到達計算區(qū)，Yarn 實物引擎會通過發(fā)出的調(diào)度指令接收下發(fā)的歷史數(shù)據(jù)集，將數(shù)據(jù)存儲在實時數(shù)據(jù)緩存區(qū)內(nèi)；緊接著對HBase 數(shù)據(jù)庫進行容量檢測，若發(fā)現(xiàn)資源充足，將會被立即送到數(shù)據(jù)庫中，若空間不足，會將其暫存在Redis 中，待資源充足后再進行傳輸。

圖6 HBase 技術(shù)下數(shù)據(jù)存儲流程圖

4 結(jié)論

本文以數(shù)據(jù)監(jiān)測平臺為研究對象，為了解決目前出現(xiàn)的數(shù)據(jù)雜亂難集中、難處理、難維護、難流通等的問題，以大數(shù)據(jù)技術(shù)為依托，對設(shè)備狀態(tài)Hadoop 平臺進行設(shè)計，再分別對Hadoop 平臺4 大組成系統(tǒng)進行設(shè)計，分別是數(shù)據(jù)采集、數(shù)據(jù)提取、數(shù)據(jù)傳輸以及數(shù)據(jù)存儲，成功將難集中、難處理、信息孤島等問題解決，實現(xiàn)海量數(shù)據(jù)的有序化存儲，為數(shù)字化礦山注入自己的一份力量。