Hadoop分布式文件系統(HDFS)是一種基于Java的分布式文件系統，它具有容錯性、可伸縮性和易擴展性等優點，它可在商用硬件上運行，也可以在低成本的硬件上進行部署。HDFS是一個分布式存儲的Hadoop應用程序，它提供了更接近數據的接口。

HDFS架構

hdfs架構圖如下圖所示：

HDFS具有主/從架構。HDFS集群由單個NameNode，和多個datanode構成。

NameNode：管理文件系統命名空間的主服務器和管理客戶端對文件的訪問組成，如打開，關閉和重命名文件和目錄。負責管理文件目錄、文件和block的對應關系以及block和datanode的對應關系，維護目錄樹，接管用戶的請求。如下圖所示：

1、將文件的元數據保存在一個文件目錄樹中2、在磁盤上保存為：fsimage 和 edits3、保存datanode的數據信息的文件，在系統啟動的時候讀入內存。

DataNode：（數據節點）管理連接到它們運行的節點的存儲，負責處理來自文件系統客戶端的讀寫請求。DataNodes還執行塊創建，刪除

Client：(客戶端)代表用戶通過與nameNode和datanode交互來訪問整個文件系統，HDFS對外開放文件命名空間并允許用戶數據以文件形式存儲。用戶通過客戶端（Client）與HDFS進行通訊交互。

**塊和復制：**我們都知道linux操作系統中的磁盤的塊的大小默認是512，而hadoop2.x版本中的塊的大小默認為128M，那為什么hdfs中的存儲塊要設計這么大呢？其目的是為了減小尋址的開銷。只要塊足夠大，磁盤傳輸數據的時間必定會明顯大于這個塊的尋址時間。

那為什么要以塊的形式存儲文件，而不是整個文件呢？1、因為一個文件可以特別大，可以大于有個磁盤的容量，所以以塊的形式存儲，可以用來存儲無論大小怎樣的文件。2、簡化存儲系統的設計。因為塊是固定的大小，計算磁盤的存儲能力就容易多了3、以塊的形式存儲不需要全部存在一個磁盤上，可以分布在各個文件系統的磁盤上，有利于復制和容錯，數據本地化計算

塊和復本在hdfs架構中分布如下圖所示：

既然namenode管理著文件系統的命名空間，維護著文件系統樹以及整顆樹內的所有文件和目錄，這些信息以文件的形式永遠的保存在本地磁盤上，分別問命名空間鏡像文件fsimage和編輯日志文件Edits。datanode是文件的工作節點，根據需要存儲和檢索數據塊，并且定期的向namenode發送它們所存儲的塊的列表。那么就知道namenode是多么的重要，一旦那么namenode掛了，那整個分布式文件系統就不可以使用了，所以對于namenode的容錯就顯得尤為重要了，hadoop為此提供了兩種容錯機制：

就是通過對那些組成文件系統的元數據持久化，分別問命名空間鏡像文件fsimage（文件系統的目錄樹）和編輯日志文件Edits（針對文件系統做的修改操作記錄）。磁盤上的映像FsImage就是一個Checkpoint,一個里程碑式的基準點、同步點,有了一個Checkpoint之后,NameNode在相當長的時間內只是對內存中的目錄映像操作,同時也對磁盤上的Edits操作,直到關機。下次開機的時候,NameNode要從磁盤上裝載目錄映像FSImage,那其實就是老的Checkpoint,也許就是上次開機后所保存的映像,而自從上次開機后直到關機為止對于文件系統的所有改變都記錄在Edits文件中;將記錄在Edits中的操作重演于上一次的映像,就得到這一次的新的映像,將其寫回磁盤就是新的Checkpoint（也就是fsImage）。但是這樣有很大一個缺點，如果Edits很大呢，開機后生成原始映像的過程也會很長，所以對其進行改進：每當 Edits長到一定程度,或者每隔一定的時間,就做一次Checkpoint，但是這樣就會給namenode造成很大的負荷，會影響系統的性能。于是就有了SecondaryNameNode的需要,這相當于NameNode的助理,專替NameNode做Checkpoint。當然,SecondaryNameNode的負載相比之下是偏輕的。所以如果為NameNode配上了熱備份,就可以讓熱備份兼職,而無須再有專職的SecondaryNameNode。所以架構圖如下圖所示：

