原文連結:  http://www.alibuybuy.com/posts/24118.html

本系列是基於公開資料對Google App Engine是如何實現的這個話題進行深度探討。而且在切入Google App Engine之前，首先會對Google的核心技術和其整體架構進行分析，以幫助大家之後更好地理解Google App Engine的實現。

本篇將主要介紹Google的十個核心技術，而且可以分為四大類：

1. 1. 分散式基礎設施：GFS，Chubby和Protocol Buffer。
   2. 分散式大規模資料處理：MapReduce和Sawzall。
   3. 分散式資料庫技術：BigTable和資料庫Sharding。
   4. 資料中心優化技術：資料中心高溫化，12V電池和伺服器整合。

分散式基礎設施

GFS

由於搜尋引擎需要處理海量的資料，所以Google的兩位創始人Larry Page和Sergey Brin在創業初期設計一套名為“BigFiles”的檔案系統，而GFS（全稱為“Google File System”）這套分散式檔案系統則是“BigFiles”的延續。

首先，介紹它的架構，GFS主要分為兩類節點：

1. 1. Master節點：主要儲存與資料檔案相關的元資料，而不是Chunk（資料塊）。元資料包括一個能將64位標籤對映到資料塊的位置及其組成檔案 的表格，資料塊副本位置和哪個程序正在讀寫特定的資料塊等。還有Master節點會週期性地接收從每個Chunk節點來的更新（”Heart- beat”）來讓元資料保持最新狀態。
   2. Chunk節點：顧名思義，肯定用來儲存Chunk，資料檔案通過被分割為每個預設大小為64MB的Chunk的方式儲存，而且每個Chunk有 唯一一個64位標籤，並且每個Chunk都會在整個分散式系統被複制多次，預設為3次。

下圖就是GFS的架構圖：

圖1. GFS的架構圖（參片[15]）

接著，在設計上，GFS主要有八個特點：

1. 1. 大檔案和大資料塊：資料檔案的大小普遍在GB級別，而且其每個資料塊預設大小為64MB，這樣做的好處是減少了元資料的大小，能使Master節 點能夠非常方便地將元資料放置在記憶體中以提升訪問效率。
   2. 操作以新增為主：因為檔案很少被刪減或者覆蓋，通常只是進行新增或者讀取操作，這樣能充分考慮到硬碟線性吞吐量大和隨機讀寫慢的特點。
   3. 支援容錯：首先，雖然當時為了設計方便，採用了單Master的方案，但是整個系統會保證每個Master都會有其相對應的複製品，以便於在 Master節點出現問題時進行切換。其次，在Chunk層，GFS已經在設計上將節點失敗視為常態，所以能非常好地處理Chunk節點失效的問題。
   4. 高吞吐量：雖然其單個節點的效能無論是從吞吐量還是延遲都很普通，但因為其支援上千的節點，所以總的資料吞吐量是非常驚人的。
   5. 保護資料：首先，檔案被分割成固定尺寸的資料塊以便於儲存，而且每個資料塊都會被系統複製三份。
   6. 擴充套件能力強：因為元資料偏小，使得一個Master節點能控制上千個存資料的Chunk節點。
   7. 支援壓縮：對於那些稍舊的檔案，可以通過對它進行壓縮，來節省硬碟空間，並且壓縮率非常驚人，有時甚至接近90%。
   8. 使用者空間：雖然在使用者空間執行在執行效率方面稍差，但是更便於開發和測試，還有能更好利用Linux的自帶的一些POSIX API。

現在Google內部至少執行著200多個GFS叢集，最大的叢集有幾千臺伺服器，並且服務於多個Google服務，比如 Google搜尋。但由於GFS主要為搜尋而設計，所以不是很適合新的一些Google產品，比YouTube、Gmail和更強調大規模索引和實時性的 Caffeine搜尋引擎等，所以Google已經在開發下一代GFS，代號為“Colossus”，並且在設計方面有許多不同，比如：支援分散式 Master節點來提升高可用性並能支撐更多檔案，chunk節點能支援1MB大小的chunk以支撐低延遲應用的需要。

Chubby

簡單的來說，Chubby屬於分散式鎖服務，通過Chubby，一個分散式系統中的上千個client都能夠對於某項資源進行“加鎖”或者“解 鎖”，常用於BigTable的協作工作，在實現方面是通過對檔案的建立操作來實現“加鎖”，並基於著名科學家Leslie Lamport的Paxos演算法。

Protocol Buffer

Protocol Buffer，是Google內部使用一種語言中立，平臺中立和可擴充套件的序列化結構化資料的方式，並提供java、c++ 和python這三種語言的實現，每一種實現都包含了相應語言的編譯器以及庫檔案，而且它是一種二進位制的格式，所以其速度是使用xml進行資料交換的10 倍左右。它主要用於兩個方面：其一是RPC通訊，它可用於分散式應用之間或者異構環境下的通訊。其二是資料儲存方面，因為它自描述，而且壓縮很方便，所以 可用於對資料進行持久化，比如儲存日誌資訊，並可被Map Reduce程式處理。與Protocol Buffer比較類似的產品還有Facebook的Thrift，而且Facebook號稱Thrift在速度上還有一定的優勢。

