HDFS常見知識點總結


一、主從結構:在一個集群中,會有部分節點充當主服務器的角色,其他服務器都是從服務器的角色,當前這種架構模式叫做主從結構。

主從結構分類:

1、一主多從

2、多主多從

Hadoop中的HDFS和YARN都是主從結構,主從結構中的主節點和從節點有多重概念方式:

1、主節點  從節點

2、master  slave

3、管理者  工作者

4、leader  follower

Hadoop集群中各個角色的名稱:

服務 主節點 從節點
HDFS NameNode DataNode
YARN ResourceManager NodeManager

二、單點故障

1、如果說宕機的那個節點是從節點,那么整個集群能夠繼續運行,並且對外提供正常的服務。

2、如果說宕機的那個節點是主節點,那么整個集群就處於宕機狀態。

通用的解決方案:高可用

概念:當正在對外提供服務器的主從節點宕機,那么備用的主節點立馬上位對外提供服務。無縫的瞬時切換。

1)啟動一個擁有文件系統元數據的新NameNode(這個一般不采用,因為復制元數據非常耗時間)

2)配置一對活動-備用(Active-Sandby)NameNode,活動NameNode失效時,備用NameNode立即接管,用戶不會有明顯中斷感覺。

  共享編輯日志文件(借助NFS、zookeeper等)

  DataNode同時向兩個NameNode匯報數據塊信息

  客戶端采用特定機制處理 NameNode失效問題,該機制對用戶透明

皇帝駕崩,太子繼位。

三、集群的模式

1.單機模式

表示所有的分布式系統都是單機的。

2.為分布式模式

表示集群中的所有角色都分配給了一個節點。

表示整個集群被安裝在了只有一個節點的集群中的。

主要用於做快速使用,去模擬分布式的效果。

3.分布式模式

表示集群中的節點會被分配成很多種角色,分散在整個集群中。

主要用於學習測試等等一些場景中。

4.高可用模式

表示整個集群中的主節點會有多個

注意區分:能夠對外提供服務的主節點還是只有一個。其他的主節點全部處於一個熱備的狀態。

正在對外提供服務的主節點:active  有且僅有一個

熱備的主節點:standby  可以有多個

工作模式:1、在任意時刻,只有一個主節點是active的,active的主節點對外提供服務

     2、在任意時刻,都應至少有一個standby的主節點,等待active的宕機來進行接替

架構模式:就是為了解決分布式集群中的通用問題SPOF

不管是分布式架構還是高可用架構,都存在一個問題:主從結構---從節點數量太多了。最直觀的的問題:造成主節點的工作壓力過載,主節點會宕機,當前的這種現象是一種死循環

5.聯邦模式

表示當前集群中的主從節點都可以有很多個。

  1)主節點:可以有很多個的意思是說:同時對外提供服務的主節點有很多個。

            重點:每一個主節點都是用來管理整個集群中的一部分

  2)從節點:一定會有很多個。

  在聯邦模式下還是會有問題:

  雖然這個集群中的一個主節點的壓力被分攤到了多個主節點。但是這個多個主節點依然會有一個問題:SOFP

四、hdfs設計思想

1、分散均勻存儲 dfs.blocksize = 128M

2、備份冗余存儲 dfs.replication = 3

五、hdfs的概念和特性

1、概念

首先,它是一個文件系統,用於存儲文件,通過統一的命名空間——目錄樹來定位文件

其次,它是分布式的,由很多服務器聯合起來實現其功能,集群中的服務器有各自的角色;

2.重要特性

1)HDFS中的文件在物理上是分塊存儲(block),塊的大小可以通過配置參數( dfs.blocksize)來規定,默認大小在hadoop2.x版本中是128M,老版本中是64M

(2)HDFS文件系統會給客戶端提供一個統一的抽象目錄樹,客戶端通過路徑來訪問文件,形如:hdfs://namenode:port/dir-a/dir-b/dir-c/file.data

