数据架构新篇章：存算一体与存算分离的协同演进

前言

降本增效大环境下，存算分离架构如火如荼，Why？
首先，先来简单了解两个架构的侧重点：

• 存算一体是性能敏感型的架构
• 存算分离是成本敏感型的架构

而大家所谈论的降本增效，是降本在前增效在后，先降本再考虑增效，故而降本才是真实的着重点！
所以，这也是为什么，当下存算分离架构被追捧的主要原因。
以上是从存算一体和存算分离架构结果效应而言，接下来我们从架构本身来聊聊它们之间的故事。

被误解的存算分离

经常会有小伙伴，会发出这么些疑问：
“Hadoop是不是本身就带有存算分离架构的属性，HDFS存储和YARN计算管理分别部署在不同的节点不就是存算分离？”
“湖仓一体，湖作为有界的流批一体存储，仓进行查询加速计算，这是不是也可以理解为存算分离？”
…
从常规的部署拓扑图而言，Hadoop的HDFS和Yarn分开部署、湖仓存算分工，字面上是存和算分离了，但从存算一体的概念和存算分离的定义而言，并不是！

存算一体的概念

存算一体的过往

存算一体的概念形成，最早可以追溯到上个世纪70年代。随着云计算和人工智能应用的发展，计算中心面临着前所未有的数据洪流，数据搬运的速度慢和搬运过程中的高能耗等问题成为计算的主要瓶颈点。
在传统的冯·诺依曼计算架构中，数据需要频繁在存储单元和计算单元之间传输，这不仅导致了巨大的能耗，还造成了计算效率的降低。存算一体技术通过直接利用存储器进行数据处理或计算，将数据存储与计算融合在同一个芯片的同一区域，从而彻底消除了冯·诺依曼架构的瓶颈。特别是在深度学习神经网络这种大数据量和大规模并行的应用场景中，存算一体技术显得尤为适用。
所以，存算一体也通指为"compute-in-memory"或"compute-near-memory"，通俗而言就是让存储和计算更贴贴。它主要优势在于能够打破存储墙，消除不必要的数据搬移延迟和功耗，并利用存储单元提升算力，从而成百上千倍地提高计算效率。在特定领域可以提供更大的算力（超过1000TOPS）和更高的能效（超过10-100TOPS/W），将能耗降低至1/10至1/100；使用存储单元参与逻辑计算，从而提升算力，相当于在面积不变的情况下大规模增加计算核心数。

存算一体的演进

回到世纪之初大数据兴起之时，用户数据快速膨胀，对海量数据的分析需求越来越明显，各行各业都在搭建自己的数据仓库和商业智能系统。但传统的Unix主机和高端存储价格高昂，搭建一个用于决策支持的数据仓库系统需要巨额投资。此外，可能耗费巨资搭建的系统在进行海量数据统计汇总时速度非常慢。
经过分析发现，问题的根本在于IO瓶颈。因为计算单元处理数据，但并不存储数据，所有的数据都需要从存储中取出。而存储在取数据时是一个数据块一个数据块地取，无法判断这个块中哪些数据是计算单元需要的。在传统的行存储场景中，一个决策查询可能只需要几个字段，但必须把所有数据都传输到计算单元进行处理和判断，之后再丢弃不需要的数据。这不仅浪费了大量IO，还因为计算单元内存不足，在大表join关联时会产生大量临时数据，这些数据需要在存储中临时存放，造成了进一步的资源浪费。

为了应对这些挑战，自然催生出新的架构。普遍的原理是在OLTP系统中每次操作都是小数据量，适合移动数据到计算单元；而在OLAP系统中每次都会涉及大量数据处理，适合移动计算到数据单元。这意味着海量数据首先在本地进行初步加工，减少数据量后再参与后续计算，从而节省IO和算力，提高性能。在这个阶段，技术的核心关注点在于减少网络间传输的IO。通过列式存储来支持分析系统中按列统计的习惯，每次查询只需要取需要的列，从而减少无谓的IO。同时，利用各种索引技术加快数据定位和存取的效率，闪存技术的高速发展也进一步提升了系统的性能。
总而言之，存算一体的概念核心是为了解决传统计算架构中的数据搬运瓶颈和存储单元参与逻辑计算低效的问题。通过将存储和计算功能集成在同一芯片上，大幅减少数据在存储和计算单元之间的传输需求，显著降低了能耗并提升了计算效率。在大数据分析和需求不断增长的背景下，基于这种概念，通过减少网络传输和IO操作，优化存储和计算的协同工作，也为大数据架构提供了一种高效的解决方案。

