基于Hadoop的云計算在清分系統中的應用

胡宇舟 范濱 顧學道 繆力

【摘要】針對軌道交通行業客流量逐年增大而帶來的大數據和在清分系統中采用大中型計算機和關系型數據庫導致成本高與容錯低的問題，本文首次提出了采用Hadoop云計算解決該問題的一個技術途徑，包括系統設計與實現以及測試結果等。實踐表明，于Hadoop的云計算完全適用于軌道交通售檢票清分系統的處理實時數據業務和非實時數據業務，具有成本低，容錯好，運行穩定和效率高的優點，硬件投資僅占單臺服務器的十分之一，其擴展性與容錯性均優于單臺服務器。

【關鍵詞】Hadoop;云計算;清分系統;大數據

Abstract：According to the problems of big data caused by yearly increased rail transit passenger flow and cost as well as fault tolerance of using large and medium scale computers and RDB in the ACC system，this paper presents a technical way，including system design and implement as well as testing results and so on，to solve the problems based on Hadoop cloud computing technology at first.Practice indicates that cloud computing based on Hadoop is totally suitable for real time and non-real time data processing services in the ACC system of rail transit Automatic Fare Collection system（AFC）with advantages of lower cost，better fault tolerant capability，stable operation as well as higher efficiency.Covered hardware investment is only a tenth of single server，but its expansibility and fault tolerance are both superior to single server.

Key word：Hadoop;cloud computing;Automatic Clearing Collection;big data

1.引言

為了解決交通擁堵和綠色出行，各城市都在建設包括地鐵在內的軌道交通。一個城市的軌道交通往往不是由一個運營公司運行，一個乘客從起點到終點常常經歷多條地鐵線路，乘車費就要在所經歷的線路運營公司之間進行分配。清分系統就承擔該清算的功能，實現軌道交通所有線路之間以及軌道交通線路與“一卡通”結算中心系統之間進行票務清算與分帳，是運營商的一個核心系統。以深圳為例，目前已有5條地鐵線路，由3個運營商運營，每天承載大約200多萬名乘客。清分系統負責所有線路票款的收集，統計，處理，會產生大約2GB的原始數據文件。加工處理并經過壓縮存放數據庫后，每天會產生6-8GB的數據量。這些數據有的保留半年，有的會長期保留。可見，清分系統生成龐大的數據量，達到PB級數據。為了滿足清分系統對處理數據的要求，目前在國內外均采用耗資幾百萬元的大中型計算機和關系型數據庫，如Oracle。但是，經過作者對清分系統數據計算的大量調查研究后發現，CPU利用率低，因為清分系統的數據加工極大多數是進行分拆，重排和組合等操作，計算的工作量很小，非常適合采用具有高容錯性的由PC機組成的分布式云計算，成本將大幅下降，容錯性好且運行穩定。

清分系統的數據可分為實時數據和非實時數據。實時性數據主要包括客流數據，票卡及票庫數據，設備狀態數據和運營模式數據以及聯機數據等。非實時數據，也稱批處理數據主要包括現金收益數據，電子收益數據和各類報表數據等。實時性，精確性，高容錯性和量大是清分系統數據的四大特殊性。用云計算處理大數據量被公認為最有效的方式[1-9]。目前大數據量處理平臺有Twitter的Storm，Yahoo的S4，Apache的Hadoop，UC Berkeley AMPLab的Spark，NokiaDisco，LexisNexis的HPCC等。作者選用開放式的Hadoop作為清分系統大數據處理的平臺。Hadoop[10]是Apache軟件基金會開發和推出的用于海量數據的存儲和計算的并行分布式MapReduce[1]框架，包括分布式文件系統，并行編程和并行執行引擎三大內容。用戶只需只需將所處理的問題轉化為MapReduce的模型，提供自己的Map函數以及Reduce函數即可并行處理海量數據。陳吉榮等人認為：Hadoop生態系統將是中小企業在面對大數據問題時的首選解決方案[11]。寧文瑜等人經過大量研究認為MapReduce已經成為主流的海量數據處理模式[12]。

為使Hadoop真正能商用，必須對其性能進行優化。楊浩等人為了有效地提高集群處理實時作業的成功率，設計并實現了一種基于空閑時間的實時調度器[13]。作者也對Hadoop的性能進行了性能參數的優化，包括實時與非實時數據業務，以及建立了一個日志分析和可視化的監控系統[14]。限于篇幅，本文只敘述Hadoop在清分系統處理大數據業務應用中的問題。