(3)目錄結構及文件分塊信息(元數據)的管理由namenode節點承擔

——namenode是HDFS集群主節點,負責維護整個hdfs文件系統的目錄樹,以及每一個路徑(文件)所對應的block塊信息(block的id,及所在的datanode服務器)

(4)文件的各個block的存儲管理由datanode節點承擔

---- datanode是HDFS集群從節點,每一個block都可以在多個datanode上存儲多個副本(副本數量也可以通過參數設置dfs.replication)

(5)HDFS是設計成適應一次寫入,多次讀出的場景,且不支持文件的修改

六、hdfs的特點和hdfs的組成

1.特點

保存多個副本,且提供容錯機制,副本丟失或宕機自動恢復(默認存3份)。

運行在廉價的機器上

適合大數據的處理。HDFS默認會將文件分割成block,,在hadoop2.x以上版本默認128M為1個block。然后將block按鍵值對存儲在HDFS上,並將鍵值對的映射存到內存中。如果小文件太多,那內存的負擔會很重。

2.組成

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

NameNode:是Master節點,是大領導。管理數據塊映射;處理客戶端的讀寫請求;配置副本策略;管理HDFS的名稱空間;
SecondaryNameNode:是一個小弟,分擔大哥namenode的工作量;是NameNode的冷備份;合並fsimage和fsedits然后再發給namenode。
DataNode:Slave節點,奴隸,干活的。負責存儲client發來的數據塊block;執行數據塊的讀寫操作。
熱備份:b是a的熱備份,如果a壞掉。那么b馬上運行代替a的工作。
冷備份:b是a的冷備份,如果a壞掉。那么b不能馬上代替a工作。但是b上存儲a的一些信息,減少a壞掉之后的損失。
fsimage:元數據鏡像文件(文件系統的目錄樹。)
edits:元數據的操作日志(針對文件系統做的修改操作記錄)
namenode內存中存儲的是=fsimage+edits。
SecondaryNameNode負責定時默認1小時,從namenode上,獲取fsimage和edits來進行合並,然后再發送給namenode。減少namenode的工作量。

七、hdfs的局限性

1)低延時數據訪問。在用戶交互性的應用中,應用需要在ms或者幾個s的時間內得到響應。由於HDFS為高吞吐率做了設計,也因此犧牲了快速響應。對於低延時的應用,可以考慮使用HBase或者Cassandra。
2)大量的小文件。標准的HDFS數據塊的大小是64M,存儲小文件並不會浪費實際的存儲空間,但是無疑會增加了在NameNode上的元數據,大量的小文件會影響整個集群的性能。

前面我們知道,Btrfs為小文件做了優化-inline file,對於小文件有很好的空間優化和訪問時間優化。
3)多用戶寫入,修改文件。HDFS的文件只能有一個寫入者,而且寫操作只能在文件結尾以追加的方式進行。它不支持多個寫入者,也不支持在文件寫入后,對文件的任意位置的修改。
但是在大數據領域,分析的是已經存在的數據,這些數據一旦產生就不會修改,因此,HDFS的這些特性和設計局限也就很容易理解了。HDFS為大數據領域的數據分析,提供了非常重要而且十分基礎的文件存儲功能。

八、hdfs保證可靠性的措施

1)冗余備份

  每個文件存儲成一系列數據塊(Block)。為了容錯,文件的所有數據塊都會有副本(副本數量即復制因子,課配置)(dfs.replication)

2)副本存放

  采用機架感知(Rak-aware)的策略來改進數據的可靠性、高可用和網絡帶寬的利用率

3)心跳檢測

  NameNode周期性地從集群中的每一個DataNode接受心跳包和塊報告,收到心跳包說明該DataNode工作正常

4)安全模式

  系統啟動時,NameNode會進入一個安全模式。此時不會出現數據塊的寫操作。

5)數據完整性檢測

  HDFS客戶端軟件實現了對HDFS文件內容的校驗和(Checksum)檢查(dfs.bytes-per-checksum)。

