轉自：https://www.cnblogs.com/DarrenChan/p/6416043.html?utm_source=itdadao&utm_medium=referral

首先我們看一下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上的數據塊。

namenode和datanode機制