大數(shù)據(jù)關(guān)鍵技術(shù)

摘要：結(jié)合大數(shù)據(jù)系統(tǒng)的一般結(jié)構(gòu)，介紹和對比了當(dāng)前大數(shù)據(jù)領(lǐng)域在文件存儲、數(shù)據(jù)處理和數(shù)據(jù)庫領(lǐng)域的關(guān)鍵技術(shù)。通過各種技術(shù)的對比，得到了一些分析結(jié)果。分析結(jié)果表明大數(shù)據(jù)系統(tǒng)的解決方案必將落地于現(xiàn)有的云計(jì)算平臺；云計(jì)算平臺的分布式文件系統(tǒng)、分布式運(yùn)算模式和分布式數(shù)據(jù)庫管理技術(shù)是解決大數(shù)據(jù)問題的基礎(chǔ)；一些大的依靠數(shù)據(jù)盈利的大公司必然會是大數(shù)據(jù)應(yīng)用的主體。

關(guān)鍵詞：大數(shù)據(jù)；分布式文件系統(tǒng)；分布式數(shù)據(jù)庫；MapReduce技術(shù)

Abstract：In this paper， we discuss the general structure of a big-data system as well as key technologies in big-data storage， processing， and database. We compare these technologies in order find problems in the big-data system and propose solutions that will be used in the cloud computing platform. We propose distributed file system， computing model， and database management to solve problems associated with big data. Big companies that profit from big data will be the main users of big-data applications.

Key words： big data； distributed file system； distributed database； MapReduce

中圖分類號：TN915.03； TP393.03 文獻(xiàn)標(biāo)志碼：A 文章編號：1009-6868 （2013） 04-0017-005

21世紀(jì)，世界已經(jīng)進(jìn)入數(shù)據(jù)大爆炸的時(shí)代，大數(shù)據(jù)時(shí)代已經(jīng)來臨。從商業(yè)公司內(nèi)部的各種管理和運(yùn)營數(shù)據(jù)，到個(gè)人移動終端與消費(fèi)電子產(chǎn)品的社會化數(shù)據(jù)，再到互聯(lián)網(wǎng)產(chǎn)生的海量信息數(shù)據(jù)等，每天世界上產(chǎn)生的信息量正在飛速增長。2009年數(shù)據(jù)信息量達(dá)到8 000億GB，而到2011年達(dá)到1.8 ZB[1]。圖靈獎(jiǎng)獲得者Jim Gray提出的“新摩爾定律”：“每18個(gè)月全球新增信息量是計(jì)算機(jī)有史以來全部信息量的總和”，已經(jīng)得到驗(yàn)證。

大數(shù)據(jù)的“大”不僅僅體現(xiàn)在數(shù)據(jù)的海量性，還在于其數(shù)據(jù)類型的復(fù)雜性。隨著報(bào)表、賬單、影像、辦公文檔等在商業(yè)公司中得到普遍使用，互聯(lián)網(wǎng)上視頻、音樂、網(wǎng)絡(luò)游戲不斷發(fā)展，越來越多的非結(jié)構(gòu)化數(shù)據(jù)進(jìn)一步推動數(shù)字宇宙爆炸。數(shù)據(jù)海量而復(fù)雜，這是對大數(shù)據(jù)的詮釋。與傳統(tǒng)的數(shù)據(jù)相比，大數(shù)據(jù)具有規(guī)模性（Volume）、多樣性（Variety）、高速性（Velocity）和低價(jià)值密度（Value）的4V特點(diǎn)[2]。規(guī)模性和高速性是數(shù)據(jù)處理一直以來研究和探討的問題，多樣性和價(jià)值密度低是當(dāng)前數(shù)據(jù)處理發(fā)展中不斷顯現(xiàn)出來的問題，而且在可以預(yù)見的未來，隨著智慧城市、智慧地球等各種新設(shè)想的不斷成為現(xiàn)實(shí)，上面的4中問題將會變得更加凸顯，而且是不得不面對的問題。

