HDFS的工做原理

元數據管理機制

一、文件讀取過程

1.客戶端經過調用 DistributedFileSystem 的create方法，建立一個新的文件。

2.DistributedFileSystem經過RPC（遠程過程調用）調用NameNode，去建立一個沒有blocks關聯的新文件。建立前，NameNode會作各類校驗，好比文件是否存在，客戶端有無權限去建立等。若是校驗經過，NameNode就會記錄下新文件，不然就會拋出IO異常。

3.前兩步結束後會返回FSDataOutputStream的對象，和讀文件的時候類似，FSDataOutputStream被封裝成DFSOutputStream，DFSOutputStream 能夠協調 NameNode和DataNode。客戶端開始寫數據到DFSOutputStream,DFSOutputStream會把數據切成一個個小packet，而後排成隊列 data queue。

4.DataStreamer會去處理接受dataqueue，它先問詢NameNode這個新的block最適合存儲的在哪幾個DataNode裏，好比重複數是3，那麼就找到3個最適合的DataNode，把它們排成一個pipeline。DataStreamer把packet按隊列輸出到管道的第一個 DataNode 中，第一個 DataNode又把 packet 輸出到第二個 DataNode 中，以此類推。

5.DFSOutputStream 還有一個隊列叫ack ueue，也是由packet組成，等待DataNode的收到響應，當pipeline中的全部DataNode都表示已經收到的時候，這時akc queue纔會把對應的packet包移除掉。

6.客戶端完成寫數據後，調用close方法關閉寫入流。

7.DataStreamer 把剩餘的包都刷到 pipeline 裏，而後等待 ack 信息，收到最後一個 ack 後，通知 DataNode 把文件標示爲已完成。

二、文件寫入過程

一、首先調用FileSystem對象的open方法，其實獲取的是一個DistributedFileSystem的實例。

二、DistributedFileSystem經過RPC(遠程過程調用)得到文件的第一批block的locations，同一block按照重複數會返回多個locations，這些locations按照Hadoop拓撲結構排序，距離客戶端近的排在前面。

三、前兩步會返回一個FSDataInputStream對象，該對象會被封裝成DFSInputStream對象，DFSInputStream能夠方便的管理datanode和namenode數據流。客戶端調用read方法，DFSInputStream就會找出離客戶端最近的datanode並鏈接datanode。

四、數據從datanode源源不斷的流向客戶端。

五、若是第一個block塊的數據讀完了，就會關閉指向第一個block塊的datanode鏈接，接着讀取下一個block塊。這些操做對客戶端來講是透明的，從客戶端的角度來看只是讀一個持續不斷的流。

六、若是第一批block都讀完了，DFSInputStream就會去namenode拿下一批blocks的location，而後繼續讀，若是全部的block塊都讀完，這時就會關閉掉全部的流。

名詞解釋

一、NameNode

​ hdfs-site.xml的dfs.name.dir屬性

​ 是整個文件系統的管理節點。它維護着整個文件系統的文件目錄樹，文件/（根）目錄的元信息和每一個文件對應的數據塊列表。接收用戶的操做請求。

文件包括：

​ fsimage:元數據鏡像文件。存儲某一時段NameNode內存元數據信息

​ edits:操做日誌文件

​ fstime:保存最近一次checkpoint的時間

以上這些文件是保存在linux的文件系統中。

二、Bolck

​ 文件塊（block）：最基本的存儲單位。

對於文件內容而言，一個文件的長度大小是size，那麼從文件的0偏移開始，按照固定的大小，順序對文件進行劃分並編號，劃分好的每個塊稱一個Block。

​ HDFS默認Block大小是128MB，以一個256MB文件爲例，共有256/128=2個Block。

​ dfs.block.size不一樣於普通文件系統的是，HDFS中，若是一個文件小於一個數據塊的大小，並不佔用整個數據塊存儲空間Replication。

三、DataNode

​ hdfs-site.xml的dfs.replication屬性

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

​ 一個DataNode上有多個bolck——多複本。默認是三個。

四、客戶端上傳元數據

​ 一、客戶端發起寫入請求

​ 二、NN返回可用的DN

​ 三、客戶端把元數據拆分紅多個塊

​ 四、上傳第一個塊到某個DN1

​ 五、DN1向DN2發起複製請求，DN2向DN3發起複製請求，若是失敗，則由NN從新指定一個block向新的DN4發起複製請求

五、上傳元數據信息安全機制

​ 一、客戶端發起寫入請求

​ 二、把操做寫入到edits logs

​ 三、客戶端上傳文件文件，並把結果反饋給NN，NN在內存中寫入本次上傳信息

​ 四、當edits logs寫滿，則同步（flush）到 fs image文件系統中

​ 五、讀取的時候日誌以特殊的方式跟fs image合併（因此不能在NN作合併）

六、元數據存儲與讀取細節

SN的checkpoint機制

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

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

​ Namenode始終在內存中保存metedata，用於處理「讀請求」，到有「寫請求」到來時，namenode會首先寫editlog到磁盤，即向edits文件中寫日誌，成功返回後，纔會修改內存，而且向客戶端返回，Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，可是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間經過合併edits文件來更新內容。Secondary namenode就是用來合併fsimage和edits文件來更新NameNode的metedata的。