Hadoop Erasure Coding结构分析

Posted Android路上的人

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop Erasure Coding结构分析相关的知识,希望对你有一定的参考价值。

前言


Hadoop-3.0-alpha2版本最近已经发布了,在Hadoop-3.0-alpha2版本中,社区继续fix了许多关于HDFS EC特性相关的issue。而Hadoop EC作为3.0版本中具有重大意义的feature,我们非常有必要去学习,并用好这个特性。在之前的文章中,笔者或多或少介绍过EC技术的原理知(再聊HDFS Erasure Coding)以及EC技术在Hadoop中的运用(Hadoop 3.0 Erasure Coding 纠删码功能预分析)。最近笔者重新阅读、学习了EC相关的代码,本文将要阐述的是EC在Hadoop整个工程项目中的一个结构,包括各个部分代码结构的组成以及关键代码的实现等等。

EC在Hadoop工程中的结构


首先看到这里,有些人可能会疑惑这里为什么不说是EC在HDFS中的结构呢?尽管目前EC的主要使用部分是在HDFS内部,但并不代表EC技术在未来不会被用在其它的组件上。所以社区将EC技术最最基础的部分定义在了Hadoop-Common过程下,例如EC内部中的基础块类,以及编解码算法类等等。

EC另外一部分内容的定义就自然在HDFS组件内了,比如说我们需要定义一个完全针对EC方式的数据流类:DFSStripedInputStream数据输入流类和DFSStripedOutputStream数据输出流类。总的归纳起来一句话,由于EC下的数据的条带式存储方式与原本的副本连续式的存储方式不同,这需要在许多地方做一个适配和改造。所以想要在HDFS内引入EC技术,工程量其实是不少的。笔者大致地阅读了EC相关的代码,主要存在于下面的一些HDFS模块中:

第一个,BlockManager类。EC的引入,需要在BlockManager中做多处的变更。在很多块相关处理的方法内部,需要增加是否为条带块逻辑的判断,

if(block.isStriped()){
    // EC模式下的块处理逻辑
}

第二个,ErasureCodingPolicyManager类。ErasureCodingPolicyManager是全新构造的一个类,用来管理EC策略类的。而EC策略类内部会包含具体将要使用到的EC编解码模式,数据块/加密块的数量组成等等。这些策略类到时会设置到具体的文件中的,类似于HDFS现有的StoragePolicy。

第三个,ECCLI。通过名称不难理解,此类就是EC的命令行接口类,主要为获取和设置EC策略的2类命令。

第四个,NamenodeFsck。此类内部也需要适配hdfs fsck命令对于EC文件块的扫描,识别。目前的代码中NamenodeFsck为EC文件构造了一份额外的结果报告。

第五个,Metric。Metric统计指标在EC中也是需要的,目前HDFS只针对EC中Reconstruction Task部分进行了metric的统计。包括重构任务中失败的task数,读取的字节数等等指标。

第六个,数据读写模块。之前在上文中也已提过,由于EC Strip方式的存储模式与传统副本的Contiguous存储方式的不同,原先的DFSInputStream/DFSOuputStream也将不再适用。社区为此实现了它们的继承子类DFSStripedInputStream、DFSStripedOutputStream。此部分内容在下文中还将会具体提到。

第七个,其它部分。其它部分指的是HDFS内部其它地方对于EC做出的小小适配,比如说Balancer/Mover块转移相关的部分,或者说是EC文件的数据保存,它是如何将EC相关的信息持久化到fsimage中的,又或者说EC文件的块恢复是怎么做的等等。这些都是更加细节方面的内容了,感兴趣的同学可以自行做更为深入的分析和学习。

综述所述的结构,大致为下图所示的结构:



图1-1 Hadoop EC结构

EC部分关键点的实现逻辑


下面笔者来谈谈几个EC的关键点实现逻辑。

EC下的数据流操作


EC下的数据流操作实质上指的是数据流类DFSStripedInputStream/DFSStripedOutputStream是如何被使用的。笔者在阅读此类代码的时候,发现其中会有一个独特的编/解码类。此类的作用是将dataBlock和parityBlock数据进行编/解码处理。按照读取数据时进行解密处理,写入数据时进行编码处理的原则,DFSStripedInputStream包含的是ErasureEncoder对象而DFSStripedOutputStream用的则是EnsureDecoder对象。

