namenode和datanode機制

首先咱們看一下NAMENODE:

咱們已經知道了NAMENODE做爲DATANODE的管理者，其重要性不言而喻，那麼NAMENODE是怎麼管理數據的呢？

首先，咱們看一下上面這張圖，每次客戶端讀寫數據都要先通過NAMENODE，其實就是先查詢NAMENODE中的元數據，那麼問題來了，NAMENODE中的元數據到底是存在內存中仍是存在硬盤中呢？若是存在內存中，一旦斷電就意味着數據的丟失；可是存在硬盤中，讀寫速度必然降低。下面將對其細節進行詳盡的闡述。

經過看以上這幅圖，咱們能夠看到NAMENODE中的元數據既存在在內存中，也存在在硬盤中。咱們先看一下元數據的存儲細節：

從左到右依次是存儲路徑，有哪些副本，每一個副本在哪些主機上面存儲。NAMENODE是整個文件系統的管理節點。它維護着整個文件系統的文件目錄樹，文件/目錄的元信息和每一個文件對應的數據塊列表，接受用戶的操做請求。

文件包括：

1.fsimage:元數據鏡像文件，存儲某一時段NAMENODE內存元數據信息。

2.edits:操做日誌文件。

3.fstime:保存最近一次checkpoint的時間。

如今咱們回到上一幅圖，

1.NAMENODE始終在內存中保存meta.data，用於處理「讀請求」。

2.到有「寫請求」到來時，NAMENODE會首先寫edits到磁盤，即向edits文件中寫日誌，成功返回後，纔會修改內存，而且向客戶端返回。

3.Hadoop會維護一個fsimage文件，也就是namenode中meta.data的鏡像，可是fsimage不會隨時與NAMENODE內存中的meta.data保持一致，而是每隔一段時間經過合併edits文件來更新內容。Secondary NAMENODE就是用來合併fsimage和edits文件來更新NAMENODE的meta.data的。

 

這裏就用到了Secondary NAMENODE，咱們再來看一張圖：

 

在這張圖中，咱們能夠看到SN的一些做用，當NN通知SN要進行checkpoint操做的時候，NN就中止向edits日誌中寫數據了，可是寫操做又不能中止，這時候就會向一個edits.new日誌文件中寫數據，而SN會把fsimage和edits裏面的內容下載到SN中，在SN中進行合併，說白了，就是將日誌格式轉化成要存儲的文件格式，產生fsimage.chkpoint文件，並將它上傳給NN，替換fsimage，而且重命名成fsimage，同時edits.new替換edits，而且重命名成edits。詳細過程就是：

那麼何時checkpoint呢？有兩種判別方式：

1.fs.checkpoint.period:指定兩次checkpoint的最大時間間隔，默認是3600秒。

2.fs.checkpoint.size:規定edits文件的最大值，一旦超過這個值則強制checkpoint，無論是否達到最大時間間隔。默認大小是64M。

兩種斷定方式先達到哪一個斷定條件，則先採用哪一個。

咱們再來看一下DATANODE:

DataNode

提供真實文件數據的存儲服務

文件塊：最基本的存儲單位，對於文件內容而言，一個文件的長度大小是size，那麼從文件的0偏移，按照固定的大小，順序對文件進行劃分並編號。劃分好的每一塊稱爲一個Block，默認Block的大小是128M。開始不一樣於普通文件系統的是HDFS中，若是一個文件小於一個數據塊的大小，並不佔用整個數據塊存儲空間。datanode與namenode保存心跳機制，當長時間未向namenode報告，則視爲該datanode死機，namenode會從新備份該datanode上的數據塊。