基于開源生態(tài)系統的大數據平臺研究

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

1(武漢大學計算機學院 武漢 430072)2(小米科技有限責任公司 北京 100085)3 (軟件工程國家重點實驗室(武漢大學) 武漢 430072)(leijun@xiaomi.com)

基于開源生態(tài)系統的大數據平臺研究

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

1(武漢大學計算機學院 武漢 430072)2(小米科技有限責任公司 北京 100085)3(軟件工程國家重點實驗室(武漢大學) 武漢 430072)(leijun@xiaomi.com)

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

Hadoop；開源生態(tài)系統；大數據;數據中心；網絡虛擬化

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

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

1) 數據存量和增量大.PB級別的數據總量和TB級別的數據日增量，對數據存儲和傳輸的成本與效率提出很高的要求.

2) 業(yè)務線多、數據來源和格式多樣化.上百個業(yè)務項目和數據來源，多種異構的數據格式，要求大數據平臺有足夠的靈活性和可擴展性.

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

4) 業(yè)務部署和大數據平臺部署的情況比較復雜.多機房部署、異構的機房環(huán)境、要求集群和平臺的部署、監(jiān)控和報警等要足夠高效.

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

1 相關工作

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

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

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

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

2 總體架構

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

Fig. 1 Overall architecture of big-data platform圖1 大數據平臺整體架構圖

3 數據收集系統

對于大部分應用場景來說，業(yè)務數據的來源和格式經常會有很多種，比如Apache或Nginx等Web Server的訪問日志、業(yè)務自定義的CSV格式文件以及用Protocol Buffer[23]或者Thrift消息編碼過后的消息.一個足夠通用和靈活的數據收集平臺，需要同時滿足不同業(yè)務的多樣化需求.

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

1) 高可用.數據不會因為單節(jié)點或者少數節(jié)點的故障丟失.

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

3) 使用簡單.各業(yè)務接入系統的學習成本較低.

4) 易配置和維護.較低的運維成本.

5) 低外部依賴.較低的運維成本.

6) 架構和實現簡單.多數開源系統需要一些改進來適配業(yè)務的要求.

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

Fig. 2 Architecture of data collection system圖2 數據收集系統架構圖

3.1 數據傳輸的優(yōu)化與改進

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

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

Scribe是通過Thrift的RPC接口對外提供服務，Thrift本身不提供傳輸數據壓縮的功能.Thrift本身也是一個分層設計的結構，加上Scribe又是搭建在Thrift之上的應用，所以有多個地方可以選擇來實現壓縮，比如Thrift Protocol層、Thrift Transport層或者在Scribe本身.由于其他Thrift Server也可能有數據傳輸壓縮的需求，本文提出了一種通用的解決方案，在Thrift Transport層來實現Compressed的傳輸協議，使得各類Thrift Server都能與之兼容.

Thrift本身提供了良好的擴展性.Thrift Server缺省使用了內置的TFramedTransport傳輸協議，這是一個直接基于系統底層傳輸協議(在Thrift Server里就是TCP協議)之上的簡單的非壓縮傳輸協議.同時Thrift Server在構造的時候允許傳入一個TTransportFactory的傳輸層工廠類，通過傳輸層的串聯模式，可以在內置傳輸協議的基礎上實現更復雜的協議.

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

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

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

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

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

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

Table 1 Compression Ratio of Data Transportation

在真實業(yè)務場景下，壓縮傳輸只使用了原來30%左右的網絡帶寬，并且CPU沒有成為新的瓶頸，因此也不需要部署新的Scribe Server來分擔負載.該項改進明顯降低了日志數據在網絡傳輸上的成本.

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

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

在本文提出的數據收集系統中，需要有一套中心服務器負責接受所有業(yè)務的數據，再把數據寫入到統一的HDFS集群中.為了避免該服務器成為系統的故障點，需要用一主一備2個服務器來提高可用性，用Buffer Store配置成主服務器不可用時寫入備服務器.這在應對服務器的偶然宕機或者運維操作時將起關鍵作用，顯著提升可用性.

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

1) 跟蹤所有服務器的狀態(tài)，未能成功應答的服務器會被標志成“不可用”.

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

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

下面通過模擬實驗來比較改進前后日志收集系統的總體可用性.假設單個Scribe服務器的可用性為p，總共有n臺Scribe服務器，將n臺Scribe服務器配成n個bucket.假設各個服務器的可用性是獨立的，可以推導出總體可用性為

(1)

在改進之后，同樣假設各個服務器的可用性是獨立的，但至少要有m個服務器可用總體系統才可用(考慮到服務器的處理能力)，可以推導出總體可用性為

(2)

