Fast22 论文

Page 1

香港中文大学 王秋平

研究在有关log-struct的存储系统中，通过对数据块被更新时间进行数据分离，以减少写放大的放大；该工作是与阿里的块存储团队合作产出的；

Page 2

研究背景：

基于阿里的块存储生产系统：ESSD云盘；EDDS云盘的架构，可以看成是在分布式文件存储——盘古上面搭建的一个log structure的存储系统；数据的存储在全闪存集群中，以提供-100ps的延迟和高达1M的IOPS的性能；每个ESSD云盘是一个块级的卷，实现上是一个追加写(append only)的log；每个log内部的基本数据单元是最大大小为几百Mib的segment，固定大小的数据块被追加写到segment中；用户以逻辑块地址LBAs来寻址这些数据块。

Page 3

Log-structure的存储需要垃圾回收（Garbage Collection GC）来回收被更新覆盖的旧数据；从而使得之前被旧数据占用的空间被重复利用；

我们把GC抽象为三个步骤：

1. 触发：当存储系统中垃圾数据总比例超过一定阈值，例如15%，我们触发垃圾回收；这里的垃圾比例定义为无效数据块占总数据块的比例；
2. 选择：垃圾回收按照一定策略选择待回收的segment。例如贪心算法选则内部垃圾比例最高的segment；
3. 重写：将选择阶段被选中的segment中的有效数据搬迁至新的segment中，然后删除旧segment，这样以释放无效数据占用的存储空间；

写放大：由于垃圾回收在重写阶段会不断地重写有效数据，所以系统中会有写放大的问题。写放大不仅会降低闪存的寿命；还会占用可用的带宽，导致可售卖的带宽减少；

Page 4

在本工作中，我们探讨如何使用数据摆放来减少写放大。首先我们定义用户数据块（user-written block），和GC重写数据块(GC-rewritten block)；每一个用户的写入或者更新，会产生一个用户写数据块；根据这个用户写数据块在GC时被重写的情况，会进一步产生0个或多个gc重写数据块。所以我们定义WA=1+#GC-rewritten blocks / #user-written blocks

如图所示，数据摆放会根据写入的数据块的不同特性，将他们追加写到不同的segment中，这里的open segment，是指还未达到最大大小的segment，他们可以用于追加写新数据，sealed segment是指已经达到最大大小的segment，GC会将他们回收，并重写内部的有效数据。数据摆放将特性相似的数据块摆放到相同的组里面，使得segment内部的数据块尽量在一起被更新，从而减少在被回收时，segment内部的有效数据比例，gc就可以重写更少的数据，从而降低写放大。

Page 5

我们提出SepBIT，通过推测每一个数据块被更新的时间，我们称为block invalidation time（BIT），然后将被更新时间接近的数据块放到同一个组里面.基于对真实世界trace的分析，我们的方法首先将用户写数据块和GC重写数据块分开，然后再分别考虑每个组别内部的数据块的特性，从而有效降低写放大。目前SepBIT已被部署在阿里云ESSDs生产系统中，我们也做了大量的trace分析和原型测试来验证SepBIT的有效性。

Page 6

SepBIT按照数据块被更新时间分离的思想来自于一个理想模型。我们发现如果知道每个数据块未来被更新的时间，我们可以实现一个理想化的数据放置策略，使得GC造成的写放大等于1。在这个理想策略中，我们先给所有的segment进行编号，我们严格按照所有被写入的数据块被更新的顺序，追加写到相应的segment中，这样一来，在选segment的时候，我们只需要选保存着那些最先被更新掉的数据块的segment，这样就可以保证每次回收的segment中只有无效数据块，所以CC可以回收一整个segment的空间，而不需要重写任何数据。

然而在这个理想模型中，我们发现有两点不实际的假设：

第一：我们需要得到每一个数据块被更新时间这个知识，但是在实际情况中，这是不可能的；

第二：我们需要为每一个块提前预留空间，以放置相应的数据块，这就要求存储空间足够装下整个工作负载，这也是不现实的。

所以一个实际的方法不仅需要能够准确推断每一个数据块被更新时间，也需要在有限的空间下，尽量把已写入的数据块按照被更新时间相近这一个条件去分组.

Page 7

我们进一步通过trace分析，说明已有方法有效性，不如按照被更新时间的分离方法。我们定义每一个被写入的块，它的寿命为该块被写入的时间点到被更新时间点trace写入的数据量的总值。我们使用阿里云块存储的trace，该trace包含1000个云盘，在2020年1月1整个月的读写请求信息，我们从中选取了186个写流量足够大的盘，来做实验，以避免实验误差。我们同样也在腾讯云公开的块存储trace上验证了我们的结论。

Page 8

结论一：用户写入的数据块总体来说寿命都比较短.例如大多数云盘都有很高比例的用户写数据块寿命很短，甚至小于10%的工作集大小。与此相反，因为GC重写块都至少是在系统中存活了一段时间才会被GC重写的，所以大部分都会有比较长的寿命。

结论二：频繁被更新的数据块，他们的寿命偏差较大。我们把每个盘里边的块分成不同更新频率的组别。发现高更新频率的组别，它们的内部的数据块寿命相差很大。