SecondaryNameNode工作原理圖：

SecondaryNameNode主要負責下載NameNode中的fsImage文件和Edits文件，并合并生成新的fsImage文件，并推送給NameNode，工作原理如下：

1、secondarynamenode請求主namenode停止使用edits文件，暫時將新的寫操作記錄到一個新的文件中；2、secondarynamenode從主namenode獲取fsimage和edits文件（通過http get）3、secondarynamenode將fsimage文件載入內存，逐一執行edits文件中的操作，創建新的fsimage文件。4、secondarynamenode將新的fsimage文件發送回主namenode（使用http post）.5、namenode用從secondarynamenode接收的fsimage文件替換舊的fsimage文件；用步驟1所產生的edits文件替換舊的edits文件。同時，還更新fstime文件來記錄檢查點執行時間。6、最終，主namenode擁有最新的fsimage文件和一個更小的edits文件。當namenode處在安全模式時，管理員也可調用hadoop dfsadmin –saveNameSpace命令來創建檢查點。

從上面的過程中我們清晰的看到secondarynamenode和主namenode擁有相近內存需求的原因（因為secondarynamenode也把fsimage文件載入內存）。因此，在大型集群中，secondarynamenode需要運行在一臺專用機器上。

創建檢查點的觸發條件受兩個配置參數控制。通常情況下，secondarynamenode每隔一小時（有fs.checkpoint.period屬性設置）創建檢查點；此外，當編輯日志的大小達到64MB（有fs.checkpoint.size屬性設置）時，也會創建檢查點。系統每隔五分鐘檢查一次編輯日志的大小。

三、HDFS讀數據流程

HDFS讀數據流程如下圖所示：

1、客戶端通過FileSystem對象（DistributedFileSystem）的open()方法來打開希望讀取的文件。

2、DistributedFileSystem通過遠程調用（RPC）來調用namenode，獲取到每個文件的起止位置。對于每一個塊，namenode返回該塊副本的datanode。這些datanode會根據它們與客戶端的距離（集群的網絡拓撲結構）排序，如果客戶端本身就是其中的一個datanode，那么就會在該datanode上讀取數據。DistributedFileSystem遠程調用后返回一個FSDataInputStream（支持文件定位的輸入流）對象給客戶端以便于讀取數據，然后FSDataInputStream封裝一個DFSInputStream對象。該對象管理datanode和namenode的IO。

3、客戶端對這個輸入流調用read()方法，存儲著文件起始幾個塊的datanode地址的DFSInputStream隨即連接距離最近的文件中第一個塊所在的datanode，通過數據流反復調用read()方法，可以將數據從datanode傳送到客戶端。當讀完這個塊時，DFSInputStream關閉與該datanode的連接，然后尋址下一個位置最佳的datanode。

客戶端從流中讀取數據時，塊是按照打開DFSInputStream與datanode新建連接的順序讀取的。它也需要詢問namenode來檢索下一批所需塊的datanode的位置。一旦客戶端完成讀取，就對FSDataInputStream調用close()方法。

注意：在讀取數據的時候，如果DFSInputStream在與datanode通訊時遇到錯誤，它便會嘗試從這個塊的另外一個臨近datanode讀取數據。他也會記住那個故障datanode，以保證以后不會反復讀取該節點上后續的塊。DFSInputStream也會通過校驗和確認從datanode發送來的數據是否完整。如果發現一個損壞的塊， DFSInputStream就會在試圖從其他datanode讀取一個塊的復本之前通知namenode。