Google，無疑是互聯(lián)網(wǎng)時代最閃亮的明星。截止到今天為止，Google美國主站在Alexa排名已經(jīng)連續(xù)3年第一，Alexa Top100中，各國的Google分站竟然霸占了超過20多個名額，不得不令人感嘆Google的強大。不論何時，不論何地，也不論你搜索多么冷門的詞匯，只要你的電腦連接互聯(lián)網(wǎng)，只要你輕輕點擊“google搜索”，那么這一切相關(guān)內(nèi)容google都會在1秒鐘之內(nèi)全部搞定，這甚至比你查詢“我的文檔”都要快捷。這也就是為什么Google創(chuàng)業(yè)12年，市值超過2000億美元的原因。

有人可能認為Google擁有幾臺“藍色基因”那樣的超級計算機來處理各種數(shù)據(jù)和搜索，事實是怎樣的呢？下面我們就將詳細解析神奇Google的神奇架構(gòu)。

硬件：

截止到2010年，Google大約有100萬臺服務(wù)器，有超過500個計算機集群，處理不同地域的不同任務(wù)?？上Х?wù)器的詳細配置和最新集群的具體情況，在多個文獻庫里面都查詢不到，我個人理解，這可能屬于商業(yè)機密。大概也是因為機密的緣故，強大的Google計算機集群并沒有遞交Top500計算機的申請，多年來我們在Top500中都看不到Google的影子。(進入Top500需要提交并且公開自己計算機系統(tǒng)的詳細配置)不過根據(jù)文獻資料，可以肯定的是，這45萬臺服務(wù)器都不是什么昂貴的服務(wù)器，而是非常普通的PC級別服務(wù)器，其中的服務(wù)器硬盤在兩年前還普遍是IDE接口、并且采用PC級主板而非昂貴的服務(wù)器專用主板。Google的集群也全部是自己搭建的，沒有采用Myricom 的 Myrinet或者Giganet 的 cLAN等先進昂貴的集群連接技術(shù)，Google各個數(shù)據(jù)中心和服務(wù)器間不同的耦合程度都隨需而定自行連接。

那么google的存儲呢？Google存儲著海量的資訊，近千億個網(wǎng)頁、數(shù)百億張圖片。早在2004年，Google的存儲容量就已經(jīng)達到了5PB。可能很多讀者一開始都認為Google采用了諸如EMC Symmetrix系列磁盤陣列來保存大量的資訊，但是Google的實際做法又一次讓我們大跌眼鏡——Google沒有使用任何磁盤陣列，哪怕是低端的磁盤陣列也沒用。Google的方法是將集群中的每一臺PC級服務(wù)器，配備兩個普通IDE硬盤來存儲。不過Google倒也不是都是什么設(shè)備都落后，至少這些硬盤的轉(zhuǎn)速都很高，而且每臺服務(wù)器的內(nèi)存也還算比較大。最大的電腦DIY消費者是誰？恐怕Google又登上了這個DIY寶座。Google的絕大部分服務(wù)器甚至也不是采購什么大品牌，而是購買各種廉價零件而后自行裝配的。有趣的是，Google非常不滿意現(xiàn)存的各種PC電源的功耗，甚至還自行設(shè)計了Google專用服務(wù)器電源。

很快，我們就有了疑問。這樣的一個以PC級別服務(wù)器搭建起來的系統(tǒng)，怎么能承受巨大的工作負載呢？怎么能保證高可用性呢？的確，這些低端的服務(wù)器經(jīng)常出現(xiàn)故障——硬盤壞道、系統(tǒng)宕機這類的事故其實每天都在45萬臺服務(wù)器中發(fā)生。而Google的方法是設(shè)立鏡像站。以Google主站為例，2003年就在美國硅谷和弗吉尼亞設(shè)立了多個鏡像站。這些鏡像站其實不是傳統(tǒng)的鏡像站。真正的鏡像站是雙機熱備，當一臺服務(wù)器宕機時，另一臺服務(wù)器接管相關(guān)任務(wù)。而Google的鏡像站其實真正的職責(zé)是DNS負載均衡，所以有的Google鏡像站本身還有自己的鏡像站。這里舉例說明Google鏡像站的作用：一個訪問，DNS正常解析到A處，但當A處負載過大時，DNS服務(wù)就將域名解析到B處，這樣既達到了冗余，也縮減了投資。由于不是雙機熱備，某一時間，鏡像站的內(nèi)容可能略有不同，不過對于精確度要求不那么高的普通檢索而言，并不是問題。

