StarRocks 3.0 存算分离版基于亚马逊云科技的最佳实践

介绍

StarRocks 致力于构建新一代极速全场景 MPP （Massively Parallel Processing）数据库，致力于帮助企业构建极速统一的湖仓分析新范式。从初创公司到企业，组织都在使用 StarRocks on AWS 解决方案进行数据分析和治理。 StarRocks on AWS 让我们的客户可以在全球各地快速可靠地构建自己的数据分析中心。现在，为了让更多用户以更低廉的成本进行数据分析和治理，我们推出了存算分离版本。让我们的用户可以提高资源利用率的同时优化成本。

存算分离的价值与优势

在 3.0 版本之前，StarRocks 一直使用基于 MPP 的存算一体架构。计算节点与本地存储绑定，利用单机多核并行，分布式计算，SIMD 等多种技术手段，实现了海量数据下的高性能数据分析。但存算一体架构存在一些局限性，主要表现为：

存算一体，导致资源浪费

存算一体模式采用了 shared-nothing 架构，每个节点独占自己的 CPU、内存、磁盘资源，节点之间不进行资源和数据共享。数据分析时，不同节点上的数据并行处理，不同节点间不发生计算资源争抢。例如：大规模数据导入场景需要占用大量的磁盘 IO、带宽和内存，但 CPU 资源需求较低。而报表分析场景需要大量 CPU 计算和内存，而对 IO 要求较低。在 share-nothing 的架构下，为满足不同业务场景的资源需求，用户往往需要预留超出实际所需的计算和存储资源，从而造成一定程度的资源浪费。

扩缩容时间成本高昂

MPP 架构中，数据通常按照一定的规则均匀的打散到集群的各个节点上。如需对集群增加或减少节点，就需要对数据进行 rebalance（重平衡）操作。rebalance 的目的是在新的计算节点加入和移除后，再次将数据重新均匀分布于集群现有节点。此过程会占用大量带宽和磁盘 IO 。数据量越大，rebalance 所需时长越长。因此，在存算一体的模式下，集群的扩缩容不可能在秒级完成。

为了进一步提升用户体验，帮助最终用户优化成本，提升性能，StarRocks 进行了架构升级。在 StarRocks 3.0 中，我们通过存算分离的架构解决了随着数据规模增加和计算复杂度增加所带来的成本压力以及运维压力。StarRocks 3.0 进一步优化了以下方面：

成本优化：亚马逊云上对象存储拥有近乎无限的存储空间，且相比于本地盘存储，成本大幅降低。
灵活扩缩计算集群：计算节点无状态，可以秒级添加或释放。用户可以根据当前集群负载灵活调配资源，弹性伸缩。
更高的数据可靠性：使用成熟稳定的对象存储相比于存算一体的多副本数据冗余存储的方式可以提供更高数据可靠性
计算资源物理隔离：在 StarRocks 3.0 版本中引入了 warehouse 的概念。warehouse 是计算节点的逻辑分组，用户可基于不同业务创建多个 warehouse。例如，在物流行业中，报表业务和实时监控业务可以各自有独立的 warehouse。不同 warehouse 可读取同一个数据源，从而达到不同业务计算资源物理隔离的效果。

StarRocks 3.0 存算分离版系统架构介绍

StarRocks 3.0 有两个版本，分别是存算分离版和存算一体版。两个版本有着一样的简洁架构。本文我们关注在存算分离版本上。在 StarRocks 3.0 存算分离版中只有两种类型的服务，FE（Front End）和 CN（Compute Node）。以下是 StarRocks 3.0 存算分离版的核心组件。

图 1. StarRocks 存算分离系统架构图

核心组件：

FE Worker：负责接受客户端请求以及对请求进行解析，并生成执行计划。StarRocks 的每个 Front End 节点都是一个 FE Worker。FE Worker 为无状态进程，可动态扩展。
CN Worker：负责数据计算，StarRocks 的每个计算节点（CN）都是一个 CN Worker。CN Worker 也是无状态进程。
Starlet：Worker（包含 FE Worker 和 CN Worker）上的代理。Worker 通过 Starlet 与 StarManager 交互，汇报自身状态，执行来自 StarManager 的指令。
Shard：是 StarManager 调度的基本数据单元。它代表了底层存储的一个数据分片。系统会将一张物理表划分为多个数据分片，每个分片即为一个 Shard。所有的 Shard 都存储在 Amazon S3 上。
StarManager：它是系统元数据的存储与管理模块，包含服务管理、物理资源管理与分配、Worker 的调度和迁移、负载均衡等模块。
ShardManager：负责 Shard 的管理和调度，解决如何将 Shard 放置到对应的 Worker 的基本问题。包括 Shard 的注册，调度，销毁生命周期管理，以及 Shard 与 Worker 的绑定关系管理。
WorkerManager：负责 Worker 的注册、销毁和调度工作。系统运行过程中 WorkerManager 也可以根据实际需求动态增加或者移除 Worker，以实现计算资源的弹性扩缩容。
StoreManager：管理 StarManager 拥有的所有存储资源，如 Amazon S3 存储。

在传统的存算一体架构中，用户数据存储于 Amazon EBS 上，或者 Amazon EC2 的实例存储（NVME）上。而存算分离架构中，数据存储于 Amazon S3 上。显然，计算节点对 Amazon S3 的访问速度低于对实例存储或者 Amazon EBS 的访问速度。因此，为了提升数据查询性能，计算节点可以利用 EBS 或者实例存储（NVME）缓存部分热点数据，以达到优化查询性能的目的。当用户在建表时指定开启缓存，计算节点在查询时就会优先从指定的缓存中读取数据。如缓存未命中对应数据，计算节点再访问 Amazon S3 读取对应数据，并同时将该数据加载入缓存。

