对象存储和新型分布式文件系统 - 填补Hadoop存储的空白

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
简介: IT软硬件架构、企业部署已经发生了翻天覆地的变化,在这些新的变革下,HDFS露出了一定的颓势。但是云上对象存储是唯一的选择吗?面向on-premise,云环境以及混合云环境,在这新旧存储架构交替之际,数据存储会如何发展呢,如何填补Hadoop存储留下的空白?

背景

Hadoop分布式文件系统(HDFS)从Hadoop出现到现在已有了10多个年头。HDFS的出现和成熟为企业提供了廉价的海量数据存储方案,大数据存储不再是“王谢堂前燕”,而真正地“飞入”了各个公司。但是10多年的时间,IT软硬件架构、企业部署已经发生了翻天覆地的变化,在这些新的变革下,HDFS露出了一定的颓势。但是云上对象存储是唯一的选择吗?面向on-premise,云环境以及混合云环境,在这新旧存储架构交替之际,数据存储会如何发展呢,如何填补Hadoop存储留下的空白?

本文为翻译文章,翻译自datanami的文章 Object and Scale-Out File Systems Fill Hadoop Storage Void[1].

前言

快速增长的数据量以及变化的数据处理方式对于现有的、已经建立起来的大数据存储架构产生了一定的影响。在原先的方案中,一个组织想要存储PB级的弱结构化数据,他们往往首先会想到的是on-premise数据湖架构。但是现在,他们会更多地去考虑多云和混合云架构下的可扩展文件系统或是对象存储,这会带来更多的灵活性。

自从Hadoop的光环渐渐褪去后,许多企业一直寻找其他方案来存储半结构化和非结构化数据,这些数据占据了泛滥的大数据中的绝大部分。这些企业希望将这些数据应用到各个场景中,其中最重要的是训练机器学习模型以使决策自动化。

尽管宣告Hadoop的死亡还为时过早[2],但是显然HDFS不再存储企业的绝大部分数据。Hadoop,就像所有之前出现的快速增长技术那样,随着人们对于其功能的重新评估,对它的期望已经从顶峰逐渐下降。Cloudera,现如今唯一的Hadoop发行者,已经脱离Hadoop一段时间了,现在正着眼于帮助客户以混合云的方式存储和处理数据方式。

鉴于大数据领域现阶段的动荡,显然,现今的趋势正在寻找一种替代的存储方式。在这之中,对象存储正在逐步蚕食Hadoop所占的领地。

对象存储

基于云的对象存储系统是当今的真正赢家,尤其是AWS[3]的S3,它已成为当今对象系统事实上的标准接口。每个销售对象存储的软件公司和大多数公有云供应商都为其对象存储提供了与S3兼容的API ,当然在这其中Microsoft Azure[4]及ADLS是个例外。

尽管公有云迅速增长,但企业仍然不愿将所有数据(鸡蛋)存储在云(一个篮子)上。这确实是一个难题,因为S3本身并没有on premise部署。

这样的需求催生了新兴的,基于混合云架构的第三方对象存储的增长,包括Red Hat[5]的开源方案,例如来自SwiftStack[6]的Swift和OpenStack[7]的Ceph,以及Minio[8]对象存储,还有一些闭源方案,如Scality[9]的Ring,Cloudian[10]的HyperStore,Dell EMC[11]的Isilon和Nutanix[12]的Objects。

对象存储,理论上没有存储上限,它实质上是大规模的键值存储,能够在单个全局命名空间中存储PB或EB级的数据,并允许使用简单的键来读取数据。同时像HDFS一样,对象存储系统可以在X86节点的群集上运行,并有容错机制,可以减少丢失数据的机会。

对象存储擅长存储大量非结构化数据,例如视频和图像。诸如像媒体娱乐、监视、医疗保健以及石油和天然气领域的公司都是对象存储的大用户,这得要归功于其存储海量数据的能力。

尽管可伸缩性和弹性是对象存储的主要优点,但I/O性能和数据局部性却是其短板。对于那些超大的群集,往往可能需要等待几秒钟才能返回所需的数据。因此,对象存储通常用于备份和存档,而不是用于热数据存取。

新型分布式文件系统

除了对象存储,现如今也出现了新一代的分布式文件系统,以及对Lustre等现有文件系统的修改。这些更新的分布式文件系统中的许多都还提供了S3兼容的API,并且还提供了对象存储的功能,但是究其内部,它们看起来更像传统文件系统。

这些新型的分布式文件系统包括Qumulo[13]的分布式文件系统,Elastfile[14]的Cloud File System(ECFS),WekaIO[15]的Matrix和Hedvig[16]的Distributed Storage Platform,等等。这些系统所针对的场景往往是那些需要更快访问的场景。

借助更先进的数据缓存和数据分层功能,这些分布式文件系统可以提供快速的文件I/O能力,为现代数据应用程序、新兴的机器学习和AI场景所用。同时,它们还能与Docker以及Kubernetes这样的容器编排框架很好地配合使用,当然也很好地适配了混合云的部署架构。

总结

软件定义存储(software-defined storage)领域现在正是高速增长中。 Gartner[17]在其2018年的分布式文件系统和对象存储魔力象限中预测,到2022年,将有80%的企业数据存储在此类可扩展的存储系统中。而2018年,则只有40%的企业数据存储在分布式文件系统和对象存储中。

image.png

显然,我们正处于存储快速变革时期。在许多情况下,对象存储和分布式文件系统之间的边界变得越来越模糊。许多供应商完全避开了这这些所谓的称呼,并称其为“data fabric”。

