概覽html
首先咱們來認識一下HDFS, HDFS(Hadoop Distributed File System )Hadoop分佈式文件系統。它實際上是將一個大文件分紅若干塊保存在不一樣服務器的多個節點中。經過聯網讓用戶感受像是在本地同樣查看文件,爲了下降文件丟失形成的錯誤,它會爲每一個小文件複製多個副本(默認爲三個),以此來實現多機器上的多用戶分享文件和存儲空間。node
HDFS特色:linux
① 保存多個副本,且提供容錯機制,副本丟失或宕機自動恢復。默認存3份。安全
② 運行在廉價的機器上。服務器
③ 適合大數據的處理。由於小文件也佔用一個塊,小文件越多(1000個1k文件)塊越 多,NameNode壓力越大。網絡
如:將一個大文件分紅三塊A、B、C的存儲方式分佈式
PS:數據複製原則:oop
除了最後一個塊以外的文件中的全部塊都是相同的大小。大數據
HDFS的放置策略:日誌
是將一個副本放在本地機架中的一個節點上,另外一個位於不一樣(遠程)機架中的節點上,而最後一個位於不一樣節點上遠程機架。
涉及到的屬性:
塊大小:Hadoop1版本里默認爲64M,Hadoop2版本里默認爲128M
複製因子:每一個文件加上其文件副本的份數
HDFS的基本結構
如上圖所示,HDFS基本結構分NameNode、SecondaryNameNode、DataNode這幾個。
NameNode:是Master節點,有點相似Linux裏的根目錄。管理數據塊映射;處理客戶端的讀寫請求;配置副本策略;管理HDFS的名稱空間;
SecondaryNameNode:保存着NameNode的部分信息(不是所有信息NameNode宕掉以後恢復數據用),是NameNode的冷備份;合併fsimage和edits而後再發給namenode。(防止edits過大的一種解決方案)
DataNode:負責存儲client發來的數據塊block;執行數據塊的讀寫操做。是NameNode的小弟。
熱備份:b是a的熱備份,若是a壞掉。那麼b立刻運行代替a的工做。
冷備份:b是a的冷備份,若是a壞掉。那麼b不能立刻代替a工做。可是b上存儲a的一些信息,減小a壞掉以後的損失。
fsimage:元數據鏡像文件(文件系統的目錄樹。)
edits:元數據的操做日誌(針對文件系統作的修改操做記錄)
namenode內存中存儲的是=fsimage+edits。
NameNode詳解
做用:
Namenode起一個統領的做用,用戶經過namenode來實現對其餘數據的訪問和操做,相似於root根目錄的感受。
Namenode包含:目錄與數據塊之間的關係(靠fsimage和edits來實現),數據塊和節點之間的關係
fsimage文件與edits文件是Namenode結點上的核心文件。
Namenode中僅僅存儲目錄樹信息,而關於BLOCK的位置信息則是從各個Datanode上傳到Namenode上的。
Namenode的目錄樹信息就是物理的存儲在fsimage這個文件中的,當Namenode啓動的時候會首先讀取fsimage這個文件,將目錄樹信息裝載到內存中。
而edits存儲的是日誌信息,在Namenode啓動後全部對目錄結構的增長,刪除,修改等操做都會記錄到edits文件中,並不會同步的記錄在fsimage中。
而當Namenode結點關閉的時候,也不會將fsimage與edits文件進行合併,這個合併的過程其實是發生在Namenode啓動的過程當中。
也就是說,當Namenode啓動的時候,首先裝載fsimage文件,而後在應用edits文件,最後還會將最新的目錄樹信息更新到新的fsimage文件中,而後啓用新的edits文件。
整個流程是沒有問題的,可是有個小瑕疵,就是若是Namenode在啓動後發生的改變過多,會致使edits文件變得很是大,大得程度與Namenode的更新頻率有關係。
那麼在下一次Namenode啓動的過程當中,讀取了fsimage文件後,會應用這個無比大的edits文件,致使啓動時間變長,而且不可控,可能須要啓動幾個小時也說不定。
Namenode的edits文件過大的問題,也就是SecondeNamenode要解決的主要問題。
SecondNamenode會按照必定規則被喚醒,而後進行fsimage文件與edits文件的合併,防止edits文件過大,致使Namenode啓動時間過長。
DataNode詳解
DataNode在HDFS中真正存儲數據。
首先解釋塊(block)的概念:
SecondaryNode
執行過程:從NameNode上 下載元數據信息(fsimage,edits),而後把兩者合併,生成新的fsimage,在本地保存,並將其推送到NameNode,同時重置NameNode的edits.
工做原理(轉自「大牛筆記」的博客,因爲實現是清晰,受益很大,在此不作改動)
寫操做:
有一個文件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>以此類推,如圖紅線實線所示,直到將block1發送完畢。
6>host2,host1,host3向NameNode,host2向Client發送通知,說「消息發送完了」。如圖粉紅顏色實線所示。
7>client收到host2發來的消息後,向namenode發送消息,說我寫完了。這樣就真完成了。如圖黃色粗實線
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上的數據,放到其餘節點去。讀取時,要讀其餘節點去。
③掛掉一個節點,不要緊,還有其餘節點能夠備份;甚至,掛掉某一個機架,也不要緊;其餘機架上,也有備份。
讀操做:
讀操做就簡單一些了,如圖所示,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。那麼讀取的時候,遵循的規律是:
優選讀取本機架上的數據。
運算和存儲在同一個服務器中,每個服務器均可以是本地服務器
補充
元數據
元數據被定義爲:描述數據的數據,對數據及信息資源的描述性信息。(相似於Linux中的i節點)
以 「blk_」開頭的文件就是 存儲數據的block。這裏的命名是有規律的,除了block文件外,還有後 綴是「meta」的文件 ,這是block的源數據文件,存放一些元數據信息。
數據複製
NameNode作出關於塊複製的全部決定。它週期性地從集羣中的每一個DataNode接收到一個心跳和一個阻塞報告。收到心跳意味着DataNode正常運行。Blockreport包含DataNode上全部塊的列表。
參考文獻:
http://www.cnblogs.com/laov/p/3434917.html
https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/
http://www.cnblogs.com/linuxprobe/p/5594431.html