轉載:http://blog.csdn.net/mindfloating/article/details/49103611

我們知道 HDFS 最早是根據 GFS（Google File System）的論文概念模型來設計實現的。 
然後呢，我就去把 GFS 的原始論文找出來仔細看了遍，GFS 的整體架構圖如下： 

HDFS 參照了它所以大部分架構設計概念是類似的，比如 HDFS NameNode 相當於 GFS Master，HDFS DataNode 相當於 GFS chunkserver。 
但還有些細節不同的地方，所以本文主要分析下不同的地方。

寫入模型

HDFS 在考慮寫入模型時做了一個簡化，就是同一時刻只允許一個寫入者或追加者。 
在這個模型下同一個檔案同一個時刻只允許一個客戶端寫入或追加。 
而 GFS 則允許同一時刻多個客戶端併發寫入或追加同一檔案。

允許併發寫入帶來了更復雜的一致性問題。 
多個客戶端併發寫入時，它們之間的順序是無法保證的，同一個客戶端連續追加成功的多個記錄也可能被打斷。 
這意味著一個客戶端在連續寫入檔案資料時，它的資料最終在檔案中的分佈可能是不連續的。

所謂一致性就是，對同一個檔案，所有的客戶端看到的資料是一致的，不管它們是從哪個副本讀取的。 
如果允許多個客戶端同時寫一個檔案，怎麼保證寫入資料在多個副本間一致？ 
我們前面講 HDFS 時它只允許一個寫入者按流水線方式寫入多個副本，寫入順序一致，寫入完成後資料將保持最終一致。 
而對多個客戶端而言，就必須讓所有同時寫入的客戶端按同一種流水線方式去寫入，才可能保證寫入順序一致。 
這個寫入流程我們下一節詳細分析。

寫入流程

GFS 使用租約機制來保障在跨多個副本的資料寫入中保持順序一致性。 
GFS Master 將 chunk 租約發放給其中一個副本，這個副本我們就稱為主副本，其他副本稱為次副本。 
由主副本來確定一個針對該 chunk 的寫入順序，次副本則遵守這個順序，這樣就保障了全域性順序一致性。 
chunk 租約機制的設計主要是為了減輕 Master 的負擔，由主副本所在的 chunkserver 來承擔流水線順序的安排。 
如下圖，我們詳細描述下這個過程。 

1. 客戶端請求 Master 詢問哪個 chunkserver 持有租約以及其他副本的位置。 
   如果沒有 chunkserver 持有租約，說明該 chunk 最近沒有寫操作。 
   Master 則選擇將租約授權給其中一臺 chunkserver。
2. Master 返回客戶端主副本和次副本的位置資訊。 
   客戶端快取這些資訊以備將來使用。 
   客戶端以後不再需要聯絡 Master，除非主副本所在 chunkserver 不可用或返回租約過期了。
3. 客戶端選擇最優的網路順序推送資料，chunkserver 將資料先快取在內部的 LRU 快取中。 
   GFS 中採用資料流和控制流分離的方法，從而能夠基於網路拓撲結構更好地排程資料流的傳輸。
4. 一旦所有的副本確認收到了資料，客戶端將傳送一個寫請求控制命令到主副本。 
   由主副本分配連續的序列號來確定最終的寫入順序。
5. 主副本轉發寫請求到所有次副本，次副本按主副本安排的順序執行寫入操作。
6. 次副本寫完後向主副本應答確認操作完成。
7. 最後主副本應答客戶端，若任意副本寫入過程中出現錯誤，將報告給客戶端，由客戶端發起重試。

GFS 和 HDFS 的寫入流程都採用了流水線方式，但 HDFS 沒有分離資料流和控制流。 
HDFS 的資料流水線寫入在網路上的傳輸順序與最終寫入檔案的順序一致。 
而 GFS 資料在網路上的傳輸順序與最終寫入檔案的順序可能不一致。 
GFS 在支援併發寫入和優化網路資料傳輸方面做出了最佳的折衷。

總結

