分散式檔案系統很多，包括GFS，HDFS，淘寶開源的TFS，Tencent用於相簿儲存的TFS (Tencent FS，為了便於區別，後續稱為QFS)，以及Facebook Haystack。其中，TFS，QFS以及Haystack需要解決的問題以及架構都很類似，這三個檔案系統稱為Blob FS (Blob File System)。本文從分散式架構的角度對三種典型的檔案系統進行對比。

我們先看GFS和HDFS。HDFS基本可以認為是GFS的一個簡化版實現，二者因此有很多相似之處。首先，GFS和HDFS都採用單一主控機+多臺工作機的模式，由一臺主控機(Master)儲存系統全部元資料，並實現資料的分佈、複製、備份決策，主控機還實現了元資料的checkpoint和操作日誌記錄及回放功能。工作機儲存資料，並根據主控機的指令進行資料儲存、資料遷移和資料計算等。其次，GFS和HDFS都通過資料分塊和複製（多副本，一般是3）來提供更高的可靠性和更高的效能。當其中一個副本不可用時，系統都提供副本自動複製功能。同時，針對資料讀多於寫的特點，讀服務被分配到多個副本所在機器，提供了系統的整體效能。最後，GFS和HDFS都提供了一個樹結構的檔案系統，實現了類似與Linux下的檔案複製、改名、移動、建立、刪除操作以及簡單的許可權管理等。

然而，GFS和HDFS在關鍵點的設計上差異很大，HDFS為了規避GFS的複雜度進行了很多簡化。首先，GFS最為複雜的部分是對多客戶端併發追加同一個檔案，即多客戶端併發Append模型。GFS允許檔案被多次或者多個客戶端同時開啟以追加資料，以記錄為單位。假設GFS追加記錄的大小為16KB ~ 16MB之間，平均大小為1MB，如果每次追加都訪問GFS Master顯然很低效，因此，GFS通過Lease機制將每個Chunk的寫許可權授權給Chunk Server。寫Lease的含義是Chunk Server對某個Chunk在Lease有效期內(假設為12s)有寫許可權，擁有Lease的Chunk Server稱為Primary Chunk Server，如果Primary Chunk Server宕機，Lease有效期過後Chunk的寫Lease可以分配給其它Chunk Server。多客戶端併發追加同一個檔案導致Chunk Server需要對記錄進行定序，客戶端的寫操作失敗後可能重試，從而產生重複記錄，再加上客戶端API為非同步模型，又產生了記錄亂序問題。Append模型下重複記錄、亂序等問題加上Lease機制，尤其是同一個Chunk的Lease可能在Chunk Server之間遷移，極大地提高了系統設計和一致性模型的複雜度。而在HDFS中，HDFS檔案只允許一次開啟並追加資料，客戶端先把所有資料寫入本地的臨時檔案中，等到資料量達到一個Chunk的大小（通常為64MB），請求HDFS Master分配工作機及Chunk編號，將一個Chunk的資料一次性寫入HDFS檔案。由於累積64MB資料才進行實際寫HDFS系統，對HDFS Master造成的壓力不大，不需要類似GFS中的將寫Lease授權給工作機的機制，且沒有了重複記錄和亂序的問題，大大地簡化了系統的設計。然而，我們必須知道，HDFS由於不支援Append模型帶來的很多問題，構建於HDFS之上的Hypertable和HBase需要使用HDFS存放表格系統的操作日誌，由於HDFS的客戶端需要攢到64MB資料才一次性寫入到HDFS中，Hypertable和HBase中的表格服務節點(對應於Bigtable中的Tablet Server)如果宕機，部分操作日誌沒有寫入到HDFS，可能會丟資料。其次是Master單點失效的處理。GFS中採用主從模式備份Master的系統元資料，當主Master失效時，可以通過分散式選舉備機接替主Master繼續對外提供服務，而由於Replication及主備切換本身有一定的複雜性，HDFS Master的持久化資料只寫入到本機（可能寫入多份存放到Master機器的多個磁碟中防止某個磁碟損害），出現故障時需要人工介入。另外一點是對快照的支援。GFS通過內部採用copy-on-write的資料結構實現叢集快照功能，而HDFS不提供快照功能。在大規模分散式系統中，程式有bug是很正常的情況，雖然大多數情況下可以修復bug，不過很難通過補償操作將系統資料恢復到一致的狀態，往往需要底層系統提供快照功能，將系統恢復到最近的某個一致狀態。

總之，HDFS基本可以認為是GFS的簡化版，由於時間及應用場景等各方面的原因對GFS的功能做了一定的簡化，大大降低了複雜度。

Blob File System的需求和GFS/HDFS其實是有區別的。
（1）GFS和HDFS比較通用，可以在GFS和HDFS上搭建通用的表格系統，如Bigtable，Hypertable以及HBase，而Blog File System的應用場景一般為圖片，相簿這類的Blob資料。
（2）GFS的資料是一點一點追加寫入到系統的，而Blob資料一般是整個Blob塊一次性準備好寫入到Blob檔案系統，如使用者上傳一個圖片。
（3）GFS是大檔案系統，考慮吞吐量，可以在上面搭建通用KV或者通用表格系統，而Blob檔案系統是小檔案系統，一般只是用來存放Blob資料。

GFS與Blob FS看起來也有很多相似之處。
比如GFS和TFS目前都採用單一主控機+多臺工作機的模式，主控機實現資料的分佈、複製、備份決策，工作機儲存資料，並根據主控機命令進行資料儲存，遷移等.

但是，二者的區別還是比較大的。
由於業務場景不同，二者面臨的問題不同，在Blob FS中，由於整個Blob塊資料一次準備就緒，Blob FS的資料寫入模型天生就是比較簡單，每次寫入都請求Master分配Blob塊編號及寫入的機器列表，然後一次性寫入到多臺機器中。然而，Blob FS面臨的挑戰是元資料過於龐大的問題。由於Blob FS儲存的Blob塊個數一般很大，比如TFS中儲存了百億級的淘寶圖片，假設每張圖片的元資料佔用20位元組，所有的元資料佔用空間為10G * 20 = 200GB，單機記憶體存放不下，並且資料量膨脹很快。因此，TFS, QFS以及Facebook Haystack都採取了幾乎相同的思路，Blob FS不存放元資料，元資料存放到外部的系統中。比如，淘寶TFS中的元資料為圖片的id，這些圖片id存放在外部資料庫，比如商品庫中，外部資料庫一般是Oracle或者Mysql sharding叢集。Blob FS內部也是按照Chunk塊組織資料，每個Blob檔案是一個邏輯檔案，內部的Chunk塊是一個物理檔案，多個邏輯檔案共享同一個物理檔案，從而減少單個工作機的物理檔案的個數。由於所有物理檔案的元資料都可以存放到記憶體中，每次讀取Blob邏輯檔案只需要一次磁碟IO，基本可以認為達到了最優。

總之，HDFS和GFS可以認為是類似的，GFS基本覆蓋了HDFS的功能，而Blob FS和GFS面臨的問題不同，設計的出發點也不一樣，兩類系統有本質的差別。如果需要將GFS和Blob FS統一成一套系統，這套系統需要同時支援大檔案和小檔案，且這套系統因為存放的元資料量太大，Master節點本身也需要設計成分散式。這個大一統的系統實現複雜度非常高，目前只有GFS v2有可能可以做到。