段軍　張翔

摘 要： 分析了煤礦企業(yè)備件儲備定額的構(gòu)成以及計算過程中存在的不足，針對原來基于串行處理技術(shù)的備件消耗量預測方法執(zhí)行效率低，傳統(tǒng)的并行計算模式關(guān)于節(jié)點失效和負載均衡問題沒有好的解決方案，提出了基于Hadoop平臺實現(xiàn)備件消耗量預測的設計方法，對概率統(tǒng)計分析方法進行改進，并給出其在Hadoop平臺的MapReduce編程模型上的執(zhí)行流程。在Hadoop平臺上對改進的備件預測方法進行測試，并與傳統(tǒng)的方法進行對比，結(jié)果證明，改進后的方法時間耗費小，可擴展性高。

關(guān)鍵詞： Hadoop； 備件； 概率統(tǒng)計分析法； MapReduce

中圖分類號：TP393 文獻標志碼：A 文章編號：1006-8228（2014）05-10-04

Abstract： The composition of reserving quota in the coal mining enterprises and the deficiency existing in the calculation of minimum storage process are analyzed. The original spare parts consumption prediction method based on serial processing execution efficiency is low. The traditional parallel computing mode cannot handle node failure and it is also difficult to deal with issues such as load balancing. The spare parts consumption forecast based on the Hadoop platform is proposed， probability and statistics analysis method has been improved. The implementation process of the improved algorithm based on the MapReduce programming model is given. The improved spare part prediction method is tested on Hadoop platform and compared with the traditional method. The experimental results show that the improved method is less time consuming， and higher extensibility.

Key words： Hadoop； the spare parts； probability and statistics analysis； MapReduce

0 引言

某煤礦集團公司成功引進了SAP公司的ERP（Enterprise Resource Planning）系統(tǒng)，ERP系統(tǒng)的使用給企業(yè)帶來了先進的管理理念，建成了完整的企業(yè)資原管理體系和高效、便捷的信息技術(shù)平臺。但是，其ERP系統(tǒng)里分析和計算備件儲備定額的功能側(cè)重于機械制造等備件消耗規(guī)律性較強的行業(yè)，對于煤礦企業(yè)這類備件消耗隨需求變化的行業(yè)起不到應有的作用，所以我們?yōu)榇碎_發(fā)了備件儲備定額系統(tǒng)來對備件信息進行管理，協(xié)助業(yè)務人員制定備件采購計劃，自動提示所需訂貨的備件等。

但是，隨著系統(tǒng)的使用，一些問題也緊跟著暴露出來。如儲備定額系統(tǒng)對于日常少量備件做消耗量預測可以在較短的時間內(nèi)很好地完成，但在年中需要為下半年作訂購計劃或為來年制定訂購計劃的時候，因為其備件庫龐大（現(xiàn)常用備件有29萬多種，歷史出入庫存記錄數(shù)據(jù)更多），做消耗量預測時花費時間很長；而隨著Hadoop云計算平臺在各個領(lǐng)域的運用很好地證明了其對海量數(shù)據(jù)的存儲能力和并行計算能力，為大量備件的消耗量預測提供了一種新的解決方式。將Hadoop平臺技術(shù)與煤礦企業(yè)備件儲備定額并行化研究結(jié)合起來是一種很新穎的想法，目前還處于探索階段，也是本文主要研究的內(nèi)容，我們將研究如何解決煤礦企業(yè)備件管理所面臨的難題。

1 基于Hadoop的備件消耗預測系統(tǒng)框架

利用云計算平臺實現(xiàn)備件消耗預測，可解決大數(shù)據(jù)集運算和存儲，并能夠保證系統(tǒng)的可擴展性。國際與國內(nèi)已經(jīng)有一些學者在云計算平臺的利用上進行了相關(guān)的研究和應用，如利用開源云計算平臺Hadoop進行海量數(shù)據(jù)分析研究[6]，在電力行業(yè)進行的海量數(shù)據(jù)存儲和安全性研究[7]，在數(shù)據(jù)挖掘方面利用Hadoop平臺進行的研究等。借鑒這些研究，筆者在開源云平臺Hadoop上進行備件消耗預測的研究，其系統(tǒng)架構(gòu)如圖1所示，主要包括數(shù)據(jù)收集模塊、數(shù)據(jù)預處理模塊和概率統(tǒng)計分析模塊。

1.1 數(shù)據(jù)采集模塊