至此，StarRocks 3.0 存算分离解决方案通过内存、缓存（EBS 或实例存储）、后端存储（Amazon S3），构建了一个多层次的数据存储体系。以达到热数据更快访问，冷数据更便宜地存储的目的。真正实现了高性能计算和低成本存储。

StarRocks 3.0 存算分离版本工作流程介绍：

StarRocks 存算分离方案的工作流程如图 2 所示。在整个执行过程中 FE 节点会将用户的请求转化成为内部的执行计划，并下发至计算引擎 CN（Compute Node）。CN 会执行数据扫描、查询计算、缓存数据管理等任务。

以下通过一个 SQL查询在存算分离架构下的执行过程来介绍 StarRocks 3.0 的工作流程：

图 2. StarRocks 存算分离工作流程图

客户端发起查询请求
FE 接受到请求后进行对 SQL 进行解析，生成逻辑执行计划
FE 向 ShardManager 请求 shard（数据分片）的分布信息
FE 向 WorkerManager 请求当前可用的 worker（计算节点）列表
FE 根据数据的分片信息，统计信息，节点列表生成对应的物理执行计划
FE 分发物理执行计划到各 CN worker（计算节点），worker 分布式并行扫描数据。在有配置缓存的情况下，还将进行如下流程：
- CN worker 访问本地缓存，如命中，则直接返回数据扫描结果，提供给 CN worker上层的计算模块进行计算
- 缓存中未包含所需要的数据，则 CN worker 从 Amazon S3 上读取对应数据，提供给 CN 上层的计算模块进行计算，并将数据异步加载至本地缓存
CN worker 数据加载完成后，执行分布式计算，计算结果汇集到单个 worker 后返回给 FE
FE 接受查询结果，并将结果返回给客户端

性能对比与成本测算

注：存算分离通过存储与计算的解耦，使用价格相对经济的 S3 作为存储，降低了用户的存储成本。性能上通过多层次的数据缓存方式，数据预取等优化手段，保持了与存算一体基本持平的性能表现。

以下是 StarRocks 3.0 基于亚马逊云科技平台的性能基准测试。我们共比较了三个不同方案下 StarRocks 的查询性能：

sr-3.0-native：通过 StarRocks 3.0 查询本地 SSD 存储（EBS GP2 SSD）
sr-3.0-cloud-native：代表存算分离在数据完全命中缓存情况下性能
sr-3.0-cloud-native-no-cache：关闭所有缓存（包括内存 page cache 以及 local disk cache）情况下 StarRocks 3.0 的查询性能

测试环境

节点类型	实例类型	实例个数	vCPU	内存(GiB)	存储类型
FE	m6i.2xlarge	1	8	32	50GB EBS GP2 SSD
CN	r6id.2xlarge	8	8	64	474GB NVMe SSD

软件版本

StarRocks

V 3.0

查询

本博客使用了来自 TPC-DS 基准测试的 99 个 SQL 查询。有关这些查询的更多详细信息，请参阅 StarRocks 社区的 TPC-DS Benchmarking 官方文档。

测试结果

注：Excution time 为全部 99 个 SQL 执行时间的总和，单位为秒。其中每个 SQL 执行四次，去除第一次查询耗时，取后三次执行时长的平均值作为每组 SQL 的执行时间。

图 3. StarRocks 3.0 基于亚马逊云科技平台进行 TPC-DS 基准测试结果

图 4. StarRocks 3.0 基于亚马逊云科技平台 TPC-DS 基准测试-不同 Query 耗时分布图

存算分离版本在缓存完全命中情况下，其总体性与存算一体已基本持（存算分离：428s VS 存算一体：423s）。

即使在完全访问冷数据情况下，也很好地将冷数据查询性能衰退控制在一个合理范围内（668s VS 428s）。

成本核算

客户 A 的网站每天会产生 1TB 的增量日志数据，数据保存周期为 2 年。日常分析主要集中在近 7 天内的日志数据，但偶尔也需要查询超过 7 天的数据。

在存算一体的架构下数据副本为 3，压缩率为 50%。那么存储 700TB 的数据，总计需要 700TB * 3 * 0.5 ≈ 1050TB 的磁盘空间。

实际上 80% 的场景下只分析近 7 天的数据，因此只需对近 7 天的数据进行缓存就可以使 80% 的查询性能和存算一体保持一致。而 cache 所用的存储空间只需要 7TB * 1 * 0.5 ≈ 3.5TB ，这意味着超过 99% 的存储成本都用在了存储低频查询所需的冷数据上。

这种场景下，如果用户使用存算分离的架构使用 S3 存储全部数据 700TB ，cache 缓存使用 EBS gp2 存储 3.5 TB，相比于存算一体 1050TB 数据全部使用 EBS gp2 存储的方式，存储成本可下降 90% 以上。

总结

StarRocks 3.0 通过全新的存算分离模式，借助亚马逊云科技提供的近乎无限的存储空间以及云上计算资源的资源池化能力，实现了计算与存储解耦，计算节点弹性伸缩，可选择的高性能数据缓存等特性。

StarRocks 3.0 存算分离版本具备灵活、高性能、高可靠、低成本等特点。用户可以按照实际需求调度计算资源，避免计算资源过载或闲置。同时，用户数据存储于 Amazon S3 上，而对象存储相比本地磁盘具有容量大、可靠性高、成本低等优点，进一步提升了数据分析平台的性价比。

目前 StarRocks 存算一体的版本已经在 Global AWS Marketplace 上架，支持全球用户的快速部署。存算分离版本的适配开发已经完成，预计于年底前可完成上架。

亚马逊AWS官方博客