导读：大数据集群从最初开始建设时，一般都采用存算一体化的架构，主要是考虑部署简单、管理起来也方便。但是随着集群规模的不断扩大，在整个集群的资源规划和稳定性上都遭受到了不同程度的挑战。业务数据不断增长和技术框架的不断革新，导致集群资源无法始终维护在一个存储和计算比较均衡的状态。因此，对集群适当做一些存储和计算的拆分，一方面可以提升集群的稳定性和性能，另外一方面，也可以降低整体的成本。达到降本增效的效果。
最近跟好几个用户在交流的时候都提到了大数据的存算分离，有的是云厂商给他们推荐的方案，比如：某某运营商说最近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%以上。
2 存算分离和多层存储
基于业务和技术的发展，对集群进行存算分离化改造能够提升整体的计算资源利用率，在此基础之上，根据业务自身发展的特性，还可以对业务的存储做多层存储拆分，进一步降低数据存储的成本。
一般来说，业务的数据量是一直不断在增长的，而应用使用的数据，都具有一定的时效性，更多的会集中在最近一两个月甚至最近一两周的数据，大量历史数据更多的是在某些特殊的场景下会被利用到，比如：几个月前的用户行为数据。大量的存储空间被这种重要但已经“过期”的数据所占据。在大部分的存储系统中，经常被访问的数据(热数据)一般只占了15% ~ 25%，而不经常被访问的数据(冷数据)却占了75% ~ 85%。由于冷数据不活跃的特点，如果对冷数据的存储进行一定的改造，将会取得较为不错的成本收益。
上图中，我们对原本存在IDC1中的存储集群做了一定的拆分，把原本一个集群拆分成两个集群，分别称之为：热集群和冷集群，热集群的搭建与原先一致，而冷集群在搭建的时候，我们采用了EC(纠删码)的方式进行了改造，使得大量的冷数据在保证原来的高可用性的同时，存储成本降至原来的50%，在业务具有较大规模冷数据的情况下，该种方式也可以为业务减少大量数据存储成本。
3 存算分离和计算混部
存储上可以根据数据冷热做到多层存储，计算层也可以通过一定的混部措施来提升业务整体计算的利用率。按照业务的特性，一般在线的业务高峰期每天的10:00-24:00，而离线计算的高峰期在24:00-8:00，从时间分布来看，在线业务与离线业务存在较好的互补特性。因此，如果能够把部分离线的任务在在线业务的低峰期，能跑在在线业务的服务器上，做到在线离线业务混合部署，也是可以节省离线计算服务器。
2021年，杭研大数据联合云计算、传媒数据团队在传媒大数据场景下进行了在线/离线计算混合部署试点，试着把业务的Spark任务调度到轻舟K8s上，使得大数据任务在业务在线业务低峰实现混部，从而减少整个BU大数据计算的节点数量。
4 云环境下的存算分离
大数据私有场景下的存算分离一般通过把存储和计算拆开，分别采用更高密度的存储/计算机型来节省整个成本，存储依旧采用HDFS的方式来搭建集群。而在云环境下，本身提供了对象存储服务(如：S3，OSS，OBS等)，在搭建大数据平台的时候，是否可以选用对象存储来做大数据存储的底层。答案当然是可以，而且大多数云上大数据方案都是这么做的，如：AWS的EMR、阿里云的MaxCompute、华为的MRS等等。杭研大数据团队针对不同的客户需求，也设计了云上部署方案，如下：
在上述整个云上部署方案中，我们采用了云平台的云主机来搭建计算引擎，同时使用了各家云平台的对象存储来作为底层数据存储。云上部署平台相比于云下私有化部署的大数据平台来说，最显著的一个变化就是用对象存储+Block Cache的方式替换了原来的HDFS存储，之所以引入Block Cache主要有两方面的因素考虑：Block Cache通过标准协议，能够屏蔽底层不同对象存储，使得整体对上层计算无感知 Block Cache兼具缓存功能，能够尽量减少远程对象存储访问延迟对计算任务的影响。
除了架构上有些许不同之外，采用云原生对象存储作为大数据的存储层，需要考虑性能上的影响，比如，对象存储对于像remove之类的命令，整体性能会比较低下，特别是在对大目录的remove上，而大数据计算场景下，会有较多的insert overwrite操作，会频繁的去删除老的数据后写入新的数据。因此对于像remove类的接口，如果性能很差，会大幅度影响计算性能。
5 总结
回过头来看看开头的两个问题：集群经常出问题，需要做存算分离改造，其实还可以有较大的优化空间，比如：增加NameNode JVM的内存，或者合并小文件减少元数据信息等等，一般情况下，几十台的规模远不会达到HDFS性能瓶颈。
至于第二个，为了技术栈的统一，需要衡量对象存储给大数据计算造成的性能影响后再来综合考虑。
