Google云計(jì)算平臺的技術(shù)架構(gòu)及對其成本的影響研究*

孫 健，賈曉菁

（1.中國移動(dòng)通信集團(tuán)公司 北京 100032；2.中央財(cái)經(jīng)大學(xué) 北京 100081）

Google云計(jì)算平臺的技術(shù)架構(gòu)及對其成本的影響研究*

孫 健1，賈曉菁2

（1.中國移動(dòng)通信集團(tuán)公司 北京 100032；2.中央財(cái)經(jīng)大學(xué) 北京 100081）

本文通過Google云計(jì)算平臺與傳統(tǒng)IT系統(tǒng)技術(shù)架構(gòu)的對比研究，指出Google云計(jì)算平臺能夠?qū)崿F(xiàn)極低的計(jì)算成本的關(guān)鍵在于采用了“自頂向下”的設(shè)計(jì)思想。

云計(jì)算；成本；技術(shù)架構(gòu)

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

1 引言

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

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

2 Google云計(jì)算平臺的關(guān)鍵技術(shù)

“云計(jì)算”的概念是Google公司首先提出的，其擁有一套專屬的云計(jì)算平臺，這個(gè)平臺先是為網(wǎng)頁搜索應(yīng)用提供服務(wù),現(xiàn)在已經(jīng)擴(kuò)展到其他應(yīng)用程序。

作為一種新型的計(jì)算方式，Google云計(jì)算平臺包含了許多獨(dú)特的技術(shù)，如數(shù)據(jù)中心節(jié)能技術(shù)、節(jié)點(diǎn)互聯(lián)技術(shù)、可用性技術(shù)、容錯(cuò)性技術(shù)、數(shù)據(jù)存儲技術(shù)、數(shù)據(jù)管理技術(shù)、數(shù)據(jù)切分技術(shù)、任務(wù)調(diào)度技術(shù)、編程模型、負(fù)載均衡技術(shù)、并行計(jì)算技術(shù)和系統(tǒng)監(jiān)控技術(shù)等。

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

在Google云計(jì)算平臺的技術(shù)架構(gòu)中，除了少量負(fù)責(zé)特定管理功能的節(jié)點(diǎn) （如 GFS master、Chubby和 Scheduler等），所有的節(jié)點(diǎn)都是同構(gòu)的，即同時(shí)運(yùn)行BigTable Server、GFS chunkserver和MapReduce Job等核心功能模塊，與之相對應(yīng)的則是數(shù)據(jù)存儲、數(shù)據(jù)管理和編程模型等3項(xiàng)關(guān)鍵技術(shù)，因此本文將重點(diǎn)對它們進(jìn)行研究。

圖1 Google云計(jì)算平臺的技術(shù)架構(gòu)

2.1 數(shù)據(jù)存儲技術(shù)

網(wǎng)頁搜索業(yè)務(wù)需要海量的數(shù)據(jù)存儲，同時(shí)還需要滿足高可用性、高可靠性和經(jīng)濟(jì)性等要求。為此，Google基于以下幾個(gè)假設(shè)開發(fā)了分布式文件系統(tǒng)——GFS（google file system）。

（1）硬件故障是常態(tài)

系統(tǒng)平臺是建立在大量廉價(jià)的、消費(fèi)級的IT部件之上，系統(tǒng)必須時(shí)刻進(jìn)行自我監(jiān)控、節(jié)點(diǎn)檢測和容錯(cuò)處理，能夠從部件級的錯(cuò)誤中快速恢復(fù)是一個(gè)基本的要求。

（2）支持大數(shù)據(jù)集

系統(tǒng)平臺需要支持海量大文件的存儲，可能包括幾百萬個(gè)100 MB以上的文件，GB級別的文件也是常見的。與此同時(shí)，小文件也能夠支持，但將不進(jìn)行專門的優(yōu)化。

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

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

（4）高并發(fā)性

系統(tǒng)平臺需要支持多個(gè)客戶端同時(shí)對某一個(gè)文件的追加寫入操作，這些客戶端可能分布在幾百個(gè)不同的節(jié)點(diǎn)上，同時(shí)需要以最小的開銷保證寫入操作的原子性。

