Google 為了應(yīng)對(duì)快速增長(zhǎng)的數(shù)據(jù)處理,開(kāi)發(fā)了一套算法。后來(lái)有人根據(jù)算法的思想,開(kāi)發(fā)出開(kāi)源的軟件框架 ,就是Hadoop, 隨著越來(lái)越多的組織和個(gè)人開(kāi)發(fā)者在框架開(kāi)發(fā)中不斷貢獻(xiàn)改進(jìn),Hadoop 已經(jīng)形成一套家族產(chǎn)品,成為當(dāng)下最成功最流行的分布式大數(shù)據(jù)處理框架。
Hadoop 受到很多組織青睞,是因?yàn)橛袃纱笠蛩兀?/p>
一、超大規(guī)模的數(shù)據(jù)處理, 通常 10TB 以上;
二、超復(fù)雜的計(jì)算工作,例如統(tǒng)計(jì)和模擬。
Hadoop 在很多應(yīng)用場(chǎng)景中發(fā)揮著主要功用,如大規(guī)模統(tǒng)計(jì)、ETL數(shù)據(jù)挖掘、大數(shù)據(jù)智能分析、機(jī)器學(xué)習(xí)等。
Hadoop 和 傳統(tǒng)SQL關(guān)系數(shù)據(jù)存儲(chǔ) 有什么區(qū)別?
Hadoop 讀時(shí)模式(Schema on read),傳統(tǒng)SQL是 寫(xiě)時(shí)模式(Schema on write).傳統(tǒng)數(shù)據(jù)庫(kù)存儲(chǔ)時(shí)對(duì)數(shù)據(jù)進(jìn)行檢查,需要檢查表結(jié)構(gòu)定義等必須匹配后才讓存儲(chǔ)(write),否則就報(bào)錯(cuò)。Hadoop 是你拿過(guò)任何數(shù)據(jù)格式我都給你存儲(chǔ),只要你給我讀取這些數(shù)據(jù)的接口程序,在用到這些數(shù)據(jù)時(shí)(read),才會(huì)檢查。
左邊是Schema on Read ,右邊是Schema on Write。 右邊數(shù)據(jù)格式不對(duì)會(huì)報(bào)錯(cuò),左邊更關(guān)注讀數(shù)據(jù)的規(guī)則。Hadoop 是分布式數(shù)據(jù)庫(kù), 而大部分SQL是集中存儲(chǔ)的。
舉例來(lái)講: 微信后臺(tái)有可能數(shù)千個(gè)服務(wù)器節(jié)點(diǎn)用于存儲(chǔ)微信聊天記錄,假設(shè)我的聊天記錄分布在60個(gè)不同的服務(wù)節(jié)點(diǎn)上。而對(duì)于關(guān)系數(shù)據(jù)庫(kù),會(huì)集中在多個(gè)表空間中。
假如我搜索我的一個(gè)聊天記錄,Hadoop 會(huì)把搜索任務(wù)分成多個(gè)均衡負(fù)載的搜索任務(wù)運(yùn)行在60個(gè)節(jié)點(diǎn)上。而傳統(tǒng)SQL會(huì)逐個(gè)搜索存儲(chǔ)空間,直到全部遍歷。如果沒(méi)有完全搜索完,會(huì)返回搜索結(jié)果嗎? Hadoop的回答是YES,而傳統(tǒng)SQL會(huì)是NO。
Hadoop 家族的產(chǎn)品 Hive,可以讓不怎么懂SQL 的客戶開(kāi)發(fā)出基本上和SQL同樣功能的查詢
Hadoop 的數(shù)據(jù)寫(xiě)入、備份、刪除操作
一、數(shù)據(jù)寫(xiě)入
在客戶端想HDFS寫(xiě)數(shù)據(jù)的過(guò)程中,主要分為下面幾個(gè)過(guò)程:
客戶端將數(shù)據(jù)緩存到本地的一個(gè)臨時(shí)文件中;
當(dāng)這個(gè)本地的臨時(shí)文件到達(dá)HDFS中的塊大小限制時(shí),客戶端訪問(wèn)Namenode,Namenode將文件的名字插入到HDFS命名空間中,并且為其分配相應(yīng)的存儲(chǔ)位置;
Namenode與分配好的Datanode進(jìn)行溝通,確定存儲(chǔ)位置可用,然后將這些存儲(chǔ)位置信息返回給客戶端;
客戶端將本地的臨時(shí)文件傳輸?shù)紻atanode中;
當(dāng)寫(xiě)文件結(jié)束,臨時(shí)文件關(guān)閉時(shí),會(huì)將已有的臨時(shí)數(shù)據(jù)傳輸?shù)紻atanode中,并告知Namenode寫(xiě)數(shù)據(jù)完成;
Namenode將該文件改變?yōu)槌志玫囊恢滦誀顟B(tài),也就事將該操作記錄到日志EditLog中。如果此時(shí)Namenode宕掉,那么文件信息丟失。
上面的過(guò)程主要特點(diǎn)是寫(xiě)入數(shù)據(jù)先緩存到本地,在達(dá)到塊大小限制時(shí)才與Datanode通信進(jìn)行傳輸。這樣的好處在于避免在客戶寫(xiě)數(shù)據(jù)的過(guò)程中持續(xù)占用網(wǎng)絡(luò)帶寬,這對(duì)于處理多用戶大量數(shù)據(jù)的寫(xiě)入是非常關(guān)鍵的。
二、數(shù)據(jù)備份
數(shù)據(jù)的寫(xiě)入同時(shí)伴隨這數(shù)據(jù)塊的備份,過(guò)程如下:
在客戶端臨時(shí)數(shù)據(jù)達(dá)到一個(gè)塊時(shí),與Namenode通信,得到一組Datanode地址,這些Datanode就是用來(lái)存儲(chǔ)該數(shù)據(jù)塊的;
客戶端首先將該數(shù)據(jù)塊發(fā)送到一個(gè)Datanode上,Datanode在接受時(shí)是以4kb為單位進(jìn)行,我們把這些小單位稱為緩存頁(yè)(參考了Linux管道文件的說(shuō)法);
對(duì)于第一個(gè)接到數(shù)據(jù)的Datanode,它把緩存頁(yè)中的數(shù)據(jù)寫(xiě)入自己的文件系統(tǒng),另一方面,它又將這些緩存頁(yè)傳送給下一個(gè)Datanode;
重復(fù)3的過(guò)程,第二個(gè)Datanode又將緩存頁(yè)存儲(chǔ)在本地文件系統(tǒng),同時(shí)將它傳送給第三個(gè)Datanode;
如果HDFS中的備份數(shù)目設(shè)置為3,那么第三個(gè)Datanode就只需要將緩存頁(yè)存儲(chǔ)即可。
上面的過(guò)程中,數(shù)據(jù)塊從客戶端流向第一個(gè)Datanode,然后再流向第二個(gè),從第二個(gè)再到第三個(gè),整個(gè)是一個(gè)流水線過(guò)程,中間不會(huì)有停頓。所以HDFS將它稱為Replication Pipelining。
為什么不采取客戶端同時(shí)向多個(gè)Datanode寫(xiě)數(shù)據(jù)的方法呢?其實(shí)從Pipelining這個(gè)稱呼上就可以猜到,客戶端和Datanode采用的緩存文件都是管道文件,即只支持一次讀取。
三、 數(shù)據(jù)刪除
HDFS中的數(shù)據(jù)刪除也是比較有特點(diǎn)的,并不是直接刪除,而是先放在一個(gè)類似回收站的地方(/trash),可供恢復(fù)。
對(duì)于用戶或者應(yīng)用程序想要?jiǎng)h除的文件,HDFS會(huì)將它重命名并移動(dòng)到/trash中,當(dāng)過(guò)了一定的生命期限以后,HDFS才會(huì)將它從文件系統(tǒng)中刪除,并由Namenode修改相關(guān)的元數(shù)據(jù)信息。并且只有到這個(gè)時(shí)候,Datanode上相關(guān)的磁盤空間才能節(jié)省出來(lái),也就是說(shuō),當(dāng)用戶要求刪除某個(gè)文件以后,并不能馬上看出HDFS存儲(chǔ)空間的增加,得等到一定的時(shí)間周期以后(現(xiàn)在默認(rèn)為6小時(shí))。
對(duì)于備份數(shù)據(jù),有時(shí)候也會(huì)需要?jiǎng)h除,比如用戶根據(jù)需要下調(diào)了Replicaion的個(gè)數(shù),那么多余的數(shù)據(jù)備份就會(huì)在下次Beatheart聯(lián)系中完成刪除,對(duì)于接受到刪除操作的Datanode來(lái)說(shuō),它要?jiǎng)h除的備份塊也是先放入/trash中,然后過(guò)一定時(shí)間后才刪除。因此在磁盤空間的查看上,也會(huì)有一定的延時(shí)。
那么如何立即徹底刪除文件呢,可以利用HDFS提供的Shell命令:bin/hadoop dfs expunge清空/trash。
-
存儲(chǔ)
+關(guān)注
關(guān)注
13文章
4298瀏覽量
85805 -
Hadoop
+關(guān)注
關(guān)注
1文章
90瀏覽量
15975
原文標(biāo)題:Hadoop分布式存儲(chǔ)與傳統(tǒng)SQL存儲(chǔ)比較及存儲(chǔ)操作描述
文章出處:【微信號(hào):cunchujie,微信公眾號(hào):存儲(chǔ)界】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論