HDFS架構和原理

HDFS版本

 

Hdfs的版本基本是對應hadooop的版本，瞭解hadoop的版本歷程簡介也就是了解HDFS的版本歷程，簡而言之，hadoop的大版本歷程以下：

 

• Hadoop1.x

• Hadoop2.x

• Hadoop3.x

 

其中hadoop2.x是目前大部分企業在使用的版本，hadoop1.x基本不多新項目會考慮使用這個版本，hadoop3.x是將來更多新項目會考慮使用的一個版本，這裏要注意，不一樣的hadoop版本存在蠻大的區別，在咱們查閱網絡資料或官方文檔時都要額外注意，要找到對於的版本進行學習。在沒有特別版本說明的狀況下，本人編寫任何關於hadoop的文章都是基於hadoop3進行的。

 

理解hadoop平臺

 

怎麼去理解hadoop平臺，爲何一提到大數據大多數開發都知道有個hadoop平臺，首先咱們來訪問最新hadoop官方文檔的網站：

https://hadoop.apache.org

 

 

 

咱們重點關注Modules部分，能夠看到，其實hadoop核心也就只有5個模塊：

 

• Hadoop Common: 支持其餘Hadoop模塊的公共應用程序

• Hadoop Distributed File System (HDFS™): 分佈式文件系統

• Hadoop YARN: 工做調度和集羣資源管理框架

• Hadoop MapReduce: 基於YARN的一個計算框架

• Hadoop Ozone: 對象存儲框架

 

其實真正使用最多的只有3個：

 

• HDFS

• YARN

• MAPREDUCE

 

爲何hadoop底層只有這3個模塊就能夠打遍天下，號稱爲hadoop平臺呢？緣由在於：hadoop率先提供了大數據須要的底層基礎組件HDFS存儲、YARN資源管理和調度、MR離線計算，後來的其它框架基本都是基於這3個進行封裝的，例如hive、hbase、spark等。

 

HDFS架構和原理

 

先扔一張hadoop官方提供的HDFS的架構圖：

 

 

這個圖基本詮釋了HDFS的總體架構和原理，理解這個圖基本就理解了HDFS的原理，下面咱們就基於這個架構圖來展開分析HDFS的架構和原理。

 

Blocks（塊）

 

HDFS是爲了解決大數據存儲的一個hadoop組件，大數據的特色就是數據量大，這就有可能出現單個文件就達到TB級別，那麼如今咱們思考一個問題，一個1TB的文件，如何在現有常規的服務器保存？

 

 

 

HDFS是這麼去解決這個問題的，首先作大數據存儲一臺服務器確定是不夠的，因此須要集羣不少的服務器組成一個邏輯上的大磁盤進行存儲，將任何須要存儲的文件物理切割爲固定大小的塊，塊的大小能夠配置（dfs.blocksize），默認是128M（hadoop1.x默認是64M），這些塊散落分佈在1臺或多臺服務器節點上，這就解決了單個TB級別文件的存儲問題。

 

 

塊大小的配置頗有講究，配置過小，會增長磁盤尋址開銷，同時會增長NameNode的內存消耗，這點後面會講到。那麼問題來了，若是咱們存儲都是小文件好比幾十MB，那麼一個塊就128M，會不會存在磁盤浪費的狀況呢？根據Hadoop權威指南給出的說法是這樣的：

當一個1MB的文件存儲在一個128MB的塊中時，文件只使用1MB的磁盤空間，而不是128MB。

 

注意：

 

一、同一個文件塊大小是相同的（最後一個塊除外），不一樣的文件塊大小能夠不相同。

二、文件內容只能寫入一次，寫入後不能修改，可是能夠追加。

三、因爲文件按配置塊大小被物理切分，那麼就存在數據完整性問題，好比hello由於單詞的hel和lo分別被切分都兩個塊中，爲了保證讀取數據的完整性，mapreduce解決方式是每開始讀取一個塊時，都跳過第一行數據，而每一個塊讀取結束時，都會繼續讀取第二個塊的第一行。

四、塊在磁盤中以一個個小文件的方式進行保存。保存的目錄是由塊所在節點自動肯定和建立的。

 

名稱節點（NameNode）和數據節點（DataNode）

 

