分布式文件系統(tǒng)是大型分析非常重要的一環(huán)。即使你是在使用Spark，你仍然需要將大量的數(shù)據(jù)快速的存入內(nèi)存，所以文件系統(tǒng)一定要可以是高速率的。但是，HDFS并不像它標(biāo)榜的那樣好，它是大數(shù)據(jù)分析的薄弱環(huán)節(jié)。

[[184262]]

什么是分布式文件系統(tǒng)?普通的文件系統(tǒng)是基于塊來存儲文件的。查找文件時，要去磁盤中匹配每一個塊。一般是有文件分配表或多種FAT的。但是，分布式文件系統(tǒng)的物理存儲資源是不一定直接連接在本地節(jié)點(diǎn)上的，而是通過計算機(jī)網(wǎng)絡(luò)與節(jié)點(diǎn)相連。另外，像RAID或SAN系統(tǒng)，塊是會復(fù)制的，因此，網(wǎng)絡(luò)節(jié)點(diǎn)丟失并不會造成數(shù)據(jù)丟失。

HDFS存在的缺陷

HDFS中的文件分配表的核心是NameNode?？蛻舳酥饕ㄟ^NameNode執(zhí)行數(shù)據(jù)操作，DataNode會與其他DataNode進(jìn)行通信并復(fù)制數(shù)據(jù)塊以實(shí)現(xiàn)冗余，這樣單一的DataNode損壞不會導(dǎo)致集群的數(shù)據(jù)丟失。但是NameNode一旦發(fā)生故障，后果會非常嚴(yán)重。雖然NameNode可以故障轉(zhuǎn)移，但是需要花費(fèi)大量的時間。這也意味著序列中會有更多的等待時間。HDFS的垃圾回收，尤其是Java垃圾回收是需要占用大量的內(nèi)存，一般是本機(jī)有效內(nèi)存的10倍。

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

傳統(tǒng)的操作可以用更短的時間來開發(fā)部署，維護(hù)成本更低、安全性更好。業(yè)內(nèi)有這樣一種說法，大多數(shù)操作系統(tǒng)支持C語言、匯編和Java的原因是，文件系統(tǒng)處于一個較低的水平。

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

HDFS支持原生代碼擴(kuò)展，提高了運(yùn)行效率。另外，社區(qū)也為NameNode的發(fā)展做出了很多貢獻(xiàn)。如果你想要打造一個高端的系統(tǒng)，那么必須打破監(jiān)測和診斷工具中的NameNode瓶頸?？傊?，在操作系統(tǒng)上使用基于C或C ++的較為成熟的分布式文件系統(tǒng)往往是一個更好的選擇。

Spark和云計算需求的變化

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

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

MAPR FS文件系統(tǒng)漸漸引起了企業(yè)的興趣。MAPR FS沒有NameNode，而是采用了更標(biāo)準(zhǔn)和熟悉的集群方案方案。 MAPR的分區(qū)設(shè)計也很好的避免了瓶頸。

除了上述的分布式文件系統(tǒng)，還有很多的分布式文件系統(tǒng)可以供選擇，例如Ceph、Gluster。Gluster是一種更為標(biāo)準(zhǔn)的分布式文件系統(tǒng)，擅長I/O操作。目前，大多數(shù)人選擇使用Spark來存儲文件是因為他們對于Spark更加熟悉，而并非是因為它性能好、速度快。

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