GFS, HDFS, Blob File System架構對比
作者: Chuanhui | 可以轉載， 但必須以超鏈接形式標明文章原始出處和作者信息及版權聲明
本文鏈接地址: http://www.nosqlnotes.net/archives/119
分佈式文件系統很多，包括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其實是有區別的。GFS和HDFS比較通用，可以在GFS和HDFS上搭建通用的表格系統，如Bigtable，Hypertable以及HBase，而Blog File System的應用場景一般爲圖片，相冊這類的Blob數據。GFS的數據是一點一點追加寫入到系統的，而Blob數據一般是整個Blob塊一次性準備好寫入到Blob文件系統，如用戶上傳一個圖片。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有可能可以做到。