大数据-hadoop-hdfs

Hadoop分布式文件系统(HDFS)是指被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统(Distributed File System)。它和现有的分布式文件系统有很多共同点。但同时,它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束,来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。

HDFS有着高容错性(fault-tolerant)的特点,并且设计用来部署在低廉的(low-cost)硬件上。而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relax)POSIX的要求(requirements)这样可以实现流的形式访问(streaming access)文件系统中的数据。

•存储模型

•架构设计

•角色功能

•元数据持久化

•安全模式

•副本放置策略

•读写流程

•安全策略


1.存储模型

文件线性按字节切割成块(block),具有offset,id

文件与文件的block大小可以不一样

一个文件除最后一个block,其他block大小一致

block的大小依据硬件的I/O特性调整

block被分散存放在集群的节点中,具有location

Block具有副本(replication),没有主从概念,副本不能出现在同一个节点

副本是满足可靠性和性能的关键

文件上传可以指定block大小和副本数,上传后只能修改副本数

一次写入多次读取,不支持修改

支持追加数据

2.架构设计

HDFS是一个主从(Master/Slaves)架构

由一个NameNode(主)和一些DataNode(从)组成

面向文件包含:文件数据(data)和文件元数据(metadata)

NameNode负责存储和管理文件元数据,并维护了一个层次型的文件目录树

DataNode负责存储文件数据(block块),并提供block的读写

DataNode与NameNode维持心跳,并汇报自己持有的block信息

Client客户端和NameNode交互文件元数据和DataNode交互文件block数据

角色即进程 namenode data node client都是一个JVM进程

大数据-hadoop-hdfs_第1张图片
大数据-hadoop-hdfs_第2张图片

3.角色功能

NameNode

•完全基于 内存 存储文件元数据、目录结构、文件block的映射

•需要持久化方案保证数据可靠性

•提供副本放置策略

DataNode

•基于本地磁盘存储block(文件的形式)

•并保存block的(md5)校验和数据保证block的可靠性

•与NameNode保持心跳,汇报block列表状态

4.元数据持久化

数据持久化

日志:记录实时发生的增删改的操作 mkdir /abc

完整性比较好

加载恢复数据: 慢/占空间

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

间隔 容易丢失一部分数据

内存全量数据基于某一个时间点做的像磁盘的溢写

HDFS 对于以上两者 同时使用:

日志:EditsLog 优点:体积小 记录少

镜像:FsImage、快照 优点:更快的滚动更新时间点

最近时点的FsImage + 增量的Editslog

现在10点

FI: 9点 +9点到10点的增量的EL

  1. 加载 FI

  1. 加载EL

  1. 内存就得到了关机前的全量数据!

那么:FI 时点是怎么滚动更新的?

由NN 8点溢写 9点溢写。。

NN:第一次开机的时候,只写一次FI 假设8点 到9点的时候EL记录 的是8-9 的日志

只需要将8-9的日志的记录更新到8 点的FI中, FI的数据时点就变成了9点

寻求另外一台机器来做这个事情。

•任何对文件系统元数据产生修改的操作,Namenode都会使用一种称为EditLog的事务日志记录下来

•使用FsImage存储内存所有的元数据状态

•使用本地磁盘保存EditLog和FsImage

•EditLog具有完整性,数据丢失少,但恢复速度慢,并有体积膨胀风险

•FsImage具有恢复速度快,体积与内存数据相当,但不能实时保存,数据丢失多

•NameNode使用了FsImage+EditLog整合的方案:

•滚动将增量的EditLog更新到FsImage,以保证更近时点的FsImage和更小的EditLog体积

5.安全模式

NameNode 存元数据: 文件属性/ 每个块存在哪个dateNode上

在持久化的时候:文件属性会持久化,但是文件的每一个块不会持久化

恢复的时候 NN会丢失块的位置信息

为了避免分布式时代 数据不一致

会等, Data node会和name node建立心跳,汇报块信息(安全模式)

流程:

•HDFS搭建时会格式化,格式化操作会产生一个空的FsImage

•当Namenode启动时,它从硬盘中读取Editlog和FsImage

•将所有Editlog中的事务作用在内存中的FsImage上

•并将这个新版本的FsImage从内存中保存到本地磁盘上

•然后删除旧的Editlog,因为这个旧的Editlog的事务都已经作用在FsImage上了

•Namenode启动后会进入一个称为安全模式的特殊状态。

•处于安全模式的Namenode是不会进行数据块的复制的。

•Namenode从所有的 Datanode接收心跳信号和块状态报告。

•每当Namenode检测确认某个数据块的副本数目达到这个最小值,那么该数据块就会被认为是副本安全(safelyreplicated)的。

•在一定百分比(这个参数可配置)的数据块被Namenode检测确认是安全之后(加上一个额外的30秒等待时间),Namenode将退出安全模式状态。

接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些数据块复制到其他Datanode上

5.1 HDFS中的SNN

SecondaryNameNode(SNN)

•在非Ha(high avaliable)模式下,SNN一般是独立的节点,周期完成对NN的EditLog向FsImage合并,减少EditLog大小,减少NN启动时间

•根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒

•根据配置文件设置editslog大小fs.checkpoint.size规定edits文件的最大值默认是64MB

大数据-hadoop-hdfs_第3张图片

6. Block的副本放置策略

▪第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。 (放在本机)

▪第二个副本:放置在于第一个副本不同的机架的节点上。(出机架)

▪第三个副本:与第二个副本相同机架的节点。

▪更多副本:随机节点。

7. HDFS读写流程

7.1 HDFS的写流程

某一时间点 传一个块的:

大数据-hadoop-hdfs_第4张图片

•Client和NN连接创建文件元数据

•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的汇报也是并行的

7.2 HDFS读流程

大数据-hadoop-hdfs_第5张图片

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

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

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

•语义:下载一个文件:

•Client和NN交互文件元数据获取fileBlockLocation

•NN会按距离策略排序返回

•Client尝试下载block并校验数据完整性

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

•Hdfs支持client给出文件的offset自定义连接哪些block的DN,自定义获取数据

想读哪读哪 而不是必须要从头开始读

•这个是支持计算层的分治、并行计算的核心

你可能感兴趣的:(大数据,hadoop,hdfs)