本文結構如下：第2節介紹基于Hadoop的清分系統設計，包括系統組成，體系架構設計和數據庫遷移;第3節敘述了基于Hadoop的清分系統的實現，包括預處理模塊、實時處理模塊和批處理模塊的實現;第4節是基于Hadoop清分系統數據處理的測試結果，包括批數據和實時數據處理的結果;第5節為本文的簡要結論。

2.基于Hadoop的清分系統設計

2.1 系統組成

Hadoop集群在物理上是由一臺名字節點（NameNode）、一臺備用名字節點（SecondaryNameNode）和多臺數據節點（DataNode）組成。名字節點負責管理整個集群的數據存儲、任務分發等，是集群的關鍵節點。為了避免名字節點出現單點故障問題，采用一臺備用名字節點作為輔助，在名字節點出現故障的時候，自動接替名字節點的工作。數據節點是集群的具體工作者，負責數據的存儲，任務執行等工作。集群部署圖如圖1所示。

圖1 Hadoop集群部署圖

2.2 清分系統云計算平臺性能測試

清分系統主要處理的是數據去重、數據合并、客流統計、清分結算等。實際數據處理是一萬行作為一個文件，每五分鐘以內向云計算平臺發送數據。表1中的數據代表每處理一萬行記錄的時間。由于云計算把計算任務分散到每臺機器中執行，所以計算時間不會遞增很快，而遞增的時間，主要消耗在數據去重時查找數據的時間。

表1 清分系統下云計算平臺性能測試統計表

這種計算性能，和運行在單臺服務器上的清分系統性能非常接近了。而成本卻大大降低了，顯示出云計算平臺的優勢。

2.3 體系架構設計

系統采用三層體系架構，由業務層，持久層和物理層組成，如圖2所示。

圖2 體系架構示意圖

2.3.1 物理層

物理層包括操作系統和數據庫。操作系統采用64位CentOS版的Linux系統。數據庫采用兩種：MySQL與HBase。MySQL主要用作實時客流統計;HBase用作存儲批量任務計算的中間結果和最終的交易數據的入庫，如數據合并、清分結算等。

清分系統中要求實時性高的計算任務是各種客流的統計。參照企業信息化管理系統的開發經驗，關系型數據庫是最好的實時數據庫，故采用MySQL存儲實時客流數據。而數據合并、清分結算等任務由于實時性要求不高，故設計為運營日結束后系統從后臺運行，操作數據最終存放在HBase中。系統設計但是如圖3所示

。

圖3 物理層設計

2.3.2 持久層

持久層位于物理層與業務層之間，起適配的作用。本系統采用Hibernate和HBaseORM作為持久層，分別對應MySQL數據庫和HBase數據庫。持久層可以屏蔽數據庫訪問的具體細節，讓開發人員更簡便地操作數據庫。

在清分系統的設計中，提供一個BaseDao作為ORM的公共操作類，把所有對數據庫的操作都放入該類中。持久層設計類圖如圖4所示。

2.3.3 業務層

業務層主要實現清分系統中各種業務的處理和操作，如客流統計，清分結算等都在這里完成。

圖4 持久層類圖

前面已經提到，把Hadoop運用到清分系統中，關鍵是怎樣把任務分解為Map階段和Reduce階段。在本系統的設計中，Map階段的數據源可以是HBase和HDFS，Reduce階段的處理結果可以存儲在HBase或其它介質中（如HDFS，MySQL等）。綜合上述情況，可以把Map和Reduce分為以下兩種情況：（1）數據源是HDFS，計算結果存放在HDFS、MySQL或HBase中。（2）數據源是HBase，計算結果存放在HBase中。

以上兩種情況，在實際的編碼中發現，如果數據源是HDFS，在Map階段處理過程都相同：把任務平均分配到各臺機器中計算。如果數據源是HBase，在Reduce階段處理結果也相同：把Map階段的數據插入HBase中。這樣，系統在處理數據源為HDFS的時候，只需要重寫Reduce階段;在處理數據源為HBase的時候，只需要重寫Map階段。

2.4 數據庫遷移

