HDFS系统详解

HDFS设计原理、核心概念以及上传原理

目录

• HDFS设计原理
• HDFS核心概念
• 上传

1. HDFS设计原则

1.1 设计目标

• 存放非常大的文件
• 采用流式数据的访问方式；一点一点的读，而不是一次读全部
• 运行在商业集群上面

1.2 HDFS不适用场景类型

• 低延迟访问 对延时要求在毫秒级别的应用，不适合采用HDFS。HDFS是为高吞吐数据传输设计的,因此可能牺牲延时HBase更适合低延时的数据访问。
• 大量小文件 由于每个文件的信心都会由Namenode记录，当小文件过多时，整个系统会受到内存限制，效率降低
• 多方读写，需要任意修改

2. HDFS核心概念

2.1 Block

每个文件都是由一个一个的Block组成（Block默认大小128M），例如一个300M的文件会被保存成3个Block，而一个3K的文件也统一会占用一个Block，只不过这个Block只会占用3K

DataNode使用Block存放的原因：

• 方便大文件的存放
• 可用性更高
• Block有规律的存放和读取

鉴于DataNode的保存机制，在使用hdfs 的时候需要注意什么

2.2 NameNode&&DataNode

整个HDFS采用两类节点管理，即一个NameNode和多个DataNode。

2.2.1 Namenode

管理整个文件系统的目录树以及所有的文件、目录和元数据。元数据持久化为两种形式：

• fsimage :整个Namenode的快照
• edit log : 上次快照到目前为止的所有操作信息

fsimage、edit log会在首次hdfs系统formate的时候创建，再以后的 formate 会对fsimage、editlog进行删除后重建，不会对整个系统文件产生影响。重启集群后DataNode会重新想NameNode发送Block信息，NameNode重新获得整个集群的数据

2.2.2 DataNode

数据节点负责存储和提取Block，读写请求可能来自namenode，也可能直接来自客户端。数据节点周期性向Namenode汇报自己节点上所存储的Block相关信息。

2.3 HDFS Federation

产生原因：

由于在一个庞大集群当中会有很多操作，而将所有操作都记录到同一个节点的NameNode的editlog上时，可能存在内存不够用的情况。

解决办法：

HDFS Federation是一种横向拓展的方式，在HDFS Federation中，每个NameNode都只记录一个命名空间。例如：/usr，可以只交给一个NameNnode管理

2.4 备份机制

在Namenode的上传保存一个文件时，是以Block的形式保存，默认会保存三份。

mark

备份机制

• 第一份会放在存储最少的节点上
• 放在另一个机架的节点上面
• 放在当前机架的另一个节点上面
• 备份的数量最高为当前节点的数量

2.5 HDFS HA(High Availability)

产生原因：

当NameNode出现某些异常宕机时，整个系统将变得无法访问

解决办法：

HDFS HA(High Availability)，通过启动两个NameNode，分别处于Active-Standby。当Active节点失效时，Standby会顶替上，在处理的过程中也没有任何中断的迹象

• NameNode之间需要通过High Availability共享实现编辑日志共享，Standby节点接管工作以后会读取日志文件，实现与Active节点状态同步
• DataNode会同时向两个节点发送Block信息，因为数据块映射信息存放在内存当中，而非磁盘

High Availability实现共享的方式有两种

• NFS过滤器
• 集群日志管理(QJM,quorum journal manager):QJM是一个专用的HDFS实现，为其提供一个高可用的编辑日志而设计，每一次的编辑都写入多个日志节点

文件上传

文件上传流程

mark

1. 客户端找到Namenode进行上传
2. Namenode返回是否可以上传，以及上传的信息，包含分成的BLock以及每块上传的地址
3. 客户端与DataNode建立连接上传数据
4. Namenode指挥DataNode对上传的文件进行备份