首先我們應該更具體的理解這樣一個現象仁卷，為什么流行的技術框架會被淘汰。談到淘汰邀窃，常見兩種情況：
第一：應用模式被淘汰了荸哟，例如：BB機，功能機瞬捕，最終被智能機淘汰鞍历，膠卷被數碼相機淘汰，即便諾基亞的功能機做得再完美肪虎，也會被淘汰堰燎。軟件方面例如：終端的字處理，郵件收發(fā)等應用軟件被視窗應用軟件淘汰笋轨。
第二：技術升級，新技術彌補了老技術的缺陷赊淑，并且引入了更多有優(yōu)勢的功能爵政。例如：Springframework的橫空出世，配合Hibernate陶缺，在具有同樣功效的情況下钾挟，解決了EJB的部署復雜，體態(tài)臃腫饱岸，計算效率低掺出，用靈活性，面向程序員的友好性苫费，淘汰了曾經企業(yè)級經典的EJB汤锨。
那么對于Hadoop分布式文件系統(tǒng)（HDFS），我們要討論它的淘汰可能性百框，淘汰時間闲礼，首先我們就要看它為什么要被淘汰的因素。從模式上，分布式文件系統(tǒng)是大數據存儲技術極為重要的一個領域柬泽，我們還看不到分布式文件系統(tǒng)有被淘汰的任何理由慎菲，那么我就再看技術升級是否有淘汰它的可能性。
談技術升級锨并，首先要看HDFS的缺點露该，然后再看這種缺點的解決辦法，是否會帶來新的技術框架第煮，然后讓HDFS埋進歷史的垃圾堆解幼。
01?部署復雜
HDFS為集中式協(xié)調架構，namenode若是單節(jié)點空盼，部署并不復雜书幕，但是namenode作為單節(jié)點無法可靠的運行在生產環(huán)境，必須對namenode實現雙機HA揽趾，那么部署復雜度就變得極高台汇，這時候需要在namenode，datanode的基礎上再引入namenode active篱瞎，namenode standby的概念苟呐，需要引入QJM的元數據共享存儲并基于Paxos做一致性協(xié)調，另外需要引入ZKFC和ZooKeeper俐筋，解決主備選舉牵素，健康探測，主備切換等操作澄者。
因此HDFS的部署復雜度完全是因為namenode HA導致的笆呆。這是集中式管理的分布式架構一個原生問題，如果在這個地方進行優(yōu)化的話粱挡，那么就是簡化QJM赠幕，ZKFC，ZooKeeper的多組服務询筏，用一組服務來代替榕堰，但是namenode和datanode的分布式數據塊的讀寫，復制嫌套，恢復機制逆屡，目前看非常成熟，高效踱讨，這是核心問題魏蔗，并不是缺點，不需要更具顛覆性的優(yōu)化痹筛。
02?元數據的內存瓶頸
由于namenode在內存中記錄了所有數據塊（block 默認128M）的信息沫勿，索引了數據塊與datanode的關系挨约，并且構建了文件系統(tǒng)樹，因此可想而知namenode的元數據內存區(qū)是大量占用內存产雹，這是沒有上限的诫惭。對于較大型數據存儲項目，例如上百個datanode節(jié)點和上千萬個數據塊的容量來說蔓挖，元數據在namenode的內存大概能控制在32G以內夕土，這是還沒問題的，但是對于構建海量數據中心的超大型項目瘟判，這個問題就好像達摩克斯之劍怨绣，首先堆內存超過臨界范圍導致的內存尋址性能問題不說，一旦namenode內存超限到單機內存可承載的物理上最大承受范圍拷获，整個hdfs數據平臺將面臨停止服務篮撑。
這個問題的本質還是Google設計GFS時候采用粗放的實用主義，先把元數據都交給主節(jié)點在內存中節(jié)制匆瓜，超大問題以后再解決赢笨。目前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的元數據瓶頸問題將被徹底解決圾笨，很難看到比這更具優(yōu)勢的替代性技術框架了教馆。
如下圖所示：
03?默認副本數占用空間
副本數默認為3最大的問題就是占空間，這幾乎是所有傳統(tǒng)分布式文件系統(tǒng)（DFS）的通病擂达。因此HDFS集群的默認空間利用率只有33.3%土铺，這么低的利用率顯然不符合一些場景，例如長期的冷數據備份，那么有沒有更好的方式呢悲敷？是有的究恤，目前比較成熟的方案就是糾刪碼技術，類似raid5后德，raid6部宿，HDFS 3.0版本以后支持這種模式，叫做Erasure Coding(EC)方案瓢湃。
HDFS是怎么通過EC方案解決磁盤利用率的問題呢理张？我們先聊點比較硬的原理，說說EC方案之一的條形布局：
首先數據文件寫的時候會向N個節(jié)點的塊(Block)依次寫入绵患，N個Block會被切成多組條(stripe?1... stripe n)雾叭，如果分布式環(huán)境有五個存儲節(jié)點(DataNode)，那么就把stripe切成3個單元(cell)落蝙，然后再根據這3個cell計算出2個校驗cell织狐，然后這5個cell（3個data+2個parity）分別寫入5個Block中。數據條就這么依次輪巡的方式掘殴，將校驗塊的位置輪換存儲在不同Block上赚瘦，直至寫滿，這樣校驗塊的分布可以更均勻奏寨。
其次再說取數據起意，取數據每次只從3個DataNode中各取出1個cell，如果這3個cell都是數據cell病瞳，那么就成功拿到一組數據條stripe揽咕，如果有一個cell是校驗cell，那么就能通過校驗cell和另外2個數據cell計算出第3個數據cell套菜，完成數據條stripe的組合亲善。這種情況下，即便是5個datanode節(jié)點有2個datanode宕機了逗柴，另外3個datanode也能通過校驗碼計算完成剩余2個節(jié)點的數據蛹头，這就是利用糾刪碼技術實現數據冗余的原理。
通過這種方式戏溺，我們就比傳統(tǒng)2副本50%渣蜗，3副本33.3%的多副本模式要省空間，EC中2+1可以達到66.7%的磁盤利用率旷祸，例子是3+2可以達到60%的磁盤利用率
但是其問題是特別消耗CPU計算耕拷，上面那種讀取情況，五分之三的讀取數據條時間都要進行校驗碼計算托享。因此可以利用Intel CPU推出的ISA-L底層函數庫專門用于提升校糾刪碼算法的編解碼性能骚烧。通常情況下浸赫，糾刪碼用于冷數據的冗余，也就是不經常訪問赃绊，但又必須聯(lián)機存儲以備查詢的數據既峡。除了磁盤利用率，多副本方式用空間換效率的方式肯定是最好凭戴，沒什么問題涧狮。