數(shù)據(jù)的產(chǎn)生經(jīng)歷了被動、主動和自動3個(gè)階段[3]。大數(shù)據(jù)的迅猛發(fā)展是信息時(shí)代數(shù)字設(shè)備計(jì)算能力和部署數(shù)量指數(shù)增長的必然結(jié)果。解決大數(shù)據(jù)研究中的問題，必須要從大數(shù)據(jù)的產(chǎn)生背景進(jìn)行研究。大數(shù)據(jù)的產(chǎn)生源于規(guī)模效應(yīng)，這種規(guī)模效應(yīng)給數(shù)據(jù)的存儲、管理以及數(shù)據(jù)的分析帶來了極大的挑戰(zhàn)，數(shù)據(jù)管理方式上的變革正在醞釀和發(fā)生。大數(shù)據(jù)的規(guī)模效應(yīng)要求其存儲、運(yùn)算方案也應(yīng)當(dāng)從規(guī)模效應(yīng)上進(jìn)行考慮。傳統(tǒng)的單純依靠單設(shè)備處理能力縱向發(fā)展的技術(shù)早已經(jīng)不能滿足大數(shù)據(jù)存儲和處理需求。以Google等為代表的一些大的數(shù)據(jù)處理公司通過橫向的分布式文件存儲、分布式數(shù)據(jù)處理和分布式的數(shù)據(jù)分析技術(shù)很好的解決了由于數(shù)據(jù)爆炸所產(chǎn)生的各種問題。

1 大數(shù)據(jù)關(guān)鍵技術(shù)

1.1 大數(shù)據(jù)系統(tǒng)的架構(gòu)

大數(shù)據(jù)處理系統(tǒng)不管結(jié)構(gòu)如何復(fù)雜，采用的技術(shù)千差萬別，但是總體上總可以分為以下的幾個(gè)重要部分。大數(shù)據(jù)系統(tǒng)結(jié)構(gòu)如圖1所示。

從數(shù)據(jù)處理的一般流程可以看到，在大數(shù)據(jù)環(huán)境下需要的關(guān)鍵技術(shù)主要針對海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的運(yùn)算。傳統(tǒng)的關(guān)系數(shù)據(jù)庫經(jīng)過近40年的發(fā)展已經(jīng)成為了一門成熟同時(shí)仍在不斷演進(jìn)的數(shù)據(jù)管理和分析技術(shù)，結(jié)構(gòu)化查詢語言（SQL）作為存取關(guān)系數(shù)據(jù)庫的語言得到了標(biāo)準(zhǔn)化，其功能和表達(dá)能力也得到的不斷增強(qiáng)。但是，關(guān)系數(shù)據(jù)管理系統(tǒng)的擴(kuò)展性在互聯(lián)網(wǎng)環(huán)境下遇到了前所未有的障礙，不能勝任大數(shù)據(jù)分析的要求。關(guān)系數(shù)據(jù)管理模型追求的是高度的一致性和正確性?？v向擴(kuò)展系統(tǒng)，通過增加或者更換CPU、內(nèi)存、硬盤以擴(kuò)展單個(gè)節(jié)點(diǎn)的能力，終會遇到“瓶頸”。

大數(shù)據(jù)的研究主要來源于依靠數(shù)據(jù)獲取商業(yè)利益的大公司。Google公司作為全球最大的信息檢索公司，其走在了大數(shù)據(jù)研究的前沿。面對呈現(xiàn)爆炸式增加的因特網(wǎng)信息，僅僅依靠提高服務(wù)器性能已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足業(yè)務(wù)的需求。如果將各種大數(shù)據(jù)應(yīng)用比作“汽車”，支撐起這些“汽車”運(yùn)行的“高速公路”就是云計(jì)算。正是云計(jì)算技術(shù)在數(shù)據(jù)存儲、管理與分析等方面的支持，才使得大數(shù)據(jù)有用武之地。Google公司從橫向進(jìn)行擴(kuò)展，通過采用廉價(jià)的計(jì)算機(jī)節(jié)點(diǎn)集群，改寫軟件，使之能夠在集群上并行執(zhí)行，解決海量數(shù)據(jù)的存儲和檢索功能。2006年Google首先提出云計(jì)算的概念。支撐Google公司各種大數(shù)據(jù)應(yīng)用的關(guān)鍵正是其自行研發(fā)的一系列云計(jì)算技術(shù)和工具。Google公司大數(shù)據(jù)處理的三大關(guān)鍵技術(shù)為：Google文件系統(tǒng)GFS[4]、MapReduce[5]和Bigtable[6]。Google的技術(shù)方案為其他的公司提供了一個(gè)很好的參考方案，各大公司紛紛提出了自己的大數(shù)據(jù)處理平臺，采用的技術(shù)也都大同小異。下面將從支持大數(shù)據(jù)系統(tǒng)所需要的分布式文件系統(tǒng)、分布式數(shù)據(jù)處理技術(shù)、分布式數(shù)據(jù)庫系統(tǒng)和開源的大數(shù)據(jù)系統(tǒng)Hadoop等方面介紹大數(shù)據(jù)系統(tǒng)的關(guān)鍵技術(shù)。