系統(tǒng)按需要輸入日期，調(diào)用PI將某大型煤炭集團SAP系統(tǒng)中備件的相關(guān)數(shù)據(jù)，如備件出庫與入庫量、備件信息、各個庫存點備件庫存等，這些信息被傳送到本地數(shù)據(jù)庫中可用于分析、計算。數(shù)據(jù)獲取時，系統(tǒng)通過觸發(fā)接口到PI的Web Service，并向PI傳遞日期（年月），PI傳遞到SAP系統(tǒng)中實時計算庫存、計劃量、未清訂單以及出入庫量，PI調(diào)用定額系統(tǒng)的Web Services完成數(shù)據(jù)的同步傳輸。

1.2 數(shù)據(jù)預處理模塊

獲取到備件相關(guān)數(shù)據(jù)后，需要對所獲得的數(shù)據(jù)進行數(shù)據(jù)整理和統(tǒng)計、頻數(shù)分析，以及裕度系數(shù)計算。具體方法如下。

⑴ 備件出入庫數(shù)據(jù)整理，即根據(jù)備件基本信息和大量備件出入庫信息，選擇出某備件兩年的消耗數(shù)據(jù)（以月為單位），插入到Oracle數(shù)據(jù)庫的備件整理表中。

⑵ 查詢Oracle數(shù)據(jù)庫備件整理表中某備件兩年內(nèi)的消耗數(shù)據(jù)，通過對其分析，進行選擇性分組，把每組的組中值，頻率，以及備件號插入到Oracle數(shù)據(jù)庫的備件頻制表中。

⑶ 把頻制表中的記錄根據(jù)備件號，分別把頻率值和組中值插入到

⑷ 建立基于資金占用和關(guān)鍵性的備件評估數(shù)學模型，得到用來彌補預測偏差的裕度系數(shù)k，根據(jù)備件號插入到Oracle數(shù)據(jù)庫備件本信息表中。

1.3 概率統(tǒng)計分析模塊

筆者利用開源的Hadoop云計算平臺對備件消耗量預測算法（概率統(tǒng)計分析法）進行MapReduce并行化設計，并在Hadoop平臺上實現(xiàn)MapRedece化備件消耗量預測算法，利用該算法計算備件的平均月消耗量。根據(jù)備件的平均月消耗量可以得到訂貨周期內(nèi)的預測消耗量。概率統(tǒng)計分析法描述如下[11-12]。

⑴ 收集數(shù)據(jù)。概率統(tǒng)計分析法對數(shù)據(jù)的要求很低，只需對消耗量進行定期統(tǒng)計。這對企業(yè)而言較為方便。

⑵ 對數(shù)據(jù)進行整理，編制頻數(shù)表。

⑶ 計算平均消耗量。

2.1 Hadoop平臺簡介

Hadoop是一個由Apache軟件基金會開發(fā)的開源分布式云計算平臺，大數(shù)據(jù)的存儲和分布式處理能力顯著。Hadoop已經(jīng)成為包含許多項目的集合，核心包括Hadoop分布式文件系統(tǒng)（Hadoop Distributed File System，HDFS）和MapReduce分布式計算模型（Google MapReduce的開源實現(xiàn)），Hadoop分布式基礎(chǔ)架構(gòu)的底層細節(jié)對用戶來說是透明的。HDFS的高容錯、高伸縮等特性使得用戶在廉價、低配的硬件上部署Hadoop成為可能；MapReduce分布式編程模型使開發(fā)并行應用程序更加簡單，開發(fā)者不必了解分布式系統(tǒng)底層細節(jié)。用戶可以利用Hadoop方便的架構(gòu)資源，搭建自己的工作集群，充分利用搭建集群的計算和存儲能力，解決海量數(shù)據(jù)的存儲和運算問題[4]。

Hadoop在分布式存儲和分布式計算方面有著非凡的能力2.2 概率統(tǒng)計分析法MapReduce化分析和設計

根據(jù)MapReduce的計算框架，大致可以分為兩個階段：Map階段和Reduce階段。

Map階段：需要處理的輸入數(shù)據(jù)會被MapReduce框架提供的函數(shù)InputFormat分割成大小一定的片段Splits。MapReduce計算框架會根據(jù)被分割的分塊的數(shù)量來創(chuàng)建等量的Map任務，同時將每個Splits片段進一步分解為形式的鍵值對作為Map函數(shù)的輸入?yún)?shù)。然后用戶自己定義的Map函數(shù)接收Map函數(shù)的輸入?yún)?shù)，產(chǎn)生一個中間鍵值對，框架會對每個鍵值對的Key值進行排序整合，把所有相同Key值的value合并到一起形成一個新的鍵值對列表{Key，List（Value）}并將其傳遞給Reduce。

Reduce階段：根據(jù)MapReduce計算框架，把不同Mapper接收到的數(shù)據(jù)整合，進行排序處理，同時調(diào)用用戶編寫的reduce函數(shù)進行處理。

