HDFS深刻淺析

1、HDFS的背景介紹

隨着數據量愈來愈大， 在 一個操做系統管轄的範圍存不下了， 那麼就 分配到更多的操做系統管理的磁盤中， 可是不方便管理和維護，迫切須要一種系統來管理多臺機器上的文件，這就是分佈式文件管理系統。

學術一點的定義就是： 分佈式文件系統是一種容許文件經過網絡在多臺主機上分享的 文件的系統，可以讓多機器上的多用戶分享文件和存儲空間。分佈式文件管理系統不少，hdfsHDFS 只是其中一種。適用於一次寫入、屢次查詢的狀況，不支持併發寫狀況，小文件不合適。由於小文件也佔用一個塊，小文件越多（1000個1k文件）塊越 多，NameNode壓力越大。

2、 HDFS的基本概念

咱們經過 hadoop shell上傳的文件是存放在 DataNode的block中， 經過 linux shell是看 不到文件的，只能看到block。 能夠一句話描述HDFS： 把客戶端的大文件存放在不少節點的數據塊中 。在這裏，出現了三個關鍵詞：文件、節點、數據塊。HDFS就是圍繞着這三個關鍵詞設計的，咱們在學習的時候也要緊抓住這三個關鍵詞來學習。

3、 HDFS的基本結構之 NameNode

1. 做用

NameNode的做用是 管理文件目錄結構，接受用戶的操做請求,是管理數據節點的。名字節點維護兩套數據， 一套 是文件 目錄與數據塊之間的關係 ， 另外一套 是 數據塊與節點之間的關係 。 前一套 數據是 靜態的 ，是存放在磁盤上的， 經過fsimage和edits文件來維護 ； 後一套 數據是 動態的 ，不持久放到到磁盤的，每當集羣啓動的時候，會自動創建這些信息，因此通常都放在內存中。

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

文件包括：

① fsimage （文件系統鏡像）:元數據鏡像文件。存儲某一時段NameNode內存 元數據信息。

② edits: 操做日誌文件。

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

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

2. 特色

<1>是一種容許文件 經過網絡在多臺主機上分享的文件系統，可以讓多機器上的多用戶分享文件和存儲空間。

<2>通透性。讓其實是經過網絡來訪問文件的動做，由程序與用戶看來，就像是訪問本地的磁盤通常。

<3>容錯。即便系統中有某些節點脫機，總體來講系統仍然能夠持續運做而不會有數據損失。

<4>適用於 一次寫入、 屢次查詢的狀況，不支持併發寫狀況，小文件不合適

3. 目錄結構

<1>既然NameNode維護這麼多的信息,那麼 這些信息都存放在哪裏呢?

在hadoop源代碼中有個文件叫作 hdfs-default.xml

<2>打開這個文件

在第149行和第158行，有兩個配置信息，一個是 dfs.name.dir， 另外一個是dfs.name.edits.dir 。這兩個文件表示的是 NameNode的核心文件fsimage和edits的存放位置，以下圖所示

在對應配置的value值有 ${}，這是 變量的表示方式，ER表達式 ，在程序讀取文件時，會把變量的值讀取出來。那麼，第150行的變量 hadoop.tmp.dir的值 (即hadoop臨時存儲路徑)，以下圖所示。

可是在咱們在上一章的配置文件 core-site.xml中， 配置的值是/usr/local/hadoop/tmp。

<3>咱們能夠進入linux文件系統

執行命令 cd /usr/local/hadoop/conf,more core-site.xml 查看，以下圖所示

能夠看出，這 兩個文件的存儲位置 是在linux文件系統的/usr/local/hadoop/tmp/dfs/name目錄下。

<4>咱們進入這個目錄

查看這個目錄的內容，以下圖所示

從圖中可知，NameNode的核心文件 fsimage和 edits的存放在current目錄下， 與此同時 name目錄下有一個文件 in_use.lock 而查看其內容的時候發現，內容爲空，也就是說只能有一個Namenode進程可以訪問該目錄，讀者能夠本身試一下，當沒有開啓hadoop時，該目錄下是沒有文件 in_use.lock 的，當hadoop啓動之後纔會生成該文件。

<5>文件 fsimage 是NameNode的核心文件

這個文件很是重要，丟失的話，Namenode沒法使用， 那麼如何防止該文件丟失而形成不良後果呢。我能夠下再次看一下hdfs-default.xml中的一段代碼，以下圖所示

由其中的描述可知，該變量，決定DFS NameNode 的NameTable(fsimage)應該在本地文件系統上的存儲位置。若是這是 一個用逗號分隔的列表的目錄，那麼nametable，會被複複製到全部的目錄中,來冗餘（備份來保證數據的安全性）。 如${hadoop.tmp.dir}/dfs/name，~/name2，~/name3，~/name4。那麼fsimage會分別複製到~/name1，~/name2，~/name3，~/name4 目錄中。因此這些目錄通常是在不一樣的機器,不一樣的磁盤，不一樣的文件夾上，總之越分散越好，這樣能保證數據的安全性。有人會問在多臺機上怎麼實現呢？其實在Linux中有nfs文件共享系統，這裏不作詳述。

