Hadoop技術分享:HDFS概念普及版

hadoop

Hadoop 是 Apache 旗下的一個用 java 語言實現開源軟件框架,是一個開發和運行處理大規模數據的軟件平臺。允許使用簡單的編程模型在大量計算機集群上對大型數據集進行分佈式處理。

它的核心組件有:

HDFS(分佈式文件系統):解決海量數據存儲

YARN(作業調度和集群資源管理的框架):解決資源任務調度

MAPREDUCE(分佈式運算編程框架):解決海量數據計算

Hadoop技術分享:HDFS概念普及版

當下的 Hadoop 已經成長為一個龐大的體系,隨著生態系統的成長,新出現的項目越來越多,其中不乏一些非 Apache 主管的項目,這些項目對 HADOOP 是很好的補充或者更高層的抽象

存儲介紹

在現代的企業環境中,單機容量往往無法存儲大量數據,需要跨機器存儲。統一管理分佈在集群上的文件系統稱為分佈式文件系統。而一旦在系統中,引入網絡,就不可避免地引入了所有網絡編程的複雜性,例如挑戰之一是如果保證在節點不可用的時候數據不丟失。

傳統的網絡文件系統(NFS)雖然也稱為分佈式文件系統,但是其存在一些限制。由於NFS中,文件是存儲在單機上,因此無法提供可靠性保證,當很多客戶端同時訪問NFS Server時,很容易造成服務器壓力,造成性能瓶頸。另外如果要對NFS中的文件進行操作,需要首先同步到本地,這些修改在同步到服務端之前,其他客戶端是不可見的。某種程度上,NFS不是一種典型的分佈式系統,雖然它的文件的確放在遠端(單一)的服務器上面。

HDFS,是Hadoop Distributed File System的簡稱,是Hadoop抽象文件系統的一種實現。Hadoop抽象文件系統可以與本地系統、Amazon S3等集成,甚至可以通過Web協議(webhsfs)來操作。HDFS的文件分佈在集群機器上,同時提供副本進行容錯及可靠性保證。例如客戶端寫入讀取文件的直接操作都是分佈在集群各個機器上的,沒有單點性能壓力。

HDFS設計原則

HDFS設計之初就非常明確其應用場景,適用與什麼類型的應用,不適用什麼應用,有一個相對明確的指導原則。

1.1 設計目標

存儲非常大的文件:這裡非常大指的是幾百M、G、或者TB級別。實際應用中已有很多集群存儲的數據達到PB級別。根據Hadoop官網,Yahoo!的Hadoop集群約有10萬顆CPU,運行在4萬個機器節點上。

採用流式的數據訪問方式: HDFS基於這樣的一個假設:最有效的數據處理模式是一次寫入、多次讀取數據集經常從數據源生成或者拷貝一次,然後在其上做很多分析工作

分析工作經常讀取其中的大部分數據,即使不是全部。 因此讀取整個數據集所需時間比讀取第一條記錄的延時更重要。

·

運行於商業硬件上: Hadoop不需要特別貴的、reliable的(可靠的)機器,可運行於普通商用機器(可以從多家供應商採購) ,商用機器不代表低端機器。在集群中(尤其是大的集群),節點失敗率是比較高的HDFS的目標是確保集群在節點失敗的時候不會讓用戶感覺到明顯的中斷。

HDFS不適合的應用類型

有些場景不適合使用HDFS來存儲數據。下面列舉幾個:

1) 低延時的數據訪問

對延時要求在毫秒級別的應用,不適合採用HDFS。HDFS是為高吞吐數據傳輸設計的,因此可能犧牲延時HBase更適合低延時的數據訪問。

2)大量小文件

文件的元數據(如目錄結構,文件block的節點列表,block-node mapping)保存在NameNode的內存中, 整個文件系統的文件數量會受限於NameNode的內存大小。

經驗而言,一個文件/目錄/文件塊一般佔有150字節的元數據內存空間。如果有100萬個文件,每個文件佔用1個文件塊,則需要大約300M的內存。因此十億級別的文件數量在現有商用機器上難以支持。

3)多方讀寫,需要任意的文件修改

HDFS採用追加(append-only)的方式寫入數據。不支持文件任意offset的修改。不支持多個寫入器(writer)。

HDFS核心概念

HDFS角色