平臺：GFS/MapReduce/ BigTable/Linux

GFS/MapReduce/ BigTable/這三個平臺，是Google最引以為傲的平臺，全部架構(gòu)在Linux之上。

首先我們來看一看GFS（Google File System）Google文件系統(tǒng)。我們知道，一般的數(shù)據(jù)中心檢索時候需要用到數(shù)據(jù)庫系統(tǒng)。但是Google的情況很特殊——Google擁有全球上百億個Web文檔，如果用常規(guī)數(shù)據(jù)庫系統(tǒng)檢索，那么檢索速度就可想而知了。因此，當Crawlers采集到許多新的Web后，Google將很多的Web都匯集到一個文件里進行存儲管理，而且Google將Web文件壓縮成Chunk塊，進一步減少占用空間(64MB一個chunk)。最后，Google只檢索壓縮后的部分。而GFS(Google File System）正是在這樣的檢索技術(shù)上構(gòu)建的文件系統(tǒng)，GFS包括了GFS Master服務(wù)器和Chunk服務(wù)器。如下圖所示，系統(tǒng)的流程從GFS客戶端開始：GFS客戶端以chunk偏移量制作目錄索引并且發(fā)送請求——GFS Master收到請求通過chunk映射表映射反饋客戶端——客戶端有了chunk handle和chunk 位置，并將文件名和chunk的目錄索引緩存，向chunk服務(wù)器發(fā)送請求——chunk服務(wù)器回復(fù)請求傳輸chunk數(shù)據(jù)。

如果讀者您讀著有點迷糊，這很正常，因為只有少數(shù)搜索引擎企業(yè)才采用這樣的技術(shù)。簡單來說是這樣：Google運用GFS大大簡化了檢索的難度。

除了GFS，MapReduce對Google也是功不可沒。Google擁有不少于45萬臺服務(wù)器，看起來每臺服務(wù)器的職能都非常明確，但是其中卻有重要的協(xié)同問題有待解決：如何并發(fā)計算，如何分布數(shù)據(jù)，如何處理失敗，如何負載均衡？我們可以預(yù)見，無數(shù)的代碼將被用在協(xié)同問題上，而且很可能效率低下。這時候，MapReduce就派上用場了。MapReduce是Google開發(fā)的C++編程工具，用于大規(guī)模數(shù)據(jù)集的并行運算。MapReduce主要功能是提供了一個簡單強大的接口，可以將計算自動的并發(fā)和分布執(zhí)行。這樣一來，就可以通過普通PC的集群，實現(xiàn)高性能。MapReduce主要從兩方面提升了系統(tǒng)：首先是失效的計算機問題。如果某一臺計算機失效了，或者是I/O出現(xiàn)了問題——這在Google以廉價服務(wù)器組建的集群中極為常見，MapReduce的解決方法是用多個計算機同時計算一個任務(wù)，一旦一臺計算機有了結(jié)果，其它計算機就停止該任務(wù)，而進入下一任務(wù)。另外，在MapReduce之間傳輸?shù)臄?shù)據(jù)都是經(jīng)過壓縮的，節(jié)省了很多帶寬資源。至于BigTable，這是一個用來處理大數(shù)據(jù)量的系統(tǒng)，適合處理半結(jié)構(gòu)化的數(shù)據(jù)。

Google心經(jīng)：

Google總是嘗試用最少的錢，做最多的事情。不要小看那些便宜、不牢靠的PC級服務(wù)器，一臺服務(wù)器也許確實不牢靠，但是45萬臺的有機集成卻成為了全球最完善、最穩(wěn)定的系統(tǒng)之一。在采購服務(wù)器方面，Google也從未一次性大量購買，都是有了需求再選購。另一個能夠體現(xiàn)Google精打細算的方面是Google盡量壓縮所有能夠壓縮的文件。

包括軟件和硬件，Google的設(shè)計構(gòu)想都很前衛(wèi)，Google嘗試過許多還在實驗室里的萌芽技術(shù)，如上文所說，很多都取得了巨大成功。Google早先的目標是0.5秒鐘做出搜索結(jié)果，但實際上目前的平均時間已經(jīng)縮減到了0.25秒。而且，Google從來沒有停止研究的腳步，現(xiàn)在還在測試OpenSoalris，觀察OpenSoalris是否能夠替代Linux。

