後Hadoop時代的Google三駕馬車

         Google在2003年到2004年公佈了關於GFS、MapReduce和BigTable三篇技術論文,成爲後來雲計算髮展的重要基石。如今,Google的Caffeine、Pregel、Dremel或將再次影響着全球大數據發展的技術潮流。

GOOGLE搜索引擎Caffeine

  谷歌(GOOGLE)開發的新的搜索引擎代號爲“咖啡因

 

  網絡搜索服務巨頭谷歌公司的新一代搜索引擎已經上線,供使用者測試。據悉,該版本測試完成後將取代谷歌現有的搜索引擎。

 

  谷歌表示,新的引擎代號爲“咖啡因”,搜索速度是舊版本的兩倍,並且能提供更精確、更全面的搜索結果。

 

  新引擎有一個獨立的網址,雖然外觀同現有的谷歌引擎一樣,但谷歌表示,引擎的基本框架已經升級到了新版本。

 

  業界認爲,谷歌此舉顯然是感受到了微軟搜索引擎“必應”(BING)的壓力,試圖以此拉開與後者的距離。

 

  還有搜索引擎優化(SEO)人士表示,儘管更新架構會讓谷歌搜索更爲出色,但谷歌Caffeine將給網絡開發與SEO帶來相當大的衝擊。網絡上已經出現大量有關這一新架構的分析與猜測文章。

 

  谷歌Caffeine項目可能是微軟Bing發佈後搜索巨頭進行的最大一個項目。《紐約郵報》曾報道稱,谷歌聯席創始人塞吉布林對微軟Bing的發佈相當緊張,他已經召集了一隊人馬對自家的服務進行緊急升級。

 

  但谷歌發言人卻表示,Caffeine絕不是谷歌對Bing做出的反擊。新一代搜索引擎的計劃已經在公司內開展了相當長一段時間。


Caffeine索引技術

  索引對比

索引對比

  爲何要開發新型Caffeine索引技術?原因就是互聯網內容的規模每天都在增長。互聯網內容的增長並不僅僅體現在數量上面,而且還出現了視頻、圖片和實時更新等內容。與以往相比,目前平均每個網頁所含信息量比以前更爲豐富。此外,網民對搜索引擎性能的期望值比以前更高,他們希望能夠更及時查找到互聯網上剛剛發佈的內容。

 

  爲適應互聯網產業的向前演進以及滿足網民的需求,我們開發了Caffeine索引系統。我們老式索引採用了多層技術,而部分索引層的內容更新快於其他層面;主索引層通常是每隔數週更新一次。如果我們要更新其中的某個索引層,就是必須對整個互聯網進行分析。如此一來,網民所搜索到的結果,與互聯網的實際內容之間會有一個時間差。

 

  利用Caffeine技術,我們將互聯網劃分爲不同的部分,然後以連續狀態在全球範圍對不同部分內容加以升級。當我們發現了新內容,只需將這些新內容添加到當前索引當中。這就是說,你在使用谷歌搜索過程中,所獲得的結果與互聯網實際內容的時間差已經非常小。

 

  Caffeine技術可以使我們實現對網絡內容索引的規模化。事實上,Caffeine每秒鐘可同時處理數十萬個網頁。如果這些網頁是現實生活中的紙張,則這些紙張每秒鐘將堆成3英里高。Caffeine在一個數據庫中可處理近1億GB的存儲信息,且每天存儲信息量都在大幅增長。你需要使用62.5萬部容量最大的iPod音樂播放器才能存儲這些信息,如果將這些iPod並排放置,則可長達40英里。

 

  我們開發Caffeine技術,其實是着眼於互聯網產業的未來發展。Caffeine不僅僅提高了網絡索引的時效性,而且使我們希望組建性更強大的搜索引擎成爲可能,然後再向網民提供質量更好的搜索服務。請關注Caffeine的發展,今後數月內,我們將對Caffeine技術加以進一步完善和改進。

 

