雷 軍 葉航軍 武澤勝 張 鵬 謝 龍 何炎祥

1(武漢大學(xué)計(jì)算機(jī)學(xué)院 武漢 430072)2(小米科技有限責(zé)任公司 北京 100085)3 (軟件工程國(guó)家重點(diǎn)實(shí)驗(yàn)室(武漢大學(xué)) 武漢 430072)(leijun@xiaomi.com)

基于開(kāi)源生態(tài)系統(tǒng)的大數(shù)據(jù)平臺(tái)研究

雷 軍1,2葉航軍2武澤勝2張 鵬2謝 龍2何炎祥1,3

1(武漢大學(xué)計(jì)算機(jī)學(xué)院 武漢 430072)2(小米科技有限責(zé)任公司 北京 100085)3(軟件工程國(guó)家重點(diǎn)實(shí)驗(yàn)室(武漢大學(xué)) 武漢 430072)(leijun@xiaomi.com)

大規(guī)模數(shù)據(jù)的收集和處理是近年的研究熱點(diǎn)，業(yè)界已經(jīng)提出了若干平臺(tái)級(jí)的設(shè)計(jì)方案，大量使用了開(kāi)源軟件作為數(shù)據(jù)收集和處理組件.然而，要真正滿足企業(yè)應(yīng)用中海量數(shù)據(jù)存儲(chǔ)、多樣化業(yè)務(wù)處理、跨業(yè)務(wù)分析、跨環(huán)境部署等復(fù)雜需求，尚需設(shè)計(jì)具有完整性、通用性、支持整個(gè)數(shù)據(jù)生命周期管理的大數(shù)據(jù)平臺(tái)，并且對(duì)開(kāi)源軟件進(jìn)行大量的功能開(kāi)發(fā)、定制和改進(jìn).從小米公司的行業(yè)應(yīng)用和實(shí)踐出發(fā)，在深入研究現(xiàn)有平臺(tái)的基礎(chǔ)上，提出了一種新的基于開(kāi)源生態(tài)系統(tǒng)的大數(shù)據(jù)收集與處理平臺(tái)，在負(fù)載均衡、故障恢復(fù)、數(shù)據(jù)壓縮、多維調(diào)度等方面進(jìn)行了大量?jī)?yōu)化，同時(shí)發(fā)現(xiàn)并解決了現(xiàn)有開(kāi)源軟件在數(shù)據(jù)收集、存儲(chǔ)、處理以及軟件一致性、可用性和效率等方面的缺陷.該平臺(tái)已經(jīng)在小米公司成功部署，為小米公司各個(gè)業(yè)務(wù)線的數(shù)據(jù)收集和處理提供支撐服務(wù).

Hadoop；開(kāi)源生態(tài)系統(tǒng)；大數(shù)據(jù);數(shù)據(jù)中心；網(wǎng)絡(luò)虛擬化

大規(guī)模數(shù)據(jù)的收集和處理是近年來(lái)業(yè)界和學(xué)術(shù)界的熱點(diǎn)，被稱(chēng)為“大數(shù)據(jù)”問(wèn)題.“大數(shù)據(jù)”問(wèn)題存在多種定義，現(xiàn)在普遍被接受的是IBM的3V定義[1]，即數(shù)量(volume)、種類(lèi)(variety)和速度(velocity)，也就是數(shù)量巨大、種類(lèi)豐富、快速生成并需要快速處理的數(shù)據(jù).大規(guī)模數(shù)據(jù)的收集和處理有許多實(shí)際的應(yīng)用.對(duì)互聯(lián)網(wǎng)企業(yè)而言，用戶在使用其產(chǎn)品的過(guò)程中會(huì)產(chǎn)生大量的業(yè)務(wù)數(shù)據(jù)，比如使用日志、交易日志和關(guān)系鏈等.對(duì)這些數(shù)據(jù)的分析和處理，可以深刻了解用戶的需求.每一次用戶對(duì)產(chǎn)品的使用都反映了用戶的需求和對(duì)產(chǎn)品的反饋.對(duì)這些數(shù)據(jù)的分析和挖掘可以幫助公司改進(jìn)自身產(chǎn)品，提升用戶體驗(yàn)，為用戶創(chuàng)造更大的價(jià)值.因此，公司通常有強(qiáng)烈的需求來(lái)分析和處理上述數(shù)據(jù).

以小米科技有限責(zé)任公司(以下簡(jiǎn)稱(chēng)：小米公司)為例，公司業(yè)務(wù)數(shù)據(jù)的收集、分析和處理是一個(gè)典型的大數(shù)據(jù)問(wèn)題：PB量級(jí)的數(shù)據(jù)總量、多種數(shù)據(jù)格式(如逗號(hào)分隔值(comma separated value, CSV)、Thrift消息[2]、文本文件、關(guān)系數(shù)據(jù)庫(kù)等)、上百個(gè)數(shù)據(jù)來(lái)源、每日TB量級(jí)的數(shù)據(jù)增量和小時(shí)級(jí)別的處理速度要求等.大數(shù)據(jù)問(wèn)題的解決，需要一套行之有效的技術(shù)架構(gòu)，一般是分層次的堆棧式技術(shù)架構(gòu).對(duì)此，EMC將大數(shù)據(jù)技術(shù)架構(gòu)分成了4層：基礎(chǔ)層、管理層、分析層和應(yīng)用層.小米公司的內(nèi)部業(yè)務(wù)在基礎(chǔ)層和管理層上沿襲了該框架，但在數(shù)據(jù)的應(yīng)用和分析上有所不同，以適應(yīng)公司自身的業(yè)務(wù)特點(diǎn).

1) 數(shù)據(jù)存量和增量大.PB級(jí)別的數(shù)據(jù)總量和TB級(jí)別的數(shù)據(jù)日增量，對(duì)數(shù)據(jù)存儲(chǔ)和傳輸?shù)某杀九c效率提出很高的要求.

2) 業(yè)務(wù)線多、數(shù)據(jù)來(lái)源和格式多樣化.上百個(gè)業(yè)務(wù)項(xiàng)目和數(shù)據(jù)來(lái)源，多種異構(gòu)的數(shù)據(jù)格式，要求大數(shù)據(jù)平臺(tái)有足夠的靈活性和可擴(kuò)展性.

3) 跨業(yè)務(wù)數(shù)據(jù)分析和挖掘的需求大.聯(lián)合利用用戶在多個(gè)產(chǎn)品上的使用數(shù)據(jù)，才能更深刻了解用戶的需求，更好地改善用戶體驗(yàn).

4) 業(yè)務(wù)部署和大數(shù)據(jù)平臺(tái)部署的情況比較復(fù)雜.多機(jī)房部署、異構(gòu)的機(jī)房環(huán)境、要求集群和平臺(tái)的部署、監(jiān)控和報(bào)警等要足夠高效.

本文從小米公司的應(yīng)用和實(shí)踐出發(fā)，在不失通用性的前提下，提出了一個(gè)基于開(kāi)源生態(tài)系統(tǒng)[3]的統(tǒng)一的大數(shù)據(jù)收集和處理的基礎(chǔ)平臺(tái).本文的主要貢獻(xiàn)是將開(kāi)源軟件的組件與自主研發(fā)的軟件組成一個(gè)完整的大數(shù)據(jù)平臺(tái)，并通過(guò)一系列的技術(shù)創(chuàng)新和改進(jìn)，使其能夠勝任真實(shí)場(chǎng)景下大數(shù)據(jù)對(duì)系統(tǒng)功能、性能、一致性和可用性等各方面的需求.本文首先介紹相關(guān)研究和實(shí)踐工作，然后分別描述平臺(tái)的總體架構(gòu)組成以及所做的改進(jìn)和創(chuàng)新，最后展望未來(lái)的發(fā)展路線和計(jì)劃.

1 相關(guān)工作

關(guān)于大數(shù)據(jù)平臺(tái)，業(yè)界較為有代表性的工作是Facebook的實(shí)時(shí)數(shù)據(jù)收集和分析平臺(tái)[3-4].該平臺(tái)的目標(biāo)是解決大規(guī)模(scalability)和低延遲(latency)的問(wèn)題，它既使用了Scribe[5]，HDFS(Hadoop distributed file system，是Hadoop項(xiàng)目的一個(gè)核心子項(xiàng)目[6])，MapReduce[7]，Hive[8]，HBase[9]等開(kāi)源系統(tǒng)，也自行開(kāi)發(fā)了Calligraphus，PTail，Puma等私有系統(tǒng).該平臺(tái)的側(cè)重點(diǎn)是數(shù)據(jù)的收集和匯聚，即實(shí)時(shí)的分類(lèi)統(tǒng)計(jì)，而非通用的數(shù)據(jù)計(jì)算和分析服務(wù).這個(gè)平臺(tái)最終能夠在9 GBps的寫(xiě)入速度下把延時(shí)控制在10 s之內(nèi).

學(xué)術(shù)界關(guān)于大數(shù)據(jù)平臺(tái)也有大量的研究和實(shí)踐，大致可以分為基于應(yīng)用、基于模型以及基于平臺(tái)3類(lèi).基于應(yīng)用的研究工作主要從Web日志挖掘這個(gè)應(yīng)用出發(fā)，考慮如何在Hadoop等開(kāi)源的生態(tài)系統(tǒng)上構(gòu)建分布式、可存儲(chǔ)和挖掘大規(guī)模日志數(shù)據(jù)的平臺(tái).主要的工作在于討論和驗(yàn)證分布式集群對(duì)于提高Web日志挖掘效率的可行性，并提出了相應(yīng)的解決方案[10-12].基于模型的工作重點(diǎn)是討論了更為通用的海量數(shù)據(jù)處理和計(jì)算模型，包括計(jì)算模型本身、網(wǎng)絡(luò)模型和優(yōu)化、編程模型等關(guān)鍵問(wèn)題，也討論了通用模型在具體應(yīng)用中的實(shí)際問(wèn)題和效果，比如數(shù)據(jù)清洗、容錯(cuò)等[13-15].此外，基于平臺(tái)的工作更多是從平臺(tái)自身的角度，比如數(shù)據(jù)管理、資源調(diào)度與虛擬化，并把整個(gè)系統(tǒng)分成多個(gè)層次[16-18].例如把系統(tǒng)分為數(shù)據(jù)庫(kù)訪問(wèn)層、數(shù)據(jù)處理層和業(yè)務(wù)應(yīng)用層[16]；將系統(tǒng)分為算法層、任務(wù)層和用戶層[18].