Google的行為非常踏實。不參加Top500評選，文獻里也鮮有相關(guān)資料?？梢奊oogle不吹噓、也沒有過度宣傳，只是勤勤懇懇的更新程序、優(yōu)化集群。今天，google收錄了絕大多數(shù)人類語言的網(wǎng)頁，并且在多數(shù)國家都建立了Google分站，收錄的網(wǎng)頁也是與日俱增，全球影響力更是不言而喻。

向Google的架構(gòu)學(xué)習(xí)，向Google的成就致敬。

Google是伸縮性的王者。Google一直的目標就是構(gòu)建高性能高伸縮性的基礎(chǔ)組織來支持它們的產(chǎn)品。
平臺

Linux
大量語言：Python，Java，C++

狀態(tài)
在2006年大約有450,000臺廉價服務(wù)器，這個數(shù)量到2010年增加到了1,000,000臺。
在2005年Google索引了80億Web頁面，現(xiàn)在沒有人知道具體數(shù)目，近千億并不斷增長中。
目前在Google有超過500個GFS集群。一個集群可以有1000或者甚至5000臺機器。成千上萬的機器從運行著5000000000000000字節(jié)存儲的GFS集群獲取數(shù)據(jù)，集群總的讀寫吞吐量可以達到每秒40兆字節(jié)
目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序
BigTable伸縮存儲幾十億的URL，幾百千千兆的衛(wèi)星圖片和幾億用戶的參數(shù)選擇

堆棧
Google形象化它們的基礎(chǔ)組織為三層架構(gòu)：
1，產(chǎn)品：搜索，廣告，email，地圖，視頻，聊天，博客
2，分布式系統(tǒng)基礎(chǔ)組織：GFS，MapReduce和BigTable
3，計算平臺：一群不同的數(shù)據(jù)中心里的機器
4，確保公司里的人們部署起來開銷很小
5，花費更多的錢在避免丟失日志數(shù)據(jù)的硬件上，其他類型的數(shù)據(jù)則花費較少

可信賴的存儲機制GFS(Google File System)
1，可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺
2，Google File System – 大型分布式結(jié)構(gòu)化日志文件系統(tǒng)，Google在里面扔了大量的數(shù)據(jù)
3，為什么構(gòu)建GFS而不是利用已有的東西？因為可以自己控制一切并且這個平臺與別的不一樣，Google需要：
-跨數(shù)據(jù)中心的高可靠性
-成千上萬的網(wǎng)絡(luò)節(jié)點的伸縮性
-大讀寫帶寬的需求
-支持大塊的數(shù)據(jù)，可能為上千兆字節(jié)
-高效的跨節(jié)點操作分發(fā)來減少瓶頸
4，系統(tǒng)有Master和Chunk服務(wù)器
-Master服務(wù)器在不同的數(shù)據(jù)文件里保持元數(shù)據(jù)。數(shù)據(jù)以64MB為單位存儲在文件系統(tǒng)中?？蛻舳伺cMaster服務(wù)器交流來在文件上做元數(shù)據(jù)操作并且找到包含用戶需要數(shù)據(jù)的那些Chunk服務(wù)器
-Chunk服務(wù)器在硬盤上存儲實際數(shù)據(jù)。每個Chunk服務(wù)器跨越3個不同的Chunk服務(wù)器備份以創(chuàng)建冗余來避免服務(wù)器崩潰。一旦被Master服務(wù)器指明，客戶端程序就會直接從Chunk服務(wù)器讀取文件
6，一個上線的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，關(guān)鍵點在于有足夠的基礎(chǔ)組織來讓人們對自己的程序有所選擇，GFS可以調(diào)整來適應(yīng)個別程序的需求

