Hadoop源碼分析五hdfs架構原理剖析

Posted on by

1、 hdfs架構

在本系列文章三中出現瞭與hdfs相關的數個服務。

如果在hadoop配置時寫的配置文件不同，啟動的服務也有所區別

按照本系列文章二中的配置，會啟動以下服務：namenode、journalnode、datanode、zkfc。其關系如圖：

在這裡插入圖片描述

從圖中可以看出namenode是絕對的中心節點，所有的節點都會和它進行交互。圖中namenode有兩臺，一臺為active，另一臺為standby。其中active是正常提供namenode服務，standby不對外提供服務，它負責及時同步active的數據，並在active故障的時候轉換為active繼續提供服務。

namenode的下方是三臺datanode。

datanode負責存儲集群中的數據，並向namenode匯報其存儲數據的情況。

namenode左右兩邊的是兩個zkfc。

它負責的是namenode的故障轉移，在active的namenode故障的時候，由zkfc將standby的namenode轉換為active。zkfc上方連接的是zookeeper，它對namenode的故障轉移是依靠zookeeper來實現的。

namenode的上方是三臺journalnode集群。

journalnode負責存儲namenode的日志文件，由active的namenode向journalnode寫入，standby的namenode不會向journalnode寫日志，standby主要會從其中讀取日志文件。

註意，這裡的日志文件不是普通的運行日志，而是namenode的操作日志。例如，客戶端向hdfs上傳瞭一個文件，這時namenode會執行一系列操作來完成這次上傳，而這些操作連同操作方式與操作內容一起寫到操作日志中(journalnode中)，通過這些操作日志可以還原這次上傳操作。

2、 namenode介紹

namenode作為hdfs的核心，它主要的作用是管理文件的元數據

元數據主要包括三類：文件的命名空間、文件與塊的對應關系、塊的存儲位置。

文件與塊的對應關系中的塊

是由於hdfs在存儲文件的時候並不是將整個文件將存儲在某一臺datanode上，而是將文件按照指定的大小切割成一定數量的塊。

namenode負責管理hdfs的元數據

這意味著所有與hdfs相關的操作都需要與namenode進行交互。這樣namenode的速度就不能太慢，所以namenode將元數據存儲在內存中。但是數據不能隻存儲在內存中，所以這時需要將數據持久化到硬盤中。

namenode的數據持久化，采用瞭一種日志加快照的方式

日志即上文提到的操作日志，快照即將內存中的數據狀態直接序列化到硬盤。在安裝集群的時候會先格式化namenode，這時便會創建一個快照文件，名為fsimage。然後在namenode運行的時候它會將操作日志寫入到fsimage文件所在的文件夾中。這裡根據配置的不同寫入的路徑有所不同。如果使用本系列文章二中的配置，這個日志文件還會被寫到journalnode中。

最後還會有一個程序讀取這個快照文件和日志文件

將數據恢復到最新的狀態，然後再更新原來的快照文件。下一次再讀取快照和日志文件的時候就隻讀最新的文件。這裡的程序會根據配置的不同有所區別，按照本系列文章二中的配置來說，是standby的namenode。這裡為什麼不直接使用active的namenode執行更新fsimage文件，而是使用standby的namenode先讀取active的日志，然後再重演一遍操作日志恢復數據再由standby的namenode更新fsimage文件。這是因為更新fsimage操作很費時間，由active的namenode執行會導致整個集群不可用。

以上就是Hadoop源碼分析五hdfs架構原理剖析的詳細內容，本系列下一篇文章傳送門Hadoop源碼分析六啟動文件namenode原理詳解更多關於Hadoop源碼分析的資料請持續關註WalkonNet更新！

推薦閱讀：