基于Hadoop的Aprior算法改進(jìn)及其在動車組運維的應(yīng)用

任廣強，舒 敏

（1.中車青島四方機車車輛股份有限公司，青島 266111；2.北京交通大學(xué) 計算機與信息技術(shù)學(xué)院，北京 100044）

當(dāng)今中國高鐵發(fā)展位居世界之巔[1]，鐵路網(wǎng)的建設(shè)迅速拓寬，列車調(diào)度密度增大，維修間隔變短，安全問題日益重要。列車在實際運行過程中，由于外部環(huán)境的影響或者零部件磨損以及欠維修等因素，會導(dǎo)致各類不同故障發(fā)生[2]，因此提高動車組運行維修效率迫在眉睫。由于傳感器技術(shù)快速發(fā)展，保留了大量的動車組運維以及故障數(shù)據(jù)，通過對這些數(shù)據(jù)的分析和挖掘，可以探索出運維或者故障規(guī)律，從而有助于指導(dǎo)運維決策。但是當(dāng)今數(shù)據(jù)增長速度快，存儲成本高、流動性大等特點，制約著動車組數(shù)據(jù)挖掘效率的提高[3]。

隨著大數(shù)據(jù)技術(shù)的出現(xiàn)和發(fā)展，基于Hadoop的動車組故障數(shù)據(jù)關(guān)聯(lián)規(guī)則挖掘算法顯示出巨大的優(yōu)勢，相對于傳統(tǒng)挖掘算法，效率更高，耗時更少，對動車組故障數(shù)據(jù)分析效率和動車組故障診斷實時性有大幅提升。高子喆通過改進(jìn)的傅里葉變換（FFT）算法加快高鐵信息變化過程[4]。趙成兵等人設(shè)計實現(xiàn)了基于Hadoop平臺的高鐵振動數(shù)據(jù)的預(yù)處理實現(xiàn)系統(tǒng)[5]。數(shù)據(jù)挖掘算法中最經(jīng)典的當(dāng)屬Apriori算法[6]，但是該算法耗時較長，面對日益增長的數(shù)據(jù)，數(shù)據(jù)挖掘算法的并行化將有效地提高挖掘效率[7]。Agrawal R.提出了諸如計數(shù)分布和數(shù)據(jù)分布等方法來改進(jìn)Apriori算法，但是該算法在通信和同步過程中也存在明顯的缺點[8]。

因此，本文在分析解決大數(shù)據(jù)問題的Hadoop技術(shù)以及傳統(tǒng)關(guān)聯(lián)分析挖掘算法Apriori算法的基礎(chǔ)上，將兩者進(jìn)行有效的結(jié)合，使其進(jìn)一步提升挖掘效率。

1 理論及相關(guān)技術(shù)介紹

1.1 Hadoop概述

Hadoop是一個專門為離線和大規(guī)模數(shù)據(jù)分析設(shè)計的開源框架，通過分布式來處理海量數(shù)據(jù)。大數(shù)據(jù)處理框架，它主要包括分布式文件系統(tǒng)（HDFS）、并行處理框架（MapReduce）和多種不同的組件，可以以原生格式存儲任意數(shù)據(jù)、進(jìn)行擴展以支持大數(shù)據(jù)更高的可用性。Hadoop生態(tài)圈的基本組成[9]，如圖1所示。

圖1 Hadoop相關(guān)項目

1.2 Apriori算法

數(shù)據(jù)挖掘的本質(zhì)是通過分類、聚類、關(guān)聯(lián)等方法從一堆雜亂多樣、模糊復(fù)雜的數(shù)據(jù)中尋找一個可應(yīng)用的模式或者規(guī)律，識別未知的、有價值的知識過程[10]。關(guān)聯(lián)規(guī)則挖掘領(lǐng)域的經(jīng)典代表算法為Apriori算法，基本原理是通過逐層搜索的迭代方法獲得頻繁集[11]，然后發(fā)現(xiàn)強關(guān)聯(lián)規(guī)則。

