Google，無疑是互聯(lián)網(wǎng)時(shí)代最閃亮的明星。截止到今天為止，Google美國主站在Alexa排名已經(jīng)連續(xù)3年第一，Alexa Top100中，各國的Google分站竟然霸占了超過20多個(gè)名額，不得不令人感嘆Google的強(qiáng)大。不論何時(shí)，不論何地，也不論你搜索多么冷門的詞匯，只要你的電腦連接互聯(lián)網(wǎng)，只要你輕輕點(diǎn)擊“google搜索”，那么這一切相關(guān)內(nèi)容google都會(huì)在1秒鐘之內(nèi)全部搞定，這甚至比你查詢“我的文檔”都要快捷。這也就是為什么Google創(chuàng)業(yè)12年，市值超過2000億美元的原因。
有人可能認(rèn)為Google擁有幾臺(tái)“藍(lán)色基因”那樣的超級(jí)計(jì)算機(jī)來處理各種數(shù)據(jù)和搜索，事實(shí)是怎樣的呢？下面我們就將詳細(xì)解析神奇Google的神奇架構(gòu)。
硬件：
截止到2010年，Google大約有100萬臺(tái)服務(wù)器，有超過500個(gè)計(jì)算機(jī)集群，處理不同地域的不同任務(wù)。可惜服務(wù)器的詳細(xì)配置和最新集群的具體情況，在多個(gè)文獻(xiàn)庫里面都查詢不到，我個(gè)人理解，這可能屬于商業(yè)機(jī)密。大概也是因?yàn)闄C(jī)密的緣故，強(qiáng)大的Google計(jì)算機(jī)集群并沒有遞交Top500計(jì)算機(jī)的申請(qǐng)，多年來我們?cè)赥op500中都看不到Google的影子。(進(jìn)入Top500需要提交并且公開自己計(jì)算機(jī)系統(tǒng)的詳細(xì)配置)不過根據(jù)文獻(xiàn)資料，可以肯定的是，這45萬臺(tái)服務(wù)器都不是什么昂貴的服務(wù)器，而是非常普通的PC級(jí)別服務(wù)器，其中的服務(wù)器硬盤在兩年前還普遍是IDE接口、并且采用PC級(jí)主板而非昂貴的服務(wù)器專用主板。Google的集群也全部是自己搭建的，沒有采用Myricom 的 Myrinet或者Giganet 的 cLAN等先進(jìn)昂貴的集群連接技術(shù)，Google各個(gè)數(shù)據(jù)中心和服務(wù)器間不同的耦合程度都隨需而定自行連接。
那么google的存儲(chǔ)呢？Google存儲(chǔ)著海量的資訊，近千億個(gè)網(wǎng)頁、數(shù)百億張圖片。早在2004年，Google的存儲(chǔ)容量就已經(jīng)達(dá)到了5PB?？赡芎芏嘧x者一開始都認(rèn)為Google采用了諸如EMC Symmetrix系列磁盤陣列來保存大量的資訊，但是Google的實(shí)際做法又一次讓我們大跌眼鏡——Google沒有使用任何磁盤陣列，哪怕是低端的磁盤陣列也沒用。Google的方法是將集群中的每一臺(tái)PC級(jí)服務(wù)器，配備兩個(gè)普通IDE硬盤來存儲(chǔ)。不過Google倒也不是都是什么設(shè)備都落后，至少這些硬盤的轉(zhuǎn)速都很高，而且每臺(tái)服務(wù)器的內(nèi)存也還算比較大。最大的電腦DIY消費(fèi)者是誰？恐怕Google又登上了這個(gè)DIY寶座。Google的絕大部分服務(wù)器甚至也不是采購什么大品牌，而是購買各種廉價(jià)零件而后自行裝配的。有趣的是，Google非常不滿意現(xiàn)存的各種PC電源的功耗，甚至還自行設(shè)計(jì)了Google專用服務(wù)器電源。
很快，我們就有了疑問。這樣的一個(gè)以PC級(jí)別服務(wù)器搭建起來的系統(tǒng)，怎么能承受巨大的工作負(fù)載呢？怎么能保證高可用性呢？的確，這些低端的服務(wù)器經(jīng)常出現(xiàn)故障——硬盤壞道、系統(tǒng)宕機(jī)這類的事故其實(shí)每天都在45萬臺(tái)服務(wù)器中發(fā)生。而Google的方法是設(shè)立鏡像站。以Google主站為例，2003年就在美國硅谷和弗吉尼亞設(shè)立了多個(gè)鏡像站。這些鏡像站其實(shí)不是傳統(tǒng)的鏡像站。真正的鏡像站是雙機(jī)熱備，當(dāng)一臺(tái)服務(wù)器宕機(jī)時(shí)，另一臺(tái)服務(wù)器接管相關(guān)任務(wù)。而Google的鏡像站其實(shí)真正的職責(zé)是DNS負(fù)載均衡，所以有的Google鏡像站本身還有自己的鏡像站。這里舉例說明Google鏡像站的作用：一個(gè)訪問，DNS正常解析到A處，但當(dāng)A處負(fù)載過大時(shí)，DNS服務(wù)就將域名解析到B處，這樣既達(dá)到了冗余，也縮減了投資。由于不是雙機(jī)熱備，某一時(shí)間，鏡像站的內(nèi)容可能略有不同，不過對(duì)于精確度要求不那么高的普通檢索而言，并不是問題。
平臺(tái)：GFS/MapReduce/ BigTable/Linux
GFS/MapReduce/ BigTable/這三個(gè)平臺(tái)，是Google最引以為傲的平臺(tái)，全部架構(gòu)在Linux之上。
首先我們來看一看GFS（Google File System）Google文件系統(tǒng)。我們知道，一般的數(shù)據(jù)中心檢索時(shí)候需要用到數(shù)據(jù)庫系統(tǒng)。但是Google的情況很特殊——Google擁有全球上百億個(gè)Web文檔，如果用常規(guī)數(shù)據(jù)庫系統(tǒng)檢索，那么檢索速度就可想而知了。因此，當(dāng)Crawlers采集到許多新的Web后，Google將很多的Web都匯集到一個(gè)文件里進(jìn)行存儲(chǔ)管理，而且Google將Web文件壓縮成Chunk塊，進(jìn)一步減少占用空間(64MB一個(gè)chunk)。最后，Google只檢索壓縮后的部分。而GFS(Google File System）正是在這樣的檢索技術(shù)上構(gòu)建的文件系統(tǒng)，GFS包括了GFS Master服務(wù)器和Chunk服務(wù)器。如下圖所示，系統(tǒng)的流程從GFS客戶端開始：GFS客戶端以chunk偏移量制作目錄索引并且發(fā)送請(qǐng)求——GFS Master收到請(qǐng)求通過chunk映射表映射反饋客戶端——客戶端有了chunk handle和chunk 位置，并將文件名和chunk的目錄索引緩存，向chunk服務(wù)器發(fā)送請(qǐng)求——chunk服務(wù)器回復(fù)請(qǐng)求傳輸chunk數(shù)據(jù)。
如果讀者您讀著有點(diǎn)迷糊，這很正常，因?yàn)橹挥猩贁?shù)搜索引擎企業(yè)才采用這樣的技術(shù)。簡單來說是這樣：Google運(yùn)用GFS大大簡化了檢索的難度。
除了GFS，MapReduce對(duì)Google也是功不可沒。Google擁有不少于45萬臺(tái)服務(wù)器，看起來每臺(tái)服務(wù)器的職能都非常明確，但是其中卻有重要的協(xié)同問題有待解決：如何并發(fā)計(jì)算，如何分布數(shù)據(jù)，如何處理失敗，如何負(fù)載均衡？我們可以預(yù)見，無數(shù)的代碼將被用在協(xié)同問題上，而且很可能效率低下。這時(shí)候，MapReduce就派上用場了。MapReduce是Google開發(fā)的C++編程工具，用于大規(guī)模數(shù)據(jù)集的并行運(yùn)算。MapReduce主要功能是提供了一個(gè)簡單強(qiáng)大的接口，可以將計(jì)算自動(dòng)的并發(fā)和分布執(zhí)行。這樣一來，就可以通過普通PC的集群，實(shí)現(xiàn)高性能。MapReduce主要從兩方面提升了系統(tǒng)：首先是失效的計(jì)算機(jī)問題。如果某一臺(tái)計(jì)算機(jī)失效了，或者是I/O出現(xiàn)了問題——這在Google以廉價(jià)服務(wù)器組建的集群中極為常見，MapReduce的解決方法是用多個(gè)計(jì)算機(jī)同時(shí)計(jì)算一個(gè)任務(wù)，一旦一臺(tái)計(jì)算機(jī)有了結(jié)果，其它計(jì)算機(jī)就停止該任務(wù)，而進(jìn)入下一任務(wù)。另外，在MapReduce之間傳輸?shù)臄?shù)據(jù)都是經(jīng)過壓縮的，節(jié)省了很多帶寬資源。至于BigTable，這是一個(gè)用來處理大數(shù)據(jù)量的系統(tǒng)，適合處理半結(jié)構(gòu)化的數(shù)據(jù)。
Google心經(jīng)：
Google總是嘗試用最少的錢，做最多的事情。不要小看那些便宜、不牢靠的PC級(jí)服務(wù)器，一臺(tái)服務(wù)器也許確實(shí)不牢靠，但是45萬臺(tái)的有機(jī)集成卻成為了全球最完善、最穩(wěn)定的系統(tǒng)之一。在采購服務(wù)器方面，Google也從未一次性大量購買，都是有了需求再選購。另一個(gè)能夠體現(xiàn)Google精打細(xì)算的方面是Google盡量壓縮所有能夠壓縮的文件。
包括軟件和硬件，Google的設(shè)計(jì)構(gòu)想都很前衛(wèi)，Google嘗試過許多還在實(shí)驗(yàn)室里的萌芽技術(shù)，如上文所說，很多都取得了巨大成功。Google早先的目標(biāo)是0.5秒鐘做出搜索結(jié)果，但實(shí)際上目前的平均時(shí)間已經(jīng)縮減到了0.25秒。而且，Google從來沒有停止研究的腳步，現(xiàn)在還在測試OpenSoalris，觀察OpenSoalris是否能夠替代Linux。
Google的行為非常踏實(shí)。不參加Top500評(píng)選，文獻(xiàn)里也鮮有相關(guān)資料?？梢奊oogle不吹噓、也沒有過度宣傳，只是勤勤懇懇的更新程序、優(yōu)化集群。今天，google收錄了絕大多數(shù)人類語言的網(wǎng)頁，并且在多數(shù)國家都建立了Google分站，收錄的網(wǎng)頁也是與日俱增，全球影響力更是不言而喻。
向Google的架構(gòu)學(xué)習(xí)，向Google的成就致敬。
Google是伸縮性的王者。Google一直的目標(biāo)就是構(gòu)建高性能高伸縮性的基礎(chǔ)組織來支持它們的產(chǎn)品。
平臺(tái)
Linux
大量語言：Python，Java，C++
狀態(tài)
在2006年大約有450,000臺(tái)廉價(jià)服務(wù)器，這個(gè)數(shù)量到2010年增加到了1,000,000臺(tái)。
在2005年Google索引了80億Web頁面，現(xiàn)在沒有人知道具體數(shù)目，近千億并不斷增長中。
目前在Google有超過500個(gè)GFS集群。一個(gè)集群可以有1000或者甚至5000臺(tái)機(jī)器。成千上萬的機(jī)器從運(yùn)行著5000000000000000字節(jié)存儲(chǔ)的GFS集群獲取數(shù)據(jù)，集群總的讀寫吞吐量可以達(dá)到每秒40兆字節(jié)
目前在Google有6000個(gè)MapReduce程序，而且每個(gè)月都寫成百個(gè)新程序
BigTable伸縮存儲(chǔ)幾十億的URL，幾百千千兆的衛(wèi)星圖片和幾億用戶的參數(shù)選擇
堆棧
Google形象化它們的基礎(chǔ)組織為三層架構(gòu)：
1，產(chǎn)品：搜索，廣告，email，地圖，視頻，聊天，博客
2，分布式系統(tǒng)基礎(chǔ)組織：GFS，MapReduce和BigTable
3，計(jì)算平臺(tái)：一群不同的數(shù)據(jù)中心里的機(jī)器
4，確保公司里的人們部署起來開銷很小
5，花費(fèi)更多的錢在避免丟失日志數(shù)據(jù)的硬件上，其他類型的數(shù)據(jù)則花費(fèi)較少
可信賴的存儲(chǔ)機(jī)制GFS(Google File System)
1，可信賴的伸縮性存儲(chǔ)是任何程序的核心需求。GFS就是Google的核心存儲(chǔ)平臺(tái)
2，Google File System – 大型分布式結(jié)構(gòu)化日志文件系統(tǒng)，Google在里面扔了大量的數(shù)據(jù)
3，為什么構(gòu)建GFS而不是利用已有的東西？因?yàn)榭梢宰约嚎刂埔磺胁⑶疫@個(gè)平臺(tái)與別的不一樣，Google需要：
-跨數(shù)據(jù)中心的高可靠性
-成千上萬的網(wǎng)絡(luò)節(jié)點(diǎn)的伸縮性
-大讀寫帶寬的需求
-支持大塊的數(shù)據(jù)，可能為上千兆字節(jié)
-高效的跨節(jié)點(diǎn)操作分發(fā)來減少瓶頸
4，系統(tǒng)有Master和Chunk服務(wù)器
-Master服務(wù)器在不同的數(shù)據(jù)文件里保持元數(shù)據(jù)。數(shù)據(jù)以64MB為單位存儲(chǔ)在文件系統(tǒng)中?？蛻舳伺cMaster服務(wù)器交流來在文件上做元數(shù)據(jù)操作并且找到包含用戶需要數(shù)據(jù)的那些Chunk服務(wù)器
-Chunk服務(wù)器在硬盤上存儲(chǔ)實(shí)際數(shù)據(jù)。每個(gè)Chunk服務(wù)器跨越3個(gè)不同的Chunk服務(wù)器備份以創(chuàng)建冗余來避免服務(wù)器崩潰。一旦被Master服務(wù)器指明，客戶端程序就會(huì)直接從Chunk服務(wù)器讀取文件
6，一個(gè)上線的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群
7，關(guān)鍵點(diǎn)在于有足夠的基礎(chǔ)組織來讓人們對(duì)自己的程序有所選擇，GFS可以調(diào)整來適應(yīng)個(gè)別程序的需求
使用MapReduce來處理數(shù)據(jù)
1，現(xiàn)在你已經(jīng)有了一個(gè)很好的存儲(chǔ)系統(tǒng)，你該怎樣處理如此多的數(shù)據(jù)呢？比如你有許多TB的數(shù)據(jù)存儲(chǔ)在1000臺(tái)機(jī)器上。數(shù)據(jù)庫不能伸縮或者伸縮到這種級(jí)別花費(fèi)極大，這就是MapReduce出現(xiàn)的原因
2，MapReduce是一個(gè)處理和生成大量數(shù)據(jù)集的編程模型和相關(guān)實(shí)現(xiàn)。用戶指定一個(gè)map方法來處理一個(gè)鍵/值對(duì)來生成一個(gè)中間的鍵/值對(duì)，還有一個(gè)reduce方法來合并所有關(guān)聯(lián)到同樣的中間鍵的中間值。許多真實(shí)世界的任務(wù)都可以使用這種模型來表現(xiàn)。以這種風(fēng)格來寫的程序會(huì)自動(dòng)并行的在一個(gè)大量機(jī)器的集群里運(yùn)行。運(yùn)行時(shí)系統(tǒng)照顧輸入數(shù)據(jù)劃分、程序在機(jī)器集之間執(zhí)行的調(diào)度、機(jī)器失敗處理和必需的內(nèi)部機(jī)器交流等細(xì)節(jié)。這允許程序員沒有多少并行和分布式系統(tǒng)的經(jīng)驗(yàn)就可以很容易使用一個(gè)大型分布式系統(tǒng)資源
3，為什么使用MapReduce？
-跨越大量機(jī)器分割任務(wù)的好方式
-處理機(jī)器失敗
-可以與不同類型的程序工作，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操作。你可以預(yù)先計(jì)算有用的數(shù)據(jù)、查詢字?jǐn)?shù)統(tǒng)計(jì)、對(duì)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頁面里的字?jǐn)?shù)。你將存儲(chǔ)在GFS里的所有頁面拋入MapReduce。這將在成千上萬臺(tái)機(jī)器上同時(shí)進(jìn)行并且所有的調(diào)整、工作調(diào)度、失敗處理和數(shù)據(jù)傳輸將自動(dòng)完成
-步驟類似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce里一個(gè)map操作將一些數(shù)據(jù)映射到另一個(gè)中，產(chǎn)生一個(gè)鍵值對(duì)，在我們的例子里就是字和字?jǐn)?shù)
-Shuffling操作聚集鍵類型
-Reduction操作計(jì)算所有鍵值對(duì)的綜合并產(chǎn)生最終的結(jié)果
6，Google索引操作管道有大約20個(gè)不同的map和reduction。
7，程序可以非常小，如20到50行代碼
8，一個(gè)問題是掉隊(duì)者。掉隊(duì)者是一個(gè)比其他程序慢的計(jì)算，它阻塞了其他程序。掉隊(duì)者可能因?yàn)榫徛腎O或者臨時(shí)的CPU不能使用而發(fā)生。解決方案是運(yùn)行多個(gè)同樣的計(jì)算并且當(dāng)一個(gè)完成后殺死所有其他的
9，數(shù)據(jù)在Map和Reduce服務(wù)器之間傳輸時(shí)被壓縮了。這可以節(jié)省帶寬和I/O。
在BigTable里存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)
1，BigTable是一個(gè)大伸縮性、錯(cuò)誤容忍、自管理的系統(tǒng)，它包含千千兆的內(nèi)存和1000000000000000的存儲(chǔ)。它可以每秒鐘處理百萬的讀寫
2，BigTable是一個(gè)構(gòu)建于GFS之上的分布式哈希機(jī)制。它不是關(guān)系型數(shù)據(jù)庫。它不支持join或者SQL類型查詢
3，它提供查詢機(jī)制來通過鍵訪問結(jié)構(gòu)化數(shù)據(jù)。GFS存儲(chǔ)存儲(chǔ)不透明的數(shù)據(jù)而許多程序需求有結(jié)構(gòu)化數(shù)據(jù)
4，商業(yè)數(shù)據(jù)庫不能達(dá)到這種級(jí)別的伸縮性并且不能在成千上萬臺(tái)機(jī)器上工作
5，通過控制它們自己的低級(jí)存儲(chǔ)系統(tǒng)Google得到更多的控制權(quán)來改進(jìn)它們的系統(tǒng)。例如，如果它們想讓跨數(shù)據(jù)中心的操作更簡單這個(gè)特性，它們可以內(nèi)建它
6，系統(tǒng)運(yùn)行時(shí)機(jī)器可以自由的增刪而整個(gè)系統(tǒng)保持工作
7，每個(gè)數(shù)據(jù)條目存儲(chǔ)在一個(gè)格子里，它可以通過一個(gè)行key和列key或者時(shí)間戳來訪問
8，每一行存儲(chǔ)在一個(gè)或多個(gè)tablet中。一個(gè)tablet是一個(gè)64KB塊的數(shù)據(jù)序列并且格式為SSTable
9，BigTable有三種類型的服務(wù)器：
-Master服務(wù)器分配tablet服務(wù)器，它跟蹤tablet在哪里并且如果需要?jiǎng)t重新分配任務(wù)
-Tablet服務(wù)器為tablet處理讀寫請(qǐng)求。當(dāng)tablet超過大小限制(通常是100MB-200MB)時(shí)它們拆開tablet。當(dāng)一個(gè)Tablet服務(wù)器失敗時(shí)，則100個(gè)Tablet服務(wù)器各自挑選一個(gè)新的tablet然后系統(tǒng)恢復(fù)。
-Lock服務(wù)器形成一個(gè)分布式鎖服務(wù)。像打開一個(gè)tablet來寫、Master調(diào)整和訪問控制檢查等都需要互斥
10，一個(gè)locality組可以用來在物理上將相關(guān)的數(shù)據(jù)存儲(chǔ)在一起來得到更好的locality選擇
11，tablet盡可能的緩存在RAM里
硬件
1，當(dāng)你有很多機(jī)器時(shí)你怎樣組織它們來使得使用和花費(fèi)有效？
2，使用非常廉價(jià)的硬件
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主板，低端存儲(chǔ)
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，一個(gè)基礎(chǔ)組織處理程序的版本，這樣它們可以發(fā)布而不用害怕會(huì)破壞什么東西
Google將來的方向
1，支持地理位置分布的集群
2，為所有數(shù)據(jù)創(chuàng)建一個(gè)單獨(dú)的全局名字空間。當(dāng)前的數(shù)據(jù)由集群分離
3，更多和更好的自動(dòng)化數(shù)據(jù)遷移和計(jì)算
4，解決當(dāng)使用網(wǎng)絡(luò)劃分來做廣闊區(qū)域的備份時(shí)的一致性問題(例如保持服務(wù)即使一個(gè)集群離線維護(hù)或由于一些損耗問題)
學(xué)到的東西
1，基礎(chǔ)組織是有競爭性的優(yōu)勢。特別是對(duì)Google而言。Google可以很快很廉價(jià)的推出新服務(wù)，并且伸縮性其他人很難達(dá)到。許多公司采取完全不同的方式。許多公司認(rèn)為基礎(chǔ)組織開銷太大。Google認(rèn)為自己是一個(gè)系統(tǒng)工程公司，這是一個(gè)新的看待軟件構(gòu)建的方式
2，跨越多個(gè)數(shù)據(jù)中心仍然是一個(gè)未解決的問題。大部分網(wǎng)站都是一個(gè)或者最多兩個(gè)數(shù)據(jù)中心。我們不得不承認(rèn)怎樣在一些數(shù)據(jù)中心之間完整的分布網(wǎng)站是很需要技巧的
3，如果你自己沒有時(shí)間從零開始重新構(gòu)建所有這些基礎(chǔ)組織你可以看看Hadoop。Hadoop是這里很多同樣的主意的一個(gè)開源實(shí)現(xiàn)
4，平臺(tái)的一個(gè)優(yōu)點(diǎn)是初級(jí)開發(fā)人員可以在平臺(tái)的基礎(chǔ)上快速并且放心的創(chuàng)建健全的程序。如果每個(gè)項(xiàng)目都需要發(fā)明同樣的分布式基礎(chǔ)組織的輪子，那么你將陷入困境因?yàn)橹涝鯓油瓿蛇@項(xiàng)工作的人相對(duì)較少
5，協(xié)同工作不一直是擲骰子。通過讓系統(tǒng)中的所有部分一起工作則一個(gè)部分的改進(jìn)將幫助所有的部分。改進(jìn)文件系統(tǒng)則每個(gè)人從中受益而且是透明的。如果每個(gè)項(xiàng)目使用不同的文件系統(tǒng)則在整個(gè)堆棧中享受不到持續(xù)增加的改進(jìn)
6，構(gòu)建自管理系統(tǒng)讓你沒必要讓系統(tǒng)關(guān)機(jī)。這允許你更容易在服務(wù)器之間平衡資源、動(dòng)態(tài)添加更大的容量、讓機(jī)器離線和優(yōu)雅的處理升級(jí)
7，創(chuàng)建可進(jìn)化的基礎(chǔ)組織，并行的執(zhí)行消耗時(shí)間的操作并采取較好的方案
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，考慮壓縮。當(dāng)你有許多CPU而IO有限時(shí)壓縮是一個(gè)好的選擇。
Google主要以GFS、MapReduce、BigTable這三大平臺(tái)來支撐其龐大的業(yè)務(wù)系統(tǒng)，我稱他們?yōu)镚oogle三劍客，網(wǎng)上也有說是Google的三架馬車。
一、GFS（Google File System）
這是Google獨(dú)特的一個(gè)面向大規(guī)模數(shù)據(jù)密集型應(yīng)用的、可伸縮的分布式文件系統(tǒng)，由于這個(gè)文件系統(tǒng)是通過軟件調(diào)度來實(shí)現(xiàn)的，所以Google可以把GFS部署在很多廉價(jià)的PC機(jī)上，來達(dá)到用昂貴服務(wù)器一樣的效果。
下面是一張Google GFS的架構(gòu)圖：
從上圖我們可看到Google的GFS主要由一個(gè)master和很多chunkserver組成，master主要是負(fù)責(zé)維護(hù)系統(tǒng)中的名字空間、訪問控制信息、從文件到塊的映射以及塊的當(dāng)前位置等元素?fù)?jù)，并通過心跳信號(hào)與chunkserver通信，搜集并保存chunkserver的狀態(tài)信息。chunkserver主要是用來存儲(chǔ)數(shù)據(jù)塊，google把每個(gè)數(shù)據(jù)塊的大小設(shè)計(jì)成64M，至于為什么這么大后面會(huì)提到，每個(gè)chunk是由master分配的chunk-handle來標(biāo)識(shí)的，為了提高系統(tǒng)的可靠性，每個(gè)chunk會(huì)被復(fù)制3個(gè)副本放到不同的chunkserver中。
當(dāng)然這樣的單master設(shè)計(jì)也會(huì)帶來單點(diǎn)故障問題和性能瓶頸問題，Google是通過減少client與master的交互來解決的，client均是直接與chunkserver通信，master僅僅提供查詢數(shù)據(jù)塊所在的chunkserver以及詳細(xì)位置。下面是在GFS上查詢的一般流程：
1、client使用固定的塊大小將應(yīng)用程序指定的文件名和字節(jié)偏移轉(zhuǎn)換成文件的一個(gè)塊索引（chunk index）。
2、給master發(fā)送一個(gè)包含文件名和塊索引的請(qǐng)求。
3、master回應(yīng)對(duì)應(yīng)的chunk handle和副本的位置（多個(gè)副本）。
4、client以文件名和塊索引為鍵緩存這些信息。（handle和副本的位置）。
5、Client 向其中一個(gè)副本發(fā)送一個(gè)請(qǐng)求，很可能是最近的一個(gè)副本。請(qǐng)求指定了chunk handle（chunkserver以chunk handle標(biāo)識(shí)chunk）和塊內(nèi)的一個(gè)字節(jié)區(qū)間。
6、除非緩存的信息不再有效（cache for a limited time）或文件被重新打開，否則以后對(duì)同一個(gè)塊的讀操作不再需要client和master間的交互。
不過我還是有疑問，google可以通過減少client與master通信來解決性能瓶頸問題，但單點(diǎn)問題呢，一臺(tái)master掛掉豈不是完蛋了，總感覺不太放心，可能是我了解不夠透徹，不知道哪位朋友能解釋一下，謝謝：）
二、MapReduce，Google的分布式并行計(jì)算系統(tǒng)
如果上面的GFS解決了Google的海量數(shù)據(jù)的存儲(chǔ)，那這個(gè)MapReduce則是解決了如何從這些海量數(shù)據(jù)中快速計(jì)算并獲取指定數(shù)據(jù)的問題。我們知道，Google的每一次搜索都在零點(diǎn)零幾秒，能在這么短時(shí)間里環(huán)游世界一周，這里MapReduce有很大的功勞。
Map即映射，Reduce即規(guī)約，由master服務(wù)器把map和reduce任務(wù)分發(fā)到各自worker服務(wù)器中運(yùn)行計(jì)算，最后把結(jié)果規(guī)約合并后返回給用戶。這個(gè)過程可以由下圖來說明。
按照自己的理解，簡單對(duì)上圖加點(diǎn)說明：
1、首先把用戶請(qǐng)求的數(shù)據(jù)文件切割成多份，每一份（即每一個(gè)split）被拷貝在集群中不同機(jī)器上，然后由集群啟動(dòng)程序中的多份拷貝。
2、master把map和reduce任務(wù)交給相對(duì)空閑的worker處理，并阻塞等待處理結(jié)果。
3、處理map任務(wù)的worker接到任務(wù)后，把以key/value形式的輸入數(shù)據(jù)傳遞給map函數(shù)進(jìn)行處理，并將處理結(jié)果也以key/value的形式輸出，并保存在內(nèi)存中。
4、上一步內(nèi)存中的結(jié)果是要進(jìn)行reduce的，于是這些map worker就把這些數(shù)據(jù)的位置返回給master，這樣master知道數(shù)據(jù)位置就可以繼續(xù)分配reduce任務(wù)，起到了連接map和reduce函數(shù)的作用。
5、reduce worker知道這些數(shù)據(jù)的位置后就去相應(yīng)位置讀取這些數(shù)據(jù)，并對(duì)這些數(shù)據(jù)按key進(jìn)行排序。將排序后的數(shù)據(jù)序列放入reduce函數(shù)中進(jìn)行合并和規(guī)約，最后每個(gè)reduce任務(wù)輸出一個(gè)結(jié)果文件。
6、任務(wù)結(jié)束，master解除阻塞，喚醒用戶。
以上是個(gè)人的一些理解，有不對(duì)的地方請(qǐng)指出。
三、BigTable，分布式的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)系統(tǒng)？
BigTable是基于GFS和MapReduce之上的，那么google既然已經(jīng)有了GFS，為何還要有BigTable呢（也是我原先的一個(gè)疑問）？后來想想這和已經(jīng)有操作系統(tǒng)文件系統(tǒng)為何還要有SQL SERVER數(shù)據(jù)庫一樣的道理，GFS是更底層的文件系統(tǒng)，而BigTable建立在其上面，不僅可以存儲(chǔ)結(jié)構(gòu)化的數(shù)據(jù)，而且可以更好的管理和做出負(fù)載均衡決策。
以下是BigTable的架構(gòu)圖：
它完全是一個(gè)基于key/value的數(shù)據(jù)庫，和一般的關(guān)系型數(shù)據(jù)庫不同，google之所以采用BigTable，因?yàn)樗跐M足需求的同時(shí)簡化了系統(tǒng)，比如去掉了事務(wù)、死鎖檢測等模塊，讓系統(tǒng)更高效。更重要的一點(diǎn)是在BigTable中數(shù)據(jù)是沒有格式的，它僅僅是一個(gè)個(gè)key/value的pairs，用戶可以自己去定義數(shù)據(jù)的格式，這也大大提高了BigTable的靈活性和擴(kuò)展性。
四、總結(jié)
這篇隨筆主要是一些總結(jié)性的內(nèi)容，Google架構(gòu)遠(yuǎn)遠(yuǎn)不止這些。
