HDFS

---

Hadoop 1.0:

• 3個組件：
  • Namenode
  • SecondNamenode
  • Datanode

namenode（主節點，master，只有一個，單點故障的風險）中間存儲信息（元數據）
2種映射關系：

path -> blockid list 列表

blockid 數據塊 -> datanode 節點地址
元數據存在內存中
元數據進行持久化 — 磁盤fsimage — 目的：避免數據丟失
fsimage ： 元數據鏡像文件
只有機器重啟的時候加載fsimage

元數據持久化的過程 — SNN — secondnamenode
內存 -> edit log（磁盤）-> fsimage

SNN 存在意義 ： 備份 / 數據恢復

namenode和 edit log關系：
namenode需要把每一次改動都存在 edit log ，整個過程誰來推動？（Datanode和namenode之間心跳機制）

namenode除了單點問題之外，還有不適合存儲太多小文件的問題，因為內存有限

datanode （slave，從節點，多個機器）

block 數據塊 -> 真實輸據
多副本機制 — 默認3副本 （作用：數據冗余，高可用）
本地化原則 （就近原則）：mapreduce：主（jobtracker - namenode），從（tasktracker - datanode）

可靠性保證 :

數據校驗
目的 ： 保證數據完整性 （通過crc32校驗算法）
整個數據傳輸過程，輸據需要校驗幾次？

client給datanode寫數據：要針對寫的數據，每個檢查單元（512字節）

• 每一個單元創建一個單獨的校驗碼（crc32） ， 數據和校驗碼統一發送給Datanode

Datanode 接受輸據的時候 ： 用同樣的加密算法，生成校驗碼，并校驗

• 在后臺還會運行一個掃描進程：DataBlockScanner（定期校驗）
• 一旦檢測出現問題，通過心跳，通知NN，讓NN發起DN修復 （拷貝沒有問題的備份）

2.可靠性保證 ：

• 心跳
• 多副本機制
• crc32
• SNN （secondnamenode）
• 回收站 （ .Trash 目錄）

Hadoop 2.0:

?

HA 高可用 ： 解決了單點故障問題
1.0里有一個SNN，但是不可靠
如何便可靠：需要兩個NN，一個active，一個standby（備用）
為了保證兩個NN的數據一致性，Datanode要對兩個NN同時發送心跳

雖然Datanode同時發送心跳，但是為什么還需要JN？
2種映射關系：
path -> blockid list 列表 ：JN
blockid 數據塊 -> datanode 節點地址 ： Datanode心跳
分工不同：：：

HDFS２.０ 需要引入zookeeper ， （zookeeper目的：協調分布式集群中各個節點工作有序進行，完成故障轉移）

在2.0，引入zkfc（ZookeeperFailoverController）進程，和NN部署到同一個機器上，目的：負責自己管轄之內的NN進行健康檢查
zkfc 進程會在zookeeper上注冊一個臨時節點
目的：監控NN，一旦NN掛掉，相對應的臨時節點消失，接下來開始選主（申請鎖）流程

JN目的：讓activeNN和standbyNN保持輸據同步（文件 -> block)
同步問題：需要以來JN（JournalNodes）守護進程，完成元數據的一致性

JN 角色有兩種選擇：
1） NFS — 網絡系統 （network file system）
需要額外的磁盤空間
2）QJM — 最低法人管理機制 （投票）
不需要額外的磁盤空間
需要用2n+1臺機器存儲edit log (奇數是為了投票）
QJM本質是小集群
好處：
* 不需要空間
* 無但點問題
* 不會因為個別機器延遲，影響整體性能
* 只需要通過簡單的系統配置可以實現

NN 和 JN 通常不再一個機器上
FC 和 NN 在同一個機器上
RM（Yarn主） 和 NN（HDFS主） 通常在同一臺機器上
zookeeper 需要單獨維護一套獨立集群

?

HDFS Federation（聯邦） ： 水平擴展

集群中提供多個Name Node，每個NameNode負責管理一部分DataNode
每一個NN只管理自己管轄之內的DN
目的：減輕單一NN壓力，將一部分文件轉移到其他NN上管理

如果集群中一個目錄比較大，那么可以用單獨的NN維護起來
橫向虧站，突破了NN的限制

不同的NN，會可以訪問所有的DN嗎？ 會的?
聯邦的本質：將元數據管理NN和存儲DN進行解耦

可以把聯邦和高可用同時體現出來

快照：真實數據（不是元數據） ：：： 數據備份/災備/快速恢復

本質：僅僅記錄block列表和大小而已，并不涉及數據本身的復制
某個目錄的某一時刻的鏡像
創建和恢復，都非常快 — 瞬間完成，高效

HDFS快照是一個只讀的基于時間點文件系統拷貝
HDFS快照是對目錄進行設定，是某個目錄的某一個時刻的鏡像

• 快照可以是整個文件系統的也可以是一部分
• 常用來作為數據備份，防止用戶錯誤操作和容災恢復
• Snapshot并不會影響HDFS的正常操作：修改會按照時間的反序記錄，這樣可以直接讀取到最新的數據
• 快照數據是當前數據減去修改部分計算出來的
• 快照會存儲在snapeshottable的目錄下

?

快照的各種命令

hdfs dfsadmin -allowSnapshot /user/spark hdfs dfs -createSnapshot /user/spark s0 hdfs dfs -renameSnapshot /user/spark s0 s_init hdfs dfs -deleteSnapshot /user/spark s_init hdfs dfsadmin -disallowSnapshot /user/spark

?

?

緩存（集中式緩存 — 不局限具體的機器的cpu和操作系統層面上的優化）

對于重復訪問的文件很有用
優點：速度快

• 允許用戶指定要緩存的HDFS路徑
• 明確的鎖定可以阻止頻繁使用的數據被從內存中清除
• 集中化緩存管理對于重復訪問的文件很有用
• 可以換成目錄或文件，但目錄是非遞歸的

?

權限控制 ACL

類似于linux系統acl

例：rwx - rwx - rwx
自己 - 組 - 其他

設置權限： setacl命令
需要開啟功能：

dfs.permissions.enableddfs.namenode.acls.enabledhadoop fs -getfacl /input/aclhdfs dfs -setfacl -m user:mapred:r-- /input/aclhdfs dfs -setfacl -x user:mapred /input/acl

轉載于:https://www.cnblogs.com/pipemm/articles/11331639.html

總結

以上是生活随笔為你收集整理的大数据 — Hadoop的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。