HDFS也是按照Master和Slave的結構。分NameNode、SecondaryNameNode、DataNode這幾個角色;

NameNode:是Master節點,是大領導。管理數據塊映射;處理客戶端的讀寫請求;配置副本策略;管理HDFS的名稱空間;

SecondaryNameNode:是一個小弟,分擔大哥namenode的工作量;是NameNode的冷備份;合併fsimage和fsedits然後再發給namenode;

熱備份:b是a的熱備份,如果a壞掉。那麼b馬上運行代替a的工作。

冷備份:b是a的冷備份,如果a壞掉。那麼b不能馬上代替a工作。但是b上存儲a的一些信息,減少a壞掉之後的損失。

fsimage:元數據鏡像文件(文件系統的目錄樹。)

edits:元數據的操作日誌(針對文件系統做的修改操作記錄)

DataNode:Slave節點,奴隸,幹活的。負責存儲client發來的數據塊block;執行數據塊的讀寫操作。

寫數據工作原理

Hadoop技術分享:HDFS概念普及版

有一個文件FileA,100M大小。Client將FileA寫入到HDFS上。

HDFS按默認配置。

HDFS分佈在三個機架上Rack1,Rack2,Rack3。

a. Client將FileA按64M分塊。分成兩塊,block1和Block2;

b. Client向nameNode發送寫數據請求,如圖①------>。

c. NameNode節點,記錄block信息。並返回可用的DataNode,如②--------->。

Block1: host2,host1,host3

Block2: host7,host8,host4

原理:

NameNode具有RackAware機架感知功能,這個可以配置。

若client為DataNode節點,那存儲block時,規則為:副本1,同client的節點上;副本2,不同機架節點上;副本3,同第二個副本機架的另一個節點上;其他副本隨機挑選。

若client不為DataNode節點,那存儲block時,規則為:副本1,隨機選擇一個節點上;副本2,不同副本1,機架上;副本3,同副本2相同的另一個節點上;其他副本隨機挑選。

d. client向DataNode發送block1;發送過程是以流式寫入。

流式寫入過程,

1>將64M的block1按64k的package劃分;

2>然後將第一個package發送給host2;

3>host2接收完後,將第一個package發送給host1,同時client想host2發送第二個package;

4>host1接收完第一個package後,發送給host3,同時接收host2發來的第二個package。

5>以此類推,如圖紅線實線RACK1(host3)->RACK2(host1)->RACK2(host3)所示,直到將block1發送完畢。

6>host2,host1,host3向NameNode,host2向Client發送通知,說“消息發送完了”。如圖粉紅顏色RACK2(host3)->RACK2(host1)->RACK1(host3)實線所示彙報給nn。

7>client收到host2發來的消息後,向namenode發送消息,說我寫完了。這樣就真完成了。如圖block1,block2

8>發送完block1後,再向host7,host8,host4發送block2,如圖藍色實線所示。

9>發送完block2後,host7,host8,host4向NameNode,host7向Client發送通知,如圖淺綠色實線所示。

10>client向NameNode發送消息,說我寫完了,如圖黃色粗實線。。。這樣就完畢了。

分析:通過寫過程,我們可以瞭解到:

寫1T文件,我們需要3T的存儲,3T的網絡流量貸款。

在執行讀或寫的過程中,NameNode和DataNode通過HeartBeat進行保存通信,確定DataNode活著。如果發現DataNode死掉了,就將死掉的DataNode上的數據,放到其他節點去。讀取時,要讀其他節點去。

掛掉一個節點,沒關係,還有其他節點可以備份;甚至,掛掉某一個機架,也沒關係;其他機架上,也有備份。

讀數據工作原理

Hadoop技術分享:HDFS概念普及版

讀操作就簡單一些了,如圖所示,client要從datanode上,讀取FileA。而FileA由block1和block2組成。

那麼,讀操作流程為:

a. client向namenode發送讀請求。

b. namenode查看Metadata信息,返回fileA的block的位置。

block1:host2,host1,host3

block2:host7,host8,host4

c. block的位置是有先後順序的,先讀block1,再讀block2。而且block1去host2上讀取;然後block2,去host7上讀取;

上面例子中,client位於機架外,那麼如果client位於機架內某個DataNode上,例如,client是host6。那麼讀取的時候,遵循的規律是:

優選讀取本機架上的數據

相關推薦

推薦中...