Google云計算平臺的技術架構及對其成本的影響研究*

孫 健，賈曉菁

（1.中國移動通信集團公司 北京 100032；2.中央財經大學 北京 100081）

Google云計算平臺的技術架構及對其成本的影響研究*

孫 健1，賈曉菁2

（1.中國移動通信集團公司 北京 100032；2.中央財經大學 北京 100081）

本文通過Google云計算平臺與傳統IT系統技術架構的對比研究，指出Google云計算平臺能夠實現極低的計算成本的關鍵在于采用了“自頂向下”的設計思想。

云計算；成本；技術架構

* 國家自然科學基金資助項目（No.70801067），教育部人文社科基金資助項目（No.07JC630052），教育部青年專項課題(No.EFA080250)

1 引言

毫無疑問，云計算是2009年IT行業最熱門的話題，Google、Amazon、Yahoo 等互聯網服務商 ，IBM、Microsoft等IT廠商都紛紛提出了自己的云計算戰略，各電信運營商也對云計算投入了極大的關注，云計算平臺極低的成本成為業界關注的焦點。Google宣稱，由于使用了云計算技術，其計算成本僅為競爭對手的1/100，存儲成本僅為競爭對手的1/30。如果事實真的如此，那么Google究竟是怎么做到的呢？

為了滿足運營管理的需要，電信運營商建設了許多大規模的IT系統，如中國移動建設了業務支撐系統、網絡管理系統和管理信息系統等，這些IT系統一般都是建立在高性能UNIX服務器集群的基礎上，與建立在大量的廉價x86服務器集群基礎上的Google云計算平臺相比，兩者在技術架構等方面存在明顯的差異。本文試圖在深入分析Google云計算平臺關鍵技術的基礎上，通過Google云計算平臺和傳統IT系統的對比研究，尋找出Google云計算平臺極低的計算成本和存儲成本的根本原因。

2 Google云計算平臺的關鍵技術

“云計算”的概念是Google公司首先提出的，其擁有一套專屬的云計算平臺，這個平臺先是為網頁搜索應用提供服務,現在已經擴展到其他應用程序。

作為一種新型的計算方式，Google云計算平臺包含了許多獨特的技術，如數據中心節能技術、節點互聯技術、可用性技術、容錯性技術、數據存儲技術、數據管理技術、數據切分技術、任務調度技術、編程模型、負載均衡技術、并行計算技術和系統監控技術等。

Google云計算平臺是建立在大量的x86服務器集群上的，Node是最基本的處理單元，其總體技術架構如圖1所示。

在Google云計算平臺的技術架構中，除了少量負責特定管理功能的節點 （如 GFS master、Chubby和 Scheduler等），所有的節點都是同構的，即同時運行BigTable Server、GFS chunkserver和MapReduce Job等核心功能模塊，與之相對應的則是數據存儲、數據管理和編程模型等3項關鍵技術，因此本文將重點對它們進行研究。

圖1 Google云計算平臺的技術架構

2.1 數據存儲技術

網頁搜索業務需要海量的數據存儲，同時還需要滿足高可用性、高可靠性和經濟性等要求。為此，Google基于以下幾個假設開發了分布式文件系統——GFS（google file system）。

（1）硬件故障是常態

系統平臺是建立在大量廉價的、消費級的IT部件之上，系統必須時刻進行自我監控、節點檢測和容錯處理，能夠從部件級的錯誤中快速恢復是一個基本的要求。

（2）支持大數據集

系統平臺需要支持海量大文件的存儲，可能包括幾百萬個100 MB以上的文件，GB級別的文件也是常見的。與此同時，小文件也能夠支持，但將不進行專門的優化。

（3）一次寫入、多次讀取的處理模式

Google需要支持對文件進行大量的批量數據寫入操作，并且是追加方式（append）的，即寫入操作結束后文件就幾乎不會被修改了。與此同時，隨機寫入的方式可以支持，但將不進行專門的優化。

（4）高并發性

系統平臺需要支持多個客戶端同時對某一個文件的追加寫入操作，這些客戶端可能分布在幾百個不同的節點上，同時需要以最小的開銷保證寫入操作的原子性。

GFS由一個master和大量塊服務器構成，如圖2所示。master存放文件系統的所有元數據,包括名字空間、存取控制、文件分塊信息、文件塊的位置信息等。GFS中的文件切分成64 MB的塊進行存儲。