无论如何,他们都希望提供类似的功能,给与客户自由选择的权力,将PB级的数据存储在他们所选择的地方(on-premise,云或混合的形态),并通过各种接口提供服务,包括S3和Swift API,以及低级的块存储,和更为高级的标准NFS和SMB接口,来访问该数据。

在许多大数据的用例中,现如今HDFS似乎是这座“围城”里唯一的选择,而企业现在面临着大量的大数据存储选择。在这个领域中,尽管当前有领导者,但没有明确的领先者来为后来者明确追赶的方向(除非你将AWS的S3协议视为新的标准协议)。

就像数据孤岛的泛滥一样,我们看到了数据存储标准的泛滥。这在某种程度上增加了企业的风险,希望避免投资无法持久的技术,这迫使他们做足功课以找到适合他们的软件定义存储系统。

附录

Hitting the Reset Button on Hadoop[18]

Mike Olson on Zoo Animals, Object Stores, and the Future of Cloudera[19]

IBM Challenges Amazon S3 with Cloud Object Store[20]

References

[1] Object and Scale-Out File Systems Fill Hadoop Storage Void: https://www.datanami.com/2019/07/17/object-and-scale-out-file-systems-fill-hadoop-storage-void/
[2] Hadoop的死亡还为时过早: https://www.datanami.com/2019/06/24/hitting-the-reset-button-on-hadoop/
[3] AWS: http://www.aws.amazon.com/
[4] Microsoft Azure: http://www.azure.microsoft.com/
[5] Red Hat: https://www.redhat.com/
[6] SwiftStack: http://www.swiftstack.com/
[7] OpenStack: https://www.openstack.org/
[8] Minio: http://www.min.io/
[9] Scality: http://www.scality.com/
[10] Cloudian: http://www.cloudian.com/
[11] Dell EMC: http://www.dellemc.com/
[12] Nutanix: http://www.nutanix.com/
[13] Qumulo: http://www.qumulo.com/
[14] Elastfile: http://www.elastifile.com/
[15] WekaIO: http://www.weka.io/
[16] Hedvig: https://www.hedvig.io/
[17] Gartner: https://www.gartner.com/
[18] Hitting the Reset Button on Hadoop: https://www.datanami.com/2019/06/24/hitting-the-reset-button-on-hadoop/
[19] Mike Olson on Zoo Animals, Object Stores, and the Future of Cloudera: https://www.datanami.com/2018/09/19/mike-olson-on-zoo-animals-object-stores-and-the-future-of-cloudera/
[20] IBM Challenges Amazon S3 with Cloud Object Store: https://www.datanami.com/2016/10/12/ibm-challenges-amazon-s3-cloud-object-store/


本文转载自公众号:数据湖技术

作者:绍赛赛
原文链接


阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区,定期推送精彩案例,技术专家直播,问答区近万人Spark技术同学在线提问答疑,只为营造纯粹的Spark氛围,欢迎钉钉扫码加入!
image.png

对开源大数据和感兴趣的同学可以加小编微信(下图二维码,备注“进群”)进入技术交流微信群。

image.png

Apache Spark技术交流社区公众号,微信扫一扫关注

image.png

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
相关文章
|
3月前
|
存储 关系型数据库 MySQL
MySQL——数据库备份上传到阿里云OSS存储
MySQL——数据库备份上传到阿里云OSS存储
168 0
|
15天前
|
存储 弹性计算 数据管理
阿里云对象存储OSS收费标准,存储、流量和请求等多个计费项
阿里云对象存储OSS提供按量付费与包年包月两种计费方式,涵盖存储、流量、请求等费用。标准存储按量付费0.09元/GB/月,包年包月40GB起售,价格9元/年。公网流量出方向收费,内网及上传免费。具体费用视使用情况而定,详情见官网。
127 0
|
1月前
|
分布式计算 NoSQL Java
Hadoop-32 ZooKeeper 分布式锁问题 分布式锁Java实现 附带案例和实现思路代码
Hadoop-32 ZooKeeper 分布式锁问题 分布式锁Java实现 附带案例和实现思路代码
43 2
|
1月前
|
SQL 存储 数据管理
Hadoop-15-Hive 元数据管理与存储 Metadata 内嵌模式 本地模式 远程模式 集群规划配置 启动服务 3节点云服务器实测
Hadoop-15-Hive 元数据管理与存储 Metadata 内嵌模式 本地模式 远程模式 集群规划配置 启动服务 3节点云服务器实测
57 2
|
1月前
|
分布式计算 Hadoop
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
Hadoop-27 ZooKeeper集群 集群配置启动 3台云服务器 myid集群 zoo.cfg多节点配置 分布式协调框架 Leader Follower Observer
47 1
|
1月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
44 1
|
1月前
|
分布式计算 Hadoop 网络安全
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
30 1
|
1月前
|
存储 机器学习/深度学习 缓存
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
44 1
|
1月前
|
分布式计算 资源调度 Hadoop
Hadoop-05-Hadoop集群 集群WordCount 超详细 真正的分布式计算 上传HDFS MapReduce计算 YRAN查看任务 上传计算下载查看
Hadoop-05-Hadoop集群 集群WordCount 超详细 真正的分布式计算 上传HDFS MapReduce计算 YRAN查看任务 上传计算下载查看
47 1
|
1月前
|
存储 SQL 消息中间件
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
Hadoop-26 ZooKeeper集群 3台云服务器 基础概念简介与环境的配置使用 架构组成 分布式协调框架 Leader Follower Observer
47 0