基于Hadoop的云計(jì)算在清分系統(tǒng)中的應(yīng)用

胡宇舟 范濱 顧學(xué)道 繆力

【摘要】針對(duì)軌道交通行業(yè)客流量逐年增大而帶來的大數(shù)據(jù)和在清分系統(tǒng)中采用大中型計(jì)算機(jī)和關(guān)系型數(shù)據(jù)庫導(dǎo)致成本高與容錯(cuò)低的問題，本文首次提出了采用Hadoop云計(jì)算解決該問題的一個(gè)技術(shù)途徑，包括系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)以及測試結(jié)果等。實(shí)踐表明，于Hadoop的云計(jì)算完全適用于軌道交通售檢票清分系統(tǒng)的處理實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)和非實(shí)時(shí)數(shù)據(jù)業(yè)務(wù)，具有成本低，容錯(cuò)好，運(yùn)行穩(wěn)定和效率高的優(yōu)點(diǎn)，硬件投資僅占單臺(tái)服務(wù)器的十分之一，其擴(kuò)展性與容錯(cuò)性均優(yōu)于單臺(tái)服務(wù)器。

【關(guān)鍵詞】Hadoop;云計(jì)算;清分系統(tǒng);大數(shù)據(jù)

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.引言

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

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

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

本文結(jié)構(gòu)如下：第2節(jié)介紹基于Hadoop的清分系統(tǒng)設(shè)計(jì)，包括系統(tǒng)組成，體系架構(gòu)設(shè)計(jì)和數(shù)據(jù)庫遷移;第3節(jié)敘述了基于Hadoop的清分系統(tǒng)的實(shí)現(xiàn)，包括預(yù)處理模塊、實(shí)時(shí)處理模塊和批處理模塊的實(shí)現(xiàn);第4節(jié)是基于Hadoop清分系統(tǒng)數(shù)據(jù)處理的測試結(jié)果，包括批數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)處理的結(jié)果;第5節(jié)為本文的簡要結(jié)論。

2.基于Hadoop的清分系統(tǒng)設(shè)計(jì)

2.1 系統(tǒng)組成

Hadoop集群在物理上是由一臺(tái)名字節(jié)點(diǎn)（NameNode）、一臺(tái)備用名字節(jié)點(diǎn)（SecondaryNameNode）和多臺(tái)數(shù)據(jù)節(jié)點(diǎn)（DataNode）組成。名字節(jié)點(diǎn)負(fù)責(zé)管理整個(gè)集群的數(shù)據(jù)存儲(chǔ)、任務(wù)分發(fā)等，是集群的關(guān)鍵節(jié)點(diǎn)。為了避免名字節(jié)點(diǎn)出現(xiàn)單點(diǎn)故障問題，采用一臺(tái)備用名字節(jié)點(diǎn)作為輔助，在名字節(jié)點(diǎn)出現(xiàn)故障的時(shí)候，自動(dòng)接替名字節(jié)點(diǎn)的工作。數(shù)據(jù)節(jié)點(diǎn)是集群的具體工作者，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)，任務(wù)執(zhí)行等工作。集群部署圖如圖1所示。

圖1 Hadoop集群部署圖

2.2 清分系統(tǒng)云計(jì)算平臺(tái)性能測試

清分系統(tǒng)主要處理的是數(shù)據(jù)去重、數(shù)據(jù)合并、客流統(tǒng)計(jì)、清分結(jié)算等。實(shí)際數(shù)據(jù)處理是一萬行作為一個(gè)文件，每五分鐘以內(nèi)向云計(jì)算平臺(tái)發(fā)送數(shù)據(jù)。表1中的數(shù)據(jù)代表每處理一萬行記錄的時(shí)間。由于云計(jì)算把計(jì)算任務(wù)分散到每臺(tái)機(jī)器中執(zhí)行，所以計(jì)算時(shí)間不會(huì)遞增很快，而遞增的時(shí)間，主要消耗在數(shù)據(jù)去重時(shí)查找數(shù)據(jù)的時(shí)間。

表1 清分系統(tǒng)下云計(jì)算平臺(tái)性能測試統(tǒng)計(jì)表

這種計(jì)算性能，和運(yùn)行在單臺(tái)服務(wù)器上的清分系統(tǒng)性能非常接近了。而成本卻大大降低了，顯示出云計(jì)算平臺(tái)的優(yōu)勢。

2.3 體系架構(gòu)設(shè)計(jì)

系統(tǒng)采用三層體系架構(gòu)，由業(yè)務(wù)層，持久層和物理層組成，如圖2所示。

圖2 體系架構(gòu)示意圖

2.3.1 物理層

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

