Hadoop分布式文件系統(tǒng)-HDFS的相關(guān)概念

Hadoop分布式文件系統(tǒng)——HDFS的相關(guān)概念北京信息職業(yè)技術(shù)學(xué)院|朱立本文來(lái)自：大數(shù)據(jù)技術(shù)原理與應(yīng)用（第2版）——概念、存儲(chǔ)、處理、分析與應(yīng)用作者：林子雨出版社：人民郵電出版社版權(quán)說(shuō)明若作者對(duì)本資料使用持有異議，請(qǐng)及時(shí)聯(lián)系本網(wǎng)站，我們將在第一時(shí)間妥善處理。21.塊1.塊HDFS默認(rèn)一個(gè)塊64MB，一個(gè)文件被分成多個(gè)塊，以塊作為存儲(chǔ)單位塊的大小遠(yuǎn)遠(yuǎn)大于普通文件系統(tǒng)，可以最小化尋址開銷HDFS采用抽象的塊概念可以帶來(lái)以下幾個(gè)明顯的好處：●支持大規(guī)模文件存儲(chǔ)：文件以塊為單位進(jìn)行存儲(chǔ)，一個(gè)大規(guī)模文件可以被分拆成若干個(gè)文件塊，不同的文件塊可以被分發(fā)到不同的節(jié)點(diǎn)上，因此，一個(gè)文件的大小不會(huì)受到單個(gè)節(jié)點(diǎn)的存儲(chǔ)容量的限制，可以遠(yuǎn)遠(yuǎn)大于網(wǎng)絡(luò)中任意節(jié)點(diǎn)的存儲(chǔ)容量●簡(jiǎn)化系統(tǒng)設(shè)計(jì)：首先，大大簡(jiǎn)化了存儲(chǔ)管理，因?yàn)槲募K大小是固定的，這樣就可以很容易計(jì)算出一個(gè)節(jié)點(diǎn)可以存儲(chǔ)多少文件塊；其次，方便了元數(shù)據(jù)的管理，元數(shù)據(jù)不需要和文件塊一起存儲(chǔ)，可以由其他系統(tǒng)負(fù)責(zé)管理元數(shù)據(jù)●適合數(shù)據(jù)備份：每個(gè)文件塊都可以冗余存儲(chǔ)到多個(gè)節(jié)點(diǎn)上，大大提高了系統(tǒng)的容錯(cuò)性和可用性2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)名稱節(jié)點(diǎn)的數(shù)據(jù)結(jié)構(gòu)在HDFS中，名稱節(jié)點(diǎn)（NameNode）負(fù)責(zé)管理分布式文件系統(tǒng)的命名空間（Namespace），保存了兩個(gè)核心的數(shù)據(jù)結(jié)構(gòu)，即FsImage和EditLogFsImage用于維護(hù)文件系統(tǒng)樹以及文件樹中所有的文件和文件夾的元數(shù)據(jù)操作日志文件EditLog中記錄了所有針對(duì)文件的創(chuàng)建、刪除、重命名等操作名稱節(jié)點(diǎn)記錄了每個(gè)文件中各個(gè)塊所在的數(shù)據(jù)節(jié)點(diǎn)的位置信息2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)FsImage文件FsImage文件包含文件系統(tǒng)中所有目錄和文件inode的序列化形式。每個(gè)inode是一個(gè)文件或目錄的元數(shù)據(jù)的內(nèi)部表示，并包含此類信息：文件的復(fù)制等級(jí)、修改和訪問(wèn)時(shí)間、訪問(wèn)權(quán)限、塊大小以及組成文件的塊。對(duì)于目錄，則存儲(chǔ)修改時(shí)間、權(quán)限和配額元數(shù)據(jù)FsImage文件沒(méi)有記錄塊存儲(chǔ)在哪個(gè)數(shù)據(jù)節(jié)點(diǎn)。而是由名稱節(jié)點(diǎn)把這些映射保留在內(nèi)存中，當(dāng)數(shù)據(jù)節(jié)點(diǎn)加入HDFS集群時(shí)，數(shù)據(jù)節(jié)點(diǎn)會(huì)把自己所包含的塊列表告知給名稱節(jié)點(diǎn)，此后會(huì)定期執(zhí)行這種告知操作，以確保名稱節(jié)點(diǎn)的塊映射是最新的。2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)名稱節(jié)點(diǎn)的啟動(dòng)在名稱節(jié)點(diǎn)啟動(dòng)的時(shí)候，它會(huì)將FsImage文件中的內(nèi)容加載到內(nèi)存中，之后再執(zhí)行EditLog文件中的各項(xiàng)操作，使得內(nèi)存中的元數(shù)據(jù)和實(shí)際的同步，存在內(nèi)存中的元數(shù)據(jù)支持客戶端的讀操作一旦在內(nèi)存中成功建立文件系統(tǒng)元數(shù)據(jù)的映射，則創(chuàng)建一個(gè)新的FsImage文件和一個(gè)空的EditLog文件名稱節(jié)點(diǎn)起來(lái)之后，HDFS中的更新操作會(huì)重新寫到EditLog文件中，因?yàn)镕sImage文件一般都很大（GB級(jí)別的很常見），如果所有的更新操作都往FsImage文件中添加，這樣會(huì)導(dǎo)致系統(tǒng)運(yùn)行的十分緩慢，但是，如果往EditLog文件里面寫就不會(huì)這樣，因?yàn)镋ditLog要小很多。每次執(zhí)行寫操作之后，且在向客戶端發(fā)送成功代碼之前，edits文件都需要同步更新2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)名稱節(jié)點(diǎn)運(yùn)行期間EditLog不斷變大的問(wèn)題在名稱節(jié)點(diǎn)運(yùn)行期間，HDFS的所有更新操作都是直接寫到EditLog中，久而久之，EditLog文件將會(huì)變得很大雖然這對(duì)名稱節(jié)點(diǎn)運(yùn)行時(shí)候是沒(méi)有什么明顯影響的，但是，當(dāng)名稱節(jié)點(diǎn)重啟的時(shí)候，名稱節(jié)點(diǎn)需要先將FsImage里面的所有內(nèi)容映像到內(nèi)存中，然后再一條一條地執(zhí)行EditLog中的記錄，當(dāng)EditLog文件非常大的時(shí)候，會(huì)導(dǎo)致名稱節(jié)點(diǎn)啟動(dòng)操作非常慢，而在這段時(shí)間內(nèi)HDFS系統(tǒng)處于安全模式，一直無(wú)法對(duì)外提供寫操作，影響了用戶的使用2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)名稱節(jié)點(diǎn)運(yùn)行期間EditLog不斷變大的問(wèn)題如何解決？答案是：SecondaryNameNode第二名稱節(jié)點(diǎn)第二名稱節(jié)點(diǎn)是HDFS架構(gòu)中的一個(gè)組成部分，它是用來(lái)保存名稱節(jié)點(diǎn)中對(duì)HDFS元數(shù)據(jù)信息的備份，并減少名稱節(jié)點(diǎn)重啟的時(shí)間。SecondaryNameNode一般是單獨(dú)運(yùn)行在一臺(tái)機(jī)器上2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)SecondaryNameNode的工作情況：（1）SecondaryNameNode會(huì)定期和NameNode通信，請(qǐng)求其停止使用EditLog文件，暫時(shí)將新的寫操作寫到一個(gè)新的文件edit.new上來(lái)，這個(gè)操作是瞬間完成，上層寫日志的函數(shù)完全感覺不到差別（2）SecondaryNameNode通過(guò)HTTPGET方式從NameNode上獲取到FsImage和EditLog文件，并下載到本地的相應(yīng)目錄下（3）SecondaryNameNode將下載下來(lái)的FsImage載入到內(nèi)存，然后一條一條地執(zhí)行EditLog文件中的各項(xiàng)更新操作，使得內(nèi)存中的FsImage保持最新；這個(gè)過(guò)程就是EditLog和FsImage文件合并2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)SecondaryNameNode的工作情況：（4）SecondaryNameNode執(zhí)行完（3）操作之后，會(huì)通過(guò)post方式將新的FsImage文件發(fā)送到NameNode節(jié)點(diǎn)上（5）NameNode將從SecondaryNameNode接收到的新的FsImage替換舊的FsImage文件，同時(shí)將edit.new替換EditLog文件，通過(guò)這個(gè)過(guò)程EditLog就變小了2.名稱節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)節(jié)點(diǎn)（Dat