目前已有的工作主要集中研究了大數(shù)據(jù)平臺(tái)中一些重要組件的設(shè)計(jì)和實(shí)現(xiàn).由于小米公司的業(yè)務(wù)具有數(shù)據(jù)量大、業(yè)務(wù)需求多樣化、跨業(yè)務(wù)分析的需求大、部署環(huán)境復(fù)雜等特點(diǎn)，需要一個(gè)能管理海量數(shù)據(jù)整個(gè)生命周期的、完整的、通用的大數(shù)據(jù)平臺(tái).此外，還需解決現(xiàn)有的系統(tǒng)在數(shù)據(jù)收集、存儲(chǔ)和處理、一致性、可用性和效率等關(guān)鍵問(wèn)題上存在的缺陷.然而，現(xiàn)有開(kāi)源軟件的組合方案在數(shù)據(jù)存儲(chǔ)、壓縮、傳輸?shù)刃阅苌铣３o(wú)法滿足大型互聯(lián)網(wǎng)企業(yè)的海量業(yè)務(wù)處理需求；另一方面，現(xiàn)有方案也無(wú)法支持多樣化業(yè)務(wù)的分析和挖掘需求.此外，分布式部署環(huán)境下的可靠性尚需提升，存儲(chǔ)、帶寬、維護(hù)成本也需要進(jìn)行優(yōu)化.

本文從通用平臺(tái)設(shè)計(jì)的角度出發(fā)，主要解決下列問(wèn)題：大規(guī)模數(shù)據(jù)的實(shí)時(shí)收集和存儲(chǔ)、計(jì)算資源與作業(yè)的管理與調(diào)度、集群管理(部署、監(jiān)控和報(bào)警).同時(shí)，在功能、一致性、可用性和效率等方面做了重大改進(jìn)和提高.

2 總體架構(gòu)

一個(gè)完整通用的大數(shù)據(jù)平臺(tái)，至少要涵蓋數(shù)據(jù)的收集、存儲(chǔ)、計(jì)算和管理等方面.本平臺(tái)選用了部分開(kāi)源軟件作為系統(tǒng)的主要組件，包括ZooKeeper[19]，Hadoop(HDFSMapReduceYARN)，HBase，Hive， Scribe等.這些開(kāi)源軟件相對(duì)成熟，生態(tài)系統(tǒng)已經(jīng)比較完備，可用于快速搭建大數(shù)據(jù)平臺(tái).在此基礎(chǔ)上，本平臺(tái)增加了自主開(kāi)發(fā)的Minos監(jiān)控系統(tǒng)，并基于對(duì)業(yè)務(wù)特性的深入分析調(diào)整和完善平臺(tái)的設(shè)計(jì).圖1是平臺(tái)的整體架構(gòu)圖.出于完整性的考慮，該架構(gòu)圖還包含了該大數(shù)據(jù)平臺(tái)正在試驗(yàn)支持的計(jì)算框架，包括Storm[20]，Spark[21]，Impala[22]等.

Fig. 1 Overall architecture of big-data platform圖1 大數(shù)據(jù)平臺(tái)整體架構(gòu)圖

3 數(shù)據(jù)收集系統(tǒng)

對(duì)于大部分應(yīng)用場(chǎng)景來(lái)說(shuō)，業(yè)務(wù)數(shù)據(jù)的來(lái)源和格式經(jīng)常會(huì)有很多種，比如Apache或Nginx等Web Server的訪問(wèn)日志、業(yè)務(wù)自定義的CSV格式文件以及用Protocol Buffer[23]或者Thrift消息編碼過(guò)后的消息.一個(gè)足夠通用和靈活的數(shù)據(jù)收集平臺(tái)，需要同時(shí)滿足不同業(yè)務(wù)的多樣化需求.

許多開(kāi)源的數(shù)據(jù)收集系統(tǒng)，比如Facebook的Scribe[5]、LinkedIn的Kafka[24]、Cloudera的Flume[25]和Apache的Chukwa[26]，在業(yè)界都有廣泛的應(yīng)用.如果需要考慮到業(yè)務(wù)種類(lèi)較多，數(shù)據(jù)格式和對(duì)數(shù)據(jù)的后續(xù)處理有多種方式，期望的數(shù)據(jù)收集系統(tǒng)需要滿足下面6個(gè)特點(diǎn)(優(yōu)先級(jí)由高到低)：

1) 高可用.數(shù)據(jù)不會(huì)因?yàn)閱喂?jié)點(diǎn)或者少數(shù)節(jié)點(diǎn)的故障丟失.

2) 靈活.能夠滿足多種業(yè)務(wù)不同的使用方式和后續(xù)處理需求.

3) 使用簡(jiǎn)單.各業(yè)務(wù)接入系統(tǒng)的學(xué)習(xí)成本較低.

4) 易配置和維護(hù).較低的運(yùn)維成本.

5) 低外部依賴(lài).較低的運(yùn)維成本.

6) 架構(gòu)和實(shí)現(xiàn)簡(jiǎn)單.多數(shù)開(kāi)源系統(tǒng)需要一些改進(jìn)來(lái)適配業(yè)務(wù)的要求.

綜合考慮，Scribe在這6個(gè)方面有一定優(yōu)勢(shì)，圖2是本文提出的基于Scribe的數(shù)據(jù)收集系統(tǒng)架構(gòu)圖.

Fig. 2 Architecture of data collection system圖2 數(shù)據(jù)收集系統(tǒng)架構(gòu)圖

3.1 數(shù)據(jù)傳輸?shù)膬?yōu)化與改進(jìn)

在設(shè)計(jì)支持跨數(shù)據(jù)中心的分布式數(shù)據(jù)收集系統(tǒng)時(shí)，為了統(tǒng)計(jì)和數(shù)據(jù)處理的方便，經(jīng)常需要將所有的業(yè)務(wù)數(shù)據(jù)最終寫(xiě)入到同一個(gè)Hadoop集群里(也會(huì)在同一個(gè)數(shù)據(jù)中心)，引起跨數(shù)據(jù)中心的數(shù)據(jù)傳輸.實(shí)踐發(fā)現(xiàn)，大量的日志數(shù)據(jù)占據(jù)跨數(shù)據(jù)中心帶寬的相當(dāng)比例，浪費(fèi)了寶貴的帶寬資源.

本文提出了一種改進(jìn)方法，可以在傳輸時(shí)對(duì)收集的數(shù)據(jù)進(jìn)行壓縮.實(shí)踐證明這可以有效地減少數(shù)據(jù)傳輸量，很大地節(jié)約運(yùn)營(yíng)成本.

Scribe是通過(guò)Thrift的RPC接口對(duì)外提供服務(wù)，Thrift本身不提供傳輸數(shù)據(jù)壓縮的功能.Thrift本身也是一個(gè)分層設(shè)計(jì)的結(jié)構(gòu)，加上Scribe又是搭建在Thrift之上的應(yīng)用，所以有多個(gè)地方可以選擇來(lái)實(shí)現(xiàn)壓縮，比如Thrift Protocol層、Thrift Transport層或者在Scribe本身.由于其他Thrift Server也可能有數(shù)據(jù)傳輸壓縮的需求，本文提出了一種通用的解決方案，在Thrift Transport層來(lái)實(shí)現(xiàn)Compressed的傳輸協(xié)議，使得各類(lèi)Thrift Server都能與之兼容.

Thrift本身提供了良好的擴(kuò)展性.Thrift Server缺省使用了內(nèi)置的TFramedTransport傳輸協(xié)議，這是一個(gè)直接基于系統(tǒng)底層傳輸協(xié)議(在Thrift Server里就是TCP協(xié)議)之上的簡(jiǎn)單的非壓縮傳輸協(xié)議.同時(shí)Thrift Server在構(gòu)造的時(shí)候允許傳入一個(gè)TTransportFactory的傳輸層工廠類(lèi)，通過(guò)傳輸層的串聯(lián)模式，可以在內(nèi)置傳輸協(xié)議的基礎(chǔ)上實(shí)現(xiàn)更復(fù)雜的協(xié)議.

Fig. 3 Default transport protocol and compressed transport protocol圖3 缺省傳輸協(xié)議與壓縮傳輸協(xié)議

本文提出了一種新壓縮傳輸協(xié)議TSnappy-Transport和它的工廠類(lèi)TSnappyTransportFactory.圖3是原始的非壓縮的傳輸協(xié)議和本文提出的壓縮傳輸協(xié)議的對(duì)比.由于本文提出的協(xié)議使用了傳輸層的串聯(lián)模式，所以可以認(rèn)為在原始的傳輸協(xié)議基礎(chǔ)上，對(duì)它的有效載荷(payload)又進(jìn)行了一次分塊壓縮與編碼.

本文提出的壓縮傳輸協(xié)議使用了Snappy壓縮算法，它是Google提出并開(kāi)源的一個(gè)壓縮算法和代碼庫(kù)[27].和其他常用的壓縮算法相比，它的最大特點(diǎn)是在壓縮率可接受的情況下，壓縮和解壓縮的速度非?？?例如與zlib的快速模式相比，對(duì)于大部分輸入Snappy能夠快10倍以上，但其壓縮率會(huì)有20%～50%的損失.所以該算法特別適用于在線傳輸數(shù)據(jù)的壓縮，不會(huì)給CPU造成嚴(yán)重負(fù)擔(dān)或明顯增加延遲.

根據(jù)Google的官方數(shù)據(jù)，使用64位Intel Core i7 CPU，單核模式下Snappy的壓縮速度超過(guò)250 MBps，解壓速度超過(guò)500 MBps.線上服務(wù)器一般是8～24核的配置，所以它引起的CPU開(kāi)銷(xiāo)基本可以忽略不計(jì).

目前的實(shí)現(xiàn)僅支持了一種壓縮算法，所以本文提出的壓縮傳輸層協(xié)議直接命名為Snappy Transport.理論上該協(xié)議可以擴(kuò)展支持任意的塊壓縮算法，以便于業(yè)務(wù)根據(jù)實(shí)際需求進(jìn)行選擇，留給將來(lái)的工作做擴(kuò)展.

