您的位置：
首页
>>
管理中心
>>
行业资讯
>>修改新闻资讯信息
资讯类型：
行业要闻
企业动态
新品速递
解决方案
交流培训
嘉宾访谈
产业纵横
人物聚焦
展会动态
会展报告
本站动态
标 题：
*
页面广告：
不显示
显示
副 标 题：
关 键 字：
多个关键字请用“
/
”分隔，如：西门子/重大新闻
内容描述：
新闻来源：
链 接：
责任编辑：
标题图片：
无
/uploadfile/newspic/20220722152525554.jpg
/uploadfile/newspic/20220722152532120.jpg
/uploadfile/newspic/20220722152600339.jpg
当编辑区有插入图片时，将自动填充此下拉框
*
所属类别：
(不超过20项)
电源产品分类
：
UPS电源
稳压电源
EPS电源
变频电源
净化电源
特种电源
发电机组
开关电源(AC/DC)
逆变电源(DC/AC)
模块电源(DC/DC)
电源应用分类
：
通信电源
电力电源
车载电源
军工电源
航空航天电源
工控电源
PC电源
LED电源
电镀电源
焊接电源
加热电源
医疗电源
家电电源
便携式电源
充电机(器)
励磁电源
电源配套分类
：
功率器件
防雷浪涌
测试仪器
电磁兼容
电源IC
电池/蓄电池
电池检测
变压器
传感器
轴流风机
电子元件
连接器及端子
散热器
电解电容
PCB/辅助材料
新能源分类
：
太阳能(光伏发电)
风能发电
潮汐发电
水利发电
燃料电池
其他类
：
其他
静态页面：
生成静态页面
*
内 容：
<P> </P> <P> 作者：落风潭</P> <P> 保险IT圈知名自媒体主理人</P> <P> 关于Alluxio的文章让潭主把注意力转移到了大数据上。</P> <P> 文中提及Cloudera作为Hadoop生态最后的种子选手，为什么没有鼓捣出Alluxio这样的东西？</P> <P> 没想到在学习Cloudera的过程中无意间发现了Ozone，解答了潭主之前的疑问。</P> <P> 技术体系繁杂，存在着很多“平行宇宙”。今天，潭主跟大家分享最近学习的一个数据湖存储技术，Ozone。</P> <P> Ozone是哪路神</P> <P> Ozone是Apache软件基金会下的一个项目，其定位是：一个用户大数据分析和云原生应用、具有高扩展性、强一致性的分布式Key-Value对象存储。</P> <P> 看过潭主文章的读者自然对Alluxio有所了解，在使用功能上，Ozone跟Alluxio类似，也兼容支持S3和HDFS的API。</P> <P> 因为上述特性，Ozone可以“透明”地支持现有Hadoop生态中如Spark和Hive等上层计算框架，无需修改应用代码。</P> <P> 套路是一样的，把自己“模仿”成高手的样子。当然，简单模仿肯定不行，还要有属于自己的“创新”。</P> <P> 潭主的“穷人”思维</P> <P> 传统保险行业受限于业务模式，存在很多的数据“孤岛”，每个岛的容量也有限。</P> <P> 不过，这几年非结构化业务数据增长迅猛，之前引入的HCP对象存储已经是上十亿的量级。</P> <P> 虽然之前也上线了一些大数据项目，但据潭主所知，Hadoop集群的规模其实并不大，以至于写此文之前，潭主受限于自身经验对Hadoop其实并无痛感。</P> <P> 即便是互联网行业，十多年前可能也无法预料数据膨胀得如此之快，以至于Hadoop很快就变得力不从心。</P> <P> 互联网的“富人”思维</P> <P> 这两年，数据湖这个词很火。</P> <P> 大家对于数据湖的理解也不尽相同，有人认为Hadoop是数据湖，而有人认为S3也是数据湖。</P> <P> 换个角度，从线上公有云的视角看，S3是主流存储，而到了线下的私有云，Hadoop似乎更有优势一些，这种情况无形中对于混合云的一统江湖形成了存储上的障碍。</P> <P> 因此，面向未来的数据湖技术应该是向上兼容多种主流计算框架，平滑支撑多种应用场景，向下对接不同的存储引擎，实现数据访问接口的标准化。</P> <P> 从最近了解的技术发展趋势看，这种承上启下、统一标准的存储技术将成为下一代数据湖的显著特征。</P> <P> 况且对于互联网，HDFS系统的确在集群扩展性、支持应用标准上的确存在一些局限性。</P> <P> 为了解决HDFS存在的问题，开源社区这些年也没闲着，尝试了不少解决方案。</P> <P align=center><IMG border=0 src="/uploadfile/newspic/20220722152600339.jpg"></P> <P> HDFS的“联邦”时代</P> <P> 最初Hadoop集群只允许有一个命名空间（Namespace），且只能被一个NameNode管理。</P> <P> 虽然可以通过添加底层DataNode节点实现集群横向扩展，增加存储空间，但由于所有的Block元数据都驻留在NameNode内存中，在集群规模增大时，NameNode很容易成为瓶颈，直接限制了HDFS的文件、目录和数据块的数量。</P> <P> Hadoop社区为了解决HDFS横向扩展的问题，做了两个联邦方案（如上图）：</P> <P> NNF（NameNode Federation）</P> <P> RBF（Router Based Federation）</P> <P> 早期的NNF方案中，集群引入了多个NameNode，分别管理不同的Namespace和对应的BlockPool，多个NameNode可以共享Hadoop集群中的DataNode。</P> <P> 虽然解决了Namespace的扩展问题，但需要对HDFS的Client进行“静态”配置挂载，还要结合ViewFS才能实现统一入口。</P> <P> 而在RBF的联邦方案中，尝试把“挂载表”从Client中抽离出来形成了Router，虽然Hadoop集群是独立的，但同时又增加了一个“State Store”组件，架构变得更复杂。</P> <P> 局部改进的“联邦”方案对于面向未来的大数据存储而言，治标不治本。</P> <P> 青出于蓝而胜于蓝</P> <P> 有时候，最好的优化就是另起炉灶。</P> <P> 毕竟Hadoop技术已经很多年了，当下的软硬件环境已与当初大不相同，系统重构也在情理之中。</P> <P> 与其等别人来革HDFS的命，不如自我革命。目前看，Ozone的确给用户提供了一个新选择。</P> <P> 就好像CDH和HDP最终融合成了CDP一样，HDFS和S3也可以融合成Ozone。</P> <P> 总之，Ozone站在Hadoop这个巨人的肩膀上，设计之初就是为了替换掉HDFS，青出于蓝而胜于蓝。</P> <P> 潭主家的“存储一哥”</P> <P> 早年间接触过Ceph，也搞过HCP（Hitachi Content Platform）对象存储，这些经验对潭主理解Ozone大有裨益。</P> <P> 特意查了一下自家的HCP，发现影像文件已经20多亿个了，存储容量也小2PB。不过查询过程中明显感觉到元数据响应缓慢，估计快该扩容了。</P> <P> 言归正传，再来说说Ozone的核心概念：</P> <P> Volume：通常表示用户、业务，与HCP中的租户（Tenant）对应</P> <P> Bucket：通常表示业务、应用，与HCP中的命名空间（Namespace）对应</P> <P> Key：对应的就是实际的Object</P> <P> Ozone的存储路径为/Volume/Bucket/Key，一个业务可以对应一个或多个Volume，每个Volume可以包含多个Bucket，在访问方式上Ozone实现了ofs和o3fs的适配和协议封装。</P> <P> 值得注意的是，HCP里面有文件夹的概念，就是说对象文件有层次结构，但Ozone在设计上是扁平的，目录是一个“伪目录”概念，是文件名的一部分，统一作为Key而存在。</P> <P align=center><IMG border=0 src="/uploadfile/newspic/20220722152532120.jpg"></P> <P> Ozone的体系架构</P> <P> 介绍完了概念，再看看Ozone的体系架构（如上图）：</P> <P> OM（Ozone Manager）：通过RocksDB的K-V方式管理Namespace，Raft协议保持高可用，Shardig实现水平扩展</P> <P> SCM（Storage Container Manager）：用于Ozone集群管理，负责分配Block，跟踪SC复制状态</P> <P> DataNode：负责向SCM汇报SC状态</P> <P> SC（Storage Container）：Ozone的实际存储单元</P> <P> Recon Server：用于监控Ozone集群</P> <P> Ozone做了架构优化，上层实现职能分离，OM负责管理Namespace，SCM负责管理Storage Containers。</P> <P> 下层实现了一个叫Hadoop Distributed Data Store（HDDS）的高可用、块存储层。</P> <P> Ozone中的一个DataNode包括多个Storage Container，每个SC的容量（默认5GB，可配置）远大于Hadoop中Block容量（默认128MB），这种设计使得每个DN发送给SCM的Container-Report系统压力要远远小于传统Hadoop集群的Block-Report。</P> <P> Storage Container作为Ozone的基础存储和复制单元，类似于一个“超级块”，通过其内置RocksDB（key记录BlockID，Value记录object的文件名、偏移量和长度），实现对小文件的块管理。</P> <P align=center><IMG border=0 src="/uploadfile/newspic/20220722152525554.jpg"></P> <P> Ozone，新一代的“融合”数据湖存储</P> <P> 在网上看到之前某互联网大厂专家的分享，现网同时在使用HDFS和Ceph。</P> <P> HDFS主要用于大数据分析场景，但机器学习场景中受限于大量小文件而使用Ceph。</P> <P> 不过，在介绍Ozone的Roadmap时说未来会在存储层引入Ozone。</P> <P> 开源世界，风起云涌，前脚刚看过Alluxio，觉得眼前一亮，这会儿再看Ozone，更是金光闪闪。</P> <P> Ozone既是Hadoop的优化升级版，又能“分层”解决海量小文件的对象存储，再加上对云原生CSI的支持，让其成为了新一代“融合”存储。</P> <P> Ozone这股新势力着实让潭主不敢小觑，希望未来能有机会做些实践。</P> <P> 存储圈，数据不息，折腾不止！</P>