存算分离的定义

存算分离的过往

提到存算分离，不得不提一位传奇人物，即Oracle的创始人之一Larry Ellison。自1977年创建SDL并在1982年更名为Oracle以来，Oracle迅速利用小型机的快速发展占据了商用数据库市场的主导地位。直至今日，Oracle仍然在DB-Engine排行榜上名列前茅，数十年未被动摇。
存算分离的概念最早在Unix系统的普及过程中逐渐成型。当时，市场上能够提供Unix主机的企业数量不断增加，除了IBM，还有HP、Compaq和富士通和Sun等公司。这些Unix主机普遍采用了连接独立存储服务器的方式，第一次实现了存储和计算的分离。
在这次存算分离的实现过程中，几项关键技术起到了重要作用，包括成熟的网络组网技术和存储网络技术，当然还有Oracle自身的杀手级技术——缓存融合。通过这些技术，用户可以获得N多好处：

1. 增强系统的伸缩性：用户可以独立增加数据库服务器来提升处理能力，或者增加存储服务器来扩大数据库容量。
2. 增强系统的容错性：在存算分离架构下，通过冗余配置可以防止任何一个环节出现单点故障，增强了数据库系统的持续服务能力。
   内存融合技术则是允许两个计算节点共享对方节点的内存数据，从而减少磁盘读取带来的IO负担。缓存融合技术允许不同RAC节点通过高速内网共享各节点数据库实例内部缓存的数据块，直接在节点间传递而无需等待写入磁盘，从而实现高效的协同工作。为了降低远端内存访问时的主机消耗，Oracle还使用了基于RDMA技术的RDS协议，可以直接绕开CPU，实现远程内存的直接读取，进一步提升访问效率。

存算分离的演进

随着公有云的快速发展，按需付费的理念逐步深入人心，用户对大规模数据分析的需求也要求能够按需供给，而传统MPP存算一体的紧耦合架构已经无法满足这种需求。与此同时，网络技术和存储技术的飞速发展，自然而然地催生了新一代的云原生数据库架构——存算分离架构。
以业界最著名的Snowflake公司为例，其创始人Benoit Dageville和Thierry Cruanes曾在Oracle从事数据工程工作多年，后来他们决定在云上创建数仓，联合另一位创始人Marcin Żukowski共同创立了Snowflake。为了更好地利用云上的资源，他们首先将存储和计算再次分离。数据被大量分区地存储在共享的对象存储中，并以列式存储方式保存。中间的计算层通过无状态的虚拟数据仓库来动态拉起和销毁，实现用户不同工作负载的灵活调度和计费。这一设计目前已成为云原生数仓的标准范本。
Snowflake的成功进一步阐明了存算分离的定义和优势。在存算分离架构中，数据存储和计算资源被解耦，从而实现了更高的资源利用率和灵活性。数据被存储在共享存储中，而计算任务可以根据需求动态地启动和销毁。这种方法不仅提高了系统的弹性，还减少了资源的浪费。
结合Snowflake关于存算分离的论文来分析关于存算分离的定义：

可以简单总结为两点：

1. 弹性：需要有足够的弹性支持，分为存储和计算两个维度：
   • 存储：基于对象存储或者公用存储池具备可灵活弹性，可以使用更低成本的对象存储，HDFS 等低成本存储。
   • 计算：弹性的计算资源，并且计算节点是无状态的。例如不同时间点使用不同规模的计算资源服务业务请求，按需使用计算资源，节约成本。
2. 缓存：主要指的是数据和元数据缓存：
   • 数据缓存：只要是跨节点或跨网络环境进行数据通信交换计算之类的操作，必然需要缓存加速，通常是基于 LRU 策略和 TTL 策略去实现。
   • 元数据缓存：主要是为了提升整体服务的易用可靠性，比如解决对象存储中常见的List（列出对象操作；当对象存储中的文件数量非常多时，执行List操作可能会变得缓慢，因为需要遍历大量的对象以生成列表）和Rename（重命名对象，重操作）问题。

