最近跟好几个用户在交流的时候都提到了大数据的存算分离，有的是云厂商给他们推荐的方案，比如：某某运营商说最近xx云一直在给他们推荐存算分离化改造，背景是有个几十台的HDFS小集群，存储的文件数量比较多，经常性出问题，xx云的商务就跟他们说用对象存储如何如何来解决问题，听起来感觉有点道理，但是又拿不定主意，毕竟整个改造过程动静大、周期长，而且需要很大的投入，无论从建设周期还是成本投入上来看，都需要慎重考虑。有的是为了技术栈统一，比如：某某医药类企业，在整体技术架构重构时，已经引入了xx对象存储，基于技术栈统一的角度，想了解下大数据基于对象存储下存算分离是否可行，如果可行，有没有什么潜在的风险？

上面的两个例子，都是最近碰到的，相信有类似疑问的用户还有很多，正好最近2年，我们在内部也在做集群的存算分离化改造，接下去，我们就来谈谈对于大数据做存算分离这件事到底应该怎么来考虑。个人认为：大数据集群是否适合做存算分离，主要从两个方面来考虑：

技术层面：存算分离是否能够简化我们的技术栈，或者解决某些瓶颈问题。

成本层面：存算分离能否在计算性能、存储空间等方面带来成本上的优势。

1.存算分离和存算一体化

相信早期的大数据集群的建设，都是采用存算一体化的形式进行的，购买几台即包含计算资源又带一定存储的机型来搭建整个大数据集群，如下图：

存算一体化的集群中每个节点都具备相同的硬件配置，我们早期内部典型的配置基本上是：48核，256GB内存，12块8T SATA盘，整体提供约48个CU(1CU包含1核，4GB内存)和96TB的存储。

随着业务的发展，我们发现，类似上述存算一体化的架构，在发展到一定阶段的时候，整体集群中的资源需求会打破原来存储计算之间的比例平衡，造成某一类资源的利用率一直无法提升。比如：内部某业务在两年的时间内数据存储量上涨到原来的4倍，而计算资源只上涨到原来的2倍，数据存储量需求明显比计算资源增长快，这时，如果继续采用存算一体化的机型就意味着我要满足存储资源增长的同时，计算资源也会增长4倍，而实际的需求只要2倍，计算资源存在过剩的情况。

除了业务外，技术上的不断革新带来计算能力的提升，也会导致原先的存算一体化资源配置出现比例失调的现象。就拿大数据领域离线计算来说，从最初的Hive发展到Spark，而Spark从Spark1.x到当前的Spark3.x，相比于最早初的框架的能力，整体性能上有数量级的提升。

综上，业务和技术的不断发展，会造成原先存算一体化体系下存储和计算的比例不断发生变化，我们很难找到一种合适的机型来满足不断变化的需求。因此，我们在后续的采购过程中，进行了部分存算分离采购的调整：计算资源和存储资源进行单独的方式采购，并且存储和计算都分别采用了更高密度的机型，从而把线上集群调整到一种合适的存算比例。

存算分离改造带来的另外一大好处是把原先大数据计算过程中的离散I/O(shuffle数据)和顺序I/O(数据块)进行了很好的拆分，解决了计算过程中的I/O瓶颈，从而进一步提升了CPU的利用率。

通过上述存算分离化改造，集群中大部分节点的资源利用率有了大幅度提升，全天CPU 95峰值维持在90%左右，平均CPU利用率从25%提升到55%以上。