前言
Ozone作为对象存储系统而言，在对于用户使用的方式上，我们难免会想到另外一个已经在业界十分成熟的对象存储系统：S3存储。不过本文笔者并不想比较二者系统孰优孰劣，从用户角度出发，在用户已经使用S3接口方式做对象存储时，我们是否有方式能够透明的将底层存储移到Ozone上。换言之来说，Ozone是否能够做到兼容S3接口方式的对象存储，这样客户端就不需要做大的改动了。Ozone在早期release的版本中就已经提供了适配S3 Protocol的存储方式了，而且在后续还完成了S3的multipart upload的语义实现，使得整个Ozone S3 的feature变得更加的完善。本文笔者简单聊聊Ozone在S3适配上是怎么做的。
相关背景
这里的相关背景是说Ozone社区为了能够兼容现有S3 REST API的接口，计划在Ozone内部实现一个叫S3 gateway的新feature来做这个事情。S3 REST API的操作最后会转化为为Ozone内部的volume/bucket/key存储里面去，详细内容见JIRA：HDDS-434（Provide an s3 compatible REST api for ozone objects）。
Ozone的S3方式的存储实现分析
Ozone要做到兼容现有S3 REST API的实现，那么必须它的接口定义必须和现有S3一致，目前Ozone内部已经实现有以下的接口：
| Operations on Bucket |
|---|
| GET Bucket |
| HEAD Bucket |
| DELETE Bucket |
| PUT Bucket |
| Delete Multiple Objects |
| PUT Bucket |
| Operation on Objects |
|---|
| PUT Object |
| GET Object |
| DELETE Object |
| HEAD Object |
| Multipart Upload |
我们看到在上面的接口操作中，设计的对象都是bucket以及bucket里的object(key)的操作，但是在bucket上一级其实还有volume的概念的。那么Ozone是怎么做的呢？把调用用户名作为volume name？
Ozone采用了一个默认的“s3v”作为这些bucket统一所属的volume，S3接口设计的bucket改动均在此独立volume下做改动。简单原理图如下所示：
Ozone S3的Multipart Upload功能分析
另外这里重点介绍Ozone S3的Multipart Upload(分片上传)功能。这里首先有一个疑问点：在原生S3 Multipart Upload里，这个接口是做什么用的呢？它和普通的upload 一个object对象有什么区别呢？这里和我们上传对象文件的大小密切相关了。
一般情况下来说，我们上传的文件大小一般都不会太大（比如1GB以内）。在大部分情况下，我们还不至于需要Multipart Upload的功能，但是假设我们上传的文件非常大，好几十GB甚至百GB级别，我们如果还用单次put object的操作去用，是有可能中途发生失败的。而且在效率上，这也不是一种高效的方式。这时候，Multipart Upload的功能就能够很好的弥补这个场景，假设我们能够将大对象进行拆分，然后将分片对象逐一上传或者并行地上传。最后再将分片的文件进行合并，就高效地完成了一次大对象的上传操作。
Ozone的Multipart Upload分片上传的过程中涉及到的改动是里面各种key的转变以及最后的part key到最终key的合并，原理图如下所示：
首先，上面的左上图的multipart key并不等同于待上传文件的key名称，而是key全名+uploadID。然后第二个阶段是分片上传阶段，这里操作的key是part key信息，part key=key全名+openID，最后右图则是对象key全名，此key对象的block存储就来自于原先part key写出的各个block数据，在最后阶段逻辑上进行location的合并，part key作为中间key，也会在最后阶段从table里进行移除。
上面是Ozone S3 multipart upload的简单过程图，我们再来详细了解里面对应的实际请求过程，这里面涉及到的请求步骤过程，总共分为下面4步：
- 1）Initiate Multipart Upload，初始化Multipart Upload的call调用，此过程会添加multipart key信息到multipart info表和open key表。
- 2）Part Key Write，分片key上传阶段，此过程会添加open key到open key表，这里的open key对应的是分片key正在写，和1） 插入的open key的信息代表意思不同。
- 3）Commit Multipart Upload Part，commit 分片上传key的调用，此call为分片上传结束时会调用的call，此步骤会删除2） 中添加的open key。同时这里会更新1）中multipart info表里multipart key的信息，因为这里添加了新的分片文件信息，需要更新。
- 4-1）Complete Multipart Upload，整个 Multipart Upload过程的结束调用，此步骤会删除1）中添加到multipart info表和open key表中的multipart key这项记录信息。同时这里会额外加入key信息到key table表里去，意为此key上传完成，对外表示可见状态了。
- 4-2）Abort Multipart Upload，Multipart Upload过程的失败调用，此步骤是说假设上面的分片过程发生了失败，我们如何做此过程的清理。Abort过程同样会删除1）中添加到multipart info表和open key表中的multipart key这项记录信息。另外它会把2）中的part key的信息加入到Deleted table里，让系统去清理掉这些key对应的数据。
上述过程对于的过程图如下所示：
以上就是本文所要阐述的Ozone S3接口适配相关的功能介绍了，具体更多相关的内容可参考下文链接处。
参考链接
[1].https://issues.apache.org/jira/browse/HDDS-434
[2].https://issues.apache.org/jira/browse/HDDS-763
[3].https://ozone.apache.org/docs/1.0.0/interface/s3.html