HDFS和Ozone的数据删除原理对比思考

文章目录

  • 前言
  • 现有HDFS删除操作的性能问题
  • HDFS删除操作的brainstorm改进想法
  • 相关设计:Ozone系统内的删除操作处理
  • 相关文章

前言


前段时间笔者一直在折腾HDFS大目录删除的性能问题,也尝试了很多不同的方案来降低大目录删除所带来的性能影响,包括改INodeDirectly内部child list结构,或者是在Snapshot层面做改进优化等等(详见此文章:HDFS大目录文件删除方案的实践思考)。不过后续笔者在对比HDFS的删除操作和新一代存储Ozone系统内部的删除操作时,发现二者还是存在不少区别的,后者在设计上有着不小的改进之处。本文笔者来聊聊关于HDFS和Ozone的删除行为操作的对比,以及后面对HDFS现有删除操作的一些brainstorm的一些想法。

现有HDFS删除操作的性能问题


重新再回到这个老生常谈的问题–HDFS删除操作性能问题,用简单两个词简单概括:第一操作重,第二影响大。

这个过程简单来说如下:

  • 1)递归遍历目录树结构,收集里面需要被清除的INode实例(包括INode目录和INode文件),以及INodeFile下面所属的block块,即待删除的块。
  • 2)然后执行block的批量删除操作,每一批处理完毕,中间释放一下锁,然后再拿锁进行处理。

鉴于上述过程涉及到NameNode元数据的改动,因此都是在持有FSN全局锁的情况下执行的,因此这个过程就变得很重了。

下图是HDFS内部数据删除过程的一个简要示意图:

HDFS和Ozone的数据删除原理对比思考_第1张图片

在上述过程中,中间待删除的数据块信息被查询出来后,并没有做持久化,都是在一个过程中进行的,因此一个很自然的优化点设想是:

这个过程能否做到异步化处理?此外,这种一个目录一次性的清理方式能否变为多个batch式的delete行为?RemoveBlock已经是batch化了,前面清理INode的时候是否也能够做到batch处理化,而不是一下遍历完毕的方式?

OK,针对上述几个提议,出发点都是好的,不过要想实现上述几点改进势必要解决下面会出现的问题:

  • 删除操作异步化处理,HDFS认为只有INode真正被清理了,才算释放quota,这里的quota一致性问题如何保证?当然如果我们允许牺牲少血的quota准确性来做异步删除,那也是可以接受的。
  • 如果在INode目录树内删除的时候,做batch化处理,删到某一个INode的时候,然后结束退出,那下一次,如何恢复呢?可能会出现某些子INode出现无父INode实例的存在了。那这批被中断处理的INode将会成为脏数据驻留在NameNode里了。另外一个问题,INode删除时中途退出,是否可能出现另外的并发的操作又在读写正在删除的目录呢?

HDFS删除操作的brainstorm改进想法


针对上小节提到的几个棘手的问题,我们难道就没有办法解决了?不是的,凡是总有可行解。

首先第一个,quota不一致的问题,这个按照上面说了,我们可以牺牲一点quota的实时精准度来做delete操作的异步化这个事情,笔者认为这个取舍还是OK的。

然后第二个,关于INode的删除batch处理问题,概括起来有2个小问题:

  • 中间INode退出处理的恢复问题。如果在中间按照INode删除的数量达到阈值,然后强制退出处理释放锁,确实会造成一些问题。不过我们可以对这个做个转化,先将这个目录数进行递归遍历,只收集所有的INode实例,将其存放到list结构内。然后针对INode list做batch删除操作处理。在原有目录树内做删除操作中断处理,恢复起来比较难。
  • 第二个小问题是,待删除目录存在被读写的可能性在删除操作被batch中断释放的那一会。这个处理的方式比较简单,在batch删除INode的一开始,先将待删除目录文件rename成一个预留的名字,这个名字绝对不会被用户访问到,例如现有.trash之类的目录形式。简单来说,就是先做rename后delete。

有了上述几点的处理,我们再启动一个后台的线程,就可以正式做目录文件的异步化batch处理了,新的处理过程图设想如下所示:
HDFS和Ozone的数据删除原理对比思考_第2张图片
其实上图显示的过程和目前HDFS trash数据清理机制已经很接近 ,trash机制已经满足了rename成预留的名字以及后台删除这2个阶段,唯一可以改进的是将INode删除做batch化处理,而不是直接调NameNode的delete操作方法。笔者个人比较aggressive的想法是,HDFS的delete操作可以变为一个简单的rename操作,所有的实际操作行为都应该有后台专门的service去做异步处理。Client没有必要强制等待删除行为的同步执行结束,尤其在分布式存储系统中。

相关设计:Ozone系统内的删除操作处理


下面我们来看看另外一个对象存储系统Ozone在这块的设计。

首先Ozone同样作为存储系统,它也要面对大数据量删除的情况。不过它的namespace比较的简单,都是K-V,它目前不存在目录树删除的情况。因此它的删除行为比较容易做到batch化,批量拿一批待删除的Key就完事了。

它同样使用了rename成reserved名字的方式+后台删除线程的模型处理方式,Ozone目前现有的删除过程图如下所示:
HDFS和Ozone的数据删除原理对比思考_第3张图片
上图显示Ozone内部删除过程比HDFS是要略复杂一些,源于以下几点背景原因:

  • Ozone内部使用了基于Container的存储,涉及到OM SCM服务的交互通信,而不是类似于HDFS这种完全统一化的管理。
  • Ozone使用了第三方K-V db存储,不是纯memory,因此它可以做删除信息的持久化处理,因此也可以比较容易做删除行为的再恢复,当系统重新启动的时候。

另外在OM和SCM服务内部,每次做删除的时候,都是有limit限制的去删除一批的数据,这样一来整个删除行为对于Ozone的系统来说,影响就会很小。

笔者在对比完Ozone的删除机理和HDFS现有的删除行为,前者在扩展性,性能上要比后者更佳,后者设计上比较简单的处理设计,因此在量大的时候就展露出了弊端。对Ozone和HDFS删除原理感兴趣的同学可继续阅读笔者之前写的相关文章,链接在文章末尾处。

相关文章


[1],https://blog.csdn.net/Androidlushangderen/article/details/105778885
[2].https://blog.csdn.net/Androidlushangderen/article/details/77619513

你可能感兴趣的:(Ozone,HDFS数据删除)