什么是存算分离架构？

随着硬件技术的快速进步，尤其是网络和存储设备的性能迅速提升，以及云计算厂商推动软硬件协同加速的云存储服务，越来越多的企业开始基于云存储来构建数据存储服务，或数据湖，因此就需要单独再建设一个独立的计算层来提供数据分析服务，这也就是存算分离架构（Disaggregated Storage and Compute Architecture）。本文介绍存算分离架构。

— 背景介绍 —

Apache Hadoop开启了分布式存储的浪潮，其采用的架构是“存算一体”架构，即在一个集群中实现计算和存储功能，并且为了保证尽量减少横向网络带来的性能损失，计算引擎在设计上采用了“计算贴近存储”的设计，即每个计算任务会选择在对应的数据文件所在的服务器上运行，这样就可以发挥本地IO的性能，避免大量点对点的数据传输导致的网络单点瓶颈问题。下图描述了这个设计，每个工作节点上都有存储服务和计算服务。

从一个抽象的角度，存算分离架构如下图所示，其存储层和计算层相对独立，存储层采用HDFS或其他与Hadoop兼容存储（HCFS）甚至是关系型数据库，而计算层一般采用多样化的计算引擎，如Spark、Presto、Flink等。这种架构带来的的好处主要在以下三个方面：

• 更方便的为不同的业务提供数据分析服务，对接不同的计算引擎，避免热门数据要在不同的业务都重复存储的问题。
• 计算层和存储层可以按照各自业务的需求来做独立扩缩容，一般情况下计算资源的增长速度要显式快于存储增长，这种方式就可以减少存储部分的成本。
• 计算服务与存储服务相对资源隔离，对业务稳定性也有很好的提高

— 架构目标与技术要求 —

最近几年，存算分离架构不仅在公有云上广泛落地，在私有化场景下，也逐渐成为热点。但是需要特别强调的是，存算分离架构并不等同于采用兼容S3接口的对象存储来构建数据湖，也不是采用容器化来实现资源隔离或者弹性伸缩，更好的满足业务需求是存算架构升级的一个根本原因。由于学术界没有对这个架构有过严谨的讨论和定义，本文尝试对存算分离架构做一个比较抽象的定义：

存算分离的架构参考示意图如下：

• 数据的灵活开放性

这是存算分离的一个最主要的业务目标，能够将数据更好更灵活的开放给业务分析。每个业务团队可能有自己的数据分析的技术栈和数据架构，譬如做交互式数据分析的团队比较依赖数据库和BI工具构建的数据集市，而做预测性分析的团队则依赖机器学习和数据湖等，因此存算分离架构在存储层提供相对统一的接口，而计算层能够支持多种计算引擎，并且可以基于存储层的数据接口来做数据查询和分析。这种方式的好处是大部分数据仅存储一份，而不是每个业务用户都保存一份自己需要的数据结果，另外用户做数据分析可以采用Serverless模式按需申请数据和计算资源，降低项目启动成本，为各个业务做数据创新提供灵活性和便利性。

• 计算与存储层独立的可扩展性

这是一个非常直接的技术需求，就是存储层和计算层的服务相对独立，尤其是计算服务可以在没有数据存储的服务器上部署，可以按照业务的特点来灵活对计算资源还是对存储资源做扩缩容。基于Hadoop的存算一体的框架，如果计算资源不足就需要扩容集群，此时存储也整体扩容，这样可能会导致存储资源使用率低的问题。而采用存算分离架构，计算资源不足就扩容专门用于计算的服务器而存储资源保持不动，或者存储资源不足的时候对存储池进行扩容，这样可以提高整体的资源使用率，也可以更好的管理异构服务器。

• 提高存算的资源隔离性

存算资源的隔离性是另外一个推动存算分离架构的技术需求，在存算一体的架构中，如果计算需求增加，那么只能在服务器上增加计算服务，而如果资源隔离性不足，那么计算服务和存储服务就会争抢同一份内存或计算资源，从而导致服务的稳定性下降。而如果通过架构升级保证了存算服务的资源隔离性，数据平台本身的稳定性和可运维性就可以得到较大的提升

• 与存算一体等同的性能

除了业务目标以外，需要注意的一点，存算一体通过“计算贴近存储”的方式来保证性能，而存算分离框架就不可避免会导致数据分析过程中有更大量的网络和存储流量，从而需要做更多的技术创新来保证数据分析性能可以与存算一体处于同一等级，可以实现的方式可以包括更好的网络/存储硬件以及配套的管理策略，或者是通过更好的云调度算法，亦或是更好的数据缓存策略等方式来实现。业内已经有很多的企业在探索存算分离架构的落地，目前该架构在公有云领域落地较多，而在私有化领域该技术还在快速发展中，推动相关技术发展的有几个流派，包括大数据平台厂商、云厂商、存储厂商以及数据库厂商。这些不同的路线在技术实现上有很多的相似性，也有各自的独特性。

— 星环大数据平台的存算分离—

星环科技从2015年开始探索大数据的云化，并且选择了Kubernetes和Docker技术来实现这一路径，并且在2018年完成了产品化Transwarp Data Cloud并完成生产落地。在当时存算分离架构还没有被正式提出来，而基于K8S实现的数据云架构在技术架构上也实现了存算分离，因此我们也对相关架构设计做个详细的阐述。

在设计上，我们将大数据平台与服务总体抽象为四层：云操作系统层、数据存储层、计算层和数据应用服务层。

