HDFS存储原理

1. 引言

在整个 hadoop 框架中,主要存在三个组件:HDFS、MapReduce 和 YARN,HDFS 主要负责数据的存储,MapReduce 则数据模型的运算,YARN 负责资源的调度。接下来的博文会对这几个组件进行一一介绍,这篇博文先聊一聊 HDFS 的存储原理。

2. HDFS实现机制

HDFS 主要是为了应对海量数据的存储,由于数据量非常大,因此一台服务器是解决不能够应付的,需要一个集群来存储这些数据。在这个集群中,存在一个 NameNode 节点,该节点用于管理元数据,即用户上传的文件位于哪个服务器上,都多少个副本等信息。此外,还有多个 DataNode 节点,这些节点就是文件存储位置。文件存储到集群中需要考虑以下这几个问题:

  1. 保证数据的安全性,即数据应该有足够多的副本
  2. 能够适应高并发的访问
  3. 因为这些数据是存储在多个服务器上的,因此需要保证每个服务器的负载均衡

HDFS 的设计很巧妙,完美的解决了这几个问题。当用户上传一个文件时,会提供一个 虚拟路径,该路径是方便客户端对文件进行读写操作的,NameNode 中存在该路径和真实的存储物理路径的映射。NameNode 会先判断上传的文件是否存在,如果不存在,则允许用户继续上传。

客户端收到服务器允许上传文件的响应之后,会将该文件分为一个个块(block),每个块默认大小为 128MB,将每个块依次发送到 Datanode 中,由 NameNode 记录块的存储位置等信息存储在元数据中。为了保证数据有足够多的副本,这时服务器会进行一个异步的操作,将这个块再进行复制操作,随机存储到一个 DataNode 中(这里随机存储是为了保证服务器的负载均衡,避免多个客户端对同一个文件进行访问,这个文件和其副本都存储在同一个 DataNode 节点上的情况)。存储的大致过程如下:

HDFS存储原理

3. NameNode 工作原理

上面讲述了 HDFS 的实现机制,不过这样存储实际上只解决了两个问题:数据的安全性和每个服务器的负载均衡,但是当多个客户端同时上传文件时,都需要访问 NameNode 节点,在这种高并发的情况下,NameNode 是如何应付的呢?

上面说过,NameNode 是通过元数据来定位文件的存储路径的,如果元数据只是存储在磁盘文件中,当多个客户端同时访问时,响应速度就会受到限制。HDFS 是这样解决这个问题的:首先,会有一个 fsimage文件,用于存储所有的元数据,fsimage 文件中的数据会 加载到内存中,这样就提高了读取文件的速度。除此之外,还有一个 edits log 文件用于存储最新上传文件的元数据,这个文件大小是有限制的,一般为 64MB。当 edits log 文件存储大小达到 64MB 时,就会将这些元数据添加到 fsimage 文件中。整个操作流程如下:

HDFS存储原理

通过这样的设计,由于内存读取数据非常快,因此能够适应多个客户端同时访问的压力。而且当服务器碰到意外情况时,例如突然断电或者服务器崩溃等情况,虽然内存中的元数据会丢失,但由于 edits log 和 fsimage 存储着元数据,依然可以找到文件存储的真实路径,只是在服务器恢复之前不能够再进行上传和下载操作了。(不过有一个 HA 机制可以避免 NameNode 崩溃之后还可以继续提供服务,这个稍后再进行了解。)

由于 edits log 是日志,其存储的格式与元 fsimage 存储的元数据格式不一样,在进行合并操作时,需要进行额外的逻辑运算,如果这些运算直接在 NameNode 中进行的话,无疑会增大 CPU 的负荷,HDFS 便将这些操作放在 Secondary Node 中进行,整个过程如下:

HDFS存储原理

:这是我对 HDFS 存储机制的理解,由于刚开始接触 HDFS,因此文中可能会有错误,欢迎指正。

相关推荐