1.2 分布式文件系統(tǒng)

文件系統(tǒng)是支持大數(shù)據(jù)應(yīng)用的基礎(chǔ)。Google是有史以來唯一需要處理如此海量數(shù)據(jù)的大公司。對于Google而言，現(xiàn)有的方案已經(jīng)難以滿足其如此大的數(shù)據(jù)量的存儲，為此Google提出了一種分布式的文件管理系統(tǒng)——GFS。

GFS與傳統(tǒng)的分布式文件系統(tǒng)有很多相同的目標(biāo)，比如，性能、可伸縮性、可靠性以及可用性。但是，GFS的成功之處在于其與傳統(tǒng)文件系統(tǒng)的不同。GFS的設(shè)計(jì)思路主要基于以下的假設(shè)：對于系統(tǒng)而言，組件失敗是一種常態(tài)而不是異常。GFS是構(gòu)建于大量廉價(jià)的服務(wù)器之上的可擴(kuò)展的分布式文件系統(tǒng)，采用主從結(jié)構(gòu)。通過數(shù)據(jù)分塊、追加更新等方式實(shí)現(xiàn)了海量數(shù)據(jù)的高效存儲，如圖2所示給出了GFS體系結(jié)構(gòu)。但是隨著業(yè)務(wù)量的進(jìn)一步變化，GFS逐漸無法適應(yīng)需求。Google對GFS進(jìn)行了設(shè)計(jì)，實(shí)現(xiàn)了Colosuss系統(tǒng)，該系統(tǒng)能夠很好地解決GFS單點(diǎn)故障和海量小文件存儲的問題。

除了Google的GFS，眾多的企業(yè)和學(xué)者也從不同的方面對滿足大數(shù)據(jù)存儲需求的文件系統(tǒng)進(jìn)行了詳細(xì)的研究。微軟開發(fā)的Cosmos[7]支撐其搜索、廣告業(yè)務(wù)。HDFS[8]、FastDFS[9]、OpenAFS[10]和CloudStore[11]都是類似GFS的開源實(shí)現(xiàn)。類GFS的分布式文件系統(tǒng)主要針對大文件而設(shè)計(jì)，但是在圖片存儲等應(yīng)用場景中，文件系統(tǒng)主要存儲海量小文件，F(xiàn)acebook為此推出了專門針對海量小文件的文件系統(tǒng)Haystack[12]，通過多個(gè)邏輯文件共享同一個(gè)物理文件，增加緩存層、部分元數(shù)據(jù)加載到內(nèi)存等方式有效地解決了海量小文件存儲的問題。Lustre是一種大規(guī)模、安全可靠的，具備高可靠性的集群文件系統(tǒng)，由SUN公司開發(fā)和維護(hù)。該項(xiàng)目主要的目的就是開發(fā)下一代的集群文件系統(tǒng)，可以支持超過10 000個(gè)節(jié)點(diǎn)，數(shù)以拍字節(jié)的數(shù)量存儲系統(tǒng)。

1.3 分布式數(shù)據(jù)處理系統(tǒng)

大數(shù)據(jù)的處理模式分為流處理和批處理兩種[13-14]。流處理是直接處理，批處理采用先存儲再處理。