清分系統(tǒng)中要求實(shí)時(shí)性高的計(jì)算任務(wù)是各種客流的統(tǒng)計(jì)。參照企業(yè)信息化管理系統(tǒng)的開發(fā)經(jīng)驗(yàn)，關(guān)系型數(shù)據(jù)庫是最好的實(shí)時(shí)數(shù)據(jù)庫，故采用MySQL存儲(chǔ)實(shí)時(shí)客流數(shù)據(jù)。而數(shù)據(jù)合并、清分結(jié)算等任務(wù)由于實(shí)時(shí)性要求不高，故設(shè)計(jì)為運(yùn)營日結(jié)束后系統(tǒng)從后臺(tái)運(yùn)行，操作數(shù)據(jù)最終存放在HBase中。系統(tǒng)設(shè)計(jì)但是如圖3所示

。

圖3 物理層設(shè)計(jì)

2.3.2 持久層

持久層位于物理層與業(yè)務(wù)層之間，起適配的作用。本系統(tǒng)采用Hibernate和HBaseORM作為持久層，分別對(duì)應(yīng)MySQL數(shù)據(jù)庫和HBase數(shù)據(jù)庫。持久層可以屏蔽數(shù)據(jù)庫訪問的具體細(xì)節(jié)，讓開發(fā)人員更簡便地操作數(shù)據(jù)庫。

在清分系統(tǒng)的設(shè)計(jì)中，提供一個(gè)BaseDao作為ORM的公共操作類，把所有對(duì)數(shù)據(jù)庫的操作都放入該類中。持久層設(shè)計(jì)類圖如圖4所示。

2.3.3 業(yè)務(wù)層

業(yè)務(wù)層主要實(shí)現(xiàn)清分系統(tǒng)中各種業(yè)務(wù)的處理和操作，如客流統(tǒng)計(jì)，清分結(jié)算等都在這里完成。

圖4 持久層類圖

前面已經(jīng)提到，把Hadoop運(yùn)用到清分系統(tǒng)中，關(guān)鍵是怎樣把任務(wù)分解為Map階段和Reduce階段。在本系統(tǒng)的設(shè)計(jì)中，Map階段的數(shù)據(jù)源可以是HBase和HDFS，Reduce階段的處理結(jié)果可以存儲(chǔ)在HBase或其它介質(zhì)中（如HDFS，MySQL等）。綜合上述情況，可以把Map和Reduce分為以下兩種情況：（1）數(shù)據(jù)源是HDFS，計(jì)算結(jié)果存放在HDFS、MySQL或HBase中。（2）數(shù)據(jù)源是HBase，計(jì)算結(jié)果存放在HBase中。

以上兩種情況，在實(shí)際的編碼中發(fā)現(xiàn)，如果數(shù)據(jù)源是HDFS，在Map階段處理過程都相同：把任務(wù)平均分配到各臺(tái)機(jī)器中計(jì)算。如果數(shù)據(jù)源是HBase，在Reduce階段處理結(jié)果也相同：把Map階段的數(shù)據(jù)插入HBase中。這樣，系統(tǒng)在處理數(shù)據(jù)源為HDFS的時(shí)候，只需要重寫Reduce階段;在處理數(shù)據(jù)源為HBase的時(shí)候，只需要重寫Map階段。

2.4 數(shù)據(jù)庫遷移

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

3.基于Hadoop清分系統(tǒng)的實(shí)現(xiàn)

本系統(tǒng)分為三個(gè)實(shí)現(xiàn)模塊：預(yù)處理模塊、實(shí)時(shí)處理模塊、批處理模塊。各個(gè)模塊之間的關(guān)系如圖5所示。

3.1 預(yù)處理模塊的實(shí)現(xiàn)

原始交易數(shù)據(jù)必須要通過解析格式化和數(shù)據(jù)去重后才能使用。傳統(tǒng)的數(shù)據(jù)去重方法是查詢數(shù)據(jù)庫。但是面對(duì)超過一億的數(shù)據(jù)記錄時(shí)，直接查詢數(shù)據(jù)庫的方法會(huì)存在嚴(yán)重的性能問題。在本系統(tǒng)中，采用了Hadoop中附帶的BloomFilter數(shù)據(jù)結(jié)構(gòu)進(jìn)行高效的數(shù)據(jù)去重操作。數(shù)據(jù)去重示意圖如圖6所示。

圖5 清分系統(tǒng)模塊

圖6 數(shù)據(jù)去重過程

BloomFilter由于提供了基于Bit字節(jié)的存儲(chǔ)，在數(shù)據(jù)量達(dá)到20億的時(shí)候，所占用的內(nèi)存空間為3M，實(shí)現(xiàn)了存儲(chǔ)量大，占空間小的目標(biāo)。

