开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第19天，点击查看活动详情
前言
继续学习，今天学习Hadoop-HDFS的角色功能要点和元数据持久化方案和要点。
角色功能要点
NameNode
- 完全基于内存存储文件元数据、目录结构、文件block的映射
- 需要持久化方案保证数据可靠性
- 提供副本放置策略
DataNode
- 基于本地磁盘存储block(文件的形式)
- 并保存block的校验和数据保证block的可靠性
- 与NameNode保持心跳，汇报block列表状态
在HDFS中，最重要的两个角色就是NameNode和DataNode。阿里推荐一个集群最好不要超过5000个节点，因为节点数量太多对网络的使用和业务数据的访问可能会造成影响。
因为集群中只有一个NameNode，所有的数据存储都要先经过NameNode分配位置，所有NameNode要尽可能快的响应请求。内存寻址速度是I/O寻址速度的10万倍，所以NameNode是完全基于内存存储文件元数据。一般内存不是持久化存储，断电会遗失数据，除了不可靠之外，还受大小限制，所以需要持久化方案保证数据可靠性。
DataNode以文件的形式保存block后，还要保存DataNode的校验值，这是为了之后客户端在读取数据后可以通过校验值比对获取的文件是否完整正确。
元数据持久化
数据持久化方案
现在大多数数据库保证持久化可靠性，一般有两种方案，两种方案各有优劣，正常是选一种作为持久化方案。
1、日志文件
记录实时发生的增删改的操作。
每当执行一个操作时，就将操作记录（追加append）到一个日志文件中，当系统发生异常重启后，元数据丢失了，但是可以通过顺序执行操作日志，一步步恢复元数据。
日志文件的优点是完整性比较好，但是在加载恢复数据的时候速度比较慢，而且日志文件体积相对较大，会占用较大的空间。
2、镜像、快照、dump、db
这种方案就是内存全量数据基于某一时间点做的向磁盘的溢写，发生时间是间隔的。这种方案的优点是恢复速度快，但因为是间隔的，容易丢失一部分数据。
HDFS持久化方案
EditsLog（日志）体积小，记录少，有日志方案的优势；
FsImage（镜像、快照）有滚动更新的时点。
HDFS的持久化方案是使用最近时点的FsImage和增量的EditsLog解决持久化问题，结合两种方案的优点相互弥补，提高性能。
例如当前时间是9点，HDFS有一个8点的快照和8点到9点的增量日志，如果这时候HDFS挂了，那么重启后HDFS会有以下步骤：
- 加载FsImage；
- 加载增量EditsLog；
- 基于8点的快照，根据增量EditsLog恢复数据。
接下来我们根据总结的元数据持久化要点来看看HDFS是如何实现持久化方案的。
元数据持久化要点
- 任何对文件系统元数据产生修改的操作，Namenode都会使用一种称为EditLog的事务日志记录下来
- 使用Fslmage存储内存所有的元数据状态
- 使用本地磁盘保存EditLog和FsImage
- EditLog具有完整性，数据丢失少，但恢复速度慢，并有体积膨胀风险
- Fslmage具有恢复速度快，体积与内存数据相当，但不能实时保存，数据丢失多
- NameNode使用了Fslmage+EditLog整合的方案:
- 滚动将增量的EditLog更新到Fslmage，以保证更近时点的Fslmage和更小的EditLog体积