那么，结合以上存储一体的概念和存算分离的定义而言，Hadoop和湖仓架构并不算严格意义上的存算分离，只是存算一体紧耦合的架构。

存算一体和分离示例

以Apache Doris的存算一体和存算分离架构为例：
Doris 的整体架构由两类进程组成：Frontend (FE) 和 Backend (BE)。其中 FE 主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作；BE 主要负责数据存储、查询计划的执行。

1. 存算一体：在存算一体架构下，BE 节点上存储与计算紧密耦合，数据主要存储在 BE 节点上，多 BE 节点采用 MPP 分布式计算架构。
   存算一体的优点

• 部署简易：Apache Doris 不需要依赖类似外部共享文件系统或者对象存储，仅依赖物理服务器部署 FE 和 BE 两个进程即可完成集群的搭建，可以从一个节点扩展到数百个节点，同时也增强了系统的稳定性。
• 性能优异：Apache Doris 执行计算时，计算节点可直接访问本地存储数据，充分利用机器的 IO、减少不必要的网络开销、获得更极致的查询性能。

存算一体的适用场景

• 简单使用/快速试用 Doris，或在开发和测试环境中使用。
• 不具备可靠的共享存储，如 HDFS、Ceph、对象存储等。
• 业务线独立维护 Apache Doris，无专职 DBA 来维护 Doris 集群。
• 不需极致弹性扩缩容，不需 K8s 容器化，不需运行在公有云或者私有云上。

2. 存算分离：BE 节点不再存储主数据，而是将共享存储层作为统一的数据主存储空间。同时，为了应对底层对象存储系统性能不佳和网络传输带来的性能下降，Doris 引入计算节点本地高速缓存。主要角色如下：

• FE: Doris FE 节点。
• BE: 无状态化的 Doris BE 节点，BE 上会 Cache 一部分 Tablet 元数据和数据以提高查询性能。
• Cluster: 无状态的计算资源 (BE 节点) 集合，多个 Cluster 共享一份数据，Cluster 可以随时弹性加减节点。
• Meta-service: Doris 存算分离元数据服务，主要负责处理导入事务，tablet meta, rowset meta 以及集群资源管理。这是一个可以横向扩展的无状态服务。
• Foundationdb: 实际存储元数据的分布式事务 kv。

存算分离的优点

• 弹性的计算资源：不同时间点使用不同规模的计算资源服务业务请求，按需使用计算资源，节约成本。
• 负载 (完全) 隔离：不同业务之间可在共享数据的基础上隔离计算资源，兼具稳定性和高效率。
• 低存储成本：可以使用更低成本的对象存储，HDFS 等低成本存储。

存算分离的适用场景

• 已使用公有云服务。
• 具备可靠的共享存储系统，比如 HDFS、Ceph、对象存储等。
• 需要极致的弹性扩缩容，需要 K8S 容器化，需要运行在私有云上。
• 有专职团队维护整个公司的数据仓库平台。
  

总结

基于上述的一些对比说明，数据架构中存算一体和存算分离的选择建议：

1. 如果数据量较小，是不建议走存算分离架构，至少也得几十或百来T的数据规模再考虑存算分离。因为存算分离虽然主打降本，但它的架构实施是相对复杂的，并且相对是更依赖于缓存cache加速提升性能，而cache这块也是需要综合考虑的成本。
2. 如果本身集群资源管控管控也够用，业务也比较求稳，上线的项目都跑的稳稳当当的，就不建议瞎折腾去跟风上存算分离了。本身存算分离架构实施比存算一体复杂许多，试错成本相对较高，还不如把时间拿去优化优化已有组件和数据建模体系，测试环境测测即可。
3. 性能高要求，还得是走存算一体。存储分离是在满cache的条件下，性能结果才能和存算一体相对持平。那么如果对性能有较高要求的业务线，不要轻易分离。
4. 当然，如果公司数据体量本身不小，公司又不卡成本，又有新的业务线可以试错。可以试试激进些上存算分离架构，有一定的结果站台后，再考虑大面积铺盖。

最后，Apache Doris下一个3.0大版本也将在最近推出，目前在走发版流程。主要新特性也是存算分离架构，当前已经有不少Doris用户在测试环境体验中，欢迎大家多多关注！