使用MapReduce來處理數(shù)據(jù)
1，現(xiàn)在你已經(jīng)有了一個很好的存儲系統(tǒng)，你該怎樣處理如此多的數(shù)據(jù)呢？比如你有許多TB的數(shù)據(jù)存儲在1000臺機器上。數(shù)據(jù)庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現(xiàn)的原因
2，MapReduce是一個處理和生成大量數(shù)據(jù)集的編程模型和相關(guān)實現(xiàn)。用戶指定一個map方法來處理一個鍵/值對來生成一個中間的鍵/值對，還有一個reduce方法來合并所有關(guān)聯(lián)到同樣的中間鍵的中間值。許多真實世界的任務(wù)都可以使用這種模型來表現(xiàn)。以這種風(fēng)格來寫的程序會自動并行的在一個大量機器的集群里運行。運行時系統(tǒng)照顧輸入數(shù)據(jù)劃分、程序在機器集之間執(zhí)行的調(diào)度、機器失敗處理和必需的內(nèi)部機器交流等細節(jié)。這允許程序員沒有多少并行和分布式系統(tǒng)的經(jīng)驗就可以很容易使用一個大型分布式系統(tǒng)資源
3，為什么使用MapReduce？
-跨越大量機器分割任務(wù)的好方式
-處理機器失敗
-可以與不同類型的程序工作，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操作。你可以預(yù)先計算有用的數(shù)據(jù)、查詢字數(shù)統(tǒng)計、對TB的數(shù)據(jù)排序等等
4，MapReduce系統(tǒng)有三種不同類型的服務(wù)器
-Master服務(wù)器分配用戶任務(wù)到Map和Reduce服務(wù)器。它也跟蹤任務(wù)的狀態(tài)
-Map服務(wù)器接收用戶輸入并在其基礎(chǔ)上處理map操作。結(jié)果寫入中間文件
-Reduce服務(wù)器接收Map服務(wù)器產(chǎn)生的中間文件并在其基礎(chǔ)上處理reduce操作
5，例如，你想在所有Web頁面里的字數(shù)。你將存儲在GFS里的所有頁面拋入MapReduce。這將在成千上萬臺機器上同時進行并且所有的調(diào)整、工作調(diào)度、失敗處理和數(shù)據(jù)傳輸將自動完成
-步驟類似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一個map操作將一些數(shù)據(jù)映射到另一個中，產(chǎn)生一個鍵值對，在我們的例子里就是字和字數(shù)
-Shuffling操作聚集鍵類型
-Reduction操作計算所有鍵值對的綜合并產(chǎn)生最終的結(jié)果
6，Google索引操作管道有大約20個不同的map和reduction。
7，程序可以非常小，如20到50行代碼
8，一個問題是掉隊者。掉隊者是一個比其他程序慢的計算，它阻塞了其他程序。掉隊者可能因為緩慢的IO或者臨時的CPU不能使用而發(fā)生。解決方案是運行多個同樣的計算并且當一個完成后殺死所有其他的
9，數(shù)據(jù)在Map和Reduce服務(wù)器之間傳輸時被壓縮了。這可以節(jié)省帶寬和I/O。

在BigTable里存儲結(jié)構(gòu)化數(shù)據(jù)
1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統(tǒng)，它包含千千兆的內(nèi)存和1000000000000000的存儲。它可以每秒鐘處理百萬的讀寫
2，BigTable是一個構(gòu)建于GFS之上的分布式哈希機制。它不是關(guān)系型數(shù)據(jù)庫。它不支持join或者SQL類型查詢
3，它提供查詢機制來通過鍵訪問結(jié)構(gòu)化數(shù)據(jù)。GFS存儲存儲不透明的數(shù)據(jù)而許多程序需求有結(jié)構(gòu)化數(shù)據(jù)
4，商業(yè)數(shù)據(jù)庫不能達到這種級別的伸縮性并且不能在成千上萬臺機器上工作
5，通過控制它們自己的低級存儲系統(tǒng)Google得到更多的控制權(quán)來改進它們的系統(tǒng)。例如，如果它們想讓跨數(shù)據(jù)中心的操作更簡單這個特性，它們可以內(nèi)建它
6，系統(tǒng)運行時機器可以自由的增刪而整個系統(tǒng)保持工作
7，每個數(shù)據(jù)條目存儲在一個格子里，它可以通過一個行key和列key或者時間戳來訪問
8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數(shù)據(jù)序列并且格式為SSTable
9，BigTable有三種類型的服務(wù)器：
-Master服務(wù)器分配tablet服務(wù)器，它跟蹤tablet在哪里并且如果需要則重新分配任務(wù)
-Tablet服務(wù)器為tablet處理讀寫請求。當tablet超過大小限制(通常是100MB-200MB)時它們拆開tablet。當一個Tablet服務(wù)器失敗時，則100個Tablet服務(wù)器各自挑選一個新的tablet然后系統(tǒng)恢復(fù)。
-Lock服務(wù)器形成一個分布式鎖服務(wù)。像打開一個tablet來寫、Master調(diào)整和訪問控制檢查等都需要互斥
10，一個locality組可以用來在物理上將相關(guān)的數(shù)據(jù)存儲在一起來得到更好的locality選擇
11，tablet盡可能的緩存在RAM里