將概率統(tǒng)計分析法中平均月消耗量的計算轉(zhuǎn)換成矩陣相乘的形式，構(gòu)建MapReduce算法，將數(shù)據(jù)解析整理放在Map階段，運算放在Reduce階段執(zhí)行。

以下給出算法的步驟。

⑴ 備件處理信息的存儲。針對Hadoop平臺的MapReduce計算框架，把待處理備件信息按備件號、行、列、組中值、頻率分為兩個文件，存儲在Hadoop分布式文件系統(tǒng)HDFS中。

⑵ 在Map函數(shù)中，同時遍歷兩個文件，進行解析整理操作，形成輸入鍵值對，并對鍵值對進行處理，構(gòu)造輸出鍵值對Key/value。

⑶ 中間結(jié)果處理，對Map函數(shù)輸出的鍵值對進行整合處理，把Key值相同的Value合并到一起，形成一個新的鍵值對輸出列表，傳遞給Reduce函數(shù)。

⑷ 在Reduce函數(shù)中，遍歷輸入的鍵值對列表，進行乘積和累加運算，得到最終結(jié)果。

2.3 Hadoop平臺實現(xiàn)概率統(tǒng)計分析法

基于上述MapReduce化概率統(tǒng)計分析法的描述，下面介紹該算法在Hadoop平臺的MapReduce計算框架的具體執(zhí)行流程：

⑴ 將測試樣本備件消耗量頻數(shù)表，按照{(diào)備件編碼、行、組中值}、{備件編碼、列、頻率}的形式存儲在Hadoop分布式文件系統(tǒng)HDFS中，由SequenceFile類進行存儲工作。其中i代表矩陣中的行值，j代表矩陣中的列值。

⑵ Map函數(shù)讀取HDFS中兩個文件，以[key，value]的形式輸入每一項數(shù)據(jù)。Key是文件中行偏移量，但是在map階段的計算中我們用不到這個值，所以可以忽略。Value是存儲文件的每行的數(shù)據(jù)。Map函數(shù)是對輸入鍵值對的值進行解析，通過遍歷文件中每一行，分別截取備件編碼、行號、列號、組中值和頻率，以備件編碼為Key，（行號#組中值）、（列號#頻率）為value的輸出鍵值對。

⑶ MapReduce計算框架根據(jù)用戶自定義的函數(shù)將Map函數(shù)產(chǎn)生的中間結(jié)果進行排序整合處理，形成一個備件編碼相同的value列表。以此作為Reduce函數(shù)的輸入。

⑷ Reduce函數(shù)階段，對輸入列表中的值進行遍歷，進行result+=valA[i]*valB[j]運算。圖3展示了整個MapReduce的計算執(zhí)行過程。

MapReduce化設計的概率統(tǒng)計分析法算法，在解決節(jié)點失效和負載不易均衡這兩個問題上也取得了不錯的效果。

一是在Hadoop集群中，如果其中某一臺計算機發(fā)生故障從而停止工作，那么被這臺計算機上運行的計算任務會被轉(zhuǎn)移交接給集群中沒有任務處理而處于空閑狀態(tài)的計算機處理。

二是Hadoop上處理的任務塊數(shù)可以變動，不論計算任務的大小，可以通過更改配置文件的手段來設定每個Map數(shù)據(jù)塊的大小，以使所處理的任務塊數(shù)遠大于集群中計算機的節(jié)點數(shù)，這樣，寶貴的計算資源就不會被浪費，也可以達到負載均衡的目的。

3 實驗結(jié)果與分析

3.1 實驗環(huán)境

本實驗選取三臺計算機搭建Hadoop平臺，計算機系統(tǒng)采用 Ubuntu Linux 10.10，Hadoop版本選用Hadoop—1.1.2，一臺機器作為Master和JobTracker服務節(jié)點3.2 實驗數(shù)據(jù)選取

選取某大型煤炭集團備件消耗記錄為實驗數(shù)據(jù)，實驗數(shù)據(jù)分為Bjdb1、Bjdb2、Bjdb3和Bjdb4四個大小不同的數(shù)據(jù)集，它們的大小分別為：1000、10000、100000和1000000條備件消耗記錄。每組的消耗記錄分別由備件的編號、組中值、頻率組成。

3.3 實驗結(jié)果及分析

實驗內(nèi)容為：分別采用上面選定的大小不同的四個數(shù)據(jù)集，比較C/S模式和hadoop平臺的MapReduce模式下的備件預測消耗量的計算，即概率統(tǒng)計分析算法的實現(xiàn)所需要的時間。實驗的硬件環(huán)境是在實驗室局域網(wǎng)內(nèi)的PC機上。

