当前位置:   article > 正文

【HDFS】HDFS的整体架构设计,阅读笔记_hdfs总体设计

hdfs总体设计

HDFS是一个高度容错性的系统,适合部署在 廉价的机器上。

HDFS可能由成百上千的服务器构成,每个服务器上存储着文件系统的部分数据,构成系统的组件数目是巨大的,任一组件都有可能失效,这意味着总是有一部分HDFS的组件是不工作的,所以 HDFS的核心架构目标是错误检测和快速、自动的恢复

HDFS上的一个典型文件大小一般都在G字节至T字节
一个单一的HDFS实例应该能支撑数以千万计的文件

HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题,并且使高吞吐量的数据访问成为可能。

一个应用请求的计算,离它操作的数据越近就越高效,在数据达到海量级别的时候更是如此。
HDFS为应用提供了将它们自己移动到数据附近的接口。

架构

HDFS采用主从架构,一个HDFS集群有一个namenode和一定数目的datanode组成。
namenode是一个中心服务器,负责管理文件系统的名字空间(namespace)以及客户端对文件的访问(namenode去映射文件所在datanode)。
集群中的datanode一般是一个节点作为一个datanode,负责管理自己节点上的存储。

一个文件被分成一个或多个数据块,存储在一组datanode上。
namenode负责执行文件系统操作,确定数据块到具体datanode节点的映射。
datanode负责处理文件系统客户端的读写请求,在namenode的统一调度下进行数据块的创建、删除、复制。


HDFS采用JAVA开发,因此任何支持java的机器都可以部署namenode和datanode
集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者,这样,用户数据永远不会流过Namenode。

HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块,除了最后一个,所有的数据块都是同样大小的。为了容错,文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。HDFS中的文件都是一次性写入的,并且严格要求在任何时候只能有一个写入者。
Namenode全权管理数据块的复制,它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。


HDFS采用一种称为机架感知(rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。
通过一个机架感知的过程,Namenode可以确定每个Datanode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上。这样可以有效防止当整个机架失效时数据的丢失,并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中,有利于当组件失效情况下的负载均衡。但是,因为这种策略的一个写操作需要传输数据块到多个机架,这增加了写的代价。

在大多数情况下,副本系数是3, HDFS的存放策略是将一个副本存放在本地机架的节点上,一个副本放在同一机架的另一个节点上,最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输,这就提高了写操作的效率。机架的错误远远比节点的错误少,所以这个策略不会影响到数据的可靠性和可用性。于此同时,因为数据块只放在两个(不是三个)不同的机架上,所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下,副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上,三分之二的副本在一个机架上,其他副本均匀分布在剩下的机架中,这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。


HDFS会尽量让读取程序读取离它最近的副本

namenode启动后会进入一个 安全模式的特殊状态,这时候不会进行块复制,但是会通过块状态报告确认是否安全(数据块副本达到最小值的比例),安全后则退出,后续会确定哪些块副本未达标的将进行块复制。

EditLog事务日志,FsImage文件块映射、文件属性等
namenode在内存中保存映射表,这个数据结构设计紧凑,4G内存的namenode足够支撑大量的文件和目录;
当namenode启动时,从硬盘读取EditLog和FsImage,将所有的EditLog中的事务作用在内存的FsImage上,并将新的FsImage从内存保存到磁盘上,然后删除旧的EditLog,这就是检查点过程。
如果namenode很久都没有启动,那么EditLog是不是慢慢变的越来越大了(因为只有启动才会合并fsimage和edits),下一次启动很慢!!
所以 secondary namenode就应运而生了,负责定期合并fsimage和edits,将edits日志大小控制在一个限度下。和namenode在不同机器上



datanode启动时,扫描本地文件系统,产生一个本地文件对应的所有HDFS数据块的列表,将这块状态报告发送给namenode。
FsImage和Editlog是HDFS的核心数据结构。如果这些文件损坏了,整个HDFS实例都将失效。
因而,Namenode可以配置成支持维护多个FsImage和Editlog的副本。任何对FsImage或者Editlog的修改,都将同步到它们的副本上。这种多副本的同步操作可能会降低Namenode每秒处理的名字空间事务数量。然而这个代价是可以接受的,因为即使HDFS的应用是数据密集的,它们也非元数据密集的。当Namenode重启的时候,它会选取最近的完整的FsImage和Editlog来使用。



网络错误的解决,datanode失效??
每个datanode节点周期性的想namenode发送心跳信号。网络断开可能导致一部分datanode和namenode失去联系,namenode通过心跳信号的缺失将此datanode标记为宕机,不会在将新的IO请求发给它们。这进一步导致一些数据块的副本系数下降,namenode会不断检测需要复制的块并启动复制操作。


DFSAdmin
hadoop is deprecated,use hdfs

如何知道谁是admin呢??
启动NameNode的用户被视为HDFS的超级用户


副本系数减小
namenode感知到会将多余的副本删除,下个心跳会将该信息传递给datanode,datanode即将数据块删除,空闲空间加大。

fsck用来检查文件系统
用法:hadoop fsck [ GENERIC_OPTIONS ] <path> [-move | -delete | -openforwrite] [-files [-blocks [-locations | -racks]]]




HDFS小文件处理
小文件是指文件大小小于HDFS上block的大小的文件。这样的文件会给hadoop的扩展性和性能带来严重影响。
HDFS中,任何block,文件或者目录在内存中均以对象的形式存储,每个对象大约占用150字节。如果有N个小文件,每个文件占用一个block,那么namenode大约需要占用N*150 字节的空间,这样namenode的内存空间就严重制约了集群的扩展,而且访问大量小文件的速度远远小于访问几个大文件。
HDFS最初是为流式访问大文件开发的,如果访问大量的小文件,需要从一个datanode跳到另一个datanode,严重影响性能。
每一个小文件都要占用一个slot,task启动将耗费大量的时间,以及task释放。
HDFS文件存取流程
1、读文件
1》、client发送读文件请求给namenode,如果文件不存在,返回错误,否则将文件对应的block以及所在datanode位置发送给client。
2》、client收到文件位置信息后,与不同datanode建立socket连接并获取数据。
2、写文件
1》、client发送写文件请求,namenode检查文件是否存在,如果已存在,返回错误信息,否则发送给client一些可用的datanode节点
2》、client将文件分块,并行存储到不同datanode节点上,完成后,同时发送信息给namenode和datanode
3》、namenode收到client信息后,发送确认信息给datanode
4》、datanode同时收到namenode和datanode的确认信息后,提交写操作

hadoop自带的小文件解决方案
1、hadoop archive
将小文件存档成*.har文件,har是hdfs上一个文件系统,所有hdfs shell对har也可用
将文件归档成har文件

har的访问方式:




声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/寸_铁/article/detail/917737
推荐阅读
相关标签
  

闽ICP备14008679号