為何HDFS是大數據分析的軟肋

分散式文件系統是大型分析非常重要的一環。即使你是在使用Spark，你仍然需要將大量的數據快速的存入內存，所以文件系統一定要可以是高速率的。但是，HDFS並不像它標榜的那樣好，它是大數據分析的薄弱環節。

什麼是分散式文件系統?普通的文件系統是基於塊來存儲文件的。查找文件時，要去磁碟中匹配每一個塊。一般是有文件分配表或多種FAT的。但是，分散式文件系統的物理存儲資源是不一定直接連接在本地節點上的，而是通過計算機網路與節點相連。另外，像RAID或SAN系統，塊是會複製的，因此，網路節點丟失並不會造成數據丟失。

HDFS存在的缺陷

HDFS中的文件分配表的核心是NameNode。客戶端主要通過NameNode執行數據操作，DataNode會與其他DataNode進行通信並複製數據塊以實現冗餘，這樣單一的DataNode損壞不會導致集群的數據丟失。但是NameNode一旦發生故障，後果會非常嚴重。雖然NameNode可以故障轉移，但是需要花費大量的時間。這也意味著序列中會有更多的等待時間。HDFS的垃圾回收，尤其是Java垃圾回收是需要佔用大量的內存，一般是本機有效內存的10倍。

因為HDFS的設計更多的是建立在響應"一次寫入、多次讀寫"任務的基礎上。在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。所以HDFS在語言選擇方面更偏向於基礎語言，而不是高級語言。

傳統的操作可以用更短的時間來開發部署，維護成本更低、安全性更好。業內有這樣一種說法，大多數操作系統支持C語言、彙編和Java的原因是，文件系統處於一個較低的水平。

HDFS的工具和其他文件系統的工具相較是有差距的。比起你曾經處理的任何文件系統或分散式存儲HDFS周圍的工具是一種較差。基於Java的文件系統只能搭上IT人員最喜愛的POSIX工具的末班車。你嘗試過NFS掛載HDFS嗎?其它的HDFS工具的安裝也是非常複雜的。相反的，如果你使用REST bridge Tool和客戶端命令行就會非常容易。

HDFS支持原生代碼擴展，提高了運行效率。另外，社區也為NameNode的發展做出了很多貢獻。如果你想要打造一個高端的系統，那麼必須打破監測和診斷工具中的NameNode瓶頸。總之，在操作系統上使用基於C或C ++的較為成熟的分散式文件系統往往是一個更好的選擇。

Spark和雲計算需求的變化

早期的Hadoop企業部署基本上是在本地完成的，隨著Spark和雲部署的崛起，使用Amazon S3作為數據源的情況漸漸多了起來。

Hadoop供應商都期望能夠出現更為統一的Hadoop平台，期望HDFS能夠與安全組件集成。Spark本身就因文件系統的多樣性而存在很多矛盾，所以，想要和文件系統緊密集成幾乎是不可能的。

MAPR FS文件系統漸漸引起了企業的興趣。MAPR FS沒有NameNode，而是採用了更標準和熟悉的集群方案方案。 MAPR的分區設計也很好的避免了瓶頸。

除了上述的分散式文件系統，還有很多的分散式文件系統可以供選擇，例如Ceph、Gluster。Gluster是一種更為標準的分散式文件系統，擅長I/O操作。目前，大多數人選擇使用Spark來存儲文件是因為他們對於Spark更加熟悉，而並非是因為它性能好、速度快。

大型HDFS安裝的遷移是不可能一蹴而就的，但是隨著時間的遷移，未來我們在Spark和雲項目中會越來越少的看到HDFS。也許，HDFS會脫離YARN，單獨成為Hadoop的一部分。