HDFS 架构

,

简介

HDFS全称是Hadoop Distributed System。
HDFS是为以流的方式存取大文件而设计的, 适用于几百MB，GB以及TB，读多写少的场合。
而对于低延时数据访问、大量小文件、同时写和任意的文件修改，则并不是十分适合。

HDFS 架构

hdfs-architecture

HDFS包括元数据节点（NameNode）、数据节点（DataNode）

NameNode 管理文件系统的命名空间

  • 其将所有的文件和文件夹的元数据保存在一个文件系统树中
  • 这些信息也会在硬盘上保存成以下文件：命名空间镜像(namespace image)及修改日志(edit log)
  • 保存一个文件包括哪些数据块，分布在哪些数据节点上。然而这些信息并不存储在硬盘上，而是在系统启动的时候从 datanode 收集而成的

DataNode 文件系统中真正存储数据的地方

  • 客户端(client)或者元数据信息(namenode)可以向 datanode 请求写入或者读出数据块
  • 其周期性的向元数据节点回报其存储的数据块信息

Block 数据块

  • 在任何文件系统中，都将数据存储为 block 的集合。block 是硬盘上存储数据的不连续的位置。
  • HDFS 不会将每个文件存储在配置的 block 大小的确切倍数中。比如每个 block 的默认大小为 128M, 一个 514M 的文件将会存储在5个block 中, 前4个 block 大小为 128M，但是最后一个 block 的大小则仅为 2M

Metadata 元数据

  • NameNode 将整个 namespace，包括 block 到文件的映射、文件的属性等，都存储在一个称为 FsImage 的文件中，
    它被存放在内存以及本地文件系统中。而任何对于 namespace 元数据产生修改的操作，NameNode 都会使用一种称为 EditLog 的事务日志记录下来。
  • 例如在 HDFS 中创建一个文件，NameNode 就会在 EditLog 中插入一条记录来表示；同样的，修改文件的副本系数也将往 EditLog 插入一条记录。
  • 当 NameNode 启动时，它会从硬盘中读取 EditLog 和 FsImage，将所有 EditLog 中的事务作用在内存中的 FsImage 上
    并将这个新版本的 FsImage 从内存中保存到本地磁盘上，然后删除旧的 EditLog，这个过程也被称为一个 checkpoint。
  • 通过 NameNode 上的元数据可以确定 block 到具体 DataNode 节点的一个映射，所以客户端在读取或者写入数据到 HDFS 时，
    都是先到 NameNode 上获取元数据，然后根据元数据中的地址直接与 DataNode 交互，与此同时，客户端会缓存一段时间的元数据，从而减少与 NameNode 的交互。

HDFS 读流程

先会请求namenode，从namenode获取数据的信息（存储在哪些节点）
然后选择最近的datanode节点读取数据，然后将从各个节点读取来的信息合并成一个完整的文件

hdfs-read

HDFS 写流程

  1. 向namenode请求上传文件，namenode响应后，客户端请求上传一个块（block）
  2. namenode 响应 一个datanode，客户端向该DataNode发送数据，以packet为单位进行传输，每个DataNode之间建立pipeline通道，同时向所有的DataNode上传数据。即第一个数据节点将它接收到的一部分数据块发送给第二个数据节点。第二个数据节点将其接收到的一部分数据发送给第三个数据节点
hdfs-write

常见问题

  1. datanode 宕机, 数据如何恢复
  • 由于 hdfs 有数据备份机制，datanode长时间宕机，数据已经备份到其他机器，数据不会丢失，重启即可

参考文章

https://hexiaoqiao.github.io/blog/2018/03/30/the-analysis-of-basic-principle-of-hdfs-ha-using-qjm/