Hadoop 是一个能够让用户轻松架构和使用的分布式计算平台,用户可以在 Hadoop上管理、开发和运行处理大规模数据的应用,其中,Hadoop分布式文件系统 (Hadoop Distributed File System, HDFS) 以文件系统的形式为应用提供海量数据存储服务。

一、概述

HDFS作为一个分布式文件系统,具有高容错的特点,它可以部署在廉价的通用硬件上,提供高吞吐率的数据访问,适合那些需要处理海量数据集的应用程序。

1.1. HDFS 主要特性

HDFS作为一个分布式文件系统,具有高容错的特点,它可以部署在廉价的通用硬件上,提供高吞吐率的数据访问,适合那些需要处理海量数据集的应用程序。

had0090
  1. 支持超大文件
  1. 流式的数据访问

    HDFS 的设计建立在一次写入、多次读写 任务的基础上。HDFS 应用对文件要求的是 write-one-read-many 访问模型。一个文件经过创建、写,关闭之后就不会改变。这一假设简化了数据一致性问题,使高吞吐量的数据访问成为可能。

  2. 只须运行在低廉的商用硬件集群上,而无需在昂贵的高可用性机器上

正是由于以上的设计目标,HDFS并不适合如下应用

  • 低延迟数据访问

    低延迟数据,如和用户进行交互的应用,需要数据在毫秒或秒的范围内得到响应。由于Hadoop针对高数据吞吐量做了优化,而牺牲了获取数据的延迟,对于低延迟访问,可以考虑使用 HBase 或 Cassandra

  • 大量的小文件

    HDFS 支持超大文件,是通过将数据分布在数据节点 DataNode ,并将文件的元数据保存在名字节点 NameNode 上。NameNode 的内存大小决定了HDFS 文件系统可保存的文件数量,大量的小文件还是会影响 NameNode 的性能

  • 不支持多用户写入及任意修改文件

    在 HDFS 的一个文件中只有一个写入者,而且写操作只能在文件末尾完成,即只能执行追加操作,目前 HDFS 还不支持多个户对同一文件的写操作,以及在文件任意位置进行修改。

二、HDFS 架构

HDFS 采用了主从(Master/Slave)体系结构,NameNode、数据节点 DataNode 和客户端Client是HDFS中3个重要的角色。

2.1. Hadoop 1.x

2.1.1. NameNode

NameNode 是 Hadoop 分布式文件系统的核心,架构中的主角色。它维护和管理文件系统元数据,包括名称空间目录树结构、文件和块的位置信息、访问权限等信息。基于此,NameNode 成为了访问 HDFS 的唯一入口。

内部通过内存和磁盘两种方式管理元数据。其中磁盘上的元数据文件包括Fsimage内存元数据镜像文件和edits log (Journal) 编辑日志。

在HDFS中,Namenode管理的元数据具有两种类型:

  1. 文件自身属性信息

文件名称、权限,修改时间,文件大小,复制因子,数据块大小。

  1. 文件块位置映射信息

记录文件块和DataNode之间的映射信息,即哪个块位于哪个节点上。

在 Hadoop2 之前,NameNode 是单点故障。

2.1.2. Secondary NameNode

Secondary NameNode 出现在 Hadoop1.x 版本中,在 Hadoop2.x 以后的版本中此角色消失。如果充当 Datanode 节点的一台机器宕机或者损害,其数据不会丢失,因为备份数据还存在于其他的 Datanode 中。但是,如果充当 Namenode 节点的机器宕机或损害导致文件系统无法使用,那么文件系统上的所有文件将会丢失,因为我们不知道如何根据 Datanode 的块重建文件😭。因此,对 NameNode 实现容错非常重要。

Hadoop 提供了两种机制实现高容错性。

  • Secondary NameNode 工作,分担 Namenode 工作量。比如定期合并 FsImage 和 Edits ,防止编辑日志文件过大,并且能保证其信息与 NameNode 信息保持一致,并推送给 NameNode

  • 紧急情况下,可以辅助恢复 NameNode

SecondaryNameNode 一般在另一台单独的物理计算机上运行,因为它需要占用大量 CPU 时间来与 Namenode 进行合并操作,一般情况是单独开一个线程来执行操作过程。但是,SecondaryNameNode 保存的信息永远是滞后于 NameNode ,所以在 NameNode 失效时,难免会丢失部分数据。

SecondaryNameNode 主要工作是帮助 NameNode 合并 edits 和 fsimage,减少 Namenode 的启动时间

