分布式文件系統(tǒng)的HDFS是什么

一、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這些常用的分布式組件。