自行整理, 学习用途, 侵知删歉
1.HDFS
- 新加入的文件被分成block, 64M默认;
- 默认每一个block复制3份,分布在多台node上
Paste_Image.png
- HDFS can be deployed with or without high availability
2. HDFS without high availability, 3 deamons, [Mode A]:
- NameNode(Master)
- Secondary NameNode(Master)
- DataNode (slave)
3 daemons
NameNode
- NameNode 包含所有metadata
hdfs中文件位置信息
所属关系(ownership)和权限(permission)
独立block的名字
block的位置信息
Metadata
- 存储在硬盘上, 当Namenode守护进程启动时读取
- 文件名: fsimage (block的位置信息没有存在里面)
edits
- 硬盘上,对metadata的更改被写进一份log文件,叫做
edits
SlaveNode
- 实际的文件内容以block的形式存储在slva node上
- block文件名:
blk_xxxxxxx - 每个slaveNode运行一个NataNode daemon, 控制对block的访问, 与NameNode通信
the Secondary NameNode(SN)
- SN并不是NameNode的失效备援
- SN将
metadata的变化内容写到edit log里 - SN周期性的将
系统的metadata快照与edit log合并成一份新的metadata快照, 并将新的metadata快照传送回NameNode - SN的运行环境经需要和NameNode一样的RAM
文件系统的metadata快照 和 Edit
- fsimage包含了一个系统metadata的快照, 并不会在每次写入操作时更新
- 当hdfs客户端进行一个写操作, 它首先记录在Primary Namenode的
edits - 对所有
edits进行更新(Namenode重启时)将会耗时很长, 所以这个事由the secondary namenode做
Checkingpointing the file system Metadata
- SN周期性的检查NameNode里的in-memory file去获取
fsimage和新产生edits - SN把
fsimage放到内存, 然后应用edits中的更新内容, 然后构造新的fsimage文件,并将其送回primary NameNode - primary NameNode收到后, 更新
fsimage和 新产生的edits - 默认情况下checkpoint = min{ 每小时或者每1,000,000传输进行一次 }
在这种模式下, 一个NameNode就是一个single point of failure, SN不是 ; 如果故障, HDFS会在故障的NameNode更换后恢复正常; risk比较低,恢复也比较简单
3.HDFS with high Availability [Mode B]:
为了排除Single Point of Failure
2个NameNode:
standbyNameNode和ActiveNameNode, standby在Active挂掉后代替它.
activeNameNode把metadata写到JournalNodes[Quorum机制]
standbyNameNode读取JournalNode[Quorum机制]来和Active NameNode保持同步
2个NameNode
-
一个HDFS目录可以快照(snapshot),例如:
Paste_Image.png
-
HDFS Cache
- it is possible to cache HDFS files in off-heap memory on DataNodes
- cache is in off-heap memory for DataNode user
-
HDFS HA 部署步骤
1.配置Hadoop的 configuration
2.安装和启动JournalNodes
3.如果没有安装, 则配置并启动一个ZooKeeper ensemble
4.如果从一个con-HA的配置转成HA, 初始化shared edits directory
5.安装, 引导, 启动Standby NameNode
6.安装, 规定(format),启动ZooKeeper failover controllers
7.重启DataNodes, Yarn, MapReduce守护进程
- Journal Node配置
在每一个要运行JournalNode的host上
1.安装
- sudo yum install hadoop-hdfs-journalnode
2.在Journal Node 创建shared edits directory
-路径 dfs.journalnode.edits.dir
3.启动JournalNode
-sudo service hadoop-hdfs-journalnode start
4.HDFS写文件(client写到DataNode)
-
client连接到NameNode -
NameNode设置好metadata的入口(entry), 并将block的名字和DataNode的列表发送给client -
client连接到第一个DataNode然后开始发送数据; 第一个发送完了给第二DataNode发送, 然后去第三个 - 流水线的请求数据包返回发送给
client - block写入完成,
client给NameNode报告完成
关系图
-
如果这个流水线的DataNode失败了:
- 这个流水线就关闭了
- 一个新的流水线启动, 开启2个好的节点, 数据就继续写到这2个好的节点
-
NameNode会知晓这个block是有备份的, 然后这个数据会在另一个DataNode重新备份
-
当数据的block写完后, client会计算每一个block的checkSum
- checkSum和data一起发送到
DataNode - checkSum和每一个数据
block一起写入 - 保证了数据的一致性
- checkSum和data一起发送到
Rack-aware
Hadoop了解rack awareness的概念:
- 知晓node在哪里, 如何和另一个node关联
- 帮助ResourceManager给靠近
data的node分配处理资源 - 帮助
NameNode找到最近的block给client去读取 - HDFS将data blocks复制在不同的节点, 不同的机架, 更好的安全性
第一份拷贝: 在client的同一个节点
第二份拷贝: 靠近的另一个机架上的一个节点
第三份拷贝: 同一机架上的不同节点上
5. HDFS读文件(client读DataNode)
-
client连接NameNode -
NameNode返回文件的第一部分block的名字和路径(距离最近的先返回) -
client连接到第一个DataNode开始读取block - 如果连接失败,
client会连接到list里的下一个节点去读block
Paste_Image.png
数据污染
- 当
client读取一个block时, 它会校对checkSum, 实时的checkSum会和block创建时的checkSum对比 - 如果不同,
client会读取下一个DataNode中的数据, 然后告知NameNode这里出现一个数据污染版本,NameNode会在别处重新备份这个block -
DataNode默认每3周会检查block的checkSums
数据可靠性和恢复
-
DataNode每3秒发送心跳给NameNode - 一段时间没有收到心跳就可以认为
DataNode挂了 -
NameNode会知道哪些block受影响, 然后让其他的节点复制这些block到一个新的节点
*挂了的节点恢复后,NameNode会告知新备份的DataNode删除多余的备份
数据从不会经过NameNode, 不管是读写还是拷贝过程
`
网友评论