有人可能認爲Google擁有幾臺“藍色基因”那樣的超級計算機來處理各種數據和搜索，事實是怎樣的呢？下面我們就將詳細解析神奇Google的神奇架構。
硬件：
截止到2010年，Google大約有100萬臺服務器，有超過500個計算機集羣，處理不同地域的不同任務。可惜服務器的詳細配置和最新集羣的具體情況，在多個文獻庫裏面都查詢不到，我個人理解，這可能屬於商業機密。大概也是因爲機密的緣故，強大的Google計算機集羣並沒有遞交Top500計算機的申請，多年來我們在Top500中都看不到Google的影子。(進入Top500需要提交併且公開自己計算機系統的詳細配置)不過根據文獻資料，可以肯定的是，這45萬臺服務器都不是什麼昂貴的服務器，而是非常普通的PC級別服務器，其中的服務器硬盤在兩年前還普遍是IDE接口、並且採用PC級主板而非昂貴的服務器專用主板。Google的集羣也全部是自己搭建的，沒有采用Myricom 的 Myrinet或者Giganet 的 cLAN等先進昂貴的集羣連接技術，Google各個數據中心和服務器間不同的耦合程度都隨需而定自行連接。
那麼google的存儲呢？Google存儲着海量的資訊，近千億個網頁、數百億張圖片。早在2004年，Google的存儲容量就已經達到了5PB。可能很多讀者一開始都認爲Google採用了諸如EMC Symmetrix系列磁盤陣列來保存大量的資訊，但是Google的實際做法又一次讓我們大跌眼鏡——Google沒有使用任何磁盤陣列，哪怕是低端的磁盤陣列也沒用。Google的方法是將集羣中的每一臺PC級服務器，配備兩個普通IDE硬盤來存儲。不過Google倒也不是都是什麼設備都落後，至少這些硬盤的轉速都很高，而且每臺服務器的內存也還算比較大。最大的電腦DIY消費者是誰？恐怕Google又登上了這個DIY寶座。Google的絕大部分服務器甚至也不是採購什麼大品牌，而是購買各種廉價零件而後自行裝配的。有趣的是，Google非常不滿意現存的各種PC電源的功耗，甚至還自行設計了Google專用服務器電源。
那麼google的存儲呢？Google存儲着海量的資訊，近千億個網頁、數百億張圖片。早在2004年，Google的存儲容量就已經達到了5PB。可能很多讀者一開始都認爲Google採用了諸如EMC Symmetrix系列磁盤陣列來保存大量的資訊，但是Google的實際做法又一次讓我們大跌眼鏡——Google沒有使用任何磁盤陣列，哪怕是低端的磁盤陣列也沒用。Google的方法是將集羣中的每一臺PC級服務器，配備兩個普通IDE硬盤來存儲。不過Google倒也不是都是什麼設備都落後，至少這些硬盤的轉速都很高，而且每臺服務器的內存也還算比較大。最大的電腦DIY消費者是誰？恐怕Google又登上了這個DIY寶座。Google的絕大部分服務器甚至也不是採購什麼大品牌，而是購買各種廉價零件而後自行裝配的。有趣的是，Google非常不滿意現存的各種PC電源的功耗，甚至還自行設計了Google專用服務器電源。
很快，我們就有了疑問。這樣的一個以PC級別服務器搭建起來的系統，怎麼能承受巨大的工作負載呢？怎麼能保證高可用性呢？的確，這些低端的服務器經常出現故障——硬盤壞道、系統宕機這類的事故其實每天都在45萬臺服務器中發生。而Google的方法是設立鏡像站。以Google主站爲例，2003年就在美國硅谷和弗吉尼亞設立了多個鏡像站。這些鏡像站其實不是傳統的鏡像站。真正的鏡像站是雙機熱備，當一臺服務器宕機時，另一臺服務器接管相關任務。而Google的鏡像站其實真正的職責是DNS負載均衡，所以有的Google鏡像站本身還有自己的鏡像站。這裏舉例說明Google鏡像站的作用：一個訪問，DNS正常解析到A處，但當A處負載過大時，DNS服務就將域名解析到B處，這樣既達到了冗餘，也縮減了投資。由於不是雙機熱備，某一時間，鏡像站的內容可能略有不同，不過對於精確度要求不那麼高的普通檢索而言，並不是問題。
平臺：GFS/MapReduce/ BigTable/Linux
GFS/MapReduce/ BigTable/這三個平臺，是Google最引以爲傲的平臺，全部架構在Linux之上。
首先我們來看一看GFS（Google File System）Google文件系統。我們知道，一般的數據中心檢索時候需要用到數據庫系統。但是Google的情況很特殊——Google擁有全球上百億個Web文檔，如果用常規數據庫系統檢索，那麼檢索速度就可想而知了。因此，當Crawlers採集到許多新的Web後，Google將很多的Web都彙集到一個文件裏進行存儲管理，而且Google將Web文件壓縮成Chunk塊，進一步減少佔用空間(64MB一個chunk)。最後，Google只檢索壓縮後的部分。而GFS(Google File System）正是在這樣的檢索技術上構建的文件系統，GFS包括了GFS Master服務器和Chunk服務器。如下圖所示，系統的流程從GFS客戶端開始：GFS客戶端以chunk偏移量製作目錄索引並且發送請求——GFS Master收到請求通過chunk映射表映射反饋客戶端——客戶端有了chunk handle和chunk 位置，並將文件名和chunk的目錄索引緩存，向chunk服務器發送請求——chunk服務器回覆請求傳輸chunk數據。
如果讀者您讀着有點迷糊，這很正常，因爲只有少數搜索引擎企業才採用這樣的技術。簡單來說是這樣：Google運用GFS大大簡化了檢索的難度。
除了GFS，MapReduce對Google也是功不可沒。Google擁有不少於45萬臺服務器，看起來每臺服務器的職能都非常明確，但是其中卻有重要的協同問題有待解決：如何併發計算，如何分佈數據，如何處理失敗，如何負載均衡？我們可以預見，無數的代碼將被用在協同問題上，而且很可能效率低下。這時候，MapReduce就派上用場了。MapReduce是Google開發的C++編程工具，用於大規模數據集的並行運算。MapReduce主要功能是提供了一個簡單強大的接口，可以將計算自動的併發和分佈執行。這樣一來，就可以通過普通PC的集羣，實現高性能。MapReduce主要從兩方面提升了系統：首先是失效的計算機問題。如果某一臺計算機失效了，或者是I/O出現了問題——這在Google以廉價服務器組建的集羣中極爲常見，MapReduce的解決方法是用多個計算機同時計算一個任務，一旦一臺計算機有了結果，其它計算機就停止該任務，而進入下一任務。另外，在MapReduce之間傳輸的數據都是經過壓縮的，節省了很多帶寬資源。至於BigTable，這是一個用來處理大數據量的系統，適合處理半結構化的數據。
Google心經：
Google總是嘗試用最少的錢，做最多的事情。不要小看那些便宜、不牢靠的PC級服務器，一臺服務器也許確實不牢靠，但是45萬臺的有機集成卻成爲了全球最完善、最穩定的系統之一。在採購服務器方面，Google也從未一次性大量購買，都是有了需求再選購。另一個能夠體現Google精打細算的方面是Google儘量壓縮所有能夠壓縮的文件。
包括軟件和硬件，Google的設計構想都很前衛，Google嘗試過許多還在實驗室裏的萌芽技術，如上文所說，很多都取得了巨大成功。Google早先的目標是0.5秒鐘做出搜索結果，但實際上目前的平均時間已經縮減到了0.25秒。而且，Google從來沒有停止研究的腳步，現在還在測試OpenSoalris，觀察OpenSoalris是否能夠替代Linux。
Google的行爲非常踏實。不參加Top500評選，文獻裏也鮮有相關資料。可見Google不吹噓、也沒有過度宣傳，只是勤勤懇懇的更新程序、優化集羣。今天，google收錄了絕大多數人類語言的網頁，並且在多數國家都建立了Google分站，收錄的網頁也是與日俱增，全球影響力更是不言而喻。
向Google的架構學習，向Google的成就致敬。
Google是伸縮性的王者。Google一直的目標就是構建高性能高伸縮性的基礎組織來支持它們的產品。
平臺
平臺
Linux
大量語言：Python，Java，C++
大量語言：Python，Java，C++
狀態
在2006年大約有450,000臺廉價服務器，這個數量到2010年增加到了1,000,000臺。
在2005年Google索引了80億Web頁面，現在沒有人知道具體數目，近千億並不斷增長中。
目前在Google有超過500個GFS集羣。一個集羣可以有1000或者甚至5000臺機器。成千上萬的機器從運行着5000000000000000字節存儲的GFS集羣獲取數據，集羣總的讀寫吞吐量可以達到每秒40兆字節
目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序
BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇
在2006年大約有450,000臺廉價服務器，這個數量到2010年增加到了1,000,000臺。
在2005年Google索引了80億Web頁面，現在沒有人知道具體數目，近千億並不斷增長中。
目前在Google有超過500個GFS集羣。一個集羣可以有1000或者甚至5000臺機器。成千上萬的機器從運行着5000000000000000字節存儲的GFS集羣獲取數據，集羣總的讀寫吞吐量可以達到每秒40兆字節
目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序
BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇
堆棧
Google形象化它們的基礎組織爲三層架構：
1，產品：搜索，廣告，email，地圖，視頻，聊天，博客
2，分佈式系統基礎組織：GFS，MapReduce和BigTable
3，計算平臺：一羣不同的數據中心裏的機器
4，確保公司裏的人們部署起來開銷很小
5，花費更多的錢在避免丟失日誌數據的硬件上，其他類型的數據則花費較少
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可以調整來適應個別程序的需求
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臺機器上。數據庫不能伸縮或者伸縮到這種級別花費極大，這就是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。
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，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，當你有很多機器時你怎樣組織它們來使得使用和花費有效？
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，一個基礎組織處理程序的版本，這樣它們可以發佈而不用害怕會破壞什麼東西
1，迅速更改而不是等待QA
2，庫是構建程序的卓越方式
3，一些程序作爲服務提供
4，一個基礎組織處理程序的版本，這樣它們可以發佈而不用害怕會破壞什麼東西
Google將來的方向
1，支持地理位置分佈的集羣
2，爲所有數據創建一個單獨的全局名字空間。當前的數據由集羣分離
3，更多和更好的自動化數據遷移和計算
4，解決當使用網絡劃分來做廣闊區域的備份時的一致性問題(例如保持服務即使一個集羣離線維護或由於一些損耗問題)
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有限時壓縮是一個好的選擇。
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有限時壓縮是一個好的選擇。
Google主要以GFS、MapReduce、BigTable這三大平臺來支撐其龐大的業務系統，我稱他們爲Google三劍客，網上也有說是Google的三架馬車。
一、GFS（Google File System）
這是Google獨特的一個面向大規模數據密集型應用的、可伸縮的分佈式文件系統，由於這個文件系統是通過軟件調度來實現的，所以Google可以把GFS部署在很多廉價的PC機上，來達到用昂貴服務器一樣的效果。
下面是一張Google GFS的架構圖：
從上圖我們可看到Google的GFS主要由一個master和很多chunkserver組成，master主要是負責維護系統中的名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置等元素據，並通過心跳信號與chunkserver通信，蒐集並保存chunkserver的狀態信息。chunkserver主要是用來存儲數據塊，google把每個數據塊的大小設計成64M，至於爲什麼這麼大後面會提到，每個chunk是由master分配的chunk-handle來標識的，爲了提高系統的可靠性，每個chunk會被複制3個副本放到不同的chunkserver中。
當然這樣的單master設計也會帶來單點故障問題和性能瓶頸問題，Google是通過減少client與master的交互來解決的，client均是直接與chunkserver通信，master僅僅提供查詢數據塊所在的chunkserver以及詳細位置。下面是在GFS上查詢的一般流程：
1、client使用固定的塊大小將應用程序指定的文件名和字節偏移轉換成文件的一個塊索引（chunk index）。
2、給master發送一個包含文件名和塊索引的請求。
3、master迴應對應的chunk handle和副本的位置（多個副本）。
4、client以文件名和塊索引爲鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個字節區間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以後對同一個塊的讀操作不再需要client和master間的交互。
2、給master發送一個包含文件名和塊索引的請求。
3、master迴應對應的chunk handle和副本的位置（多個副本）。
4、client以文件名和塊索引爲鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個副本發送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個字節區間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以後對同一個塊的讀操作不再需要client和master間的交互。
不過我還是有疑問，google可以通過減少client與master通信來解決性能瓶頸問題，但單點問題呢，一臺master掛掉豈不是完蛋了，總感覺不太放心，可能是我瞭解不夠透徹，不知道哪位朋友能解釋一下，謝謝：）
二、MapReduce，Google的分佈式並行計算系統
如果上面的GFS解決了Google的海量數據的存儲，那這個MapReduce則是解決了如何從這些海量數據中快速計算並獲取指定數據的問題。我們知道，Google的每一次搜索都在零點零幾秒，能在這麼短時間裏環遊世界一週，這裏MapReduce有很大的功勞。
Map即映射，Reduce即規約，由master服務器把map和reduce任務分發到各自worker服務器中運行計算，最後把結果規約合併後返回給用戶。這個過程可以由下圖來說明。
按照自己的理解，簡單對上圖加點說明：
1、首先把用戶請求的數據文件切割成多份，每一份（即每一個split）被拷貝在集羣中不同機器上，然後由集羣啓動程序中的多份拷貝。
2、master把map和reduce任務交給相對空閒的worker處理，並阻塞等待處理結果。
3、處理map任務的worker接到任務後，把以key/value形式的輸入數據傳遞給map函數進行處理，並將處理結果也以key/value的形式輸出，並保存在內存中。
4、上一步內存中的結果是要進行reduce的，於是這些map worker就把這些數據的位置返回給master，這樣master知道數據位置就可以繼續分配reduce任務，起到了連接map和reduce函數的作用。
5、reduce worker知道這些數據的位置後就去相應位置讀取這些數據，並對這些數據按key進行排序。將排序後的數據序列放入reduce函數中進行合併和規約，最後每個reduce任務輸出一個結果文件。
6、任務結束，master解除阻塞，喚醒用戶。
以上是個人的一些理解，有不對的地方請指出。
三、BigTable，分佈式的結構化數據存儲系統？
BigTable是基於GFS和MapReduce之上的，那麼google既然已經有了GFS，爲何還要有BigTable呢（也是我原先的一個疑問）？後來想想這和已經有操作系統文件系統爲何還要有SQL SERVER數據庫一樣的道理，GFS是更底層的文件系統，而BigTable建立在其上面，不僅可以存儲結構化的數據，而且可以更好的管理和做出負載均衡決策。
以下是BigTable的架構圖：
它完全是一個基於key/value的數據庫，和一般的關係型數據庫不同，google之所以採用BigTable，因爲它在滿足需求的同時簡化了系統，比如去掉了事務、死鎖檢測等模塊，讓系統更高效。更重要的一點是在BigTable中數據是沒有格式的，它僅僅是一個個key/value的pairs，用戶可以自己去定義數據的格式，這也大大提高了BigTable的靈活性和擴展性。
四、總結
這篇隨筆主要是一些總結性的內容，Google架構遠遠不止這些。
附：Google背後的IT架構策略揭祕
Google是與衆不同的。它的獨特不僅僅表現於革新的思維和充滿創意的應用 (比如那個大堂裏的地球模型)，更在於其有別常規的IT策略……
加利福尼亞州山景城(Mountain View)Google公司(Google，下稱Google)總部有一個43號大樓，該建築的中央大屏幕上顯示着一個與Google地球(Google Earth)相仿的世界地圖，一個轉動的地球上不停地閃動着五顏六色的光點，恍如羅馬宮廷的千萬燭燈，每一次閃動標誌着地球的這個角落一名Google用戶發起了一次新的搜索。
這同時意味着Google又一次滿足了人們對未知信息的好奇與渴望。
Google是與衆不同的。它的獨特不僅僅表現於革新的思維和充滿創意的應用 (比如那個大堂裏的地球模型)，更在於其有別常規的IT策略。從人們的常理來看，簡單的硬件商品和免費軟件是無法構建出一個帝國的，但是Google做到了。在性能調整後，Google把它們變成一個無可比擬的分佈式計算平臺，該平臺能夠支持大規模的搜索和不斷涌現的新興應用。我們原本認爲這些應用都是個人消費級別的，但是Google改變了這一切。現在商業世界也在使用它們，這就令這家搜索公司顯得那麼與衆不同。
GoogleWeb 服務背後的IT架構對無數使用搜索引擎的用戶來說也許並不是非常重要，但它是Google幾百位致力於把全球信息組織起來，實現“隨處可達，隨時可用”目標的工程師們的最核心工作。這就需要一個在覆蓋範圍和野心上都與Google的商業願景完全相符的IT藍圖作爲支撐。
Google 的經理們一直對公司的IT策略話題保持沉默，他們厭惡談及特定的廠商或者產品，當被問到他們的服務器和數據中心時，他們總是閉口不談。但與幾位 Google的IT領導一起呆了一天後，我們最終得以揭示該公司的IT是如何運作的，那可不僅僅是一個運行在無數服務器集羣上的、表面看來非常簡單的搜索引擎。在其簡單的外表下，蘊涵着許多內部研發軟件、定製硬件、人工智能，以及對性能的執着追求和打破常規的人力管理模式。
IT理念方面，Google對同行有一條建議：儘量避免那些人人都在使用的系統和軟件，以自己的方式做事會更有獨特的競爭優勢。
“企業文化決定了你的做事方式。”道格拉斯”美林(Douglas Merrill)，這位Google工程副總裁和事實上的首席信息官(CIO) 指出，“到了我們這樣的發展階段，企業觀念和文化非常與衆不同，這也反過來鞭策我們必須要採用與衆不同的方式來運行那些他人看來很常規的系統。”
Google 最大的IT優勢在於它能建造出既富於性價比(並非廉價)又能承受極高負載的高性能系統。因此IT顧問史蒂芬”阿諾德(Stephen Arnold)指出，Google與競爭對手，如亞馬遜網站(Amazon)、電子港灣公司(eBay)、微軟公司(Microsoft，下稱微軟)和雅虎公司 (Yahoo，下稱雅虎)等公司相比，具有更大的成本優勢。Google程序員的效率比其他Web公司同行們高出50%～100%，原因是Google已經開發出了一整套專用於支持大規模並行系統編程的定製軟件庫。據他估算，其他競爭公司可能要花上四倍的時間才能獲得同等的效果。
打造服務器
Google 究竟是怎樣做到這點的呢?其中一個手段，美林認爲，“是因爲我們自己動手打造硬件。”Google並不製造計算機系統，但它根據自己的參數定製硬件，然後像MTV的節目“靚車打造”(Pimp My Ride)那樣自己安裝和調整硬件系統。開源程序經理克里斯”迪博納(Chris DiBona)評論道：“我們很善於購買商業服務器，並且改造他們爲我們所用，最後把性能壓榨和發揮到極致，以致有時候他們熱得像要融化了似的。”
這種親手打造的方式，來源於Google從車庫誕生時與生俱來的節儉風格，更與Google那超大型的系統規模息息相關，良好的習慣一直延續至今。據說 Google在65個數據中心擁有20萬～45萬臺服務器—這個數目會有偏差(取決於你如何定義服務器和由誰來做這項統計)。但是，不變的是持續上升的趨勢。
Google不會去討論這些資產，因爲它認爲保密也是一種競爭優勢。事實上，Google之所以喜歡開源軟件也是因爲它的私密性。“如果我們購買了軟件許可或代碼許可，人們只要對號入座，就可以猜出Google的IT基礎架構。”迪博納分析說， “使用開源軟件，就使我們多了一條把握自己命運的途徑。”
Google喜歡規模化的服務器運行方式。當有成百上千臺機器時，定製服務器的優勢也會成倍增加，效果也會更趨明顯。Google正在俄勒岡州哥倫比亞河邊的達勒斯市建造一個佔地30畝的數據中心，在那兒它可以獲得運算和降溫需要的低價水力電力能源(參見邊欄《Google數據中心自有一套》)。
Google以“單元”(Cell)的形式組織這些運行 Linux操作系統的服務器，迪博納把這種形式比喻成互聯網服務的“磁盤驅動器”(但別和一直謠傳的Google存儲服務Gdrive混淆了，“並沒有 Gdrive這回事。”一位Google女發言人明確表示。)，公司的軟件程序都駐紮在這些並不昂貴的電腦機箱裏，由程序員決定它們的冗餘工作量。這種由很多單元組成的文件系統代替了商業存儲設備;迪博納表示Google這些單元設備更易於建造和維護，他還暗示他們能處理更大規模的數據。
Google 不會漏過對任何技術細節的關注。多年來，公司的工程師就在研究微處理器的內部工作機制，隨着Google規模的持續壯大，必然會用到特別定製和調節過的芯片。知名工程師路易斯”巴羅索(Luiz Barroso)去年在一篇發表在工業雜誌上的論文中證實，近年來Google的主要負荷都由單核設計的系統承擔着。但許多服務器端的應用，如 Google搜索索引服務，所需的並行計算在單核芯片的指令級別上執行得並不好。
曾在數據設備公司(Digital Equipment)和康柏公司(Compaq)當過芯片設計師的巴羅索認爲，隨着AMD公司、英特爾公司(Intel)、太陽計算機系統公司(Sun)開始製造多核芯片，必將會出現越來越多芯片級別的並行計算。
Google 也曾考慮過自己製造計算機芯片，但從業界潮流來看，這個冒險的舉動似乎不是很必要。“微處理器的設計非常複雜而且成本昂貴，”運營高級副總裁烏爾斯”霍爾茨勒(Urs Holzle)表示。Google寧願與芯片製造商合作，讓他們去理解自己的應用並設計適合的芯片。這是一種客戶建議式的設計，其關注點在於總體吞吐量、效能，以及耗電比，而不是看單線程的峯值性能。霍爾茨勒表示，“這也是最近多核CPU的設計潮流與未來方向。”
裁縫般地定製軟件
爲了能儘量壓榨硬件性能，Google開發了相當數量的定製軟件。創新產品主要包括用於簡化處理和創建大規模數據集的編程模型MapReduce;用於存儲和管理大規模數據的系統BigTable;分析分佈式運算環境中大規模數據集的解釋編程語言Sawzall;用於數據密集型應用的分佈式文件系統的 “Google文件系統”(Google File System);還有爲處理分佈式系統隊列分組和任務調度的“Google工作隊列”(Google Workqueue)。
正是從Sawzall這些工具裏體現出Google對計算效率的執著關注。並不是每家公司都能從底層去解決效率問題，但是對Google來說，爲常規關係型數據庫無法容納的大規模數據集專門設計一種編程語言是完全合理的。即使其他編程工具可以解決問題，Google的工程師們仍然會爲了追求效率而另外開發一套定製方案。Google工程師認爲，Sawzall能與C++中的MapReduce相媲美，而且它更容易編寫一些。
Google 對效率的關注使它不可能對標準Linux內核感到滿意;Google會根據自己的需要運行修改過的內核版本。通過調整Linux的底層性能，Google 工程師們在提高了整體系統可靠性的基礎上，還一併解決了數據損壞和數據瓶頸等一系列棘手問題。對內核的修改也使Google的計算機集羣系統因爲通信效率的提高而運行得更快。
當然，Google偶爾也會出現系統故障，情況一旦發生，無數的用戶就會受到影響了。三年前一次持續30分鐘的系統故障使20%的搜索流量受到影響。
Google 開發了自己的網站服務器卻沒有使用開源的Apache服務器，儘管它在網站服務器的市場佔有率超過60%。迪博納認爲，Google的網站服務器可以運行在更多數量的主機上，對Google站點上內容龐大又彼此互相依賴的應用程序來說，這種服務器的負載均衡能力遠比Apache的能力更高。同時，在用標準公共網關接口(CGI)訪問數據庫動態網頁方面，Google服務器的編程難度要比 Apache更高，但是最終運行速度卻更快。“如果我們能夠壓榨出10%～20%的性能，我們就可以節省出更多系統資源、電量和人力了。”迪博納在總結中指出。
Google還設計了自己的客戶關係管理(CRM)系統用於支持自己基於競價和點擊的互聯網廣告收費業務。但對是否需要設計自己的工具，Google的態度也不是一成不變的。比如在財會軟件上，它就使用了甲骨文公司(Oracle)的Financials軟件。
美林拿着一隻叉子舉例說明現成的產品也可以帶來價值。但在有些場合現成的軟件產品就不一定適用了。“我們的文化在各個層面對我們的運作都有深遠影響，”他表示，“所以我們不想讓購買所得的工具改變我們的工作方式和文化層面。”