硬件
1，當你有很多機器時你怎樣組織它們來使得使用和花費有效？
2，使用非常廉價的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存儲
5，Price per wattage on performance basis isn’t getting better. Have huge power and cooling issues
6，使用一些collocation和Google自己的數(shù)據(jù)中心

其他
1，迅速更改而不是等待QA
2，庫是構(gòu)建程序的卓越方式
3，一些程序作為服務(wù)提供
4，一個基礎(chǔ)組織處理程序的版本，這樣它們可以發(fā)布而不用害怕會破壞什么東西

Google將來的方向
1，支持地理位置分布的集群
2，為所有數(shù)據(jù)創(chuàng)建一個單獨的全局名字空間。當前的數(shù)據(jù)由集群分離
3，更多和更好的自動化數(shù)據(jù)遷移和計算
4，解決當使用網(wǎng)絡(luò)劃分來做廣闊區(qū)域的備份時的一致性問題(例如保持服務(wù)即使一個集群離線維護或由于一些損耗問題)

學(xué)到的東西
1，基礎(chǔ)組織是有競爭性的優(yōu)勢。特別是對Google而言。Google可以很快很廉價的推出新服務(wù)，并且伸縮性其他人很難達到。許多公司采取完全不同的方式。許多公司認為基礎(chǔ)組織開銷太大。Google認為自己是一個系統(tǒng)工程公司，這是一個新的看待軟件構(gòu)建的方式
2，跨越多個數(shù)據(jù)中心仍然是一個未解決的問題。大部分網(wǎng)站都是一個或者最多兩個數(shù)據(jù)中心。我們不得不承認怎樣在一些數(shù)據(jù)中心之間完整的分布網(wǎng)站是很需要技巧的
3，如果你自己沒有時間從零開始重新構(gòu)建所有這些基礎(chǔ)組織你可以看看Hadoop。Hadoop是這里很多同樣的主意的一個開源實現(xiàn)
4，平臺的一個優(yōu)點是初級開發(fā)人員可以在平臺的基礎(chǔ)上快速并且放心的創(chuàng)建健全的程序。如果每個項目都需要發(fā)明同樣的分布式基礎(chǔ)組織的輪子，那么你將陷入困境因為知道怎樣完成這項工作的人相對較少
5，協(xié)同工作不一直是擲骰子。通過讓系統(tǒng)中的所有部分一起工作則一個部分的改進將幫助所有的部分。改進文件系統(tǒng)則每個人從中受益而且是透明的。如果每個項目使用不同的文件系統(tǒng)則在整個堆棧中享受不到持續(xù)增加的改進
6，構(gòu)建自管理系統(tǒng)讓你沒必要讓系統(tǒng)關(guān)機。這允許你更容易在服務(wù)器之間平衡資源、動態(tài)添加更大的容量、讓機器離線和優(yōu)雅的處理升級
7，創(chuàng)建可進化的基礎(chǔ)組織，并行的執(zhí)行消耗時間的操作并采取較好的方案
8，不要忽略學(xué)院。學(xué)院有許多沒有轉(zhuǎn)變?yōu)楫a(chǎn)品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。

Google主要以GFS、MapReduce、BigTable這三大平臺來支撐其龐大的業(yè)務(wù)系統(tǒng)，我稱他們?yōu)镚oogle三劍客，網(wǎng)上也有說是Google的三架馬車。

一、GFS（Google File System）

這是Google獨特的一個面向大規(guī)模數(shù)據(jù)密集型應(yīng)用的、可伸縮的分布式文件系統(tǒng)，由于這個文件系統(tǒng)是通過軟件調(diào)度來實現(xiàn)的，所以Google可以把GFS部署在很多廉價的PC機上，來達到用昂貴服務(wù)器一樣的效果。

下面是一張Google GFS的架構(gòu)圖：

從上圖我們可看到Google的GFS主要由一個master和很多chunkserver組成，master主要是負責(zé)維護系統(tǒng)中的名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置等元素據(jù)，并通過心跳信號與chunkserver通信，搜集并保存chunkserver的狀態(tài)信息。chunkserver主要是用來存儲數(shù)據(jù)塊，google把每個數(shù)據(jù)塊的大小設(shè)計成64M，至于為什么這么大后面會提到，每個chunk是由master分配的chunk-handle來標識的，為了提高系統(tǒng)的可靠性，每個chunk會被復(fù)制3個副本放到不同的chunkserver中。