在上述實驗中，數(shù)據(jù)的規(guī)模是逐漸增長的，實驗情況如表3所示（T1為C/S模式單機上運行串行算法所用時間；T2為運行MapReduce化設計的算法所用時間）。

c/s模式處理數(shù)據(jù)所用時間的消耗增長較快，呈線性增長直到100萬條數(shù)據(jù)集時機器宕機。而MapReduce并行計算方式處理數(shù)據(jù)的時間消耗隨著數(shù)據(jù)集的增長緩慢增長，最終完成100萬條記錄運算所需的時間開銷很小。在測試數(shù)據(jù)集較小的情況下，MapReduce化設計的并行計算方式的時間性比不上C/S模式，C/S模式在小數(shù)據(jù)量時機器性能尚能滿足計算要求，機器內(nèi)的通信要比機器間的通信節(jié)省時間，master節(jié)點和slave節(jié)點通信、slave節(jié)點并發(fā)處理數(shù)據(jù)會比C/S模式耗費時間，所以C/S模式下所消耗的時間要比MapReduce模式下少。而當數(shù)據(jù)量逐漸增大時，C/S模式下的單機運算要遠遠遜色于Hadoop集群的強大計算能力，C/S模式要想獲得與Hadoop集群相應的能力就要增加硬件性能。由此可知，Hadoop集群不適合小數(shù)據(jù)量的處理，而更適合處理大數(shù)據(jù)量的計算。

4 結(jié)束語

本文對于煤礦企業(yè)備件儲備定額系統(tǒng)在備件預測消耗量的計算上做了改進，提出基于Hadoop 平臺對備件消耗量預測進行MapReduce化設計，并在Hadoop平臺上實現(xiàn)MapReduce化備件消耗量預測算法。從實驗結(jié)果可以看出，在處理大規(guī)模數(shù)據(jù)集時，基于 Hadoop 平臺改進的預測消耗量算法執(zhí)行效率上有較好的表現(xiàn)，而且基于Hadoop的計算具有更加好的移植性和容錯性。下一步，筆者將嘗試Oracle數(shù)據(jù)庫和Hadoop平臺的連接處理，不用從數(shù)據(jù)庫中導出數(shù)據(jù)，直接以數(shù)據(jù)庫中的待處理表為輸入MapReduce并行化模型中Map階段的輸入，Reduce階段輸出結(jié)果直接寫入到數(shù)據(jù)庫相關(guān)表中，使得執(zhí)行效率進一步提升。

參考文獻：

[1] 王意潔，孫偉東，周松.云計算環(huán)境下的分布存儲關(guān)鍵技術(shù)[J].軟件學

報，2012.23（4）：962-986

[2] 劉鵬.云計算[M].電子工業(yè)出版社，2010.

[3] 維基百科.云計算[EB/OL].http：//zh.wikipedia.org/wiki/云計算，

2011.10.23.

[4] 劉鵬.實戰(zhàn)Hadoop——開啟通向云計算的捷徑[M].電子工業(yè)出版

社，2011.

[5] Michael Armbrust.Above the clouds： A Berkeley View of Cloud

Computing[EB/OL].http：//www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf，2009.2.10.

[6] 王敬昌.基于Hadoop分布式計算架構(gòu)的海量數(shù)據(jù)分析[J].數(shù)字技術(shù)

與應用，2010.7.

[7] 朱珠.基于Hadoop的海量數(shù)據(jù)處理模型研究和應用[D].北京郵電大

學，2008.

[8] 張少敏，李曉強，王保義.基于Hadoop的智能電網(wǎng)數(shù)據(jù)安全存儲設計[J].

電力系統(tǒng)保護與控制，2013.41（14）：136-140

[9] 胡志剛，梁曉楊.基于Hadoop的海量網(wǎng)格數(shù)據(jù)建模[J].計算機系統(tǒng)應

用，2010.19（10）：191-194

[10] 余楚禮.基于Hadoop的并行關(guān)聯(lián)規(guī)則算法研究[D].天津理工大學，

2011.

[11] 段軍，郭穎.煤礦企業(yè)備件儲備定額的研究[J].煤礦機械，2011.32

（11）：70-72

[12] 郭穎.煤礦企業(yè)備件動態(tài)儲備定額管理系統(tǒng)的研究[D].內(nèi)蒙古科技

大學，2011.

[13] 謝娟，何嘉鵬，張葉，閻麗萍.基于C#地鐵站安全疏散模糊綜合評價

系統(tǒng)的開發(fā)與應用[J].南京工業(yè)大學學報，2007.29（6）：28-31

[14] 李玲，任青，付園，陳鶴，梅圣民.基于Hadoop的社交網(wǎng)絡服務推薦

算法[J].吉林大學學報，2013.31（4）：359-364