分散式大規模資料處理

MapReduce

首先，在Google資料中心會有大規模資料需要處理，比如被網路爬蟲（Web Crawler）抓取的大量網頁等。由於這些資料很多都是PB級別，導致處理工作不得不盡可能的並行化，而Google為了解決這個問題，引入了 MapReduce這個程式設計模型，MapReduce是源自函式式語言，主要通過”Map（對映）”和”Reduce（化簡）”這兩個步驟來並行處理大規 模的資料集。Map會先對由很多獨立元素組成的邏輯列表中的每一個元素進行指定的操作，且原始列表不會被更改，會建立多個新的列表來儲存Map的處理結 果。也就意味著，Map操作是高度並行的。當Map工作完成之後，系統會先對新生成的多個列表進行清理（Shuffle）和排序，之後會這些新建立的列表 進行Reduce操作，也就是對一個列表中的元素根據Key值進行適當的合併。

下圖為MapReduce的執行機制：

圖2. MapReduce的執行機制（參[19]）

接下來，將根據上圖來舉一個MapReduce的例子：比如，通過搜尋Spider將海量的Web頁面抓取到本地的GFS 叢集中，然後Index系統將會對這個GFS叢集中多個數據Chunk進行平行的Map處理，生成多個Key為URL，value為html頁面的鍵值對 （Key-Value Map），接著系統會對這些剛生成的鍵值對進行Shuffle（清理），之後系統會通過Reduce操作來根據相同的key值（也就是URL）合併這些鍵 值對。

最後，通過MapReduce這麼簡單的程式設計模型，不僅能用於處理大規模資料，而且能將很多繁瑣的細節隱藏起來，比如自動並行化，負載均衡和機器宕 機處理等，這樣將極大地簡化程式設計師的開發工作。MapReduce可用於包括“分佈grep，分佈排序，web訪問日誌分析，反向索引構建，文件聚類，機 器學習，基於統計的機器翻譯，生成Google的整個搜尋的索引“等大規模資料處理工作。Yahoo也推出MapReduce的開源版本Hadoop，而 且Hadoop在業界也已經被大規模使用。

Sawzall

Sawzall可以被認為是構建在MapReduce之上的採用類似Java語法的DSL（Domain-Specific Language），也可以認為它是分散式的AWK。它主要用於對大規模分散式資料進行篩選和聚合等高階資料處理操作，在實現方面，是通過直譯器將其轉化 為相對應的MapReduce任務。除了Google的Sawzall之外，yahoo推出了相似的Pig語言，但其語法類似於SQL。

分散式資料庫技術

BigTable

由於在Google的資料中心儲存PB級以上的非關係型資料時候，比如網頁和地理資料等，為了更好地儲存和利用這些資料，Google開發了一套數 據庫系統，名為“BigTable”。BigTable不是一個關係型的資料庫，它也不支援關聯（join）等高階SQL操作，取而代之的是多級對映的數 據結構，並是一種面向大規模處理、容錯性強的自我管理系統，擁有TB級的記憶體和PB級的儲存能力，使用結構化的檔案來儲存資料，並每秒可以處理數百萬的讀 寫操作。

什麼是多級對映的資料結構呢？就是一個稀疏的，多維的，排序的Map，每個Cell由行關鍵字，列關鍵字和時間戳三維定位．Cell的內容是一個不 解釋的字串，比如下表儲存每個網站的內容與被其他網站的反向連線的文字。 反向的URL com.cnn.www是這行的關鍵字；contents列儲存網頁內容，每個內容有一個時間戳，因為有兩個反向連線，所以archor的Column Family有兩列：anchor: cnnsi.com和anchhor:my.look.ca。Column Family這個概念，使得表可以輕鬆地橫向擴充套件。下面是它具體的資料模型圖：

圖3. BigTable資料模型圖（參[4]）

在結構上，首先，BigTable基於GFS分散式檔案系統和Chubby分散式鎖服務。其次BigTable也分為兩部分：其一是Master節 點，用來處理元資料相關的操作並支援負載均衡。其二是tablet節點，主要用於儲存資料庫的分片tablet，並提供相應的資料訪問，同時tablet 是基於名為SSTable的格式，對壓縮有很好的支援。

圖4. BigTable架構圖（參[15]）

BigTable正在為Google六十多種產品和專案提供儲存和獲取結構化資料的支撐平臺，其中包括有Google Print， Orkut，Google Maps，Google Earth和Blogger等，而且Google至少執行著500個BigTable叢集。

隨著Google內部服務對需求的不斷提高和技術的不斷地發展，導致原先的BigTable已經無法滿足使用者的需求，而 Google也正在開發下一代BigTable，名為“Spanner（扳手）”，它主要有下面這些BigTable所無法支援的特性：

