大数据系列文章-Hadoop的HDFS读写流程(二)
生活随笔
收集整理的這篇文章主要介紹了
大数据系列文章-Hadoop的HDFS读写流程(二)
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
在介紹HDFS讀寫流程時,先介紹下Block副本放置策略。
Block副本放置策略
- 第一個副本:放置在上傳文件的DataNode;如果是集群外提交,則隨機挑選一臺磁盤不太滿,CPU不太忙的節點。
- 第二個副本:放置在與第一個副本不同的機架的節點上。
- 第三個副本:與第二個副本相同機架的節點。
- 更多副本:隨機節點。
HDFS寫流程
- 客戶端發請求給NameNode,我想保存一個文件A,這時候在NameNode會有一個標識,標識為A_copy(文件不可用)。
- 根據副本放置策略,返回三個副本的可放置位置列表,且默認為sort排好順序的。
- 客戶端主動去和離自己最近的DataNode連接(暫且叫DN1),然后DN1后續的DN2進行連接,DN2在和DN3進行連接。(串聯方式Pipeline)
- 客戶端讀取源文件,對該Block進行更小的切割,
- 第一次:傳遞第一個Block中的第一個小包給DN1。
- 第二次:傳遞第一個Block中的第二個小包給DN1,與此同時,DN1中的第一個小包傳遞給DN2。
- 第三次:傳遞第一個Block中的第三個小包給DN1,與此同時,DN1中的第二個小包傳遞給DN2,DN2傳遞第一個小包給DN3.
- 依次類推
(Block切割更小的小包,這里這么設計的好處是時間不重疊。如果不切,一次性傳遞例如64M,當傳遞DN1時,等待,傳遞DN2時,繼續等待,傳遞DN3時,還在等,造成時間浪費。另外的一個好處時,如果增加節點,時間影響不大)
- 最后通過DataNode與NameNode心跳,通知是否文件徹底傳遞完畢,補全NameNode中元數據的位置信息。
HDFS讀流程
- 客戶端發請求給NameNode,NameNode將這個文件的元數據找到,告知給客戶端(例如文件A,被切割為5個Block,元文件會紀錄Block1:DN1,DN2,DN3,Block2:DN1,DN4,DN5等等依次類推)
- 客戶端直接向DataNode請求Block數據(遵循距離優先)
- 當把所有的Block下載回本地后,進行驗證每個Block元信息的MD5。如果每個Block都是正確的,沒有被破壞,開始進行拼接,最終文件就被還原回來了。
HDFS文件權限
- 與Linux文件權限類似
- r:read;w:write;x:execute
- 權限x對應文件忽略,對于文件夾表示是否允許訪問其內容
- 如果Linux系統用戶zhangyongli使用Hadoop命名創建一個文件,那么這個文件在HDFS中owner就是zhangyongli
- HDFS的權限目的,阻止好人做錯事,而不是阻止壞人做壞事。HDFS相信,你告訴我你是誰,我就認為你是誰。
解釋:
- 阻止好人做錯事:例如AB兩個用戶,A用戶創建了一個X文件,B用戶創建了一個Y文件,B用戶刪除不了A用戶的文件X。
- 阻止壞人做壞事:如果AB兩個用戶中的某個壞人,裝了一臺全新的linux系統,也創建AB用戶,補全Hadoop部署文件內容,客戶端程序,然后用新系統的A向NameNode去刪除X文件,由于NameNode是被動受信,所以未來需要集成kerberos來防止這種操作。
(轉發請注明出處:http://www.cnblogs.com/zhangyongli2011/ 如發現有錯,請留言,謝謝)
轉載于:https://www.cnblogs.com/zhangyongli2011/p/10897766.html
總結
以上是生活随笔為你收集整理的大数据系列文章-Hadoop的HDFS读写流程(二)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 第二阶段SCRUM
- 下一篇: Java常用工具类---IP工具类、Fi