Hadoop学习笔记(1)-HDFS

自行整理, 学习用途, 侵知删歉

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)

1. client连接到NameNode
2. NameNode设置好metadata的入口(entry), 并将block的名字和DataNode的列表发送给client
3. client连接到第一个DataNode然后开始发送数据; 第一个发送完了给第二DataNode发送, 然后去第三个
4. 流水线的请求数据包返回发送给client
5. block写入完成,client给NameNode报告完成

关系图

• 如果这个流水线的DataNode失败了:

  • 这个流水线就关闭了
  • 一个新的流水线启动, 开启2个好的节点, 数据就继续写到这2个好的节点
  • NameNode会知晓这个block是有备份的, 然后这个数据会在另一个DataNode重新备份

• 当数据的block写完后, client会计算每一个block的checkSum

  • checkSum和data一起发送到DataNode
  • checkSum和每一个数据block一起写入
  • 保证了数据的一致性

---

Rack-aware

Hadoop了解rack awareness的概念:

• 知晓node在哪里, 如何和另一个node关联
• 帮助ResourceManager给靠近data的node分配处理资源
• 帮助NameNode找到最近的block给client去读取
• HDFS将data blocks复制在不同的节点, 不同的机架, 更好的安全性

第一份拷贝: 在client的同一个节点
第二份拷贝: 靠近的另一个机架上的一个节点
第三份拷贝: 同一机架上的不同节点上

---

5. HDFS读文件(client读DataNode)

1. client连接NameNode
2. NameNode返回文件的第一部分block的名字和路径(距离最近的先返回)
3. client连接到第一个DataNode开始读取block
4. 如果连接失败, 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, 不管是读写还是拷贝过程

`