表2比較了改進前后日志收集系統的總體可用性.假設單個Scribe服務器的可用性p=0.99，同時至少有一半的服務器可用總體系統才可用(m=n2).這個改進徹底解決了Scribe在負載均衡和故障處理上的缺陷.在業(yè)務中的實踐也表明進行上述改進后，可用性和系統的可擴展性有明顯提高，沒有再出現因為超載或者單機故障造成的系統不可用.

Table 2 Comparison of Log Collection System OverallAvailability BeforeAfter Improvement

表2 改進前后日志收集系統總體可用性的比較

(p=0.99,m=n2)

Table 2 Comparison of Log Collection System OverallAvailability BeforeAfter Improvement

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

4 數據存儲系統

數據規(guī)模較大的存儲會超出單機的存儲能力，需要一個分布式的存儲系統.傳統的技術包括存儲區(qū)域網絡(storage area network, SAN)、網絡附加存儲(network attached storage, NAS)、網絡文件系統(network file system, NFS)等.這些存儲技術都需要高端或專用存儲設備，成本通常較高.

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

此后出現了大量的開源實現.其中HDFS是使用比較廣泛、也比較成熟的一種開源實現.本文提出的大數據平臺也是以HDFS為核心的存儲系統.

作為一個分布式存儲系統，最重要的衡量指標是一致性(可靠性)、可用性和性能.尤其是一致性和可用性，往往是選擇一個分布式存儲系統時的關鍵因素.在部署和使用開源的HDFS版本時，我們發(fā)現HDFS在一致性和可用性上的一些嚴重缺陷.本文提出了相應的改進和優(yōu)化方案并在業(yè)務系統中部署了改進后的版本.

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

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

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

在實施過程中發(fā)現在這種升級方式下，HDFS上的文件很小概率下有損壞的情況.對于一個存儲系統而言，文件損壞是很嚴重的缺陷，所以也是本文必須要解決的問題.由于該現象是偶發(fā)的，深入分析后確認是在HDFS寫數據的流水線中間節(jié)點宕機后恢復的過程中，由于HDFS本身邏輯的缺陷，導致Checksum文件多出一個Checksum，從而導致HDFS校驗Checksum失敗，進而認為數據被損壞.這已經相當于出現了丟失數據的現象，之前已經成功寫入的數據無法再正確讀出，從而破壞了一致性的約定.

在Hadoop2.0版本時我們已向社區(qū)匯報了該問題，并提交了補丁代碼[29].該問題被社區(qū)確認為嚴重的數據損壞問題，并在Hadoop2.7版本中得到了解決.對此缺陷進行了修正之后，再未出現集群逐臺滾動升級時的文件損壞.

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

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

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

下面通過模擬實驗計算在改進之前出現異常(移除節(jié)點時無法正常結束或者丟失數據)的概率.假設集群有n個存儲節(jié)點，同時移除m個存儲節(jié)點，當時有k個文件同時被寫入數據.根據前面的分析，只要任何一個正在被寫入的文件的3個副本都在這m個存儲節(jié)點，就會出現異常.假設副本在數據節(jié)點上的分配是均勻分布且獨立的，可以推導出出現異常的概率為

(3)

Table 3 Probability of Abnormity for RepresentativeConfigurations

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

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

當前HDFS的實現中，在客戶端有一個數據節(jié)點(DataNode)的黑名單，在用戶使用客戶端操作HDFS的過程中，如果發(fā)現某個數據節(jié)點出現故障，都會被加入到這個黑名單，后續(xù)該客戶端就不再從該數據節(jié)點讀寫數據.這樣是一種優(yōu)化，目的是避免從故障或者繁忙的節(jié)點讀寫數據.

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

下面通過模擬實驗來計算在改進之前HDFS集群出現不可用的概率.假設集群有n個存儲節(jié)點，每個存儲節(jié)點在這個時間周期內(這里是1 d)出現不可用(主要是讀寫超時)的概率為p，這個時間周期內有k個文件被寫入數據且未出現文件切換.假設副本在數據節(jié)點上的分配是均勻分布且獨立的，存儲節(jié)點出現不可用是獨立事件，可以推導出HDFS集群出現不可用的概率為

(4)

表4給出了6種典型配置下出現不可用(某個文件無法寫入)的概率.

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

Table 4 Probability of Unavailability for RepresentativeConfigurations

對此本文做了優(yōu)化和改進，對于進入黑名單的數據節(jié)點，當它進入黑名單超過一定的時間，給與它一定的機會讓其復活.從上線后的效果來看，對可用性有很明顯的提高，再未出現由于數據節(jié)點負載高造成的偶爾超時，導致某個文件不可寫入的情況.

5 計算系統