GFS由一個(gè)master和大量塊服務(wù)器構(gòu)成，如圖2所示。master存放文件系統(tǒng)的所有元數(shù)據(jù),包括名字空間、存取控制、文件分塊信息、文件塊的位置信息等。GFS中的文件切分成64 MB的塊進(jìn)行存儲。

為了保證數(shù)據(jù)的可靠性，GFS文件系統(tǒng)采用了冗余存儲的方式，每份數(shù)據(jù)在系統(tǒng)中保存3個(gè)以上的備份，其中兩份拷貝在同一機(jī)架的不同節(jié)點(diǎn)上，以充分利用機(jī)柜內(nèi)部帶寬，另外一份拷貝存儲在不同機(jī)架的節(jié)點(diǎn)上。同時(shí)，為了保證數(shù)據(jù)的一致性,對于數(shù)據(jù)的所有修改需要在所有的備份上進(jìn)行,并用版本號的方式來確保所有備份處于一致的狀態(tài)。

為避免大量讀操作使master成為系統(tǒng)瓶頸，客戶端不直接通過master讀取數(shù)據(jù)，而是從master獲取目標(biāo)數(shù)據(jù)塊的位置信息后，直接和塊服務(wù)器交互進(jìn)行讀操作。

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

通過服務(wù)器端和客戶端的聯(lián)合設(shè)計(jì)，GFS對應(yīng)用支持達(dá)到了性能與可用性的最優(yōu)化。在Google云計(jì)算平臺中部署了多個(gè)GFS集群，有的集群擁有超過1000個(gè)存儲節(jié)點(diǎn)和超過300 TB的硬盤空間，被不同機(jī)器上的數(shù)百個(gè)客戶端連續(xù)不斷地頻繁訪問著。

2.2 數(shù)據(jù)管理技術(shù)

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

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

BigTable中的數(shù)據(jù)項(xiàng)按照行關(guān)鍵字的字典序排列，每行動(dòng)態(tài)地劃分到記錄板中，每個(gè)服務(wù)器節(jié)點(diǎn)Tablet Server負(fù)責(zé)管理大約100個(gè)記錄板。時(shí)間戳是一個(gè)64位的整數(shù),表示數(shù)據(jù)的不同版本。列簇是若干列的集合，BigTable中的存取權(quán)限控制在列簇的粒度進(jìn)行。

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

BigTable的主服務(wù)器除了管理元數(shù)據(jù)之外，還負(fù)責(zé)對Tablet Server進(jìn)行遠(yuǎn)程管理與負(fù)載調(diào)配?？蛻舳送ㄟ^編程接口與主服務(wù)器進(jìn)行控制通信以獲得元數(shù)據(jù)，與Tablet Server進(jìn)行數(shù)據(jù)通信，而具體的讀寫請求則由Tablet Server負(fù)責(zé)處理。

與前述的系統(tǒng)類似，BigTable也是客戶端和服務(wù)器端的聯(lián)合設(shè)計(jì)，使得性能能夠最大程度地符合應(yīng)用的需求。

2.3 編程模型

Google構(gòu)造了Map-Reduce編程框架來支持并行計(jì)算，應(yīng)用程序編寫人員只需將精力放在應(yīng)用程序本身，關(guān)于如何通過分布式的集群來支持并行計(jì)算，包括可靠性和可擴(kuò)展性，則交由平臺來處理，從而保證了后臺復(fù)雜的并行執(zhí)行和任務(wù)調(diào)度向用戶和編程人員透明。

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

從圖5可以看出,執(zhí)行一個(gè)Map-Reduce程序需要5個(gè)步驟：輸入文件，將文件分配給多個(gè)worker并行地執(zhí)行，寫中間文件(本地寫)，多個(gè)Reduce worker同時(shí)運(yùn)行，輸出最終結(jié)果。本地寫中間文件減少了對網(wǎng)絡(luò)帶寬的壓力，同時(shí)減少了寫中間文件的時(shí)間耗費(fèi)；執(zhí)行Reduce時(shí),根據(jù)從master獲得的中間文件位置信息，Reduce使用遠(yuǎn)程過程調(diào)用，從中間文件所在節(jié)點(diǎn)讀取所需的數(shù)據(jù)。