表1是從3種典型的業(yè)務(wù)日志數(shù)據(jù)中分別抽取一段，分別用未壓縮和壓縮2種模式傳輸日志消耗的網(wǎng)絡(luò)帶寬以及壓縮率.

Table 1 Compression Ratio of Data Transportation

在真實(shí)業(yè)務(wù)場(chǎng)景下，壓縮傳輸只使用了原來(lái)30%左右的網(wǎng)絡(luò)帶寬，并且CPU沒(méi)有成為新的瓶頸，因此也不需要部署新的Scribe Server來(lái)分擔(dān)負(fù)載.該項(xiàng)改進(jìn)明顯降低了日志數(shù)據(jù)在網(wǎng)絡(luò)傳輸上的成本.

3.2 負(fù)載均衡和故障處理的優(yōu)化與改進(jìn)

數(shù)據(jù)收集系統(tǒng)很重要的一個(gè)要求是高可用性.Scribe在這方面有獨(dú)特設(shè)計(jì)，比如Buffer Store可以在下游的主通道不可用的時(shí)候，先把數(shù)據(jù)寫(xiě)到本地文件(也可以配置為寫(xiě)到其他Store中)，待下游主通道可用時(shí)再把本地緩存的數(shù)據(jù)發(fā)送過(guò)去.

在本文提出的數(shù)據(jù)收集系統(tǒng)中，需要有一套中心服務(wù)器負(fù)責(zé)接受所有業(yè)務(wù)的數(shù)據(jù)，再把數(shù)據(jù)寫(xiě)入到統(tǒng)一的HDFS集群中.為了避免該服務(wù)器成為系統(tǒng)的故障點(diǎn)，需要用一主一備2個(gè)服務(wù)器來(lái)提高可用性，用Buffer Store配置成主服務(wù)器不可用時(shí)寫(xiě)入備服務(wù)器.這在應(yīng)對(duì)服務(wù)器的偶然宕機(jī)或者運(yùn)維操作時(shí)將起關(guān)鍵作用，顯著提升可用性.

然而，在這種配置下的單個(gè)服務(wù)器需要承擔(dān)系統(tǒng)的所有負(fù)載(主和備同時(shí)只有一個(gè)在提供服務(wù)).隨著業(yè)務(wù)數(shù)據(jù)流量的增加，在業(yè)務(wù)峰值時(shí)，流量經(jīng)常超過(guò)單個(gè)服務(wù)器的處理能力.如果主服務(wù)器因?yàn)槌d變得不可用，所有數(shù)據(jù)又都會(huì)寫(xiě)到備服務(wù)器，由于這些服務(wù)器的配置相同，備服務(wù)器也常常超載，導(dǎo)致整個(gè)系統(tǒng)的不可用或者抖動(dòng).實(shí)際上并不需要關(guān)心具體是哪個(gè)Scribe服務(wù)器把數(shù)據(jù)寫(xiě)入到HDFS，所有服務(wù)器的角色是對(duì)等的，所以需要一個(gè)完備的負(fù)載均衡方案.Scribe有一種Bucket Store的配置，具有負(fù)載均衡的能力，但對(duì)Scribe服務(wù)器的故障處理(failover)支持差，單個(gè)服務(wù)器故障也會(huì)導(dǎo)致整個(gè)系統(tǒng)不可用.本文對(duì)此提出了4點(diǎn)改進(jìn)以提高可用性:

1) 跟蹤所有服務(wù)器的狀態(tài)，未能成功應(yīng)答的服務(wù)器會(huì)被標(biāo)志成“不可用”.

2) 只有處于“可用”狀態(tài)的服務(wù)器才會(huì)成為日志數(shù)據(jù)下發(fā)的候選.

3) 定義了一種“round_robin”的Bucket新類(lèi)型，在所有“可用”服務(wù)器中循環(huán)選擇候選下發(fā)數(shù)據(jù)，直到有一個(gè)服務(wù)器成功應(yīng)答(即發(fā)送成功).

下面通過(guò)模擬實(shí)驗(yàn)來(lái)比較改進(jìn)前后日志收集系統(tǒng)的總體可用性.假設(shè)單個(gè)Scribe服務(wù)器的可用性為p，總共有n臺(tái)Scribe服務(wù)器，將n臺(tái)Scribe服務(wù)器配成n個(gè)bucket.假設(shè)各個(gè)服務(wù)器的可用性是獨(dú)立的，可以推導(dǎo)出總體可用性為

(1)

在改進(jìn)之后，同樣假設(shè)各個(gè)服務(wù)器的可用性是獨(dú)立的，但至少要有m個(gè)服務(wù)器可用總體系統(tǒng)才可用(考慮到服務(wù)器的處理能力)，可以推導(dǎo)出總體可用性為

(2)

表2比較了改進(jìn)前后日志收集系統(tǒng)的總體可用性.假設(shè)單個(gè)Scribe服務(wù)器的可用性p=0.99，同時(shí)至少有一半的服務(wù)器可用總體系統(tǒng)才可用(m=n2).這個(gè)改進(jìn)徹底解決了Scribe在負(fù)載均衡和故障處理上的缺陷.在業(yè)務(wù)中的實(shí)踐也表明進(jìn)行上述改進(jìn)后，可用性和系統(tǒng)的可擴(kuò)展性有明顯提高，沒(méi)有再出現(xiàn)因?yàn)槌d或者單機(jī)故障造成的系統(tǒng)不可用.

Table 2 Comparison of Log Collection System OverallAvailability BeforeAfter Improvement

表2 改進(jìn)前后日志收集系統(tǒng)總體可用性的比較

(p=0.99,m=n2)

Table 2 Comparison of Log Collection System OverallAvailability BeforeAfter Improvement

nBeforeImprovementAfterImprovement20．98010．999940．960596010．9999960360．9414801494010．99999985239

4 數(shù)據(jù)存儲(chǔ)系統(tǒng)

數(shù)據(jù)規(guī)模較大的存儲(chǔ)會(huì)超出單機(jī)的存儲(chǔ)能力，需要一個(gè)分布式的存儲(chǔ)系統(tǒng).傳統(tǒng)的技術(shù)包括存儲(chǔ)區(qū)域網(wǎng)絡(luò)(storage area network, SAN)、網(wǎng)絡(luò)附加存儲(chǔ)(network attached storage, NAS)、網(wǎng)絡(luò)文件系統(tǒng)(network file system, NFS)等.這些存儲(chǔ)技術(shù)都需要高端或?qū)Ｓ么鎯?chǔ)設(shè)備，成本通常較高.

近年來(lái)隨著低成本存儲(chǔ)設(shè)備的可靠性提高，軟件冗余和糾錯(cuò)技術(shù)的發(fā)展，也逐漸出現(xiàn)了基于廉價(jià)和通用存儲(chǔ)設(shè)備的分布式文件系統(tǒng).尤其是Google發(fā)表了內(nèi)部設(shè)計(jì)和使用的分布式文件系統(tǒng)(Google file system, GFS)[28]，驗(yàn)證了這種技術(shù)在提供類(lèi)似可靠性的前提下，性價(jià)比和可擴(kuò)展性有很大的提高.

此后出現(xiàn)了大量的開(kāi)源實(shí)現(xiàn).其中HDFS是使用比較廣泛、也比較成熟的一種開(kāi)源實(shí)現(xiàn).本文提出的大數(shù)據(jù)平臺(tái)也是以HDFS為核心的存儲(chǔ)系統(tǒng).

作為一個(gè)分布式存儲(chǔ)系統(tǒng)，最重要的衡量指標(biāo)是一致性(可靠性)、可用性和性能.尤其是一致性和可用性，往往是選擇一個(gè)分布式存儲(chǔ)系統(tǒng)時(shí)的關(guān)鍵因素.在部署和使用開(kāi)源的HDFS版本時(shí)，我們發(fā)現(xiàn)HDFS在一致性和可用性上的一些嚴(yán)重缺陷.本文提出了相應(yīng)的改進(jìn)和優(yōu)化方案并在業(yè)務(wù)系統(tǒng)中部署了改進(jìn)后的版本.

4.1 一致性的優(yōu)化與改進(jìn)

存儲(chǔ)系統(tǒng)由于各種原因(新特性、修復(fù)缺陷等)，會(huì)對(duì)軟件版本進(jìn)行發(fā)布和升級(jí).為了盡量避免對(duì)業(yè)務(wù)的影響和提高可用性，更好的實(shí)踐是在持續(xù)提供服務(wù)的情況下，對(duì)集群中的各個(gè)節(jié)點(diǎn)進(jìn)行逐臺(tái)滾動(dòng)升級(jí).

德斯拜思機(jī)電控制技術(shù)（上海）有限公司是德國(guó)dSPACE于2008年在中國(guó)建立的分支機(jī)構(gòu)。20多年以來(lái)，德國(guó)dSPACE的高品質(zhì)現(xiàn)成軟件和硬件工具使工程師可以隨心所欲地進(jìn)行設(shè)計(jì)和創(chuàng)新，并顯著減少了開(kāi)發(fā)時(shí)間和成本。憑借廣泛的產(chǎn)品系列和高新技術(shù)，該公司成為汽車(chē)工業(yè)、航空航天領(lǐng)域和工業(yè)自動(dòng)化領(lǐng)域最受歡迎的開(kāi)發(fā)合作伙伴之一。

在實(shí)施過(guò)程中發(fā)現(xiàn)在這種升級(jí)方式下，HDFS上的文件很小概率下有損壞的情況.對(duì)于一個(gè)存儲(chǔ)系統(tǒng)而言，文件損壞是很?chē)?yán)重的缺陷，所以也是本文必須要解決的問(wèn)題.由于該現(xiàn)象是偶發(fā)的，深入分析后確認(rèn)是在HDFS寫(xiě)數(shù)據(jù)的流水線中間節(jié)點(diǎn)宕機(jī)后恢復(fù)的過(guò)程中，由于HDFS本身邏輯的缺陷，導(dǎo)致Checksum文件多出一個(gè)Checksum，從而導(dǎo)致HDFS校驗(yàn)Checksum失敗，進(jìn)而認(rèn)為數(shù)據(jù)被損壞.這已經(jīng)相當(dāng)于出現(xiàn)了丟失數(shù)據(jù)的現(xiàn)象，之前已經(jīng)成功寫(xiě)入的數(shù)據(jù)無(wú)法再正確讀出，從而破壞了一致性的約定.