九、hdfs常用命令

1.啟動hdfs集群

start-dfs.sh

2.啟動yarn集群

start-yarn.sh

3.查看hdfs系統的根目錄

hadoop fs -ls /

4.創建文件夾

hadoop fs -mkdir /a

5.級聯創建文件夾

hadoop fs -mkdir -p /aa/bb/cc

6.查看根目錄下的所有文件包括子文件夾里面的文件

hadoop fs -ls -R /aa

7.上傳文件

hadoop fs -put a.txt /aa

hadoop fs -copyFromLocal words.txt /aa/bb

8.下載文件

hadoop fs -get /aa/word.txt /aa

hadoop fs -copyToLocal /aa/word.txt /aa

9.合並下載

hadoop fs -getmerge /aa/word.txt /aa/bb/word.txt /aa

10.復制

hadoop fs -cp /aa/word.txt /a

11.移動

hadoop fs -mv /a/word.txt /a/b

12.刪除文件

hadoop fs -rm /a/bword.txt

13.刪除空目錄

hadoop fs -rmdir /a/b

14.強制刪除

hadoop fs -rm -r /aa/bb

15.從本地剪切到hdfs上

hadoop fs -moveFromLocal /a/word.txt /a/b

16.追加文件

hadoop fs -appendToFile /hello.txt /aa/bb/word.txt

17.查看文件內容

hadoop fs -cat /a/b/word.txt

十、hdfs優缺點

優點

1、可構建在廉價機器上

    通過多副本提高可靠性,提供了容錯和恢復機制

    服務器節點的宕機是常態   必須理性對象

 

2、高容錯性

    數據自動保存多個副本,副本丟失后,自動恢復

    HDFS的核心設計思想:  分散均勻存儲 + 備份冗余存儲

3、適合批處理

    移動計算而非數據,數據位置暴露給計算框架

    海量數據的計算 任務 最終是一定要被切分成很多的小任務進行

 

4、適合大數據處理

    GB、TB、甚至 PB 級數據,百萬規模以上的文件數量,10K+節點規模

5、流式文件訪問

     一次性寫入,多次讀取,保證數據一致性

缺點:

1、低延遲數據訪問

    比如毫秒級 低延遲與高吞吐率

2、小文件存取

    占用 NameNode 大量內存 150b* 1000W = 15E,1.5G 尋道時間超過讀取時間

3、並發寫入、文件隨機修改

    一個文件只能有一個寫者 僅支持 append

十一、為什么hdfs不適合存儲小文件

這是和HDFS系統底層設計實現有關系的,HDFS本身的設計就是用來解決海量大文件數據的存儲.,他天生喜歡大數據的處理,大文件存儲在HDFS中,會被切分成很多的小數據塊,任何一個文件不管有多小,都是一個獨立的數據塊,而這些數據塊的信息則是保存在元數據中的,在之前的博客HDFS基礎里面介紹過在HDFS集群的namenode中會存儲元數據的信息,這里再說一下,元數據的信息主要包括以下3部分:

  1)抽象目錄樹

  2)文件和數據塊的映射關系,一個數據塊的元數據大小大約是150byte

  3)數據塊的多個副本存儲地

而元數據的存儲在磁盤(1和2)和內存中(1、2和3),而服務器中的內存是有上限的,舉個例子:

有100個1M的文件存儲進入HDFS系統,那么數據塊的個數就是100個,元數據的大小就是100*150byte,消耗了15000byte的內存,但是只存儲了100M的數據。

有1個100M的文件存儲進入HDFS系統,那么數據塊的個數就是1個,元數據的大小就是150byte,消耗量150byte的內存,存儲量100M的數據。

所以說HDFS文件系統不適用於存儲小文件。

十二、hdfs心跳機制

