云計算背后的秘密（2）-GFS
由于周日Linode在加州機房出現停電事故，所以這兩天PeopleYun沒法訪問，在這里向大家表示歉意
由于搜索引擎需要處理海量的數據，所以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的架構圖：
圖1. GFS的架構圖
接著，在設計上，GFS主要有八個特點：
大文件和大數據塊：數據文件的大小普遍在GB級別，而且其每個數據塊默認大小為64MB，這樣做的好處是減少了元數據的大小，從而能使Master節點能夠非常方便地將元數據都放置在內存中以提升訪問效率。
操作以添加為主：文件很少會被刪減或者覆蓋，通常只是進行添加或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大，但隨機讀寫慢的特點。
支持容錯：首先，雖然當時為了設計方便，采用了單Master的方案，但是整個系統會保證Master節點會有其相對應的替身（Shadow），以便于當Master節點出現問題時進行切換。其次，在Chunk層，GFS已經在設計上將節點失敗視為常態，所以能非常好地處理Chunk節點失效的問題。
高吞吐量：雖然以單個節點來看，GFS的性能無論是從吞吐量還是延遲都很普通，但因為其支持上千的節點，所以總的數據吞吐量是非常驚人的。
保護數據：文件被分割成固定尺寸的數據塊以便于保存，而且每個數據塊都會被系統至少復制三份。
擴展能力強：因為元數據偏小，使得一個Master節點能控制和管理上千個存數據的Chunk節點。
支持壓縮：對于那些稍舊的文件，可以通過對它進行壓縮，來節省硬盤空間，并且壓縮率非常驚人，有時甚至接近90%。
基于用戶空間：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那樣，將其設計的細節和經驗拿出來和大家分享。
【編輯推薦】
