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

大數(shù)據(jù)關(guān)鍵技術(shù)ResearchonKeyTechnologiesofBigData王秀磊/WANGXiulei劉鵬/LiuPeng（解放軍理工大學指揮信息系統(tǒng)學院，江蘇南京210007）（CollegeofCommandInformationSystems,PLAUniversityofScience&Technology,Nanjing210007,China）中圖分類號：TP311文獻標識碼：A基金項目：國家科技重大專項（2012ZX03002003）“新一代寬帶無線移動通信網(wǎng)”摘要：大數(shù)據(jù)的4V特征要求其文件系統(tǒng)應該具有海量存儲、快速讀寫的性能，處理系統(tǒng)應該具有更快速的運算能力，數(shù)據(jù)庫系統(tǒng)能夠存儲和檢索各種類型數(shù)據(jù)的能力。本文結(jié)合大數(shù)據(jù)系統(tǒng)的一般結(jié)構(gòu)，重點介紹了當前大數(shù)據(jù)領(lǐng)域在文件存儲，數(shù)據(jù)處理和數(shù)據(jù)庫領(lǐng)域的關(guān)鍵技術(shù)。通過各種技術(shù)的對比，對大數(shù)據(jù)近一步的研究工作將起到一定的指導作用。關(guān)鍵詞：大數(shù)據(jù)；分布式文件系統(tǒng)；MapReduce；分布式數(shù)據(jù)庫Abstract:The4VcharacterofBigDatarequiresthefilesystemshouldhavethecharactersofmassivestorageandfastI/O，theprocessingsystemshouldhavethecharacterofpowerfulcomputingandthedatabasesystemshouldhavetheabilityofstorageandindexvarietykindsofdata.Combinedwiththegeneralstructureofbigdatasystem,thisthesismainlyintroducesthekeytechnologiesofBigDatainfilestoragesystem,datacomputingsystemanddatabase.Withthecomparisonofvarietykindsoftechnologies,thisthesiswillhavecertainguidingsignificanceforfurtherstudyingonBigData.Keywords:BigData;DistributedFileSystem;MapReduce;DistributedDataBase1.引言21世紀，世界已經(jīng)進入數(shù)據(jù)大爆炸的時代，大數(shù)據(jù)時代已經(jīng)來臨。從商業(yè)公司內(nèi)部的各種管理和運營數(shù)據(jù)，到個人移動終端與消費電子產(chǎn)品的社會化數(shù)據(jù)，再到互聯(lián)網(wǎng)產(chǎn)生的海量信息數(shù)據(jù)等，每天世界上產(chǎn)生的信息量正在飛速增長。2009年數(shù)據(jù)信息量達到8000億GB，而到2011年達到1.8ZB[1][1]。圖靈獎獲得者JimGray提出的“新摩爾定律”：“每18個月全球新增信息量是計算機有史以來全部信息量的總和”，已經(jīng)開始得到驗證。大數(shù)據(jù)的“大”不僅僅體現(xiàn)在數(shù)據(jù)的海量性，還在于其數(shù)據(jù)類型的復雜性。隨著報表、賬單、影像、辦公文檔等在商業(yè)公司中得到普遍使用，互聯(lián)網(wǎng)上視頻、音樂、網(wǎng)絡游戲不斷發(fā)展，越來越多的非結(jié)構(gòu)化數(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ù)的產(chǎn)生經(jīng)歷了被動、主動和自動3個階段[3]。大數(shù)據(jù)的迅猛發(fā)展是信息時代數(shù)字設備計算能力和部署數(shù)量指數(shù)增長的必然結(jié)果，解決大數(shù)據(jù)研究中的問題，必須要從大數(shù)據(jù)的產(chǎn)生背景進行研究。大數(shù)據(jù)的產(chǎn)生源于規(guī)模效應，這種規(guī)模效應給數(shù)據(jù)的存儲、管理以及數(shù)據(jù)的分析帶來了極大的挑戰(zhàn)，數(shù)據(jù)管理方式上的變革正在醞釀和發(fā)生。大數(shù)據(jù)的規(guī)模效應要求其存儲、運算方案也應當從規(guī)模效應上進行考慮。傳統(tǒng)的單純依靠單設備處理能力縱向發(fā)展的技術(shù)早已經(jīng)不能滿足大數(shù)據(jù)存儲和處理需求。以Google等為代表的一些大的數(shù)據(jù)處理公司通過橫向的分布式文件存儲、分布式數(shù)據(jù)處理和分布式的數(shù)據(jù)分析技術(shù)很好的解決了由于數(shù)據(jù)爆炸所產(chǎn)生的各種問題。本論文將通過當前主流的大數(shù)據(jù)相關(guān)技術(shù)進行分析，介紹大數(shù)據(jù)研究中數(shù)據(jù)存儲和數(shù)據(jù)處理的關(guān)鍵技術(shù)。2大數(shù)據(jù)關(guān)鍵技術(shù)大數(shù)據(jù)系統(tǒng)的架構(gòu)大數(shù)據(jù)處理系統(tǒng)不管結(jié)構(gòu)如何復雜，采用的技術(shù)千差萬別，但是總體上總可以分為以下的幾個重要部分,如圖1所示。橫向擴展（Scaleout結(jié)構(gòu)并行計算框架圖1大數(shù)據(jù)系統(tǒng)結(jié)構(gòu)從數(shù)據(jù)處理的一般流程可以看到，在大數(shù)據(jù)環(huán)境下需要的關(guān)鍵技術(shù)主要針對海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的運算。傳統(tǒng)的關(guān)系數(shù)據(jù)庫經(jīng)過近40年的發(fā)展已經(jīng)成為了一門成熟同時仍在不斷演進的數(shù)據(jù)管理和分析技術(shù)，SQL語言作為存取關(guān)系數(shù)據(jù)庫的語言得到了標準化，其功能和表達能力也得到的不斷增強。但是，關(guān)系數(shù)據(jù)管理系統(tǒng)的擴展性在互聯(lián)網(wǎng)環(huán)境下遇到了前所未有的障礙，不能勝任大數(shù)據(jù)分析的要求。關(guān)系數(shù)據(jù)管理模型追求的是高度的一致性和正確性。縱向擴展系統(tǒng)，通過增加或者更換CPU、內(nèi)存、硬盤以擴展單個節(jié)點的能力，終會遇到瓶頸。大數(shù)據(jù)的研究主要來源于依靠數(shù)據(jù)獲取商業(yè)利益的大公司。Google公司作為全球最大的信息檢索公司，其走在了大數(shù)據(jù)研究的前沿。面對呈現(xiàn)爆炸式增加的因特網(wǎng)信息，僅僅依靠提高服務器性能已經(jīng)遠遠不能滿足業(yè)務的需求。如果將各種大數(shù)據(jù)應用比作“汽車”，支撐起這些“汽車”運行的“高速公路”就是云計算。正是云計算技術(shù)在數(shù)據(jù)存儲、管理與分析等方面的支持，才使得大數(shù)據(jù)有用武之地［3］。Google公司從橫向進行擴展，通過采用廉價的計算機節(jié)點集群，改寫軟件，使之能夠在集群上并行執(zhí)行，解決海量數(shù)據(jù)的存儲和檢索功能。2006年Google首先提出云計算的概念。支撐Google公司各種大數(shù)據(jù)應用的關(guān)鍵正是其自行研發(fā)的一系列云計算技術(shù)和工具。Google公司大數(shù)據(jù)處理的三大關(guān)鍵技術(shù)為：Google文件系統(tǒng)GFS［4］，MapReduce［5#DBigtable［6］。Google的技術(shù)方案為其他的公司提供了一個很好的參考方案，各大公司紛紛提出了自己的大數(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ù)。分布式文件系統(tǒng)文件系統(tǒng)是支持大數(shù)據(jù)應用的基礎(chǔ)。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是構(gòu)建于大量廉價的服務器之上的可擴展的分布式文件系統(tǒng)，采用主從(Master-Slave)結(jié)構(gòu)。通過數(shù)據(jù)分塊、追加更新等方式實現(xiàn)了海量數(shù)據(jù)的高效存儲，如圖2所示給出了GFS體系結(jié)構(gòu)［4］。但是隨著業(yè)務量的進一步變化，GFS逐漸無法適應需求。Google對GFS進行了設計，實現(xiàn)了Colosuss系統(tǒng)，該系統(tǒng)能夠很好的解決GFS單點故障和海量小文件存儲的問題。CuntrolCuntrol圖2GFS體系結(jié)構(gòu)除了Google的GFS,眾多的企業(yè)和學者也從不同的方面對滿足大數(shù)據(jù)存儲需求的文件系統(tǒng)進行了詳細的研究。微軟開發(fā)的Cosmos［7］支撐其搜索、廣告業(yè)務。HDFS網(wǎng)、FastDFS［9］、OpenAFS［10#DCloudStore［11］都是類似GFS的開源實現(xiàn)。類GFS的分布式文件系統(tǒng)主要針對大文件而設計，但是在圖片存儲等應用場景中，文件系統(tǒng)主要存儲海量小文件，F(xiàn)acebook為此推出了專門針對海量小文件的文件系統(tǒng)Haystack［12］，通過多個邏輯文件共享同一個物理文件，增加緩存層、部分元數(shù)據(jù)加載到內(nèi)存等方式有效地解決了海量小文件存儲的問題。Lustre是一種大規(guī)模、安全可靠的，具備高可靠性的集群文件系統(tǒng)，由SUN公司開發(fā)和維護。該項目主要的目的就是開發(fā)下一代的集群文件系統(tǒng)，可以支持超過10000個節(jié)點，數(shù)以PB的數(shù)量存儲系統(tǒng)。分布式數(shù)據(jù)處理系統(tǒng)大數(shù)據(jù)的處理模式分為流處理(streamprocessing)和批處理(batchprocessing)兩種［13］［14］。流處理是直接處理(straight-throughprocessing)，批處理采用先存儲再處理(store-then-process)。流處理將數(shù)據(jù)視為流，源源不斷的數(shù)據(jù)形成數(shù)據(jù)流。當新的數(shù)據(jù)到來即立即處理并返回所需的結(jié)果。大數(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架構(gòu)的程序能夠在大量的普通配置的計算機上實現(xiàn)并行化處理。這個系統(tǒng)在運行時只關(guān)心如何分割輸入數(shù)據(jù)，在大量計算機組成的集群上的調(diào)度，集群中計算機的錯誤處理，管理集群中的計算機之間必要的通信。對于有些計算，由于輸入數(shù)據(jù)量的巨大，想要在可接受的時間內(nèi)完成運算，只有將這些計算分布在成百上千的主機上。這種計算模式對于如何處理并行計算、如何分發(fā)數(shù)據(jù)、如何處理錯誤需要大規(guī)模的代碼處理，使得原本簡單的運算變得難以處理。MapReduce就是針對上述問題的一種新的設計模型。用戶程序(1)fork(1)fork(1)fork(1)fork(1)f0rkMaster(2)assignmapWorkerMaster(2)assignmapWorker(2)assignreduceWorkersplit。splitlsplit2split3split4(6)writesplit。splitlsplit2split3split4(6)writeOutput

