概述

介绍如下内容:

  • HA高可靠性
  • 元数据持久化
  • HDFS联邦(Federation)
  • 数据副本机制

HA 高可靠性

图片加载失败

  • ZooKeeper:用于监控主备NameNode节点的切换。
  • ZKFC:操作主备NameNode节点的切换。
  • EditLog:元数据操作日志。

元数据持久化

  1. 生成一个新的 EditLog。
  2. 从主NameNode中获取到EditLog以及FSImage并将两者进行整合。
  3. 整合完成后生成FSImage.ckpt(Checkpoint,检查点)。
  4. FSImage.ckpt回传到主NameNodes使用FSImage.ckpt对主NameNodeFSImage进行回滚。

HDFS 联邦(Federation)

通常只有数据量非常庞大的公司才会使用这个特性。

图片加载失败

单组Namenode局限性:

  • 单组Namenode只允许整个集群有一个活动的Namenode,管理所有的命名空间。随着集群规模的增长,在1000个节点以上的大型Hadoop集群中,单组Namenode的局限性越发的明显,主要表现在以下几个方面:
  • 扩展性:Namenode内存使用和元数据量正相关。180GB堆内存配置下,元数据量红线约为7亿,而随着集群规模和业务的发展,即使经过小文件合并与数据压缩,仍然无法阻止元数据量逐渐接近红线。
  • 可用性:随着元数据量越来越接近7亿,CMS GC频率也越来越高,期间也曾发生过一次在CMS GC过程中由于大文件“get Block location”并发过高导致的promotion fail。
  • 性能:随着集群规模增长,Namenode响应的RPC QPS也在逐渐提高。越来越高并发的读写,与Namenode的粗粒度元数据锁,使Namenode RPC响应延迟和平均RPC队列长度都在慢慢提高。
  • 隔离性:由于Namenode没有隔离性设计,单一对Namenode负载过高的应用,会影响到整个集群的服务能力。
    既然单组Namenode存在上述局限性,那么为什么要通过Federation的方式横向拓展Namenode,纵向拓展Namenode为什么不行?不选择纵向拓展Namenode的原因主要体现在以下三个方面:
  • 启动时间长:Namenode启动需要将元数据加载到内存中,具有128 GB Java Heap的Namenode启动一次大概需要40分钟到1个小时,那512GB呢?
  • 调试困难:对大 JVM Heap 进行调试比较困难,优化Namenode的内存使用性价比比较低。
  • 集群易宕机:Namenode在Full GC时,如果发生错误将会导致整个集群宕机。

内容来自:https://cloud.tencent.com/developer/article/1349468

数据副本机制

  • 规定如果数据在当前服务器内则\(Distance=0\)
  • 规定如果数据所在服务器和当前服务器在同一个机架上则\(Distance=2\)
  • 规定如果数据坐在服务器和当前服务器在同一个机房则则\(Distance=4\)

读取时使用就近原则,优先读取最近的数据副本。

写入时先写最近的,然后写最远的,最后写中间的。