posts - 310, comments - 6939, trackbacks - 0, articles - 3
            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

          GOOGLE系統架構(ZZ)

          Posted on 2009-11-01 21:15 詩特林 閱讀(1232) 評論(1)  編輯  收藏 所屬分類: 系統架構

          Google是可伸縮性之王。每個人都知道Google是因為他們對大量,復雜信息的快速搜索,但是Google的技術并不只是在搜索領域閃閃發 光。他們構建大型應用的平臺方式能夠讓他們以驚人的競爭速度在網絡規模應用上面大展拳腳。Google的目標一直是構建更高性能更高規?;A設施來支持他 們的產品。他們怎么做到的呢?

          參考資料以及信息來源
          視頻:在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. )

          平臺
          • 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大的塊存儲在文件系統中??蛻魴C和主服務器對話來操作文件里的元數據,定位包含了磁盤上他們需要的數據的分塊服務器。
          • 一個新的應用可以使用一個已經存在的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上的時間。
          在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限制時,壓縮是一個很好的選擇。


          評論

          # re: GOOGLE系統架構(ZZ)  回復  更多評論   

          2009-11-03 10:11 by 咖啡妝
          這應該是一份內部文檔,有沒有google的商業模式架構,分享一下?
          主站蜘蛛池模板: 通州区| 杭锦后旗| 全椒县| 香港| 文化| 舒兰市| 遂平县| 寻甸| 浦江县| 当雄县| 宣化县| 手游| 恩施市| 蒙阴县| 泰顺县| 沅陵县| 金坛市| 福鼎市| 神池县| 保山市| 天水市| 万盛区| 高淳县| 清新县| 资源县| 青浦区| 霍林郭勒市| 苏尼特左旗| 房产| 土默特左旗| 岳西县| 隆昌县| 阿克陶县| 武城县| 黎平县| 三原县| 安新县| 海伦市| 庄河市| 汝州市| 阜南县|