Google是可伸縮性之王。每個人都知道Google是因為他們對大量，復雜信息的快速搜索，但是Google的技術并不只是在搜索領域閃閃發(fā) 光。他們構建大型應用的平臺方式能夠讓他們以驚人的競爭速度在網(wǎng)絡規(guī)模應用上面大展拳腳。Google的目標一直是構建更高性能更高規(guī)模基礎設施來支持他 們的產(chǎn)品。他們怎么做到的呢？
參考資料以及信息來源
視頻：在Google上構建大型系統(tǒng) (Video: Building Large Systems at Google )
Google實驗室：Google文件系統(tǒng) (Google Lab: The Google File System )
Google實驗室：MapReduce：在大規(guī)模集群上簡化數(shù)據(jù)處理 (Google Lab: MapReduce: Simplified Data Processing on Large Clusters )
Google實驗室：BigTable: (Google Lab : BigTable .)
視頻：BigTable: 一個分布式的結構化存儲系統(tǒng) (Video: BigTable: A Distributed Structured Storage System .)
Google實驗室：松散耦合的分布式系統(tǒng)的 Chubby Lock服務 (Google Lab: The Chubby Lock Service for Loosely-Coupled Distributed Systems. )
Google是如何工作的 作者 David Carr發(fā)表于Baseline雜志 (How Google Works by David Carr in Baseline Magazine.)
Google實驗室：翻譯數(shù)據(jù)：使用Sawzall并行分析(Google Lab: Interpreting the Data: Parallel Analysis with Sawzall. )
可伸縮性大會上Dare Obasonjo的筆記 (Dare Obasonjo’s Notes on the scalability conference. )
平臺
• Linux
• 多種不同的語言： Python, Java, C++
數(shù)據(jù)揭秘
目前的情形：
• 2006年估計有450,000個價格便宜的商用服務器
• 2005年Google索引了80億的web頁面。到現(xiàn)在為止有多少，已經(jīng)無法統(tǒng)計出來了。
• 目前Google有超過200GFS的集群。一個集群能有1000甚至5000個機器。成百上千的機器從運行大到5peta字節(jié)存儲的GFS集群檢索數(shù)據(jù)。通過集群的總的讀寫吞吐量達到每秒400億字節(jié)。
• 目前在Google有6000個 MapReduce應用，并且每個月有幾百個新的應用正在出現(xiàn)。
架構的層次
Google把他們的基礎設施架構描述為三個層次棧：
• 產(chǎn)品：檢索，廣告，電子郵件，地圖，視頻，聊天，博客
• 分布式系統(tǒng)基礎設施：GFS, MapReduce, 以及BigTable。
• 計算平臺：很多不同數(shù)據(jù)中心的很多機器
• 確保公司員工容易低成本配置。
• 看看每個應用基線的價格性能數(shù)據(jù)。把更多的錢花在硬件上以期不丟失日志數(shù)據(jù)，但是在其他類型的數(shù)據(jù)上花少一點。既然這樣處理，實際上他們就不會丟數(shù)據(jù)。
使用GFS（Google文件系統(tǒng)）的可靠存儲機制
• 可靠的可伸縮存儲是任何應用的一個核心需要。GFS就是他們的核心存儲平臺。
• Google文件系統(tǒng)- 大的分布式日志結構化文件系統(tǒng)，里面有大量數(shù)據(jù)
• 為什么不用其他的而非要構建一個文件系統(tǒng)呢？因為他們需要控制所有的事情，而正是這個平臺把他們和其他任何一個區(qū)分開來。他們需要：
- 通過數(shù)據(jù)中心的高可靠性
- 對于幾千個網(wǎng)絡節(jié)點的可伸縮性
- 大的讀寫帶寬需求
- 支持十億字節(jié)大的數(shù)據(jù)塊
- 高效的通過節(jié)點減少瓶頸的分布式操作
• 系統(tǒng)有主服務器和分塊服務器（chunk servers）
- 主服務器在各種數(shù)據(jù)文件上保存元數(shù)據(jù)。數(shù)據(jù)以64MB大的塊存儲在文件系統(tǒng)中。客戶機和主服務器對話來操作文件里的元數(shù)據(jù)，定位包含了磁盤上他們需要的數(shù)據(jù)的分塊服務器。
• 一個新的應用可以使用一個已經(jīng)存在的GFS集群或者他們自己制作。去理解他們使用的通過數(shù)據(jù)中心的這個供應過程將是非常有趣的。
• 主鍵是足夠的基礎設施來確保人們對他們的應用有多種選擇。可以調(diào)整GFS以適應個人應用需要。
使用MapReduce對數(shù)據(jù)做一些事情
• 既然你有了一個好的存儲系統(tǒng)，你怎樣使用如此多的數(shù)據(jù)呢？假如說你有很多TB的數(shù)據(jù)存儲在1000臺機器上。數(shù)據(jù)庫不能擴展或者有效地擴展到這樣的規(guī)模。這時就要用到MapReduce了。
• MapReduce是一個編程模型和用來處理和產(chǎn)生大規(guī)模數(shù)據(jù)集。用戶指定一個映射函數(shù)處理一個鍵/值對來產(chǎn)生中間的鍵/值對集合，還指定一個縮小函數(shù)來合并所有的與同一中間鍵相關的中間值。
許多現(xiàn)實世界的任務在這個模型里被表示出來。用這個函數(shù)風格寫的程序自動并行化并且在一大集群商務機器上執(zhí)行。運行時系統(tǒng)關心分割輸入數(shù)據(jù)的細節(jié)， 通過一系列的機器安排程序的執(zhí)行，處理機器事故，以及管理所需的機器內(nèi)部通信。這使得沒有任何并行和分布式系統(tǒng)經(jīng)驗的程序員能夠容易地利用一個大的分布式 系統(tǒng)的資源。
• 為什么使用MapReduce呢？
- 在大量機器上分割任務的極佳方式
- 處理機器故障
- 在不同類型的應用上工作，如搜索和廣告。幾乎每個應用都有映射簡化類型之類的操作。你可以預計算有用的數(shù)據(jù)，統(tǒng)計字數(shù)，分類幾TB的數(shù)據(jù)，等等。
- 計算可以自動地更加靠近IO源。
• MapReduce 系統(tǒng)有三個不同類型的服務器。
- 主服務器分配用戶任務以映射和減少服務器。它也跟蹤任務的狀態(tài)。
- 映射服務器接收用戶輸入，在它們上面實行映射操作。結果寫入中間文件。
- 化簡服務器接收由映射服務器產(chǎn)生的中間文件并在它們上面實行化簡操作。
• 例如，你想要統(tǒng)計所有網(wǎng)頁中字符的個數(shù)。你可以把存儲在GFS中的頁面放入MapReduce。這些都將在1000秒內(nèi)發(fā)生，包括機器同步和協(xié)調(diào)，任務安排，事故處理和數(shù)據(jù)傳輸將會自動完成。
- 步驟如下：GFS -> Map -> Shuffle -> Reduction -> 把結果存回GFS
- 在MapReduce 里，一個映射把一個視圖映射到另一個，產(chǎn)生一個鍵值對，在我們的例子里是單詞和數(shù)量。
- Shuffling 聚合鍵的類型
- 化簡把所有的鍵值對加起來產(chǎn)生最后的結果。
• Google索引管道有大概20個不同的映射化簡。一個管道把數(shù)據(jù)看做記錄的一個整體束和聚合鍵。第二個映射-化簡進來把那個結果拿走做其他的一些事情。等等。
• 程序可以很小。可以小到20到50行的代碼。
• 一個問題是stragglers。Stragglers是一種比其他都要慢的計算。Stragglers會發(fā)生是因為慢的IO（比如一個糟糕的控制器）或者從一個臨時的CPU尖峰信號。解決辦法是運行多個同樣的計算，當一個完成時就銷毀所有其他的計算。
• 在映射和化簡之間轉(zhuǎn)換的數(shù)據(jù)被壓縮。這樣做是因為服務器不受CPU約束，花時間在數(shù)據(jù)的壓縮和解壓縮上還是有意義的，可以節(jié)省花在帶寬和I/O上的時間。
在BigTable中存儲結構化數(shù)據(jù)
• BigTable 是一個大型的容錯和自我管理系統(tǒng)，包括太（萬億）字節(jié)的內(nèi)存和皮字節(jié)的內(nèi)存。它每秒能夠處理幾百萬的讀寫。
• BigTable是一個構建在GFS之上的分布式散列機制。它不是一個關系數(shù)據(jù)庫。它不支持聯(lián)結或者SQL類型查詢。
• 它提供查找機制，可以通過鍵來訪問結構化的數(shù)據(jù)。GFS存儲不透明數(shù)據(jù)和許多應用所需的結構化數(shù)據(jù)。
• 商業(yè)化數(shù)據(jù)不能伸縮到這個層次，它們不在1000個機器上工作。
• 通過控制它們自己的低層次存儲系統(tǒng)，Google得到更多的控制和有力的工具來改進它們的系統(tǒng)。例如，如果它們想要使得分布
數(shù)據(jù)操作更簡單的特征，它們可以在里面構建。
• 當系統(tǒng)運行的時候，機器可以增加和減少，而整個系統(tǒng)還會正常工作。
• 每個數(shù)據(jù)條存儲在一個可以使用行鍵，列鍵或者時間郵票訪問的單元中。
• 每行存儲在一個或者更多個tablet中。一個tablet是數(shù)據(jù)形式的64KB塊的序列叫做SSTable。
• BigTable 有三個不同類型的服務器：
- 主服務器分配tablet到tablet服務器中。它們跟蹤的位置，當需要時還會重新分配任務。
- Tablet 服務器處理tablet的讀寫請求。當tablet超過規(guī)模限制（通常是100MB - 200MB）時，它們將它分開。當一個tablet服務器出故障時，會有100個tablet服務器每個撿起一個新的tablet，所以系統(tǒng)就恢復了。
• 一個位置組可以被用作與幾比特的數(shù)據(jù)相關的物理存儲，為了有一個更好的參考位置。
• Tablets盡可能在RAM里被緩存。
硬件
• 當你有很多個機器時，你如何構建它們以使花費代價最小電能消耗最少呢？
• 使用超便宜的商業(yè)硬件，拼命利用它們在上面構建軟件。
• 增加 1,000-fold 計算機電力，如果你使用容易出事故的基礎設施而不是構建在高度可靠的部件之上的基礎設施時，可以有33倍更低的花費。你必須使用這一策略在不可靠之上構建可靠。
• Linux，內(nèi)部的架構設計，PC類主機板，低端存儲。
• 性能基線中每瓦的價格沒有越來越好。存在著很多的電力和其他問題。
• 使用混合收集和它們自己的數(shù)據(jù)中心。
雜類
• 很快找出改變而不是等著提問和回答。
• 庫是構建程序的主要方式。
• 一些是以服務的形式提供的應用，比如crawling。
• 基礎設施處理應用程序的版本，所以它們就能夠發(fā)布，不用擔心破壞事情。
Google未來的方向
• 支持地理位置分布的集群
• 為所有的數(shù)據(jù)創(chuàng)建單一的全局名字空間。當前數(shù)據(jù)由集群分離開的。
• 更多更好的數(shù)據(jù)和計算的自動化遷移。
• 解決當你用網(wǎng)絡分割耦合大范圍的復制時產(chǎn)生的一致性問題（例如，即使一個集群已經(jīng)因為維修或是其他一些臨時停電等原因而下線時，還能繼續(xù)提供服務）
Goolge告訴我們的經(jīng)驗
• 基礎設施是一個很有競爭性的優(yōu)勢。它當然是屬于Google的。它們能更快更便宜地提供和生產(chǎn)新的網(wǎng)絡服務，這在一定程度上是無人能比的。許多公司采取了 完全不同的方式。許多公司把基礎設施看做一種花銷。每個組將使用完全不同的技術，而且他們很少有計劃如何更經(jīng)濟地構建系統(tǒng)。Google把他們自己看做一 個系統(tǒng)工程公司，以一個非常新的方式來看待構建軟件。
• 跨越多個數(shù)據(jù)中心仍是一個未解決的問題。大多數(shù)網(wǎng)站是一個至多是兩個數(shù)據(jù)中心。如何在大量數(shù)據(jù)中心上充分分配網(wǎng)站，我們說，非常復雜。
• 看一看Hadoop (產(chǎn)品)如果你沒有時間來從頭開始構建所有這個基礎設施的話。Hadoop 是一個這里講的一些主意的開源實現(xiàn)。
• 一個平臺方式被忽略的優(yōu)點是初級開發(fā)人員可以在平臺上很快自信地構建健壯的應用。如果每個項目需要創(chuàng)建同樣的分布式基礎設施輪，你將會陷入困境，因為知道如何這樣做的人員相對稀少。
• 協(xié)同工作并不總是廢話。通過使系統(tǒng)中所有部件一起工作，一個改進會有助于所有的改進。改善文件系統(tǒng)，每個人都會立刻明顯受益。如果每個項目使用一個不同的文件系統(tǒng)，那么就沒有整個展的持續(xù)的改進。
• 構建不需要降低系統(tǒng)性能的自我管理系統(tǒng)。這可以讓你更容易地平衡各服務器的資源，動態(tài)增加更多空間，允許機器下線，以及更從容地處理升級。
• 創(chuàng)建一個進化式基礎設施。花時間在并行處理上會有回報的。
• 不要忽視了學院。學術界有很多好的創(chuàng)意并沒有轉(zhuǎn)入生產(chǎn)環(huán)境里。Google所做的大部分先于藝術，不只是先于大規(guī)模配置。
• 考慮壓縮。當你有大量CPU可以揮霍和IO限制時，壓縮是一個很好的選擇。