去重后的數(shù)據(jù)，先上傳到HDFS中作為實(shí)時(shí)客流統(tǒng)計(jì)的數(shù)據(jù)源;同時(shí)插入HBase中作為批量計(jì)算任務(wù)的數(shù)據(jù)源。

3.2 實(shí)時(shí)處理模塊的實(shí)現(xiàn)

由于客流統(tǒng)計(jì)是實(shí)時(shí)性要求比較高的模塊，所以采用實(shí)時(shí)計(jì)算方式。當(dāng)有文件上傳到指定目錄時(shí)，立即觸發(fā)系統(tǒng)運(yùn)行，統(tǒng)計(jì)的客流數(shù)據(jù)包括：實(shí)時(shí)客流、換乘客流、斷面客流和實(shí)時(shí)客流。

在MapReduce中進(jìn)行客流統(tǒng)計(jì)的時(shí)候，系統(tǒng)進(jìn)行了巧妙的設(shè)計(jì)。由于系統(tǒng)是利用了Hadoop中的并行計(jì)算功能，則我們希望所有任務(wù)能夠以接近平均的方式分配到每臺(tái)機(jī)器中處理。為了實(shí)現(xiàn)這種方式，只需要在Map階段的輸出key中定義為集群中數(shù)據(jù)節(jié)點(diǎn)的個(gè)數(shù)，這樣Hadoop就會(huì)把key相同的數(shù)據(jù)傳送到同一臺(tái)機(jī)器中處理。過程如圖7所示。

圖7 實(shí)時(shí)任務(wù)中Map-Reduce計(jì)算過程

這樣的設(shè)計(jì)可以屏蔽Map-Reduce過程中的Map階段，開發(fā)人員只需要繼承Reduce類，重寫其方法，就可以實(shí)現(xiàn)Hadoop的并行計(jì)算功能。

3.3 批處理模塊的實(shí)現(xiàn)

批處理任務(wù)被設(shè)計(jì)為在日運(yùn)營結(jié)束后進(jìn)行處理，主要包括三個(gè)任務(wù)、數(shù)據(jù)合并、清分結(jié)算和卡狀態(tài)更新。處理的數(shù)據(jù)源已經(jīng)在預(yù)處理模塊中，插入到HBase中了。所以這里利用MapReduce計(jì)算的數(shù)據(jù)源是HBase，接收數(shù)據(jù)也是HBase。

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

圖8 批量任務(wù)中Map-Reduce計(jì)算過程

表2 試驗(yàn)系統(tǒng)集群集群配置表

4.基于Hadoop清分系統(tǒng)數(shù)據(jù)處理的測試結(jié)果

以下分別對(duì)預(yù)處理模塊、實(shí)時(shí)處理模塊、批處理模塊三個(gè)部分進(jìn)行測試。試驗(yàn)中作者截取了連續(xù)3天（共一千萬條記錄）的清分系統(tǒng)的交易數(shù)據(jù)。集群機(jī)器的配置如表2所示。

4.1 測試內(nèi)容與方法

系統(tǒng)每5分鐘讀取一個(gè)大小為2.5M，行數(shù)為一萬行的文件，然后在后臺(tái)分別經(jīng)過預(yù)處理模塊、實(shí)時(shí)處理模塊、批處理模塊三個(gè)步驟的處理。在處理的過程中，程序會(huì)統(tǒng)計(jì)每個(gè)步驟的執(zhí)行時(shí)間，并輸出性能統(tǒng)計(jì)圖表。

4.2 測試結(jié)果與分析

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

4.2.1 預(yù)處理模塊的測試

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

圖9 預(yù)處理模塊的測試

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

4.2.2 實(shí)時(shí)處理模塊測試

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

圖11 實(shí)時(shí)處理模塊測試

從圖表中可以看出，實(shí)時(shí)處理模塊在處理一千萬條記錄的過程中，處理時(shí)間穩(wěn)定在61秒左右，與單臺(tái)服務(wù)器性能相近。

4.2.3 批處理模塊測試

批處理模塊主要處理清分結(jié)算，數(shù)據(jù)合并和卡狀態(tài)更新等過程。觸發(fā)批處理的運(yùn)行的時(shí)間點(diǎn)是日運(yùn)營結(jié)束后，系統(tǒng)自動(dòng)運(yùn)行。由于只有三天的數(shù)據(jù)，所以批處理的運(yùn)行次數(shù)只有三次，如表3所示：（下轉(zhuǎn)第21頁）（上接第17頁）

表3 批處理模塊測試