GFS 的論文發表於 2003 年，後來大部分的分散式檔案系統設計實現或多或少都參考了 GFS 的設計思路。 
而 HDFS 算是開源分散式檔案系統中最完整實現了 GFS 論文中的概念模型。 
但 HDFS 依然簡化了 GFS 中關於併發寫的思路，本文就兩者的寫入模型和過程做了一些對比說明，並希望引發一些思考。

參考

GFS：Google File System
HDFS：Hadoop Distribute File System
 
首先，有一點要確認的是，作為GFS的一個最重要的實現，HDFS設計目標和GFS是高度一致的。在架構、塊大小、元資料等的實現上，HDFS與GFS大致一致。但是，在某些地方，HDFS與GFS又有些不同。如：

1、	快照（Snapshot）：
	GFS中的快照功能是非常強大的，可以非常快的對檔案或者目錄進行拷貝，並且不影響當前操作（讀/寫/複製）。GFS中生成快照的方式叫copy-on-write。也就是說，檔案的備份在某些時候只是將快照檔案指向原chunk，增加對chunk的引用計數而已，等到chunk上進行了寫操作時，Chunk Server才會拷貝chunk塊，後續的修改操作落到新生成的chunk上。
	而HDFS暫時並不支援快照功能，而是運用最基礎的複製來完成。想象一下，當HBase上的資料在進行重新劃分時（過程類似於hash平衡），HDFS需要對其中的所有資料（P/T級的）進行復制遷移，而GFS只需要快照，多不方便！

2、	記錄追加操作（append）：
 
	在資料一致性方面，GFS在理論上相對HDFS更加完善。
 
	a)	GFS提供了一個相對寬鬆的一致性模型。GFS同時支援寫和記錄追加操作。寫操作使得我們可以隨機寫檔案。記錄追加操作使得並行操作更加安全可靠。
 
	b)	HDFS對於寫操作的資料流和GFS的功能一樣。但是，HDFS並不支援記錄追加和並行寫操作。NameNode用INodeFileUnderConstruction屬性標記正在進行操作的檔案塊，而不關注是讀還是寫。DataNode甚至看不到租約！一個檔案一旦建立、寫入、關閉之後就不需要修改了。這樣的簡單模型適合於Map/Reduce程式設計。

3、	垃圾回收（GC）：
 
	a)	GFS垃圾回收採用惰性回收策略，即master並不會立即回收程式所刪除的檔案資源。 GFS選擇以一種特定的形式標記刪除檔案（通常是將檔名改為一個包含時間資訊的隱藏名字），這樣的檔案不再被普通使用者所訪問。Master會定期對檔案的名稱空間進行檢查，並刪除一段時間前的隱藏檔案（預設3天）。
 
	b)	HDFS並沒有採用這樣的垃圾回收機制，而是採取了一種更加簡單但是更容易實現的直接刪除方式。
 
	c)	應該說延遲迴收和直接刪除各有優勢。延遲迴收為那些“不小心“的刪除操作留了後路。同時，回收資源的具體操作時在Master結點空閒時候完成，對GFS的效能有很好的提高。但是延遲迴收會佔用很大的儲存空間，假如某些可惡的使用者無聊了一直建立刪除檔案怎麼辦？

試分析下這種不同。有人說，GFS在功能上非常完善，非常強大，而HDFS在策略上較之簡單些，主要是為了有利於實現。但實際上，GFS作為儲存平臺早已經被廣泛的部署在Google內部，儲存Google服務產生或者要處理的資料，同時用於大規模資料集的研究與開發工作。因此GFS並不僅僅是理論上的研究，而是具體實現。作為GFS的後輩與開源實現，HDFS在技術上應該是更加成熟的，不可能為了“偷懶”而簡化功能。因此，簡化說應該是不成立的。

	個人認為，GFS與HDFS的不同是由於“專”與“通”的區別。眾所周知，Hadoop是一個開源軟體/框架，在設計之初就考慮到了使用者（面向世界上的所有個人、企業）在需求上的差異，比如資料密集型（如淘寶的資料儲存）、計算密集型（百度的PR演算法）、混合型等等。而GFS在設計之初就對目標比較明確，都是Google的嘛，因此GFS可以對其主要功能進行效能上的優化。