流處理將數(shù)據(jù)視為流，源源不斷的數(shù)據(jù)形成數(shù)據(jù)流。當(dāng)新的數(shù)據(jù)到來即立即處理并返回所需的結(jié)果。大數(shù)據(jù)的實(shí)時(shí)處理是一個(gè)極具挑戰(zhàn)性的工作，數(shù)據(jù)具有大規(guī)模、持續(xù)到達(dá)的特點(diǎn)。因此，如果要求實(shí)時(shí)的處理大數(shù)據(jù)，必然要求采用分布式的方式，在這種情況下，除了應(yīng)該考慮分布式系統(tǒng)的一致性問題，還將涉及到分布式系統(tǒng)網(wǎng)絡(luò)時(shí)延的影響，這都增加了大數(shù)據(jù)流處理的復(fù)雜性。目前比較有代表性的開源流處理系統(tǒng)主要有：Twitter的Storm[15]、Yahoo的S4[16]以及Linkedin的Kafka[17]等。

Google公司2004年提出的MapReduce編程模型是最具代表性的批處理模型。MapReduce架構(gòu)的程序能夠在大量的普通配置的計(jì)算機(jī)上實(shí)現(xiàn)并行化處理。這個(gè)系統(tǒng)在運(yùn)行時(shí)只關(guān)心如何分割輸入數(shù)據(jù)，在大量計(jì)算機(jī)組成的集群上的調(diào)度，集群中計(jì)算機(jī)的錯(cuò)誤處理，管理集群中的計(jì)算機(jī)之間必要的通信。

對于有些計(jì)算，由于輸入數(shù)據(jù)量的巨大，想要在可接受的時(shí)間內(nèi)完成運(yùn)算，只有將這些計(jì)算分布在成百上千的主機(jī)上。這種計(jì)算模式對于如何處理并行計(jì)算、如何分發(fā)數(shù)據(jù)、如何處理錯(cuò)誤需要大規(guī)模的代碼處理，使得原本簡單的運(yùn)算變得難以處理。MapReduce就是針對上述問題的一種新的設(shè)計(jì)模型。

MapReduce模型的主要貢獻(xiàn)就是通過簡單的接口來實(shí)現(xiàn)自動的并行化和大規(guī)模的分布式計(jì)算，通過使用MapReduce模型接口實(shí)現(xiàn)在大量普通的PC上的高性能計(jì)算。

MapReduce編程模型的原理：利用一個(gè)輸入鍵-值（Key/Value）對集合來產(chǎn)生一個(gè)輸出的key/value對集合。MapReduce庫的用戶用兩個(gè)函數(shù)表達(dá)這個(gè)計(jì)算：Map和Reduce。用戶自定義的Map函數(shù)接受一個(gè)輸入的key/value值，然后產(chǎn)生一個(gè)中間key/value對集合。MapReduce庫把所有具有相同中間key值的value值集合在一起傳遞給Reduce函數(shù)。用戶自定義的Reduce函數(shù)接收一個(gè)中間key的值和相關(guān)的一個(gè)value值的集合。Reduce函數(shù)合并這些value值，形成一個(gè)較小的value值集合，如圖3所示。

MapReduce的提出曾經(jīng)遭到過一系列的指責(zé)和詬病。數(shù)據(jù)專家Stonebraker就認(rèn)為MapReduce是一個(gè)巨大的倒退，指出其存取沒有優(yōu)化、依靠蠻力進(jìn)行數(shù)據(jù)處理等問題。但是隨著MapReduce在應(yīng)用上的不斷成功，以其為代表的大數(shù)據(jù)處理技術(shù)還是得到了廣泛的關(guān)注。研究人員也針對MapReduce進(jìn)行了深入的研究，目前針對MapReduce性能提升研究主要有以下幾個(gè)方面：多核硬件與GPU上的性能提高；索引技術(shù)與連接技術(shù)的優(yōu)化；調(diào)度技術(shù)優(yōu)化等。在MapReduce的易用性的研究上，研究人員正在研究更為高層的、表達(dá)能力更強(qiáng)的語言和系統(tǒng)，包括Yahoo的Pig、Microsoft的LINQ、Hive等。