當然這樣的單master設(shè)計也會帶來單點故障問題和性能瓶頸問題，Google是通過減少client與master的交互來解決的，client均是直接與chunkserver通信，master僅僅提供查詢數(shù)據(jù)塊所在的chunkserver以及詳細位置。下面是在GFS上查詢的一般流程：

1、client使用固定的塊大小將應(yīng)用程序指定的文件名和字節(jié)偏移轉(zhuǎn)換成文件的一個塊索引（chunk index）。
2、給master發(fā)送一個包含文件名和塊索引的請求。
3、master回應(yīng)對應(yīng)的chunk handle和副本的位置（多個副本）。
4、client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個副本發(fā)送一個請求，很可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內(nèi)的一個字節(jié)區(qū)間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以后對同一個塊的讀操作不再需要client和master間的交互。

不過我還是有疑問，google可以通過減少client與master通信來解決性能瓶頸問題，但單點問題呢，一臺master掛掉豈不是完蛋了，總感覺不太放心，可能是我了解不夠透徹，不知道哪位朋友能解釋一下，謝謝：）

二、MapReduce，Google的分布式并行計算系統(tǒng)

如果上面的GFS解決了Google的海量數(shù)據(jù)的存儲，那這個MapReduce則是解決了如何從這些海量數(shù)據(jù)中快速計算并獲取指定數(shù)據(jù)的問題。我們知道，Google的每一次搜索都在零點零幾秒，能在這么短時間里環(huán)游世界一周，這里MapReduce有很大的功勞。

Map即映射，Reduce即規(guī)約，由master服務(wù)器把map和reduce任務(wù)分發(fā)到各自worker服務(wù)器中運行計算，最后把結(jié)果規(guī)約合并后返回給用戶。這個過程可以由下圖來說明。

按照自己的理解，簡單對上圖加點說明：

1、首先把用戶請求的數(shù)據(jù)文件切割成多份，每一份（即每一個split）被拷貝在集群中不同機器上，然后由集群啟動程序中的多份拷貝。

2、master把map和reduce任務(wù)交給相對空閑的worker處理，并阻塞等待處理結(jié)果。

3、處理map任務(wù)的worker接到任務(wù)后，把以key/value形式的輸入數(shù)據(jù)傳遞給map函數(shù)進行處理，并將處理結(jié)果也以key/value的形式輸出，并保存在內(nèi)存中。

4、上一步內(nèi)存中的結(jié)果是要進行reduce的，于是這些map worker就把這些數(shù)據(jù)的位置返回給master，這樣master知道數(shù)據(jù)位置就可以繼續(xù)分配reduce任務(wù)，起到了連接map和reduce函數(shù)的作用。

5、reduce worker知道這些數(shù)據(jù)的位置后就去相應(yīng)位置讀取這些數(shù)據(jù)，并對這些數(shù)據(jù)按key進行排序。將排序后的數(shù)據(jù)序列放入reduce函數(shù)中進行合并和規(guī)約，最后每個reduce任務(wù)輸出一個結(jié)果文件。

6、任務(wù)結(jié)束，master解除阻塞，喚醒用戶。

以上是個人的一些理解，有不對的地方請指出。

三、BigTable，分布式的結(jié)構(gòu)化數(shù)據(jù)存儲系統(tǒng)？

BigTable是基于GFS和MapReduce之上的，那么google既然已經(jīng)有了GFS，為何還要有BigTable呢（也是我原先的一個疑問）？后來想想這和已經(jīng)有操作系統(tǒng)文件系統(tǒng)為何還要有SQL SERVER數(shù)據(jù)庫一樣的道理，GFS是更底層的文件系統(tǒng)，而BigTable建立在其上面，不僅可以存儲結(jié)構(gòu)化的數(shù)據(jù)，而且可以更好的管理和做出負載均衡決策。

以下是BigTable的架構(gòu)圖：

它完全是一個基于key/value的數(shù)據(jù)庫，和一般的關(guān)系型數(shù)據(jù)庫不同，google之所以采用BigTable，因為它在滿足需求的同時簡化了系統(tǒng)，比如去掉了事務(wù)、死鎖檢測等模塊，讓系統(tǒng)更高效。更重要的一點是在BigTable中數(shù)據(jù)是沒有格式的，它僅僅是一個個key/value的pairs，用戶可以自己去定義數(shù)據(jù)的格式，這也大大提高了BigTable的靈活性和擴展性。

四、總結(jié)

這篇隨筆主要是一些總結(jié)性的內(nèi)容，Google架構(gòu)遠遠不止這些。