圖5 Map-Reduce程序的具體執(zhí)行過程

Map-Reduce模型具有很強(qiáng)的容錯(cuò)性，當(dāng)worker節(jié)點(diǎn)出現(xiàn)錯(cuò)誤時(shí),只需要將該worker節(jié)點(diǎn)屏蔽在系統(tǒng)外等待修復(fù)，并將該worker上執(zhí)行的程序遷移到其他worker上重新執(zhí)行，同時(shí)將該遷移信息通過master發(fā)送給需要該節(jié)點(diǎn)處理結(jié)果的節(jié)點(diǎn)。Map-Reduce使用檢查點(diǎn)的方式來處理master出錯(cuò)失敗的問題，當(dāng)master出現(xiàn)錯(cuò)誤時(shí)，可以根據(jù)最近的一個(gè)檢查點(diǎn)重新選擇一個(gè)節(jié)點(diǎn)作為master并由此檢查點(diǎn)位置繼續(xù)運(yùn)行。

3 Google云計(jì)算平臺與傳統(tǒng)IT系統(tǒng)的差異

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

圖6 Browser/Server的技術(shù)架構(gòu)

3.1 數(shù)據(jù)存儲技術(shù)

對于數(shù)據(jù)存儲技術(shù)來說，存儲可靠性、I/O吞吐能力和可擴(kuò)展性是最核心的技術(shù)指標(biāo)。

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

圖7 NAS和SAN的基本原理

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

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

3.2 數(shù)據(jù)管理技術(shù)

在數(shù)據(jù)管理技術(shù)中，如何提高數(shù)據(jù)庫系統(tǒng)的性能是最核心的問題。

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

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

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

值得注意的是，與傳統(tǒng)的RDBMS相比，BigTable也存在許多缺點(diǎn)，例如類似數(shù)據(jù)庫中的Join操作效率太低、只支持string的數(shù)據(jù)類型，不支持全表的排序運(yùn)算，不支持多個(gè)表的關(guān)系運(yùn)算，不支持多行的事務(wù)，不支持跨表的事務(wù)，對ACID的支持有限等，但是由于Google云計(jì)算平臺所承載的應(yīng)用并不是以O(shè)LTP事務(wù)處理為重點(diǎn)，這些缺點(diǎn)并不會產(chǎn)生嚴(yán)重的影響。

3.3 編程框架

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

圖8 Oracle RAC的系統(tǒng)架構(gòu)

圖9 Map-Reduce模式和并行執(zhí)行模式的對比

·在并行執(zhí)行模式下，數(shù)據(jù)是集中管理的（通常是由一個(gè)關(guān)系型數(shù)據(jù)庫系統(tǒng)RDBMS來負(fù)責(zé)完成），每個(gè)應(yīng)用都可以直接操作數(shù)據(jù)庫中的數(shù)據(jù)，由數(shù)據(jù)庫系統(tǒng)負(fù)責(zé)保證數(shù)據(jù)的一致性和完整性。在Map-Reduce模式下，由于數(shù)據(jù)是由每個(gè)節(jié)點(diǎn)分散進(jìn)行管理的，不存在獨(dú)立的、集中的數(shù)據(jù)庫系統(tǒng)，每個(gè)節(jié)點(diǎn)只能對自己所管理的數(shù)據(jù)進(jìn)行操作，因此需要上層應(yīng)用軟件的干預(yù)，以保證跨節(jié)點(diǎn)的數(shù)據(jù)的一致性和完整性。

·在Map-Reduce模式下，增加了對任務(wù)的分解Map以及結(jié)果的規(guī)約Reduce等處理環(huán)節(jié)，以支持多個(gè)worker節(jié)點(diǎn)的并行處理，同時(shí)還需要完成worker節(jié)點(diǎn)失效處理以及worker節(jié)點(diǎn)間的協(xié)調(diào)通信等工作，因此系統(tǒng)處理負(fù)荷有所增加，但是考慮到大規(guī)模并行處理所帶來的巨大優(yōu)勢，這種代價(jià)是完全值得的。

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

4 Google云計(jì)算平臺的成本分析

Google云計(jì)算平臺獨(dú)特的技術(shù)架構(gòu)對其總體成本產(chǎn)生了深刻的影響，主要體現(xiàn)在以下5個(gè)方面。

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

