如今,Hadoop已經(jīng)成為了大數(shù)據(jù)的代名詞,無處不在。在短短的幾年中,Hadoop從一種邊緣技術(shù)成為一種事實(shí)上的標(biāo)準(zhǔn)。你若想成為大數(shù)據(jù)分析師或商業(yè)智能分析師,那你必須對Hadoop了如指掌才可以。
毫無疑問,Hadoop作為大數(shù)據(jù)的標(biāo)準(zhǔn)分析工具已深深地植根于企業(yè),至少在未來10年它的地位都不會被動搖。但Hadoop真如表面上那樣前途無量嗎?企業(yè)是否正在購買或使用一項(xiàng)“日落西山”技術(shù),只是“夕陽無限好”?
Google文件系統(tǒng)和Google MapReduce
Hadoop的出現(xiàn)是受到最先由 Google Lab 開發(fā)的 Map/Reduce 和 Google File System(GFS) 啟發(fā)。2006 年 3 月份,Map/Reduce 和 Nutch Distributed File System (NDFS) 分別被納入稱為 Hadoop 的項(xiàng)目中。面對數(shù)據(jù)大爆炸時代的到來,谷歌的兩位工程師Jeff Dean and Sanjay Ghemawat設(shè)計(jì)并發(fā)布了兩個開創(chuàng)性的系統(tǒng):谷歌文件系統(tǒng)(GFS)和谷歌的MapReduce(GMR)。前者是一個可擴(kuò)展的分布式文件系統(tǒng),用于大型的、分布式的、對大量數(shù)據(jù)進(jìn)行訪問的應(yīng)用,運(yùn)行于廉價的普通硬件上,但可以提供容錯功能,可以給大量的用戶提供總體性能較高的服務(wù);后者用于大規(guī)模數(shù)據(jù)集(大于1TB)的并行運(yùn)算。
GMR的特色在于極大的方便了谷歌編程人員在不會分布式并行編程的情況下,將自己的程序運(yùn)行在分布式系統(tǒng)上,并提高速度和容錯能力。簡而言之,GMR按比例將數(shù)據(jù)規(guī)??s小,在兼顧所有數(shù)據(jù)的同時突出關(guān)鍵性數(shù)據(jù)。GFS和GMR逐漸成為處理器引擎的核心技術(shù),用來抓取和分析數(shù)據(jù)、進(jìn)行網(wǎng)頁排序等,這些我們在Google.com日常搜索中都使用過。這顯然是谷歌的一個主要優(yōu)勢。
由Hadoop分布式文件系統(tǒng)和Hadoop MapReduce組成的Apache Dadoop源于GFS和GMR的設(shè)計(jì)思路。Hadoop確實(shí)已經(jīng)演變成一個生態(tài)系統(tǒng),它幾乎可以應(yīng)對所有的數(shù)據(jù)管理和數(shù)據(jù)處理。但是,Hadoop的核心仍然是MapReduce系統(tǒng)。你寫的代碼最終都會變成映射(Map)和化簡(Reduce),Hadoop為你運(yùn)行這些代碼。
谷歌發(fā)力,hadoop何去何從?
然而,最有趣的是,GMR不再允許這樣卓越的東西存在于Google Stack中。正如企業(yè)正在鎖定MapReduce一樣,谷歌似乎正在舍棄它而大步向前。事實(shí)上,接下來本文討論的許多技術(shù)都不是新出現(xiàn)的,這些技術(shù)可以追溯到過去的5-10年,GMR文章出現(xiàn)的幾年后。
我希望以下這些技術(shù)能支撐后Hadoop時代。盡管許多Apache項(xiàng)目和商業(yè)Hadoop機(jī)構(gòu)都在積極努力的通過各種技術(shù)如HBase、Hive和下一代MapReduce(aka YARN)來解決一些問題,但在我看來,這需要新的、基于non-MapReduce的架構(gòu)做Hadoop的核心(HDFS和Zookeeper)才能與谷歌做真正的技術(shù)較量。
為增量索引而生的Percolator和頻率分析正在改變數(shù)據(jù)集。Hadoop是一個大機(jī)器。一旦你將它開啟并加速,它那非常擅長挖掘數(shù)據(jù)的功能就能展現(xiàn)出來,你的磁盤將以盡可能快的速度轉(zhuǎn)動。然而,每次你要分析數(shù)據(jù)(比如添加,修改或刪除數(shù)據(jù)后),你必須重新梳理整個數(shù)據(jù)集。如果你的數(shù)據(jù)集總是在擴(kuò)大,這意味著你的分析時間也在無限制的延長。
那么,谷歌是如何實(shí)現(xiàn)實(shí)時結(jié)果搜索呢?是通過一個名叫Percolator的增量處理引擎取代了GMR。通過只處理新增的、修改過或刪除的文件和使用輔助指標(biāo)有效地編目和查詢結(jié)果輸出,谷歌才得以大幅降低搜索結(jié)果輸出時間。Percolator論文的作者寫道,“將索引系統(tǒng)轉(zhuǎn)換為增量系統(tǒng)后,文件處理的平均時間延遲減少了100倍。”這意味著,與使用MapReduce系統(tǒng)相比,互聯(lián)網(wǎng)上的新增內(nèi)容被搜索到的時間快了100倍。
為特殊分析而生的Dremel。Google和Hadoop生態(tài)系統(tǒng)的相關(guān)機(jī)構(gòu)都在非常努力使MapReduce成為一個可用的特色分析工具。從Sawzall到Pig和Hive,許多界面層已建成。然而,他們都忽視了一個基本的現(xiàn)實(shí) —MapReduce是針對處理結(jié)構(gòu)化數(shù)據(jù)建立的。它誕生于工作流的核心需求,而非非結(jié)構(gòu)化數(shù)據(jù)的大爆炸。
與之形成鮮明對比的是,許多BI /分析查詢是基于非結(jié)構(gòu)化、互動、低延遲的分析。映射(Map)和化簡(Reduce)工作流程不僅讓許多分析師望而卻步,而且這種工作流程也不利于互動式體驗(yàn)。因此,谷歌發(fā)明了Dremel(現(xiàn)在作為BigQuery呈現(xiàn)),專門為分析師在瀏覽PB級數(shù)據(jù),應(yīng)對及時響應(yīng)特殊查詢、預(yù)測和強(qiáng)大的可視化需求而建立的工具。
谷歌的BigQuery
谷歌的DREMEL文章指出,這是“能夠運(yùn)行超過萬億秒的行聚集查詢”,文章同時指出,運(yùn)行相同的需求,標(biāo)準(zhǔn)的MapReduce比DREMEL慢了約100倍。然而,最令人印象深刻的是谷歌產(chǎn)品系統(tǒng)所產(chǎn)生數(shù)據(jù),DREMEL用不到10秒的時間即可完成查詢?nèi)蝿?wù),甚至比開始執(zhí)行一個MapReduce的工作流程及其相關(guān)工作的典型延遲時間還要短。
為分析圖表數(shù)據(jù)而生的Pregel。谷歌MapReduce建立的目的是抓取和分析世界上最大的圖形數(shù)據(jù)結(jié)構(gòu)—互聯(lián)網(wǎng)。然而,MapReduce的一些核心假設(shè)是基本由人、電信設(shè)備、文件和其他圖標(biāo)數(shù)據(jù)組成的網(wǎng)絡(luò)結(jié)構(gòu)的基本概率。例如,若果要通過圖表計(jì)算單源最短路徑(SSSP)的話,需要復(fù)制圖表到MapReduce,這種做法效率非常低。
因此,谷歌建立了Pregel—在分布式的普通硬件上同步處理PB級規(guī)模的應(yīng)用。結(jié)果令人印象深刻。與Hadoop對比,Hadoop在圖形處理時往往導(dǎo)致指數(shù)數(shù)據(jù)放大,Pregel卻能夠順利且有效地在極短的時間內(nèi)執(zhí)行諸如SSSP或PageRank的圖算法,而且代碼并不復(fù)雜
雖然,Hadoop是一個用普通硬件處理大規(guī)模數(shù)據(jù)集群的非常棒的工具。但如果你想處理動態(tài)數(shù)據(jù)集,非結(jié)構(gòu)化數(shù)據(jù)或圖形數(shù)據(jù)結(jié)構(gòu),谷歌自己的行動清楚地表明了MapReduce模式的替代品—Percolator、Dremel 和Pregel組成了大數(shù)據(jù)時代一曲非常美妙的三重奏。如果它們對IT產(chǎn)生的影響不能與GFS、GMR和GigTable相媲美,那才會人感到震驚。
原文作者:Mike Miller 來源:GigaOM