2 基于Hadoop的Apriori算法研究與改進(jìn)

傳統(tǒng)的Apriori算法缺點之一是無法滿足大數(shù)據(jù)集下的挖掘要求[12]，因此，Apriori算法在分布式環(huán)境下的并行化方案已成為新的研究方向。

2.1 算法的改進(jìn)

Hadoop的核心組件MapReduce對存儲在分布式文件系統(tǒng)中的文件進(jìn)行分布式計算的過程[13]可以很好地擴展應(yīng)用到Apriori算法中，可以完成基于大數(shù)據(jù)量下關(guān)聯(lián)規(guī)則的快速挖掘。

基于MapReduce的Apriori算法的核心思想是每次頻繁項集調(diào)用Map并減少進(jìn)程，即頻繁k項集的挖掘稱之為k次MapReduce。該算法生成頻繁k項集的時候經(jīng)常會在頻繁k-1項集迭代時候遇到如下兩個問題。

（1）Map中每個節(jié)點的計算非常不同，存在負(fù)載不平衡問題。

（2）重復(fù)讀取原始數(shù)據(jù)在大數(shù)據(jù)量的情況下導(dǎo)致的資源消耗，算法性能降低的問題。

因此，本論文在上述算法基礎(chǔ)上提出一種改進(jìn)的新算法T-MR-Apriori，改進(jìn)后的算法只需要兩個MapReduce過程，所有k個頻繁項集都可以計算出來。算法執(zhí)行流程圖，如圖2所示。

圖2 T-MR-Apriori算法運行流程

改進(jìn)后算法的第1次MapReduce過程如圖2中的實線所示，對每個Map輸入的所有數(shù)據(jù)作為一個完整數(shù)據(jù)集運用傳統(tǒng)的Apriori算法，對局部頻繁k項集進(jìn)行挖掘。其中，min_support_count（最小支持度）、partial_min_support_count（Map節(jié)點的局部最小支持?jǐn)?shù)）與該Map節(jié)點的事務(wù)數(shù)量trans_count的關(guān)系如下：

partial_min_support_count = min_support_count /trans_count 。

Map端和Reduce端實現(xiàn)的改進(jìn)后的偽代碼，如下所示：

Map輸入：Si //每一行是一個事務(wù)：

Map輸出一個鍵值對＜key，value＞，/ *鍵key是k個本地頻繁項集元素，值value是在split中計數(shù)的.*/

