Hadoop分散式檔案系統（HDFS）會不會被淘汰？

第一：應用模式被淘汰了，例如：BB機，功能機，最終被智慧機淘汰，膠捲被數位相機淘汰，即便諾基亞的功能機做得再完美，也會被淘汰。軟體方面例如：終端的字處理，郵件收發等應用軟體被視窗應用軟體淘汰。

第二：技術升級，新技術彌補了老技術的缺陷，並且引入了更多有優勢的功能。例如：Springframework的橫空出世，配合Hibernate，在具有同樣功效的情況下，解決了EJB的部署複雜，體態臃腫，計算效率低，用靈活性，面向程式設計師的友好性，淘汰了曾經企業級經典的EJB。

那麼對於Hadoop分散式檔案系統（HDFS），我們要討論它的淘汰可能性，淘汰時間，首先我們就要看它為什麼要被淘汰的因素。從模式上，分散式檔案系統是大資料儲存技術極為重要的一個領域，我們還看不到分散式檔案系統有被淘汰的任何理由，那麼我就再看技術升級是否有淘汰它的可能性。

談技術升級，首先要看HDFS的缺點，然後再看這種缺點的解決辦法，是否會帶來新的技術框架，然後讓HDFS埋進歷史的垃圾堆。

HDFS的缺點，我們在研究和使用過程中，主要發現有三個問題：

• 部署複雜

• 後設資料的記憶體瓶頸

• 預設副本數佔用儲存空間

HDFS為集中式協調架構，namenode若是單節點，部署並不複雜，但是namenode作為單節點無法可靠的執行在生產環境，必須對namenode實現雙機HA，那麼部署複雜度就變得極高，這時候需要在namenode，datanode的基礎上再引入namenode active，namenode standby的概念，需要引入QJM的後設資料共享儲存並基於Paxos做一致性協調，另外需要引入ZKFC和ZooKeeper，解決主備選舉，健康探測，主備切換等操作。

複雜的HDFS HA架構

因此HDFS的部署複雜度完全是因為namenode HA導致的。這是集中式管理的分散式架構一個原生問題，如果在這個地方進行最佳化的話，那麼就是簡化QJM，ZKFC，ZooKeeper的多組服務，用一組服務來代替，但是namenode和datanode的分散式資料塊的讀寫，複製，恢復機制，目前看非常成熟，高效，這是核心問題，並不是缺點，不需要更具顛覆性的最佳化。

由於namenode在記憶體中記錄了所有資料塊（block 預設128M）的資訊，索引了資料塊與datanode的關係，並且構建了檔案系統樹，因此可想而知namenode的後設資料記憶體區是大量佔用記憶體，這是沒有上限的。對於較大型資料儲存專案，例如上百個datanode節點和上千萬個資料塊的容量來說，後設資料在namenode的記憶體大概能控制在32G以內，這是還沒問題的，但是對於構建海量資料中心的超大型專案，這個問題就好像達摩克斯之劍，首先堆記憶體超過臨界範圍導致的記憶體定址效能問題不說，一旦namenode記憶體超限到單機記憶體可承載的物理上最大承受範圍，整個hdfs資料平臺將面臨停止服務。

這個問題的本質還是Google設計GFS時候採用粗放的實用主義，先把後設資料都交給主節點在記憶體中節制，超大問題以後再解決。目前Google的GFS2設計上，已經將後設資料在記憶體中遷移至了BigTable上，那麼問題就來了：“BigTable基於GFS，而GFS2的後設資料基於BigTable”？有點雞生蛋還是蛋生雞的自相矛盾。是的，看似矛盾實質上是架構的巢狀複用，可以這麼去解讀：GFS2是基於<基於GFS的BigTable的後設資料儲存>的下一代GFS架構。用BigTable的k-v儲存模型放GFS2的後設資料，雖然沒有記憶體高效，但是夠用，而且可以無限儲存，用BigTable專門儲存後設資料形成的k-v記錄最終儲存成GFS資料塊，因此在GFS的後設資料記憶體中只需少量的記憶體佔用，就能支撐天量的真正應用於資料塊儲存的GFS2後設資料。

基於GFS2的設計思想，我相信下一代HDFS應該也是這樣的方案去解決後設資料的記憶體瓶頸問題，也就是基於<基於HDFS的HBase的後設資料儲存>的下一代HDFS架構。那麼HDFS的後設資料瓶頸問題將被徹底解決，很難看到比這更具優勢的替代性技術框架了。

如下圖所示：

GFS V2假想圖

副本數預設為3最大的問題就是佔空間，這幾乎是所有傳統分散式檔案系統（DFS）的通病。因此HDFS叢集的預設空間利用率只有33.3%，這麼低的利用率顯然不符合一些場景，例如長期的冷資料備份，那麼有沒有更好的方式呢？是有的，目前比較成熟的方案就是糾刪碼技術，類似raid5，raid6，HDFS 3.0版本以後支援這種模式，叫做Erasure Coding(EC)方案。

HDFS是怎麼透過EC方案解決磁碟利用率的問題呢？我們先聊點比較硬的原理，說說EC方案之一的條形佈局：

首先資料檔案寫的時候會向N個節點的塊(Block)依次寫入，N個Block會被切成多組條(stripe 1... stripe n)，如果分散式環境有五個儲存節點(DataNode)，那麼就把stripe切成3個單元(cell)，然後再根據這3個cell計算出2個校驗cell，然後這5個cell（3個data+2個parity）分別寫入5個Block中。資料條就這麼依次輪巡的方式，將校驗塊的位置輪換儲存在不同Block上，直至寫滿，這樣校驗塊的分佈可以更均勻。

HDFS EC Striping Layout

其次再說取資料，取資料每次只從3個DataNode中各取出1個cell，如果這3個cell都是資料cell，那麼就成功拿到一組資料條stripe，如果有一個cell是校驗cell，那麼就能透過校驗cell和另外2個資料cell計算出第3個資料cell，完成資料條stripe的組合。這種情況下，即便是5個datanode節點有2個datanode當機了，另外3個datanode也能透過校驗碼計算完成剩餘2個節點的資料，這就是利用糾刪碼技術實現資料冗餘的原理。

透過這種方式，我們就比傳統2副本50%，3副本33.3%的多副本模式要省空間，EC中2+1可以達到66.7%的磁碟利用率，例子是3+2可以達到60%的磁碟利用率

但是其問題是特別消耗CPU計算，上面那種讀取情況，五分之三的讀取資料條時間都要進行校驗碼計算。因此可以利用Intel CPU推出的ISA-L底層函式庫專門用於提升校糾刪碼演算法的編解碼效能。通常情況下，糾刪碼用於冷資料的冗餘，也就是不經常訪問，但又必須聯機儲存以備查詢的資料。除了磁碟利用率，多副本方式用空間換效率的方式肯定是最好，沒什麼問題。