除了Google的MapReduce，Yunhong Gu等人設(shè)計(jì)實(shí)現(xiàn)了Sector and Sphere云計(jì)算平臺[18]，包括Sector和Sphere兩部分。Sector是部署在廣域網(wǎng)的分布式系統(tǒng)，Sphere是建立在Sector上的計(jì)算服務(wù)。Sphere是以Sector為基礎(chǔ)構(gòu)建的計(jì)算云，提供大規(guī)模數(shù)據(jù)的分布式處理。Sphere的基本數(shù)據(jù)處理模型如圖4所示。

針對不同的應(yīng)用會有不同的數(shù)據(jù)，Sphere統(tǒng)一地將它們以數(shù)據(jù)流的形式輸入。為了便于大規(guī)模地并行計(jì)算，首先需要對數(shù)據(jù)進(jìn)行分割，分割后的數(shù)據(jù)交給SPE執(zhí)行。SPE是Sphere處理引擎，是Sphere的基本運(yùn)算單元。除了進(jìn)行數(shù)據(jù)處理外SPE還能起到負(fù)載平衡的作用，因?yàn)橐话闱闆r下數(shù)據(jù)量遠(yuǎn)大于SPE數(shù)量，當(dāng)前負(fù)載較重的SPE能繼續(xù)處理的數(shù)據(jù)就較少，反之則較多，如此就實(shí)現(xiàn)了系統(tǒng)的負(fù)載平衡。

1.4 分布式數(shù)據(jù)庫系統(tǒng)

傳統(tǒng)的關(guān)系模型分布式數(shù)據(jù)庫難以適應(yīng)大數(shù)據(jù)時(shí)代的要求，主要的原因有以下幾點(diǎn)：

（1）規(guī)模效應(yīng)帶來的壓力。大數(shù)據(jù)時(shí)代的數(shù)據(jù)遠(yuǎn)遠(yuǎn)超出單機(jī)處理能力，分布式技術(shù)是必然的選擇。傳統(tǒng)的數(shù)據(jù)庫傾向于采用縱向擴(kuò)展的方式，這種方式下性能的增加遠(yuǎn)低于數(shù)據(jù)的增加速度。大數(shù)據(jù)采用數(shù)據(jù)庫系統(tǒng)應(yīng)該是橫向發(fā)展的，這種方式具有更好的擴(kuò)展性。

（2）數(shù)據(jù)類型的多樣性和低價(jià)值密度性。傳統(tǒng)的數(shù)據(jù)庫適合結(jié)構(gòu)清晰，有明確應(yīng)用目的的數(shù)據(jù)，數(shù)據(jù)的價(jià)值密度相對較高。在大數(shù)據(jù)時(shí)代數(shù)據(jù)的存在的形式是多樣的，各種半結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)是大數(shù)據(jù)的重要組成部分。如何利用如此多樣、海量的低價(jià)值密度的數(shù)據(jù)是大數(shù)據(jù)時(shí)代數(shù)據(jù)庫面臨的重要挑戰(zhàn)之一。

（3）設(shè)計(jì)理念的沖突。關(guān)系數(shù)據(jù)庫追求的是“一種尺寸適用所有”，但在大數(shù)據(jù)時(shí)代不同的應(yīng)用領(lǐng)域在數(shù)據(jù)理性、數(shù)據(jù)處理方式以及數(shù)據(jù)處理時(shí)間的要求上千差萬別。實(shí)際處理中，不可能存在一種統(tǒng)一的數(shù)據(jù)存儲方式適應(yīng)所有場景。

