2.HDFS理论基础—读写流程

hadoop

hadoop模块

Distributed File System (HDFS™)
YARN
MapReduce

流计算

现在大数据市场再从批量计算转向流计算
批量计算：每天增量的数据，第二天统一进行处理。
流计算：实时处理，数据每新增一条，我就处理一条。

HDFS和其他分布式存储区别

HDFS能更好的支持分布式计算

HDFS

存储模型

HDFS如何做到分而治之

1. 文件线性按字节切割成块(block)，具有offset，id
   • offset:偏移下标
   • id：唯一标识
2. 文件与文件的block大小可以不一样
3. 一个文件除最后一个block，其他block大小一致
4. block的大小依据硬件的I/O特性调整
   • 1.x版本：默认大小64MB
   • 2.x版本： 默认大小128MB
   • 3.x版本： 默认大小256MB
5. block被分散存放在集群的节点中，具有location
   • location：块所在的地址
6. Block具有副本(replication)，没有主从概念，副本不能出现在同一个节点
7. 副本是满足可靠性和性能的关键
8. 文件上传可以指定block大小和副本数，上传后只能修改副本数
9. 一次写入多次读取，不支持修改
   • 如果修改其中一块的数据，这块数据会变大，需要将多余的部分扔到下一块中，而后每一块都需要将自身多余的块送到下一块中。
   • 也叫泛洪
10. 支持追加数据

架构设计

1. HDFS是一个主从(Master/Slaves)架构
2. 由一个NameNode和一些DataNode组成
   • NameNode：主节点
   • DataNode：从节点
3. 面向文件包含：文件数据(data)和文件元数据(metadata)
   • 元数据：文件属性
4. NameNode负责存储和管理文件元数据，并维护了一个层次型的文件目录树
5. DataNode负责存储文件数据(block块)，并提供block的读写
   • 网络等关系，阿里建议集群不要超过5000台
6. DataNode与NameNode维持心跳，并汇报自己持有的block信息
7. Client和NameNode交互文件元数据和DataNode交互文件block数据

角色功能

NameNode

1. 完全基于内存存储文件元数据、目录结构、文件block的映射
2. 需要持久化方案保证数据可靠性
   • 持久化方案：所有基于内存存储都需要持久化。
3. 提供副本放置策略

DataNode

1. 基于本地磁盘存储block(文件的形式)
2. 并保存block的校验和数据保证block的可靠性
3. 与NameNode保持心跳，汇报block列表状态

元数据持久化

日志文件

将所有操作记录下来，断电后再读取日志恢复内存。

优点：完整性好。
缺点：加载恢复慢、占空间。

日志重写：将重复操作删掉，压缩日志。

快照、镜像、dump、db、序列化

间隔发生，内存全量数据基于某一时间点向磁盘做溢写。

优点：恢复速度快。
缺点：容易丢失一部分数据。

HDFS持久化

HDFS中同时使用了日志和快照

EditsLog(日志)：体积小、记录少情况下，必然有优势
FsImage(快照)：如果能更快的滚动时间节点

最近时间点的FsImage + 增量的EditsLog
例如：
1. 系统10:00重启开机
2. 加载到了9点的FsImage快照
3. 恢复9:00~10:00的增量EditsLog日志

这样内存就得到了全量数据

安全模式

HDFS持久化启动流程

1. HDFS搭建时会格式化，产生一个空的FsImage
2. 当Namenode启动时，从硬盘中读取Editlog和FsImage
3. 将所有Editlog中的事务作用在内存中的FsImage上
4. 并将这个新版本的FsImage从内存中保存到本地磁盘上
5. 然后删除旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了	

HDFS持久化安全模式

1. Namenode启动后会进入一个称为安全模式的特殊状态。
2. 处于安全模式的Namenode是不会进行数据块的复制的。
3. Namenode从所有的Datanode接收心跳信号和块状态报告。
4. 每当Namenode检测确认某个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全(safely replicated)的。
5. 在一定百分比（这个参数可配置）的数据块被Namenode检测确认是安全之后（加上一个额外的30秒等待时间），Namenode将退出安全模式状态。
6. 接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些数据块复制到其他Datanode上。

NameNode存储的元数据：
	1. 文件属性
		/a/b/c.txt	32G	root/root	rwxrwxrwx
	2. 每个块存在哪个DataNode上
		  块		位置1	  位置2
		blk01	node01	node03
		blk02	node04	node07
在持久化的时候，文件属性会持久化，但是每个文件的块位置不会被持久化。
恢复的时候，NameNode会丢失块的位置信息。
为什么？

因为NameNode会定期和DataNode保持心跳，DataNode向NameNode汇报自身信息。
一旦开机的时候块位置被恢复了，块所在的节点位置宕机了，并且NameNode还没有来得及和DataNode心跳同步，就会出现访问出错的情况。
所以宁可让NameNode等待一轮时间，也不要访问错误的信息。

SecondaryNameNode（SNN）

1. 在非Ha(高可用)模式下，SNN一般是独立的节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间。
2. 根据配置文件设置的时间间隔fs.checkpoint.period  默认3600秒做一次合并。
3. 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB，达到最大值做一次合并。

总结

NameNode-->NN，SecondaryNameNode-->SNN
1. NN开机，创建一个空Editlog和FsImage。
2. 到达指定条件，SNN会把NN的Editlog和FsImage拉到自己主机，将增量日志合并到快照内。
3. 合并完成后再将完整快照推送给NN
4. 这样NN就会得到完整的滚动快照

Block副本放置策略

第一个副本：放置在上传文件的DN。如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点。
第二个副本：放置在于第一个副本不同的机架的节点上。
第三个副本：与第二个副本相同机架的节点。
更多副本：随机节点。

HDFS读写流程

HDFS写

1. Client和NN连接创建文件元数据
2. NN判定元数据是否有效
3. NN处发副本放置策略，返回一个有序的DN列表
4. Client和DN建立Pipeline连接
5. Client将块切分成packet（64KB），并使用chunk（512B）+chucksum校验（4B）填充
6. Client将packet放入发送队列dataqueue中，并向第一个DN发送
7. 第一个DN收到packet后本地保存并发送给第二个DN
8. 第二个DN收到packet后本地保存并发送给第三个DN
9. 这一个过程中，上游节点同时发送下一个packet
10. 生活中类比工厂的流水线：结论：流式其实也是变种的并行计算
11. Hdfs使用这种传输方式，副本数对于client是透明的
12. 当block传输完成，DN们各自向NN汇报，同时client继续传输下一个block
13. 所以，client的传输和block的汇报也是并行的

HDFS读

1. 为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。

2. 如果在读取程序的同一个机架上有一个副本，那么就读取该副本。

3. 如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。

4. 语义：下载一个文件：

   • Client和NN交互文件元数据获取fileBlockLocation
   • NN会按距离策略排序返回
   • Client尝试下载block并校验数据完整性

5. 语义：下载一个文件其实是获取文件的所有的block元数据，那么子集获取某些block应该成立

   • Hdfs支持client给出文件的offset(偏移量)自定义连接哪些block的DN，自定义获取哪些块的数据
   • 这个是支持计算层的分治、并行计算的核心