為了保證數據的可靠性，GFS文件系統采用了冗余存儲的方式，每份數據在系統中保存3個以上的備份，其中兩份拷貝在同一機架的不同節點上，以充分利用機柜內部帶寬，另外一份拷貝存儲在不同機架的節點上。同時，為了保證數據的一致性,對于數據的所有修改需要在所有的備份上進行,并用版本號的方式來確保所有備份處于一致的狀態。

為避免大量讀操作使master成為系統瓶頸，客戶端不直接通過master讀取數據，而是從master獲取目標數據塊的位置信息后，直接和塊服務器交互進行讀操作。

GFS的寫操作將控制信號和數據流分開，即客戶端在獲取master的寫授權后,將數據傳輸給所有的數據副本，在所有的數據副本都收到修改的數據后，客戶端才發出寫請求控制信號，在所有的數據副本更新完數據后,由主副本向客戶端發出寫操作完成控制信號。

通過服務器端和客戶端的聯合設計，GFS對應用支持達到了性能與可用性的最優化。在Google云計算平臺中部署了多個GFS集群，有的集群擁有超過1000個存儲節點和超過300 TB的硬盤空間，被不同機器上的數百個客戶端連續不斷地頻繁訪問著。

2.2 數據管理技術

由于 Google的許多應用 （包括 Search History、Maps、Orkut和RSS閱讀器等）需要管理大量的格式化以及半格式化數據，上述應用的共同特點是需要支持海量的數據存儲，讀取后進行大量的分析，數據的讀操作頻率遠大于數據的更新頻率等，為此Google開發了弱一致性要求的大規模數據庫系統——BigTable。

BigTable針對數據讀操作進行了優化，采用基于列存儲的分布式數據管理模式以提高數據讀取效率。BigTable的基本元素是行、列、記錄板和時間戳。其中,記錄板Tablet就是一段行的集合體，如圖3所示。

BigTable中的數據項按照行關鍵字的字典序排列，每行動態地劃分到記錄板中，每個服務器節點Tablet Server負責管理大約100個記錄板。時間戳是一個64位的整數,表示數據的不同版本。列簇是若干列的集合，BigTable中的存取權限控制在列簇的粒度進行。

BigTable系統依賴于集群系統的底層結構，一個是分布式的集群任務調度器，一個是前述的GFS文件系統，還有一個分布式的鎖服務Chubby，如圖4所示。Chubby是一個非常健壯的粗粒度鎖，BigTable使用Chubby來保存Root Tablet的指針，并使用一臺服務器作為主服務器，用來保存和操作元數據。當客戶端讀取數據時,用戶首先從Chubby Server中獲得Root Tablet的位置信息，并從中讀取相應的元數據表Metadata Tablet的位置信息，接著從Metadata Tablet中讀取包含目標數據位置信息的User Table的位置信息，然后從該User Table中讀取目標數據的位置信息項。

BigTable的主服務器除了管理元數據之外，還負責對Tablet Server進行遠程管理與負載調配。客戶端通過編程接口與主服務器進行控制通信以獲得元數據，與Tablet Server進行數據通信，而具體的讀寫請求則由Tablet Server負責處理。

與前述的系統類似，BigTable也是客戶端和服務器端的聯合設計，使得性能能夠最大程度地符合應用的需求。

2.3 編程模型

Google構造了Map-Reduce編程框架來支持并行計算，應用程序編寫人員只需將精力放在應用程序本身，關于如何通過分布式的集群來支持并行計算，包括可靠性和可擴展性，則交由平臺來處理，從而保證了后臺復雜的并行執行和任務調度向用戶和編程人員透明。

Map-Reduce是一種處理和產生大規模數據集的編程模型，同時也是一種高效的任務調度模型，它通過“Map(映射)”和“Reduce(化簡)”這樣兩個簡單的概念來構成運算基本單元，程序員在Map函數中指定對各分塊數據的處理過程,在Reduce函數中指定如何對分塊數據處理的中間結果進行歸約，就能完成分布式的并行程序開發。當在集群上運行Map-Reduce程序時,程序員不需要關心如何將輸入的數據分塊、分配和調度,同時系統還將處理集群內節點失敗以及節點間通信的管理等。圖5給出了一個Map-Reduce程序的具體執行過程。

