Google的體系架構

      Google是可伸縮性之王。每一個人都知道Google是由於他們對大量，複雜信息的快速搜索，可是Google的技術並不僅是在搜索領域閃閃發光。他們構建大型應用的平臺方式可以讓他們以驚人的競爭速度在網絡規模應用上面大展拳腳。Google的目標一直是構建更高性能更高規模基礎設施來支持他們的產品。他們怎麼作到的呢？

參考資料以及信息來源
    視頻：在Google上構建大型系統 (Video: Building Large Systems at Google)
    Google實驗室：Google文件系統 (Google Lab: The Google File System)
    Google實驗室：MapReduce：在大規模集羣上簡化數據處理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters)
    Google實驗室：BigTable: (Google Lab: BigTable.)
    視頻：BigTable: 一個分佈式的結構化存儲系統 (Video: BigTable: A Distributed Structured Storage System.)
    Google實驗室：鬆散耦合的分佈式系統的 Chubby Lock服務 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems.)
    Google是如何工做的 做者 David Carr發表於Baseline雜誌 (How Google Works by David Carr in Baseline Magazine.)
    Google實驗室：翻譯數據：使用Sawzall並行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall.)
    可伸縮性大會上Dare Obasonjo的筆記 (Dare Obasonjo's Notes on the scalability conference.)

1平臺
• Linux
• 多種不一樣的語言： Python, Java, C++

數據揭祕
目前的情形：
• 2006年估計有450,000個價格便宜的商用服務器
• 2005年Google索引了80億的web頁面。到如今爲止有多少，已經沒法統計出來了。
• 目前Google有超過200GFS的集羣。一個集羣能有1000甚至5000個機器。成百上千的機器從運行大到5peta字節存儲的GFS集羣檢索數據。經過集羣的總的讀寫吞吐量達到每秒400億字節。
• 目前在Google有6000個 MapReduce應用，而且每月有幾百個新的應用正在出現。

架構的層次
Google把他們的基礎設施架構描述爲三個層次棧：
• 產品：檢索，廣告，電子郵件，地圖，視頻，聊天，博客
• 分佈式系統基礎設施：GFS, MapReduce, 以及BigTable。
• 計算平臺：不少不一樣數據中心的不少機器
• 確保公司員工容易低成本配置。
• 看看每一個應用基線的價格性能數據。把更多的錢花在硬件上以期不丟失日誌數據，可是在其餘類型的數據上花少一點。既然這樣處理，實際上他們就不會丟數據。

使用GFS（Google文件系統）的可靠存儲機制
• 可靠的可伸縮存儲是任何應用的一個核心須要。GFS就是他們的核心存儲平臺。
• Google文件系統- 大的分佈式日誌結構化文件系統，裏面有大量數據
• 爲何不用其餘的而非要構建一個文件系統呢？由於他們須要控制全部的事情，而正是這個平臺把他們和其餘任何一個區分開來。他們須要：
- 經過數據中心的高可靠性
- 對於幾千個網絡節點的可伸縮性
- 大的讀寫帶寬需求
- 支持十億字節大的數據塊
- 高效的經過節點減小瓶頸的分佈式操做

• 系統有主服務器和分塊服務器（chunk servers）
- 主服務器在各類數據文件上保存元數據。數據以64MB大的塊存儲在文件系統中。客戶機和主服務器對話來操做文件裏的元數據，定位包含了磁盤上他們須要的數據的分塊服務器。
• 一個新的應用可使用一個已經存在的GFS集羣或者他們本身製做。去理解他們使用的經過數據中心的這個供應過程將是很是有趣的。
• 主鍵是足夠的基礎設施來確保人們對他們的應用有多種選擇。能夠調整GFS以適應我的應用須要。

使用MapReduce對數據作一些事情
• 既然你有了一個好的存儲系統，你怎樣使用如此多的數據呢？假如說你有不少TB的數據存儲在1000臺機器上。數據庫不能擴展或者有效地擴展到這樣的規模。這時就要用到MapReduce了。

• MapReduce是一個編程模型和用來處理和產生大規模數據集。用戶指定一個映射函數處理一個鍵/值對來產生中間的鍵/值對集合，還指定一個縮小函數來合併全部的與同一中間鍵相關的中間值。

  許多現實世界的任務在這個模型裏被表示出來。用這個函數風格寫的程序自動並行化而且在一大集羣商務機器上執行。運行時系統關心分割輸入數據的細節，經過一系列的機器安排程序的執行，處理機器事故，以及管理所需的機器內部通訊。這使得沒有任何並行和分佈式系統經驗的程序員可以容易地利用一個大的分佈式系統的資源。

• 爲何使用MapReduce呢？
- 在大量機器上分割任務的極佳方式
- 處理機器故障
- 在不一樣類型的應用上工做，如搜索和廣告。幾乎每一個應用都有映射簡化類型之類的操做。你能夠預計算有用的數據，統計字數，分類幾TB的數據，等等。
- 計算能夠自動地更加靠近IO源。

• MapReduce 系統有三個不一樣類型的服務器。
- 主服務器分配用戶任務以映射和減小服務器。它也跟蹤任務的狀態。
- 映射服務器接收用戶輸入，在它們上面實行映射操做。結果寫入中間文件。
- 化簡服務器接收由映射服務器產生的中間文件並在它們上面實行化簡操做。
• 例如，你想要統計全部網頁中字符的個數。你能夠把存儲在GFS中的頁面放入MapReduce。這些都將在1000秒內發生，包括機器同步和協調，任務安排，事故處理和數據傳輸將會自動完成。
- 步驟以下：GFS -> Map -> Shuffle -> Reduction -> 把結果存回GFS
- 在MapReduce 裏，一個映射把一個視圖映射到另外一個，產生一個鍵值對，在咱們的例子裏是單詞和數量。
- Shuffling 聚合鍵的類型
- 化簡把全部的鍵值對加起來產生最後的結果。
• Google索引管道有大概20個不一樣的映射化簡。一個管道把數據看作記錄的一個總體束和聚合鍵。第二個映射-化簡進來把那個結果拿走作其餘的一些事情。等等。
• 程序能夠很小。能夠小到20到50行的代碼。
• 一個問題是stragglers。Stragglers是一種比其餘都要慢的計算。Stragglers會發生是由於慢的IO（好比一個糟糕的控制器）或者從一個臨時的CPU尖峯信號。解決辦法是運行多個一樣的計算，當一個完成時就銷燬全部其餘的計算。
• 在映射和化簡之間轉換的數據被壓縮。這樣作是由於服務器不受CPU約束，花時間在數據的壓縮和解壓縮上仍是有意義的，能夠節省花在帶寬和I/O上的時間。
1
 
在BigTable中存儲結構化數據
• BigTable 是一個大型的容錯和自我管理系統，包括太（萬億）字節的內存和皮字節的內存。它每秒可以處理幾百萬的讀寫。
• BigTable是一個構建在GFS之上的分佈式散列機制。它不是一個關係數據庫。它不支持聯結或者SQL類型查詢。
• 它提供查找機制，能夠經過鍵來訪問結構化的數據。GFS存儲不透明數據和許多應用所需的結構化數據。
• 商業化數據不能伸縮到這個層次，它們不在1000個機器上工做。
• 經過控制它們本身的低層次存儲系統，Google獲得更多的控制和有力的工具來改進它們的系統。例如，若是它們想要使得分佈

數據操做更簡單的特徵，它們能夠在裏面構建。
• 當系統運行的時候，機器能夠增長和減小，而整個系統還會正常工做。
• 每一個數據條存儲在一個可使用行鍵，列鍵或者時間郵票訪問的單元中。
• 每行存儲在一個或者更多個tablet中。一個tablet是數據形式的64KB塊的序列叫作SSTable。
• BigTable 有三個不一樣類型的服務器：
- 主服務器分配tablet到tablet服務器中。它們跟蹤的位置，當須要時還會從新分配任務。
- Tablet 服務器處理tablet的讀寫請求。當tablet超過規模限制（一般是100MB - 200MB）時，它們將它分開。當一個tablet服務器出故障時，會有100個tablet服務器每一個撿起一個新的tablet，因此係統就恢復了。
• 一個位置組能夠被用做與幾比特的數據相關的物理存儲，爲了有一個更好的參考位置。
• Tablets儘量在RAM裏被緩存。

 
硬件
• 當你有不少個機器時，你如何構建它們以使花費代價最小電能消耗最少呢？
• 使用超便宜的商業硬件，拼命利用它們在上面構建軟件。
• 增長 1,000-fold 計算機電力，若是你使用容易出事故的基礎設施而不是構建在高度可靠的部件之上的基礎設施時，能夠有33倍更低的花費。你必須使用這一策略在不可靠之上構建可靠。
• Linux，內部的架構設計，PC類主機板，低端存儲。
• 性能基線中每瓦的價格沒有愈來愈好。存在着不少的電力和其餘問題。
• 使用混合收集和它們本身的數據中心。

雜類
• 很快找出改變而不是等着提問和回答。
• 庫是構建程序的主要方式。
• 一些是以服務的形式提供的應用，好比crawling。
• 基礎設施處理應用程序的版本，因此它們就可以發佈，不用擔憂破壞事情。

Google將來的方向
• 支持地理位置分佈的集羣
• 爲全部的數據建立單一的全局名字空間。當前數據由集羣分離開的。
• 更多更好的數據和計算的自動化遷移。
• 解決當你用網絡分割耦合大範圍的複製時產生的一致性問題（例如，即便一個集羣已經由於維修或是其餘一些臨時停電等緣由而下線時，還能繼續提供服務）
 
Goolge告訴咱們的經驗
• 基礎設施是一個頗有競爭性的優點。它固然是屬於Google的。它們能更快更便宜地提供和生產新的網絡服務，這在必定程度上是無人能比的。許多公司採起了徹底不一樣的方式。許多公司把基礎設施看作一種花銷。每一個組將使用徹底不一樣的技術，並且他們不多有計劃如何更經濟地構建系統。Google把他們本身看作一個系統工程公司，以一個很是新的方式來看待構建軟件。

• 跨越多個數據中心還是一個未解決的問題。大多數網站是一個至可能是兩個數據中心。如何在大量數據中心上充分分配網站，咱們說，很是複雜。

• 看一看Hadoop (產品)若是你沒有時間來從頭開始構建全部這個基礎設施的話。Hadoop 是一個這裏講的一些主意的開源實現。
• 一個平臺方式被忽略的優勢是初級開發人員能夠在平臺上很快自信地構建健壯的應用。若是每一個項目須要建立一樣的分佈式基礎設施輪，你將會陷入困境，由於知道如何這樣作的人員相對稀少。

• 協同工做並不老是廢話。經過使系統中全部部件一塊兒工做，一個改進會有助於全部的改進。改善文件系統，每一個人都會馬上明顯受益。若是每一個項目使用一個不一樣的文件系統，那麼就沒有整個展的持續的改進。

• 構建不須要下降系統性能的自我管理系統。這可讓你更容易地平衡各服務器的資源，動態增長更多空間，容許機器下線，以及更從容地處理升級。

• 建立一個進化式基礎設施。花時間在並行處理上會有回報的。
• 不要忽視了學院。學術界有不少好的創意並無轉入生產環境裏。Google所作的大部分先於藝術，不僅是先於大規模配置。
• 考慮壓縮。當你有大量CPU能夠揮霍和IO限制時，壓縮是一個很好的選擇。

 

本文轉載於

http://publish.itpub.net/i/2007-12-13/200712130852781.shtml