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

简介: 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

相关文章
|
6月前
|
存储 人工智能 Cloud Native
阿里云渠道商:OSS与传统存储系统的差异在哪里?
本文对比传统存储与云原生对象存储OSS的架构差异,涵盖性能、成本、扩展性等方面。OSS凭借高持久性、弹性扩容及与云服务深度集成,成为大数据与AI时代的优选方案。
|
8月前
|
存储 运维 安全
阿里云国际站OSS与自建存储的区别
阿里云国际站对象存储OSS提供海量、安全、低成本的云存储解决方案。相比自建存储,OSS具备易用性强、稳定性高、安全性好、成本更低等优势,支持无限扩展、自动冗余、多层防护及丰富增值服务,助力企业高效管理数据。
|
11月前
|
存储 人工智能 Kubernetes
AI 场景深度优化!K8s 集群 OSSFS 2.0 存储卷全面升级,高效访问 OSS 数据
阿里云对象存储OSS是一款海量、安全、低成本、高可靠的云存储服务,是用户在云上存储的高性价比选择…
|
12月前
|
存储 Kubernetes 对象存储
StrmVol存储卷:如何解锁K8s对象存储海量小文件访问性能新高度?
如何提升海量文件的数据读取速率,对于AI训练集管理、量化回测、时序日志分析等场景尤为重要。阿里云容器服务(ACK))支持StrmVol类型存储卷,基于底层虚拟块设备及内核态文件系统,显著降低海量小文件访问延迟。
|
12月前
|
存储 Kubernetes 对象存储
StrmVol 存储卷:解锁 K8s 对象存储海量小文件访问性能新高度
本文介绍了阿里云容器服务(ACK)支持的StrmVol存储卷方案,旨在解决Kubernetes环境中海量小文件访问性能瓶颈问题。通过虚拟块设备与内核态文件系统(如EROFS)结合,StrmVol显著降低了小文件访问延迟,适用于AI训练集加载、时序日志分析等场景。其核心优化包括内存预取加速、减少I/O等待、内核态直接读取避免用户态切换开销,以及轻量索引快速初始化。示例中展示了基于Argo Workflows的工作流任务,模拟分布式图像数据集加载,测试结果显示平均处理时间为21秒。StrmVol适合只读场景且OSS端数据无需频繁更新的情况,详细使用方法可参考官方文档。
1591 145
|
存储 弹性计算 数据管理
阿里云对象存储oss怎么收费?存储费用+流量收费标准
阿里云对象存储OSS收费标准包含存储费、流量费及请求费等,支持按量付费与包年包月两种模式。标准型本地冗余存储按量付费价格为0.09元/GB/月,包年包月500GB预留空间优惠价118元/年。流量费仅收取公网出方向费用,忙时0.50元/GB,闲时0.25元/GB。更多详情可参考官方页面。
2308 91
|
存储 前端开发 Java
Harry技术添加存储(minio、aliyun oss)、短信sms(aliyun、模拟)、邮件发送等功能
### SpringBoot3 + Vue3 前后端分离的Java快速开发框架更新 本次更新主要包含以下内容: 1. **端口修改**:为避免与Minio存储服务冲突,后端启动端口从9000改为9999。 2. **添加存储支持**:集成Minio和阿里云OSS对象存储服务,详细配置请参考相关文档。 3. **短信服务**:接入阿里云短信服务,并增加模拟发送功能,方便本地测试。 4. **邮件发送**:引入邮件发送功能,支持简单文本邮件和带附件邮件。 5. **完善个人中心**:优化个人中心页面,提升用户体验。
454 85
Harry技术添加存储(minio、aliyun oss)、短信sms(aliyun、模拟)、邮件发送等功能
|
11月前
|
存储 人工智能 测试技术
AI 场景深度优化!K8s 集群 OSSFS 2.0 存储卷全面升级,高效访问 OSS 数据
OSSFS 2.0通过轻量化协议设计、协程化技术及FUSE3低级API重构,实现大文件顺序读写与小文件高并发加载的显著提升,在实际测试中表现出高达数十倍的吞吐量增长。适用于机器学习训练、推理等对高带宽低延迟要求严苛的场景,同时支持静态和动态挂载方式,方便用户在ACK集群中部署使用。
1281 34
|
10月前
|
存储 关系型数据库 MySQL
成本直降30%!RDS MySQL存储自动分层实战:OSS冷热分离架构设计指南
在日均订单量超500万的场景下,MySQL数据年增200%,但访问集中在近7天(85%)。通过冷热数据分离,将历史数据迁移至OSS,实现存储成本下降48%,年省72万元。结合RDS、OSS与Redis构建分层架构,自动化管理数据生命周期,优化查询性能与资源利用率,支撑PB级数据扩展。
669 3