fileO(3)readWorker(4)localwrite(5)remotereadWorkerOutput

filelWorker圖3MapReduce工作流程MapReduce模型的主要貢獻就是通過簡單的接口來實現(xiàn)自動的并行化和大規(guī)模的分布式計算，通過使用MapReduce模型接口實現(xiàn)在大量普通的PC上的高性能計算。MapReduce編程模型的原理：利用一個輸入key/value對集合來產(chǎn)生一個輸出的key/value對集合。MapReduce庫的用戶用兩個函數(shù)表達這個計算：Map和Reduce。用戶自定義的Map函數(shù)接受一個輸入的key/value值，然后產(chǎn)生一個中間key/value對集合。MapReduce庫把所有具有相同中間key值的value值集合在一起傳遞給reduce函數(shù)。用戶自定義的Reduce函數(shù)接收一個中間key的值和相關(guān)的一個value值的集合。Reduce函數(shù)合并這些value值，形成一個較小的value值集合，如圖3所示。MapReduce的提出曾經(jīng)遭到過一系列的指責和詬病。數(shù)據(jù)專家Stonebraker就認為MapReduce是一個巨大的倒退，指出其存取沒有優(yōu)化、依靠蠻力進行數(shù)據(jù)處理等問題。但是隨著MapReduce在應用上的不斷成功，以其為代表的大數(shù)據(jù)處理技術(shù)還是得到了廣泛的關(guān)注。研究人員也針對MapReduce進行了深入的研究，目前針對MapReduce性能提升研究主要有以下幾個方面：多核硬件與GPU上的性能提高；索引技術(shù)與連接技術(shù)的優(yōu)化；調(diào)度技術(shù)優(yōu)化等。在MapReduce的易用性的研究上，研究人員正在研究更為高層的、表達能力更強的語言和系統(tǒng)。包括Yahoo的Pig、Microsoft的LINQ、Hive等。除了Google的MapReduce，YunhongGu等人設計實現(xiàn)了SectorandSphere云計算平臺［26］，包括Sector和Sphere兩部分。Sector是部署在廣域網(wǎng)的分布式系統(tǒng)，Sphere是建立在Sector上的計算服務。Sphere是以Sector為基礎(chǔ)構(gòu)建的計算云，提供大規(guī)模數(shù)據(jù)的分布式處理。Sphere的基本數(shù)據(jù)處理模型如圖4所示。圖4圖4Sphere的基本數(shù)據(jù)處理模型針對不同的應用會有不同的數(shù)據(jù)，Sphere統(tǒng)一地將它們以數(shù)據(jù)流的形式輸入。為了便于大規(guī)模地并行計算，首先需要對數(shù)據(jù)進行分割，分割后的數(shù)據(jù)交給SPE執(zhí)行。SPE是Sphere處理引擎(SphereProcessingEngine),是Sphere的基本運算單元。除了進行數(shù)據(jù)處理外SPE還能起到負載平衡的作用，因為一般情況下數(shù)據(jù)量遠大于SPE數(shù)量，當前負載較重的SPE能繼續(xù)處理的數(shù)據(jù)就較少，反之則較多，如此就實現(xiàn)了系統(tǒng)的負載平衡。SPE處理后的結(jié)果既可以作為最終結(jié)果以輸出流形式輸出，也可以作為下一個處理過程的輸入。分布式數(shù)據(jù)庫系統(tǒng)傳統(tǒng)的關(guān)系模型分布式數(shù)據(jù)庫難以適應大數(shù)據(jù)時代的要求，主要的原因有以下幾點[引：.規(guī)模效應帶來的壓力。大數(shù)據(jù)時代的數(shù)據(jù)遠遠超出單機處理能力，分布式技術(shù)是必然的選擇。傳統(tǒng)的數(shù)據(jù)庫傾向于采用縱向擴展的方式，這種方式下性能的增加遠低于數(shù)據(jù)的增加速度。大數(shù)據(jù)采用數(shù)據(jù)庫系統(tǒng)應該是橫向發(fā)展的，這種方式具有更好的擴展性。.數(shù)據(jù)類型的多樣性和低價值密度性。傳統(tǒng)的數(shù)據(jù)庫適合結(jié)構(gòu)清晰，有明確應用目的的數(shù)據(jù),數(shù)據(jù)的價值密度相對較高。在大數(shù)據(jù)時代數(shù)據(jù)的存在的形式是多樣的，各種半結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)是大數(shù)據(jù)的重要組成部分。如何利用如此多樣、海量的低價值密度的數(shù)據(jù)是大數(shù)據(jù)時代數(shù)據(jù)庫面臨的重要挑戰(zhàn)之一。.設計理念的沖突。關(guān)系數(shù)據(jù)庫追求的是“Onesizeforall”，但在大數(shù)據(jù)時代不同的應用領(lǐng)域在數(shù)據(jù)理性、數(shù)據(jù)處理方式以及數(shù)據(jù)處理時間的要求上千差萬別。實際處理中，不可能存在一種統(tǒng)一的數(shù)據(jù)存儲方式適應所有場景。面對這些挑戰(zhàn)，Google公司提出了Bigtable的解決方案。Bigtable的設計目的是可靠的處理PB級別的數(shù)據(jù)，并且能夠部署到千臺機器上。Bigtable已經(jīng)實現(xiàn)了以下幾個目標：適用性廣泛、可擴展、高性能和高可靠性。Bigtable已經(jīng)在超過60個Google的產(chǎn)品和項目上得到了應用。這些產(chǎn)品在性能要求和集群的配置上都提出了迥異的需求，Bigtable都能夠很好的滿足。Bigtable不支持完整的關(guān)系數(shù)據(jù)模型，為用戶提供了簡單的數(shù)據(jù)模型，利用這個模型,客戶可以動態(tài)控制數(shù)據(jù)的分布和格式。用戶也可以自己推測底層存儲數(shù)據(jù)的位置相關(guān)性。數(shù)據(jù)的下標是行和列的名字，名字可以是任意的字符串。Bigtable將存儲的數(shù)據(jù)都視字符串，但是Bigtable本身不去解釋這些字符串，客戶程序通常會把各種結(jié)構(gòu)化或者半結(jié)構(gòu)化的數(shù)據(jù)串行化到這些字符串。通過仔細選擇數(shù)據(jù)的模式，客戶可以控制數(shù)據(jù)的位置的相關(guān)性。最后，可以通過Bigtable的模式參數(shù)來控制數(shù)據(jù)是存放在內(nèi)存中、還是硬盤上。如圖5所示，給出7Bigtable存儲大量網(wǎng)頁信息的實例。"cDn.Mmw"cDn.Mmw11圖5Bigtable數(shù)據(jù)模型示例除了Google公司為人熟知的Bigtable,其他的大型Internet內(nèi)容提供商也紛紛提出大數(shù)據(jù)系統(tǒng)。具有代表性的系統(tǒng)有Amazon的Dynamo[18#DYahoo的PNUTS[19]。Dynamo綜合使用了鍵/值存儲、改進的分布式哈希表(DHT)、向量時鐘(vectorclock)等技術(shù)實現(xiàn)了一個完全的分布式、去中性化的高可用系統(tǒng)。PNUTS是一個分布式的數(shù)據(jù)庫系統(tǒng)，在設計上使用弱一致性來達到高可用性的目標，主要的服務對象是相對較小的記錄，比如在線的大量單個記錄或者小范圍記錄集合的讀和寫訪問，不適合存儲大文件、流媒體。Bigtable、Dynamo,PNUTS等技術(shù)的成功促使研究人員開始對關(guān)系數(shù)據(jù)庫進行反思，產(chǎn)生了一批為采用關(guān)系模型的數(shù)據(jù)庫，這些方案通稱為：NoSQL(notonlySQL)。NoSQL數(shù)據(jù)庫具有以下的特征：模式只有、支持簡易備份、簡單的應用程序接口、一致性、支持海量數(shù)

據(jù)。目前典型的非關(guān)系型數(shù)據(jù)庫主要有以下集中類別，如表1[27]。表1典型NoSQL數(shù)據(jù)庫類別相關(guān)數(shù)據(jù)庫性能擴展性靈活性復雜性優(yōu)點缺點Key-ValueRedisRiak高高高無查詢高效數(shù)據(jù)存儲缺乏結(jié)構(gòu)ColumnHBaseCassandra高高中低查詢高效功能有限D(zhuǎn)ocumentCouchDBMongoDB高可變高低對數(shù)據(jù)結(jié)構(gòu)限制小查詢性能低GraphOrientDB可變可變高高圖算法高效數(shù)據(jù)規(guī)模小2.5大數(shù)據(jù)系統(tǒng)的開源實現(xiàn)Hadoop除了商業(yè)化的大數(shù)據(jù)處理方案，還有一些開源的項目也在積極的加入到大數(shù)據(jù)的研究當中。Hadoop[20]是一個開源分布式計算平臺，它是MapReduce計算機模型的載體。借助于Hadoop,軟件開發(fā)者可以輕松地編出分布式并行程序，從而在計算機集群上完成海量數(shù)據(jù)的計算。Intel公司給出了一種Hadoop的開源實現(xiàn)方案，如圖6所示。在該系統(tǒng)中HDFS是與GFS類似的分布式文件系統(tǒng)，它可以構(gòu)建從幾臺到幾千臺常規(guī)服務器組成的集群，并提供高聚合輸入輸出的文件讀寫訪問；HBase[21]是與Bigtable類似的分布式、按列存儲的、多維表結(jié)構(gòu)的實時分布式數(shù)據(jù)庫?？梢蕴峁┐髷?shù)據(jù)量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的高度讀寫操作；Hive[22]是基于Hadoop的大數(shù)據(jù)分布式數(shù)據(jù)倉庫引擎。它可以將數(shù)據(jù)存放在分布式文件系統(tǒng)或分布式數(shù)據(jù)庫中，并使用SQL語言進行海量信息的統(tǒng)計、查詢和分析操作；ZooKeeper[23]是針對大型分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)，提供的功能包括：配置維護、名字服務、分布式同步、組服務等。它可以維護系統(tǒng)配置、群組用戶和命名等信息；Sqoop[24]提供高效在Hadoop和結(jié)構(gòu)化數(shù)據(jù)源之間雙向傳送數(shù)據(jù)的連接器組件。它將數(shù)據(jù)傳輸任務轉(zhuǎn)換為分布式Map任務實現(xiàn)，在傳輸過程中還可以實現(xiàn)數(shù)據(jù)轉(zhuǎn)換等功能；Flume[25]是分布式、高可靠的和高可用的日志采集系統(tǒng),它用來從不同源的系統(tǒng)中采集、匯總和搬移大量日志數(shù)據(jù)到一個集中式的數(shù)據(jù)存儲中。IntelHadoopManager2.2安裝、部署、配置、監(jiān)控“告警和訪間控制Mahout0.6數(shù)據(jù)挖掘R-statistics數(shù)據(jù)分析Mahout0.6數(shù)據(jù)挖掘R-statistics數(shù)據(jù)分析Pig0.9.2數(shù)據(jù)流處理3總結(jié)情況。E3總結(jié)情況。E用n口Map/Reduce1,03分布式計算椎架-IDH組件和系統(tǒng)結(jié)構(gòu)，介紹了當前國內(nèi)外外在大數(shù)據(jù)技術(shù)方面的進展