面對這些挑戰(zhàn)，Google公司提出了Bigtable的解決方案。Bigtable的設(shè)計(jì)目的是可靠的處理拍字節(jié)級別的數(shù)據(jù)，并且能夠部署到千臺機(jī)器上。Bigtable已經(jīng)實(shí)現(xiàn)了以下幾個(gè)目標(biāo)：適用性廣泛、可擴(kuò)展、高性能和高可靠性。Bigtable已經(jīng)在超過60個(gè)Google的產(chǎn)品和項(xiàng)目上得到了應(yīng)用。這些產(chǎn)品在性能要求和集群的配置上都提出了迥異的需求，Bigtable都能夠很好地滿足。Bigtable不支持完整的關(guān)系數(shù)據(jù)模型，為用戶提供了簡單的數(shù)據(jù)模型，利用這個(gè)模型，客戶可以動態(tài)控制數(shù)據(jù)的分布和格式。用戶也可以自己推測底層存儲數(shù)據(jù)的位置相關(guān)性。數(shù)據(jù)的下標(biāo)是行和列的名字，名字可以是任意的字符串。Bigtable將存儲的數(shù)據(jù)都視字符串，但是Bigtable本身不去解釋這些字符串，客戶程序通常會把各種結(jié)構(gòu)化或者半結(jié)構(gòu)化的數(shù)據(jù)串行化到這些字符串。通過仔細(xì)選擇數(shù)據(jù)的模式，客戶可以控制數(shù)據(jù)的位置的相關(guān)性。最后，可以通過Bigtable的模式參數(shù)來控制數(shù)據(jù)是存放在內(nèi)存中、還是硬盤上。Bigtable數(shù)據(jù)模型如圖5所示，給出了Bigtable存儲大量網(wǎng)頁信息的實(shí)例。

除了Google公司為人熟知的Bigtable，其他的大型Internet內(nèi)容提供商也紛紛提出大數(shù)據(jù)系統(tǒng)。具有代表性的系統(tǒng)有Amazon的Dynamo[19]和Yahoo的PNUTS[20]。Dynamo綜合使用了鍵/值存儲、改進(jìn)的分布式哈希表（DHT）、向量時(shí)鐘等技術(shù)實(shí)現(xiàn)了一個(gè)完全的分布式、去中性化的高可用系統(tǒng)。PNUTS是一個(gè)分布式的數(shù)據(jù)庫系統(tǒng)，在設(shè)計(jì)上使用弱一致性來達(dá)到高可用性的目標(biāo)，主要的服務(wù)對象是相對較小的記錄，比如在線的大量單個(gè)記錄或者小范圍記錄集合的讀和寫訪問，不適合存儲大文件、流媒體。

Bigtable、Dynamo、PNUTS等技術(shù)的成功促使研究人員開始對關(guān)系數(shù)據(jù)庫進(jìn)行反思，產(chǎn)生了一批為采用關(guān)系模型的數(shù)據(jù)庫，這些方案通稱為：NoSQL（not only SQL）。NoSQL數(shù)據(jù)庫具有以下的特征：模式只有、支持簡易備份、簡單的應(yīng)用程序接口、一致性、支持海量數(shù)據(jù)。目前典型的非關(guān)系型數(shù)據(jù)庫主要有以下集中類別，如表1所示[21]。

1.5 大數(shù)據(jù)系統(tǒng)的開源實(shí)現(xiàn)平臺

Hadoop

除了商業(yè)化的大數(shù)據(jù)處理方案，還有一些開源的項(xiàng)目也在積極的加入到大數(shù)據(jù)的研究當(dāng)中。Hadoop[22]是一個(gè)開源分布式計(jì)算平臺，它是MapReduce計(jì)算機(jī)模型的載體。借助于Hadoop，軟件開發(fā)者可以輕松地編出分布式并行程序，從而在計(jì)算機(jī)集群上完成海量數(shù)據(jù)的計(jì)算。Intel公司給出了一種Hadoop的開源實(shí)現(xiàn)方案，如圖6所示。

在該系統(tǒng)中HDFS是與GFS類似的分布式文件系統(tǒng)，它可以構(gòu)建從幾臺到幾千臺常規(guī)服務(wù)器組成的集群，并提供高聚合輸入輸出的文件讀寫訪問。HBase[23]是與Bigtable類似的分布式、按列存儲的、多維表結(jié)構(gòu)的實(shí)時(shí)分布式數(shù)據(jù)庫?？梢蕴峁┐髷?shù)據(jù)量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的高度讀寫操作。Hive[24]是基于Hadoop的大數(shù)據(jù)分布式數(shù)據(jù)倉庫引擎。它可以將數(shù)據(jù)存放在分布式文件系統(tǒng)或分布式數(shù)據(jù)庫中，并使用SQL語言進(jìn)行海量信息的統(tǒng)計(jì)、查詢和分析操作。ZooKeeper[25]是針對大型分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)，提供的功能包括：配置維護(hù)、名字服務(wù)、分布式同步、組服務(wù)等。它可以維護(hù)系統(tǒng)配置、群組用戶和命名等信息。Sqoop[26]提供高效在Hadoop和結(jié)構(gòu)化數(shù)據(jù)源之間雙向傳送數(shù)據(jù)的連接器組件。它將數(shù)據(jù)傳輸任務(wù)轉(zhuǎn)換為分布式Map任務(wù)實(shí)現(xiàn)，在傳輸過程中還可以實(shí)現(xiàn)數(shù)據(jù)轉(zhuǎn)換等功能。Flume[27]是分布式、高可靠的和高可用的日志采集系統(tǒng)，它用來從不同源的系統(tǒng)中采集、匯總和搬移大量日志數(shù)據(jù)到一個(gè)集中式的數(shù)據(jù)存儲中。