ErasureEncoder、EnsureDecoder这种涉及到具体EC算法的编码类是从哪里传进来的呢?其实通过代码不难发现,答案是从文件中的ECPolicy中取来的。ECPolicy就是在这个时候被应用到文件数据中的。我们再来看一个更加原始的问题,DFSStripedInputStream/DFSStripedOutputStream是怎么生存的呢?这里要从DFSClient端说起了,DFSClient通过open方法创建出数据输入流准备进行数据的读取,通过create方法创建出输出流对象进行数据的写入。

所以EC下的数据流模型如图1-2所示:



图1-2 EC数据读写模型

EC相关数据的持久化


这部分的内容笔者一直觉得比较好奇的,最近也花了一些时间进行学习,最终发现可能这里的持久化还不能称之为完全的持久化。当然了,首先EC数据文件也是用INodeFile类进行存储的,最终也会被持久化到FSImage中。但是在持久化的数据中,它与笔者原本所想的有些不一样。主要为下面2点:

  • EC文件区别于普通INodeFile文件,最大的区别是它引入了ECPolicy这个对象,里面包含了具体EC算法的很多信息。如果按照正常逻辑,
    应该是也要被持久化到FSImage中的,但是这里只存了一个ECPolicy Id。
  • 基于上一点ECPolicy Id的存储,HDFS内部并不是另起一个新的字段来存储这个id,而是与replication复用了同一个字段。因为在EC中
    其实是不应该有副本的概念的,它本身就能够做数据恢复。所以当在EC文件时,这里讲ECPolicy id赋给了replication字段,同时也节省
    了字段空间。

然后EC文件做数据恢复的时候,是通过反向获取的方式得到ECPolicy具体信息的。相关代码如下:

    // 加载INodeFile文件对象
    private INodeFile loadINodeFile(INodeSection.INode n) {
      assert n.getType() == INodeSection.INode.Type.FILE;
      INodeSection.INodeFile f = n.getFile();
      List<BlockProto> bp = f.getBlocksList();
      // 获取文件副本值
      short replication = (short) f.getReplication();
      // 获取块类型
      BlockType blockType = PBHelperClient.convert(f.getBlockType());
      LoaderContext state = parent.getLoaderContext();
      // 根据块类型得到ECPolicy策略信息,id为副本值
      ErasureCodingPolicy ecPolicy = (blockType == BlockType.STRIPED) ?
          ErasureCodingPolicyManager.getPolicyByPolicyID((byte) replication) :
          null;
      // 进行块信息的恢复
      BlockInfo[] blocks = new BlockInfo[bp.size()];
      for (int i = 0; i < bp.size(); ++i) {
        BlockProto b = bp.get(i);
        if (blockType == BlockType.STRIPED) {
          blocks[i] = new BlockInfoStriped(PBHelperClient.convert(b), ecPolicy);
        } else {
          blocks[i] = new BlockInfoContiguous(PBHelperClient.convert(b),
              replication);
        }
      }
      ...
}

上述代码为FSImageFormatPBINode类中的代码,在反向加载FSImage中会用到。下面是笔者个人的观点:

  • 这种持久化的方式其实是一种简化版的持久化方案,它本身没有持久化ECPolicy的信息,在一定程度上会牺牲一点效率,因为每次都要从
    ErasureCodingPolicyManager中进行重新获取。
  • 与replication共用一个字段是否稳妥,个人觉得如果是EC文件,这个值应该就设置为恒定值1即可,然后另行存储EC的元数据信息。这样在结构上更易理解。

关于此话题的讨论目前在社区上早已有相应的JIRA:HDFS-7869(Erasure Coding: Persist erasure coding policies in NameNode),感兴趣的同学可以到这个JIRA上看看。

参考资料


[1].Erasure Coding: Persist erasure coding policies in NameNode, https://issues.apache.org/jira/browse/HDFS-7859

以上是关于Hadoop Erasure Coding结构分析的主要内容,如果未能解决你的问题,请参考以下文章

【HDFS】超详细讲解Erasure Coding-- EC架构及图解相关核心代码。

Erasure Coding

分布式系统下的纠删码技术 -- Erasure Code (EC)

分布式系统下的纠删码技术 -- Erasure Code (EC)

Hadoop经典案例Spark实现——日志分析:分析非结构化文件

erasure code