SecondaryNameNode 执行合并的时机决定于:

  • 配置文件设置的时间间隔 **fs.checkpoint.period**,默认为 3600 秒。

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

  • 第一阶段:NameNode 启动

    • 第一次启动 NameNode 格式化后,创建 FsImage 和 Edits 文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
    • 客户端对元数据进行增删改的请求
    • NameNode 记录操作日志,更新滚动日志。
    • NameNode 在内存中对数据进行增删改查
  • 第二阶段:Secondary NameNode 工作

    • Secondary NameNode 请求 NameNode 是否需要 checkpoint。直接带回 NameNode 是否需要检查结果。checkpoint 触发条件:定时时间和Edits 数据已满
    • Secondary NameNode 请求执行 checkpoint
    • NameNode 滚动正在写的 Edits 日志
    • 将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode
    • Secondary NameNode 加载编辑日志和镜像文件到内存,并合并。生成新的镜像文件fsimage.chkpoint
    • 拷贝 fsimage.chkpoint 到 NameNode
    • NameNode 将 fsimage.chkpoint 重新命名成 fsimage

2.1.3. DataNode

DataNode是Hadoop HDFS中的从角色,负责具体的数据块存储,维护了 blockId 与 datanode 本地文件的映射。DataNode的数量决定了HDFS集群的整体数据存储能力。通过和 NameNode 配合维护着数据块。

2.1.4. Client

客户端是用户和 HDFS 进行交互的手段,HDFS 提供了各种各样的客户端,包括命令行接口、Java API、 Thrift接口等。

  • 职责

    • 文件切分。文件上传 HDFS 的时候,client 将文件切分成一个一个的 Block,然后进行上传。

    • 和 NameNode 进行交互,获取文件的位置信息。

    • 和 DataNode 进行交互,读取或写入文件

    • 提供一些命令来管理 HDFS,如 NameNode 格式化

    • 提供一些命令来访问HDFS,如 NameNode 增删改查操作。

2.2. Hadoop 2.x

Hadoop2 中引入的高可用性。在同一个 HA HDFS 集群中,将会同时运行两个 Namenode 实例,其中一个为 Active Namenode,用于实时处理所有客户端请求;另一个为 Standby Namenode,Standby Namenode 的命名空间与 ActiveNamenode 是完全保持一致的。所以当 ActiveNamenode 出现故障时,Standby Namenode 可以立即切换成 Active 状态。

2.2.1. Active NameNode

2.2.2. StandBy NameNode

HDFS2.X 版本中加入了 Namenode HA 策略,这使得 HA 机制下检查点操作的流程与非 HA 机制下的完全不同,因为在 HA 配置下已经没有 Secondary Namenode 这个节点了,而是直接通过配置奇数个 JournalNode 来实现 Namenode 热备 HA 策略。

2.3. Namespace

HDFS支持传统的层次型文件组织结构。用户可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。

Namenode负责维护文件系统的namespace名称空间,任何对文件系统名称空间或属性的修改都将被Namenode记录下来。

HDFS会给客户端提供一个统一的抽象目录树,客户端通过路径来访问文件

形如: hdfs://namenode:port/dir-a/dir-b/dir-c/file.data。

2.4. 总结

2.4.1. Secondary NameNode 和 Standby NameNde的区别

  1. Secondary NameNode
    HDFS 单 NameNode节点的情况下(即非高可用HA),Secondary NameNode负责每隔一段时间将旧的fsimage文件和edits log文件merge成新的fsimage并替换,即为NameNode 合并编辑日志edits log,减少NameNode 启动时间,一旦NameNode挂了,可能会导致元数据丢失;
  2. Standby NameNde
    HDFS主从架构情况下(即高可用HA,生产环境都是用HA的),Active NameNode 和 Standby NameNode,后者会实时同步前者的fsimage,并将merge后的新fsimage文件替换前者中旧的fsimage文件,实时merge,一旦前者Active NameNode,Standby NameNode 能够马上顶替,不会出现元数据丢失;

即非 HA 时,有 Secondary NameNode;HA 时,有 Standby NameNode。

三、设计思想

HDFS集群遵循主从架构。每个群集包括一个主节点和多个从节点。在内部,文件分为一个或多个块,每个块根据复制因子存储在不同的从节点计算机上。主节点存储和管理文件系统名称空间,即有关文件块的信息,例如块位置,权限等。从节点存储文件的数据块。主从各司其职,互相配合,共同对外提供分布式文件存储服务。当然内部细节对于用户来说是透明的。

3.1. 主从架构

HDFS采用master/slave架构。每个群集包括一个主节点和多个从节点。其中: NameNode 是主节点,负责存储和管理文件系统元数据信息,包括 namespace 目录结构、文件块位置信息等;DataNode是从节点,负责存储文件具体的数据块。

3.2. 分块机制

HDFS 中的文件在物理上是分块存储 (block) 的,HDFS 首先把一个文件分割成多个块,然后再把这些文件块存储在不同服务器上。这种方式的优势就是不怕文件太大,并且读文件的压力不会全部集中在一台服务器上,从而可以避免某个热点文件会带来的单机负载过高的问题

块的大小可以通过配置参数来规定,参数位于 hdfs-default.xml 中: dfs.blocksize 。默认大小是 128M

3.3. 副本机制

为了容错,文件的所有 block 都会有副本。每个文件的 block 大小 dfs.blocksize 和副本系数 dfs.replication 都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后通过命令改变。

默认 dfs.replication 的值是 3,也就是会额外再复制 2 份,连同本身总共 3 份副本。