1、DataNode啟動的時候會向NameNode匯報信息,就像釘釘上班打卡一樣,你打卡之后,你領導才知道你今天來上班了,同樣的道理,DataNode也需要向NameNode進行匯報,只不過每次匯報的時間間隔有點短而已,默認是3秒中,DataNode向NameNode匯報的信息有2點,一個是自身DataNode的狀態信息,另一個是自身DataNode所持有的所有的數據塊的信息。而DataNode是不會知道他保存的所有的數據塊副本到底是屬於哪個文件,這些都是存儲在NameNode的元數據中。

2、按照規定,每個DataNode都是需要向NameNode進行匯報。那么如果從某個時刻開始,某個DataNode再也不向NameNode進行匯報了。 有可能宕機了。因為只要通過網絡傳輸數據,就一定存在一種可能: 丟失 或者 延遲。

3、HDFS的標准: NameNode如果連續10次沒有收到DataNode的匯報。 那么NameNode就會認為該DataNode存在宕機的可能。

4、DataNode啟動好了之后,會專門啟動一個線程,去負責給NameNode發送心跳數據包,如果說整個DataNode沒有任何問題,但是僅僅只是當前負責發送信條數據包的線程掛了。NameNode會發送命令向這個DataNode進行確認。查看這個發送心跳數據包的服務是否還能正常運行,而為了保險起見,NameNode會向DataNode確認2遍,每5分鍾確認一次。如果2次都沒有返回 結果,那么NameNode就會認為DataNode已經GameOver了!!!

最終NameNode判斷一個DataNode死亡的時間計算公式:

timeout = 10 * 心跳間隔時間  + 2 * 檢查一次消耗的時間

 心跳間隔時間:dfs.heartbeat.interval 心跳時間:3s
檢查一次消耗的時間:heartbeat.recheck.interval checktime : 5min

最終結果默認是630s。

十二、hdfs安全模式

1、HDFS的啟動和關閉都是先啟動NameNode,在啟動DataNode,最后在啟動secondarynamenode。

2、決定HDFS集群的啟動時長會有兩個因素:

  1)磁盤元數據的大小

  2)datanode的節點個數

 當元數據很大,或者 節點個數很多的時候,那么HDFS的啟動,需要一段很長的時間,那么在還沒有完全啟動的時候HDFS能否對外提供服務?

在HDFS的啟動命令start-dfs.sh執行的時候,HDFS會自動進入安全模式

為了確保用戶的操作是可以高效的執行成功的,在HDFS發現自身不完整的時候,會進入安全模式。保護自己。

在正常啟動之后,如果HDFS發現所有的數據都是齊全的,那么HDFS會啟動的退出安全模式

3、在安全模式下:

如果一個操作涉及到元數據的修改的話。都不能進行操作

如果一個操作僅僅只是查詢。那是被允許的。

所謂的安全模式,僅僅只是保護namenode,而不是保護datanode

十三、hdfs副本存放策略

第一副本:放置在上傳文件的DataNode上;如果是集群外提交,則隨機挑選一台磁盤不太慢、CPU不太忙的節點上;
第二副本:放置在於第一個副本不同的機架的節點上;
第三副本:與第二個副本相同機架的不同節點上;
如果還有更多的副本:隨機放在節點中;

十四、hdfs負載均衡

負載均衡理想狀態:節點均衡、機架均衡和磁盤均衡。

Hadoop的HDFS集群非常容易出現機器與機器之間磁盤利用率不平衡的情況,例如:當集群內新增、刪除節點,或者某個節點機器內硬盤存儲達到飽和值。當數據不平衡時,Map任務可能會分配到沒有存儲數據的機器,這將導致網絡帶寬的消耗,也無法很好的進行本地計算。
當HDFS負載不均衡時,需要對HDFS進行數據的負載均衡調整,即對各節點機器上數據的存儲分布進行調整。從而,讓數據均勻的分布在各個DataNode上,均衡IO性能,防止熱點的發生。進行數據的負載均衡調整,必須要滿足如下原則:

  • 數據平衡不能導致數據塊減少,數據塊備份丟失
  • 管理員可以中止數據平衡進程
  • 每次移動的數據量以及占用的網絡資源,必須是可控的
  • 數據均衡過程,不能影響namenode的正常工作

