欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Hadoop源碼分析五hdfs架構(gòu)原理剖析

 更新時(shí)間:2021年09月02日 17:21:03   作者:huserblog  
本篇是Hadoop源碼分析系列文章第五篇,主要介紹Hadoop的hdfs架構(gòu)原理剖析,后續(xù)本系列文章會(huì)持續(xù)更新,有需要的朋友可以借鑒參考下

1、 hdfs架構(gòu)

本系列文章三中出現(xiàn)了與hdfs相關(guān)的數(shù)個(gè)服務(wù)。

如果在hadoop配置時(shí)寫的配置文件不同,啟動(dòng)的服務(wù)也有所區(qū)別

按照本系列文章二中的配置,會(huì)啟動(dòng)以下服務(wù):namenode、journalnode、datanodezkfc。其關(guān)系如圖:

在這里插入圖片描述

從圖中可以看出namenode是絕對(duì)的中心節(jié)點(diǎn),所有的節(jié)點(diǎn)都會(huì)和它進(jìn)行交互。圖中namenode有兩臺(tái),一臺(tái)為active,另一臺(tái)為standby。其中active是正常提供namenode服務(wù),standby不對(duì)外提供服務(wù),它負(fù)責(zé)及時(shí)同步active的數(shù)據(jù),并在active故障的時(shí)候轉(zhuǎn)換為active繼續(xù)提供服務(wù)。

namenode的下方是三臺(tái)datanode。

datanode負(fù)責(zé)存儲(chǔ)集群中的數(shù)據(jù),并向namenode匯報(bào)其存儲(chǔ)數(shù)據(jù)的情況。

namenode左右兩邊的是兩個(gè)zkfc。

它負(fù)責(zé)的是namenode的故障轉(zhuǎn)移,在active的namenode故障的時(shí)候,由zkfc將standby的namenode轉(zhuǎn)換為active。zkfc上方連接的是zookeeper,它對(duì)namenode的故障轉(zhuǎn)移是依靠zookeeper來(lái)實(shí)現(xiàn)的。

namenode的上方是三臺(tái)journalnode集群。

journalnode負(fù)責(zé)存儲(chǔ)namenode的日志文件,由active的namenode向journalnode寫入,standby的namenode不會(huì)向journalnode寫日志,standby主要會(huì)從其中讀取日志文件。

注意,這里的日志文件不是普通的運(yùn)行日志,而是namenode的操作日志。例如,客戶端向hdfs上傳了一個(gè)文件,這時(shí)namenode會(huì)執(zhí)行一系列操作來(lái)完成這次上傳,而這些操作連同操作方式與操作內(nèi)容一起寫到操作日志中(journalnode中),通過(guò)這些操作日志可以還原這次上傳操作。

2、 namenode介紹

namenode作為hdfs的核心,它主要的作用是管理文件的元數(shù)據(jù)

元數(shù)據(jù)主要包括三類:文件的命名空間、文件與塊的對(duì)應(yīng)關(guān)系、塊的存儲(chǔ)位置。

文件與塊的對(duì)應(yīng)關(guān)系中的塊

是由于hdfs在存儲(chǔ)文件的時(shí)候并不是將整個(gè)文件將存儲(chǔ)在某一臺(tái)datanode上,而是將文件按照指定的大小切割成一定數(shù)量的塊。

namenode負(fù)責(zé)管理hdfs的元數(shù)據(jù)

這意味著所有與hdfs相關(guān)的操作都需要與namenode進(jìn)行交互。這樣namenode的速度就不能太慢,所以namenode將元數(shù)據(jù)存儲(chǔ)在內(nèi)存中。但是數(shù)據(jù)不能只存儲(chǔ)在內(nèi)存中,所以這時(shí)需要將數(shù)據(jù)持久化到硬盤中。

namenode的數(shù)據(jù)持久化,采用了一種日志加快照的方式

日志即上文提到的操作日志,快照即將內(nèi)存中的數(shù)據(jù)狀態(tài)直接序列化到硬盤。在安裝集群的時(shí)候會(huì)先格式化namenode,這時(shí)便會(huì)創(chuàng)建一個(gè)快照文件,名為fsimage。然后在namenode運(yùn)行的時(shí)候它會(huì)將操作日志寫入到fsimage文件所在的文件夾中。這里根據(jù)配置的不同寫入的路徑有所不同。如果使用本系列文章二中的配置,這個(gè)日志文件還會(huì)被寫到j(luò)ournalnode中。

最后還會(huì)有一個(gè)程序讀取這個(gè)快照文件和日志文件

將數(shù)據(jù)恢復(fù)到最新的狀態(tài),然后再更新原來(lái)的快照文件。下一次再讀取快照和日志文件的時(shí)候就只讀最新的文件。這里的程序會(huì)根據(jù)配置的不同有所區(qū)別,按照本系列文章二中的配置來(lái)說(shuō),是standby的namenode。這里為什么不直接使用active的namenode執(zhí)行更新fsimage文件,而是使用standby的namenode先讀取active的日志,然后再重演一遍操作日志恢復(fù)數(shù)據(jù)再由standby的namenode更新fsimage文件。這是因?yàn)楦耭simage操作很費(fèi)時(shí)間,由active的namenode執(zhí)行會(huì)導(dǎo)致整個(gè)集群不可用。

以上就是Hadoop源碼分析五hdfs架構(gòu)原理剖析的詳細(xì)內(nèi)容,本系列下一篇文章傳送門Hadoop源碼分析六啟動(dòng)文件namenode原理詳解更多關(guān)于Hadoop源碼分析的資料請(qǐng)持續(xù)關(guān)注腳本之家更新!

相關(guān)文章

最新評(píng)論