雲計算關鍵技術系列之二——GFS

由於搜尋引擎需要處理海量的資料，所以Google的兩位創始人Larry Page和Sergey Brin在創業初期設計一套名為「BigFiles」的檔案系統，而GFS(全稱為「Google File System」) 這套分散式檔案系統則是「BigFiles」的延續。

技術概覽

首先，介紹它的架構，GFS主要分為兩類節點：其一是Master節點，其主要存儲與資料檔案相關的中繼資料，而不是Chunk(資料塊)。 中繼資料包括一個能將64位標籤映射到資料塊的位置及其組成檔的表格，資料塊副本位置和哪個進程正在讀寫特定的資料塊等。 還有Master節點會週期性地接收從每個Chunk節點來的更新(「Heart-beat」)來讓中繼資料保持最新狀態;其二是Chunk節點，它主要用於存儲資料。 在每個Chunk節點上，資料檔案會以每個預設大小為64MB Chunk的方式存儲，而且每個Chunk有唯一一個64位標籤，並且每個Chunk都會在整個分散式系統被覆制多次，預設次數為3。 下圖就是GFS的架構圖：

GFS的架構圖

接著，在設計上，GFS主要有八個特點：

1.大檔和大資料塊：資料檔案的大小普遍在GB級別，而且其每個資料塊預設大小為64MB，這樣做的好處是減少了中繼資料的大小，從而能使Master節點能夠非常方便地將中繼資料都放置在記憶體中以提升訪問效率。

2.操作以添加為主：檔很少會被刪減或者覆蓋，通常只是進行添加或者讀取操作，這樣能充分考慮到硬碟線性輸送量大，但隨機讀寫慢的特點。

3.支援容錯：首先，雖然當時為了設計方便，採用了單Master的方案，但是整個系統會保證Master節點會有其相對應的替身(Shadow)，以便於當Master節點出現問題時進行切換。 其次，在Chunk層，GFS已經在設計上將節點失敗視為常態，所以能非常好地處理Chunk節點失效的問題。

4.高輸送量：雖然以單個節點來看，GFS的性能無論是從輸送量還是延遲都很普通，但因為其支援上千的節點，所以總的資料輸送量是非常驚人的。

5.保護資料：檔被分割成固定尺寸的資料塊以便於保存，而且每個資料塊都會被系統至少複製三份。

6.擴展能力強：因為中繼資料偏小，使得一個Master節點能控制和管理上千個存資料的Chunk節點。

7.支援壓縮：對於那些稍舊的檔，可以通過對它進行壓縮，來節省硬碟空間，並且壓縮率非常驚人，有時甚至接近90%。

8.基於使用者空間：GFS主要運行于系統的使用者空間(User Time)，雖然在效率方面，使用者空間比內核空間略低，但是更便於開發和測試，還有，就是能更好利用Linux的自帶的一些POSIX API。

優劣點

由於GFS主要是為了存儲海量搜索資料而設計的，所以它在輸送量(Throughput)和伸縮性(Scalability)這兩方面表現非常優異，可謂業界的「翹楚」，但是由於其主要以64MB資料塊形式存儲， 所以在隨機訪問方面速度並不優秀，雖然這點可謂是它的「軟肋」，但是這本身也是其當初為了輸送量和伸縮性所做的權衡。

相關產品

和MapReduce相似的是，GFS在開源界也有其對應的產品，最出名的是HDFS分散式檔案系統，在功能和設計上，HDFS從GFS身上借鑒了很多東西，而且由於其本身就是Hadoop系列的一部分， 所以它為了更好Hadoop這個MapReduce框架做了很多優化。

實際用例

　　現在Google內部至少運行著200多個GFS集群，最大的集群有幾千台伺服器，資料量是PB級別的，並且服務于多個Google服務，包括Google搜索和Google Earth等。 同時，在最近幾年，由於上面提到的高延遲問題，所以GFS並不很適合新的一些Google產品，比YouTube、Gmail和非常強調即時性的Caffeine搜尋引擎等，所以Google已經在開發下一代GFS，代號為「 Colossus」，並且在設計方面有許多不同，比如，支援分散式Master節點來提升高可用性並支撐更多檔和chunk節點能支援1MB大小的chunk以支撐低延遲應用的需要等，希望等Colossus成熟的時候， Google也能像當初GFS那樣，將其設計的細節和經驗拿出來和大家分享。