Hadoop的輝煌還能延續多久?

2021-06-28 21:32:31 字數 3331 閱讀 7940



hadoop技術已經無處不在。不管是好是壞,hadoop已經成為大資料的代名詞。短短幾年間,hadoop從一種邊緣技術成為事實上的標準。看來,不僅現在hadoop是企業大資料的標準,而且在未來,它的地位似乎一時難以動搖。

谷歌檔案系統與mapreduce

我們先來**一下hadoop的靈魂——mapreduce。面對資料的**性增長,谷歌的工程師jeff dean和sanjay ghemawat架構並發布了兩個開創性的系統:谷歌檔案系統(gfs)和谷歌mapreduce(gmr)。前者是乙個出色而實用的解決方案-使用常規的硬體擴充套件並管理資料,後者同樣輝煌,造就了乙個適用於大規模並行處理的計算框架。

谷歌mapreduce(gmr)為普通開發者/使用者進行大資料處理提供了簡易的方式,並使之快速、具備容錯性。谷歌檔案系統(gfs)和谷歌mapreduce(gmr)也為谷歌搜尋引擎對網頁進行抓取、分析提供了核心動力。

再回頭看看開源世界中的hadoop,apache hadoop的分布式檔案系統(hdfs)和hadoop mapreduce完全是谷歌檔案系統(gfs)和谷歌mapreduce(gmr)的開源實現。hadoop專案已經發展成為乙個生態系統,並觸及了大資料領域的方方面面。但從根本上,它的核心是mapreduce。

hadoop是否可以趕超谷歌?

乙個有趣的現象是,mapreduce在谷歌已不再顯赫。當企業矚目mapreduce的時候,谷歌好像早已進入到了下乙個時代。事實上,我們談論的這些技術早就不是新技術了,mapreduce也不例外。

我希望在後hadoop時代下面這些技術能夠更具競爭性。儘管許多apache社群的專案和商業化hadoop專案都非常活躍,並以來自hbase、hive和下一代mapreduce(yarn)的技術不斷完善著hadoop體系,我依然認為,hadoop核心(hdfs和zookeeper)需要脫離mapreduce並以全新的架構增強自己的競爭力,真正與谷歌技術一較高下。

過濾不斷增長的索引,分析不斷變化的資料集。hadoop的偉大之處在於,它一旦開始執行,就會飛速地分析你的資料。儘管如此,在每次分析資料之前,即新增、更改或刪除資料之後,我們都必須將整個資料集進行流式處理。這意味著,隨著資料集的膨脹,分析時間也會隨之增加,且不可預期。

那麼,谷歌又是怎麼做到搜尋結果越來越實時呈現呢?乙個名為percolator的增量處理引擎取代了谷歌mapreduce(gmr)。通過對新建、更改和已刪除文件的處理,並使用二級索引進行高效的分類、查詢,谷歌能夠顯著地降低實現其目標的時間。

percolator的作者寫道:「將索引系統轉化為乙個增量系統……文件平均處理延遲的因子降低到了現在的100。」這句話的意思是,索引web上新內容的速度比之前mapreduce系統快了100倍。

谷歌dremel即時資料分析解決方案

谷歌和hadoop社群曾致力於構建基於mapreduce的易用性即時資料分析工具,如谷歌的並行處理語言sawzall,apache pig和hive。但對熟知sql的人們而言,他們忽略了乙個基本事實-構建mapreduce的目標就在於管理資料處理工作。它的核心能力在於工作流管理,而不是即時資料分析。

與之形成鮮明對比的是,很多bi或資料分析查詢基本上都要求即時、互動和低延遲。這意味著,使用hadoop不僅需要規劃流程圖,而且需要為許多查詢分析裁減不必要的工作流。即便如此,我們也要花費數分鐘等待工作開始,然後花費數小時等待工作流完成,並且這個過程也非常不利於互動式體驗。因此,谷歌研發了dremel予以應對。dremel是google 的「互動式」資料分析系統,可以在幾秒鐘內處理pb級別的資料,並能輕鬆應對即時查詢。

google dremel的設計特點:

