Hadoop Secondarynamenode原理

namenode的文件存儲

namenode數(shù)據(jù)存儲分為兩個文件，fsp_w_picpath與edits文件，edits文件記錄了所有namenode的操作，相當于日志記錄。fsp_w_picpath記錄了namenode的數(shù)據(jù)。在namenode啟動時，會加載fsp_w_picpath的數(shù)據(jù)到內(nèi)存中，并從edits文件中解析所有數(shù)據(jù)信息到內(nèi)存，兩個數(shù)據(jù)合并后共同組成了namenode全量信息。

secondarynamenode的作用

secondarynamenode 按一定規(guī)則將edits文件和fsp_w_picpath文件合并，合并后namenode會啟用新的edits文件，這樣會減小edits文件的文件大小，控制edits文件的大小會減少namenode在啟動階段解析加載edits文件的時長。

secondarynamenode合并文件規(guī)則

   配置    fs.checkpoint.period 執(zhí)行檢查點合并文件檢查時間 默認3600s 

               fs.checkpoint.size    實行檢查點合并文件閥值大小 默認64M

  兩個條件滿足其一則合并文件

工作原理示意圖

架構(gòu)分析

    fsp_w_picpath與edits文件對于namenode存儲數(shù)據(jù)有什么區(qū)別，為什么要分開兩個文件進行存儲？

    fsp_w_picpath存儲著所有目錄和文件的序列化信息，而edits保存了所有寫或更新的信息，在namenode運行過程中只向edits文件中寫相關(guān)的操作信息和文件信息

    分兩個文件存儲是因為fsp_w_picpath由于保存了所有namenode的信息，所以文件大小通常比較大，這樣在一個大的文件中進行寫操作比較費系統(tǒng)資源而且延遲了系統(tǒng)的反應時間，而edits文件由于有secondarynamenode進行合并，通常大小要小于fsp_w_picpath，所以在edits文件中進行更新寫操作會降低系統(tǒng)資源的消耗。

    為什么會引入sencondarynamenode，只用namenode會有什么問題？

    由于namenode進行分文件保存，但又不能使edits文件過大，所以需要進行文件合并，但進行文件合并會占用系統(tǒng)內(nèi)存等資源，如果直接使用namenode進行文件合并，會導致在合并文件期間，系統(tǒng)文件管理能力下降卡頓等。另外由于secondarynamenode與namenode進行分離，可以將namenode和secondarynamenode分開部署到不同機器上，提高系統(tǒng)的穩(wěn)定與安全性。除此之外，secondarynamenode由于進行了檢查點，在namenode完全宕機數(shù)據(jù)丟失的情況下，secondarynamenode可以在檢查點上恢復系統(tǒng)數(shù)據(jù)，當然，也會造成檢查點之后的數(shù)據(jù)丟失。

                                                                                                                                       -----史龍剛