HDFS該如何理解

本篇文章給大家分享的是有關HDFS該如何理解，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

Hadoop分布式文件系統(HDFS)被設計成適合運行在通用硬件(commodity hardware)上的分布式文件系統。HDFS采用了主從（Master/Slave）結構模型，一個HDFS集群是由一個NameNode和若干個DataNode組成的。

一、HDFS的背景介紹

隨著數據量越來越大， 在 一個操作系統管轄的范圍存不下了， 那么就 分配到更多的操作系統管理的磁盤中， 但是不方便管理和維護，迫切需要一種系統來管理多臺機器上的文件，這就是分布式文件管理系統。

學術一點的定義就是： 分布式文件系統是一種允許文件通過網絡在多臺主機上分享的 文件的系統，可讓多機器上的多用戶分享文件和存儲空間。分布式文件管理系統很多，hdfsHDFS 只是其中一種。適用于一次寫入、多次查詢的情況，不支持并發寫情況，小文件不合適。因為小文件也占用一個塊，小文件越多（1000個1k文件）塊越 多，NameNode壓力越大。

二、 HDFS的基本概念

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

三、 HDFS的基本結構之 NameNode

1. 作用

NameNode的作用是 管理文件目錄結構，接受用戶的操作請求,是管理數據節點的。名字節點維護兩套數據， 一套 是文件 目錄與數據塊之間的關系 ， 另一套 是 數據塊與節點之間的關系 。 前一套 數據是 靜態的 ，是存放在磁盤上的， 通過fsimage和edits文件來維護 ； 后一套 數據是 動態的 ，不持久放到到磁盤的，每當集群啟動的時候，會自動建立這些信息，所以一般都放在內存中。

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

文件包括：

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

② edits: 操作日志文件。

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

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

2. 特點

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

通透性。讓實際上是通過網絡來訪問文件的動作，由程序與用戶看來，就像是訪問本地的磁盤一般。

容錯。即使系統中有某些節點脫機，整體來說系統仍然可以持續運作而不會有數據損失。

適用于 一次寫入、 多次查詢的情況，不支持并發寫情況，小文件不合適

3. 目錄結構

既然NameNode維護這么多的信息,那么 這些信息都存放在哪里呢?

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

打開這個文件

在第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。

我們可以進入linux文件系統

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

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

我們進入這個目錄

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

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

文件 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文件共享系統，這里不做詳述。

看一下edits的描述

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

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

四、 HDFS的基本結構之 DataNode

1.作用

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

2. block

如果一個文件非常大，比如100GB，那么怎么存儲在DataNode中呢？DataNode在存儲數據的時候是按照block為單位讀寫數據的。block是hdfs讀寫數據的基本單位。

假設文件大小是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 副本

副本就是備份，目的當時是為了 安全。 正是因為集群環境的 不可靠 ，所以才使用副本機制來保證數據的 安全性 。

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

那么，一個文件有幾個副本合適呢？我們查看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系統中。

五、 HDFS的基本結構之 SecondaryNode

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

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

合并原理 如下圖所示。

HDFS有著高容錯性（fault-tolerant）的特點，并且設計用來部署在低廉的（low-cost）硬件上。而且它提供高吞吐量（high throughput）來訪問應用程序的數據。

以上就是HDFS該如何理解，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。