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

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

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 文獻標志碼：A 文章編號：1009-6868 （2013） 04-0017-005

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hadoop

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

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

2 結束語

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

參考文獻

[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ù)管理：概念、技術與挑戰(zhàn) [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.

作者簡介

王秀磊，解放軍理工大學在讀博士研究生；研究方向為容遲/容斷網(wǎng)絡、軟件定義網(wǎng)絡、內容中心網(wǎng)絡、網(wǎng)絡測量和網(wǎng)絡管理；已發(fā)表學術論文4篇。

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