如今,分布式文件系統是大型分析非常重要的一環,即使在使用Spark仍然需要將大量的數據快速存入內存,所以文件系統一定是高速率的。但其實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 ++的較為成熟的分布式文件系統往往是更好的選擇。
早期的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的一部分。