HDFS集羣中有兩個核心角色：DataNode和NameNode，HDFS集羣實際上也是一主（NameNode）多從（DataNode）的架構。DataNode角色的節點是真正存放塊（block）數據的節點，當DataNode啓動時，它將掃描其本地文件系統，生成與每一個本地文件相對應的全部HDFS數據塊的列表，並將此報告發送到NameNode。該報告稱爲Blockreport。

 

NameNode管理文件系統的命名空間，它維護着文件系統樹及整棵樹內全部的文件和目錄，

這些信息經過：命名空間鏡像文件和編輯日誌文件兩種方式被永久保存在NameNode節點服務器磁盤上面。其中命名空間鏡像文件保存整個文件系統的目錄樹，編輯日誌文件記錄文件系統元數據發生的全部更改。

 

另外NameNode內存中還保存着DataNode上報的每一個文件中各個塊所在的數據節點信息，爲了提高NameNode的被訪問效率，同時會按期從磁盤加載命名空間到內存中保存一分內存鏡像，當客戶端須要讀取某個文件數據時，首先訪問NameNode，從NameNode內存讀取文件塊列表或塊對應的DataNode列表，而後再訪問塊對應的DataNode直接從DataNode中讀取數據。

 

若是NameNode不可用，那麼等同於整個HDFS文件系統不可用，若是NameNode因爲故障致使磁盤數據丟失，那麼等同於整個HDFS文件系統數據丟失，若是NameNode塊映射關係的內存爆滿，那麼等同於整個HDFS文件系統沒法再繼續存儲，換句話說，NameNode內存決定了HDFS可以存儲的塊數量，根據經驗值，每一個文件、目錄和數據塊的存儲信息大約佔 150 字節。

 

NameNode高可用

 

爲了保證讀寫數據一致性，HDFS集羣設計爲只能有一個狀態爲Active的NameNode,這樣就致使NameNode存在單點故障，官方提供了兩種方式來解決這個問題：

 

• QJM（推薦）：經過同步編輯事務日誌的方式備份命名空間數據，同時須要DataNode向全部NameNode上報塊列表信息。還能夠配置ZKFC組件實現故障自動轉移。

• NFS：將須要持久化的數據寫入本地磁盤的同時寫入一個遠程掛載的網絡文件系統作爲備份。

 

是經過增長一個備用NameNode節點，這個備用的節點平時不工做，處於備用Standby的狀態，這樣就同時運行兩個狀態的節點，這兩個節點狀態分別是：Active和Standby。

咱們知道，NameNode主要保存文件系統目錄樹信息和塊映射關係，爲了保證備用節點可以隨時頂替上去，因此Standby節點須要定時同步Active節點的事務日誌來更新本地的文件系統目錄樹信息，同時DataNode須要配置全部NameNode的位置，並向全部狀態的NameNode發送塊列表信息和心跳。

注意，同步事務日誌來更新目錄樹這個工做交給了一個叫JournalNode的獨立守護進程來完成，簡稱爲QJM，一個NameNode對應一個QJM進程，當Active節點執行任何命名空間文件目錄樹修改時，它會將修改記錄持久化到大多數QJM中，Standby節點從QJM中監聽並讀取編輯事務日誌內容，並將編輯日誌應用到本身的命名空間。發生故障轉移時，Standby節點將確保在將自身提高爲Active狀態以前，從QJM讀取全部編輯內容。

 

注意，QJM只是實現了數據的備份，當Active節點發送故障時，須要手工提高Standby節點爲Active節點。若是要實現NameNode故障自動轉移，則須要配套ZKFC組件來實現，ZKFC也是獨立運行的一個守護進程，基於zookeeper來實現選舉和自動故障轉移。

 

塊副本（Replication）和放置策略

 

每個文件能夠配置副本數量，默認是3，副本的做用是防止因某個DataNode掛掉或磁盤損壞而致使數據丟失，除此以外塊副本還能夠提升塊可讀取的節點，提升mapreduce計算任務向數據移動的機率。

 

由於同一個DataNode放置相同的塊數據是沒有意義的，因此NameNode不容許DataNode具備同一塊的多個副本，換句話說副本數量配置不能大於DataNode節點的數量。

 

每一個文件能夠在寫入時指定這個文件塊的副本數量，也能夠在將來修改某個文件的塊副本數量，文件塊的副本數量配置做爲塊元數據的一部分保存在NameNode中。

 

