大數據關鍵技術

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

關鍵詞：大數據；分布式文件系統；分布式數據庫；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世紀，世界已經進入數據大爆炸的時代，大數據時代已經來臨。從商業公司內部的各種管理和運營數據，到個人移動終端與消費電子產品的社會化數據，再到互聯網產生的海量信息數據等，每天世界上產生的信息量正在飛速增長。2009年數據信息量達到8 000億GB，而到2011年達到1.8 ZB[1]。圖靈獎獲得者Jim Gray提出的“新摩爾定律”：“每18個月全球新增信息量是計算機有史以來全部信息量的總和”，已經得到驗證。

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

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

1 大數據關鍵技術

1.1 大數據系統的架構

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

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

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

1.2 分布式文件系統

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

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

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

1.3 分布式數據處理系統

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

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

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

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

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

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

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

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

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

1.4 分布式數據庫系統

傳統的關系模型分布式數據庫難以適應大數據時代的要求，主要的原因有以下幾點：

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

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

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

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

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

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

1.5 大數據系統的開源實現平臺

Hadoop

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

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

2 結束語

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

參考文獻

[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] 孟小峰， 慈祥. 大數據管理：概念、技術與挑戰 [J]. 計算機研究與發展， 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.

作者簡介

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

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