在Hadoop2.0版本時(shí)我們已向社區(qū)匯報(bào)了該問(wèn)題，并提交了補(bǔ)丁代碼[29].該問(wèn)題被社區(qū)確認(rèn)為嚴(yán)重的數(shù)據(jù)損壞問(wèn)題，并在Hadoop2.7版本中得到了解決.對(duì)此缺陷進(jìn)行了修正之后，再未出現(xiàn)集群逐臺(tái)滾動(dòng)升級(jí)時(shí)的文件損壞.

除了需要對(duì)存儲(chǔ)系統(tǒng)的軟件版本進(jìn)行升級(jí)外，經(jīng)常也會(huì)有需求添加或移除一些存儲(chǔ)節(jié)點(diǎn)(DataNode).添加存儲(chǔ)節(jié)點(diǎn)的過(guò)程比較簡(jiǎn)單，只需要在新的節(jié)點(diǎn)上配置好軟件環(huán)境并啟動(dòng)相應(yīng)的服務(wù)即可，將來(lái)的數(shù)據(jù)寫(xiě)入就會(huì)依據(jù)一定的概率和規(guī)則分配到新節(jié)點(diǎn)上.但移除舊節(jié)點(diǎn)會(huì)復(fù)雜一些，為了防止數(shù)據(jù)丟失或者可靠性下降，需要先將舊節(jié)點(diǎn)所服務(wù)的數(shù)據(jù)移到還將提供服務(wù)的節(jié)點(diǎn)之后才能下線.同樣的，需要存儲(chǔ)集群在整個(gè)移除過(guò)程仍能正常服務(wù).

HDFS提供了從集群優(yōu)雅地卸下存儲(chǔ)節(jié)點(diǎn)的機(jī)制(decommission).在集群遷移的過(guò)程中，需要同時(shí)卸下(decommission)多個(gè)節(jié)點(diǎn).實(shí)施過(guò)程中發(fā)現(xiàn)，當(dāng)Decommission進(jìn)行到最后的時(shí)候，有部分節(jié)點(diǎn)無(wú)法結(jié)束Decommission，強(qiáng)制把這些節(jié)點(diǎn)關(guān)閉服務(wù)發(fā)現(xiàn)會(huì)有數(shù)據(jù)丟失.經(jīng)過(guò)調(diào)查發(fā)現(xiàn)，在移除節(jié)點(diǎn)的過(guò)程中，如果某個(gè)數(shù)據(jù)塊的3個(gè)副本都在需要移除的節(jié)點(diǎn)上，而且這個(gè)數(shù)據(jù)塊在移除時(shí)正在被打開(kāi)寫(xiě)的話，這里HDFS自身的處理邏輯有缺陷，會(huì)導(dǎo)致這樣的數(shù)據(jù)塊無(wú)法被正常復(fù)制到能夠提供正常服務(wù)的節(jié)點(diǎn)上去.

針對(duì)該缺陷，本文調(diào)整了文件完成的判斷條件：只要活躍節(jié)點(diǎn)和待移除節(jié)點(diǎn)上的塊復(fù)本數(shù)滿足最小復(fù)本數(shù)，則正常結(jié)束文件.之后由Decommision流程將數(shù)據(jù)塊從待移除節(jié)點(diǎn)復(fù)制到活躍節(jié)點(diǎn)，完成全部數(shù)據(jù)塊復(fù)制后再移除節(jié)點(diǎn)，實(shí)現(xiàn)了無(wú)數(shù)據(jù)損失的節(jié)點(diǎn)退出.

下面通過(guò)模擬實(shí)驗(yàn)計(jì)算在改進(jìn)之前出現(xiàn)異常(移除節(jié)點(diǎn)時(shí)無(wú)法正常結(jié)束或者丟失數(shù)據(jù))的概率.假設(shè)集群有n個(gè)存儲(chǔ)節(jié)點(diǎn)，同時(shí)移除m個(gè)存儲(chǔ)節(jié)點(diǎn)，當(dāng)時(shí)有k個(gè)文件同時(shí)被寫(xiě)入數(shù)據(jù).根據(jù)前面的分析，只要任何一個(gè)正在被寫(xiě)入的文件的3個(gè)副本都在這m個(gè)存儲(chǔ)節(jié)點(diǎn)，就會(huì)出現(xiàn)異常.假設(shè)副本在數(shù)據(jù)節(jié)點(diǎn)上的分配是均勻分布且獨(dú)立的，可以推導(dǎo)出出現(xiàn)異常的概率為

(3)

Table 3 Probability of Abnormity for RepresentativeConfigurations

表3給出了5種典型配置下出現(xiàn)異常的概率.可以看出在對(duì)此缺陷進(jìn)行了修正之前，出現(xiàn)異常導(dǎo)致移除節(jié)點(diǎn)時(shí)無(wú)法正常結(jié)束或者丟失數(shù)據(jù)的概率較大.對(duì)此缺陷進(jìn)行了修正之后，再未出現(xiàn)集群移除節(jié)點(diǎn)時(shí)無(wú)法正常結(jié)束或者丟失數(shù)據(jù)的情況.

4.2 可用性的優(yōu)化與改進(jìn)

當(dāng)前HDFS的實(shí)現(xiàn)中，在客戶端有一個(gè)數(shù)據(jù)節(jié)點(diǎn)(DataNode)的黑名單，在用戶使用客戶端操作HDFS的過(guò)程中，如果發(fā)現(xiàn)某個(gè)數(shù)據(jù)節(jié)點(diǎn)出現(xiàn)故障，都會(huì)被加入到這個(gè)黑名單，后續(xù)該客戶端就不再?gòu)脑摂?shù)據(jù)節(jié)點(diǎn)讀寫(xiě)數(shù)據(jù).這樣是一種優(yōu)化，目的是避免從故障或者繁忙的節(jié)點(diǎn)讀寫(xiě)數(shù)據(jù).

在集群規(guī)模較小時(shí)，由于集群上的計(jì)算任務(wù)繁重，高負(fù)載的情況時(shí)有發(fā)生，導(dǎo)致客戶端偶爾發(fā)生數(shù)據(jù)節(jié)點(diǎn)讀、寫(xiě)超時(shí)的情況.這類(lèi)數(shù)據(jù)節(jié)點(diǎn)將被加入到上述黑名單.在本文的數(shù)據(jù)收集系統(tǒng)中，中央Scribe Server寫(xiě)HDFS的模式是：打開(kāi)一個(gè)文件持續(xù)寫(xiě)，直到達(dá)到一定的大小，或者到第2天再切換文件.在實(shí)際的生產(chǎn)環(huán)境中，有些業(yè)務(wù)數(shù)據(jù)量不大但持續(xù)會(huì)有，一天的日志總大小達(dá)不到切換文件的條件，因此，一整天都在持續(xù)地寫(xiě)同一個(gè)文件.在這樣的情況下，當(dāng)所有的數(shù)據(jù)節(jié)點(diǎn)都進(jìn)入到黑名單后，Scribe Server對(duì)HDFS就不能寫(xiě)了.由于這個(gè)黑名單是文件流級(jí)別的，所以后續(xù)除非重新創(chuàng)建文件流，否則該文件流涉及到數(shù)據(jù)節(jié)點(diǎn)的操作都會(huì)失敗.這時(shí)已經(jīng)寫(xiě)入的數(shù)據(jù)不會(huì)丟失，而且能夠正確讀出，但從Scribe Server的角度，HDFS集群已經(jīng)處于不可用的狀態(tài).

下面通過(guò)模擬實(shí)驗(yàn)來(lái)計(jì)算在改進(jìn)之前HDFS集群出現(xiàn)不可用的概率.假設(shè)集群有n個(gè)存儲(chǔ)節(jié)點(diǎn)，每個(gè)存儲(chǔ)節(jié)點(diǎn)在這個(gè)時(shí)間周期內(nèi)(這里是1 d)出現(xiàn)不可用(主要是讀寫(xiě)超時(shí))的概率為p，這個(gè)時(shí)間周期內(nèi)有k個(gè)文件被寫(xiě)入數(shù)據(jù)且未出現(xiàn)文件切換.假設(shè)副本在數(shù)據(jù)節(jié)點(diǎn)上的分配是均勻分布且獨(dú)立的，存儲(chǔ)節(jié)點(diǎn)出現(xiàn)不可用是獨(dú)立事件，可以推導(dǎo)出HDFS集群出現(xiàn)不可用的概率為

(4)

表4給出了6種典型配置下出現(xiàn)不可用(某個(gè)文件無(wú)法寫(xiě)入)的概率.

在優(yōu)化和改進(jìn)之前，HDFS集群有較高的概率出現(xiàn)某個(gè)文件不可寫(xiě)入.在本平臺(tái)中，存儲(chǔ)與計(jì)算共享同一個(gè)集群，而且集群上的計(jì)算任務(wù)大，單個(gè)機(jī)器在1d的時(shí)間周期里，出現(xiàn)(對(duì)某個(gè)客戶端至少一次)讀寫(xiě)超時(shí)的概率非常高.另外計(jì)算任務(wù)是批處理提交的，機(jī)器出現(xiàn)讀寫(xiě)超時(shí)并不是獨(dú)立的，所以會(huì)經(jīng)常遇到某個(gè)文件不可寫(xiě)入的情況.

Table 4 Probability of Unavailability for RepresentativeConfigurations

對(duì)此本文做了優(yōu)化和改進(jìn)，對(duì)于進(jìn)入黑名單的數(shù)據(jù)節(jié)點(diǎn)，當(dāng)它進(jìn)入黑名單超過(guò)一定的時(shí)間，給與它一定的機(jī)會(huì)讓其復(fù)活.從上線后的效果來(lái)看，對(duì)可用性有很明顯的提高，再未出現(xiàn)由于數(shù)據(jù)節(jié)點(diǎn)負(fù)載高造成的偶爾超時(shí)，導(dǎo)致某個(gè)文件不可寫(xiě)入的情況.

5 計(jì)算系統(tǒng)

