基于Hadoop的Aprior算法改進及其在動車組運維的應用

任廣強，舒 敏

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

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

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

因此，本文在分析解決大數據問題的Hadoop技術以及傳統關聯分析挖掘算法Apriori算法的基礎上，將兩者進行有效的結合，使其進一步提升挖掘效率。

1 理論及相關技術介紹

1.1 Hadoop概述

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

圖1 Hadoop相關項目

1.2 Apriori算法

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

2 基于Hadoop的Apriori算法研究與改進

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

2.1 算法的改進

Hadoop的核心組件MapReduce對存儲在分布式文件系統中的文件進行分布式計算的過程[13]可以很好地擴展應用到Apriori算法中，可以完成基于大數據量下關聯規則的快速挖掘。

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

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

（2）重復讀取原始數據在大數據量的情況下導致的資源消耗，算法性能降低的問題。

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

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

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

partial_min_support_count = min_support_count /trans_count 。

Map端和Reduce端實現的改進后的偽代碼，如下所示：

Map輸入：Si //每一行是一個事務：

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

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

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

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

2.2 由頻繁項集產生關聯規則

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

其中，key是字符串，為生成的關聯規則，而value是該關聯規則的置信度。

2.3 算法性能評估

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

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

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

表1 數據字段說明

圖3 不同數據規模算法性能

3 動車組牽引電機運維數據挖掘系統實現

3.1 動車組運維數據

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

（1）實時監測數據

實時監測數據是指在實際運行過程中產生的各種狀態數據，包括：累計功率、距離數據、電機數據、受電弓數據和空載數據等。

（2）運行狀態數據

運行狀態數據記錄了動車組在行駛過程中的狀態數據。動車組司機可以通過運行狀態數據來監控動車組的實時運行狀態，該數據是在動車組運維過程中不斷累積產生的，隱含了對動車組運維決策的指導意義。

（3）畫面故障數據

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

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

（1）基礎數據，即牽引電機的靜態生產數據，包括額定電流電壓、生產廠家、批次編號等；

（2）部件工作數據，即牽引電機部件的運行數據，包括定子、轉子、外圈、內圈等不見得溫度、轉速等數據；

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

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

（5）線路數據；

（6）環境數據。

3.2 動車組牽引電機故障數據挖掘

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

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

圖4 數據預處理流程圖

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

（2）將清洗之后的結果數據存放在分布式文件系統HDFS中，設置好輸入輸出文件的路徑以及格式；

（3）利用現有的專家經驗值，初步設定min_support（最小支持度）以及min_confi（最小置信度），計算頻繁項集；

（4）利用改進后的T-MR-Aprior算法進行牽引電機運維效率關聯規則挖掘，得到關聯強規則；

（5）分別對每條規則進行支持度與置信度的重新計算。

部分關聯規則挖掘結果，如表2所示。

表2 部分挖掘結果

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

對于關聯規則“某地點，3月=＞通風系統異常[support=2.08% conf=11.93%]”表示該地區內，每年的3月份風閥系統和通風系統故障比較多，后續驗證該條規則是準確的。因為查資料可得，此處區域在春夏交際之間風沙較多，因而導致通風系統故障率高。

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

圖5 故障關聯規則圖

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

圖6 故障伴隨關系關聯圖

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

4 結束語

本論文在分析數據挖掘算法基礎上，結合Hadoop框架，完成了對傳統Apriori算法的改進，使其在海量數據挖掘上具有較高的挖掘效率。并且結合動車組實際運維數據進行驗證，表明了改進后算法的可用性。基于該算法實現了動車組牽引電機運維數據挖掘功能，并進行可視化的展示，以提高運維效率，降低經濟成本，提高安全性能。后期希望進一步進行研究，使該算法可以應用于其他動車組關鍵部件，并且需要繼續改進，使其在“剪枝效率”上得到更進一步的提高，以實現更好的挖掘效率。