從圖5可以看出,執行一個Map-Reduce程序需要5個步驟：輸入文件，將文件分配給多個worker并行地執行，寫中間文件(本地寫)，多個Reduce worker同時運行，輸出最終結果。本地寫中間文件減少了對網絡帶寬的壓力，同時減少了寫中間文件的時間耗費；執行Reduce時,根據從master獲得的中間文件位置信息，Reduce使用遠程過程調用，從中間文件所在節點讀取所需的數據。

圖5 Map-Reduce程序的具體執行過程

Map-Reduce模型具有很強的容錯性，當worker節點出現錯誤時,只需要將該worker節點屏蔽在系統外等待修復，并將該worker上執行的程序遷移到其他worker上重新執行，同時將該遷移信息通過master發送給需要該節點處理結果的節點。Map-Reduce使用檢查點的方式來處理master出錯失敗的問題，當master出現錯誤時，可以根據最近的一個檢查點重新選擇一個節點作為master并由此檢查點位置繼續運行。

3 Google云計算平臺與傳統IT系統的差異

傳統的IT系統，尤其是大型的IT系統，幾乎都是建立在高性能UNIX服務器集群的基礎上，其體系架構先后經歷了主機/終端和Client/Server等發展階段，隨著互聯網的發展，目前主流IT系統大多采用了三層Browser/Server架構，如圖6所示。下面我們將從數據存儲、數據管理和編程框架三個方面分析其與Google云計算平臺之間的差異。

圖6 Browser/Server的技術架構

3.1 數據存儲技術

對于數據存儲技術來說，存儲可靠性、I/O吞吐能力和可擴展性是最核心的技術指標。

傳統IT系統的數據儲存技術主要包括直連式存儲(DAS)、網絡接入存儲(NAS)和存儲區域網(SAN)等。在存儲可靠性方面，RAID技術能夠很好地解決單個磁盤的故障問題，但是需要增加RAID控制卡等硬件設備。在提高I/O吞吐能力和可擴展性方面，由于DAS依賴服務器的操作系統進行數據的I/O讀寫和存儲維護管理，難以滿足大型IT系統對性能的要求，為此先后出現了NAS和SAN等新的數據存儲技術，盡管兩者在文件系統的分布上存在一些差異，但其基本策略是一致的，即將數據儲存從服務器中分離出來，采用專門的硬件設備進行集中的管理，其實質是計算和數據的分離，如圖7所示。

圖7 NAS和SAN的基本原理

在Google云計算平臺的體系架構中，單個節點Node采用的是廉價的x86服務器，每個節點在負責計算的同時，還需要通過GFS Chunk Server管理本節點存儲的數據，也就是說，繼續保持了計算和數據的統一。GFS放棄使用RAID技術，采取了簡單的冗余存儲的方法，不僅能夠滿足存儲可靠性的要求，還有效提升了讀操作的性能。為了減少單個節點的處理負荷，Google單個節點所管理的裸數據量一般小于1 TB，但是通過大量節點的并行處理，很好地滿足了海量數據存儲的要求。

需要指出的是，對于Google云計算平臺來說，其寫操作的效率是非常低下的，但是由于其承載的應用大多具有“一次寫入，多次讀取”的特點，在實際應用中很少成為瓶頸問題。

3.2 數據管理技術

在數據管理技術中，如何提高數據庫系統的性能是最核心的問題。

傳統IT系統采用集中的數據存儲方式，并通過使用關系型數據庫管理系統（RDBMS）實現集中的數據管理，為了避免數據庫服務器成為系統性能的瓶頸問題，主要采用了數據緩存、索引和數據分區等技術，但是對于Google云計算平臺所承載的網頁搜索等應用來說，由于需要大量的全文檢索，上述技術都難以充分發揮作用，因此BigTable針對其應用中數據讀操作占比很高的特點，設計了簡化的數據表結構，并采用基于列存儲的分布式數據管理模式，很好地滿足了海量數據管理、高并發性和苛刻的響應時間等要求。

傳統IT系統普遍采取在服務器集群中進行任務分工的方法，以降低數據庫服務器負荷并提高系統整體性能，例如在B/S體系結構下，Web服務器負責接收用戶通過瀏覽器發出的請求，應用服務器負責調用相應的組件完成業務邏輯的處理，數據庫服務器只需要實現對數據庫的查詢、修改和更新等功能。但是，對于Google云計算平臺來說，由于網頁搜索等應用一般都是簡單的讀操作，并不包含復雜的業務邏輯，傳統的B/S架構難以顯著降低數據庫服務器的負荷，因此Google將并行計算引入數據庫系統中，將數據分散在大量完全同構的節點上，通過Tablet Server同時提供數據管理服務，從而將處理負荷均勻地分布在每個節點上，極大地提升了數據庫系統的性能。

