Ozone的Erasure Coding方案设计

前言


众所周知,在当下存储系统中为了存储效率的提升,Erasure Coding(纠删码)技术在扮演着一个越来越重要的角色。比如说目前Hadoop HDFS中,它就已经能够支持EC功能了。在EC模式下,HDFS 可以不必存储多打3份这样的冗余副本数来为了容灾保护。存储效率的提高意味着存储海量数据所需要的存储节点资源的减少。不过本文并不是聊HDFS的EC实现的,而是谈谈时下另外一个存储系统Ozone的EC设计,也是简单聊聊在Ozone的对象存储模式下,EC要如何实现以及它能够带来的好处。

EC技术以及EC下的存储效率的提升


关于EC技术本身,全称Erasure Coding,中文称之为纠删码技术。EC的具体算法实现细节网上资料讲述的也已经很多了,本文不做过分细致的阐述。

简单的来说,就是将原始数据块进行划分成多个data block,然后根据EC算法的计算,产生出新的校验块(parity block),如下所示:
在这里插入图片描述
当上述数据块或者校验块发生丢失或者损坏的情况时,系统可以根据EC算法进行重新生成来恢复,以此达到数据保护的效果。

还有一个问题,这里的数据存储效率的提升体现在哪里呢?
继续以上述例子为例,在上面3个数据块,2个校验块模式下,那么此时数据存储效率为3/(3+2)=60%,而在传统3副本模式下,存储效率只为1/3=33%,它的另外2份存储是完全冗余的,注意我们这里谈的是绝对有效的存储。

OK,我们可以看到在EC模式下,系统的存储效率能够得到不小的提升,当采用不同EC算法模式时,这个存储效率还可能更高。

凡是硬币都有正方面,另外一方面,EC的劣势在于做它做数据恢复时,需要耗费更多的网络和CPU资源,所以我们一般将那些访问低频次的冷数据进行EC的处理。

Ozone下的EC方案设计


在上小节部分我们对EC有个简单的了解后,我们再来看看针对Ozone系统的特点,Ozone社区是如何做这块的设计的。Ozone社区在JIRA HDDS-3816:Erasure Coding in Apache Hadoop Ozone中对此方案进行了设计。

在此方案中它主要提出了2套可选的方案:

  • 以Container为基本存储单元,针对Container Level的EC实现。
  • 以Block(Container内的Block)为基本存储单元,针对Block Level的EC实现。

这2种EC的实现方案在实现复杂度以及各自方案的优劣势都有所不同。下面我们来分别来了解这里面的实现细节部分的内容。

Container Level的EC实现


首先Container Level的EC实现,以Container为基本单位,Ozone将会把一个整的Container作为一个大的data block,而Container里面实际存储的Block在是这个data block的一个小的部分。然后不同的Container就组成了多data block,最后就是校验Container块的产生了。

此过程图如下所示:
在这里插入图片描述
上面Container里面1,2,3,4,5数字代表的里面的Block块。每个相同偏移量位置的Block数据进行对应检验块数据的生成,如下图所示:
在这里插入图片描述

我们从另外一个层面来看,多余的Container副本就可以校验Container剔除取代了,
在这里插入图片描述

在Container Level的EC实现中,对现有Ozone内部的改动其实是稍微比较小的。因为Container内部的Block数据结构,位置其实都没有发生改变。OM那边也不需要更新Key对应的Block位置信息。换句话锁,Container Level的EC对于原有的对象数据的读写访问没有什么影响。

但是这里的影响主要在于Container的异步校验Container的生成,当前设计是只考虑给closed状态的Container做EC处理,因此我们不会有数据新写入Container,而校验Container还是老的这样的问题。

另外一点的影响方面是closed状态的Container数据的删除,在Container EC模式中,每个Container的作用是被放大了,每个Container不仅自身存储有Block数据外,它还同时担负着帮助其它Container进行数据错误恢复的作用,即使这个Container它可能已经被删除了。简单来说,在Ozone中被删除的closed状态的Container或Container中的任何Block数据被删除了,都不能被马上立即地被物理删除掉,除非等到它所依赖的Container已经重新组织别的新的Container进行校验Container的生成。

最后是我们以Container级别的粒度做数据的恢复,它的cost开销可能会比较大。目前Ozone默认一个Container最大的size是5GB。在HDFS中,它的block设置往往就128MB,256MB这种级别,在Ozone中我们提升到了GB级别,它所需要的开销必然会有所增加的。

Block Level的EC实现


聊完Container Level的EC方案后,我们再来说说Block的EC方案。这里的Block指的是Container内的那些Block。如果我们按照Container Block做EC的实现,其本质已经十分类似于HDFS的EC实现了。它同样是将一个Block进行条带式的分散写入到多个Container,多个node里去。

这里类似HDFS Block EC结构,下图为HDFS Block的EC条带式存储:
在这里插入图片描述
这样的方式会打破现有Block数据的写入实现逻辑,而且OM服务那边Key对应的Block位置信息也是需要更新的。Block Level的EC实现所需要的代码变动相较Container Level来说是更多一点的。

不过在Block Level下,笔者认为它的读写性能理应会得到提升的,因为数据横向存储在多节点中,我们可以采用并行读写,然后合并结果的方式来提升数据读写的效率。

另外在Block Level下,我们可以针对更细粒度Key级别做EC的设置了。当然了,它也会损失数据的locality特征,因为此时数据是分散存储在多节点之下的。

但论整体完整度和潜在影响来说,笔者个人观点是认为Block Level的EC方案要比Container Level更好一些。包括它也没有上面提到的Container删除的问题。

以上就是本文今天所要阐述的关于Ozone EC的内容了,还是很期待这个功能在Ozone中得到完整的实现的。

引用


[1].https://issues.apache.org/jira/browse/HDDS-3816 . Erasure Coding in Apache Hadoop Ozone

©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值