HDFS

HDFS

  • HDFS系统架构

    • Master:
      • NameNode
      • SecondaryNameNode
    • DataNode

  • 主、从、client

    • client: 提交任务、读取数据从DataNode

  • 状体由DataNode定时向NameNode发心跳状态

NameNode

  • 管理着文件系统命名空间
    • 维护这文件系统树及树种的所有文件和目录
  • 存储元数据
    • NameNode保存元信息的种类有:
      • 文件目录名及他们之间的层级关系
      • 文件目录的所有者及其权限
      • 每个文件块的名及文件有哪些组成
    • 元数据保存在内存中
      • NameNode原信息并不包含每个快的位置信息
  • 保存文件，block，DataNode之间的映射关系
  • NameNode:
    • 文件名 -> block
    • block -> DataNode
  • DataNode:
    • block -> path
  • Hadoop更倾向存储大文件原因:
    • 一般来说，一条元信息记录会占用200byte内存空间，假设块大小为64MB，备份数据量是3，那么一个1GB大小的文件将占用16 * 3=48个文件块，如果现在有1000个1MB大小的文件，则会占用1000*3=3000个文件块(多个文件不能放到一个块中)。我们可以发现，如果文件越小，存储同等大小文件所需要的元信息就越多，所以hadoop更喜欢大文件。
  • 元信息持久化
    • 在NameNode中存放元信息的文件是fsimage。在系统运行期间所有对元信息的操作都保存在内存中并被持久化到另一个文件edits中。并且edits文件和fsimage文件会被SecondaryNameNode周期性的合并
    • 运行NameNode会占用大量内存和I/O，一般NameNode不会存储用户数据或执行MapReduce任务
  • 全Hadoop系统只有一个NameNode
    • 导致单点问题
    • 两种解决方案
    • 将Hadoop元数据写入到本地文件系统的同时再实时同步到一个远程过载的网络文件系统(NFS)
    • 运行一个secondary NameNode，它的作用是与NameNode进行交互，定期通过编辑日志文件名合并命名空间镜像，当NamNode发生故障时它会通过自己合并的命名空间镜像副本来恢复，需要注意的是secondaryNameNode保存的状态总是滞后与NameNode，所以这种方式难免会导致丢失部分数据

DataNode

  • 负责存储数据块，负责为系统客户端提供数据块的读写服务
  • 根据NameNode的指示进行创建，删除和复制等操作
  • 心跳机制，定期(3s)报告文件块列表信息
  • DataNode之间进行通信，块的副本处理
  • 数据块- 磁盘读写的基本单位
    • HDFS默认数据块大小:64MB
    • 磁盘块一般为512B
    • 原因:块增大可以减少寻址时间，降低寻址时间/文件传输时间，若寻址时间为10ms,磁盘传输速率为100Mb/s，那么该比例仅为1%
    • 数据块过大也不好，应为一个MapReduce通常以一个块作为输入，块过大会导致整体任务数量过小，降低作业处理速读

SecondNameNode

  • SecondNameNode并不是NameNode的备份，助手节点，检查节点
  • 用来保存HDFS的元数据信息，比如命名空间信息、块信息等，由于这些信息都是在内存的，SecondNameNode是为了考虑持久化到磁盘
  • 两个文件:
    • fsimage : 它是在NameNode启动时对整个文件系统的快照
    • edit logs: 它是在NameNode启动后，对文件系统的改动序列

  • SecondaryNameNode 所做的不过是在文件系统中设置一个检查点来帮助NameNode更好的工作
  • 它不是要取代掉NameNode也不是NameNode的备份
  • 定时到NameNode去获取edit logs，并更新到fsimage [Secondary NameNode自己的fsimage]
  • 一旦它有了新的fsimage文件，它将其拷贝会NameNode中。
  • NameNode在下次重启时会使用这个心的fsimage文件，从而减少重启的时间

机架感知策略 - Block副本放置策略

  • 第一个副本，在客户端相同的节点(如果客户端是集群外的一台机器，就随机算节点，但是系统会避免挑选太满或者太忙的节点)
  • 第二个副本，放在不同机架(随机选择)的节点上
  • 第三个副本，放在与第二个副本同机架但是不同节点上
  • 计算方式
    1
    2
    3
    4
    distance(/D1/R1/H1,/D1/R1/H1)=0 相同的datanode
    distance(/D1/R1/H1,/D1/R1/H3)=2 同一rack下的不同datanode
    distance(/D1/R1/H1,/D1/R2/H5)=4 同一IDC下的不同datanode
    distance(/D1/R1/H1,/D2/R3/H9)=6 不同IDC下的datanode

数据安全完整性效验

  • 不希望在存储和处理数据时丢失或损坏任何数据
  • HDFS会对写入的数据计算效验和，并在读取数据时验证效验和
  • 两种效验方法:
    • 效验和:
      • 检测损坏数据的常用方法是在第一次进行系统时计算数据的效验和，在通道传输过程中，如果新生产的效验和不完全匹配原始的校验和，那么数据就会被认为是损坏的。
      • crc32
      • client -> DataNode -> block
      • 默认512字节创建一个校验码
    • 数据块效验检测程序DataBlockScanner
      • 在DataNode节点上开启一个后台线程，来定期验证存储在它上的所有块，这个是防止物理介质出现孙减情况而造成的数据损坏
      • 修复命令: DN接收NN发送的一个Block修复命令，从其他节点复制block修复损坏Blokc
      • DataNode -> Client
  • 容错 - 可靠性措施
    • 一个名字节点和多个数据节点
    • 数据复制(冗余机制)
      • 存放的位置(机架感知策略)
    • 故障检测
      • 数据节点
        • 心跳包(检测是否宕机)
        • 快报告(安全模式下检测)
        • 数据完整性(效验和比较)
      • 名字节点(日志文件，镜像文件)
    • 空间回收机制
      • Trash目录: core-site.xml

HDFS特点

  • 能做什么
    • 存储并管理PB级数据
    • 处理非结构化数据
    • 注重数据处理的吞吐量（延迟不敏感）
    • 应用模式：write-once-read-many存取模式（无数据一致性问题）
  • 不适合做
    • 存储小文件（不建议）
    • 大量随机读（不建议）
    • 需要对文件修改（不支持）
    • 多用户写入（不支持）

HDFS 写流程

  • 流程图
  • 读流程图

  • 本地模式