前面几篇文章把Hadoop常用的模块都学习了，剩下一个新模块Ozone，截止到今天最新版本是0.5.0Beta，还没出正式版。好在官方网站有文档，还是中文版的，但是中文版资料没有翻译完整，我试着把它都翻译一下。参考 《Apache Hadoop Ozone》。

Ozone 是 Hadoop 的分布式对象存储系统，具有易扩展和冗余存储的特点。

Ozone 不仅能存储数十亿个不同大小的对象，还支持在容器化环境（比如 Kubernetes）中运行。

Apache Spark、Hive 和 YARN 等应用无需任何修改即可使用 Ozone。Ozone 提供了 Java API、S3 接口和命令行接口，极大地方便了 Ozone 在不同应用场景下的的使用。

Ozone 的管理由卷、桶和键组成：

• 卷的概念和用户账号类似，只有管理员可以创建和删除卷。
• 桶的概念和目录类似，用户可以在自己的卷下创建任意数量的桶，每个桶可以包含任意数量的键，但是不可以包含其它的桶。
• 键的概念和文件类似，用户通过键来读写数据。

Ozone 是一个分布式、多副本的对象存储系统，并针对大数据场景进行了专门的优化。Ozone 主要围绕可扩展性进行设计，目标是十亿数量级以上的对象存储。

Ozone 通过对命名空间与块空间的管理进行分离，大大增加了其可扩展性，其中命名空间由 Ozone Manager （OM）管理，块空间由 Storage Container Manager（SCM）管理。

Ozone 的管理由卷、桶和键组成。卷类似于个人主目录，只有管理员可以创建。

卷用来存储桶，用户可以在一个卷中创建任意数量的桶，桶中包含键，在 Ozone 中通过键来存储数据。

Ozone 的命名空间由存储卷组成，同时存储卷也用作存储账户管理。

下面的框图展示了 Ozone 的核心组件：

Ozone Manager 管理命名空间，Storage Container Manager 管理底层的数据，而 Recon 是 Ozone 的管理接口。

Ozone Manager（OM）管理 Ozone 的命名空间。

当向 Ozone 写入数据时，你需要向 OM 请求一个块，OM 会返回一个块并记录下相关信息。当你想要读取那个文件时，你也需要先通过 OM 获取那个块的地址。

OM 允许用户在卷和桶下管理键，卷和桶都是命名空间的一部分，也由 OM 管理。

每个卷都是 OM 下的一个独立命名空间的根，这一点和 HDFS 不同，HDFS 提供的是单个根目录的文件系统。

与 HDFS 中单根的树状结构相比，Ozone 的命名空间是卷的集合，或者可以看作是个森林，因此可以非常容易地部署多个 OM 来进行扩展。

Ozone Manager 元数据

OM 维护了卷、桶和键的列表。它为每个用户维护卷的列表，为每个卷维护桶的列表，为每个桶维护键的列表。

OM 使用 Apache Ratis（Raft 协议的一种实现）来复制 OM 的状态，这为 Ozone 提供了高可用性保证。

Ozone Manager 和 Storage Container Manager

为了方便理解 OM 和 SCM 之间的关系，我们来看看写入键和读取键的过程。

写入键

• 为了向 Ozone 中的某个卷下的某个桶的某个键写入数据，用户需要先向 OM 发起写请求，OM 会判断该用户是否有权限写入该键，如果权限许可，OM 分配一个块用于 Ozone 客户端数据写入。

• OM 通过 SCM 请求分配一个块（SCM 是数据节点的管理者），SCM 选择三个数据节点，分配新块并向 OM 返回块标识。

• OM 在自己的元数据中记录下块的信息，然后将块和块 token（带有向该块写数据的授权）返回给用户。

• 用户使用块 token 证明自己有权限向该块写入数据，并向对应的数据节点写入数据。

• 数据写入完成后，用户会更新该块在 OM 中的信息。

读取键

• 键读取相对比较简单，用户首先向 OM 请求该键的块列表。

• OM 返回块列表以及对应的块 token。

• 用户连接数据节点，出示块 token，然后读取键数据。

SCM提供了支持Ozone集群的多个关键函数。它提供了集群管理、认证授权、块管理、多副本管理多种功能。

集群管理

SCM负责创建Ozone集群。当通过初始化命令启动SCM的时候，SCM会创建认证授权需要的集群ID和根证书。SCM管理数据节点在集群中的完整生命周期。

认证授权（CA）

SCM的认证中心负责给集群中的每一个服务分发身份证书，底层的证书服务能够更容易地实现网络层的双向认证和基于认证的块令牌服务。

块管理

SCM向数据节点分配块，客户端可以直接读写这些块。

多副本管理

SCM掌握着块副本的实时信息。如果发生块丢失，SCM会向数据节点发指令，让它们复制一个块副本来保证高可用。

Ozone跟HDFS的命名都如此相似。

Ozone所有的数据都存放在数据节点上。客户端以块的形式写入数据，数据节点把这些块聚合起来放入存储容器中。一个存储容器包含了数据流和客户端写入块的元数据信息。

存储容器

一个存储容器是一个独立的超级块，它包含两部分内容：一部分是块清单，另一部分是保存着实际数据流的磁盘文件。上图是存储容器的默认格式。

从Ozone的角度来看，容器是一个协议规范，实际的存储层反而无关紧要。换句话说，是继承还是使用一个新的存储层都是可以的。只要是基于Ozone的容器实现就行。

Qzone的块和容器

当客户端需要读取一个键值的时候，它会向Qzone Manager发请求，Qzone Manager返回这个键对应的块清单。

一个块包含容器ID和本地ID。下图显示了Ozone块的结构。

容器ID让客户端能够找到容器的位置。一个容器到底在哪儿，SCM里的信息是最权威的。大多数情况下，Qzone Manager会把容器的位置缓存起来，随着块信息一起返回给客户端。

客户端获取到返回信息之后，它就知道容器在哪个数据节点上。客户端建立起与数据节点的连接，根据容器ID和本地ID来读取数据流。也就是说，本地ID是容器里的索引信息，它描述了我们要读取的数据流。

容器定位

SCM怎么知道容器在哪儿呢？这个过程跟HDFS类似。数据节点定期发送容器信息，就像HDFS发送块信息给NameNode一样。只不过容器信息比块信息要简单的多。举个例子，一个包含196TB数据的Ozone大约有4万个容器。相比之下，HDFS的block会达到上百万个，至少有一半的block会发送信息。Qzone发送的块信息减少了40倍。

这有助于Ozone的扩展性管理。SCM需要处理的块数据要少得多，与NameNode的类型不同，这对Ozone的扩展性很重要。