數據均衡過程的核心是一個數據均衡算法,該數據均衡算法將不斷迭代數據均衡邏輯,直至集群內數據均衡為止。

步驟分析如下:

  1. 數據均衡服務(Rebalancing Server)首先要求 NameNode 生成 DataNode 數據分布分析報告,獲取每個DataNode磁盤使用情況
  2. Rebalancing Server匯總需要移動的數據分布情況,計算具體數據塊遷移路線圖。數據塊遷移路線圖,確保網絡內最短路徑
  3. 開始數據塊遷移任務,Proxy Source Data Node復制一塊需要移動數據塊
  4. 將復制的數據塊復制到目標DataNode上
  5. 刪除原始數據塊
  6. 目標DataNode向Proxy Source Data Node確認該數據塊遷移完成
  7. Proxy Source Data Node向Rebalancing Server確認本次數據塊遷移完成。然后繼續執行這個過程,直至集群達到數據均衡標准

十五、hdfs寫過程

術語:

1、使用 HDFS 提供的客戶端 Client,向遠程的 namenode 發起 RPC 請求

2、namenode 會檢查要創建的文件是否已經存在,創建者是否有權限進行操作,成功則會 為文件創建一個記錄,否則會讓客戶端拋出異常;

3、當客戶端開始寫入文件的時候,客戶端會將文件切分成多個 packets,並在內部以數據隊列“data queue(數據隊列)”的形式管理這些 packets,並向 namenode 申請 blocks,獲 取用來存儲 replicas 的合適的 datanode 列表,列表的大小根據 namenode 中 replication 的設定而定;

4、開始以 pipeline(管道)的形式將 packet 寫入所有的 replicas 中。客戶端把 packet 以流的 方式寫入第一個 datanode,該 datanode 把該 packet 存儲之后,再將其傳遞給在此 pipeline 中的下一個 datanode,直到最后一個 datanode,這種寫數據的方式呈流水線的形式。

5、最后一個 datanode 成功存儲之后會返回一個 ack packet(確認隊列),在 pipeline 里傳遞 至客戶端,在客戶端的開發庫內部維護着"ack queue",成功收到 datanode 返回的 ack packet 后會從"data queue"移除相應的 packet。

6、如果傳輸過程中,有某個 datanode 出現了故障,那么當前的 pipeline 會被關閉,出現故 障的 datanode 會從當前的 pipeline 中移除,剩余的 block 會繼續剩下的 datanode 中繼續 以 pipeline 的形式傳輸,同時 namenode 會分配一個新的 datanode,保持 replicas 設定的 數量。

7、客戶端完成數據的寫入后,會對數據流調用 close()方法,關閉數據流;

8、只要寫入了 dfs.replication.min(最小寫入成功的副本數)的復本數(默認為 1),寫操作 就會成功,並且這個塊可以在集群中異步復制,直到達到其目標復本數(dfs.replication 的默認值為 3),因為 namenode 已經知道文件由哪些塊組成,所以它在返回成功前只需 要等待數據塊進行最小量的復制。

口語:

1、客戶端發起請求:hadoop fs -put hadoop.tar.gz / 

客戶端怎么知道請求發給那個節點的哪個進程?

因為客戶端會提供一些工具來解析出來你所指定的HDFS集群的主節點是誰,以及端口號等信息,主要是通過URI來確定,

url:hdfs://hadoop1:9000

當前請求會包含一個非常重要的信息: 上傳的數據的總大小

2、namenode會響應客戶端的這個請求

namenode的職責:

1 管理元數據(抽象目錄樹結構)

用戶上傳的那個文件在對應的目錄如果存在。那么HDFS集群應該作何處理,不會處理

用戶上傳的那個文件要存儲的目錄不存在的話,如果不存在不會創建

