摘要: 本系列是基於公開資料對Google App Engine是如何實現的這個話題進行深度探討。而且在切入Google App Engine之前，首先會對Google的核心技術和其整體架構進行分析，以幫助大家之後更好地理解Google App Engine的實現。 ...
本系列是基於公開資料對Google App Engine是如何實現的這個話題進行深度探討。而且在切入Google App
Engine之前，首先會對Google的核心技術和其整體架構進行分析，以幫助大家之後更好地理解Google App Engine的實現。
本篇將主要介紹Google的十個核心技術，而且可以分爲四大類：
分佈式基礎設施：GFS，Chubby和Protocol Buffer。
分佈式大規模數據處理：MapReduce和Sawzall。
分佈式數據庫技術：BigTable和數據庫Sharding。
數據中心優化技術：數據中心高溫化，12V電池和服務器整合。
分佈式基礎設施
GFS
由於搜索引擎需要處理海量的數據，所以Google的兩位創始人Larry Page和Sergey
Brin在創業初期設計一套名爲“BigFiles”的文件系統，而GFS（全稱爲“Google File
System”）這套分佈式文件系統則是“BigFiles”的延續。
首先，介紹它的架構，GFS主要分爲兩類節點：
Master節點：主要存儲與數據文件相關的元數據，而不是Chunk（數據塊）。元數據包括一個能將64位標籤映射到數據塊的位置及其組成文件
的表格，數據塊副本位置和哪個進程正在讀寫特定的數據塊等。還有Master節點會週期性地接收從每個Chunk節點來的更新（”Heart-
beat”）來讓元數據保持最新狀態。
Chunk節點：顧名思義，肯定用來存儲Chunk，數據文件通過被分割爲每個默認大小爲64MB的Chunk的方式存儲，而且每個Chunk有
唯一一個64位標籤，並且每個Chunk都會在整個分佈式系統被複制多次，默認爲3次。
下圖就是GFS的架構圖：
圖1. GFS的架構圖（參片[15]）
接着，在設計上，GFS主要有八個特點：
大文件和大數據塊：數據文件的大小普遍在GB級別，而且其每個數據塊默認大小爲64MB，這樣做的好處是減少了元數據的大小，能使Master節
點能夠非常方便地將元數據放置在內存中以提升訪問效率。
操作以添加爲主：因爲文件很少被刪減或者覆蓋，通常只是進行添加或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大和隨機讀寫慢的特點。
支持容錯：首先，雖然當時爲了設計方便，採用了單Master的方案，但是整個系統會保證每個Master都會有其相對應的複製品，以便於在
Master節點出現問題時進行切換。其次，在Chunk層，GFS已經在設計上將節點失敗視爲常態，所以能非常好地處理Chunk節點失效的問題。
高吞吐量：雖然其單個節點的性能無論是從吞吐量還是延遲都很普通，但因爲其支持上千的節點，所以總的數據吞吐量是非常驚人的。
保護數據：首先，文件被分割成固定尺寸的數據塊以便於保存，而且每個數據塊都會被系統複製三份。
擴展能力強：因爲元數據偏小，使得一個Master節點能控制上千個存數據的Chunk節點。
支持壓縮：對於那些稍舊的文件，可以通過對它進行壓縮，來節省硬盤空間，並且壓縮率非常驚人，有時甚至接近90%。
用戶空間：雖然在用戶空間運行在運行效率方面稍差，但是更便於開發和測試，還有能更好利用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所無法支持的特性：
支持多種數據結構，比如table，familie，group和coprocessor等。
基於分層目錄和行的細粒度的複製和權限管理。
支持跨數據中心的強一致性和弱一致性控制。
基於Paxos算法的強一致性副本同步，並支持分佈式事務。
提供許多自動化操作。
強大的擴展能力，能支持百萬臺服務器級別的集羣。
用戶可以自定義諸如延遲和複製次數等重要參數以適應不同的需求。
數據庫Sharding
Sharding就是分片的意思，雖然非關係型數據庫比如BigTable在Google的世界中佔有非常重要的地位，但
是面對傳統OLTP應用，比如廣告系統，Google還是採用傳統的關係型數據庫技術，也就是MySQL，同時由於Google所需要面對流量非常巨大，
所以Google在數據庫層採用了分片（Sharding）的水平擴展（Scale Out）解決方案，分片是在傳統垂直擴展（Scale
Up）的分區模式上的一種提升，主要通過時間，範圍和麪向服務等方式來將一個大型的數據庫分成多片，並且這些數據片可以跨越多個數據庫和服務器來實現水平
擴展。
Google整套數據庫分片技術主要有下面這些優點：
擴展性強：在Google生產環境中，已經有支持上千臺服務器的MySQL分片集羣。
吞吐量驚人：通過巨大的MySQL分片集羣能滿足巨量的查詢請求。
全球備份：不僅在一個數據中心還是在全球的範圍，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在硬件方面也引
入類似服務器整合的想法，它的做法是在一個機箱大小的空間內放置兩臺服務器，這些做的好處有很多，首先，減小了佔地面積。其次，通過讓兩臺服務器共享諸如
電源等設備，來降低設備和能源等方面的投入。