Google Architecture -- 翻譯版

Google是伸縮性的王者。Google一直的目標就是構建高性能高伸縮性的基礎組織來支持它
們的產品。

平臺
Linux

大量語言：Python，Java，C++

狀態
在2006年大約有450,000臺廉價服務器
在2005年Google索引了80億Web頁面，現在沒有人知道數目
目前在Google有超過200個GFS集羣。一個集羣可以有1000或者甚至5000臺機器。成千上萬
的機器從運行着5000000000000000字節存儲的GFS集羣獲取數據，集羣總的讀寫吞吐量可以
達到每秒40兆字節
目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序
BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇

堆棧
Google形象化它們的基礎組織爲三層架構：
1，產品：搜索，廣告，email，地圖，視頻，聊天，博客
2，分佈式系統基礎組織：GFS，MapReduce和BigTable
3，計算平臺：一羣不同的數據中心裏的機器
4，確保公司裏的人們部署起來開銷很小
5，花費更多的錢在避免丟失日誌數據的硬件上，其他類型的數據則花費較少

可信賴的存儲機制GFS(Google File System)
1，可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺
2，Google File System - 大型分佈式結構化日誌文件系統，Google在裏面扔了大量的數
據
3，爲什麼構建GFS而不是利用已有的東西？因爲可以自己控制一切並且這個平臺與別的不
一樣，Google需要：
-跨數據中心的高可靠性
-成千上萬的網絡節點的伸縮性
-大讀寫帶寬的需求
-支持大塊的數據，可能爲上千兆字節
-高效的跨節點操作分發來減少瓶頸
4，系統有Master和Chunk服務器
-Master服務器在不同的數據文件裏保持元數據。數據以64MB爲單位存儲在文件系統中。客
戶端與Master服務器交流來在文件上做元數據操作並且找到包含用戶需要數據的那些Chunk
服務器
-Chunk服務器在硬盤上存儲實際數據。每個Chunk服務器跨越3個不同的Chunk服務器備份以
創建冗餘來避免服務器崩潰。一旦被Master服務器指明，客戶端程序就會直接從Chunk服務
器讀取文件
6，一個上線的新程序可以使用已有的GFS集羣或者可以製作自己的GFS集羣
7，關鍵點在於有足夠的基礎組織來讓人們對自己的程序有所選擇，GFS可以調整來適應個
別程序的需求

使用MapReduce來處理數據
1，現在你已經有了一個很好的存儲系統，你該怎樣處理如此多的數據呢？比如你有許多TB
的數據存儲在1000臺機器上。數據庫不能伸縮或者伸縮到這種級別花費極大，這就是MapRe
duce出現的原因
2，MapReduce 是一個處理和生成大量數據集的編程模型和相關實現。用戶指定一個map方
法來處理一個鍵/值對來生成一箇中間的鍵/值對，還有一個reduce方法來合併所有關聯到
同樣的中間鍵的中間值。許多真實世界的任務都可以使用這種模型來表現。以這種風格來
寫的程序會自動並行的在一個大量機器的集羣裏運行。運行時系統照顧輸入數據劃分、程
序在機器集之間執行的調度、機器失敗處理和必需的內部機器交流等細節。這允許程序員
沒有多少並行和分佈式系統的經驗就可以很容易使用一個大型分佈式系統資源
3，爲什麼使用MapReduce？
-跨越大量機器分割任務的好方式
-處理機器失敗
-可以與不同類型的程序工作，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操
作。你可以預先計算有用的數據、查詢字數統計、對TB的數據排序等等
4，MapReduce系統有三種不同類型的服務器
-Master服務器分配用戶任務到Map和Reduce服務器。它也跟蹤任務的狀態
-Map服務器接收用戶輸入並在其基礎上處理map操作。結果寫入中間文件
-Reduce服務器接收Map服務器產生的中間文件並在其基礎上處理reduce操作
5，例如，你想在所有Web頁面裏的字數。你將存儲在GFS裏的所有頁面拋入MapReduce。這
將在成千上萬臺機器上同時進行並且所有的調整、工作調度、失敗處理和數據傳輸將自動
完成
-步驟類似於：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce裏一個map操作將一些數據映射到另一箇中，產生一個鍵值對，在我們的例子
裏就是字和字數
-Shuffling操作聚集鍵類型
-Reduction操作計算所有鍵值對的綜合併產生最終的結果
6，Google索引操作管道有大約20個不同的map和reduction。
7，程序可以非常小，如20到50行代碼
8，一個問題是掉隊者。掉隊者是一個比其他程序慢的計算，它阻塞了其他程序。掉隊者可
能因爲緩慢的IO或者臨時的CPU不能使用而發生。解決方案是運行多個同樣的計算並且當一
個完成後殺死所有其他的
9，數據在Map和Reduce服務器之間傳輸時被壓縮了。這可以節省帶寬和I/O。