Reduce端輸入得到的鍵值對＜key1，value2＞：/ * 鍵值key2是局部頻繁項集k的元素，value2是key2在當(dāng)前split中的輸出：/*

其中，每一個輸出鍵值對＜key，value＞中的Key都是局部頻繁“k項集”中的元素，而value則是該元素在切割片段中的數(shù)量統(tǒng)計。Reduce將Map節(jié)點計算得到的局部頻繁k項集保存在LP中。

如圖2虛線所示，為MapReduce過程的第2次執(zhí)行。在第2次過程中，Map端輸入的是第1次計算結(jié)果中的全部局部頻繁k項集LP以及各項事務(wù)數(shù)據(jù)集。在該過程中，Map函數(shù)的作用是計算每個本地頻繁k項集元素在每個分片中的數(shù)量，而Reduce函數(shù)則是將Map端計算得到的元素的次數(shù)進(jìn)行求和，利用min_support_count，計算全局頻繁k項集，并將結(jié)果保存在Lg中。Map端和Reduce端實現(xiàn)偽代碼如下所示：

2.2 由頻繁項集產(chǎn)生關(guān)聯(lián)規(guī)則

根據(jù)最小支持度的頻繁項集，滿足最小信任度即min_conf的關(guān)聯(lián)規(guī)則可以直接生成。在MapReduce計算模型下，頻繁項集被分割成不同的分割，可以將它們分配給不同的映射節(jié)點，同時生成關(guān)聯(lián)規(guī)則。MAP端和Reduce端實現(xiàn)程序的偽代碼，如下所示：

其中，key是字符串，為生成的關(guān)聯(lián)規(guī)則，而value是該關(guān)聯(lián)規(guī)則的置信度。

2.3 算法性能評估

為了說明算法的性能，文中還對算法進(jìn)行了對比實驗，并比較了改進(jìn)算法的有效性。在這個實驗中，使用6臺普通電腦實現(xiàn)一個Hadoop集群，安裝配置CentOS 6.5系統(tǒng)[14]和Hadoop2平臺的搭建。每臺機器配置為8 G內(nèi)存、4核2.5 GHz CPU。其中，1臺計算機作為主節(jié)點和JobTracker節(jié)點，另外5臺機器作為Hadoop集群的Slave和TaskTracker節(jié)點。本文所選取的實驗數(shù)據(jù)為動車組牽引電機運維數(shù)據(jù)，均來自動車組運行維護的實際數(shù)據(jù)，并且根據(jù)大數(shù)據(jù)處理規(guī)則，進(jìn)行了符合動車組規(guī)則的數(shù)據(jù)ETL處理，剔除重復(fù)的數(shù)據(jù)、填補缺少的數(shù)據(jù)、改正不合法的數(shù)據(jù)。處理后的動車組故障數(shù)據(jù)的主要字段，如表1所示。

6個節(jié)點的Hadoop集群下，實驗分別使用了25 GB、125 GB、250 GB、350 GB數(shù)據(jù)在運行，其中50 G數(shù)據(jù)包含了約一億條事務(wù)。圖3表示的本次實驗結(jié)果，其中，支持度為1%，結(jié)果如下。

由圖3可知，數(shù)據(jù)集在成倍增長的情況下，傳統(tǒng)的基于MapReduce的Apriori算法時間消耗始終大于改進(jìn)算法的時間消耗，并且數(shù)據(jù)量越大，改進(jìn)后的算法性能越明顯。在本實驗所使用的動車組故障數(shù)據(jù)集及硬件環(huán)境條件下，T-MR-Aprior算法在挖掘速率上提高約35%。

表1 數(shù)據(jù)字段說明

圖3 不同數(shù)據(jù)規(guī)模算法性能

3 動車組牽引電機運維數(shù)據(jù)挖掘系統(tǒng)實現(xiàn)

3.1 動車組運維數(shù)據(jù)

當(dāng)前我國鐵路信息技術(shù)飛速發(fā)展，在運行過程中會積累大量的結(jié)構(gòu)化的狀態(tài)數(shù)據(jù)，它包含很多有價值的信息。動車組數(shù)據(jù)挖掘的目的是有效地挖掘隱藏故障信息，提前做出運維決策。動車組運維數(shù)據(jù)主要分為以下3類。

（1）實時監(jiān)測數(shù)據(jù)

實時監(jiān)測數(shù)據(jù)是指在實際運行過程中產(chǎn)生的各種狀態(tài)數(shù)據(jù)，包括：累計功率、距離數(shù)據(jù)、電機數(shù)據(jù)、受電弓數(shù)據(jù)和空載數(shù)據(jù)等。

（2）運行狀態(tài)數(shù)據(jù)

運行狀態(tài)數(shù)據(jù)記錄了動車組在行駛過程中的狀態(tài)數(shù)據(jù)。動車組司機可以通過運行狀態(tài)數(shù)據(jù)來監(jiān)控動車組的實時運行狀態(tài)，該數(shù)據(jù)是在動車組運維過程中不斷累積產(chǎn)生的，隱含了對動車組運維決策的指導(dǎo)意義。

（3）畫面故障數(shù)據(jù)

電視是指動車組司機信息數(shù)據(jù)可以在屏幕的駕駛室看到，不管這些數(shù)據(jù)動車組電流故障，定期發(fā)送到地面，包括圖片資料，主要的故障數(shù)據(jù)、故障記錄數(shù)據(jù)和其他信息，其中，畫面故障數(shù)據(jù)包括列車運行的基本信息以及基本環(huán)境信息，主要包括速度、里程、經(jīng)緯度等信息。

牽引電機是動車組牽引傳動系統(tǒng)的關(guān)鍵部件，控制著列車安全運行的命脈，它的運維效率高低直接關(guān)系到整個鐵路運維成本的大小，因此，本文以研究牽引電機關(guān)聯(lián)規(guī)則挖掘為代表，著重介紹動車組牽引電機挖掘系統(tǒng)的實現(xiàn)。牽引電機在制造、運行、維修、報廢等階段的全生命周期數(shù)據(jù)主要分為6個部分。

（1）基礎(chǔ)數(shù)據(jù)，即牽引電機的靜態(tài)生產(chǎn)數(shù)據(jù)，包括額定電流電壓、生產(chǎn)廠家、批次編號等；

（2）部件工作數(shù)據(jù)，即牽引電機部件的運行數(shù)據(jù)，包括定子、轉(zhuǎn)子、外圈、內(nèi)圈等不見得溫度、轉(zhuǎn)速等數(shù)據(jù)；

（3）列車運行數(shù)據(jù)，即列車運行速度、加速度、牽引電流、反饋牽引力等數(shù)據(jù)；

（4）維修履歷數(shù)據(jù)，即該牽引電機所有的運行維護數(shù)據(jù)，包括維修時間、地點、原因以及維修方式等；

（5）線路數(shù)據(jù)；

（6）環(huán)境數(shù)據(jù)。

3.2 動車組牽引電機故障數(shù)據(jù)挖掘

故障數(shù)據(jù)挖掘系統(tǒng)由數(shù)據(jù)預(yù)處理、數(shù)據(jù)挖掘系統(tǒng)和可視化展示3部分組成。數(shù)據(jù)預(yù)處理是大數(shù)據(jù)挖掘的關(guān)鍵步驟，直接決定著數(shù)據(jù)挖掘效率。如圖4所示數(shù)據(jù)預(yù)處理步驟進(jìn)行數(shù)據(jù)處理，得到干凈有效的實驗使用數(shù)據(jù)。

Hadoop集群搭建完成以后，使用牽引電機運維數(shù)據(jù)進(jìn)行關(guān)聯(lián)規(guī)則的挖掘。對動車組故障數(shù)據(jù)通過使用改進(jìn)后的T-MR-Apriori算法進(jìn)行挖掘，挖掘步驟為：

圖4 數(shù)據(jù)預(yù)處理流程圖

（1）利用上述數(shù)據(jù)預(yù)處理技術(shù)將牽引電機運維數(shù)據(jù)清理干凈；

（2）將清洗之后的結(jié)果數(shù)據(jù)存放在分布式文件系統(tǒng)HDFS中，設(shè)置好輸入輸出文件的路徑以及格式；

（3）利用現(xiàn)有的專家經(jīng)驗值，初步設(shè)定min_support（最小支持度）以及min_confi（最小置信度），計算頻繁項集；

（4）利用改進(jìn)后的T-MR-Aprior算法進(jìn)行牽引電機運維效率關(guān)聯(lián)規(guī)則挖掘，得到關(guān)聯(lián)強規(guī)則；

（5）分別對每條規(guī)則進(jìn)行支持度與置信度的重新計算。

部分關(guān)聯(lián)規(guī)則挖掘結(jié)果，如表2所示。

表2 部分挖掘結(jié)果

對 于 關(guān) 聯(lián) 規(guī) 則“CRH3，1305C， 90～ 120萬km=＞牽引電機故障[support = 2.53%，conf =8.25%]”，表示CRH3型編組編號1305C列車在達(dá)到90～120萬km的時候運維效率比較低，且容易產(chǎn)生牽引電機故障。根據(jù)專家經(jīng)驗和修程修制可得，當(dāng)動車組的行駛總里程達(dá)到90～120萬km的時候便會進(jìn)行一輪大修，在此之前的牽引電機故障率會比較高，同時導(dǎo)致故障的因素變得更為復(fù)雜，使得檢修和運維過程變得麻煩而緩慢，導(dǎo)致運維效率變低，因此該條挖掘結(jié)果是有意義的。

對于關(guān)聯(lián)規(guī)則“某地點，3月=＞通風(fēng)系統(tǒng)異常[support=2.08% conf=11.93%]”表示該地區(qū)內(nèi)，每年的3月份風(fēng)閥系統(tǒng)和通風(fēng)系統(tǒng)故障比較多，后續(xù)驗證該條規(guī)則是準(zhǔn)確的。因為查資料可得，此處區(qū)域在春夏交際之間風(fēng)沙較多，因而導(dǎo)致通風(fēng)系統(tǒng)故障率高。

高鐵運行數(shù)據(jù)量頗大，積累下來的數(shù)據(jù)經(jīng)過一定的處理能反映出許多特別的信息，關(guān)聯(lián)關(guān)系，如圖5所示，表示故障類型與各因素之間的關(guān)聯(lián)關(guān)系。圖中的圓形區(qū)域代表故障發(fā)生次數(shù)的大小，與之相連的則是故障因素，包含車型、車次、配屬局以及制造方等因素，通過該圖圓形區(qū)域的大小則可以獲得故障大小的信息，從而獲得故障發(fā)生因素關(guān)聯(lián)，進(jìn)一步推出故障原因，從而做出準(zhǔn)確的運維決策。

圖5 故障關(guān)聯(lián)規(guī)則圖

如圖6所示，為不同類故障發(fā)生時間的伴隨關(guān)聯(lián)關(guān)系圖，它可以展示不同類型故障之間發(fā)生先后順序的關(guān)聯(lián)關(guān)系，根據(jù)置信度可以找到先發(fā)故障和后發(fā)故障之間的聯(lián)系，從而在先發(fā)故障發(fā)生后采取運維策略阻止后發(fā)故障的產(chǎn)生，降低故障率。

圖6 故障伴隨關(guān)系關(guān)聯(lián)圖

一般情況下，故障的發(fā)生是有規(guī)律的，隨著時間的推移，積累的數(shù)據(jù)量很大，數(shù)據(jù)中的這種規(guī)律很難被直接發(fā)現(xiàn)。在大數(shù)據(jù)背景下，在分布式環(huán)境下，對傳統(tǒng)的數(shù)據(jù)挖掘算法進(jìn)行改進(jìn)，挖掘故障數(shù)據(jù)的關(guān)聯(lián)規(guī)則，從故障歷史數(shù)據(jù)中發(fā)現(xiàn)隱含規(guī)則。這將指導(dǎo)動車組運維決策，實現(xiàn)基于預(yù)測的維修策略，可以有效地提高動車組運用和維修效率，增強動車組的安全性，降低檢修成本，提高經(jīng)濟效益。

4 結(jié)束語

本論文在分析數(shù)據(jù)挖掘算法基礎(chǔ)上，結(jié)合Hadoop框架，完成了對傳統(tǒng)Apriori算法的改進(jìn)，使其在海量數(shù)據(jù)挖掘上具有較高的挖掘效率。并且結(jié)合動車組實際運維數(shù)據(jù)進(jìn)行驗證，表明了改進(jìn)后算法的可用性?；谠撍惴▽崿F(xiàn)了動車組牽引電機運維數(shù)據(jù)挖掘功能，并進(jìn)行可視化的展示，以提高運維效率，降低經(jīng)濟成本，提高安全性能。后期希望進(jìn)一步進(jìn)行研究，使該算法可以應(yīng)用于其他動車組關(guān)鍵部件，并且需要繼續(xù)改進(jìn)，使其在“剪枝效率”上得到更進(jìn)一步的提高，以實現(xiàn)更好的挖掘效率。