和分布式的數據存儲系統相類似，對規(guī)模較大的數據進行處理和計算，往往也會超出單機的處理能力，需要一個并行計算的系統和框架，傳統的技術包括MPI和分布式數據庫等.

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

在開源生態(tài)系統里，Hadoop的MapReduce(也是Hadoop項目的一個核心子項目)和Hive是對應的2個實現，也是目前使用廣泛、成熟度較高的實現.本文提出的大數據平臺，也是以開源的MapReduce和Hive為核心的計算系統.

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

5.1 計算資源的配額管理

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

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

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

5.2 多維度資源調度

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

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

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

5.3 容量調度器的負載均衡

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

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

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

1) 開發(fā)程序時，利用MR Unit測試框架為Mapper和Reducer等編寫單元測試.通過單元測試覆蓋主要場景，保證程序的基本正確性.

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

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

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

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

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

1) Map階段.內存配置不合理導致內存數據頻繁落地磁盤，磁盤IO開銷大.

2) Shuffle階段.Map輸出未壓縮導致Shuffle數據量過大，帶寬開銷大；Reduce端的Shuffle內存及并發(fā)參數的配置不合理導致磁盤IO開銷大或數據拉取慢.

3) Reduce階段.任務并發(fā)數不足導致單任務處理數據量過大；Reduce的輸出數據過大和HDFS多副本導致帶寬開銷大等.

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

Fig. 4 Architecture of Minos deployment system圖4 Minos部署系統架構圖

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

6 集群管理

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

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

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

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

3) 監(jiān)視進程(supervisor).部署在集群的所有機器上，負責管理和監(jiān)控服務的所有進程.Supervisor原本是一個開源項目[36]，提供了一套讓用戶在類UNIX操作系統上遠程監(jiān)控和控制進程的方法.本文根據Minos的需要進行了擴展和改進，主要增加了一套RPC接口供Minos Client調用.

4) 包管理服務器(tank).集群運行所使用的軟件包集中管理和存放的服務器.Minos以包名和版本號來唯一表示一個軟件包.

使用Minos系統部署和管理一個集群服務的典型流程如下：

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

2) 編寫集群配置文件，通過Minos Client初始化集群;

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

Minos系統已經成為內部部署和管理大數據平臺各個組件服務的標準工具，目前支持了在使用的主流開源系統，包括Hadoop(HDFSYARN)，ZooKeeper，HBase，Impala，Storm等.它大大降低了管理和維護這些大規(guī)模分布式系統的成本，提升了業(yè)務團隊的生產效率.根據實際使用的經驗，Minos系統主要具有6個特點:

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

2) 放寬了布署服務必須是系統級服務的約束，支持同機運行多個實例.這個特性主要的應用場景是在大內存的機器上通過布署多個RegionServer來提高機器內存的使用率，同時能避免單個RegionServer的堆太大而導致的GC時間過長引起的一系列問題.

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

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

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

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

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

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

7 未來工作

7.1 計算系統

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

7.2 存儲系統

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

1) 名字服務.支持通過名字訪問HDFS集群.

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

3) HDFS QoS.希望能夠對用戶提供的服務有基本的網絡延遲和吞吐量的保證，同時保障數據的可靠.

4) 冷熱數據分離.希望對冷熱數據使用不用的策略和備份數，進一步降低存儲成本.

5) 跨數據中心同步.

7.3 集群管理

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

1) 同機多實例布署的支持；

2) 異構機型的支持；

3) 易用性的提升，包括相關文檔完善、安裝過程自動化等.

7.4 公有云

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

1) 多租戶.多個用戶之間是不可見和不相互影響的，需要良好的數據和資源隔離來達到這點；同時在多用戶情況下也要達到和用戶約定的服務等級協議(service-level agreement, SLA).

2) 安全.因為用戶的數據和計算任務會托管在小米公司提供的環(huán)境里，安全是用戶最為關心的問題之一.

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

8 總 結

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

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

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

[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]. 計算機工程, 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日志預處理的設計與實現[J]. 電信工程技術與標準化, 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日志分析系統的設計[J]. 廣西大學學報: 自然科學版, 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的海量數據處理模型研究和應用[D]. 北京: 北京郵電大學, 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]. 信息安全與技術, 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)(萬至臻. 基于MapReduce模型的并行計算平臺的設計與實現[D]. 杭州: 浙江大學, 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的海量數據存儲平臺設計與開發(fā)[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)(董賀, 徐凌宇. 基于云平臺的軟件服務流體系結構[J]. 上海大學學報：自然科學版, 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)(紀俊. 一種基于云計算的數據挖掘平臺架構設計與實現[D]. 青島: 青島大學, 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

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

TP391