HDFS原理

HDFS 基本原理分析

HDFS实现源于Google的一篇论文(Google File System)。意在解决海量数据存储的问题。随着互联网络的发展,海量数据产生,而使用传统的关系型数据库存储数据带来诸多的不便。比如产品的使用过程中产生各种非结构化数据不便于存储于传统的关系型数据库中,其次数据量过大超过了传统的关系型数据库软件处理的能力,严重降低了数据处理的效率。而以Google的GFS为理论构建的HDFS正式为了解决这个问题。HDFS本身是一个分布式的文件系统,是Hadoop生态中的最基本的组件之一,海量数据的存储实现都是以HDFS为基准的。

HDFS 组成单元

HDFS主要由三部分组成NameNode DataNodes 和 Secondary NameNode。一般是一个NN,SNN和多个DN构成整个系统。分布式文件系统中,存储的文件会被划分成多个块(每一个块称为一个block,一个block的默认大小为64MB,该值是可以设置的,并且默认每一个block都有三个副本)存放在不同的节点上。HDFS中的DataNodes即是用于存储这些数据的分块,而NameNode 则是专门用于存放这些分块数据信息的元数据。元数据包分布式文件系统中存储的文件的名称,以及文件的分块(block)与其存储节点的映射关系信息。NameNode 与Secondary有自己的独有的一套元数据管理机制,保证系统存储的元数据信息

HDFS 整体架构

HDFS整体架构

NameNode 操作元数据机制

NameNode 接受客户端的文件的读写请求。NameNode 里面有两个重要的文件,第一是fsimage 存储到硬盘的元数据(部分)。包含文件名称,文件拥有者以及权限,以及block信息(文件被分解为多少个block)。但是不会保存block存储于DataNodes节点的信息,这个信息是DataNodes启动后会上报到NameNode内存,所以block位置信息是不会进入到fsimage文件中。这个fsimage文件在NameNode启动时会从硬盘加入到内存。第二个重要文件是edits文件,记录对元数据操作的日志。

Secondary NameNode 操作元数据机制

SNN 并不是对NN的备份,用于合并edits文件与fsimage文件。fsimage文件内容在NN启动的时候就被载入到内存中,但是系统中客户端对文件的操作是不会实时写入到fsimage里面,从设计的角度讲这个也不是很现实,而这种操作记录在edits文件里面。因此在一段时间中内存中的元数据和实际NN磁盘中的fsimage信息就不一致了,而edits日志文件却详细的记录了客户端对文件系统中文件操作的信息,所以SNN的作用就是在一个时间间隔内让fsimage数据能够与内存中的元数据同步,下图是SNN 同步元数据的流程图

SNN

SNN合并日志与元数据文件的时机由两个参数决定,如下表所示

configurationdescriptions
fs.checkpoint.period设置合并的时间间隔,默认为3600秒,即是每隔这么多时间进行一次日志与元数据文件的合并
fs.checkpoint.size设置edits文件的大小,默认64MB当超过这个值时自动完成合并

DataNodes 存储Block数据机制

DataNodes 存储文件的block信息。当DN被启动时,会向NN汇报相关的block信息(这部分信息不回被NN存储在fsimage上面)。其次更重要的一点,它会向NN每三秒发送一条心跳信息,保持与NN的联系如果10分钟NN没有收到DN的心跳那么它会人为DN已经死掉,采取措施拷贝当前DN上的blocks到其他节点上,保持整个集群中blocks充足。

这三个部分的相应功能的表格如下

NameFunctionsDescriptions
NameNode存储HDFS中的元数据(元数据是存储的文件数据之外的数据)。元数据在内存当中,包含文件名称,blocks信息以及block与DN节点的映射关系一般的集群中只有这么一个NN。因此这种集群本身就容易发生单点的故障,所以在2.x的集群中会有一个HA的HDFS构建集群方式,保证整个系统的高可用性
DataNodes磁盘存储文件数据信息,维护blockid到DN本地文件的映射关系HDFS分布式文件系统中存储数据的节点
Secondary NameNode用于合并NameNode中的Fsimage信息,保证fsimage中的元数据与内存元数据的一致性SNN并不是NN的一个备份,而是用于合并元数据操作日志与NN磁盘中的元数据

HDFS 的优缺点

HDFS的优点如下:
1. 具有加高的容错性:HDFS系统中数据有多个副本,副本丢失后有机制保证集群中的副本数量不会少。
2. 适合于批量计算:HDFS使用的计算场景是让计算程序往数据靠近,HDFS之上的计算框架都有计算程序靠近数据的特点,让程序靠近数据而不是传递数据到程序进行计算。
3. 适合海量数据处理的场景:比如GB,TB,PB 级别的数据处理场景。
缺点如下:
1. 低延迟数据访问的场景:HDFS本身还是一个文件系统,针对于较快的数据访问场景并不合适,因此它本身更适合配合与离线的海量数据计算场景而不是实时的大量数据的计算场景。
2. 不适合存储大量的小文件。每一个存储于系统中的文件都会产生相关的元数据,而元数据在NN节点中是存在于内存当中的,所以如果是海量的小文件存储必然导致NN的内存有较高的占有率,导致整个系统的性能降低。
3. 不支持文件的并发写入与随机修改:HDFS文件系统并不是所用文件系统的功能都具备,它不支持并发的写入一个文件,同时文件本身的内容更改只支持追加,不支持随机的插入,修改。

HDFS的读文件实现

HDFS的读文件的流程图如下:

Read

值得注意的一点是,客户端首先需要到NN处得到block的位置信息,然后通过API到相关的数据节点获取数据。

HDFS的写文件实现

HDFS的写流程如下:

Write

值得一提的是写过程当在NN中创建的元数据信息,往DN中写入数据的过程并不是并行的过程,而是一个数据节点副本写完整后通过管道完成其他节点副本的写入。

小结

HDFS文件系统是hadoop生态中非常基础的一部分。它使得海量数据的分布式存储于访问得到了实现,同时也是一些分布式计算框架数据读取与存储的基石。当然文中提到的是HDFS中最基础的部分,高级的部分后续不断更新。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值