和分布式的數(shù)據(jù)存儲(chǔ)系統(tǒng)相類(lèi)似，對(duì)規(guī)模較大的數(shù)據(jù)進(jìn)行處理和計(jì)算，往往也會(huì)超出單機(jī)的處理能力，需要一個(gè)并行計(jì)算的系統(tǒng)和框架，傳統(tǒng)的技術(shù)包括MPI和分布式數(shù)據(jù)庫(kù)等.

Google近些年陸續(xù)發(fā)表了內(nèi)部設(shè)計(jì)和使用的計(jì)算框架，包括MapReduce，Sawzall[30]，Dremel[31]等，為大規(guī)模數(shù)據(jù)的計(jì)算框架帶來(lái)了一些新思路.其中MapReduce是把所有的并行計(jì)算都分解為Map，Shuffle和Reduce這3個(gè)階段進(jìn)行并行化，能夠滿足一大類(lèi)并行計(jì)算的需求；而Dremel則是用SQL語(yǔ)句來(lái)表示計(jì)算任務(wù)，由后臺(tái)的計(jì)算系統(tǒng)把SQL語(yǔ)句翻譯成執(zhí)行計(jì)劃，在多個(gè)節(jié)點(diǎn)上并行執(zhí)行.這2種框架非常適合大規(guī)劃數(shù)據(jù)的批次處理.

在開(kāi)源生態(tài)系統(tǒng)里，Hadoop的MapReduce(也是Hadoop項(xiàng)目的一個(gè)核心子項(xiàng)目)和Hive是對(duì)應(yīng)的2個(gè)實(shí)現(xiàn)，也是目前使用廣泛、成熟度較高的實(shí)現(xiàn).本文提出的大數(shù)據(jù)平臺(tái)，也是以開(kāi)源的MapReduce和Hive為核心的計(jì)算系統(tǒng).

在具體的MapReduce版本方面本文選用了最新的Hadoop MapReduce 2.0，該版本引入了通用的資源調(diào)度系統(tǒng)YARN，整體架構(gòu)也代表了下一代計(jì)算和資源管理的發(fā)展方向，也得到了業(yè)界的廣泛認(rèn)可和支持.在2.0的架構(gòu)中，資源調(diào)度和作業(yè)調(diào)度邏輯分離，有效地減輕了中央節(jié)點(diǎn)的壓力，以提供更好的集群可擴(kuò)展性.各個(gè)MapReduce作業(yè)之間是獨(dú)立的流程，由各自的Job Master進(jìn)行管理，單個(gè)作業(yè)的失敗不會(huì)影響到其他作業(yè)，因此作業(yè)的容錯(cuò)方面較1.0的架構(gòu)也有了大幅改進(jìn).另外相比先前架構(gòu)中以槽位(slot)作為單一調(diào)度維度，新架構(gòu)中引入了內(nèi)存、CPU等多個(gè)調(diào)度維度，用戶可以更準(zhǔn)確地對(duì)任務(wù)所需要的資源進(jìn)行描述，有利于集群資源的有效利用.此外，2.0架構(gòu)中的通用資源系統(tǒng)還支持在其上運(yùn)行多種非MapReduce的作業(yè)，這也為不同業(yè)務(wù)的集群復(fù)用提供了可能.

5.1 計(jì)算資源的配額管理

在本平臺(tái)的Hadoop應(yīng)用中，離線集群存儲(chǔ)了多種業(yè)務(wù)的數(shù)據(jù)，各業(yè)務(wù)通常都有各自的計(jì)算處理需求.除了HDFS 存儲(chǔ)配額管理之外，還需要為各業(yè)務(wù)的計(jì)算需求合理地分配計(jì)算資源.

Hadoop的YARN延續(xù)了之前MapReduce的調(diào)度器的模型，包括先入先出調(diào)度器(FifoScheduler)、容量調(diào)度器(CapacityScheduler)以及公平調(diào)度器(FairScheduler).先入先出調(diào)度器是系統(tǒng)的默認(rèn)調(diào)度器，它不考慮作業(yè)間的優(yōu)先級(jí)差異，簡(jiǎn)單地按先到先服務(wù)的策略進(jìn)行作業(yè)調(diào)度，在前面的作業(yè)沒(méi)有執(zhí)行完前，后續(xù)的作業(yè)只能排隊(duì)等待，因此它并不適合本文所討論的企業(yè)級(jí)需求場(chǎng)景；容量調(diào)度器和公平調(diào)度器在演化的過(guò)程中相互取長(zhǎng)補(bǔ)短，功能特性具有一定的相似性，它們相比默認(rèn)的調(diào)度器支持作業(yè)的優(yōu)先級(jí)設(shè)置，支持多級(jí)調(diào)度隊(duì)列的配置，支持作業(yè)搶占等，適用于企業(yè)級(jí)集群的資源分配場(chǎng)景.考慮到公平調(diào)度器還在開(kāi)發(fā)和完善階段，本文選用了更成熟的容量調(diào)度器作為資源配額管理的方案.

在實(shí)踐中，面對(duì)不同業(yè)務(wù)的計(jì)算需求，本平臺(tái)為各主要業(yè)務(wù)建立作業(yè)隊(duì)列，為每個(gè)隊(duì)列配置一定的計(jì)算資源底限以保證基本運(yùn)算需求，同時(shí)為每個(gè)隊(duì)列設(shè)置允許在集群空閑時(shí)最多使用的資源量，以提高集群整體的利用率.考慮到業(yè)務(wù)的層次化結(jié)構(gòu)，本平臺(tái)還在一級(jí)作業(yè)隊(duì)列下建立二級(jí)隊(duì)列，以滿足一個(gè)業(yè)務(wù)內(nèi)部的細(xì)分計(jì)算需求.通過(guò)隊(duì)列的合理配額配置，在對(duì)各業(yè)務(wù)的資源需求進(jìn)行隔離的同時(shí)，也能夠充分復(fù)用集群，最大化集群的資源利用率.

5.2 多維度資源調(diào)度

在Hadoop 1.0中，計(jì)算資源使用槽位作為表示方式.一個(gè)計(jì)算節(jié)點(diǎn)上的CPU、內(nèi)存等資源被等分為若干個(gè)槽位，每個(gè)任務(wù)則描述需求多少個(gè)槽位的資源.這種方式將多維度的資源抽象為一種“資源”，簡(jiǎn)化了資源調(diào)度問(wèn)題，但這種方式也有很多不足：槽位是預(yù)先靜態(tài)劃分的，無(wú)法最佳地適應(yīng)動(dòng)態(tài)變化的作業(yè)，通常導(dǎo)致由于劃分粒度過(guò)大而造成資源的浪費(fèi)；其次，單一維度的資源描述不利于對(duì)CPU或內(nèi)存需求多樣化的任務(wù)共享資源，降低了集群的資源利用率；另外，以槽位作為資源描述單位也不方便對(duì)任務(wù)進(jìn)行使用資源的隔離.

針對(duì)基于槽位調(diào)度的不足，Hadoop 2.0的YARN引入了多維度的資源調(diào)度，目前支持CPU和內(nèi)存2個(gè)維度.例如，在新框架下，一個(gè)偏內(nèi)存型的任務(wù)可以描述它需要4 GB的內(nèi)存和1個(gè)CPU核，而偏CPU型的任務(wù)可以描述它需要1 GB內(nèi)存和4個(gè)CPU核，這樣的2個(gè)任務(wù)在不同維度上的需求互補(bǔ)性，可以最大化地發(fā)揮計(jì)算節(jié)點(diǎn)的資源利用率.除了充分提高資源利用率的同時(shí)，多維度的資源調(diào)度也有利于控制一個(gè)節(jié)點(diǎn)的并發(fā)任務(wù)，避免讓節(jié)點(diǎn)負(fù)載過(guò)高.假設(shè)在集群中節(jié)點(diǎn)的內(nèi)存較大(如64 GB)，而CPU核數(shù)較少(如8核)，在只有內(nèi)存一個(gè)維度調(diào)度的情況下，要求1 GB內(nèi)存的任務(wù)會(huì)在一個(gè)節(jié)點(diǎn)上運(yùn)行幾十個(gè)，任務(wù)彼此間會(huì)形成對(duì)CPU資源的強(qiáng)烈競(jìng)爭(zhēng)，導(dǎo)致機(jī)器負(fù)載高，作業(yè)執(zhí)行速率也大幅下降.引入CPU維度后，任務(wù)默認(rèn)指定需求一個(gè)CPU核，調(diào)度時(shí)會(huì)因在這一維度達(dá)到上限而不再下發(fā)任務(wù)，從而控制機(jī)器的負(fù)載，保證作業(yè)的計(jì)算性能.

多維度調(diào)度的引入大大優(yōu)化了資源的描述和資源調(diào)度功能，但由于它是Hadoop 2.0中較新的特性，所以也有一些潛在的問(wèn)題.例如在使用過(guò)程中發(fā)現(xiàn)它在調(diào)度時(shí)計(jì)算下發(fā)任務(wù)量時(shí)存在缺陷，可能會(huì)而導(dǎo)致MapReduce作業(yè)的調(diào)度死鎖.針對(duì)這一較嚴(yán)重的問(wèn)題，本文對(duì)容量調(diào)度器進(jìn)行了修改，在下發(fā)時(shí)綜合多維度資源計(jì)算下發(fā)任務(wù)量，從而避免了調(diào)度死鎖的發(fā)生.

5.3 容量調(diào)度器的負(fù)載均衡

容量調(diào)度器的功能滿足了本平臺(tái)的大部分需求，但它也存在不完善的地方.在實(shí)踐中，調(diào)度器會(huì)在計(jì)算節(jié)點(diǎn)心跳匯報(bào)時(shí)，盡可能多地下發(fā)任務(wù).這一策略不利于計(jì)算任務(wù)在集群中的均勻分布：在集群整體空閑時(shí)，任務(wù)集中分布在少量的節(jié)點(diǎn)上，并沒(méi)有充分利用集群中節(jié)點(diǎn)的并發(fā)計(jì)算能力.針對(duì)這一問(wèn)題，本文修改了調(diào)度下發(fā)策略，限制單節(jié)點(diǎn)單次下發(fā)的任務(wù)上限.修改后雖然會(huì)降低平均下發(fā)的速率，但由于任務(wù)在集群中的分布更新均勻，有效地利用了節(jié)點(diǎn)間的并發(fā)，因此整體上縮短了作業(yè)級(jí)的執(zhí)行時(shí)間：在集群空閑時(shí)單作業(yè)執(zhí)行時(shí)間能縮短30%～50%.另外引入單次下發(fā)的上限，在一定程度上也避免了內(nèi)存或CPU需求密集性的任務(wù)集中分布在單個(gè)節(jié)點(diǎn)，有利于使一個(gè)節(jié)點(diǎn)上的任務(wù)需求多樣化，提高單節(jié)點(diǎn)上可運(yùn)行的任務(wù)數(shù)和節(jié)點(diǎn)資源的利用率.

