Google關(guān)于大數(shù)據(jù)處理的論文簡述

Google關(guān)于大數(shù)據(jù)處理的論文簡述72013年4月目錄一、簡述 3二、Google經(jīng)典三篇大數(shù)據(jù)論文介紹 32.1、GFS 32.2、MapReduce 52.3、BigTable一個分布式的結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng) 6三、Google新大數(shù)據(jù)論文介紹 63.1、Caffeine：處理個體修改 73.2、Pregel：可擴(kuò)展的圖計算 83.3、Dremel：在線可視化 8四、總結(jié) 12一、簡述Google在2003年開始陸續(xù)公布了關(guān)于GFS、MapReduce和BigTable三篇技術(shù)論文，這也成為后來云計算發(fā)展的重要基石，為數(shù)據(jù)領(lǐng)域工作者開啟了大數(shù)據(jù)算法之門。然而Google的大數(shù)據(jù)腳步顯然不止于此，其后公布了Percolator、Pregel、Dremel、Spanner等多篇論文。沒有止步的不僅是Google，很多公司也跟隨其腳步開發(fā)了很多優(yōu)秀的產(chǎn)品，雖然其中不乏模仿。主流的大數(shù)據(jù)基本都是MapReduce的衍生，然而把目光聚焦到實(shí)時上就會發(fā)現(xiàn)：MapReuce的局限性已經(jīng)漸漸浮現(xiàn)。下面將討論一下自大數(shù)據(jù)開始，Google公布的大數(shù)據(jù)相關(guān)技術(shù)，以及這些技術(shù)的現(xiàn)狀。從2010年之后Google在后Hadoop時代的新“三駕馬車”——Caffeine、Pregel、Dremel再一次影響著全球大數(shù)據(jù)技術(shù)的發(fā)展潮流。但這還遠(yuǎn)遠(yuǎn)不夠，目前Google內(nèi)部使用的大數(shù)據(jù)軟件Dremel使大數(shù)據(jù)處理起來更加智能。二、Google經(jīng)典三篇大數(shù)據(jù)論文介紹Google在2003年到2006年公布了關(guān)于GFS、MapReduce和BigTable三篇技術(shù)論文。三篇論文主要闡述：2.1、GFS公布時間：2003年。GFS闡述了GoogleFileSystem的設(shè)計原理，GFS是一個面向大規(guī)模數(shù)據(jù)密集型應(yīng)用的、可伸縮的分布式文件系統(tǒng)。GFS雖然運(yùn)行在廉價的普遍硬件設(shè)備上，但是它依然了提供災(zāi)難冗余的能力，為大量客戶機(jī)提供了高性能的服務(wù)。雖然GFS的設(shè)計目標(biāo)與許多傳統(tǒng)的分布式文件系統(tǒng)有很多相同之處，但是，我們設(shè)計還是以我們對自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的分析為基礎(chǔ)的，不管現(xiàn)在還是將來，GFS和早期的分布式文件系統(tǒng)的設(shè)想都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計上的折衷選擇，衍生出了完全不同的設(shè)計思路。GFS完全滿足了我們對存儲的需求。GFS作為存儲平臺已經(jīng)被廣泛的部署在Google內(nèi)部，存儲我們的服務(wù)產(chǎn)生和處理的數(shù)據(jù)，同時還用于那些需要大規(guī)模數(shù)據(jù)集的研究和開發(fā)工作。目前為止，最大的一個集群利用數(shù)千臺機(jī)器的數(shù)千個硬盤，提供了數(shù)百TB的存儲空間，同時為數(shù)百個客戶機(jī)服務(wù)。為了滿足Google迅速增長的數(shù)據(jù)處理需求，我們設(shè)計并實(shí)現(xiàn)了Google文件系統(tǒng)(GoogleFileSystem–GFS)。GFS與傳統(tǒng)的分布式文件系統(tǒng)有著很多相同的設(shè)計目標(biāo)，比如，性能、可伸縮性、可靠性以及可用性。但是，我們的設(shè)計還基于我們對我們自己的應(yīng)用的負(fù)載情況和技術(shù)環(huán)境的觀察的影響，不管現(xiàn)在還是將來，GFS和早期文件系統(tǒng)的假設(shè)都有明顯的不同。所以我們重新審視了傳統(tǒng)文件系統(tǒng)在設(shè)計上的折衷選擇，衍生出了完全不同的設(shè)計思路。首先，組件失效被認(rèn)為是常態(tài)事件，而不是意外事件。GFS包括幾百甚至幾千臺普通的廉價設(shè)備組裝的存儲機(jī)器，同時被相當(dāng)數(shù)量的客戶機(jī)訪問。GFS組件的數(shù)量和質(zhì)量導(dǎo)致在事實(shí)上，任何給定時間內(nèi)都有可能發(fā)生某些組件無法工作，某些組件無法從它們目前的失效狀態(tài)中恢復(fù)。我們遇到過各種各樣的問題，比如應(yīng)用程序bug、操作系統(tǒng)的bug、人為失誤，甚至還有硬盤、內(nèi)存、連接器、網(wǎng)絡(luò)以及電源失效等造成的問題。所以，持續(xù)的監(jiān)控、錯誤偵測、災(zāi)難冗余以及自動恢復(fù)的機(jī)制必須集成在GFS中。其次，以通常的標(biāo)準(zhǔn)衡量，我們的文件非常巨大。數(shù)GB的文件非常普遍。每個文件通常都包含許多應(yīng)用程序?qū)ο?，比如web文檔。當(dāng)我們經(jīng)常需要處理快速增長的、并且由數(shù)億個對象構(gòu)成的、數(shù)以TB的數(shù)據(jù)集時，采用管理數(shù)億個KB大小的小文件的方式是非常不明智的，盡管有些文件系統(tǒng)支持這樣的管理方式。因此，設(shè)計的假設(shè)條件和參數(shù)，比如I/O操作和Block的尺寸都需要重新考慮。第三，絕大部分文件的修改是采用在文件尾部追加數(shù)據(jù)，而不是覆蓋原有數(shù)據(jù)的方式。對文件的隨機(jī)寫入操作在實(shí)際中幾乎不存在。一旦寫完之后，對文件的操作就只有讀，而且通常是按順序讀。大量的數(shù)據(jù)符合這些特性，比如：數(shù)據(jù)分析程序掃描的超大的數(shù)據(jù)集；正在運(yùn)行的應(yīng)用程序生成的連續(xù)的數(shù)據(jù)流；存檔的數(shù)據(jù)；由一臺機(jī)器生成、另外一臺機(jī)器處理的中間數(shù)據(jù)，這些中間數(shù)據(jù)的處理可能是同時進(jìn)行的、也可能是后續(xù)才處理的。對于這種針對海量文件的訪問模式，客戶端對數(shù)據(jù)塊緩存是沒有意義的，數(shù)據(jù)的追加操作是性能優(yōu)化和原子性保證的主要考量因素。第四，應(yīng)用程序和文件系統(tǒng)API的協(xié)同設(shè)計提高了整個系統(tǒng)的靈活性。比如，我們放松了對GFS一致性模型的要求，這樣就減輕了文件系統(tǒng)對應(yīng)用程序的苛刻要求，大大簡化了GFS的設(shè)計。我們引入了原子性的記錄追加操作，從而保證多個客戶端能夠同時進(jìn)行追加操作，不需要額外的同步操作來保證數(shù)據(jù)的一致性。本文后面還有對這些問題的細(xì)節(jié)的詳細(xì)討論。Google已經(jīng)針對不同的應(yīng)用部署了多套GFS集群。最大的一個集群擁有超過1000個存儲節(jié)點(diǎn)，超過300TB的硬盤空間，被不同機(jī)器上的數(shù)百個客戶端連續(xù)不斷的頻繁訪問。2.2、MapReduce公布時間：2004年。MapReduce是一個編程模型，也是一個處理和生成超大數(shù)據(jù)集的算法模型的相關(guān)實(shí)現(xiàn)。用戶首先創(chuàng)建一個Map函數(shù)處理一個基于key/valuepair的數(shù)據(jù)集合，輸出中間的基于key/valuepair的數(shù)據(jù)集合；然后再創(chuàng)建一個Reduce函數(shù)用來合并所有的具有相同中間key值的中間value值。現(xiàn)實(shí)世界中有很多滿足上述處理模型的例子，本論文將詳細(xì)描述這個模型。MapReduce架構(gòu)的程序能夠在大量的普通配置的計算機(jī)上實(shí)現(xiàn)并行化處理。這個系統(tǒng)在運(yùn)行時只關(guān)心：如何分割輸入數(shù)據(jù)，在大量計算機(jī)組成的集群上的調(diào)度，集群中計算機(jī)的錯誤處理，管理集群中計算機(jī)之間必要的通信。采用MapReduce架構(gòu)可以使那些沒有并行計算和分布式處理系統(tǒng)開發(fā)經(jīng)驗(yàn)的程序員有效利用分布式系統(tǒng)的豐富資源。我們的MapReduce實(shí)現(xiàn)運(yùn)行在規(guī)?？梢造`活調(diào)整的由普通機(jī)器組成的集群上：一個典型的MapReduce計算往往由幾千臺機(jī)器組成、處理以TB計算的數(shù)據(jù)。程序員發(fā)現(xiàn)這個系統(tǒng)非常好用：已經(jīng)實(shí)現(xiàn)了數(shù)以百計的MapReduce程序，在Google的集群上，每天都有1000多個MapReduce程序在執(zhí)行。2.3、BigTable一個分布式的結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)公布時間：2006年。Bigtable是一個分布式的結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)，它被設(shè)計用來處理海量數(shù)據(jù)：通常是分布在數(shù)千臺普通服務(wù)器上的PB級的數(shù)據(jù)。Google的很多項(xiàng)目使用Bigtable存儲數(shù)據(jù)，包括Web索引、GoogleEarth、GoogleFinance。這些應(yīng)用對Bigtable提出的要求差異非常大，無論是在數(shù)據(jù)量上（從URL到網(wǎng)頁到衛(wèi)星圖像）還是在響應(yīng)速度上（從后端的批量處理到實(shí)時數(shù)據(jù)服務(wù)）。盡管應(yīng)用需求差異很大，但是，針對Google的這些產(chǎn)品，Bigtable還是成功的提供了一個靈活的、高性能的解決方案。本論文描述了Bigtable提供的簡單的數(shù)據(jù)模型，利用這個模型，用戶可以動態(tài)的控制數(shù)據(jù)的分布和格式。老三篇即使我們常用的Hadoop系統(tǒng)的設(shè)計理論基石。雖然Google沒有公布這三個產(chǎn)品的源碼，但是根據(jù)google發(fā)布了這三個產(chǎn)品的詳細(xì)設(shè)計論文。而且，Yahoo資助的Hadoop也有按照這三篇論文的開源Java實(shí)現(xiàn):Hadoop對應(yīng)Mapreduce,HadoopDistributedFileSystem(HDFS)對應(yīng)Googlefs,Hbase對應(yīng)Bigtable。不過在性能上Hadoop比Google要差很多三、Google新大數(shù)據(jù)論文介紹Hadoop來源自Google在2003年底和2004年發(fā)表的兩篇研究論文。第一篇介紹了GoogleFileSystem，它是一個可擴(kuò)展的分布式文件系統(tǒng)，用于大型的、分布式的、對大量數(shù)據(jù)進(jìn)行訪問的應(yīng)用。它運(yùn)行于廉價的普通電腦服務(wù)器上，但可以提供容錯功能并且可以給大量的用戶提供總體性能較高的服務(wù)；另一篇介紹的是MapReduce，這是是一種編程模型，用于大規(guī)模數(shù)據(jù)集（大于1TB）的并行運(yùn)算，能夠極大地方便編程人員在不會分布式并行編程的情況下,將自己的程序運(yùn)行在分布式系統(tǒng)上。八年之后，Hadoop在網(wǎng)絡(luò)上得到了廣泛的使用，應(yīng)用領(lǐng)域涉及數(shù)據(jù)分析到各種這樣的數(shù)值計算任務(wù)。但Google卻研發(fā)出了更好的技術(shù)。2009年，網(wǎng)絡(luò)巨頭Google開始用新的技術(shù)取代GoogleFileSystem和MapReduce。相應(yīng)替代的理論基礎(chǔ)來自以下三篇論文為主導(dǎo):Caffeine、Pregel、Dremel。3.1、Caffeine：處理個體修改公布時間：2010年。Google并沒有止步于MapReduce。事實(shí)上，隨著Internet的指數(shù)增長，從零開始重算所有搜索索引變得不切實(shí)際。取而代之，Google開發(fā)了一個更有價值的系統(tǒng)，同樣支持分布式計算系統(tǒng)。GoogleCaffeine是google全球數(shù)據(jù)中心網(wǎng)絡(luò)上的新的搜索基礎(chǔ)設(shè)施——是基于分布式數(shù)據(jù)處理系統(tǒng)Percolator的。Percolator引入了事務(wù)，而一些NoSQL數(shù)據(jù)庫仍然在強(qiáng)調(diào)得到高擴(kuò)展性的同時你必須犧牲（或者不再需要）事務(wù)處理。它是一個增量處理平臺——一種可以持續(xù)更新Google公司的核心搜索索引而不需要從頭開始處理所有數(shù)據(jù)的方法。在本質(zhì)上Caffeine丟棄MapReduce轉(zhuǎn)而將索引放置在由Google開發(fā)的分布式數(shù)據(jù)庫BigTable上。作為Google繼GFS和MapReduce兩項(xiàng)創(chuàng)新后的又一項(xiàng)創(chuàng)新，其在設(shè)計用來針對海量數(shù)據(jù)處理情形下的管理結(jié)構(gòu)型數(shù)據(jù)方面具有巨大的優(yōu)勢。這種海量數(shù)據(jù)可以定義為在云計算平臺中數(shù)千臺普通服務(wù)器上PB級的數(shù)據(jù)。在本論文中，Google展示了其網(wǎng)絡(luò)搜索是如何保持著與時俱進(jìn)。Percolator建立于已存類似Bigtable的技術(shù)，但是加入了事務(wù)以及行和表上的鎖和表變化的通知。這些通知之后會被用于觸發(fā)不同階段的計算。通過這樣的方式，個體的更新就可以“滲透”整個數(shù)據(jù)庫。這種方法會讓人聯(lián)想到類似Storm（或者是Yahoo的S4）的流處理框架（SPF），然而Percolator內(nèi)在是以數(shù)據(jù)作為基礎(chǔ)。SPF使用的一般是消息傳遞而不是數(shù)據(jù)共享，這樣的話更容易推測出究竟是發(fā)生了什么。然而問題也隨之產(chǎn)生：除非你手動的在某個終端上儲存，否則你將無法訪問計算的結(jié)果。Caffeine大大提升了google搜索速度。在原有的系統(tǒng)中，Google公司每天爬數(shù)以億萬計的文檔，把它們和現(xiàn)有文檔的集合一起經(jīng)過約100次MapReduce工序進(jìn)行處理。由于系統(tǒng)是順序的，每個文檔都要花2到3天來索引才能出現(xiàn)在google的在線搜索結(jié)果中。Percolator提供對現(xiàn)有的PB級索引數(shù)據(jù)的隨機(jī)訪問，讓google可以更新索引而不需要重新處理所有數(shù)據(jù)，通過這種方式減少了這個延遲?！半S機(jī)訪問讓我們可以處理單個文檔，而不是像MapReduce那樣需要對整個數(shù)據(jù)倉庫進(jìn)行掃描?！闭撐闹姓f道。該系統(tǒng)運(yùn)行于海量計算機(jī)上，通過被稱作ACID兼容數(shù)據(jù)庫事務(wù)的方式，并行的對索引進(jìn)行大量修改。3.2、Pregel：可擴(kuò)展的圖計算公布時間：2010年。最終Google還需要挖掘圖數(shù)據(jù)，比如在線社交網(wǎng)絡(luò)的社交圖譜；所以他們開發(fā)了Pregel，并在2010年公布其論文。Pregel是一個用于分布式圖計算的計算框架主要用于圖遍歷(BFS)、最短路徑(SSSP)、PageRank計算等等。共享內(nèi)存的運(yùn)行庫有很多但是對于google來說一臺機(jī)器早已經(jīng)放不下需要計算的數(shù)據(jù)了所以需要分布式的這樣一個計算環(huán)境。沒有Pregel之前用MapReduce來做,但是效率很低;也可以用已有的并行圖算法庫ParallelBGL或者CGMgraph來做,但是這兩者又沒有容錯。Pregel內(nèi)在的計算模型比MapReduce復(fù)雜的多：基本上每個節(jié)點(diǎn)都擁有一個工作者線程，并且對眾多工作者線程進(jìn)行迭代并行。在每一個所謂的“superstep”中，每一個工作者線程都可以從節(jié)點(diǎn)的“收件夾”中讀取消息和把消息發(fā)送給其它節(jié)點(diǎn)，設(shè)置和讀取節(jié)點(diǎn)相關(guān)值以及邊界，或者投票停止。線程會一直運(yùn)行，直到所有的節(jié)點(diǎn)都被投票停止。此外，還擁有Aggregator和Combiner做全局統(tǒng)計。論文陳述了許多算法的實(shí)現(xiàn)，比如Google的PageRank、最短路徑、二分圖匹配等。對比MapReduce或SPF，Pregel需要更多實(shí)現(xiàn)的再思考。3.3、Dremel：在線可視化公布時間：2010年。面對海量數(shù)據(jù)的分析處理，MapReduce的優(yōu)勢不需多言，其劣勢在于時效性較差不滿足交互式查詢的需求，比如3秒內(nèi)完成對萬億數(shù)據(jù)的一次查詢等，Dremel應(yīng)此需求而生，與MapReduce成為有效互補(bǔ)。Dremel是一個為結(jié)構(gòu)化數(shù)據(jù)設(shè)計，并擁有類SQL語言的交互式數(shù)據(jù)庫。然而取代SQL數(shù)據(jù)庫使用字段填補(bǔ)的表格，Dremel中使用的是類JSON格式數(shù)據(jù)（更準(zhǔn)確的說，使用Google

Protocolbuffer格式，這將加強(qiáng)對允許字段的限制）。內(nèi)部，數(shù)據(jù)被使用特殊格式儲存，可以讓數(shù)據(jù)掃描工作來的更高效。查詢被送往服務(wù)器，而優(yōu)秀的格式可以最大性能的輸出結(jié)果。這篇論文描述了一個叫做Dremel的系統(tǒng)，它支持在普通PC組成的共享集群上對超大規(guī)模的數(shù)據(jù)集合執(zhí)行交互式查詢。不像傳統(tǒng)的數(shù)據(jù)庫，它能夠操作原位嵌套數(shù)據(jù)。原位意味著在適當(dāng)?shù)奈恢迷L問數(shù)據(jù)的能力，比如，在一個分布式文件系統(tǒng)（比如GFS或者其他存儲層（比如Bigtable）。查詢這些數(shù)據(jù)一般需要一系列的MapReduce任務(wù)，而Dremel可以同時執(zhí)行很多，而且執(zhí)行時間比MapReduce小得多。Dremel不是為了成為MapReduce的替代品，而是經(jīng)常與它協(xié)同使用來分析MapReduce管道的輸出或者創(chuàng)建大規(guī)模計算的原型系統(tǒng)。Dremel自從2006就投入生產(chǎn)了并且在Google有幾千用戶。多種多樣Dremel的實(shí)例被部署在公司里，排列著成千上萬個節(jié)點(diǎn)。使用此系統(tǒng)的例子包括：分析網(wǎng)絡(luò)文檔追蹤Android市場應(yīng)用程序的安裝數(shù)據(jù)Google產(chǎn)品的崩潰報告分析GoogleBooks的OCR結(jié)果垃圾郵件分析GoogleMaps里地圖部件調(diào)試托管Bigtable實(shí)例中的Tablet遷移Google分布式構(gòu)建系統(tǒng)中的測試結(jié)果分析成百上千的硬盤的磁盤IO統(tǒng)計信息Google數(shù)據(jù)中心上運(yùn)行的任務(wù)的資源監(jiān)控Google代碼庫的符號和依賴關(guān)系分析Dremel基于互聯(lián)網(wǎng)搜索和并行DBMS的概念。首先，它的架構(gòu)借鑒了用在分布式搜索引擎中的服務(wù)樹概念。就像一個web搜索請求一樣，查詢請求被推入此樹、在每個步驟被重寫。通過聚合從下層樹節(jié)點(diǎn)中收到的回復(fù)，不斷裝配查詢的最終結(jié)果。其次，Dremel提供了一個高級、類SQL的語言來表達(dá)ad-hoc查詢。與Pig和Hive不同，它使用自己技術(shù)執(zhí)行查詢，而不是翻譯為MapReduce任務(wù)。最后也是最重要的，Dremel使用了一個column-striped的存儲結(jié)構(gòu)，使得它能夠從二級存儲中讀取較少數(shù)據(jù)并且通過更廉價的壓縮減少CPU消耗。列存儲曾被采用來分析關(guān)系型數(shù)據(jù)，但是據(jù)我們了解還沒有推廣到嵌套數(shù)據(jù)模型上。我們所展現(xiàn)的列狀存儲格式在Google已經(jīng)有很多數(shù)據(jù)處理工具支持，包括MapReduce、Sawzall、以及FlumeJava。關(guān)于Dremel的效率：論文中描述如下：Dremel每個月掃描千之五次方條記錄。我們采樣了某個月的查詢記錄，統(tǒng)計出耗時分布曲線。如圖15所示，大部分查詢低于10秒，在交互型查詢的耗時容忍范圍內(nèi)。一些查詢會在共享集群上執(zhí)行接近于100billion條記錄每秒的全量掃描，在專用機(jī)器上這個值還要更高。通過對上述實(shí)驗(yàn)數(shù)據(jù)進(jìn)行觀察，我們可以得到如下結(jié)論：我們可以在磁盤常駐的數(shù)據(jù)集合上對萬億級記錄執(zhí)行基于掃描的查詢，并達(dá)到交互式速度。在幾千個節(jié)點(diǎn)范圍內(nèi)，列數(shù)量和服務(wù)器數(shù)量的可伸縮性、可擴(kuò)展性是接近線性的。MapReduce也可以從列狀存儲中得益，就像一個DBMS。記錄裝配和解析是昂貴的。軟件層（在查詢處理層之上）最好被優(yōu)化，能夠直接消費(fèi)面向列的數(shù)據(jù)MapReduce和查詢處理可以互為補(bǔ)充；一個層的輸出能作為另一個的輸入。在一個多用戶環(huán)境，規(guī)模較大的系統(tǒng)能得益于高性價比的可伸縮能力，而且本質(zhì)上改善用戶體驗(yàn)。如果能接受細(xì)微的精度損失，查詢速度可以更快?；ヂ?lián)網(wǎng)級別的海量數(shù)據(jù)集合可以做到很快速的掃描，但想要花費(fèi)更少的時間則很困難。Dremel的代碼庫包含少于100K行的C++Java和Python代碼hadoop和Dremel對比：Dremel是個數(shù)據(jù)分析工具，經(jīng)專門設(shè)計用于完成大規(guī)模查詢結(jié)構(gòu)化數(shù)據(jù)集（如日志和事件文件）。它支持類SQL語法，區(qū)別在于它是只讀的。不支持修改或者建立功能，也沒有表索引。數(shù)據(jù)被列式存儲，這樣有助于提升查詢的速度。Google的BigQuery就是Dremel通過RESTfulAPI的一種實(shí)現(xiàn)。Hadoop（MapReduce的一種開源實(shí)現(xiàn)）集合了“Hive”數(shù)據(jù)倉庫軟件，同樣允許使用SQL語句對大量的數(shù)據(jù)集進(jìn)行數(shù)據(jù)分析。Hive本質(zhì)上是把查詢轉(zhuǎn)換成MapReduce運(yùn)算。對比使用ColumIO格式，Hive則是使用表索引的思想去優(yōu)化查詢。Hadoop更多的則是用于批處理，這就意味著數(shù)據(jù)是運(yùn)行在你已經(jīng)擁有的數(shù)據(jù)集上。有數(shù)據(jù)流入時，流引擎會進(jìn)行處理?！傲鳌焙汀皩?shí)時”通常被互換使用，這也是導(dǎo)致Dremel和Drill混淆的原因，通常都會把它們歸類成延時。值得注意的是Google只是打算將Dremel作為MapReduce的一種補(bǔ)充，而不是替換。通過論文也可以得知，Dremel被頻繁的用于分析MapReduce的結(jié)果或者是作為大規(guī)模計算的測試。Dremel可以做那些通常需要一系列MapReduce才可以完成的查詢，但是花費(fèi)的時間只是使用MapReduce的一小部分。如前所述，Dremel從速度上完全超越MapReduce。GoogleDremel和ApacheDrill對比:ApacheDrill更像是GoogleDrill的開原版本。OpenDremel，另一個創(chuàng)建Dremel開源版本的項(xiàng)目。當(dāng)然還有一些其他支持大數(shù)據(jù)快速查詢的項(xiàng)目，比如：ApacheCouchDB和Cloudant的演變版本BigCouch。除了Drill外，還有其他一些大數(shù)據(jù)分析工具和技術(shù)1.Storm——Backtype開發(fā)并被Twitter開源。2.ApacheS4——Yahoo！開源。而流引擎就是這些實(shí)時大數(shù)據(jù)處理系統(tǒng)（比如Storm和S4）與Dremel的最大區(qū)別，當(dāng)然Dremel是專門針對查詢設(shè)計。四、總結(jié)目前國內(nèi)提起大數(shù)據(jù)就不能不說Hadoop，而Hadoop的火爆要得益于Goo