hadoop之hdfs分布式文件

架构

HDFS是一个主从(Master/Slaves)架构
由一个NameNode和一些DataNode组成
面向文件包含：文件数据(data)和文件元数据(metadata)
NameNode：负责存储和管理文件元数据，并维护了一个层次型的文件目录树
DataNode：负责存储文件数据(block块)，并提供block的读写
DataNode与NameNode维持心跳，并汇报自己持有的block信息
Client和NameNode交互文件元数据和DataNode交互文件block数据

角色（角色即进程）

NameNode
1）完全基于内存存储文件元数据、目录结构、文件block的映射
2）需要持久化方案保证数据可靠性
3）提供block副本放置策略
DataNode
1）基于本地磁盘存储block(文件的形式)
2）并保存block的校验和数据保证block的可靠性
3）与NameNode保持心跳，汇报block列表状态
SecondaryNameNode（SNN）
1）在非Ha模式下，SNN一般是独立的节点，周期完成对NN的EditLog向FsImage合并，减少EditLog大小，减少NN启动时间
2）根据配置文件设置的时间间隔fs.checkpoint.period  默认3600秒
3）根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB

存储模型

文件线性按字节切割成块(block)，具有offset，id
文件与文件的block大小可以不一样
一个文件除最后一个block，其他block大小一致
block的大小依据硬件的I/O特性调整
block被分散存放在集群的节点中，具有location
Block具有副本(replication)，没有主从概念，副本不能出现在同一个节点，副本是满足可靠性和性能的关键
文件上传可以指定block大小和副本数，上传后只能修改副本数
一次写入多次读取，不支持修改，支持追加数据

block副本放置策略

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

数据持久化

数据持久化一般有以下两种方案：

1）日志文件：记录实时发生的增删改查
优点：数据完整性好
缺点：加载恢复数据慢，占用内存空间大

2）镜像、快照、dump、db、序列化：间隔（秒、分钟、小时），内存全量数据基于某个时刻做的数据快照，
优点：恢复数据快
缺点：IO慢，容易丢失数据

hdfs 选择了1和2方案结合的方式，充分利用其各自优点
NN 使用了FsImage+EditLog整合的方案，本地磁盘保存 EditLog 和 FsImage
滚动将增量的EditLog更新到FsImage，以保证更近时点的FsImage和更小的EditLog体积

Editslog：日志文件   体积小，记录少
FsImage：镜像、快照  更快的滚动更新时点
例如：现在是10点，HDFS存储的是：FI（9点）快照+ EL（9-10点）日志，此时如果宕机，恢复数据时则是先加载FI、然后加载EL就会得到之前的全量数据

安全模式

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

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

hdfs写流程

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

hdfs读流程

为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。
下载一个文件：
Client和NN交互文件元数据获取fileBlockLocation，NN会按距离策略排序返回
Client尝试下载block并校验数据完整性
下载一个文件其实是获取文件的所有的block元数据，那么子集获取某些block应该成立
Hdfs支持client给出文件的offset自定义连接哪些block的DN，自定义获取数据
这个是支持计算层的分治、并行计算的核心

 

hdfs HA解决方案

单点故障：
    高可用方案：HA（High Available）
    多个NN，主备切换
主压力过大，内存受限：
    联帮机制： Federation（元数据分片）
    多个NN，管理不同的元数据
HADOOP 2.x 只支持HA的一主一备，3.x 支持一主多备

hdfs HA解决方案
1）多台NN（>= 2台）主备模式，主NN是 Active 状态，备NN是 Standby 状态
2) JournalNode（JN） 角色（>= 3台）负责同步 NN 的 Editslog，保证NN数据的最终一致性
3）ZKFC角色（与NN同台），通过 ZK 集群协调NN的主从选举（写入唯一目录成功）和切换事件回调机制
4）DN同时向 NNs 列表汇报 block 清单

hdfs NN压力过大、内存受限解决方案：Federation（联邦机制）
1）NN采用分片机制（不用业务存放到不同的NN中），即元数据分治，复用DN存储
2）元数据访问隔离性
3）DN目录隔离 block