这篇文章的标题是我们过去几个月经常和客户探讨的一个问题，也是很多大公司正在思考的问题，在这里分享一下我们的观点和经验。
二十年前，大规模存储一般使用的是专有硬件设备方案（NAS），通过特殊的高性能通讯硬件给其他应用提供访问接入。这种方案不太容易扩展，而且价格昂贵，无法满足互联网的高速下的超大规模数据存储需求。
让我们回到 2001 年，Google 的 GFS 开创了先河，第一次用普通的 x86 机器和普通硬盘搭建了大规模存储。当时的 HDD 的吞吐量大概在 50MB/s，通过接入多个硬盘的方式可以提高单机吞吐量到 1GB/s 。但当时的主流网络只有 100Mb，通过网络远程访问数据实在是太慢了。为了解决数据的快速访问，Google 创造性地提出来了计算和存储耦合的架构，在同一个集群中实现计算和存储功能，并将计算的代码移动到数据所在的地方，而不是将数据传输到计算节点，有效解决了分散在各个弱连接的存储节点间的海量数据访问的困难。后来者 Hadoop 等也是完全照搬了这个架构，数据本地化是其中一个非常重要特性来保证整体的性能。还做了很多优化来进一步降低机器间、机柜间的网络带宽消耗。
经过 10 年的发展，网络的性能发生了巨大的变化，从之前主流 100Mb 到 10Gb，增长了100倍，而同时期的 HDD 硬盘的性能基本没有太大变化，倒是单盘的容量增大了很多。由于各种社交网络应用对网络的带宽要求很高，加上核心交换机和 SDN 的强力支撑，不少公司实施了点对点的 10Gb 网络架构（任意两个机器之间都有 10Gb 带宽保障）。另外，各种高效的压缩算法和列存储格式也进一步减少了 IO 数据量，将大数据的瓶颈逐渐由 IO 变成了 CPU。在数据本地化优化得很好的大数据计算集群中，大量网络带宽是闲置的，而因为存储和计算耦合在一个集群中，带来了一些其它问题：
- 在不同的应用或者发展时期，需要不同的存储空间和计算能力配比，使得机器的选型会比较复杂和纠结；
- 当存储空间或计算资源不足时，只能同时对两者进行扩容，导致扩容的经济效率比较低（另一种扩容的资源被浪费了）；
- 在云计算场景下，不能实现真正的弹性计算，因为计算集群中也有数据，关闭闲置的计算集群会丢失数据。
因为以上这些存储和计算耦合导致的问题，不少公司开始思考这种耦合以及数据本地化的必要性。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 的更好替代，为云上的大数据提供完全弹性的存储解决方案，让云上的大数据获得真正的弹性（完全按需使用）。
