原文：
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為單位存儲在文件系統中?？蛻舳伺cMaster服務器交流來在文件上做元數據操作并且找到包含用戶需要數據的那些Chunk服務器
-Chunk服務器在硬盤上存儲實際數據。每個Chunk服務器跨越3個不同的Chunk服務器備份以創建冗余來避免服務器崩潰。一旦被Master服務器指明，客戶端程序就會直接從Chunk服務器讀取文件
6，一個上線的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，關鍵點在于有足夠的基礎組織來讓人們對自己的程序有所選擇，GFS可以調整來適應個別程序的需求
使用MapReduce來處理數據
1，現在你已經有了一個很好的存儲系統，你該怎樣處理如此多的數據呢？比如你有許多TB的數據存儲在1000臺機器上。數據庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現的原因
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是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的內存和1000000000000000的存儲。它可以每秒鐘處理百萬的讀寫
2，BigTable是一個構建于GFS之上的分布式哈希機制。它不是關系型數據庫。它不支持join或者SQL類型查詢
3，它提供查詢機制來通過鍵訪問結構化數據。GFS存儲存儲不透明的數據而許多程序需求有結構化數據
4，商業數據庫不能達到這種級別的伸縮性并且不能在成千上萬臺機器上工作
5，通過控制它們自己的低級存儲系統Google得到更多的控制權來改進它們的系統。例如，如果它們想讓跨數據中心的操作更簡單這個特性，它們可以內建它
6，系統運行時機器可以自由的增刪而整個系統保持工作
7，每個數據條目存儲在一個格子里，它可以通過一個行key和列key或者時間戳來訪問
8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數據序列并且格式為SSTable
9，BigTable有三種類型的服務器：
-Master服務器分配tablet服務器，它跟蹤tablet在哪里并且如果需要則重新分配任務
-Tablet服務器為tablet處理讀寫請求。當tablet超過大小限制(通常是100MB-200MB)時它們拆開tablet。當一個Tablet服務器失敗時，則100個Tablet服務器各自挑選一個新的tablet然后系統恢復。
-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有限時壓縮是一個好的選擇。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。