您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關Hadoop之hdfs架構原理的示例分析,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
在本系列文章三中出現了與hdfs
相關的數個服務。
按照本系列文章二中的配置,會啟動以下服務:namenode
、journalnode
、datanode
、zkfc
。其關系如圖:
從圖中可以看出namenode是絕對的中心節點,所有的節點都會和它進行交互。圖中namenode有兩臺,一臺為active,另一臺為standby。其中active是正常提供namenode服務,standby不對外提供服務,它負責及時同步active的數據,并在active故障的時候轉換為active繼續提供服務。
datanode負責存儲集群中的數據,并向namenode匯報其存儲數據的情況。
它負責的是namenode的故障轉移,在active的namenode故障的時候,由zkfc將standby的namenode轉換為active。zkfc上方連接的是zookeeper,它對namenode的故障轉移是依靠zookeeper來實現的。
journalnode負責存儲namenode的日志文件,由active的namenode向journalnode寫入,standby的namenode不會向journalnode寫日志,standby主要會從其中讀取日志文件。
注意,這里的日志文件不是普通的運行日志,而是namenode的操作日志。例如,客戶端向hdfs上傳了一個文件,這時namenode會執行一系列操作來完成這次上傳,而這些操作連同操作方式與操作內容一起寫到操作日志中(journalnode中),通過這些操作日志可以還原這次上傳操作。
元數據主要包括三類:文件的命名空間、文件與塊的對應關系、塊的存儲位置。
是由于hdfs在存儲文件的時候并不是將整個文件將存儲在某一臺datanode上,而是將文件按照指定的大小切割成一定數量的塊。
這意味著所有與hdfs相關的操作都需要與namenode進行交互。這樣namenode的速度就不能太慢,所以namenode將元數據存儲在內存中。但是數據不能只存儲在內存中,所以這時需要將數據持久化到硬盤中。
日志即上文提到的操作日志,快照即將內存中的數據狀態直接序列化到硬盤。在安裝集群的時候會先格式化namenode,這時便會創建一個快照文件,名為fsimage。然后在namenode運行的時候它會將操作日志寫入到fsimage文件所在的文件夾中。這里根據配置的不同寫入的路徑有所不同。如果使用本系列文章二中的配置,這個日志文件還會被寫到journalnode中。
將數據恢復到最新的狀態,然后再更新原來的快照文件。下一次再讀取快照和日志文件的時候就只讀最新的文件。這里的程序會根據配置的不同有所區別,按照本系列文章二中的配置來說,是standby的namenode。這里為什么不直接使用active的namenode執行更新fsimage文件,而是使用standby的namenode先讀取active的日志,然后再重演一遍操作日志恢復數據再由standby的namenode更新fsimage文件。這是因為更新fsimage操作很費時間,由active的namenode執行會導致整個集群不可用。
關于“Hadoop之hdfs架構原理的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。