批量處理的時(shí)間一般在凌晨地鐵停止運(yùn)營的時(shí)候進(jìn)行，所以不會(huì)對(duì)地鐵的日運(yùn)營造成影響。

5.簡要結(jié)論

清分系統(tǒng)的主要特征是數(shù)據(jù)量大和要求持續(xù)計(jì)算與實(shí)時(shí)反饋等。運(yùn)行在傳統(tǒng)的單臺(tái)大中型服務(wù)器上的清分系統(tǒng)，主要受到存儲(chǔ)量大小和異常中斷的限制，以及沒有能充分利用服務(wù)器性能的。因?yàn)榍宸窒到y(tǒng)雖然要求持續(xù)計(jì)算和實(shí)時(shí)反饋，但是計(jì)算工作量不是很大，沒有充分利用大中型服務(wù)器的性能，這對(duì)服務(wù)器是一種極大的浪費(fèi)。

清分系統(tǒng)處理的數(shù)據(jù)，都是以一萬行記錄作為一份文件。一個(gè)計(jì)算過程就是對(duì)這一萬行記錄進(jìn)行操作，包括數(shù)據(jù)合并、客流統(tǒng)計(jì)、清分結(jié)算等。而這些計(jì)算工作量并非很大，完全可以在普通PC組成的云計(jì)算來完成，只要把這些計(jì)算任務(wù)都分散到每臺(tái)機(jī)器中執(zhí)行，其硬件投資僅占單臺(tái)服務(wù)器的十分之一，整體性能與單臺(tái)服務(wù)器性能相近，并可通過擴(kuò)展PC機(jī)器來增強(qiáng)其整體的計(jì)算性能，擴(kuò)展性與容錯(cuò)性均優(yōu)于單臺(tái)服務(wù)器。

因此，分布式云計(jì)算的架構(gòu)是非常適合清分系統(tǒng)的業(yè)務(wù)處理。經(jīng)過系統(tǒng)的搭建，數(shù)據(jù)遷移的完成，系統(tǒng)的穩(wěn)定運(yùn)行，表明基于Hadoop的云計(jì)算完全適用于軌道交通售檢票清分系統(tǒng)的業(yè)務(wù)處理，成本低，容錯(cuò)好，運(yùn)行穩(wěn)定，效率高。

參考文獻(xiàn)

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

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

[3]雷萬云.云計(jì)算——技術(shù)、平臺(tái)及應(yīng)用案例[M].北京：清華大學(xué)出版社，2011.

[4]姚宏宇，田溯寧.云計(jì)算：大數(shù)據(jù)時(shí)代的系統(tǒng)工程[M].北京：電子工業(yè)出版社，2013.

[5]周洪波.云計(jì)算：技術(shù)、應(yīng)用、標(biāo)準(zhǔn)和商業(yè)模式[M].北京：電子工業(yè)出版社，2011.

[6]（美）羅頓，著.朱麗，等，譯.云計(jì)算：企業(yè)實(shí)施手冊[M].北京：機(jī)械工業(yè)出版社，2011.

[7]徐強(qiáng)，王振江.云計(jì)算：應(yīng)用開發(fā)實(shí)踐[M].北京：機(jī)械工業(yè)出版社，2012.

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

[9]Bill Franks著.黃海，等，譯.駕馭大數(shù)據(jù)[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生態(tài)系統(tǒng)的大數(shù)據(jù)解決方案綜述[J].長沙：計(jì)算機(jī)工程與科學(xué)，2013，35（10）：25-35.

[12]寧文瑜，吳慶波，譚郁松.面向MapReduce的自適應(yīng)延遲調(diào)度算法[J].長沙：計(jì)算機(jī)工程與科學(xué)，2013，35（3）：52-57.

[13]楊浩，滕飛，李天瑞，李曌.Hadoop平臺(tái)中空閑時(shí)間調(diào)度器的設(shè)計(jì)與實(shí)現(xiàn)[J].長沙：計(jì)算機(jī)工程與科學(xué)，2013，35（10）：

125-130.

[14]繆力.基于云計(jì)算的Hadoop海量數(shù)據(jù)處理及監(jiān)控技術(shù)的研究，博士后研究人員出站報(bào)告書[R].深圳：高新現(xiàn)代智能系統(tǒng)股份有限公司博士后科研工作站，2013，9.

作者簡介：

胡宇舟，男，博士，高新現(xiàn)代智能系統(tǒng)股份有限公司高級(jí)工程師，主要研究方向：計(jì)算機(jī)及其應(yīng)用，信息管理系統(tǒng)。

范濱，男，高新現(xiàn)代智能系統(tǒng)股份有限公司工程師。

顧學(xué)道，男，教授，博士生導(dǎo)師。

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