<6>看一下edits的描述

查看一下 hdfs-default.xml 中的一段代碼，以下圖所示

由其中的描述可知，該變量，決定DFSNameNode的 存儲事務文件（edits）在本地文件系統上的位置。 若是這是一個以逗號分隔的目錄列表，那麼，事務文件會被複制全部的目錄中,來冗餘。默認值是dfs.name.dir同樣。（edit保存事務過程）

4、 HDFS的基本結構之 DataNode

1.做用

DataNode的做用是HDFS中真正存儲數據的。

2. block

<1>若是一個文件很是大，好比100GB，那麼怎麼存儲在DataNode中呢？DataNode在存儲數據的時候是按照block爲單位讀寫數據的。block是hdfs讀寫數據的基本單位。

<2>假設文件大小是100GB，從字節位置0開始，每64MB字節劃分爲一個block，依此類推，能夠劃分出不少的block。每一個block就是64MB大小。

2.1 咱們看一下 org.apache.hadoop.hdfs.protocol.Block類

這裏面的屬性有如下幾個，下圖所示。

由上圖可知，類中的屬性沒有一個是能夠存儲數據的。 因此block本質上是一個 邏輯概念，意味着block裏面不會真正的存儲數據，只是劃分文件的。

2.2 爲何必定要劃分爲64MB大小呢？

由於這是在默認配置文件中設置的，咱們查看 core-default.xml 文件，以下圖所示。

上圖中的參數ds.block.name指的就是block的大小，值是67 108 864字節，能夠換算爲64MB。若是咱們不但願使用64MB大小，能夠在core-site.xml中覆蓋該值。注意單位是字節。

2.3 副本

<1>副本就是備份，目的當時是爲了 安全。 正是由於集羣環境的 不可靠 ，因此才使用副本機制來保證數據的 安全性 。

<2>副本的缺點就是會佔用大量的存儲空間。副本越多，佔用的空間越多。相比數據丟失的風險，存儲空間的花費仍是值得的。

<3>那麼，一個文件有幾個副本合適呢？咱們查看hdfs-default.xml文件，以下圖所示。

從圖4.3中能夠看到，默認的副本數量是3。意味着HDFS中的每一個數據塊都有3份。固然，每一份確定會盡力分配在不一樣的DataNode服務器中。試想：若是備份的3份數據都在同一臺服務器上，那麼這臺服務器停機了，是否是全部的數據都丟了啊？

3. 目錄結構

3.1 DataNode是按block來劃分文件的

那麼劃分後的文件到底存放在哪裏哪？咱們查看文件core-default.xml，以下圖所示。

參數 dfs.data.dir的值就是 block存放在linux文件系統中的位置。變量 hadoop.tmp.dir的值 前面已經介紹了，是 /usr/local/hadoop/tmp ，那麼 dfs.data.dir 的完整路徑是/usr/local/hadoop/tmp/dfs/data。 經過linux命令查看，結果如圖4.5所示。

3.2 上傳一個文件

咱們首先點擊PieTTY打開另外一個Linux終端，上傳一個文件 jdk-6u24-linux-i586.bin，文件大小爲 84927175k，以下圖所示。

而後咱們能夠在原來終端，查看上傳文件，就是在該Linux文件系統的/usr/local/hadoop/tmp/dfs/data目錄下， 以下圖所示

上圖中以 「blk_」開頭的文件就是 存儲數據的block。這裏的命名是有規律的，除了block文件外，還有後 綴是「meta」的文件 ，這是block的源數據文件，存放一些元數據信息。所以，上圖中只有2個block文件。

注意：咱們從linux 磁盤上傳一個完整的文件到hdfs 中，這個文件在linux 是能夠看到的，可是上傳到hdfs 後，就不會有一個對應的文件存在，而是被劃分紅不少的block 存在的。並且因爲咱們的hadoop安裝方式是 僞分佈安裝 ，只有一個節點，DataNode和NameNode都在這一個節點上，因此上傳的block塊最終仍是在該Linux系統中。

5、 HDFS的基本結構之 SecondaryNode

HA的一個解決方案。但不支持熱備。配置便可。因爲數據操做越多edits文件膨脹越大，但不能讓他無限的膨脹下去，因此要把日誌過程轉換出來 放到fsimage中。因爲NameNode要接受用戶的操做請求，必須可以快速響應用戶請求，爲了保證NameNode的快速響應給用戶，因此將此項工 做交給了 SecondaryNode ，因此他也備份一部分fsimage的一部份內容。

執行過程：從NameNode上 下載元數據信息（fsimage,edits），而後把兩者合併，生成新的fsimage，在本地保存，並將其推送到NameNode，同時重置NameNode的edits.默認在安裝在NameNode節點上，但這樣...不安全！

合併原理 以下圖所示。

免費提供最新Linux技術教程書籍，爲開源技術愛好者努力作得更多更好：http://www.linuxprobe.com/