試驗系統耗時最多和工作量最大的是數據庫的遷移，即從傳統的關系型數據庫向Hadoop的架構遷移。關系型數據庫系統向Hadoop框架移植主要需要解決兩個問題：數據遷移和數據處理。數據遷移是指將關系型數據庫的結構化數據導入Hadoop存儲系統中;數據處理指將原來處理數據庫的程序改為處理Hadoop存儲數據的程序。Sqoop是一個用來將Hadoop和關系型數據庫中的數據相互轉移的工具，可以將一個關系型數據庫（如MySQL，Oracle，Postgres等）中的數據導入到Hadoop的HDFS中，也可以將HDFS的數據導入到關系型數據庫中。將數據庫的結構化數據導入Hadoop的非結構化文件格式，是一個直接的過程，其中要注意的問題是Hadoop與關系型數據庫不同，因此，應當避免逐表導入，把數據庫的每張表導為Hadoop中的一個文件，這會導致Hadoop運行效率低下。關系型數據庫一方面追求規范化設計，一方面可擴展性差，因此數據庫表設計通常需要避免出現冗余數據，以達到數據一致性和減少數據庫大小。一個典型的信息系統數據庫通常有數百個乃至上千個表，由于數據庫系統通常在高端的單機上運行，因此，多表鏈接的效率能得到一定的保障。Hadoop系統的優缺點與數據庫系統不同。Hadoop善于處理非結構化數據，可擴展性好，通常在數百臺以上的集群上運行，多表鏈接由于處理過程的困難，導致效率很低。因此，應當盡量將所有的表形成幾個大的文件，這樣雖然造成數據冗余，但是Hadoop的集群存儲容量巨大，數據冗余并非問題。通過避免表鏈接，執行效率可以大大提高。在數據庫遷移的過程中先進行了數次試遷移的實驗，實驗成功后才進行數據庫的正式遷移，做到一次遷移成功。

3.基于Hadoop清分系統的實現

本系統分為三個實現模塊：預處理模塊、實時處理模塊、批處理模塊。各個模塊之間的關系如圖5所示。

3.1 預處理模塊的實現

原始交易數據必須要通過解析格式化和數據去重后才能使用。傳統的數據去重方法是查詢數據庫。但是面對超過一億的數據記錄時，直接查詢數據庫的方法會存在嚴重的性能問題。在本系統中，采用了Hadoop中附帶的BloomFilter數據結構進行高效的數據去重操作。數據去重示意圖如圖6所示。

圖5 清分系統模塊

圖6 數據去重過程

BloomFilter由于提供了基于Bit字節的存儲，在數據量達到20億的時候，所占用的內存空間為3M，實現了存儲量大，占空間小的目標。

去重后的數據，先上傳到HDFS中作為實時客流統計的數據源;同時插入HBase中作為批量計算任務的數據源。

3.2 實時處理模塊的實現

由于客流統計是實時性要求比較高的模塊，所以采用實時計算方式。當有文件上傳到指定目錄時，立即觸發系統運行，統計的客流數據包括：實時客流、換乘客流、斷面客流和實時客流。

在MapReduce中進行客流統計的時候，系統進行了巧妙的設計。由于系統是利用了Hadoop中的并行計算功能，則我們希望所有任務能夠以接近平均的方式分配到每臺機器中處理。為了實現這種方式，只需要在Map階段的輸出key中定義為集群中數據節點的個數，這樣Hadoop就會把key相同的數據傳送到同一臺機器中處理。過程如圖7所示。

圖7 實時任務中Map-Reduce計算過程

這樣的設計可以屏蔽Map-Reduce過程中的Map階段，開發人員只需要繼承Reduce類，重寫其方法，就可以實現Hadoop的并行計算功能。

3.3 批處理模塊的實現

批處理任務被設計為在日運營結束后進行處理，主要包括三個任務、數據合并、清分結算和卡狀態更新。處理的數據源已經在預處理模塊中，插入到HBase中了。所以這里利用MapReduce計算的數據源是HBase，接收數據也是HBase。

在開發中發現，此過程中，Reduce階段的代碼都是相同的功能：把Map階段的數據插入到HBase中。這樣就可以屏蔽掉Reduce過程。開發人員只需要繼承Map類，重寫其方法，就可以實現Hadoop的并行計算功能。如圖8所示。

圖8 批量任務中Map-Reduce計算過程

表2 試驗系統集群集群配置表

4.基于Hadoop清分系統數據處理的測試結果

以下分別對預處理模塊、實時處理模塊、批處理模塊三個部分進行測試。試驗中作者截取了連續3天（共一千萬條記錄）的清分系統的交易數據。集群機器的配置如表2所示。

4.1 測試內容與方法

系統每5分鐘讀取一個大小為2.5M，行數為一萬行的文件，然后在后臺分別經過預處理模塊、實時處理模塊、批處理模塊三個步驟的處理。在處理的過程中，程序會統計每個步驟的執行時間，并輸出性能統計圖表。

4.2 測試結果與分析

以下均用圖表的方式展示性能測試結果。為了便于展示，圖表中只列出一千萬記錄里每二十萬條作為一個記錄點，共50個記錄點。

4.2.1 預處理模塊的測試

預處理模塊主要運行以下四個功能：解析格式化、數據去重、數據上傳到HDFS、數據插入到HBase。性能測試結果如圖9所示。