2 結(jié)束語

本文結(jié)合大數(shù)據(jù)的產(chǎn)生背景、需求和系統(tǒng)結(jié)構(gòu)，介紹了當(dāng)前全球在大數(shù)據(jù)技術(shù)方面的進(jìn)展情況。從分析可以看到，大數(shù)據(jù)系統(tǒng)的解決方案必將落地于現(xiàn)有的云計(jì)算平臺。云計(jì)算平臺的分布式文件系統(tǒng)、分布式運(yùn)算模式和分布式數(shù)據(jù)庫管理技術(shù)都為解決大數(shù)據(jù)問題提供了思路和現(xiàn)成的平臺。通過分析也可以看到，大數(shù)據(jù)的問題的研究，必然是以商業(yè)利益為驅(qū)動，一些大的依靠數(shù)據(jù)牟利的大公司必然會是大數(shù)據(jù)應(yīng)用的主體，大數(shù)據(jù)一定會成為的重點(diǎn)領(lǐng)域?？偟膩碚f，目前對于大數(shù)據(jù)的研究仍處于一個(gè)非常初步的階段，還有很多問題需要解決，希望本文的介紹能夠給大數(shù)據(jù)研究的同行提供一定的參考。

參考文獻(xiàn)

[1] MANYIKA J， CHUI M， BROWN B， et al. Big data： The next frontier for innovation， competition， and productivity [EB/OL]. [2012-10-02].

http：//www.mckinsey.com/Insight/MGI/Research/Technology_and_Innovation/Big_data_The_next_frontier_for_innovation.

[2] BARWICK H. The “four Vs” of big data. Implementing Information Infrastructure Symposium [EB/OL]. [2012-10-02]. http：//www.computerworld.com .au/article/396198/iiis_four_vs_big_data/.

[3] 孟小峰， 慈祥. 大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn) [J]. 計(jì)算機(jī)研究與發(fā)展， 2013，50（1）：146-169.

[4] GHEMAWAT S， GOBIOFF H， LEUNG S. The Google file system [C]//Proceedings of the 19th ACM SIGOPS Symposium on Operating Systems Principles （SOSP’03）， Oct 19 - 22， 2003， Bolton Landing， NY， USA. New York， NY， USA： ACM， 2003：29-43.

[5] DEAN J， GHEMAWAT S. MapReduce： Simplified data processing on large clusters [C]//Proceedings of the 6th USENIX Symposium on Operation Systems Design and Implementation （OSDI’04）， Dec 6-8， 2004， San Francisco， CA USA. New York， NY， USA： ACM， 2004：137-150.

[6] CHANG F， DEAN J， GHEMAWAT S， et.al. Bigtable： A distributed storage system for structured data [C]//Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation （OSDI’06）， Nov 6-8，2006， Seattle，WA， USA. Berkeley， CA， USA： USENIX Association， 2006：205-218.

[7] CHAIKEN R， JENKINS B， LARSON P， et al. SCOPE： Easy and efficient parallel processing of massive data sets [J]. Proceedings of the VLDB Endowment （PVLDB）， 2008， 1 （2）：1265-1276.

[8] HDFS Architecture Guide [EB/OL]. [2012-10-02]. http：//hadoop.apache.org/docs/hdfs/r0.22.0/hdfs_design.html.

