前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >为什么说存储和计算分离的架构才是未来

为什么说存储和计算分离的架构才是未来

作者头像
Lu说
发布2022-06-07 19:57:31
5050
发布2022-06-07 19:57:31
举报

编者按:本文最初发表于 2018.07.07 JuiceFS 官方博客,那是还没有开始这个公众号,官博去年的文章里这篇阅读最多,所以在官微中也发一次,方便读者引用、转发、收藏。

以下开始正文 。


这篇文章的标题是我们过去几个月经常和客户探讨的一个问题,也是很多大公司正在思考的问题,在这里分享一下我们的观点和经验。

二十年前,大规模存储一般使用的是专有硬件设备方案(NAS),通过特殊的高性能通讯硬件给其他应用提供访问接入。这种方案不太容易扩展,而且价格昂贵,无法满足互联网的高速下的超大规模数据存储需求。

让我们回到 2001 年,Google 的 GFS 开创了先河,第一次用普通的 x86 机器和普通硬盘搭建了大规模存储。当时的 HDD 的吞吐量大概在 50MB/s,通过接入多个硬盘的方式可以提高单机吞吐量到 1GB/s 。但当时的主流网络只有 100Mb,通过网络远程访问数据实在是太慢了。为了解决数据的快速访问,Google 创造性地提出来了计算和存储耦合的架构,在同一个集群中实现计算和存储功能,并将计算的代码移动到数据所在的地方,而不是将数据传输到计算节点,有效解决了分散在各个弱连接的存储节点间的海量数据访问的困难。后来者 Hadoop 等也是完全照搬了这个架构,数据本地化是其中一个非常重要特性来保证整体的性能。还做了很多优化来进一步降低机器间、机柜间的网络带宽消耗。

经过 10 年的发展,网络的性能发生了巨大的变化,从之前主流 100Mb 到 10Gb,增长了100倍,而同时期的 HDD 硬盘的性能基本没有太大变化,倒是单盘的容量增大了很多。由于各种社交网络应用对网络的带宽要求很高,加上核心交换机和 SDN 的强力支撑,不少公司实施了点对点的 10Gb 网络架构(任意两个机器之间都有 10Gb 带宽保障)。另外,各种高效的压缩算法和列存储格式也进一步减少了 IO 数据量,将大数据的瓶颈逐渐由 IO 变成了 CPU。在数据本地化优化得很好的大数据计算集群中,大量网络带宽是闲置的,而因为存储和计算耦合在一个集群中,带来了一些其它问题:

  1. 在不同的应用或者发展时期,需要不同的存储空间和计算能力配比,使得机器的选型会比较复杂和纠结;
  2. 当存储空间或计算资源不足时,只能同时对两者进行扩容,导致扩容的经济效率比较低(另一种扩容的资源被浪费了);
  3. 在云计算场景下,不能实现真正的弹性计算,因为计算集群中也有数据,关闭闲置的计算集群会丢失数据。

因为以上这些存储和计算耦合导致的问题,不少公司开始思考这种耦合以及数据本地化的必要性。2013 年我初到 Facebook 时,隔壁组的同事就做了一个这方面的研究,看在关闭 Hadoop 的数据本地化优化的情况下,对性能究竟有多少影响。实测表明,对计算任务的整体影响在 2%以内,对数据的本地读优化已经不那么重要了。后来 Facebook 就逐渐往计算和存储分离的架构迁移,也对所用的大数据软件做了些调整以适应这种新的架构,他们在今年的 Apache Spark & AI Summit 上做了主题为 Taking Advantage of a Disaggregated Storage and Compute Architecture [1] 详细的分享,他们把这种架构称为 DisAgg。Google 在这方面应该是做得更早,只是没有太多公开信息可供参考。

在 AWS 等公有云上,基于网络的块存储逐步取代了单机的本地存储,使得公有云上的计算和存储耦合架构更加不合理(数据本地化并不是真实的,DataNode 内的本地读其实在物理层也是远程读)。针对公有云设计的大数据分析服务 Databricks 一开始就是采用了计算和存储分离的架构(直接使用 S3 作为存储),给产品带来了非常大的灵活性,按需创建和自动弹性伸缩的 Spark 集群是一大卖点(还能最大限度使用 Spot 节点来大大降低计算成本),非常受客户欢迎。因为 S3 只是对象存储,用于大数据计算时会有很多问题,Databricks 以及它的客户也被坑过很多次。Databricks 花了不少精力去改进和适配,使得 Databricks 上的 Spark 任务可以更快更稳定。AWS 上的先驱 Netflix 也是使用 S3 作为大数据的存储,他们针对 Hive 等做了很多改造才能稳定使用 (不是开源的S3mper)。JuiceFS 则是把这些改进进一步抽象和产品化,让它们能够更好地服务于包括大数据在内的更多场景,帮助更多的公司改善云上大数据体验,而不用重复地去解决 S3 等对象存储带来的问题。

因为网络的高速发展,以及大数据计算框架对 IO 的优化,使得数据本地化已经不再重要,存储和计算分离的架构才是未来。JuiceFS 正是顺应了这种发展趋势,是架构落后的 HDFS 的更好替代,为云上的大数据提供完全弹性的存储解决方案,让云上的大数据获得真正的弹性(完全按需使用)。

引用链接:

[1]https://databricks.com/session/taking-advantage-of-a-disaggregated-storage-and-compute-architecture

题图摄影 Drew Beamer on Unsplash


编者荐语那里写不下了:

这篇文章思路清晰的介绍了存算分离架构的发展,转载已获得原作者的授权。 文末的推广未做修改,读者自做甄别吧。

如若不是前文写的比较好,我也不会转载的,作为自己的一个知识储备吧。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-03-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Hadoop集群运维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档