Pregel學習筆記

  Pregel是Google的一個分佈式圖計算的編程框架,是繼MapReduce之後又一大分佈式計算的利器,主要是爲了便於在大規模圖數據的情況下實現各種圖算法。據說在Google有20%的計算任務由Pregel來完成。Pregel最初在SIGMOD2010上公開發表,題爲《Pregel:A System for Large-Scale Graph Processing》。由於課程要求LZ便去拜讀了一下。

  Pregel是一個stateful model(姑且叫做狀態模型吧),它維護着圖中每個頂點的狀態,每個頂點的狀態包括該頂點自身的值,由它出發的有向邊的值和有向邊的destination,以及該頂點的活動標記(是否爲活動狀態),因此這是一個以頂點爲中心的編程框架。它的計算過程是由一系列supersteps組成,在每一輪supersteps中,Pregel調用用戶自定義的函數compute()來對每一個頂點進行計算,每一個頂點的計算過程如下:接收其他頂點(可能相鄰或不相鄰)發送給它的消息,執行自定義的compute()函數從而改變自身的值和從它出發的邊(也有可能改變圖拓撲結構)以及向其他節點發送消息。當在某一輪supersteps中它的值不變時便標記爲inactive,處於inactive狀態下的頂點在收到消息時重新變爲active,Pregel不會對inactive狀態下的頂點調用計算函數compute(),因此當所有節點都處於inactive,並且沒有消息在傳送中時計算結束。下圖爲作者在論文中舉得一個例子,目的是要將所有節點的值改爲這些節點中的最大值,其中comupute()函數定義爲向相鄰節點發送本節點的值,用灰色標記的節點表明已經處於inactive狀態。

      

  Pregel的設計就是爲了使完成處理大規模圖數據的處理(如PageRank,最短路徑)更加簡單,因此它的API接口十分的簡單,主要就是繼承Vertex類(其定義如下圖),重寫其中的compute()方法(即用戶自定義的頂點的處理函數,參數msgs表示其他頂點發送給它的消息。此外爲了節省消息在不同的物理機器之間傳遞的開銷以及消息所佔空間,Pregel提供了Combiners接口,用於消息的提前處理。爲了提供一些全集信息,Pregel提供了Aggragators接口來彙總各個頂點提交上來的信息。

  Pregel運行在Google的集羣環境中。首先有個master,管理所有的workers,每個worker完成一部分頂點的計算任務(頂點的劃分任然是個未很好解決的問題),master同步所有worker的計算,當所有worker完成一步supersteps之後master纔會命令workers進入下一步supersteps計算。在這樣的分佈式計算環境中,出錯是難免的,因此Pegel提供了容錯機制,可以將中斷的任務繼續執行,所用的方法是在每一步supersteps之前將所有頂點的狀態備份。

  利用Pregel可以完成很多圖上面的計算任務,下圖是一個利用pregel來完成pagerank的例子,發送的消息的值爲發送節點的當前pagerank的值除以該節點的outdegree。程序中只循環計算了30次(實際情況中當所有節點都inactive時終止計算)

  作者的實驗結果表明Pregel對圖數據的規模和workers的數量都具有很好的scalibility,適合稀疏圖數據的處理。

 

Google Dremel設計
 
簡介

Dremel 是Google 的“交互式”數據分析系統。可以組建成規模上千的集羣,處理PB級別的數據。MapReduce處理一個數據,需要分鐘級的時間。作爲MapReduce的發起人,Google開發了Dremel將處理時間縮短到秒級,作爲MapReduce的有力補充。Dremel作爲Google BigQuery的report引擎,獲得了很大的成功。最近Apache計劃推出Dremel的開源實現Drill,將Dremel的技術又推到了浪尖上。

 

根據Google公開的論文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的設計原理。還有一些測試報告。論文寫於2006年,公開於2010年,Google在處理大數據方面,果真有得天獨厚的優勢。下面的內容,很大部分來自這篇論文。

隨着Hadoop的流行,大規模的數據分析系統已經越來越普及。數據分析師需要一個能將數據“玩轉”的交互式系統。如此,就可以非常方便快捷的瀏覽數據,建立分析模型。Dremel系統有下面幾個主要的特點:

  • Dremel是一個大規模系統。在一個PB級別的數據集上面,將任務縮短到秒級,無疑需要大量的併發。磁盤的順序讀速度在100MB/S上下,那麼在1S內處理1TB數據,意味着至少需要有1萬個磁盤的併發讀! Google一向是用廉價機器辦大事的好手。但是機器越多,出問題概率越大,如此大的集羣規模,需要有足夠的容錯考慮,保證整個分析的速度不被集羣中的個別慢(壞)節點影響。
  • Dremel是MR交互式查詢能力不足的補充。和MapReduce一樣,Dremel也需要和數據運行在一起,將計算移動到數據上面。所以它需要GFS這樣的文件系統作爲存儲層。在設計之初,Dremel並非是MapReduce的替代品,它只是可以執行非常快的分析,在使用的時候,常常用它來處理MapReduce的結果集或者用來建立分析原型。
  • Dremel的數據模型是嵌套(nested)的。互聯網數據常常是非關係型的。Dremel還需要有一個靈活的數據模型,這個數據模型至關重要。Dremel支持一個嵌套(nested)的數據模型,類似於Json。而傳統的關係模型,由於不可避免的有大量的Join操作,在處理如此大規模的數據的時候,往往是有心無力的。
  • Dremel中的數據是用列式存儲的。使用列式存儲,分析的時候,可以只掃描需要的那部分數據的時候,減少CPU和磁盤的訪問量。同時列式存儲是壓縮友好的,使用壓縮,可以綜合CPU和磁盤,發揮最大的效能。對於關係型數據,如果使用列式存儲,我們都很有經驗。但是對於嵌套(nested)的結構,Dremel也可以用列存儲,非常值得我們學習。
  • Dremel結合了Web搜索 和並行DBMS的技術。首先,他借鑑了Web搜索中的“查詢樹”的概念,將一個相對巨大複雜的查詢,分割成較小較簡單的查詢。大事化小,小事化了,能併發的在大量節點上跑。其次,和並行DBMS類似,Dremel可以提供了一個SQL-like的接口,就像Hive和Pig那樣。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章