关于Alluxio这篇文章把注意力转移到了大数据上。

芯片采购网专注于整合国内外授权IC代理商现货资源，芯片库存实时查询，行业价格合理，采购方便IC芯片，国内专业芯片采购平台。

文中提及Cloudera作为Hadoop为什么生态最后的种子选手没有制造麻烦？Alluxio这样的东西？

没想到在学习Cloudera在这个过程中，我过程中Ozone，回答了潭主之前的问题。

技术体系复杂，有许多平行宇宙。今日，潭主与大家分享一项最近学到的数据湖存储技术，Ozone。

Ozone是哪路神

Ozone是Apache软件基金会下的一个项目定位为：用户大数据分析和云本地应用程序分布式，扩展性高，一致性强Key-Value对象存储。

读过潭主文章的读者自然会Alluxio对使用功能有所了解，Ozone跟Alluxio同样，也兼容支持S3和HDFS的API。

由于上述特点，Ozone现有可以透明支持Hadoop生态中如Spark和Hive等待上层计算框架，无需修改应用代码。

套路是一样的，把自己模仿成大师。当然，简单的模仿肯定不好，但也有自己的创新。

潭主的穷人思维

由于商业模式的限制，传统的保险业有很多数据孤岛

然而，近年来，非结构化业务数据增长迅速，之前引入的HCP对象存储已经是数十亿的量级。

据潭主所知，虽然之前也推出了一些大数据项目，Hadoop其实集群的规模并不大，所以在写这篇文章之前，潭主受到自己经验的限制Hadoop没有疼痛。

即使在互联网行业，十多年前也可能无法预测数据会膨胀得如此之快，以至于Hadoop很快就变得无能为力。

互联网富人思维

在过去的两年里，数据湖这个词非常流行。

人们对数据湖有不同的理解。有人认为Hadoop是数据湖，有人认为是数据湖，有人认为是数据湖。S也是数据湖。

从网上公有云的角度来看，S三是主流存储，而线下私有云，Hadoop这种情况似乎更有优势，无形中对混合云的统一江湖形成了储存障碍。

因此，未来的数据湖技术应与各种主流计算框架相兼容，平稳支持各种应用场景，对接不同的存储引擎，实现数据访问接口的标准化。

从最近的技术发展趋势来看，这种统一标准的存储技术将成为下一代数据湖的显著特征。

而且对互联网，HDFS该系统在集群扩展和支持应用标准方面确实存在一些局限性。

为了解决HDFS开源社区这几年没闲着，尝试了很多解决方案。

HDFS联邦时代

最初Hadoop只允许命名空间（Namespace），而且只有一个NameNode管理。

虽然可以添加底层DataNode由于所有节点的水平扩展和存储空间的增加Block元数据都停留了NameNode在内存中，当集群规模增大时，NameNode很容易成为瓶颈，直接限制HDFS文件、目录和数据块的数量。

Hadoop 为了解决社区问题 HDFS 两个联邦方案(如上图制定了两个联邦计划（如上图所示）：

· NNF（NameNode Federation）

· RBF（Router Based Federation）

早期的NNF在计划中，集群引入了多个NameNode，管理不同Namespace和对应的BlockPool，多个NameNode可以共享Hadoop集群中的DataNode。

虽然解决了Namespace但是扩展问题需要对HDFS的Client结合静态配置挂载ViewFS实现统一入口。

而在RBF在联邦计划中，试图将挂载表从Client中抽出形成Router，虽然Hadoop集群是独立的，但同时又增加了一个State Store构件，结构变得更加复杂。

对于面向未来的大数据存储，局部改进的联邦方案治标不治本。

蓝而不是蓝

有时候，最好的优化是重新开始炉灶。

毕竟Hadoop技术多年，目前的软硬件环境与当初大不相同，系统重构也是合理的。

与其等别人去革HDFS人生不如自我革命。Ozone确实为用户提供了新的选择。

就好像CDH和HDP最终融合成CDP一样，HDFS和S3也可融合成Ozone。

总之，Ozone站在Hadoop在这个巨人的肩膀上，设计是为了取代它HDFS，蓝而不是蓝。

潭主家的储存一哥

早年接触过Ceph，也搞过HCP（Hitachi Content Platform）对象存储，这些经验理解潭主Ozone大有裨益。

专门查了自己的HCP，发现图像文件已超过20亿Susumu代理，存储容量也小2PB。但在查询过程中明显感觉到元数据响应缓慢，估计很快就会扩容。

言归正传，再来说说Ozone核心概念：

· Volume：通常表示用户、业务和HCP中的租户（Tenant）对应

· Bucket：通常表示业务、应用和HCP命名空间（Namespace）对应

· Key：对应的是实际的Object

Ozone存储路径为/Volume/Bucket/Key，一个业务可以对应一个或多个Volume，每个Volume可包含多个Bucket，访问方式Ozone实现了ofs和o3fs适配和协议包装。

值得注意的是，HCP有文件夹的概念，即对象文件有层次结构，但Ozone设计扁平，目录是伪目录的概念，是文件名的一部分，统一Key而存在。

Ozone的体系架构

介绍完概念，再看Ozone系统架构(如上图):

· OM（Ozone Manager）：通过RocksDB的K-V方式管理Namespace，Raft协议保持高可用性，Shardig实现水平扩展

· SCM（Storage Container Manager）：用于Ozone集群管理，负责分配Block，跟踪SC复制状态

· DataNode：负责向SCM汇报SC状态

· SC（Storage Container）：Ozone实际存储单元

· Recon Server：用于监控Ozone集群

Ozone架构优化，上层实现功能分离，OM负责管理Namespace，SCM负责管理Storage Containers。

下层实现了一个名字Hadoop Distributed Data Store（HDDS）高可用性、块存储层。

Ozone中的一个DataNode包括多个Storage Container，每个SC(默认5)容量GB，可配置)远大于Hadoop中Block容量（默认128MB），这种设计使每一个DN发送给SCM的Container-Report系统压力远小于传统压力Hadoop集群的Block-Report。

Storage Container作为Ozone通过其内置，基本存储和复制单元类似于超级块RocksDB（key记录BlockID，Value记录object对小文件的块管理实现了文件名、偏移量和长度。

Ozone，新一代集成数据湖存储

在网上看到一个互联网大厂商专家之前的分享，现在网络同时使用HDFS和Ceph。

HDFS主要用于大数据分析场景，但机器学习场景仅限于大量的小文件Ceph。

但是，在介绍中Ozone的Roadmap未来将引入存储层Ozone。

开源世界，风起云涌，前脚刚看到Alluxio，感觉眼前一亮，现在再看Ozone，更是金光闪闪。

Ozone既是Hadoop优化升级版可以分层解决大量小文件的对象存储，再加上云原生CSI支持使其成为新一代的融合存储。

Ozone这股新势力真的让潭主不敢小觑，希望以后有机会做一些实践。

存储圈，数据不息，折腾不止！