5.4 MapReduce開(kāi)發(fā)流程優(yōu)化

在離線處理集群的運(yùn)營(yíng)過(guò)程中，除了積累Hadoop系統(tǒng)的應(yīng)用和改進(jìn)經(jīng)驗(yàn)之外，對(duì)于優(yōu)化MapReduce開(kāi)發(fā)流程本文也進(jìn)行了探索和嘗試.分布式環(huán)境中，當(dāng)程序出現(xiàn)問(wèn)題時(shí)，快速準(zhǔn)確地定位問(wèn)題是一個(gè)巨大挑戰(zhàn).通常情況下，MapReduce程序的開(kāi)發(fā)者在編寫(xiě)完程序后會(huì)在集群上直接運(yùn)行測(cè)試，當(dāng)出現(xiàn)異常時(shí)，很多時(shí)候需要查看作業(yè)日志，甚至到遠(yuǎn)程計(jì)算節(jié)點(diǎn)上分析問(wèn)題.這種方式的問(wèn)題定位成本非常高，既耗費(fèi)了開(kāi)發(fā)者的大量時(shí)間，也浪費(fèi)了寶貴的集群計(jì)算資源.在協(xié)助用戶定位問(wèn)題的過(guò)程中發(fā)現(xiàn)，很多問(wèn)題并不需要在集群上運(yùn)行作業(yè)才能暴露出來(lái)，通過(guò)單元測(cè)試或本地模式運(yùn)行就可以有效地排查.因此本文提出一個(gè)優(yōu)化的開(kāi)發(fā)流程如下：

1) 開(kāi)發(fā)程序時(shí)，利用MR Unit測(cè)試框架為Mapper和Reducer等編寫(xiě)單元測(cè)試.通過(guò)單元測(cè)試覆蓋主要場(chǎng)景，保證程序的基本正確性.

2) 取部分真實(shí)輸入數(shù)據(jù)，利用MapReduce的本地模式運(yùn)行作業(yè)，排查真實(shí)數(shù)據(jù)中的邊界情況.如果遇到錯(cuò)誤，則可以利用Eclipse等集成開(kāi)發(fā)環(huán)境單機(jī)調(diào)試，分析定位問(wèn)題.之后可以把新的場(chǎng)景補(bǔ)充到單元測(cè)試之中.

3) 上述2個(gè)階段運(yùn)行成功之后，再在集群上對(duì)更多的數(shù)據(jù)進(jìn)行測(cè)試.在這一過(guò)程中重點(diǎn)關(guān)注作業(yè)的運(yùn)算性能和資源使用情況，可以利用MapReduce的計(jì)數(shù)器功能查看系統(tǒng)及用戶自定義的計(jì)數(shù)器，從而優(yōu)化作業(yè)配置.

上述開(kāi)發(fā)流程將問(wèn)題以最小代價(jià)暴露出來(lái)，充分利用單機(jī)調(diào)試的便利性，盡量減少集群調(diào)試的需要，整體上降低了開(kāi)發(fā)者定位問(wèn)題的難度，有效地提高了開(kāi)發(fā)效率.

5.5 MapReduce作業(yè)調(diào)優(yōu)

MapReduce程序開(kāi)發(fā)者除了要保證數(shù)據(jù)處理邏輯的正確性之外，還需要關(guān)注作業(yè)在集群中的運(yùn)行性能和資源消耗.后者要求開(kāi)發(fā)者對(duì)數(shù)據(jù)處理邏輯以及MapReduce和YARN系統(tǒng)的細(xì)節(jié)有深入的了解，能夠根據(jù)實(shí)際情況調(diào)優(yōu)作業(yè)參數(shù)，這無(wú)疑增加了MapReduce用戶的使用成本.在協(xié)助用戶進(jìn)行作業(yè)性能分析和參數(shù)優(yōu)化的過(guò)程中，發(fā)現(xiàn)常見(jiàn)的問(wèn)題可以按處理階段概括為以下3類(lèi)：

1) Map階段.內(nèi)存配置不合理導(dǎo)致內(nèi)存數(shù)據(jù)頻繁落地磁盤(pán)，磁盤(pán)IO開(kāi)銷(xiāo)大.

2) Shuffle階段.Map輸出未壓縮導(dǎo)致Shuffle數(shù)據(jù)量過(guò)大，帶寬開(kāi)銷(xiāo)大；Reduce端的Shuffle內(nèi)存及并發(fā)參數(shù)的配置不合理導(dǎo)致磁盤(pán)IO開(kāi)銷(xiāo)大或數(shù)據(jù)拉取慢.

3) Reduce階段.任務(wù)并發(fā)數(shù)不足導(dǎo)致單任務(wù)處理數(shù)據(jù)量過(guò)大；Reduce的輸出數(shù)據(jù)過(guò)大和HDFS多副本導(dǎo)致帶寬開(kāi)銷(xiāo)大等.

上述這些問(wèn)題覆蓋了實(shí)際應(yīng)用中大部分的性能調(diào)優(yōu)的場(chǎng)景.為了減少用戶的使用門(mén)檻，可以利用Hadoop系統(tǒng)為每個(gè)作業(yè)記錄歷史文件，分析其中的任務(wù)數(shù)和各種系統(tǒng)計(jì)數(shù)器，判斷可能的參數(shù)優(yōu)化點(diǎn)，再提醒用戶去關(guān)注相關(guān)問(wèn)題.這種自動(dòng)化的流程也有效地降低了集群的運(yùn)營(yíng)成本.例如在實(shí)踐中曾遇到某一作業(yè)，雖然能夠正常運(yùn)行，但整體運(yùn)行比同規(guī)模作業(yè)時(shí)間長(zhǎng)很多.通過(guò)自動(dòng)化分析，發(fā)現(xiàn)問(wèn)題在于其Map階段Java GC時(shí)間占比很大(用戶的Map算法頻繁利用內(nèi)存進(jìn)行數(shù)據(jù)緩存)，因此本平臺(tái)調(diào)大了Map階段的內(nèi)存需求量，從而使單Map任務(wù)時(shí)間減少為原來(lái)的15，作業(yè)整體時(shí)間也大幅縮短.表5是優(yōu)化前后的CPU耗時(shí)對(duì)比.

Fig. 4 Architecture of Minos deployment system圖4 Minos部署系統(tǒng)架構(gòu)圖

CategoryCPUTime∕msGCTime∕msGCTimeoverCPUTime∕%BeforeOptimization74686047201563．20AfterOptimization12956210270．79

6 集群管理

隨著接入業(yè)務(wù)數(shù)量的增加和集群規(guī)模的增長(zhǎng)，集群的布署、升級(jí)、監(jiān)控以及管理成為了一個(gè)挑戰(zhàn)，亟需一套能夠方便布署、升級(jí)集群，同時(shí)能夠直觀查看集群運(yùn)行狀態(tài)的系統(tǒng).希望能夠通過(guò)這樣的系統(tǒng)，一方面可以降低集群維護(hù)成本，減輕維護(hù)集群的壓力；另一方面可以實(shí)時(shí)查看集群的運(yùn)行狀態(tài)，讓團(tuán)隊(duì)成員和用戶了解集群的健康狀況，同時(shí)也可以及時(shí)把集群的故障反饋給團(tuán)隊(duì)成員，能夠讓團(tuán)隊(duì)成員在第一時(shí)間發(fā)現(xiàn)問(wèn)題、解決問(wèn)題，把對(duì)業(yè)務(wù)的影響降到最小.

業(yè)內(nèi)已有的解決方案，包括Hadoop原生的布署腳本、Cloudera Manager[32]和Apache Ambari[33]等盡管有各自的優(yōu)點(diǎn)與缺點(diǎn)，但都與本文要研究的目標(biāo)系統(tǒng)有一些距離.因此本文提出了一套自主設(shè)計(jì)和實(shí)現(xiàn)的Hadoop布署和監(jiān)控系統(tǒng)Minos，目前該系統(tǒng)已經(jīng)開(kāi)源[34].圖4是Minos部署系統(tǒng)的架構(gòu)圖，整體系統(tǒng)主要由4個(gè)組件組成.

1) 客戶端(client).直接提供給用戶使用的命令行工具.用戶可以用來(lái)部署和管理多種系統(tǒng)的集群服務(wù)與進(jìn)程，包括安裝、啟停、清除等.

2) 監(jiān)控面板(owl).展示集群服務(wù)和進(jìn)程狀態(tài)的網(wǎng)站.它通過(guò)JMX[35]接口從它管理的各個(gè)進(jìn)程收集內(nèi)部數(shù)據(jù)和狀態(tài)，并根據(jù)集群的配置，按照服務(wù)、作業(yè)、任務(wù)(ServiceJobTask)3個(gè)級(jí)別匯總和展示.

3) 監(jiān)視進(jìn)程(supervisor).部署在集群的所有機(jī)器上，負(fù)責(zé)管理和監(jiān)控服務(wù)的所有進(jìn)程.Supervisor原本是一個(gè)開(kāi)源項(xiàng)目[36]，提供了一套讓用戶在類(lèi)UNIX操作系統(tǒng)上遠(yuǎn)程監(jiān)控和控制進(jìn)程的方法.本文根據(jù)Minos的需要進(jìn)行了擴(kuò)展和改進(jìn)，主要增加了一套R(shí)PC接口供Minos Client調(diào)用.

4) 包管理服務(wù)器(tank).集群運(yùn)行所使用的軟件包集中管理和存放的服務(wù)器.Minos以包名和版本號(hào)來(lái)唯一表示一個(gè)軟件包.

使用Minos系統(tǒng)部署和管理一個(gè)集群服務(wù)的典型流程如下：

1) 安裝Minos系統(tǒng)(所有集群服務(wù)僅需要做一次)，安裝集群服務(wù)所需要的軟件包到Tank;