结论三：不常被更新的数据块寿命也有很大差异，我们同样检查了不常更新的数据块，具体是每个盘里面在一个月内更新次数少于4次的块。我们发现他们中有寿命很长的，也有寿命很短的。

三个结论说明了基于数据温度，比如说数据块被更新了多少次这样的算法，并不能很好的预测数据块的寿命大小，也就是说不能很好的推测他们下一次被更新的时间。

Page 9

与已有的基于数据块温度的分类算法不同，SepBIT首先把所有的块分为用户写数据块和GC写数据块两组，因为他们的被更新时间的特征不一致。然后SepBIT进一步把数据块总共分成6类，对于用户写数这块，我们有两类，第1类保存预期寿命短的，因为他们被写入的时间接近，并且寿命较短，那么他们会具有相近的被更新时间。剩下的数据块我们分到第2类，因为他们的被更新时间的范围将会很大，难以继续准确分类。对于GC重写数据块我们分成4类，第3类保存那些之前存在第1类的，因为在用户写入的时候，我们认为这些块是寿命较短的，然后我们继续把剩下的GC重写数据块，块按照他们预测的剩余寿命分成三类，4~6类。虽然这里我们使用6类，但是我们实验发现使用6类已经足够有效了。

Page 10

接下来我会介绍我们对于用户写数据块和GC重写数据块的分离具体思想。我们是通过对trace中每一个盘的数据块所具有的寿命进行概率性分析，来支持我们的想法的。

对于用户写数据块。我们的直觉是给定一个用户写数据块，如果它更新了一个寿命短的旧数据块，那么它自己的寿命也有可能会比较短。具体来说我们检查了对于一个用户显示出这块，如果它更新的旧数据块寿命小于一个域值v0，它本身的寿命小于另一个域值u0的概率。我们发现在阿里云块存储trace中该条件概率对于不同的较小的v0和u0值的组合都比较高。所以我们直觉是正确的。

Page 11

对于GC重写数据块，我们认为给定一个GC重写数据块，如果他的年龄较短，那么他的预期剩余寿命也会较短，具体来说我们检查了，对于一个GC重写数据块，如果它的年龄大于一个阈值g0，那么它的剩余寿命小于另一个域值r0的概率，我们发现对于给定的r0，当g0增加的时候，条件概率会显著降低。所以我们可以根据每一个GC重写块被重写时的年龄来判断接下来他剩余寿命的高低，即我们只需要将GC重写块，按照他们的年龄分开就可以实现将他们按照被更新时间分离的预期。

Page 12

基于之前的结论我们是这么实现SepBIT的，我们将被收集的segment寿命平均值记录为L，具体操作是，每有16个从第1类收集的segment计算一次平均值，这里的第1类指的是用户写数据块分离时保存的寿命较短的数据块的那一个类别。然后我们直接用L作为用户写数据的分类阈值，对于每一个用户写数据块我们检查它更新掉的，旧数据块的寿命，如果小于L，我们就认为当前的用户写数据块寿命较短，分到第1类，否则分到第2类。对于GC重写数据块，我们设定4倍L和16倍L作为GC重写数据块年龄的分界线分到4~6三类中。该实现的内存开销也比较低，对于用户写数据块而言，我们只需要记录那些年龄小于L的用户写数据块，这一部分的数据块，占总工作集的比例较小，对于GC重写数据块而言，它的写入信息被记在了每个块的闪存上的元数据区域，当我们把这个块读上来的时候，同样也会得到这个信息，所以不需要额外的内存开销。

Page 13

为验证SepBIT的有效性，我们实施了trace分析和原型分析，在trace分析中，我们使用了来自阿里云块存储的186个盘，探究了不同选择算法、segment的最大大小和触发GC的垃圾比率之下，不同的数据摆放算法的写放大情况。我们把SepBIT和其他11个算法进行了比较，包括8个已有的算法以及一个【可以利用未来的被更新时间的信息作为分离】的一个理想算法。在原型验证中我们搭建了一个C++的原型。实验环境上，我们用Optane可持久化内存仿真了一块zone storage设备，为达到更好的可复现性以及和生产系统抽象的更好的匹配性。

Page 14

我们发现在不同的实验条件组合下，SepBIT都比已有的算法要好。比如说，在cost benefit选择算法下，相比于已有的算法，SepBIT的降低了总的写放大9.1%~20.2%。相比于理想算法只有3.1%的额外写放大。并且SepBIT在单盘的写放大中实现了最低的75分位点。

Page 15

同样实现了SepBIT的原型，并将它与在trace分析中发现的最好的已有算法进行了比较，由于时间关系，我们跑了20个写流量比较大的盘，我们发现在SepBIT可以实现最高的带宽，在25和50分位点上比第二好的算法高出28.3%和20.4%。

Page 16

总结而言，SepBIT通过对数据块的被更新时间做推断，来减少log structure的系统中的写放大，它的方法及有效性基于我们大量的真实世界的trace分析，并且他现在在阿里云ESSDs里得到部署，更多的细节请看我们的论文以及代码，感谢收听，接下来我会回答大家提出的问题。