在BigTable裏存儲結構化數據
1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的內存和10000000
00000000的存儲。它可以每秒鐘處理百萬的讀寫
2，BigTable是一個構建於GFS之上的分佈式哈希機制。它不是關係型數據庫。它不支持joi
n或者SQL類型查詢
3，它提供查詢機制來通過鍵訪問結構化數據。GFS存儲存儲不透明的數據而許多程序需求
有結構化數據
4，商業數據庫不能達到這種級別的伸縮性並且不能在成千上萬臺機器上工作
5，通過控制它們自己的低級存儲系統Google得到更多的控制權來改進它們的系統。例如，
如果它們想讓跨數據中心的操作更簡單這個特性，它們可以內建它
6，系統運行時機器可以自由的增刪而整個系統保持工作
7，每個數據條目存儲在一個格子裏，它可以通過一個行key和列key或者時間戳來訪問
8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數據序列並且格式爲SS
Table
9，BigTable有三種類型的服務器：
-Master服務器分配tablet服務器，它跟蹤tablet在哪裏並且如果需要則重新分配任務
-Tablet服務器爲tablet處理讀寫請求。當tablet超過大小限制(通常是100MB-200MB)時它
們拆開tablet。當一個Tablet服務器失敗時，則100個Tablet服務器各自挑選一個新的tabl
et然後系統恢復。
-Lock服務器形成一個分佈式鎖服務。像打開一個tablet來寫、Master調整和訪問控制檢查
等都需要互斥
10，一個locality組可以用來在物理上將相關的數據存儲在一起來得到更好的locality選
擇
11，tablet儘可能的緩存在RAM裏

硬件
1，當你有很多機器時你怎樣組織它們來使得使用和花費有效？
2，使用非常廉價的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost
if you you use a failure-prone infrastructure rather than an infrastructure
built on highly reliable components. You must build reliability on top of
unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存儲
5，Price per wattage on performance basis isn't getting better. Have huge
power and cooling issues
6，使用一些collocation和Google自己的數據中心

其他
1，迅速更改而不是等待QA
2，庫是構建程序的卓越方式
3，一些程序作爲服務提供
4，一個基礎組織處理程序的版本，這樣它們可以發佈而不用害怕會破壞什麼東西

Google將來的方向
1，支持地理位置分佈的集羣
2，爲所有數據創建一個單獨的全局名字空間。當前的數據由集羣分離
3，更多和更好的自動化數據遷移和計算
4，解決當使用網絡劃分來做廣闊區域的備份時的一致性問題(例如保持服務即使一個集羣
離線維護或由於一些損耗問題)

學到的東西
1，基礎組織是有競爭性的優勢。特別是對Google而言。Google可以很快很廉價的推出新服
務，並且伸縮性其他人很難達到。許多公司採取完全不同的方式。許多公司認爲基礎組織
開銷太大。Google認爲自己是一個系統工程公司，這是一個新的看待軟件構建的方式
2，跨越多個數據中心仍然是一個未解決的問題。大部分網站都是一個或者最多兩個數據中
心。我們不得不承認怎樣在一些數據中心之間完整的分佈網站是很需要技巧的
3，如果你自己沒有時間從零開始重新構建所有這些基礎組織你可以看看Hadoop。Hadoop是
這裏很多同樣的主意的一個開源實現
4，平臺的一個優點是初級開發人員可以在平臺的基礎上快速並且放心的創建健全的程序。
如果每個項目都需要發明同樣的分佈式基礎組織的輪子，那麼你將陷入困境因爲知道怎樣
完成這項工作的人相對較少
5，協同工作不一直是擲骰子。通過讓系統中的所有部分一起工作則一個部分的改進將幫助
所有的部分。改進文件系統則每個人從中受益而且是透明的。如果每個項目使用不同的文
件系統則在整個堆棧中享受不到持續增加的改進
6，構建自管理系統讓你沒必要讓系統關機。這允許你更容易在服務器之間平衡資源、動態
添加更大的容量、讓機器離線和優雅的處理升級
7，創建可進化的基礎組織，並行的執行消耗時間的操作並採取較好的方案
8，不要忽略學院。學院有許多沒有轉變爲產品的好主意。Most of what Google has
done has prior art, just not prior large scale deployment.
9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。