共计 4567 个字符，预计需要花费 12 分钟才能阅读完成。
随着硬件技术的疾速提高，尤其是网络和存储设备的性能迅速晋升，以及云计算厂商推动软硬件协同减速的云存储服务，越来越多的企业开始基于云存储来构建数据存储服务，或数据湖，因而就须要独自再建设一个独立的计算层来提供数据分析服务，这也就是存算拆散架构（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 阶段，还须要继续的承受生产案例的打磨来进步其成熟度、安全性等。