需要指出的是，在傳統IT系統中也有類似于BigTable的多節點并行的數據庫系統，例如Oracle的并行集群Oracle Real Application Server（簡稱 Oracle RAC），如圖 8 所示。由于Oracle RAC采用了“集中存儲+內存融合”的體系架構，不同節點之間需要通過私有網絡進行通信，對網絡帶寬和節點之間的時鐘同步有很高的要求。因此，在實際應用中節點數量很難超過4個，與Google云計算平臺支持1000個以上節點的規模相比，其擴展能力存在很大的差距。

值得注意的是，與傳統的RDBMS相比，BigTable也存在許多缺點，例如類似數據庫中的Join操作效率太低、只支持string的數據類型，不支持全表的排序運算，不支持多個表的關系運算，不支持多行的事務，不支持跨表的事務，對ACID的支持有限等，但是由于Google云計算平臺所承載的應用并不是以OLTP事務處理為重點，這些缺點并不會產生嚴重的影響。

3.3 編程框架

在傳統IT系統中，為了充分利用UNIX多任務操作系統的優勢，并發執行（concurrency）是一種常見的編程框架，如采用多進程、多線程等技術以提高處理性能 （如圖9所示），與Google采用的Map-Reduce編程框架相比，兩者之間存在的差異主要在以下兩方面。

圖8 Oracle RAC的系統架構

圖9 Map-Reduce模式和并行執行模式的對比

·在并行執行模式下，數據是集中管理的（通常是由一個關系型數據庫系統RDBMS來負責完成），每個應用都可以直接操作數據庫中的數據，由數據庫系統負責保證數據的一致性和完整性。在Map-Reduce模式下，由于數據是由每個節點分散進行管理的，不存在獨立的、集中的數據庫系統，每個節點只能對自己所管理的數據進行操作，因此需要上層應用軟件的干預，以保證跨節點的數據的一致性和完整性。

·在Map-Reduce模式下，增加了對任務的分解Map以及結果的規約Reduce等處理環節，以支持多個worker節點的并行處理，同時還需要完成worker節點失效處理以及worker節點間的協調通信等工作，因此系統處理負荷有所增加，但是考慮到大規模并行處理所帶來的巨大優勢，這種代價是完全值得的。

事實上，Map-Reduce這種編程模型并不僅適用于Google云計算平臺,在多核和多處理器、cell processor以及異構機群上同樣都有良好的性能，但是，該編程模式僅適用于編寫任務內部松耦合并能夠高度并行化的程序，如何改進該編程模式,使程序員能夠輕松地編寫緊耦合的程序，運行時能高效地調度和執行任務，是Map-Reduce編程模型未來的發展方向，同時基于Map-Reduce的開發工具Hadoop目前并不完善，特別是調度算法過于簡單,降低了整個系統的性能，仍需要繼續完善和提高。

4 Google云計算平臺的成本分析

Google云計算平臺獨特的技術架構對其總體成本產生了深刻的影響，主要體現在以下5個方面。

·由于采用了分布式的數據存儲和數據管理方式，降低了對單個節點處理能力的要求，因此Google不需要購買價格昂貴的UNIX服務器和SAN存儲設備，而是采用廉價的消費級x86芯片和內置硬盤來構建服務器集群，大大減少了建設投資。根據中國移動研究院的測算，在滿足相同處理能力的前提下，其設備投資只有UNIX平臺的1/6。

·Google云計算平臺中除少量的管理節點以外，各個節點均是同構的，同時承擔數據存儲、數據管理和任務管理等功能，因此很容易實現設備的標準化，通過大批量采購專門定制的計算機主板，裁減一切與計算無關的部件 （如顯示器、外設接口甚至機箱外殼等）等方式，進一步地降低了設備投資。

