HDFS架構

hdfs的設計前提和目標：

　　1.認爲硬件錯誤是常態而不是異常

　　2.流式數據訪問，注重批處理和高吞吐量，而不是低延遲

　　3.大規模數據集

　　4.一次寫入屢次讀取的文件訪問模式

　　5.移動計算比移動數據更加划算

　　6.異構軟硬件平臺間的可移植性

 

namenode：

　　做用

　　　　1.存儲文件和目錄的元數據（元數據放在內存中）：包含文件的block的副本個數，修改和訪問的時間，訪問權限，block大小以及block列表信息。

　　　　2.以兩種方法在namenode本地進行持久化

　　　　　　命名空間鏡像文件（fsimage）和編輯日誌（edits log）

　　　　3.fsimage文件不記錄每一個block所在的datanode信息，這些信息會在每次系統啓動的時候從datanode重建，以後datanode會週期性的經過心跳機制向namenode報告block信息。　　　

datanode向namenode註冊的時候發送的block列表信息：

• • • 一、文件名稱和路徑
    • 二、文件的大小
    • 三、文件的所屬關係
    • 四、文件的block塊大小 128MB
    • 五、文件的副本個數 3 MR 10個副本
    • 六、文件的修改時間
    • 七、文件的訪問時間
    • 八、文件的權限
    • 九、文件的block列表

blk1:0,134217728‬,node1,node13,node26：blockID
blk2:134217728,134217728‬,node7,node89,node1002
blk2:134217728*2,134217728‬,node7,node89,node1002

 

 

　　　　

　　　　　該目錄結構在第一次格式化的時候建立

　　　　　　in_use.lock文件用於NameNode鎖定存儲目錄，這樣就防止其餘同時運行的NameNode實例使用相同的存儲目錄

　　　　　　edits表示edits log日誌文件，在namenode啓動後，對文件系統的改動序列

　　　　　　fsimage：表示文件系統元數據鏡像文件，啓動時對整個文件系統的快照

　　　　　　NameNode在checkpoint以前首先要切換新的edits log文件，在切換時更新seen_txid的值。上次合併fsimage和editslog以後的第一個操做編號

　　用戶操做過程

　　　　　　當文件系統客戶端進行了寫操做（建立或者移動了文件），這個事務首先在edits log中記錄下來，namenode在內存中有文件系統的元數據，當edits log記錄結束後，才更新內存中的元數據

SecondaryNamenode

　　存在的意義

　　　　edits log會隨着對文件系統的操做而無限制的增加，這種狀況對正在運行的namenode而言沒有任何影響，若是namenode重啓，則須要很長的時間執行deits log的記錄來更新fsimage（元數據的鏡像文件），在此期間，整個系統不可用。

　　工做流程

　　　　1.secondarynamenode請求namenode生成新的edits log文件並向其中寫日誌。NameNode會在全部的存儲目錄中更新seen_txid文件

　　　　2SecondaryNameNode經過HTTP GET的方式從NameNode下載fsimage和edits文件到本地。

　　　　3.secondaryNameNode將fsimage加載到本身的內存上，並根據edits log更新內存中的fsimage信息，而後將更新完畢以後的fsimage寫到磁盤上

　　　　4.SecondaryNamenode經過HTTP Put將新的fsimage文件發送到NameNode，NameNode將該文件保存爲.ckpt的臨時文件備用。

　　　　5.NameNode重命名該臨時文件並準備使用，此時NameNode擁有一個新的fsimage文件和一個很小的edits log文件（可能不是空的，由於在SecondaryNamenode合併期間，客戶端可能有讀寫操做），管理員也能夠將NameNode置於safeMode，經過hdfs dfsadmin -saveNamespace命令來進行edits log和fsimage的合併

　　SecondaryNameNode要和NameNode擁有相同的內存，對大的集羣，SecondaryNameNode運行與一臺專用的物理主機。

　　　　

 　　更新時機：

　　　　1.默認狀況下：SecondaryNameNode每一個小時進行一次checkpoint合併，由dfs.namenode.checkpoint.period設置，單位秒

　　　　2.在不足一小時的狀況下，若是edits log存儲的事務達到了100 0000 個也進行一次checkpoint合併

　　　　　　由dfs.namenode.checkpoint.txns設置事務數量

　　　　3.事務數量檢查默認每分鐘進行一次