2) 編寫(xiě)集群配置文件，通過(guò)Minos Client初始化集群;

3) 查看集群運(yùn)行狀態(tài)，根據(jù)需求啟停、更新、清除集群服務(wù).

Minos系統(tǒng)已經(jīng)成為內(nèi)部部署和管理大數(shù)據(jù)平臺(tái)各個(gè)組件服務(wù)的標(biāo)準(zhǔn)工具，目前支持了在使用的主流開(kāi)源系統(tǒng)，包括Hadoop(HDFSYARN)，ZooKeeper，HBase，Impala，Storm等.它大大降低了管理和維護(hù)這些大規(guī)模分布式系統(tǒng)的成本，提升了業(yè)務(wù)團(tuán)隊(duì)的生產(chǎn)效率.根據(jù)實(shí)際使用的經(jīng)驗(yàn)，Minos系統(tǒng)主要具有6個(gè)特點(diǎn):

1) 提供了直觀的Web界面來(lái)查看集群的運(yùn)行狀態(tài)， 提供了命令行工具來(lái)管理集群，方便快速定位錯(cuò)誤.

2) 放寬了布署服務(wù)必須是系統(tǒng)級(jí)服務(wù)的約束，支持同機(jī)運(yùn)行多個(gè)實(shí)例.這個(gè)特性主要的應(yīng)用場(chǎng)景是在大內(nèi)存的機(jī)器上通過(guò)布署多個(gè)RegionServer來(lái)提高機(jī)器內(nèi)存的使用率，同時(shí)能避免單個(gè)RegionServer的堆太大而導(dǎo)致的GC時(shí)間過(guò)長(zhǎng)引起的一系列問(wèn)題.

3) 靈活的包管理功能，對(duì)開(kāi)發(fā)團(tuán)隊(duì)更加友好.這個(gè)特性主要的好處有：①對(duì)于同一個(gè)系統(tǒng)特定的版本，團(tuán)隊(duì)內(nèi)部只要有一位成員構(gòu)建，其他成員便可以方便地復(fù)用編譯好的軟件包；②對(duì)于同一個(gè)系統(tǒng)不同版本的軟件包都有明確的標(biāo)識(shí)，互相不影響；③所有軟件包都集中管理，有直觀的Web界面進(jìn)行操作.

4) 在集群中抽象出了ServiceJobTask的概念，能夠通過(guò)配置文件直觀、簡(jiǎn)潔地描述集群.

5) 對(duì)集群的管理既支持集群級(jí)別的管理，也支持JobTask級(jí)別的管理.這個(gè)特性可以靈活地支持操作整個(gè)集群，或者是集群中的某些JobTask.

6) 監(jiān)控指標(biāo)的收集與展示采用了OpenTSDB[37], 具有強(qiáng)大的線型擴(kuò)展性.由于Hadoop系統(tǒng)的監(jiān)控指標(biāo)較多，需要存儲(chǔ)的時(shí)間較長(zhǎng)，在前期采用MySQL來(lái)存儲(chǔ)這些指標(biāo)時(shí)，隨著集群規(guī)模的增長(zhǎng)，很快MySQL就成為了瓶頸.后來(lái)經(jīng)過(guò)調(diào)研，本平臺(tái)把MySQL換成了OpenTSDB，由于OpenTSDB底層的存儲(chǔ)是基于HBase的，HBase本身具有強(qiáng)大的線型擴(kuò)展性，因此Minos中指標(biāo)存儲(chǔ)的問(wèn)題便得到了很好的解決.

很多業(yè)務(wù)已經(jīng)接入或正在接入本平臺(tái)的存儲(chǔ)與計(jì)算集群.目前，整體數(shù)據(jù)存儲(chǔ)量已達(dá)到PB級(jí)規(guī)模，每天運(yùn)行計(jì)算作業(yè)2 000多個(gè)，吞吐量在50TB左右.圖5展示了2013年8月至11月的每日作業(yè)數(shù)情況.

Fig. 5 Daily running jobs of MapReduce圖5 MapReduce每日作業(yè)數(shù)

7 未來(lái)工作

7.1 計(jì)算系統(tǒng)

Hadoop YARN平臺(tái)在支持現(xiàn)有MapReduce計(jì)算的同時(shí)，也為未來(lái)更多的擴(kuò)展成為可能.目前很多開(kāi)源項(xiàng)目支持在YARN平臺(tái)上運(yùn)行或部署，包括Storm[20]，Spark[21]，Tez[38]，Impala[22].這些項(xiàng)目擴(kuò)展了分布式計(jì)算模型，對(duì)特定領(lǐng)域有更好的支持.本文也嘗試將這些項(xiàng)目應(yīng)用到計(jì)算集群上，在復(fù)用集群的同時(shí)為用戶提供更多的選擇.此外，YARN也有發(fā)展成為通用部署平臺(tái)的潛力，目前已經(jīng)有將HBase部署在YARN上的開(kāi)源項(xiàng)目，我們也會(huì)在這一領(lǐng)域繼續(xù)探索和嘗試.

7.2 存儲(chǔ)系統(tǒng)

HDFS目前已經(jīng)基本能夠滿足大部分業(yè)務(wù)的需求，但是隨著業(yè)務(wù)規(guī)模的增長(zhǎng)，也凸顯出一些新的需求.此外HDFS本身的易用性方面也有很大的提高空間，未來(lái)的5個(gè)主要發(fā)展方向如下：

1) 名字服務(wù).支持通過(guò)名字訪問(wèn)HDFS集群.

2) HDFS Raid.希望在減少備份數(shù)的同時(shí)不損失數(shù)據(jù)的可靠性，從而達(dá)到節(jié)約成本的目的.

3) HDFS QoS.希望能夠?qū)τ脩籼峁┑姆?wù)有基本的網(wǎng)絡(luò)延遲和吞吐量的保證，同時(shí)保障數(shù)據(jù)的可靠.

4) 冷熱數(shù)據(jù)分離.希望對(duì)冷熱數(shù)據(jù)使用不用的策略和備份數(shù)，進(jìn)一步降低存儲(chǔ)成本.

5) 跨數(shù)據(jù)中心同步.

7.3 集群管理

本文的數(shù)據(jù)存儲(chǔ)與計(jì)算平臺(tái)主要基于開(kāi)源系統(tǒng).在受益于開(kāi)源系統(tǒng)提供便利的同時(shí)，也希望能做一些事情來(lái)回饋開(kāi)源社區(qū)，這是把Minos開(kāi)源出去的主要目的.另外也希望能夠借助社區(qū)的力量，一起來(lái)完善Minos.當(dāng)前已經(jīng)規(guī)劃要做或者正在做的一些特性主要有：

1) 同機(jī)多實(shí)例布署的支持；

2) 異構(gòu)機(jī)型的支持；

3) 易用性的提升，包括相關(guān)文檔完善、安裝過(guò)程自動(dòng)化等.

7.4 公有云

目前為止，數(shù)據(jù)的收集、存儲(chǔ)、處理、計(jì)算平臺(tái)都是面向公司內(nèi)部用戶的，屬于私有云的概念.小米公司有提供開(kāi)放平臺(tái)的計(jì)劃，把自己擁有的平臺(tái)與數(shù)據(jù)開(kāi)放出去，便于各種應(yīng)用的開(kāi)發(fā)；同時(shí)也會(huì)開(kāi)放數(shù)據(jù)處理的能力，讓更多的用戶收益.在這個(gè)場(chǎng)景下會(huì)有3個(gè)新的挑戰(zhàn)：

1) 多租戶.多個(gè)用戶之間是不可見(jiàn)和不相互影響的，需要良好的數(shù)據(jù)和資源隔離來(lái)達(dá)到這點(diǎn)；同時(shí)在多用戶情況下也要達(dá)到和用戶約定的服務(wù)等級(jí)協(xié)議(service-level agreement, SLA).

2) 安全.因?yàn)橛脩舻臄?shù)據(jù)和計(jì)算任務(wù)會(huì)托管在小米公司提供的環(huán)境里，安全是用戶最為關(guān)心的問(wèn)題之一.

3) 彈性.用戶的需求是動(dòng)態(tài)變化的，平臺(tái)需要根據(jù)用戶的實(shí)際需求來(lái)分配資源，以降低用戶的使用成本.

8 總 結(jié)

隨著互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展和普及，人類(lèi)所創(chuàng)造的數(shù)據(jù)量和產(chǎn)生的速度都在迅速膨脹，比如用戶訪問(wèn)日志、用戶生成內(nèi)容(user generated content, UGC)等，客觀上推動(dòng)了大數(shù)據(jù)問(wèn)題的研究.大數(shù)據(jù)的一個(gè)特點(diǎn)是價(jià)值密度較低，但在數(shù)量龐大的數(shù)據(jù)背后，隱藏著深刻的規(guī)律和洞見(jiàn).對(duì)這些規(guī)律的挖掘和發(fā)現(xiàn)，一方面可以為企業(yè)帶來(lái)巨大的商業(yè)價(jià)值，獲得超越其他競(jìng)爭(zhēng)對(duì)手的優(yōu)勢(shì)；另一方面也能豐富用戶服務(wù)，提供更穩(wěn)定、更優(yōu)異的使用體驗(yàn).因此，如何從這些龐大、分散的數(shù)據(jù)中去粗存精，沙里淘金，是大數(shù)據(jù)要解決的問(wèn)題和面臨的挑戰(zhàn).

本文從小米公司的行業(yè)應(yīng)用和實(shí)踐出發(fā)，在深入研究現(xiàn)有平臺(tái)的基礎(chǔ)上，提出了一種基于開(kāi)源生態(tài)系統(tǒng)的大數(shù)據(jù)收集與處理平臺(tái)的設(shè)計(jì)方案.同時(shí)針對(duì)現(xiàn)有開(kāi)源軟件在功能、一致性、可用性和效率等關(guān)鍵問(wèn)題上的缺陷，提出了相應(yīng)的優(yōu)化和改進(jìn)方案，并在業(yè)務(wù)系統(tǒng)中得以實(shí)施和驗(yàn)證.