2、響應請求

真正的操作:做一系列的校驗,

1、校驗客戶端的請求是否合理
2、校驗客戶端是否有權限進行上傳

3、如果namenode返回給客戶端的結果是 通過, 那就是允許上傳

namenode會給客戶端返回對應的所有的數據塊的多個副本的存放節點列表,如:

file1_blk1 hadoop02,hadoop03,hadoop04
file1_blk2 hadoop03,hadoop04,hadoop05

4、客戶端在獲取到了namenode返回回來的所有數據塊的多個副本的存放地的數據之后,就可以按照順序逐一進行數據塊的上傳操作

5、對要上傳的數據塊進行邏輯切片

切片分成兩個階段:

1、規划怎么切
2、真正的切

物理切片: 1 和 2

邏輯切片: 1

file1_blk1 : file1:0:128
file1_blk2 : file1:128:256

  邏輯切片只是規划了怎么切

  

6、開始上傳第一個數據塊

7、客戶端會做一系列准備操作

1、依次發送請求去連接對應的datnaode

pipline : client - node1 - node2 - node3

按照一個個的數據包的形式進行發送的。

每次傳輸完一個數據包,每個副本節點都會進行校驗,依次原路給客戶端

2、在客戶端會啟動一個服務:

用戶就是用來等到將來要在這個pipline數據管道上進行傳輸的數據包的校驗信息

客戶端就能知道當前從clinet到寫node1,2,3三個節點上去的數據是否都寫入正確和成功

8、clinet會正式的把這個快中的所有packet都寫入到對應的副本節點

1、block是最大的一個單位,它是最終存儲於DataNode上的數據粒度,由dfs.block.size參數決定,2.x版本默認是128M;注:這個參數由客戶端配置決定;如:System.out.println(conf.get("dfs.blocksize"));//結果是134217728

2、packet是中等的一個單位,它是數據由DFSClient流向DataNode的粒度,以dfs.write.packet.size參數為參考值,默認是64K;注:這個參數為參考值,是指真正在進行數據傳輸時,會以它為基准進行調整,調整的原因是一個packet有特定的結構,調整的目標是這個packet的大小剛好包含結構中的所有成員,同時也保證寫到DataNode后當前block的大小不超過設定值;

如:System.out.println(conf.get("dfs.write.packet.size"));//結果是65536

3、chunk是最小的一個單位,它是DFSClient到DataNode數據傳輸中進行數據校驗的粒度,由io.bytes.per.checksum參數決定,默認是512B;注:事實上一個chunk還包含4B的校驗值,因而chunk寫入packet時是516B;數據與檢驗值的比值為128:1,所以對於一個128M的block會有一個1M的校驗文件與之對應;

如:System.out.println(conf.get("io.bytes.per.checksum"));//結果是512


9、clinet進行校驗,如果校驗通過,表示該數據塊寫入成功

10、重復7 8 9 三個操作,來繼續上傳其他的數據塊

11、客戶端在意識到所有的數據塊都寫入成功之后,會給namenode發送一個反饋,就是告訴namenode當前客戶端上傳的數據已經成功。

十六、hdfs讀過程

1、客戶端調用FileSystem 實例的open 方法,獲得這個文件對應的輸入流InputStream。

2、通過RPC 遠程調用NameNode ,獲得NameNode 中此文件對應的數據塊保存位置,包括這個文件的副本的保存位置( 主要是各DataNode的地址) 。

3、獲得輸入流之后,客戶端調用read 方法讀取數據。選擇最近的DataNode 建立連接並讀取數據。

4、如果客戶端和其中一個DataNode 位於同一機器(比如MapReduce 過程中的mapper 和reducer),那么就會直接從本地讀取數據。

5、到達數據塊末端,關閉與這個DataNode 的連接,然后重新查找下一個數據塊。

6、不斷執行第2 - 5 步直到數據全部讀完。

7、客戶端調用close ,關閉輸入流DF S InputStream。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM