hadoop之hdfs分布式文件

  • Post author:
  • Post category:其他


架构

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



版权声明:本文为ywlmsm1224811原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。