　　　　　　由dfs.namenode.checkpoint.check.period設置，單位秒。

　　存儲結構

　　　　　　1.目錄佈局和namenode徹底同樣

　　　　　　2.若是NameNode徹底壞掉，也能夠快速的從secondarynamenode回覆，可是有可能會丟失數據，由於在secondarynamenode複製合併數據的時候，namenode的edits文件也在運行添加新的數據。

 NameNode和SecondaryNamenode的工做機制

　　NameNode中的元數據是存儲在哪裏的？

　　　　首先，咱們作個假設，若是存儲在NameNode節點的磁盤中，由於常常須要進行隨機訪問，還有響應客戶請求，必然是效率太低。所以，元數據須要存放在內存中，可是，若是隻存在內存中，一旦斷電，元數據丟失，這樣，整個集羣就沒法工做了，所以產生了在磁盤中備份元數據的fsimage

　　　　這樣又會帶來新的問題，當在內存中的元數據更新時，若是同時更新fsimage，就會致使效率太低，但若是不更新，就會產生一致性的問題，一旦NameNode節點斷電，就會產生數據丟失，所以，引入edits文件（只進行追加操做，效率很高），每當元數據有更新或者添加元數據時，修改內存中的元數據並追加到edits中，這樣，一旦NameNode節點斷電，就能夠經過fsimage和edits的合併，合成完整的元數據

　　　　可是，若是長時間添加數據到edits中，會致使該文件數據過大，效率下降，並且一旦斷電，恢復元數據須要的時間過長，所以，須要按期進行fsimage和edits文件的合併，若是這個操做由NameNode節點完成，又會效率太低，所以，引入新的節點Secondarynamenode，專門用於fsimage和edits的合併

第一階段：NameNode啓動：

　　1.第一次啓動namenode格式化後，建立fsimage和edits文件，若是不是第一次啓動，直接加載編輯日誌文件和鏡像文件到內存。

　　2.NameNode記錄操做日誌，更新滾動日誌。

　　3.NameNode在內存中對元數據進行增刪改。

第二階段：Secondarynamenode工做

　　1.secondarynamenode詢問Namenode是否須要checkPoint，直接帶回那麼弄得是否檢查結果

　　2.secondarynamenode請求執行checkPoint

　　3.NameNode滾動正在寫的edits日誌

　　4.將滾動前的編輯日誌和鏡像文件拷貝到secondaryNamenode

　　5.secondaryNamenode加載編輯日誌和鏡像文件到內存，併合並。

　　6.生成新的鏡像文件fsimage.chkpoint

　　7.拷貝fsimage.chkpoint到NameNode

　　8.NameNode將fsimage.chkpoint從新命名成fsimage

 

DataNode

　　存儲結構：

　　

一、HDFS塊數據存儲於blk_前綴的文件中，包含了被存儲文件原始字節數據的一部分。

二、每一個block文件都有一個.meta後綴的元數據文件關聯。該文件包含了一個版本和類型信息的頭部，後接該block中每一個部分的校驗和。

三、每一個block屬於一個block池，每一個block池有本身的存儲目錄，該目錄名稱就是該池子的ID（跟NameNode的VERSION文件中記錄的block池ID同樣）。

 

　　副本的放置策略：

第一個副本：放置在上傳文件的DN；若是是集羣外提交，則隨機挑選一臺磁盤不太滿，CPU不太忙的節點。

第二個副本：放置在於第一個副本不一樣的 機架的節點上。

第三個副本：與第二個副本相同機架的節點。

更多副本：隨機節點

Hadoop的安全模式

工做流程

1. 啓動NameNode，NameNode加載fsimage到內存，對內存數據執行edits log日誌中的事務操做。
2. 文件系統元數據內存鏡像加載完畢，進行fsimage和edits log日誌的合併，並建立新的fsimage文件和一個空的edits log日誌文件。
3. NameNode等待DataNode上傳block列表信息，直到副本數知足最小副本條件。
4. 當知足了最小副本條件，再過30秒，NameNode就會退出安全模式。最小副本條件指整個文件系統中有99.9%的block達到了最小副本數（默認值是1，可設置）

在NameNode安全模式（safemode）

1. 對文件系統元數據進行只讀操做
2. 當文件的全部block信息具有的狀況下，對文件進行只讀操做
3. 不容許進行文件修改（寫，刪除或重命名文件）