Hadoop分布式文件系统（HDFS）知识梳理（超详细）

气性不和平，则文章事功俱无足取
语言多矫饰，则人品心术尽属可疑

推荐书目电子版下载

Hadoop必读书目（精选）
本文参考文献包含于上述书籍

HDFS知识梳理

应用背景

1. 当数据集的大小超过一台独立物理计算机的存储能力时，有必要对它进行分区并存储到若干台单独的计算机上
2. 管理网络中跨多台计算机存储的文件系统称为分布式文件系统
3. 分布式文件系统架构于网络之上，必然会引入网络编程的复杂性，分布式文件系统比普通磁盘文件系统更加复杂
4. Hadoop有一个抽象的文件系统概念，HDFS是其中的一个实现

简介

分布式存储系统HDFS（Hadoop Distributed File System）是一个文件系统，类似于Linux的文件系统。HDFS有目录，目录下可以存储文件，但它是一个分布式的文件系统。

基本原理

1. 将文件切分成等大的数据块，分别存储到多台机器上
2. 每个数据块存在多个备份
3. 数据切分、容错、负载均衡等功能透明化
4. 可将HDFS看成是一个巨大的、具有容错性的磁盘

优点

• 处理超大文件
• 流式访问数据
• 运行于廉价的商用集群上

缺点

• 不适合存储大量小文件
• 不适合低延迟数据访问
• 不支持多用户写入和任意修改文件

设计

HDFS以流式数据访问模式来存储超大文件，运行于商用硬件集群上

• 超大文件

  • 几百MB、GB、TB大小的文件，现已有Hadoop集群存储PB级数据

• 流式数据访问

  • 一次写入，多次读取是最高效的访问模式
  • 数据集通常由数据源生成或者从数据源复制而来，会长时间在此数据集上进行分析，每次均会涉及大部分或者全部数据，读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要

• 商用硬件

  • HDFS设计运行在商用硬件上，即在各种零售店都能买到的普通硬件
  • 节点故障几率高
  • HDFS被设计成在遇到故障时能够继续运行，不让用户察觉到明显的中断
  • 某些应用领域不适合使用HDFS

• 低延迟的数据访问

  • HDFS为高数据吞吐量应用优化，以增加时间延时为代价
  • 要求几十毫秒低时间延迟访问的应用，不适合在HDFS上运行，更适合于HBase

• 大量的小文件

  • NameNode将存储文件系统的元数据存储在内存中，该文件系统所能存储的文件总数受限于NameNode的内存容量
  • 每个文件、目录和数据块的存储信息大约占150字节
    存储上百万个文件是可行的，存储十亿个文件就超出了当前硬件的能力

• 多用户写入，任意修改文件

  • 文件写入只支持单个写入者，不支持多个写入者
  • 写操作以“只添加”的方式在文件末尾写数据，不支持在文件任意位置进行修改
  • 以后可能支持这些操作，但相对比较低效

概念

HDFS架构图
注：Rack-机架 Replication-副本 Block-数据块 Metadata-元数据

• 数据块
  • 每个磁盘有默认的数据块大小，是磁盘进行数据读写的最小单位
  • 构建于单个磁盘之上的文件系统通过磁盘块来管理该文件系统中的块，该文件系统块的大小可以是磁盘块的整数倍
  • HDFS同样有块（Block）的概念，默认为128MB
  • 与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块（Chunk），作为独立的存储单元
  • 与其他文件系统不同，HDFS中小于一个块大小的文件不会占据整个块的空间
  • 优点
    • 一个大文件不用存储于整块磁盘上，可以分布式存储
    • 使用块抽象而非整个文件作为存储单元，大大简化了存储子系统的设计，对于故障种类繁多的分布式系统尤为重要
  • 显示块信息的命令hdfs fsck / -files -blocks
• NameNode
  • HDFS架构中的主节点
  • 管理各个从节点（DataNode）的状态
  • 记录存储在HDFS上所有数据的元数据信息，如Block存储的位置、文件大小、文件权限、文件层级等
  • 上述信息以两个文件的形式永久保存于本地磁盘
    • 命名空间镜像文件（FsImg）
      FsImage是HDFS文件系统存于硬盘中的元数据检查点，里面记录了自最后一次检查点之前HDFS文件系统中所有目录和文件的序列化信息
    • 编辑日志文件（Edit-logs）
      • 保存了自最后一次检查点之后所有针对HDFS文件系统的操作，如增加文件、重命名文件、删除目录等
      • NameNode将改动写入Edit-logs是由DataNode的写操作触发的，
  • 记录存储在HDFS上文件的所有变化
  • 接受DataNode的心跳和DataNode上的Blocak报告信息，确认DataNode是否存活
  • 负责处理所有块的复制因子
  • 如果DataNode节点宕机，NameNode会选择另外一个DataNode均衡复制因子，并做负载均衡
  • 可参考官网
• DataNode
  • DataNode是HDFS架构的从节点，管理各自节点的Block信息
  • 文件内的数据实际存储于DatNode
  • DataNode分别运行于独立的节点
  • DataNode执行客户端级别的读写请求
  • DataNode向NameNode发送心跳（默认设置为3秒），报告各自节点的健康状况
• Secondary NameNode
  • Secondary NameNode是NameNode的助手，不是其备份
  • Secondary NameNode在HDFS中提供Chekpoint Node，因此也称之为Chekpoint Node
  • 定时从NameNode获取Edit-logs，更新到自己的FsImage上
  • 一旦Secondary NameNode有新的FsImage文件，就将其拷贝回NameNode，NameNode在下次重启时会使用新的FsImage文件，从而减少重启时间
• 复制因子
  • 复制因子使得HDFS提供可靠存储
  • 默认复制因子为3
  • DataNode定时发送心跳给NameNode，汇报各自节点的Block信息，NameNode手机这些信息后，对超出复制因子的Block进行删除，对复制份数不足的Block进行赋值
• 机架感知
  • 分布式集群通常包含非常多的机器，收到机架槽位和交换机网口的限制，通常大型分布式集群会跨好几个机架
  • 机架内机器之间的网络速度通常会高于跨机架机器之间的网络速度
  • 机架之间机器的网络通信通常受到上层交换机间网络带宽的限制
  • 文件块的放置
    • 假设一个Block有3份备份
    • 一份放在NameNode指定的DataNode上，一份放在与指定DataNode不在同一台机器上的DataNode上，最后一份放在与指定DataNode同一机架的DataNode上
    • 备份的目的是为了数据安全，采用这种配置方式主要是考虑同一机架内机器宕机的情况，以及不同机架之间进行数据复制会带来的性能降低问题
• 客户端（Client）
  • 客户端是一个需要获取分布式文件系统文件的应用程序
  • 客户端代表用户通过NameNode和DataNode访问整个文件系统
  • 客户端提供一个类似于POSIX（可移植操作系统界面）的文件系统接口，用户在编程时无需知道NameNode和DataNode也可实现其功能
  • 假设data.txt文件大小为238MB，现需要将其写入HDFS中，假设HDFS块大小设置为默认值128MB，则客户端会将此文件拆分成两个块，第一个块是128MB，第二个块是110MB

读写流程

文件写入

1. 客户端向NameNode发起写入文件请求
2. NameNode根据文件大小和文件块配置情况，以及结合了DataNode的健康状态、复制因子、机架感知等因素，将可以写入数据的DataNode的IP地址列表返回给客户端，赋予客户端写权限
3. 客户端将文件划分为多个块，根据所得的DataNode地址信息，按序将其写入DataNode块中

第3步的数据复制流程分为以下3个阶段