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

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

二十年前,大规模存储一般使用的是专有硬件设备方案(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 详细的分享,他们把这种架构称为 DisAgg。Google 在这方面应该是做得更早,只是没有太多公开信息可供参考。

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

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