·Google云計算平臺將硬件失效視為常態，轉而通過軟件容錯的方式實現節點之間的自動切換來實現高可用性，大大減少了設備冗余。例如，假設單個節點的可靠性為95%，傳統IT系統采用1+1的備份方式時系統可靠性為99.75%，但此時設備冗余為100%，采用100個節點的Google云計算平臺時，達到相同的可靠性水平只需要增加12%的設備冗余，設備投資減少了44%。設備冗余的減少帶來了設備利用率的提高，據Google宣稱，其設備利用率可以達到一般企業的280%。

·基于并行計算的獨特優勢，Google開發了優秀的負載均衡技術，能夠在全球范圍通過不同數據中心的動態負載切換的方式保證業務連續性，因此對單個數據中心來說，對電源和空調等配套設備的要求大大降低。Google的數據中心僅在服務器主板上安裝小型備用電池，舍棄了傳統IT系統所必須的不間斷電源系統（UPS），同時通過將數據中心建設在山區等寒冷地帶，將機房專用空調系統改為地下水冷卻系統等方式，大大降低了配套設備的建設投資和運營成本。據Google宣稱，其6個數據中心的平均PUE（電能利用率）為1.21，年度最優數據中心的PUE為1.15，在某一特定季度的PUE值為1.13，而傳統數據中心的PUE一般為3.0或者更大。

·Google云計算平臺大量采用Linux等開源軟件以及自行開發的專用組件，幾乎不需要系統軟件的投資。對于傳統IT系統來說，操作系統、數據庫和中間件等系統軟件占建設投資的比重一般超過15%，而且還需要持續支付版本升級、維護支持等運營成本，對成本的影響是不言而喻的。

基于以上分析我們可以得出判斷，Google宣稱其極低的計算成本和存儲成本是完全可行的，同時這也充分表明了技術架構對IT系統成本所起到的決定性作用。

盡管Google云計算平臺采用的數據存儲、數據管理和編程框架等技術都存在不同程度的缺陷，有些甚至是非常嚴重的，但是由于其云計算平臺的建設目標是為某些特定的業務提供服務，因此這些技術缺陷不僅沒有成為問題，反而在有效滿足業務需求的同時，極大地減少了建設投資和運營成本。

5 結束語

通過對Google平臺技術架構的分析，可以發現其3個基本特征，即：系統建立在大規模的廉價服務器集群之上；通過基礎設施與上層應用程序的協同構建以達到最大效率利用硬件資源的目的；通過軟件的方法實現節點的容錯，這些都與基于高性能UNIX服務器集群的傳統IT系統形成了強烈的反差。

實際上，這種平臺技術架構的差異來源于完全不同的設計思想。傳統IT系統采用的是“自下而上”的設計方法，以逐層堆疊的方式承載上層應用，強調基礎設施對應用透明，分層的集中管理以及通過工業標準實現異構設備的互聯，其本質上是一種通用平臺，而Google云計算平臺則采用了“自頂向下”的設計方法，即從上層應用出發，根據特定應用的業務特征對基礎設施進行改造 （而不是一般意義的優化），其本質上是一種專用平臺，這也是Google云計算平臺具有極低的計算成本和存儲成本的根本原因。

1 Sanjay Ghemawat,Howard Gobioff,Shun-Tak Leung.The google file system,http://labs.google.com/papers/gfs-sosp2003.pdf

2 Mike Burrows.The chubby lock service for loosely-coupled distributed systems,http://labs.google.com/papers/chubby-osdi06.pdf

3 Dean J,Ghemawat S.Distributed programming with mapreduce.Oram A,Wilson G,eds.Beautiful Code.Sebastopol:O’Reilly Media,Inc.,2007:371～384

4 陳康,鄭緯民.云計算:系統實例與研究現狀.軟件學報,2009(5)

5 陳全,鄧倩妮.云計算及其關鍵技術.計算機應用,2009(9)

6 NGBOSS1-CRM技術規范.中國移動通信企業標準,2009

7 云計算平臺的并行數據挖掘工具對經分系統的業務支撐能力的研究,中國移動通信集團上海有限公司,2009

A Study of the Influence of Technical Architecture on the Total Cost of Google Cloud Computing Platform

Sun Jian1，Jia Xiaojing2
(1.China Mobile Communications Corporation,Beijing 100032,China;2.Central University of Finance and Economics,Beijing 100081,China)

This paper compares the technical architecture between Google cloud computing platform and traditional IT system,and posts that the key of extremely low cost of google cloud computing platform is applying the “top-down” design method to infrastructure construction.

cloud computing,cost,technology architecture

2009－11－12)