統(tǒng)的解決方案必將落地署有的云電臺喇算平臺HDFS1.0.3分布式文件系統(tǒng)的分布式文件系統(tǒng)、分布式運算模式和分布式數(shù)據(jù)庫管理技術(shù)都為解決大數(shù)據(jù)問題提供了思路和現(xiàn)成的平臺。通過分析也可以看到，大數(shù)據(jù)的問題的研究，必然是以商業(yè)利益為驅(qū)動，一些大的依靠數(shù)據(jù)牟利的大公司必然會是大數(shù)據(jù)應用的主體，大數(shù)據(jù)一定會成為的重點領(lǐng)域。總的來說，目前對于大數(shù)據(jù)的研究仍處于一個非常初步的階段，還有很多問題需要解決，希望本文的介紹能夠給大數(shù)據(jù)研究的同行提供一定的參考。4參考文獻JamesManyika,MichaelChui,BradBrown,JacquesBughin,RichardDobbs,CharlesRoxburgh,AngelaHungByers.Bigdata:Thenextfrontierforinnovation,competition,andproductivity[R/OL].[2012-10-02]./Insight/MGI/Research/Technology_and_Innovation/Big_data_The_next_frontier_for_innovation.BarwickH.The“fourVs”ofBigData.ImplementingInformationInfrastructureSymposium[EB/OL].[2012-10-02]..au/article/396198/iiis_four_vs_big_data/孟小峰，慈祥.大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn).計算機研究與發(fā)展.2013,146-169.Ghemawat.S,Gobioff.H,Leung.S.TheGooglefilesystem[C].Theproceedingsofthe19thSymposiumonOperatingSystemsPrinciples,LakeGeorge,NewYork,2003.DeanJ,GhemawatS.MapReduce:Simplifieddataprocessingonlargeclusters.TheProceedingsofthe6thSymposiumonOperatingSystemDesignandImplementation(OSDI’04).SanFrancisco,California,USA,2004:137-150.ChangF,DeanJ,GhemawatS,et.al.Bigtable:ADistributedStorageSystemforStructuredData[C].TheProceedingsoftheOSDI’06:SeventhSymposiumonOperatingSystemDesignandImplementation,Seattle,WA,2006.ChaikenR,JenkinsB,etal.SCOPE:Easyandefficientparallelprocessingofmassivedatasets[J].PVLDB,2008,1(2):1265-1276.HDFSArchitectureGuide./docs/hdfs/r0.22.0/hdfs_design.html.FastDFS./p/fastdfs/w/list.OpenAFS.http://www.OpenAFS.org.CloudStore./p/kosmosfs/BeaverD,KumarS,etal.FindingaNeedleinHaystack:Facebook’sPhotoStorage[C]ProcofOSDI2010.Berkeley,CA:USENIXAssociation,2010:47-60.KumarR.Twocomputationalparadigmsforbigdata.KDDsummerschool,2012.http://kdd2012.S/sites/images/summerschool/Ravi-Kumar.pdf.InformationWeekReport.Thebigdatamanagementchallenge./abstract/81/8766/business-intelligence-and-information-management/research-the-big-data-management-challenge.html.Storm./nathanmarz/stormNeumeyerL,RobbinsB,etal.S4:DistributedStreamComputingPlatform.ProcofICDMWorkshops2010.Pisc