[笔记迁移][Hadoop][2]HDFS原理

1. 基本原理引入：以写操作为例

*防裂说明*：

• Client从字节流中仅按配置文件切块，不做其他任何改动（实际传输过程中，一个Block被切分为多个Packet，到达目标位置是再“拼装”为Block）；
• Client写入blk_x的第一份副本给某个 DataNode后，继续写blk_x+1的第一份副本给某个DataNode，blk_x的n份副本由第一份副本所在DataNode拷贝（pipe_cp）给其他DataNode（DataNode串联形成一条Pipeline），整个过程是异步进行的；
• 存储小文件降低性能，主要原因为：
  • 不会浪费DataNode，因为默认情况下一个Block=128MB，小于128MB的文件同样占用一个Block；
  • 但会浪费NameNode，因为元数据meta的存储空间是有限的（也就决定了格式化的meta项数是一定的[类似CPU地址线决定存储单元的个数]）
  • 整个FS的理论存储容量=meta的项数*Block大小

---

2. HDFS副本Replicas放置策略：

• 第一副本一般置于离客户端最近的DataNode；
• 第二副本优先放在另一个机架Rack上的DataNode；
• 第三副本将从本机架Rack随机找一个DataNode；

---

3. NameNode的meta元数据管理机制[重点]

 (1) 一条meta元数据记录：

• 数据结构：NameNode(FileName, Replicas, Block_ids, id2host, Upload_time, Permit ...)
• 举例：/test/a.log, 3, {blk_1,blk_2}, [{blk_1:[h0,h1,h2]},{blk_2:[h2,h3,h4]}],...

(2) 写入put时的meta变化

 (3)读取get直接通过内存中元数据meta进行操作。内存中的元数据meta实时更新，总是最新的。

(4) meta元数据合并——持久化

什么时候CheckPoint? 

• fs.checkpoint.period 指定两次 checkpoint 的最大时间间隔，默认3600s
• fs.checkpoint.size 规定edits_log文件的最大值，一旦超过这个值强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。

目前机制的问题：

       CheckPoint之前，NameNode宕机，meta可以通过fsimage+edits_log恢复，但是截止到恢复Service不能正常提供。

解决方案：

        双NameNode -> HA

*总结：NameNode主要职责

• 维护元数据meta信息
• 维护hdfs的虚拟目录树
• 接收Slave-DataNode心跳及其维持的Block列表
• 响应客户端请求，返回目标地址

---

4. DataNode--真实数据存储

 

*总结：DataNode的主要职责 

• HDFS默认Block大小是128MB，可以修改hdfs-site.xml中的dfs.block.size来配置块大小；
• HDFS中，如果一个文件小于一个Block大小，并不占用整个Block的存储空间，但仍会占用一条元数据meta记录；
• 副本Replicas默认为3个，可以修改hdfs-site.xml中的dfs.replication来配置块的副本数；
• 维持数据块Block
• 向NameNode发送周期性心跳信号“报道”
• 集群启动之初，向NameNode汇报Block信息以“重演检查”