自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

為何HDFS是大數(shù)據(jù)分析的軟肋

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

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

 

 

 

[[184262]]

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

HDFS存在的缺陷

HDFS中的文件分配表的核心是NameNode。客戶端主要通過(guò)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ù),也就是說(shuō),對(duì)HDFS來(lái)說(shuō),請(qǐng)求讀取整個(gè)數(shù)據(jù)集要比讀取一條記錄更加高效。所以HDFS在語(yǔ)言選擇方面更偏向于基礎(chǔ)語(yǔ)言,而不是高級(jí)語(yǔ)言。

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

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

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

Spark和云計(jì)算需求的變化

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

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

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

除了上述的分布式文件系統(tǒng),還有很多的分布式文件系統(tǒng)可以供選擇,例如Ceph、Gluster。Gluster是一種更為標(biāo)準(zhǔn)的分布式文件系統(tǒng),擅長(zhǎng)I/O操作。目前,大多數(shù)人選擇使用Spark來(lái)存儲(chǔ)文件是因?yàn)樗麄儗?duì)于Spark更加熟悉,而并非是因?yàn)樗阅芎?、速度快?/p>

大型HDFS安裝的遷移是不可能一蹴而就的,但是隨著時(shí)間的遷移,未來(lái)我們?cè)赟park和云項(xiàng)目中會(huì)越來(lái)越少的看到HDFS。也許,HDFS會(huì)脫離YARN,單獨(dú)成為Hadoop的一部分。

責(zé)任編輯:張燕妮 來(lái)源: it168網(wǎng)站
相關(guān)推薦

2015-03-04 11:01:36

大數(shù)據(jù)數(shù)據(jù)分析分析

2015-09-01 11:31:50

數(shù)據(jù)英雄

2015-07-29 16:19:54

大數(shù)據(jù)時(shí)代分析

2021-06-15 14:07:42

Google BigQ大數(shù)據(jù)大數(shù)據(jù)分析

2015-08-14 10:28:09

大數(shù)據(jù)

2015-07-29 11:27:28

大數(shù)據(jù)時(shí)代數(shù)據(jù)分析統(tǒng)計(jì)學(xué)

2022-04-06 15:59:11

大數(shù)據(jù)HDFS存儲(chǔ)系統(tǒng)

2021-08-06 11:01:23

大數(shù)據(jù)數(shù)據(jù)分析技術(shù)

2017-07-22 00:41:27

大數(shù)據(jù)數(shù)據(jù)存儲(chǔ)

2019-07-31 14:16:35

大數(shù)據(jù)人工智能算法

2015-08-11 15:52:52

大數(shù)據(jù)數(shù)據(jù)分析

2021-10-12 15:25:08

大數(shù)據(jù)數(shù)據(jù)分析

2022-03-29 14:49:14

大數(shù)據(jù)數(shù)據(jù)分析

2013-04-09 09:28:20

大數(shù)據(jù)大數(shù)據(jù)全球技術(shù)峰會(huì)

2015-07-23 09:34:57

大數(shù)據(jù)數(shù)據(jù)分析

2012-12-11 10:39:08

2012-08-21 16:32:41

IBM大數(shù)據(jù)數(shù)據(jù)分析

2023-12-22 15:49:02

大數(shù)據(jù)科學(xué)家Python數(shù)據(jù)分析師

2024-03-04 11:10:01

2021-01-27 09:18:50

大數(shù)據(jù)數(shù)據(jù)收集大數(shù)據(jù)分析
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)