大数据 / 人工智能 / 区块链 / 数据库 / 分布式存储
2020年9月，Ozone 1.0.0分布式对象存储系统在Apache Hadoop社区正式发布。据了解，经过2年多的社区持续开发和内部1000+节点的实际落地验证，Ozone 1.0.0已经具备了在大规模生产环境下实际部署的能力。
我们知道，HDFS是Hadoop的分布式文件系统，但Ozone是什么？跟HDFS是什么关系？为什么要实现Ozone？
张东涛 | 文
© 中兴数据智能（ZTE-DI）出品
Ozone是一个在Hadoop内部做的、类似亚马逊S3的分布式Key-Value对象存储系统，其内部定义的API也兼容S3。
对象存储的特点：
本质上是键值对存储系统； 采用扁平化的管理方式（根据键，找到值）； 值可以是任何东西，可以是小文件（小二进制片段），也可以是大文件； 对象存储一般不支持追加写和更新，面向的是一次写入、多次读取的需求场景。
Ozone的出现，不仅弥补了Hadoop生态圈没有自己的分布式对象存储的遗憾，而且作为对象存储系统，能够支持存储数十亿个不同大小的对象，在一定程度也能弥补HDFS在文件数量上不足的存储弱点。
目前版本的Ozone提供了一套兼容HDFS API的Hadoop Common FileSystem（HCFS）API，可以让Spark、Hive 和YARN 等应用无需任何修改就使用 Ozone。
将来的发展方向是Ozone和HDFS合二为一，在同一套分布式存储系统上既能支持文件存储，又能支持对象存储。Hadoop社区已有issue正在实现，并命名为HDDS（Hadoop Distributed Data Store）。
下面介绍一下Ozone组件的基本语义、框架和流程。
语义
Ozone是一个分布式对象存储系统，其中存储的每个Key-Value键值对就是一个Object对象。
Ozone提供给用户的语义包含Volume，Bucket 和Key：
Volume的概念和用户账号类似，只有管理员可以创建和删除Volume； Bucket的概念和目录类似，用户可以在自己的Volume下创建任意数量的Bucket，每个Bucket可以包含任意数量的Key，但是不可以包含其它的Bucket； Key的概念和文件类似，用户的数据以 Key-Value 的形式存储在Bucket 下。每个 Key 在 Bucket 中必须唯一，可以是任意字符串。
构架
Ozone 从结构上分为三个部分：
Ozone Manager：元数据管理； Storage Container Manager：存储容器管理； Datanode：数据最终的存放处。
▲ Ozone构架
▲ 图片引自：https://mp.weixin.qq.com/s/b7Dwa-O895tWc_u7wCQfKw
类比 HDFS 的构架， 可以看到原来 Namenode 的功能，现在由 Ozone Manager 和 Storage Container Manage 分别进行管理了。接下来，我们仔细看一下 Ozone 主要模块和概念。
管理 Ozone 的 Namespace，提供所有的 Volume、Bucket 和 Key 的新建，更新和删除操作。存储了 Ozone 的元数据信息，这些元数据信息包括Volumes、Buckets 和 Keys，底层通过 Ratis（实现了Raft协议）扩展元数据的副本数来实现元数据的HA。Ozone Manager 只和 Ozone Client 和 Storage Container Manager 通信，并不直接和 Datanode 通信。
Storage Container Manager（SCM）
管理 Container、Pipelines和Datanode之间的关系，为 Ozone Manager 提供 Object 和 Container 的操作和信息。SCM也监听 Datanode 发来的心跳信息，作为Datanode Manager的角色, 保证和维护集群所需的数据冗余级别。SCM 和 Ozone Client 之间没有通信。
Datanode
Datanode 是 Ozone 的数据节点，以 Container 为基本存储单元，维护每个 Container 内部的数据映射关系。Datanode 是 Ozone 中的 worker，所有的数据都存储在数据节点上，用户以对象的方式写数据，数据节点将多个对象聚合成一个Container ，Container中包含用户写入的对象和这些对象的元数据以及存储实际数据的磁盘文件。
Datanode 定时向 SCM 发送心跳节点，汇报节点的信息、管理的 Container 及Pipeline 的信息。当一个 Container Size 超过预定的大小 90% 时 或者写操作失败时，Datanode 会发送 Container Close 命令给 SCM，把 Container 的状态从 Open 转变成 Closed。
Object，Container 和 Pipeline之间关系
Object是数据对象，真实存储用户的数据。Container是一个逻辑概念，是由一些相互之间没有关系的 Object组成的集合。在 Ozone 中， 数据是以 Container 的粒度进行副本复制的。Pipeline 来保证 Container 实现想要的副本数。SCM 中目前支持2种 Pipeline 方式实现多副本，单副本的 Standalone 模式和三副本的 Ratis 方式。
Container 有2种状态，OPEN 和 CLOSED。当一个Container 是 OPEN 状态时，可以往里边写入新的 Object。当一个Container 达到它预定的大小时（默认5GB），它从 OPEN 状态转换成 CLOSED 状态。一个 Closed Container 是不可修改的。
▲ Container 内部结构
▲ 图片引自：https://ci-hadoop.apache.org/view/Hadoop%20Ozone/job/ozone-doc-master/lastSuccessfulBuild/artifact/hadoop-hdds/docs/public/zh/concept/datanodes.html
Pipeline 来保证 Container 实现想要的副本数。Namenode将不再管理HDFS的副本一致性，由Ratis接管，也就是如果缺少了副本，不会上报Namenode，Ratis自己发现及补齐。
说明：Ratis 写 Pipeline：为了将Raft一致性算法更方便地使用于各个分布式系统中，以此构建出容错性更强的分布式服务。Apache Ratis诞生了，它是一个Raft算法的Java实现库。目前在Ozone被用来做Container command的replicate的执行。在未来还将用于Ozone HA的实现。
▲ Pipeline
▲ 图片引自：https://blog.csdn.net/Androidlushangderen/article/details/74860017
Ozone语义和模块对应关系
Ozone 分层的构架结构，使得Ozone Manager、Storage Container Manager 和 Datanode 按需独立扩展。对于Ozone 提供的语义，也是由各层分层管理的。
▲ Ozone语义和模块对应关系
▲ 图片引自：https://mp.weixin.qq.com/s/b7Dwa-O895tWc_u7wCQfKw
读写过程
写过程
Ozone 客户端先和 Ozone Manager 通信，提供需要创建的Key 的信息，包括 volume/bucket/key，数据的大小，备份数，和其他用户自定义Key的属性；
Ozone Manager 收到 Ozone 客户端的请求后，调用SCM 的服务；
SCM寻找足够容纳数据的Open Container，将Container 对应的Pipeline 的Datanode 列表信息返回给Ozone Manager；
Ozone Manager 返回对应的信息给客户端；
客户端拿到Datanode列表信息之后，和第一个Datanode（Raft Leader）建立通信，将数据写入Datanode 的Container 中，更新Container 的元数据，记录新增加的这个数据块。
最后，客户端再和Ozone Manager 通信，告知数据已经成功的在 Datanode写入了。Ozone 修改 Namspace 元数据，记录一个新生成的Key。之后，其他的客户端就可以访问这个Key了。
▲ 创建一个新 Key
▲ 图片引自：https://mp.weixin.qq.com/s/b7Dwa-O895tWc_u7wCQfKw
读过程
Ozone 客户端 先和 Ozone Manager 通信，告知需要读取的Key 的信息（/volume/bucket/key）。
Ozone Manager 在元数据库中查找对应的Key，返回 Key 数据所在的 Datanode 列表给Ozone 客户端。Ozone 支持Data locality。如果Ozone 客户端运行在集群中的某个节点上，Ozone Manager 会返回按照网络拓扑距离排序的Datanode列表。
当 Ozone 客户端拿到 Key 的信息之后，可以选择第一个Datanode 节点（一本地节点），也是离客户端最近的节点来读取数据，节省数据读取的时间。
▲ 读取一个Key
▲ 图片引自：https://mp.weixin.qq.com/s/b7Dwa-O895tWc_u7wCQfKw
Ozone与HDFS架构的重要区别
Ozone在存储层上，加了一个Container层，因此Datanode向上层的Block报告被Container报告替代。因为Container数量比Block少很多，所以对相关进程内存消耗及启动时间减少很多。以一条KV对应一个文件来评估，Ozone Manager类似Namenode，会集中存放大量KV->Container->Datanode元数据；但由于Container层带来的优点，使得Ozone Manager比Namenode内存消耗量减少很多。
SCM存放所有Datanode中的Container信息及空间信息元数据，由于Container大约5G，所以SCM的元数据并不大。
Datanode要负责把KV对象写入Datanode中的Container，增加了更新Container的元数据的步骤，用于记录新增加的这个数据块；KV查询也多了一次在Container内部的元数据查询交互，这些操作都会对性能产生影响。
Ozone当前版本就介绍到这里，如果有对下一代Hadoop分布式存储HDDS（等同于HDFS+Ozone）感兴趣的同学，可以跟踪开源社区这个issue：
* 本文为中兴数据智能原创文章，转载请留言或评论获取授权。
