雲端運算背後的秘密（2）-GFS

由於周日Linode在加州機房出現停電事故，所以這兩天PeopleYun沒法訪問，在這裡向大家表示歉意

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

技術概覽

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

圖1. 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在開源界也有其對應的產品，最出名的是HDFSDistributed File System，在功能和設計上，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那樣，將其設計的細節和經驗拿出來和大家分享。