大數(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特點。規(guī)模性和高速性是數(shù)據(jù)處理一直以來研究和探討的問題，多樣性和價值密度低是當前數(shù)據(jù)處理發(fā)展中不斷顯現(xiàn)出來的問題，而且在可以預見的未來，隨著智慧城市、智慧地球等各種新設想的不斷成為現(xiàn)實，上面的4中問題將會變得更加凸顯，而且是不得不面對的問題。
數(shù)據(jù)的產生經歷了被動、主動和自動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ā)展的技術早已經不能滿足大數(shù)據(jù)存儲和處理需求。以Google等為代表的一些大的數(shù)據(jù)處理公司通過橫向的分布式文件存儲、分布式數(shù)據(jù)處理和分布式的數(shù)據(jù)分析技術很好的解決了由于數(shù)據(jù)爆炸所產生的各種問題。
1.1 大數(shù)據(jù)系統(tǒng)的架構
大數(shù)據(jù)處理系統(tǒng)不管結構如何復雜，采用的技術千差萬別，但是總體上總可以分為以下的幾個重要部分。
從數(shù)據(jù)處理的一般流程可以看到，在大數(shù)據(jù)環(huán)境下需要的關鍵技術主要針對海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的運算。傳統(tǒng)的關系數(shù)據(jù)庫經過近40年的發(fā)展已經成為了一門成熟同時仍在不斷演進的數(shù)據(jù)管理和分析技術，結構化查詢語言(SQL)作為存取關系數(shù)據(jù)庫的語言得到了標準化，其功能和表達能力也得到的不斷增強。但是，關系數(shù)據(jù)管理系統(tǒng)的擴展性在互聯(lián)網(wǎng)環(huán)境下遇到了前所未有的障礙，不能勝任大數(shù)據(jù)分析的要求。關系數(shù)據(jù)管理模型追求的是高度的一致性和正確性。縱向擴展系統(tǒng)，通過增加或者更換CPU、內存、硬盤以擴展單個節(jié)點的能力，終會遇到“瓶頸”。
大數(shù)據(jù)的研究主要來源于依靠數(shù)據(jù)獲取商業(yè)利益的大公司。Google公司作為全球最大的信息檢索公司，其走在了大數(shù)據(jù)研究的前沿。面對呈現(xiàn)爆炸式增加的因特網(wǎ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)有的方案已經難以滿足其如此大的數(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ù)的高效存儲，所示給出了GFS體系結構。但是隨著業(yè)務量的進一步變化，GFS逐漸無法適應需求。Google對GFS進行了設計，實現(xiàn)了Colosuss系統(tǒng)，該系統(tǒng)能夠很好地解決GFS單點故障和海量小文件存儲的問題。
除了Google的GFS，眾多的企業(yè)和學者也從不同的方面對滿足大數(shù)據(jù)存儲需求的文件系統(tǒng)進行了詳細的研究。微軟開發(fā)的Cosmos支撐其搜索、廣告業(yè)務。HDFS、FastDFS、OpenAFS和CloudStore都是類似GFS的開源實現(xiàn)。類GFS的分布式文件系統(tǒng)主要針對大文件而設計，但是在圖片存儲等應用場景中，文件系統(tǒng)主要存儲海量小文件，F(xiàn)acebook為此推出了專門針對海量小文件的文件系統(tǒng)Haystack，通過多個邏輯文件共享同一個物理文件，增加緩存層、部分元數(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ù)的處理模式分為流處理和批處理兩種。流處理是直接處理，批處理采用先存儲再處理。
流處理將數(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、Yahoo的S4以及Linkedin的Kafka等。
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值集合
MapReduce的提出曾經遭到過一系列的指責和詬病。數(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已經實現(xiàn)了以下幾個目標：適用性廣泛、可擴展、高性能和高可靠性。Bigtable已經在超過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.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ù)存儲中。
主要結合大數(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ù)一定會成為重點研究領域。
