一、HDFS介紹
上篇文章已經(jīng)講到了,隨著數(shù)據(jù)量越來(lái)越大,在一臺(tái)機(jī)器上已經(jīng)無(wú)法存儲(chǔ)所有的數(shù)據(jù)了,那我們會(huì)將這些數(shù)據(jù)分配到不同的機(jī)器來(lái)進(jìn)行存儲(chǔ),但是這就帶來(lái)一個(gè)問(wèn)題:不方便管理和維護(hù)
所以,我們就希望有一個(gè)系統(tǒng)可以將這些分布在不同操作服務(wù)器上的數(shù)據(jù)進(jìn)行統(tǒng)一管理,這就有了分布式文件系統(tǒng)
HDFS是分布式文件系統(tǒng)的其中一種(目前用得最廣泛的一種)
在使用HDFS的時(shí)候是非常簡(jiǎn)單的:雖然HDFS是將文件存儲(chǔ)到不同的機(jī)器上,但是我去使用的時(shí)候是把這些文件當(dāng)做是存儲(chǔ)在一臺(tái)機(jī)器的方式去使用(背后卻是多臺(tái)機(jī)器在執(zhí)行):
好比:我調(diào)用了一個(gè)RPC接口,我給他參數(shù),他返回一個(gè)response給我。RPC接口做了什么事其實(shí)我都不知道的(可能這個(gè)RPC接口又調(diào)了其他的RPC接口)-----屏蔽掉實(shí)現(xiàn)細(xì)節(jié),對(duì)用戶友好
明確一下:HDFS就是一個(gè)分布式文件系統(tǒng),一個(gè)文件系統(tǒng),我們用它來(lái)做什么?存數(shù)據(jù)呀。
下面,我們來(lái)了解一下HDFS的一些知識(shí),能夠幫我們更好地去「使用」HDFS
二、HDFS學(xué)習(xí)
從上面我們已經(jīng)提到了,HDFS作為一個(gè)分布式文件系統(tǒng),那么它的數(shù)據(jù)是保存在多個(gè)系統(tǒng)上的。例如,下面的圖:一個(gè)1GB的文件,會(huì)被切分成幾個(gè)小的文件,每個(gè)服務(wù)器都會(huì)存放一部分。
那肯定會(huì)有人會(huì)問(wèn):那會(huì)切分多少個(gè)小文件呢?默認(rèn)以128MB的大小來(lái)切分,每個(gè)128MB的文件,在HDFS叫做塊(block)
顯然,這個(gè)128MB大小是可配的。如果設(shè)置為太小或者太大都不好。如果切分的文件太小,那一份數(shù)據(jù)可能分布到多臺(tái)的機(jī)器上(尋址時(shí)間就很慢)。如果切分的文件太大,那數(shù)據(jù)傳輸時(shí)間的時(shí)間就很慢。
PS:老版本默認(rèn)是64MB
一個(gè)用戶發(fā)出了一個(gè)1GB的文件請(qǐng)求給HDFS客戶端,HDFS客戶端會(huì)根據(jù)配置(現(xiàn)在默認(rèn)是128MB),對(duì)這個(gè)文件進(jìn)行切分,所以HDFS客戶端會(huì)切分為8個(gè)文件(也叫做block),然后每個(gè)服務(wù)器都會(huì)存儲(chǔ)這些切分后的文件(block)?,F(xiàn)在我們假設(shè)每個(gè)服務(wù)器都存儲(chǔ)兩份。
這些存放真實(shí)數(shù)據(jù)的服務(wù)器,在HDFS領(lǐng)域叫做DataNode
現(xiàn)在問(wèn)題來(lái)了,HDFS客戶端按照配置切分完以后,怎么知道往哪個(gè)服務(wù)器(DataNode)放數(shù)據(jù)呢?這個(gè)時(shí)候,就需要另一個(gè)角色了,管理者(NameNode)。
NameNode實(shí)際上就是管理文件的各種信息(這種信息專業(yè)點(diǎn)我們叫做MetaData「元數(shù)據(jù)」),其中包括:文文件路徑名,每個(gè)Block的ID和存放的位置等等。
所以,無(wú)論是讀還是寫,HDFS客戶端都會(huì)先去找NameNode,通過(guò)NameNode得知相應(yīng)的信息,再去找DataNode
如果是寫操作,HDFS切分完文件以后,會(huì)詢問(wèn)NameNode應(yīng)該將這些切分好的block往哪幾臺(tái)DataNode上寫。
如果是讀操作,HDFS拿到文件名,也會(huì)去詢問(wèn)NameNode應(yīng)該往哪幾臺(tái)DataNode上讀數(shù)據(jù)。
2.1 HDFS備份
作為一個(gè)分布式系統(tǒng)(把大文件切分為多個(gè)小文件,存儲(chǔ)到不同的機(jī)器上),如果沒(méi)有備份的話,只要有其中的一臺(tái)機(jī)器掛了,那就會(huì)導(dǎo)致「數(shù)據(jù)」是不可用狀態(tài)的。
寫到這里,如果看過(guò)我的Kafka和ElasticSearch的文章可能就懂了。其實(shí)思想都是一樣的。
Kafka對(duì)partition備份,ElasticSearch對(duì)分片進(jìn)行備份,而到HDFS就是對(duì)Block進(jìn)行備份。
盡可能將數(shù)據(jù)備份到不同的機(jī)器上,即便某臺(tái)機(jī)器掛了,那就可以將備份數(shù)據(jù)拉出來(lái)用。
對(duì)Kafka和ElasticSearch不了解的同學(xué),可以關(guān)注我的GitHub,搜索關(guān)鍵字即可查詢(我覺(jué)得還算寫得比較通俗易懂的)
注:這里的備份并不需要HDFS客戶端去寫,只要DataNode之間互相傳遞數(shù)據(jù)就好了。
2.2 NameNode的一些事
從上面我們可以看到,NameNode是需要處理hdfs客戶端請(qǐng)求的。(因?yàn)樗谴鎯?chǔ)元數(shù)據(jù)的地方,無(wú)論讀寫都需要經(jīng)過(guò)它)。
現(xiàn)在問(wèn)題就來(lái)了,NameNode是怎么存放元數(shù)據(jù)的呢?
如果NameNode只是把元數(shù)據(jù)放到內(nèi)存中,那如果NameNode這臺(tái)機(jī)器重啟了,那元數(shù)據(jù)就沒(méi)了。
如果NameNode將每次寫入的數(shù)據(jù)都存儲(chǔ)到硬盤中,那如果只針對(duì)磁盤查找和修改又會(huì)很慢(因?yàn)檫@個(gè)是純IO的操作)
說(shuō)到這里,又想起了Kafka。Kafka也是將partition寫到磁盤里邊的,但人家是怎么寫的?順序IO
NameNode同樣也是做了這個(gè)事:修改內(nèi)存中的元數(shù)據(jù),然后把修改的信息append(追加)到一個(gè)名為editlog的文件上。
由于append是順序IO,所以效率也不會(huì)低?,F(xiàn)在我們?cè)鰟h改查都是走內(nèi)存,只不過(guò)增刪改的時(shí)候往磁盤文件editlog里邊追加一條。這樣我們即便重啟了NameNode,還是可以通過(guò)editlog文件將元數(shù)據(jù)恢復(fù)。
現(xiàn)在也有個(gè)問(wèn)題:如果NameNode一直長(zhǎng)期運(yùn)行的話,那editlog文件應(yīng)該會(huì)越來(lái)越大(因?yàn)樗械男薷脑獢?shù)據(jù)信息都需要在這追加一條)。重啟的時(shí)候需要依賴editlog文件來(lái)恢復(fù)數(shù)據(jù),如果文件特別大,那啟動(dòng)的時(shí)候不就特別慢了嗎?
的確是如此的,那HDFS是怎么做的呢?為了防止editlog過(guò)大,導(dǎo)致在重啟的時(shí)候需要較長(zhǎng)的時(shí)間恢復(fù)數(shù)據(jù),所以NameNode會(huì)有一個(gè)內(nèi)存快照,叫做fsimage
說(shuō)到快照,有沒(méi)有想起Redis的RDB!!
這樣一來(lái),重啟的時(shí)候只需要加載內(nèi)存快照f(shuō)simage+部分的editlog就可以了。
想法很美好,現(xiàn)實(shí)還需要解決一些事:我什么時(shí)候生成一個(gè)內(nèi)存快照f(shuō)simage?我怎么知道加載哪一部分的editlog?
問(wèn)題看起來(lái)好像復(fù)雜,其實(shí)我們就只需要一個(gè)定時(shí)任務(wù)。
如果讓我自己做的話,我可能會(huì)想:我們加一份配置,設(shè)置個(gè)時(shí)間就OK了
如果editlog大到什么程度或者隔了多長(zhǎng)時(shí)間,我們就把editlog文件的數(shù)據(jù)跟內(nèi)存快照f(shuō)siamge給合并起來(lái)。然后生成一個(gè)新的fsimage,把editlog給清空,覆蓋舊的fsimage內(nèi)存快照這樣一來(lái),NameNode每次重啟的時(shí)候,拿到的都是最新的fsimage文件,editlog里邊的都是沒(méi)合并到fsimage的。根據(jù)這兩個(gè)文件就可以恢復(fù)最新的元數(shù)據(jù)信息了。
HDFS也是類似上面這樣干的,只不過(guò)它不是在NameNode起個(gè)定時(shí)的任務(wù)跑,而是用了一個(gè)新的角色:SecondNameNode。至于為什么?可能HDFS覺(jué)得合并所耗費(fèi)的資源太大了,不同的工作交由不同的服務(wù)器來(lái)完成,也符合分布式的理念。
現(xiàn)在問(wèn)題還是來(lái)了,此時(shí)的架構(gòu)NameNode是單機(jī)的。SecondNameNode的作用只是給NameNode合并editlog和fsimage文件,如果NameNode掛了,那client就請(qǐng)求不到了,而所有的請(qǐng)求都需要走NameNode,這導(dǎo)致整個(gè)HDFS集群都不可用了。
于是我們需要保證NameNode是高可用的。一般現(xiàn)在我們會(huì)通過(guò)Zookeeper來(lái)實(shí)現(xiàn)。架構(gòu)圖如下:
主NameNode和從NameNode需要保持元數(shù)據(jù)的信息一致(因?yàn)槿绻鱊ameNode掛了,那從NameNode需要頂上,這時(shí)從NameNode需要有主NameNode的信息)。
所以,引入了Shared Edits來(lái)實(shí)現(xiàn)主從NameNode之間的同步,Shared Edits也叫做JournalNode。實(shí)際上就是主NameNode如果有更新元數(shù)據(jù)的信息,它的editlog會(huì)寫到JournalNode,然后從NameNode會(huì)在JournalNode讀取到變化信息,然后同步。從NameNode也實(shí)現(xiàn)了上面所說(shuō)的SecondNameNode功能(合并editlog和fsimage)
稍微總結(jié)一下:
NameNode需要處理client請(qǐng)求,它是存儲(chǔ)元數(shù)據(jù)的地方
NameNode的元數(shù)據(jù)操作都在內(nèi)存中,會(huì)把增刪改以editlog持續(xù)化到硬盤中(因?yàn)槭琼樞騣o,所以不會(huì)太慢)
由于editlog可能存在過(guò)大的問(wèn)題,導(dǎo)致重新啟動(dòng)NameNode過(guò)慢(因?yàn)橐蕾噀ditlog來(lái)恢復(fù)數(shù)據(jù)),引出了fsimage內(nèi)存快照。需要跑一個(gè)定時(shí)任務(wù)來(lái)合并fsimage和editlog,引出了SecondNameNode
又因?yàn)镹ameNode是單機(jī)的,可能存在單機(jī)故障的問(wèn)題。所以我們可以通過(guò)Zookeeper來(lái)維護(hù)主從NameNode,通過(guò)JournalNode(Share Edits)來(lái)實(shí)現(xiàn)主從NameNode元數(shù)據(jù)的一致性。最終實(shí)現(xiàn)NameNode的高可用。
2.3 學(xué)點(diǎn)DataNode
從上面我們就知道,我們的數(shù)據(jù)是存放在DataNode上的(還會(huì)備份)。
如果某個(gè)DataNode掉線了,那HDFS是怎么知道的呢?
DataNode啟動(dòng)的時(shí)候會(huì)去NameNode上注冊(cè),他倆會(huì)維持心跳,如果超過(guò)時(shí)間閾值沒(méi)有收到DataNode的心跳,那HDFS就認(rèn)為這個(gè)DataNode掛了。
還有一個(gè)問(wèn)題就是:我們將Block存到DataNode上,那還是有可能這個(gè)DataNode的磁盤損壞了部分,而我們DataNode沒(méi)有下線,但我們也不知道損壞了。
一個(gè)Block除了存放數(shù)據(jù)的本身,還會(huì)存放一份元數(shù)據(jù)(包括數(shù)據(jù)塊的長(zhǎng)度,塊數(shù)據(jù)的校驗(yàn)和,以及時(shí)間戳)。DataNode還是會(huì)定期向NameNode上報(bào)所有當(dāng)前所有Block的信息,通過(guò)元數(shù)據(jù)就可校驗(yàn)當(dāng)前的Block是不是正常狀態(tài)。
最后
其實(shí)在學(xué)習(xí)HDFS的時(shí)候,你會(huì)發(fā)現(xiàn)很多的思想跟之前學(xué)過(guò)的都類似。就比如提到的Kafka、Elasticsearch這些常用的分布式組件。
-
接口
+關(guān)注
關(guān)注
33文章
8390瀏覽量
150597 -
服務(wù)器
+關(guān)注
關(guān)注
12文章
8883瀏覽量
84994 -
HDFS
+關(guān)注
關(guān)注
1文章
30瀏覽量
9553
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論