HDFS是如何設(shè)計(jì)架構(gòu)的？

作者：大數(shù)據(jù)老哥 2021-01-28 05:11:26

Hadoop到目前為止發(fā)展已經(jīng)有10余年，版本經(jīng)過無數(shù)次的更新迭代，目前業(yè)內(nèi)大家把Hadoop大的版本分為Hadoop1.0、Hadoop2.0、Hadoop3.0 三個(gè)版本。

[[378843]]

前言

一、Hadoop 簡介

Hadoop版本剛出來的時(shí)候是為了解決兩個(gè)問題：一是海量數(shù)據(jù)如何存儲的問題，一個(gè)是海量數(shù)據(jù)如何計(jì)算的問題。Hadoop的核心設(shè)計(jì)就是HDFS和 Mapreduce.HDFS解決了海量數(shù)據(jù)如何存儲的問題， Mapreduce解決了海量數(shù)據(jù)如何計(jì)算的問題。HDFS的全稱：Hadoop Distributed File System。

二、分布式文件系統(tǒng)

圖片 HDFS其實(shí)就可以理解為一個(gè)分布式文件系統(tǒng)，可以看如圖1所示有4個(gè)服務(wù)器是不是都有他自己的文件系統(tǒng)都可以進(jìn)行存儲數(shù)據(jù)，假設(shè)每個(gè)服務(wù)器的存儲空間存儲10G的數(shù)據(jù)。假設(shè)數(shù)據(jù)量很小的時(shí)候存儲10G的數(shù)據(jù)還是ok的當(dāng)數(shù)據(jù)量大于服務(wù)器的存儲空間時(shí)是不是單個(gè)服務(wù)器就沒法存儲了。我們是不是可以在服務(wù)器中部署一個(gè)Hadoop這樣就能構(gòu)建出一個(gè)集群(超級大電腦)。這樣就存儲 4*10=40G的數(shù)據(jù)量，這樣我們面向用戶時(shí)是不是只有一臺超級大的電腦相當(dāng)于一個(gè)分布式文件系統(tǒng)。

HDFS是一個(gè)主從的架構(gòu)、主節(jié)點(diǎn)只有一個(gè)NemeNode。從節(jié)點(diǎn)有多個(gè)DataNode。

三、HDFS 架構(gòu)

圖片假設(shè)我們這里有5臺服務(wù)器每臺服務(wù)器都部署上Hadoop，我們隨便選擇一臺服務(wù)器部署上NameNode剩下服務(wù)器部署上DataNode。

客戶端上傳文件時(shí)假設(shè)文件大小為129MHDFS默認(rèn)切分的大小為128M這時(shí)就會產(chǎn)生出2個(gè)blkNameNode去通知DataNode上傳文件(這里有一定的策略)，我們就假設(shè)就將這幾個(gè)文件分別存儲在4個(gè)服務(wù)器上。為什們要進(jìn)行分別存儲在，假設(shè)DataNode服務(wù)器有一天突然掛掉了我們是不是還可通過DataNode4或2和3進(jìn)行讀取數(shù)據(jù)，這樣是不是就防止數(shù)據(jù)丟失。

NameNode

管理元數(shù)據(jù)信息(文件目錄樹)：文件與Block塊，Block塊與DataNode主機(jī)關(guān)系
NameNode為快速響應(yīng)用戶操作，所以把元數(shù)據(jù)信息加載到內(nèi)存里

DataNode

存儲數(shù)據(jù)，把上傳的數(shù)據(jù)劃分固定大小文件塊(Block)在Hadoop2.73之前是64M之后改為了128M
為了保證數(shù)據(jù)安全，每個(gè)文件默認(rèn)都是三個(gè)副本

SecondaryNamenode

周期性的到NameNode節(jié)點(diǎn)拉取Edtis和fsimage文件，將這兩個(gè)文件加入到內(nèi)存進(jìn)行然后將這兩個(gè)文件加入到內(nèi)存中進(jìn)行合并產(chǎn)生新的fsimage發(fā)送給NameNode。

四、HDFS寫入數(shù)據(jù)流程

客戶端會帶著文件路徑向NameNode發(fā)送寫入請求通過 RPC 與 NameNode 建立通訊， NameNode 檢查目標(biāo)文件，返回是否可以上傳;
Client 請求第一個(gè) block 該傳輸?shù)侥男?DataNode 服務(wù)器上;
NameNode 根據(jù)副本數(shù)量和副本放置策略進(jìn)行節(jié)點(diǎn)分配，返回DataNode節(jié)點(diǎn)，如：A，B，C
Client 請求A節(jié)點(diǎn)建立pipeline管道，A收到請求會繼續(xù)調(diào)用B，然后B調(diào)用C，將整個(gè)pipeline管道建立完成后,逐級返回消息到Client;
Client收到A返回的消息之后開始往A上傳第一個(gè)block塊，block塊被切分成64K的packet包不斷的在pepiline管道里傳遞，從A到B，B到C進(jìn)行復(fù)制存儲
當(dāng)一個(gè) block塊傳輸完成之后，Client 再次請求 NameNode 上傳第二個(gè)block塊的存儲節(jié)點(diǎn)，不斷往復(fù)存儲
當(dāng)所有block塊傳輸完成之后，Client調(diào)用FSDataOutputSteam的close方法關(guān)閉輸出流，最后調(diào)用FileSystem的complete方法告知NameNode數(shù)據(jù)寫入成功

五、HDFS讀取數(shù)據(jù)流程

客戶端會先帶著讀取路徑向NameNode發(fā)送讀取請求，通過 RPC 與 NameNode 建立通訊,NameNode檢查目標(biāo)文件，來確定請求文件 block塊的位置信息
NameNode會視情況返回文件的部分或者全部block塊列表，對于每個(gè)block塊，NameNode 都會返回含有該 block副本的 DataNode 地址
這些返回的 DataNode 地址，會按照集群拓?fù)浣Y(jié)構(gòu)得出 DataNode 與客戶端的距離，然后進(jìn)行排序，排序兩個(gè)規(guī)則：網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)中距離 Client 近的排靠前;心跳機(jī)制中超時(shí)匯報(bào)的 DN 狀態(tài)為 STALE，這樣的排靠后;
Client 選取排序靠前的 DataNode 調(diào)用FSDataInputSteam的read方法來讀取 block塊數(shù)據(jù)，如果客戶端本身就是DataNode,那么將從本地直接獲取block塊數(shù)據(jù)
當(dāng)讀完一批的 block塊后，若文件讀取還沒有結(jié)束，客戶端會繼續(xù)向NameNode 獲取下一批的 block 列表，繼續(xù)讀取
所有block塊讀取完成后，Client調(diào)用FSDataInputStream.close()方法，關(guān)閉輸入流，并將讀取來所有的 block塊合并成一個(gè)完整的最終文件

六、HDFS缺陷

注意：早期版本

單點(diǎn)問題
內(nèi)存受限

總結(jié)

上述給大家講解了簡單的HDFS架構(gòu)，我在最后面留了一個(gè)小問題，我會在下期通過畫圖的方式給大家講解，我在這里為大家提供大數(shù)據(jù)的資料需要的朋友可以去下面GitHub去下載，信自己，努力和汗水總會能得到回報(bào)的。我是大數(shù)據(jù)老哥，我們下期見~~~

本文轉(zhuǎn)載自微信公眾號「大數(shù)據(jù)老哥」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系大數(shù)據(jù)老哥公眾號。

責(zé)任編輯：武曉燕來源：大數(shù)據(jù)老哥

HDFS 架構(gòu)Hadoop