HDFS存在的缺陷
HDFS中的文件分配表的核心是NameNode??蛻舳酥饕ㄟ^NameNode執(zhí)行數(shù)據(jù)操作,DataNode會(huì)與其他DataNode進(jìn)行通信并復(fù)制數(shù)據(jù)塊以實(shí)現(xiàn)冗余,這樣單一的DataNode損壞不會(huì)導(dǎo)致集群的數(shù)據(jù)丟失。但是NameNode一旦發(fā)生故障,后果會(huì)非常嚴(yán)重。雖然NameNode可以故障轉(zhuǎn)移,但是需要花費(fèi)大量的時(shí)間。這也意味著序列中會(huì)有更多的等待時(shí)間。HDFS的垃圾回收,尤其是Java垃圾回收是需要占用大量的內(nèi)存,一般是本機(jī)有效內(nèi)存的10倍。
因?yàn)镠DFS的設(shè)計(jì)更多的是建立在響應(yīng)"一次寫入、多次讀寫"任務(wù)的基礎(chǔ)上。在多數(shù)情況下,分析任務(wù)都會(huì)涉及數(shù)據(jù)集中的大部分?jǐn)?shù)據(jù),也就是說,對(duì)HDFS來說,請(qǐng)求讀取整個(gè)數(shù)據(jù)集要比讀取一條記錄更加。所以HDFS在語言選擇方面更偏向于基礎(chǔ)語言,而不是語言。
傳統(tǒng)的操作可以用更短的時(shí)間來開發(fā)部署,維護(hù)成本更低、安全性更好。業(yè)內(nèi)有這樣一種說法,大多數(shù)操作系統(tǒng)支持C語言、匯編和Java的原因是,文件系統(tǒng)處于一個(gè)較低的水平。
HDFS的工具和其他文件系統(tǒng)的工具相較是有差距的。比起你曾經(jīng)處理的任何文件系統(tǒng)或分布式存儲(chǔ)HDFS周圍的工具是一種較差?;贘ava的文件系統(tǒng)只能搭上IT人員喜愛的POSIX工具的末班車。你嘗試過NFS掛載HDFS嗎?其它的HDFS工具的安裝也是非常復(fù)雜的。相反的,如果你使用RESTbridgeTool和客戶端命令行就會(huì)非常容易。
HDFS支持原生代碼擴(kuò)展,提高了運(yùn)行效率。另外,社區(qū)也為NameNode的發(fā)展做出了很多貢獻(xiàn)。如果你想要打造一個(gè)的系統(tǒng),那么必須打破監(jiān)測(cè)和診斷工具中的NameNode瓶頸??傊诓僮飨到y(tǒng)上使用基于C或C 的較為成熟的分布式文件系統(tǒng)往往是一個(gè)更好的選擇。
Spark和云計(jì)算需求的變化
早期的Hadoop企業(yè)部署基本上是在本地完成的,隨著Spark和云部署的崛起,使用AmazonS3作為數(shù)據(jù)源的情況漸漸多了起來。
Hadoop供應(yīng)商都期望能夠出現(xiàn)更為統(tǒng)一的Hadoop平臺(tái),期望HDFS能夠與安全組件集成。Spark本身就因文件系統(tǒng)的多樣性而存在很多矛盾,所以,想要和文件系統(tǒng)緊密集成幾乎是不可能的。
MAPRFS文件系統(tǒng)漸漸引起了企業(yè)的興趣。MAPRFS沒有NameNode,而是采用了更標(biāo)準(zhǔn)和熟悉的集群方案方案。MAPR的分區(qū)設(shè)計(jì)也很好的避免了瓶頸。
除了上述的分布式文件系統(tǒng),還有很多的分布式文件系統(tǒng)可以供選擇,例如Ceph、Gluster。Gluster是一種更為標(biāo)準(zhǔn)的分布式文件系統(tǒng),擅長I/O操作。目前,大多數(shù)人選擇使用Spark來存儲(chǔ)文件是因?yàn)樗麄儗?duì)于Spark更加熟悉,而并非是因?yàn)樗阅芎?、速度快?br />
大型HDFS安裝的遷移是不可能一蹴而就的,但是隨著時(shí)間的遷移,未來我們?cè)赟park和云項(xiàng)目中會(huì)越來越少的看到HDFS。也許,HDFS會(huì)脫離YARN,單獨(dú)成為Hadoop的一部分。