當(dāng)然，本文提出的大數(shù)據(jù)平臺(tái)還有需要改進(jìn)和完善的地方，比如計(jì)算模型較為單一、存儲(chǔ)尚未支持冷熱數(shù)據(jù)分離、尚未提供跨數(shù)據(jù)中心的同步功能等.下一步研究工作將集中在全面的計(jì)算模型、低成本存儲(chǔ)、跨數(shù)據(jù)中心同步、多租戶等問(wèn)題上.

[1]Zikopoulos P, Eaton C. Understanding Big Data: Analytics for Enterprise Class Hadoop and Streaming Data[M]. New York: McGraw-Hill, 2011

[2]Slee M, Agarwal A, Kwiatkowski M. Thrift: Scalable cross-language services implementation[ROL]. Palo Alto: Facebook, 2007 [2015-06-08]. https:thrift.apache.orgstaticfilesthrift-20070401.pdf

[3]Shao Z. Real-time analytics at Facebook[C]Proc of the 5th Extremely Large Databases Conf. Menlo Park: SLAC National Accelerator Laboratory, 2011: 21-33

[4]Shao Z. Real-time analytics at Facebook: Data freeway and puma[COL]Proc of 2011 Hadoop in China. [2015-04-18]. http:hic2011.hadooper.cndctattachY2xiOmNsYjpwZGY6MTQxMzY=

[5]Facebook. Scribe[CPOL]. [2015-06-08]. https:github.comfacebookscribe

[6]Apache. Hadoop[CPOL]. [2015-06-08]. http:hadoop.apache.org

[7]Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters[J]. Communications of the ACM, 2008, 51(1): 107-113

[8]Apache. Hive[CPOL]. [2015-06-08]. http:hive.apache.org

[9]Apache. HBase[CPOL]. [2015-06-08]. http:hbase.apache.org

[10]Cheng Miao, Chen Huaping. Weblog mining based on Hadoop[J]. Computer Engineering, 2011, 37(11): 37-39 (in Chinese)(程苗, 陳華平. 基于Hadoop的Web日志挖掘[J]. 計(jì)算機(jī)工程, 2011, 37(11): 37-39)

[11]Song Ying, Shen Qiwei, Wang Jing. Design and implementation of Web log pre-processing based on Hadoop[J]. Telecom Engineering Technics and Standardization, 2011, 24(11): 84-89 (in Chinese)(宋瑩, 沈奇威, 王晶. 基于Hadoop的Web日志預(yù)處理的設(shè)計(jì)與實(shí)現(xiàn)[J]. 電信工程技術(shù)與標(biāo)準(zhǔn)化, 2011, 24(11): 84-89)

[12]Liu Yongzeng, Zhang Xiaojing, Li Xianyi. Design of Web log analysis system based on HadoopHive[J]. Journal of Guangxi University: Natural Science Edition, 2011, 36(Suppl1): 314-317 (in Chinese)(劉永增, 張曉景, 李先毅. 基于HadoopHive的Web日志分析系統(tǒng)的設(shè)計(jì)[J]. 廣西大學(xué)學(xué)報(bào): 自然科學(xué)版, 2011, 36(增刊1): 314-317)

[13]Zhu Zhu. Research and application of massive data processing model based on Hadoop[D]. Beijing: Beijing University of Posts and Telecommunications, 2008 (in Chinese)(朱珠. 基于Hadoop的海量數(shù)據(jù)處理模型研究和應(yīng)用[D]. 北京: 北京郵電大學(xué), 2008)

[14]Li Jun. Exploration on the cloud computing model based on Hadoop[J]. Information Security and Technology, 2011 (6): 30-32 (in Chinese)(李珺. 基于Hadoop云計(jì)算模型探究[J]. 信息安全與技術(shù), 2011 (6): 30-32)

[15]Wan Zhizhen. Design and implementation of parallel computing platform based on MapReduce model[D]. Hangzhou: Zhejiang University, 2008 (in Chinese)(萬(wàn)至臻. 基于MapReduce模型的并行計(jì)算平臺(tái)的設(shè)計(jì)與實(shí)現(xiàn)[D]. 杭州: 浙江大學(xué), 2008)

[16]Cui Jie, Li Taoshen, Lan Hongxing. Design and development of the mass data storage platform based on Hadoop[J]. Journal of Computer Research and Development, 2012, 49(Suppl1): 12-18 (in Chinese)(崔杰, 李陶深, 蘭紅星. 基于Hadoop的海量數(shù)據(jù)存儲(chǔ)平臺(tái)設(shè)計(jì)與開(kāi)發(fā)[J]. 計(jì)算機(jī)研究與發(fā)展, 2012, 49(增刊1): 12-18)

[17]Dong He, Xu Lingyu. SaaS-Flow system structure based on cloud platform[J]. Journal of Shanghai University: Natural Science Edition , 2013, 19(1): 14-20 (in Chinese)(董賀, 徐凌宇. 基于云平臺(tái)的軟件服務(wù)流體系結(jié)構(gòu)[J]. 上海大學(xué)學(xué)報(bào)：自然科學(xué)版, 2013, 19(1): 14-20)

[18]Ji Jun. Design and implementation of a data mining platform architecture based on cloud computing[D]. Qingdao: Qingdao University, 2009 (in Chinese)(紀(jì)俊. 一種基于云計(jì)算的數(shù)據(jù)挖掘平臺(tái)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)[D]. 青島: 青島大學(xué), 2009)

[19]Hunt P, Konar M, Junqueira F P, et al. ZooKeeper: Wait-free coordination for Internet-scale systems[C]Proc of the 2010 USENIX Annual Technical Conf. Berkeley: USENIX Association, 2010: 11-18

[20]Apache. Storm[CPOL]. [2015-06-08]. http:storm.apache.org

[21]Apache. Spark[CPOL]. [2015-06-08]. http:spark.incubator.apache.org

[22]Cloudera. Impala[CPOL]. [2015-06-08]. http:impala.io

[23]Google. Protocol Buffer[CPOL]. [2015-06-08]. https:code.google.compprotobuf

[24]Apache. Kafka[CPOL]. [2015-06-08]. https:kafka.apache.org

[25]Apache. Flume[CPOL]. [2015-06-08]. http:flume.apache.org

[26]Apache. Chukwa[CPOL]. [2015-06-08]. http:chukwa.apache.org

[27]Google. Snappy[CPOL]. [2015-06-08]. http:google.github.iosnappy

[28]Ghemawat S, Gobioff H, Leung S T. The Google file system[C]Proc of the 19th ACM Symp on Operating Systems Principles. New York: ACM, 2003: 29-43

[29]Apache. HDFS-4660[CPOL]. [2015-06-08]. https:issues.apache.orgjirabrowseHDFS-4660

[30]Pike R, Dorward S, Griesemer R, et al. Interpreting the data: Parallel analysis with Sawzall[J]. Scientific Programming, 2005, 13(4): 277-298

[31]Melnik S, Gubarev A, Long J J, et al. Dremel: Interactive analysis of Web-scale datasets[J]. Proceedings of the VLDB Endowment, 2010, 3(12): 330-339

[32]Cloudera. Cloudera Manager[CPOL]. [2015-06-08]. https:www.cloudera.comproductscloudera-manager.html

[33]Apache. Ambari[CPOL]. [2015-06-08]. http:ambari.apache.org

[34]Xiaomi. Minos[CPOL]. [2015-06-08]. https:github.comXiaoMiminos

[35]Oracle. JMX:[CPOL]. [2015-06-08]. http:www.oracle.comtechnetworkarticlesjavajavamanagement-140525.html

[36]Agendaless Consulting and Contributors. Supervisor[CPOL]. [2015-06-08]. http:supervisord.org

[37]StumbleUpon. OpenTSDB[CPOL]. [2015-06-08]. http:

[38]Apache. Tez[CPOL]. [2015-06-08]. http:tez.incubator.apache.org

Lei Jun, born in 1969. PhD candidate. Founder, board chairman and CEO of Xiaomi Inc. His main research interests include software engineering, distributed system, storage system, big data and high performance computing.

Ye Hangjun, born in 1976. PhD. Software engineer of Xiaomi Inc. His main research interests include distributed system, storage system and cloud computing (yehangjun@xiaomi.com).

Wu Zesheng, born in 1986. Bachelor. Former software engineer of Xiaomi Inc and co-founder of Hangzhou Bongmi Technology Co, Ltd. His main research interests include distributed system and cloud computing (wuzesheng@bongmi.com).

Zhang Peng, born in 1984. Master. Software engineer of Xiaomi Inc. His main research interests include distributed computing system and resource management system (peng.zhang@xiaomi.com).

Xie Long, born in 1984. Master. Software engineer of Xiaomi Inc. His main research interests include high availability and high performance in distributed system (xielong.me@gmail.com).

He Yanxiang, born in 1952. PhD, professor and PhD supervisor. Member of China Computer Federation. His main research interests include trusted software, distributed parallel processing and high performance computing.

Big-Data Platform Based on Open Source Ecosystem

Lei Jun1,2, Ye Hangjun2, Wu Zesheng2, Zhang Peng2, Xie Long2, and He Yanxiang1,3

1(ComputerSchool,WuhanUniversity,Wuhan430072)2(XiaomiInc,Beijing100085)3(StateKeyLaboratoryofSoftwareEngineering(WuhanUniversity),Wuhan430072)

As large-scale data collecting and processing are being widely studied in recent years, several released big data processing platforms are increasingly playing important roles in the operations of many Internet businesses. Open source ecosystems, the engine of big data innovation, have been evolving so rapidly that a number of them are successfully adopted as the components of mainstream data processing platforms. In reality, however, the open source software is still far from perfect while dealing with real large-scale data. On the basis of the industrial practice at Xiaomi Inc, this paper proposes an improved platform for collecting and processing large-scale data in face of varied business requirements. We focus on the problems in terms of the functionality, consistency and availability of the software when they are executed for data collecting, storing and processing procedures. In addition, we propose a series of optimizations aiming at load balance, failover, data compression and multi-dimensional scheduling to significantly improve the efficiency of the current system. All these designs and optimizations described in this paper have been practically implemented and deployed to support various Internet services provided by Xiaomi Inc.

Hadoop; open source ecosystem; big data; data center; network virtualization

2015-06-12；

2016-08-08

國(guó)家自然科學(xué)基金項(xiàng)目(91118003，61373039，61170022) This work was supported by the National Natural Science Foundation of China (91118003, 61373039, 61170022).

TP391