1. 1. 支援多種資料結構，比如table，familie，group和coprocessor等。
   2. 基於分層目錄和行的細粒度的複製和許可權管理。
   3. 支援跨資料中心的強一致性和弱一致性控制。
   4. 基於Paxos演算法的強一致性副本同步，並支援分散式事務。
   5. 提供許多自動化操作。
   6. 強大的擴充套件能力，能支援百萬臺伺服器級別的叢集。
   7. 使用者可以自定義諸如延遲和複製次數等重要引數以適應不同的需求。

資料庫Sharding

Sharding就是分片的意思，雖然非關係型資料庫比如BigTable在Google的世界中佔有非常重要的地位，但 是面對傳統OLTP應用，比如廣告系統，Google還是採用傳統的關係型資料庫技術，也就是MySQL，同時由於Google所需要面對流量非常巨大， 所以Google在資料庫層採用了分片（Sharding）的水平擴充套件（Scale Out）解決方案，分片是在傳統垂直擴充套件（Scale Up）的分割槽模式上的一種提升，主要通過時間，範圍和麵向服務等方式來將一個大型的資料庫分成多片，並且這些資料片可以跨越多個數據庫和伺服器來實現水平 擴充套件。

Google整套資料庫分片技術主要有下面這些優點：

1. 1. 擴充套件性強：在Google生產環境中，已經有支援上千臺伺服器的MySQL分片叢集。
   2. 吞吐量驚人：通過巨大的MySQL分片叢集能滿足巨量的查詢請求。
   3. 全球備份：不僅在一個數據中心還是在全球的範圍，Google都會對MySQL的分片資料進行備份，這樣不僅能保護資料，而且方便擴充套件。

在實現方面，主要可分為兩塊：其一是在MySQL InnoDB基礎上添加了資料庫分片的技術。其二是在ORM層的Hibernate的基礎上也添加了相關的分片技術，並支援虛擬分片（Virtual Shard）來便於開發和管理。同時Google也已經將這兩方面的程式碼提交給相關組織。

資料中心優化技術

資料中心高溫化

大中型資料中心的PUE（Power Usage Effectiveness）普遍在2左右，也就是在伺服器等計算裝置上耗1度電，在空調等輔助裝置上也要消耗一度電。對一些非常出色的資料中心，最多也 就能達到1.7，但是Google通過一些有效的設計使部分資料中心到達了業界領先的1.2，在這些設計當中，其中最有特色的莫過於資料中心高溫化，也就 是讓資料中心內的計算裝置執行在偏高的溫度下，Google的能源方面的總監Erik Teetzel在談到這點的時候說：“普通的資料中心在70華氏度（21攝氏度）下面工作，而我們則推薦80華氏度（27攝氏度）“。但是在提高資料中心 的溫度方面會有兩個常見的限制條件：其一是伺服器裝置的崩潰點，其二是精確的溫度控制。如果做好這兩點，資料中心就能夠在高溫下工作，因為假設資料中心的 管理員能對資料中心的溫度進行正負1/2度的調節，這將使伺服器裝置能在崩潰點5度之內工作，而不是常見的20度之內，這樣既經濟，又安全。還有，業界傳 言Intel為Google提供抗高溫設計的定製晶片，但云計算界的頂級專家James Hamilton認為不太可能，因為雖然處理器也非常懼怕熱量，但是與記憶體和硬碟相比還是強很多，所以處理器在抗高溫設計中並不是一個核心因素。同時他也 非常支援使資料中心高溫化這個想法，而且期望將來資料中心甚至能執行在40攝氏度下，這樣不僅能節省空調方面的成本，而且對環境也很有利。

12V電池

由於傳統的UPS在資源方面比較浪費，所以Google在這方面另闢蹊徑，採用了給每臺伺服器配一個專用的12V電池的做 法來替換了常用的UPS，如果主電源系統出現故障，將由該電池負責對伺服器供電。雖然大型UPS可以達到92%到95%的效率，但是比起內建電池的 99.99%而言是非常捉襟見肘的，而且由於能量守恆的原因，導致那麼未被UPS充分利用的電力會被轉化成熱能，這將導致用於空調的能耗相應地攀升，從而 走入一個惡性迴圈。同時在電源方面也有類似的“神來之筆”，普通的伺服器電源會同時提供5V和12V的直流電。但是Google設計的伺服器電源只輸出 12V直流電，必要的轉換在主機板上進行，雖然這種設計會使主機板的成本增加1美元到2美元，但是它不僅能使電源能在接近其峰值容量的情況下執行，而且在銅線 上傳輸電流時效率更高。

伺服器整合

談到虛擬化的殺手鐗時，第一個讓人想到肯定是伺服器整合，而且普遍能實現1:8的整合率來降低各方面的成本。有趣的是，Google在硬體方面也引 入類似伺服器整合的想法，它的做法是在一個機箱大小的空間內放置兩臺伺服器，這些做的好處有很多，首先，減小了佔地面積。其次，通過讓兩臺伺服器共享諸如 電源等裝置，來降低裝置和能源等方面的投入。