[9] FastDFS [EB/OL]. [2012-10-02]. http：//code.google.com/p/fastdfs/w/list.

[10] OpenAFS [EB/OL]. http：//www.OpenAFS.org.

[11] CloudStore [EB/OL]. [2012-10-02]. http：//code.google.com/p/kosmosfs/.

[12] BEAVER D， KUMAR S， LI H C， et al. Finding a needle in haystack： Facebook’s photo storage [C]//Proceedings of the 9th USENIX Symposium on Operating System Design and Implementation （OSDI’10）， Oct 4-6， 2010， Vancouver， Canada. Berkeley， CA， USA： USENIX Association， 2010：47-60.

[13] KUMAR R. Two computational paradigms for big data. KDD summer school [EB/OL]. [2012-10-02]. http：//kdd2012. Sigkdd.org/sites/images/summerschool/Ravi-Kumar.pdf.

[14] The big data management challenge [EB/OL]. [2012-10-02]. http：//reports.information week.com/abstract/81/8766/business-intelligence-and-information-

management/research-the-big-data-

management-challenge.html.

[15] Storm [EB/OL]. [2012-10-02]. http：//github.com/nathanmarz/storm.

[16] NEUMEYER L， ROBBINS B， NAIR A， et al. S4： Distributed stream computing platform. Proceedings of the IEEE International Conference on Data Mining Workshops （ICDMW’10）， Dec 14-17，2010， Sydney， Australia. Los Alamitos， CA， USA： IEEE Computer Society， 2010： 170-177.

[17] GOODHOPE K， KOSHY J， KREPS J， et al. Building linkedIn’s real-time activity data pipeline [J]. IEEE Data Engineering Bulletin， 2012，35（2）：33-45.

[18] GU Y H， GROSSMAN R. Sector and sphere： The design and implementation of a high performance data cloud [J]. Philosophical Transactions of the Royal Society A， 2009，367： 2429-2445.

[19] DECANDIA G， HASTORUN D， JAMPANI M， et al. Dynamo： Amazon’s highly available key-value store [C]//Proceedings of the 21th ACM SIGOPS Symposium on Operating Systems Principles （SOSP’07）， Oct 14-17， 2007， Washington， DC，USA. New York， NY， USA： ACM， 2007：205-220.

[20] COOPER B F， RAMAKRISHNAN R， SRIVASTAVA U， et al. PNUTS： Yahoo！’s hosted data serving platform [J]. Proceedings of the VLDB Endowment （PVLDB）， 2008，1（2）：1277-1288.

[21] STRAUCH C. NoSQL databases [EB/OL]. [2012-10-02]. http：//www.christof-strauch. De/nosqldbs.pdf.

[22] Hadoop [EB/OL]. [2012-10-02]. http：//hadoop.apache.org.

[23] HBase [EB/OL]. [2012-10-02]. http：//yankay.com/up-content/hbase/book.html.

[24] Hive [EB/OL]. [2012-10-02]. http：//cwiki.apache.org./conflunce/display/Hive/Home.

[25] Zookeeper [EB/OL]. [2012-10-02]. http：//zookeeper.apache.org.

[26] Sqoop [EB/OL]. [2012-10-02]. http：//spoop.apache.org.

[27] Flume [EB/OL]. [2012-10-02]. http：//flume.apache.org.

作者簡介

王秀磊，解放軍理工大學(xué)在讀博士研究生；研究方向?yàn)槿葸t/容斷網(wǎng)絡(luò)、軟件定義網(wǎng)絡(luò)、內(nèi)容中心網(wǎng)絡(luò)、網(wǎng)絡(luò)測量和網(wǎng)絡(luò)管理；已發(fā)表學(xué)術(shù)論文4篇。

劉鵬，清華大學(xué)博士畢業(yè)；解放軍理工大學(xué)教授、博導(dǎo)、學(xué)科帶頭人，中國云計(jì)算專家咨詢委員會副主任/秘書長，中國電子學(xué)會云計(jì)算專家委員會云存儲組組長；研究方向?yàn)樾畔⒕W(wǎng)格、云計(jì)算；已主持完成基金項(xiàng)目18項(xiàng)；已發(fā)表論文80余篇，出版專著12部。