圖9 預處理模塊的測試

從圖表中可以看出，預處理模塊在處理一千萬條記錄的過程中，處理時間穩定在24秒左右。其中最耗時的是數據插入到HBase的過程。

4.2.2 實時處理模塊測試

實時處理模塊分別計算四種客流數據：OD客流、換乘客流、切面客流和實時客流。計算過程采用MapReduce進行并行計算，數據源為HDFS，數據結果存放在MySQL中。實時處理模塊的測試結果如圖10所示。

圖11 實時處理模塊測試

從圖表中可以看出，實時處理模塊在處理一千萬條記錄的過程中，處理時間穩定在61秒左右，與單臺服務器性能相近。

4.2.3 批處理模塊測試

批處理模塊主要處理清分結算，數據合并和卡狀態更新等過程。觸發批處理的運行的時間點是日運營結束后，系統自動運行。由于只有三天的數據，所以批處理的運行次數只有三次，如表3所示：（下轉第21頁）（上接第17頁）

表3 批處理模塊測試

批量處理的時間一般在凌晨地鐵停止運營的時候進行，所以不會對地鐵的日運營造成影響。

5.簡要結論

清分系統的主要特征是數據量大和要求持續計算與實時反饋等。運行在傳統的單臺大中型服務器上的清分系統，主要受到存儲量大小和異常中斷的限制，以及沒有能充分利用服務器性能的。因為清分系統雖然要求持續計算和實時反饋，但是計算工作量不是很大，沒有充分利用大中型服務器的性能，這對服務器是一種極大的浪費。

清分系統處理的數據，都是以一萬行記錄作為一份文件。一個計算過程就是對這一萬行記錄進行操作，包括數據合并、客流統計、清分結算等。而這些計算工作量并非很大，完全可以在普通PC組成的云計算來完成，只要把這些計算任務都分散到每臺機器中執行，其硬件投資僅占單臺服務器的十分之一，整體性能與單臺服務器性能相近，并可通過擴展PC機器來增強其整體的計算性能，擴展性與容錯性均優于單臺服務器。

因此，分布式云計算的架構是非常適合清分系統的業務處理。經過系統的搭建，數據遷移的完成，系統的穩定運行，表明基于Hadoop的云計算完全適用于軌道交通售檢票清分系統的業務處理，成本低，容錯好，運行穩定，效率高。

參考文獻

[1]辛大欣，劉飛.Hadoop 集群性能優化技術研究[J].北京：電腦知識與技術，2011，7（22）.

[2]劉鵬.云計算（第二版）[M].北京：電子工業出版社.2011.

[3]雷萬云.云計算——技術、平臺及應用案例[M].北京：清華大學出版社，2011.

[4]姚宏宇，田溯寧.云計算：大數據時代的系統工程[M].北京：電子工業出版社，2013.

[5]周洪波.云計算：技術、應用、標準和商業模式[M].北京：電子工業出版社，2011.

[6]（美）羅頓，著.朱麗，等，譯.云計算：企業實施手冊[M].北京：機械工業出版社，2011.

[7]徐強，王振江.云計算：應用開發實踐[M].北京：機械工業出版社，2012.

[8]（英）邁爾-舍恩伯格，（英）庫克耶，著，盛楊燕，周濤，譯.大數據時代[M].浙江：浙江人民出版社，2013.

[9]Bill Franks著.黃海，等，譯.駕馭大數據[M].北京：人民郵電出版社，2013.

[10]Dean J，Ghemawat S.MapReduce：simplified data processing on large clusters[J].USA：Communications of the ACM，2008，51（1）：107-113.

[11]陳吉榮，樂嘉錦.基于Hadoop生態系統的大數據解決方案綜述[J].長沙：計算機工程與科學，2013，35（10）：25-35.

[12]寧文瑜，吳慶波，譚郁松.面向MapReduce的自適應延遲調度算法[J].長沙：計算機工程與科學，2013，35（3）：52-57.

[13]楊浩，滕飛，李天瑞，李曌.Hadoop平臺中空閑時間調度器的設計與實現[J].長沙：計算機工程與科學，2013，35（10）：

125-130.

[14]繆力.基于云計算的Hadoop海量數據處理及監控技術的研究，博士后研究人員出站報告書[R].深圳：高新現代智能系統股份有限公司博士后科研工作站，2013，9.

作者簡介：

胡宇舟，男，博士，高新現代智能系統股份有限公司高級工程師，主要研究方向：計算機及其應用，信息管理系統。

范濱，男，高新現代智能系統股份有限公司工程師。

顧學道，男，教授，博士生導師。

繆力，男，博士，副教授。