云操作系统层负责将 CPU、GPU、内存、SSD 和 HDD 等资源抽象为一个统一的资源池，这样无论各个服务器的配置异构差异情况，都可以被有效的实时利用起来，提高资源有效利用率。云操作系统层对上层屏蔽底层硬件细节，以声明式的方式对外暴露存储卷、CPU、GPU、内存等资源接口，上层数据存储或者计算引擎可以通过声明式的增删资源来实现云化的弹性扩展，而无需做出代码上的变化，这个也是当前比较流行的Infrastructure as Code的设计理念。

应用服务层同样采用容器技术，支持微服务、传统应用、.Net 应用等容器化并在云平台上运行。应用可以设置调度优化属性，贴合计算或存储来实现最优化性能。

在数据存储层，我们将 HDFS、Search 等分布式存储进一步细化为各个子服务，并将这些子服务逐步的容器化，同时为了支持高性能的数据存储，采用了本地存储卷的方式来支持数据存储，而没有使用分布式云存储。这样做的好处可以让存储服务的部署、运维都变得比较简单，扩缩容与跨节点迁移虽然不能像微服务那样平滑，但是操作因为容器化而相对比较标准化。在实际部署时，TDC允许企业内每个业务部门采用独立租户的方式按需启动内部的分布式存储，也可以让多个租户全局共享同一个分布式存储实例。由于使用本地存储，同一个磁盘在调度上被限制为只允许一个高IO吞吐的存储服务来使用。

在分布式计算层，TDC将数据库计算节点和人工智能框架Spark、TensorFlow等相关计算服务容器化，实现在线的动态调度、弹性扩缩容等。为了保证数据分析性能，我们还是延续了存算一体的思想，尽量让计算贴近存储，这个优化的思路是分布式存储层直接提供元数据接口让计算引擎了解数据文件的分布情况，并将相关信息暴露给云操作系统调度器，调度器会通过为服务打tag等方式，将计算服务尽量贴近数据节点来运行，从而实现最优化的分析效率。

计算服务的动态弹性是存算分离架构的一个核心目标，由于TDC已经将内部计算引擎微服务化后以容器方式编排，基于K8S的调度编排能力就可以根据业务需求灵活的增删实例数量，保证秒级的扩缩容效率。我们设计了基于时间周期的计算单元弹性伸缩和基于工作负载的弹性伸缩两种调度策略。

对于主要提供批处理服务的关系型分析引擎Inceptor或提供湖仓一体能力的ArgoDB，由于夜间批处理任务和日间数据分析存在明显的潮汐效应，因此运维管理人员可以按照各自业务的特点来选择合适的调度策略。基于时间周期的弹性伸缩比较适合业务时间非常确定的场景，而基于工作负载的弹性伸缩在理论上使用场景更广，不过对相关的性能指标的要求也会更高。

从最终企业用户部署落地的效果来看，星环TDC为企业提供了一个统一的基于容器技术的多租户存算分离架构，不同租户在网络层隔离，实现类似公有云上的VPC的效果。不同租户之间数据隔离，但可以通过中心数据湖里部署的数据存储来做数据共享。一个物理节点上可以运行分属于不同租户的多个不同的有状态应用，调度器会根据资源情况来做均衡，但存储服务与计算服务独立调度，每个租户的计算服务支持默认弹性，在负载低时可以使用少量计算资源，而在负载高时操作系统将自动化扩容。

— Cloudera大数据平台的存算分离—

在解决存储层和计算层的资源隔离性的问题上，Cloudera期望借助于Kubernetes和Docker技术来解决服务的隔离性以及满足数据分析的灵活性问题。从2019年开始Cloudera和Redshift合作开始研发基于容器化的大数据平台，并于2021年开始将其机器学习产品Cloudera Machine Learning（CML）部署到Kubernetes上，这样就让用户比较方便的灵活的使用CML用于机器学习的工作，达到了部分效果。不过CDP的Private Cloud Base中的存储和计算产品（如Hive、HDFS、Hbase、Kudu、Impala等）还没有实现基于Kubernetes的云化交付，因此还不能灵活开放给业务，并且资源隔离上做的也不好。在实际部署落地时，如果需要能够运行一个云化的机器学习或者数据工程产品，还需要单独基于裸金属部署一个Private Cloud Base，一般数据湖是构建在Private Cloud Base上，为上层的多租户的算力服务提供数据接口。CDP拓扑架构如下图所示，下层Private Cloud Base是主要的存储层，上层Private Cloud Base是主要的计算层，其存算分离的抽象的粒度比较大，是多个组件构成的一系列服务。

此外，在数据湖层为了能够更灵活的做分离，Cloudera研发了兼容S3接口的Ozone存储项目，作为HDFS的一个补充。HDFS采用的元数据管理模型，导致其能够处理的文件数量与Namenode的服务内存密切相关，因此存在文件数量的上限。Ozone重新设计了元数据管理算法，使得管理的文件数量上限可以达到数十亿个，并且底层的数据存储基于Hadoop Distribution Data Store，复用了原来HDFS为了性能做的很多设计并且采用Raft协议来实现了分布式一致性。

Ozone的架构图如上，它的接口层支持多种协议，包括兼容Hadoop的Ofs和O3fs，以及S3协议，并且提供了Java API和命令行支持。由于Ozone来自Hadoop社区，因此原来基于Hive、Spark等Hadoop社区组件构建的应用程序是可以平缓迁移到Ozone上，此外新的采用S3协议的应用也同样可以支持，这比类似Ceph的技术方案在生态兼容上有很大的优势。Ozone目前刚进入GA阶段，还需要持续的接受生产案例的打磨来提高其成熟度、安全性等。