Google Cloud
設計原理：
1.分布式文件系統： Google Distributed File System(GSF)
為了滿足Google迅速增長的數據處理需求，我們設計並實現了Google文件系統(Google File System – GFS)。GFS與傳統的分布式文件系統有着很多相同的設計目標，比如，性能、可伸縮性、可靠性以及可用性。但是，我們的設計還基於我們對我們自己的應用 的負載情況和技術環境的觀察的影響，不管現在還是將來，GFS和早期文件系統的假設都有明顯的不同。所以我們重新審視了傳統文件系統在設計上的折衷選擇， 衍生出了完全不同的設計思路。
首先，組件失效被認為是常態事件，而不是意外事件。GFS包括幾百甚至幾千台普通的廉價設備組裝的存儲機器，同時被相當數量的客戶機訪問。 GFS組件的數量和質量導致在事實上，任何給定時間內都有可能發生某些組件無法工作，某些組件無法從它們目前的失效狀態中恢復。我們遇到過各種各樣的問 題，比如應用程序bug、操作系統的bug、人為失誤，甚至還有硬盤、內存、連接器、網絡以及電源失效等造成的問題。所以，持續的監控、錯誤偵測、災難冗 余以及自動恢復的機制必須集成在GFS中。
其次，以通常的標准衡量，我們的文件非常巨大。數GB的文件非常普遍。每個文件通常都包含許多應用程序對象，比如web文檔。當我們經常需要處 理快速增長的、並且由數億個對象構成的、數以TB的數據集時，采用管理數億個KB大小的小文件的方式是非常不明智的，盡管有些文件系統支持這樣的管理方 式。因此，設計的假設條件和參數，比如I/O操作和Block的尺寸都需要重新考慮。
第三，絕大部分文件的修改是采用在文件尾部追加數據，而不是覆蓋原有數據的方式。對文件的隨機寫入操作在實際中幾乎不存在。一旦寫完之后，對文 件的操作就只有讀，而且通常是按順序讀。大量的數據符合這些特性，比如：數據分析程序掃描的超大的數據集；正在運行的應用程序生成的連續的數據流；存檔的 數據；由一台機器生成、另外一台機器處理的中間數據，這些中間數據的處理可能是同時進行的、也可能是后續才處理的。對於這種針對海量文件的訪問模式，客戶 端對數據塊緩存是沒有意義的，數據的追加操作是性能優化和原子性保證的主要考量因素。
第四，應用程序和文件系統API的協同設計提高了整個系統的靈活性。比如，我們放松了對GFS一致性模型的要求，這樣就減輕了文件系統對應用程 序的苛刻要求，大大簡化了GFS的設計。我們引入了原子性的記錄追加操作，從而保證多個客戶端能夠同時進行追加操作，不需要額外的同步操作來保證數據的一 致性。本文后面還有對這些問題的細節的詳細討論。
Google已經針對不同的應用部署了多套GFS集群。最大的一個集群擁有超過1000個存儲節點，超過300TB的硬盤空間，被不同機器上的數百個客戶端連續不斷的頻繁訪問。
2.並行數據處理 MapReduce
MapReduce 解釋：
MapReduce是一種編程模型，用於大規模數據集（大於1TB）的並行運算。概念"Map（映射）"和"Reduce（歸約）"，是它們的主要思想，都是從函數式編程語言里借來的，還有從矢量編程語言里借來的特性。它極大地方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在
分布式系統上。 當前的軟件實現是指定一個Map（映射）函數，用來把一組鍵值對映射成一組新的鍵值對，指定並發的Reduce（歸約）函數，用來保證所有映射的鍵值對中的每一個共享相同的鍵組
MapReduce提供了以下的主要功能：
1）數據划分和計算任務調度：
系統自動將一個作業（Job）待處理的大數據划分為很多個數據塊，每個數據塊對應於一個計算任務（Task），並自動 調度計算節點來處理相應的數據塊。作業和任務調度功能主要負責分配和調度計算節點（Map節點或Reduce節點），同時負責監控這些節點的執行狀態，並 負責Map節點執行的同步控制。
2）數據/代碼互定位：
為了減少數據通信，一個基本原則是本地化數據處理，即一個計算節點盡可能處理其本地磁盤上所分布存儲的數據，這實現了代碼向 數據的遷移；當無法進行這種本地化數據處理時，再尋找其他可用節點並將數據從網絡上傳送給該節點（數據向代碼遷移），但將盡可能從數據所在的本地機架上尋 找可用節點以減少通信延遲。
3）系統優化：
為了減少數據通信開銷，中間結果數據進入Reduce節點前會進行一定的合並處理；一個Reduce節點所處理的數據可能會來自多個 Map節點，為了避免Reduce計算階段發生數據相關性，Map節點輸出的中間結果需使用一定的策略進行適當的划分處理，保證相關性數據發送到同一個 Reduce節點；此外，系統還進行一些計算性能優化處理，如對最慢的計算任務采用多備份執行、選最快完成者作為結果。
4）出錯檢測和恢復：
以低端商用服務器構成的大規模MapReduce計算集群中，節點硬件（主機、磁盤、內存等）出錯和軟件出錯是常態，因此 MapReduce需要能檢測並隔離出錯節點，並調度分配新的節點接管出錯節點的計算任務。同時，系統還將維護數據存儲的可靠性，用多備份冗余存儲機制提 高數據存儲的可靠性，並能及時檢測和恢復出錯的數據。
MapReduce設計上具有以下主要的技術特征：
1）向“外”橫向擴展，而非向“上”縱向擴展
即MapReduce集群的構建完全選用價格便宜、易於擴展的低端商用服務器，而非價格昂貴、不易擴展的高端服務器。
對於大規模數據處理，由於有大 量數據存儲需要，顯而易見，基於低端服務器的集群遠比基於高端服務器的集群優越，這就是為什么MapReduce並行計算集群會基於低端服務器實現的原 因。
2）失效被認為是常態
MapReduce集群中使用大量的低端服務器，因此，節點硬件失效和軟件出錯是常態，因而一個良好設計、具有高容錯性的並行計算系統不能因為節點 失效而影響計算服務的質量，任何節點失效都不應當導致結果的不一致或不確定性；任何一個節點失效時，其他節點要能夠無縫接管失效節點的計算任務；當失效節 點恢復后應能自動無縫加入集群，而不需要管理員人工進行系統配置。
MapReduce並行計算軟件框架使用了多種有效的錯誤檢測和恢復機制，如節點自動重 啟技術，使集群和計算框架具有對付節點失效的健壯性，能有效處理失效節點的檢測和恢復。
3）把處理向數據遷移
傳統高性能計算系統通常有很多處理器節點與一些外存儲器節點相連，如用存儲區域網絡（Storage Area，SAN Network）連接的磁盤陣列，因此，大規模數據處理時外存文件數據I/O訪問會成為一個制約系統性能的瓶頸。
為了減少大規模數據並行計算系統中的數據 通信開銷，代之以把數據傳送到處理節點（數據向處理器或代碼遷移），應當考慮將處理向數據靠攏和遷移。MapReduce采用了數據/代碼互定位的技術方法，計算節點將首先盡量負責計算其本地存儲的數據，以發揮數據本地化特點，僅當節點無法處理本地數據時，再采用就近原則尋找其他可用計算節點，並把數據傳送到該可用計算節點。
4）順序處理數據、避免隨機訪問數據
大規模數據處理的特點決定了大量的數據記錄難以全部存放在內存，而通常只能放在外存中進行處理。由於磁盤的順序訪問要遠比隨機訪問快得多，因此 MapReduce主要設計為面向順序式大規模數據的磁盤訪問處理。
為了實現面向大數據集批處理的高吞吐量的並行處理，MapReduce可以利用集群中 的大量數據存儲節點同時訪問數據，以此利用分布集群中大量節點上的磁盤集合提供高帶寬的數據訪問和傳輸。
5）為應用開發者隱藏系統層細節
軟件工程實踐指南中，專業程序員認為之所以寫程序困難，是因為程序員需要記住太多的編程細節（從變量名到復雜算法的邊界情況處理），這對大腦記憶是 一個巨大的認知負擔，需要高度集中注意力；而並行程序編寫有更多困難，如需要考慮多線程中諸如同步等復雜繁瑣的細節。由於並發執行中的不可預測性，程序的 調試查錯也十分困難；而且，大規模數據處理時程序員需要考慮諸如數據分布存儲管理、數據分發、數據通信和同步、計算結果收集等諸多細節問題。
MapReduce提供了一種抽象機制將程序員與系統層細節隔離開來，程序員僅需描述需要計算什么（What to compute），而具體怎么去計算（How to compute）就交由系統的執行框架處理，這樣程序員可從系統層細節中解放出來，而致力於其應用本身計算問題的算法設計。
6）平滑無縫的可擴展性
這里指出的可擴展性主要包括兩層意義上的擴展性：數據擴展和系統規模擴展性。
理想的軟件算法應當能隨着數據規模的擴大而表現出持續的有效性，性能上的下降程度應與數據規模擴大的倍數相當；在集群規模上，要求算法的計算性能應能隨着節點數的增加保持接近線性程度的增長。絕大多數現有的單機算法都達不到 以上理想的要求；把中間結果數據維護在內存中的單機算法在大規模數據處理時很快失效；從單機到基於大規模集群的並行計算從根本上需要完全不同的算法設計。奇妙的是，MapReduce在很多情形下能實現以上理想的擴展性特征。
多項研究發現，對於很多計算問題，基於MapReduce的計算性能可隨節點數目增長保持近似於線性的增長
3.分布式鎖
: Chubby
首先，Chubby是什么？Chubby主要用於解決分布式一致性問題。在一個分布式系統中，有一組的Process，它們需要確定一個Value。於是每個Process都提出了一個Value，一致性就是指只有其中的一個Value能夠被選中作為最后確定的值，並且當這個值被選出來以后，所有的Process都需要被通知到。這就是一致性問題。
其次，它是一個粗粒度的分布式鎖服務。本質上，Chubby是Google設計的提供粗粒度鎖服務的文件系統，存儲大量小文件。每個文件就代表一個鎖。在GFS中，創建文件就是進行“加鎖”操作，創建文件成功的那個server其實就是搶占到了“鎖”。用戶通過打開、關閉、讀取文件來獲取共享鎖或者獨占鎖；並通過通信機制，向用戶發送更新信息。一群機器需要選舉master時，這些機器同時申請某個鎖文件。成功獲取鎖得服務器當選主服務器，並在文件中寫入自己的地址。其他服務器通過讀取文件中的數據獲取master的地址。其他分布式系統可以使用它對共享資源的訪問進行同步。同時這種鎖服務是建議性的，而非強制性的，這樣能帶來更大的靈活性。
Chubby的設計目標基於以下幾點：高可用性、高可靠性、支持粗粒度的建議性鎖服務、支持小規模文件直接存儲，這些當然是拿高性能與存儲能力tradeoff來的。
4.結構數據表 BigTable
BigTable是非關系型數據庫，是一個稀疏的、
分布式的、持久化存儲的多維度排序Map。Bigtable的設計目的是快速且可靠地處理PB級別的數據，並且能夠部署到上千台機器上
Bigtable已經實現了以下的幾個目標：適用性廣泛、可擴展、高性能和高可用性。
Bigtable不支持完整的
關系數據模型；與之相反，Bigtable為客戶提供了簡單的數據模型，利用這個模型，客戶可以動態控制數據的分布和格式（alex注：也就是對BigTable而言，數據是沒有格式的，用數據庫領域的術語說，就是數據沒有Schema，用戶自己去定義Schema），用戶也可以自己推測(alex注：reasonabout)底層
存儲數據的位置相關性(alex注：位置相關性可以這樣理解，比如樹狀結構，具有相同前綴的數據的存放位置接近。在讀取的時候，可以把這些數據一次讀取出來)。數據的下標是行和列的名字，名字可以是任意的字符串。
Bigtable將
存儲的數據都視為字符串，但是Bigtable本身不去解析這些字符串，客戶程序通常會在把各種結構化或者半結構化的數據
串行化到這些字符串里。通過仔細選擇數據的模式，客戶可以控制數據的位置相關性。最后，可以通過BigTable的模式參數來控制數據是存放在內存中還是硬盤上。
特點:
1、適合大規模海量數據，PB級數據；
3、易於擴展，支持動態伸縮；
4、適用於廉價設備；
5、適合於讀操作，不適合寫操作。
6、不適用於傳統
關系型數據庫；