dremel是乙個可擴充套件的大型系統。在乙個pb級別的資料集上面,將任務縮短到秒級,無疑需要大量的併發。磁碟的順序讀速度在100mb/s上下,那麼在1s內處理1tb資料,意味著至少需要有1萬個磁碟的併發讀! google一向是用廉價機器辦大事的好手。但是機器越多,出問題概率越大,如此大的集群規模,需要有足夠的容錯考慮,保證整個分析的速度不被集群中的個別節點影響。 

dremel是mapreduce的補充。和mapreduce一樣,dremel也需要gfs這樣的檔案系統作為儲存層。在設計之初,dremel並非是mapreduce的替代品,它只是可以執行非常快的分析,在使用的時候,常常用它來處理mapreduce的結果集或者用來建立分析原型。 

dremel的資料模型是巢狀的。網際網路資料常常是非關係型的。dremel還需要有乙個靈活的資料模型,這個資料模型至關重要。dremel支援乙個巢狀的資料模型,類似於json。而傳統的關係模型,由於不可避免的有大量的join操作,在處理如此大規模的資料的時候,往往是有心無力的。

dremel中的資料是採用列式儲存的。使用列式儲存,分析的時候,可以只掃瞄需要的那部分資料的時候,減少cpu和磁碟的訪問量。同時列式儲存是壓縮友好的,使用壓縮,可以綜合cpu和磁碟,發揮最大的效能。

dremel結合了web搜尋和並行dbms的技術。dremel借鑑了web搜尋中的「查詢樹」的概念,將乙個相對巨大複雜的查詢,分割成較小較簡單的查詢。大事化小,小事化了,能併發的在大量節點上跑。另外,和並行dbms類似,dremel可以提供了乙個sql-like的介面,就像hive和pig那樣。

谷歌的圖資料計算框架pregel

谷歌mapreduce是專門為抓取、分析世界上最龐大的圖形架構-internet而設計的,但針對大規模圖演算法(如圖遍歷(bfs)、pagerank,最短路徑(sssp)等)的計算則顯得效率低下。因此,谷歌構建了pregel。

pregel給人的印象非常深刻。pregel不僅能高效執行sssp或pagerank演算法,更令人驚訝的是,公布的資料顯示pregel處理乙個有著幾十億節點、上萬億條邊的圖,只需數分鐘即可完成,其執行時間隨著圖的大小呈線性增長。

pregel基於bsp模型,就是「計算」-「通訊」-「同步」的模式:

在pregel中,以節點為中心計算。step 0時每節點都活動著,每個節點主動「給停止投票」進入不活動狀態。如果接收到訊息,則啟用。沒有活動節點和訊息時,整個演算法結束。容錯是通過檢查點來做的。在每個超步開始的時候,對主從節點分別備份。

總結

儘管當前大資料技術的核心依然是hadoop,但谷歌卻已經為我們展現了許多更先進的大資料技術。谷歌開發這些技術的本意並不是要立刻拋棄掉mapreduce,但毫無疑問這是未來大資料技術的趨勢。儘管已經出現了上述大資料技術的開源實現,但我們不禁要問,hadoop的輝煌還能延續多久?(張志平/編譯)

Hadoop的輝煌還能延續多久?

hadoop技術已經無處不在。不管是好是壞,hadoop已經成為大資料的代名詞。短短幾年間,hadoop從一種邊緣技術成為事實上的標準。看來,不僅現在hadoop是企業大資料的標準,而且在未來,它的地位似乎一時難以動搖。谷歌檔案系統與mapreduce 我們先來 一下hadoop的靈魂 mapred...

Hadoop的輝煌還能延續多久?

hadoop技術已經無處不在。不管是好是壞,hadoop已經成為大資料的代名詞。短短幾年間,hadoop從一種邊緣技術成為事實上的標準。看來,不僅現在hadoop是企業大資料的標準,而且在未來,它的地位似乎一時難以動搖。谷歌檔案系統與mapreduce 我們先來 一下hadoop的靈魂 mapred...

Hadoop的輝煌還能延續多久?

hadoop mapraduce dremel pregel google 大資料摘要 hadoop已經成為大資料的代名詞。短短幾年間,hadoop從一種邊緣技術成為事實上的標準。而另一方面,mapreduce在谷歌已不再顯赫。當企業矚目mapreduce的時候,谷歌好像早已進入到了下乙個時代。ha...