因爲NameNode能夠獲取每一個DataNode所屬的機架ID，而且塊副本數量配置信息保存在NameNode中，因此塊的副本放置策略是由NameNode決定好返回給客戶端的，副本放置策略簡單總結一句話爲：三分之一的副本位於寫入器所在的節點上，三分之二的副本位於寫入器所在的同一個機架上，其他三分之一則平均分佈在其他機架上。若是副本數大於3個，則隨機肯定其它的副本位置，通常副本數量配置爲3個是比較理想的。

 

當修改某個文件的塊副本數量時，NameNode將從新根據策略複製或減小塊副本。當某個DataNode超過必定的時間（默認10分鐘）沒有上報心跳給NameNode,NameNode將認爲該DataNode不可用，將不會分配塊寫入到這個DataNode中，原來分配在這個DataNode的塊副本將會從新在其它可用的DataNode上覆制。

 

HDFS聯邦

 

雖然HDFS HA解決了「單點故障」問題，可是在系統擴展性、總體性能和隔離性方面仍然存在問題。

（1）   系統擴展性方面，元數據存儲在NN內存中，受內存上限的制約。

（2）   總體性能方面，吞吐量受單個NN的影響。

（3）   隔離性方面，一個程序可能會影響其餘運行的程序，如一個程序消耗過多資源致使其餘程序沒法順利運行。HDFS HA本質上仍是單名稱節點。HDFS聯邦能夠解決以上三個方面問題。

 

 

在HDFS聯邦中，設計了多個相互獨立的NN，使得HDFS的命名服務可以水平擴展，這些NN分別進行各自命名空間和塊的管理，不須要彼此協調。每一個DN要向集羣中全部的NN註冊，並週期性的發送心跳信息和塊信息，報告本身的狀態。

HDFS聯邦擁有多個獨立的命名空間，其中，每個命名空間管理屬於本身的一組塊，這些屬於同一個命名空間的塊組成一個「塊池」。每一個DN會爲多個塊池提供塊的存儲，塊池中的各個塊其實是存儲在不一樣DN中的。

 

磁盤平衡器

 

在HDFS中，DataNode 將數據塊存儲到本地文件系統目錄中，具體的目錄能夠經過配置 hdfs-site.xml 裏面的 dfs.datanode.data.dir 參數。在典型的安裝配置中，通常都會配置多個目錄，而且把這些目錄分別配置到不一樣的設備上，好比分別配置到不一樣的HDD(HDD的全稱是Hard Disk Drive)和SSD(全稱Solid State Drives，就是咱們熟悉的固態硬盤)上。

 

當咱們往HDFS上寫入新的數據塊，DataNode 將會使用volume選擇策略來爲這個塊選擇存儲的地方。目前Hadoop支持兩種volume選擇策略：round-robin 和 available space(詳情參見：HDFS-1804)，咱們能夠經過 dfs.datanode.fsdataset.volume.choosing.policy 參數來設置。

循環(round-robin)策略將新塊均勻分佈在可用磁盤上;而可用空間( available-space )策略優先將數據寫入具備最大可用空間的磁盤(經過百分比計算的)。正以下圖所示：

 

默認狀況下，DataNode 是使用基於round-robin策略來寫入新的數據塊。然而在一個長時間運行的集羣中，因爲HDFS中的大規模文件刪除或者經過往DataNode 中添加新的磁盤仍然會致使同一個DataNode中的不一樣磁盤存儲的數據很不均衡。即便你使用的是基於可用空間的策略，卷(volume)不平衡仍可致使較低效率的磁盤I/O。好比全部新增的數據塊都會往新增的磁盤上寫，在此期間，其餘的磁盤會處於空閒狀態，這樣新的磁盤將會是整個系統的瓶頸。

 

Diskbalancer是一個命令行工具，能夠在datanode的全部磁盤上均勻分配數據。此工具與Balancer不一樣， 後者負責集羣範圍的數據平衡。因爲多種緣由，數據在節點上的磁盤之間可能存在不均勻的擴散。這多是因爲大量寫入和刪除或因爲磁盤更換形成的。此工具針對給定的datanode運行，並將塊從一個磁盤移動到另外一個磁盤。

 

 

---------------------- 正文結束 ------------------------