云計(jì)算背后的秘密（2）-GFS
由于周日Linode在加州機(jī)房出現(xiàn)停電事故，所以這兩天PeopleYun沒法訪問，在這里向大家表示歉意
由于搜索引擎需要處理海量的數(shù)據(jù)，所以Google的兩位創(chuàng)始人Larry Page和Sergey Brin在創(chuàng)業(yè)初期設(shè)計(jì)一套名為“BigFiles”的文件系統(tǒng)，而GFS（全稱為“Google File System”）這套分布式文件系統(tǒng)則是“BigFiles”的延續(xù)。
技術(shù)概覽
首先，介紹它的架構(gòu)，GFS主要分為兩類節(jié)點(diǎn)：其一是Master節(jié)點(diǎn)，其主要存儲(chǔ)與數(shù)據(jù)文件相關(guān)的元數(shù)據(jù)，而不是Chunk（數(shù)據(jù)塊）。元數(shù)據(jù)包括一個(gè)能將64位標(biāo)簽映射到數(shù)據(jù)塊的位置及其組成文件的表格，數(shù)據(jù)塊副本位置和哪個(gè)進(jìn)程正在讀寫特定的數(shù)據(jù)塊等。還有Master節(jié)點(diǎn)會(huì)周期性地接收從每個(gè)Chunk節(jié)點(diǎn)來的更新（“Heart-beat”）來讓元數(shù)據(jù)保持最新狀態(tài)；其二是Chunk節(jié)點(diǎn)，它主要用于存儲(chǔ)數(shù)據(jù)。在每個(gè)Chunk節(jié)點(diǎn)上，數(shù)據(jù)文件會(huì)以每個(gè)默認(rèn)大小為64MB Chunk的方式存儲(chǔ)，而且每個(gè)Chunk有唯一一個(gè)64位標(biāo)簽，并且每個(gè)Chunk都會(huì)在整個(gè)分布式系統(tǒng)被復(fù)制多次，默認(rèn)次數(shù)為3。下圖就是GFS的架構(gòu)圖：
圖1. GFS的架構(gòu)圖
接著，在設(shè)計(jì)上，GFS主要有八個(gè)特點(diǎn)：
大文件和大數(shù)據(jù)塊：數(shù)據(jù)文件的大小普遍在GB級(jí)別，而且其每個(gè)數(shù)據(jù)塊默認(rèn)大小為64MB，這樣做的好處是減少了元數(shù)據(jù)的大小，從而能使Master節(jié)點(diǎn)能夠非常方便地將元數(shù)據(jù)都放置在內(nèi)存中以提升訪問效率。
操作以添加為主：文件很少會(huì)被刪減或者覆蓋，通常只是進(jìn)行添加或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大，但隨機(jī)讀寫慢的特點(diǎn)。
支持容錯(cuò)：首先，雖然當(dāng)時(shí)為了設(shè)計(jì)方便，采用了單Master的方案，但是整個(gè)系統(tǒng)會(huì)保證Master節(jié)點(diǎn)會(huì)有其相對(duì)應(yīng)的替身（Shadow），以便于當(dāng)Master節(jié)點(diǎn)出現(xiàn)問題時(shí)進(jìn)行切換。其次，在Chunk層，GFS已經(jīng)在設(shè)計(jì)上將節(jié)點(diǎn)失敗視為常態(tài)，所以能非常好地處理Chunk節(jié)點(diǎn)失效的問題。
高吞吐量：雖然以單個(gè)節(jié)點(diǎn)來看，GFS的性能無論是從吞吐量還是延遲都很普通，但因?yàn)槠渲С稚锨У墓?jié)點(diǎn)，所以總的數(shù)據(jù)吞吐量是非常驚人的。
保護(hù)數(shù)據(jù)：文件被分割成固定尺寸的數(shù)據(jù)塊以便于保存，而且每個(gè)數(shù)據(jù)塊都會(huì)被系統(tǒng)至少?gòu)?fù)制三份。
擴(kuò)展能力強(qiáng)：因?yàn)樵獢?shù)據(jù)偏小，使得一個(gè)Master節(jié)點(diǎn)能控制和管理上千個(gè)存數(shù)據(jù)的Chunk節(jié)點(diǎn)。
支持壓縮：對(duì)于那些稍舊的文件，可以通過對(duì)它進(jìn)行壓縮，來節(jié)省硬盤空間，并且壓縮率非常驚人，有時(shí)甚至接近90%。
基于用戶空間：GFS主要運(yùn)行于系統(tǒng)的用戶空間（User Time），雖然在效率方面，用戶空間比內(nèi)核空間略低，但是更便于開發(fā)和測(cè)試，還有，就是能更好利用Linux的自帶的一些POSIX API。
優(yōu)劣點(diǎn)
由于GFS主要是為了存儲(chǔ)海量搜索數(shù)據(jù)而設(shè)計(jì)的，所以它在吞吐量（Throughput）和伸縮性（Scalability）這兩方面表現(xiàn)非常優(yōu)異，可謂業(yè)界的“翹楚”，但是由于其主要以64MB數(shù)據(jù)塊形式存儲(chǔ)，所以在隨機(jī)訪問方面速度并不優(yōu)秀，雖然這點(diǎn)可謂是它的“軟肋”，但是這本身也是其當(dāng)初為了吞吐量和伸縮性所做的權(quán)衡。
相關(guān)產(chǎn)品
和MapReduce相似的是，GFS在開源界也有其對(duì)應(yīng)的產(chǎn)品，最出名的是HDFS分布式文件系統(tǒng)，在功能和設(shè)計(jì)上，HDFS從GFS身上借鑒了很多東西，而且由于其本身就是Hadoop系列的一部分，所以它為了更好Hadoop這個(gè)MapReduce框架做了很多優(yōu)化。
實(shí)際用例
現(xiàn)在Google內(nèi)部至少運(yùn)行著200多個(gè)GFS集群，最大的集群有幾千臺(tái)服務(wù)器，數(shù)據(jù)量是PB級(jí)別的，并且服務(wù)于多個(gè)Google服務(wù)，包括Google搜索和Google Earth等。同時(shí)，在最近幾年，由于上面提到的高延遲問題，所以GFS并不很適合新的一些Google產(chǎn)品，比YouTube、Gmail和非常強(qiáng)調(diào)實(shí)時(shí)性的Caffeine搜索引擎等，所以Google已經(jīng)在開發(fā)下一代GFS，代號(hào)為“Colossus”，并且在設(shè)計(jì)方面有許多不同，比如，支持分布式Master節(jié)點(diǎn)來提升高可用性并支撐更多文件和chunk節(jié)點(diǎn)能支持1MB大小的chunk以支撐低延遲應(yīng)用的需要等，希望等Colossus成熟的時(shí)候，Google也能像當(dāng)初GFS那樣，將其設(shè)計(jì)的細(xì)節(jié)和經(jīng)驗(yàn)?zāi)贸鰜砗痛蠹曳窒怼?/p>
【編輯推薦】
