Table of Contents

HDFS

儲存模型

架構模型 

副本佈置

總結

​

Hadoop簡介 

HDFS

儲存模型

解釋 ： 已上傳的Block大小不可改變的原因是每個Block大小一致，改變一個其他也會跟著改變，並且改變一個其它的偏移量也會改變，這是一個很消耗cpu的過程，Hadoop的目的就是節省出儲存模型對cpu的消耗，從而更多用於檔案計算上面。

至於可以追加資料的原因是 追加會導致 原本檔案增加，又由於每塊大小已經定了下來，所以只需增加一個或多個block即可解決。

其中預設的 Block 大小為 128MB ， 副本數為3 ，其中每個副本分別在不同的計算機上，每臺計算機上不允許出現相同的副本。

架構模型 

看下圖更好理解

 解釋 :  我們原本有一個很大的檔案 ， 然後將它分成很多部分，每一個部分被稱為一個塊，每一個塊又儲存在不同的計算機上，這些儲存塊的計算機就被稱為DataNode，此時還有一臺計算機並沒有儲存塊，而是儲存了哪個塊儲存在了哪臺計算機上面，這個被稱為NameNode。當客戶端儲存資料或者獲取資料時都會先去訪問 NameNode ，獲得 將資料儲存到哪臺計算機或 從哪臺計算機上獲取資料 的資訊，這個資訊被稱為元資料，其實就是屬性包括塊的儲存位置、偏移量等等。然後會根據這個資訊。HDFSClient 會去找指定的 DataNode。

NameNode

可能有人會認為 不會和磁碟發生交換又怎麼持久化呢？

執行時有 記憶體和磁碟的雙向互動才叫交換。

持久化：執行時往磁碟寫，down機以後再重新啟動會從磁碟讀回，從而恢復記憶體。

當我們分配角色 在啟動服務之前會有一次格式化，在這次格式化時，會第一次建立 名為fsimage的空目錄，然後當開啟服務以後，會分別從fsimage 和 edits 中讀取內容， 顯然由於第一次啟動服務，這兩個都是空目錄。

當開啟服務以後，NameNode會去讀取fsimage和edits ， 讀到記憶體當中進行合併，然後重新寫入一個fsimage到磁碟當中。 

然後每隔指定的時間 會自動將 fsimage 和 edits 合併，並重新寫入新的fsimage。這裡 的 fsimage 與 edits 合併實際上是在另外一臺機器上完成的，並不會影響 NameNode這臺機器的工作。當 NameNode   down機後，再次開啟服務又會重新 讀取fsimage，恢復最近一次的 metadata資訊，同時 讀取edits檔案執行 最近一次儲存metadata與down機這段時間的使用者進行的操作。 剛才說的在 另外一臺機器上完成的 這臺機器就是 Secondary  NameNode

DataNode 

上圖的 其上 含義 為：其它副本上 cp 一份到 其他DN

HDFS的優缺點

副本佈置

官方推薦3個副本，場景是有多個機架，第一個副本在一個機架，第二個副本在另外一個機架上，第三個副本與第二個副本同機架，目的是預防整個機架癱瘓。官方說明是  第一個和第二個在同一個機架，第三個在另外一個機架，但原始碼與其描述不符。

HDFS讀寫流程

Pipeline : 上圖中的 4 ，這條路線是一個管道，每一個block預設是128M，在傳輸的過程中會被切成更小的塊64k，然後進行傳輸，很快一個64k的塊就能夠從FSData OutputStream 傳遞到 DataNode，此時會繼續向下傳遞，建立副本，從而試第一個DataNode空閒出來，這時FSData OutputStream 又可以傳送第二個64k的塊。

第一個block傳輸完畢以後，DataNode會向namenode傳送資訊，告知自身的儲存資訊，之後client再上傳其他block時就可以進行分配。

 讀取資料時，優先順序為  本機datanode  > 本機架 datanode > 其他機架   ， 一般情況如果在其它機架都會經歷3個交換機。

總結