·Google云計(jì)算平臺中除少量的管理節(jié)點(diǎn)以外，各個(gè)節(jié)點(diǎn)均是同構(gòu)的，同時(shí)承擔(dān)數(shù)據(jù)存儲、數(shù)據(jù)管理和任務(wù)管理等功能，因此很容易實(shí)現(xiàn)設(shè)備的標(biāo)準(zhǔn)化，通過大批量采購專門定制的計(jì)算機(jī)主板，裁減一切與計(jì)算無關(guān)的部件 （如顯示器、外設(shè)接口甚至機(jī)箱外殼等）等方式，進(jìn)一步地降低了設(shè)備投資。

·Google云計(jì)算平臺將硬件失效視為常態(tài)，轉(zhuǎn)而通過軟件容錯(cuò)的方式實(shí)現(xiàn)節(jié)點(diǎn)之間的自動(dòng)切換來實(shí)現(xiàn)高可用性，大大減少了設(shè)備冗余。例如，假設(shè)單個(gè)節(jié)點(diǎn)的可靠性為95%，傳統(tǒng)IT系統(tǒng)采用1+1的備份方式時(shí)系統(tǒng)可靠性為99.75%，但此時(shí)設(shè)備冗余為100%，采用100個(gè)節(jié)點(diǎn)的Google云計(jì)算平臺時(shí)，達(dá)到相同的可靠性水平只需要增加12%的設(shè)備冗余，設(shè)備投資減少了44%。設(shè)備冗余的減少帶來了設(shè)備利用率的提高，據(jù)Google宣稱，其設(shè)備利用率可以達(dá)到一般企業(yè)的280%。

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

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

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

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

5 結(jié)束語

通過對Google平臺技術(shù)架構(gòu)的分析，可以發(fā)現(xiàn)其3個(gè)基本特征，即：系統(tǒng)建立在大規(guī)模的廉價(jià)服務(wù)器集群之上；通過基礎(chǔ)設(shè)施與上層應(yīng)用程序的協(xié)同構(gòu)建以達(dá)到最大效率利用硬件資源的目的；通過軟件的方法實(shí)現(xiàn)節(jié)點(diǎn)的容錯(cuò)，這些都與基于高性能UNIX服務(wù)器集群的傳統(tǒng)IT系統(tǒng)形成了強(qiáng)烈的反差。

實(shí)際上，這種平臺技術(shù)架構(gòu)的差異來源于完全不同的設(shè)計(jì)思想。傳統(tǒng)IT系統(tǒng)采用的是“自下而上”的設(shè)計(jì)方法，以逐層堆疊的方式承載上層應(yīng)用，強(qiáng)調(diào)基礎(chǔ)設(shè)施對應(yīng)用透明，分層的集中管理以及通過工業(yè)標(biāo)準(zhǔn)實(shí)現(xiàn)異構(gòu)設(shè)備的互聯(lián)，其本質(zhì)上是一種通用平臺，而Google云計(jì)算平臺則采用了“自頂向下”的設(shè)計(jì)方法，即從上層應(yīng)用出發(fā)，根據(jù)特定應(yīng)用的業(yè)務(wù)特征對基礎(chǔ)設(shè)施進(jìn)行改造 （而不是一般意義的優(yōu)化），其本質(zhì)上是一種專用平臺，這也是Google云計(jì)算平臺具有極低的計(jì)算成本和存儲成本的根本原因。

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 陳康,鄭緯民.云計(jì)算:系統(tǒng)實(shí)例與研究現(xiàn)狀.軟件學(xué)報(bào),2009(5)

5 陳全,鄧倩妮.云計(jì)算及其關(guān)鍵技術(shù).計(jì)算機(jī)應(yīng)用,2009(9)

6 NGBOSS1-CRM技術(shù)規(guī)范.中國移動(dòng)通信企業(yè)標(biāo)準(zhǔn),2009

7 云計(jì)算平臺的并行數(shù)據(jù)挖掘工具對經(jīng)分系統(tǒng)的業(yè)務(wù)支撐能力的研究,中國移動(dòng)通信集團(tuán)上海有限公司,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)