前言
Ozone作为正在快速迭代开发中的存储系统，相比于HDFS来说，其内部能支持更大规模量级的文件对象存储。不过作为存储系统来说，它同样面临一些数据如何来存储的问题，比如数据存几副本备份，数据replication的策略是什么，数据存储的载体介质是什么等等。本文我们来聊聊Ozone对于这块内容的抽象设计。为什么笔者提到的是抽象设计呢，因为这个功能设计还处在社区讨论中，还未开发完成。
存储类别(策略)抽象提炼的意义
首先一个核心的问题：关于存储类别或者说叫存储策略的抽象化到底有什么意义呢？它能对数据的实际存储能够带来什么帮助呢？
当存储系统完善到一定程度，支持越来越复杂的数据存储形式时，它就需要有这么一层存储类别的抽象化，来帮助外部用户更方便，直观的写入他们的数据到存储系统中去。一个简单的例子，比如用户不需要去主动设置多少副本参数来保证其数据的高可用性，又或者用户想要其数据访问变得更快，让他写入的数据落在拥有SSD盘的机器上等等。
像上述这些存储的要求已经算是比较底层的存储细节了，一个成熟的存储系统能够支持上述的存储要求，但是这里的问题在于它不应该让用户来设置如此底层的存储细节要求。毕竟不是每个使用用户都是底层存储专家，用户关心的无非是它的数据读写够不够快，数据可用性高不高，会不会丢数据。因此这里需要有另外一层更上层的存储抽象来开放给用户做设置，这里笔者简单称之为存储类别(Storage Class)。
HDFS的Storage Policy
HDFS内部实现了类似Storage Class的功能，叫做HDFS Storage Policy。这个Storage Policy做了对于每个replica的数据存储盘的策略设定。
比如现有HDFS支持的以下的storage policy:
/**
* This enum wraps above Storage Policy ID and name.
* Recommend to use this enum instead of above static variables.
* For example,
* StoragePolicy.HOT.value() is equal to HOT_STORAGE_POLICY_ID
* StoragePolicy.HOT.name() is equal to HOT_STORAGE_POLICY_NAME
*/
public enum StoragePolicy{
PROVIDED(PROVIDED_STORAGE_POLICY_ID),
COLD(COLD_STORAGE_POLICY_ID),
WARM(WARM_STORAGE_POLICY_ID),
HOT(HOT_STORAGE_POLICY_ID),
ONE_SSD(ONESSD_STORAGE_POLICY_ID),
ALL_SSD(ALLSSD_STORAGE_POLICY_ID),
LAZY_PERSIST(MEMORY_STORAGE_POLICY_ID);
}
通过策略名称，我们能直观了解数据存储的形式，这些不同策略背后的差异是数据副本应所选择的盘的差别。HDFS这里的Policy还没考虑到副本数的存储设置。
同样的，Ozone也考虑到了存储抽象化的设置，Ozone内部称此为Storage Class。下面我们来看看Ozone内部是如何定义Storage Class的。
Ozone的Storage Class定义
Ozone storage class抽象化的初衷和HDFS storage policy一样，都是为了解决面对用户层而言的存储设置选择的问题。
目前在没有实现此抽象化实现前，当用户存入对象文件到Ozone中时，它能够选择的参数是副本数以及数据replication的方式，使用Ratis或者Standalone模式，命令如下所示：
ozone sh key put --replication=THREE --type=RATIS /vol1/bucket1/key1 source-file.txt
但是在如果在引入Storage-Class的抽象定义后，上述命令将会简化为更简单易用的形式，如下：
ozone sh key put --storage-class=STANDARD /vol1/bucket1/key1 source-file.txt
当然在这里，–storage-class的选择不会单单只有一种，也会有类似COLD，HOT这类针对冷热数据分类的存储类型。
有了storage class的另一个好处是我们可以更加灵活方便的做数据的不同状态下storage class的转化了。比如数据经过一段时间后，使用频率降低，就可以将其将为另外一种storage class的存储。
Ozone对storage class的定义中，添加了更为灵活的存储设计。考虑到Ozone基于Container为单位存储，其Container状态会随着数据写满了会进行Close操作，因此storage class在这里会分别对应Close和Open状态的存储定义，定义如下：
The definition of STANDARD Storage class:
First container type/parameters: Ratis/THREE replicated containers
Transitions: In case of any error or if the container is full, convert to closed containers
Second container type/parameters: Closed/THREE container
甚至Ozone在未来可以做的更加灵活，由admin设置数据的storage class来提供给用户来使用，这比HDFS内部固定写死的policy更为灵活许多。总之，storage class抽象化提取实现对于存储系统本身而言会对其未来数据存储形式的调整会带来很高的便利性。
引用
[1].https://hackmd.io/4kxufJBOQNaKn7PKFK_6OQ?view#Implementation-changes