降本60% ，阿里云 EMR StarRocks 全新发布存算分离版本

简介：

阿里云 EMR Serverless StarRocks 现已推出全新存算分离版本，该版本不仅基于开源 StarRocks 进行了全面优化，实现了存储与计算解耦架构，还在性能、弹性伸缩以及多计算组隔离能力方面取得了显著进展。通过实现存储与计算资源的解耦，降低整体存储成本和计算成本达60%以上，同时保持了与传统存算一体架构相媲美的内表处理速度。此外，该版本支持高度灵活的弹性伸缩机制，能够根据实际业务需求动态调整资源，确保高效利用的同时降低了运营成本。更重要的是，借助多计算组功能，用户可以在同一实例内部署配置多个独立的计算资源组，从而更好地满足不同工作负载的需求，并保证了各组间工作的互不影响，进一步提升了系统的灵活性和安全性。

一、EMR Serverless StarRocks 发展介绍

StarRocks 在阿里云 EMR 的发展路径如下图所示，它是典型的一个大数据的架构图，存储层一般用 HDFS 或者是 S3 协议的 OSS。处理层一般分为批处理和流处理，批处理一般来说事实标准是Spark，流处理的事实标准一般来说是 Flink，然后到分析层，实际上现在处于一种百家争鸣的状态。

在 StarRocks 出来之前，一般来说我们大家常见的左侧这几款 OLAP 引擎，包括 CK、Druid、Presto、Impala、Kudu 等等。但是在2021年9月份 StarRocks 开源之后，我们可以看到业界的一个趋势，整个 OLAP 引擎都在朝着极速和统一的方向去发展。

对于阿里云 EMR 来说，在对 OLAP 的支持上，最开始我们先是在半托管里推出数据分析集群类型，我们当时引入了 Clickhouse 等半托管 OLAP 引擎。随后，我们发现 StarRocks 在整个 OLAP 的架构里边处于非常领先的地位，所以在2021年9月份 StarRocks 开源之后，EMR 开始把团队的人员重度投入了 StarRocks 社区，也推出了半托管的 StarRocks 形态。

但是随着支持的深入，我们发现一个问题，StarRocks 社区发展地太快了，在升级包括一些监控，告警以及一些比较深入的特性，半托管是没法提供的。所以在去年六月份阿里云 EMR 正式发布了 StarRocks 全托管的产品，属于存算一体的版本。随着 StarRocks 3.X 的成熟，我们在内部打磨了将近半年的时间，推出了 EMR StarRocks 存算分离版本，并开始正式的商业化，这也是我们今天最重点的一部分。

二、EMR Serverless StarRocks 1.0-存算一体版

从去年6月份商业化开始，EMR Serverless StarRocks 1.0存算一体版本已经累积了大概有500家的生产客户，覆盖了20多个行业。从我们接触的大部分客户来看，里面的 OLAP 需求大部分是相似的，但是又有一些不同。但是从 StarRocks 的角度上来看，它已经基本上覆盖了整个 OLAP 的所有场景。包括一些高频点查，传统的 OLAP 分析，大宽表分析，多表 Join 分析，实时数仓等等。

EMR Serverless StarRocks 存算一体架构设计

在 EMR Serverless StarRocks 1.0 存算一体的架构设计上，最底层的是存储层，存储层一般来说我们提供 ESSD 机型，也提供这种本地的 SSD 机型。这里边 OSS 主要是数据的导入导出，还有一个备份的作用。计算资源层我们采用了比较经典的 K8S 加上 ECS 架构。K8S 能够保证云操作系统的升级，rolling update，一些配置管理是非常的成熟的。ECS 保证了客户的稳定性，每个客户都是独享的一份资源。

再上面是管控平台层。管控平台层包括一些实例的管理、监控与告警。我们还着力做了元仓的这套架构。元仓这套架构其实对用户的帮助是非常的大的，我们通过搜索集群的运行日志，运行的 metrics 去对整个集群做一些关联的分析，包括集群的诊断分析，慢查询分析等等。后面我们也会给大家逐个讲解这里面的核心能力。

核心能力-健康诊断

第一个核心的功能是健康诊断。客户一直会问我们一些问题，比如我们作业没有变化，但是为什么集群负载变重了？比如说我上线了一个 SQL，这个 SQL 有可能是一个大 query，是不是这个 SQL 把整个的集群的负载给拉高了？在开源里边是没有一个有效的方法来回答这些问题的。

EMR StarRocks 从两个方面解决这些问题，离线分析上，我们提供T+1的离线报告，为大家呈现出昨天的 SQL 是一个什么样的大盘。比如说慢 SQL 是多少，然后 SQL 的 top query 是什么？昨天的导入发生了一些什么情况，有没有一些热库热表等等，把这些信息都透传给大家。

另外我们也推出了实时分析的能力，用户可以圈选一段时间，分析这段时间里边对应的 compaction 任务、后台任务、导入任务、查询任务，做一个大的一个排序，然后就知道这段时间集群里面发生了什么。这个技术有依赖于刚才提到的元仓的技术。

核心能力-SQL 调优

第二个核心的功能是 SQL 调优的功能。我们将整个的 SQL 都全面地记录下来，也去做一些可视化的 profile，然后根据历史的一些经验去给一些诊断的建议。比如右边的一个比较复杂的 SQL，是一个客户刚刚上线的一个 SQL，他可以通过图形化的界面非常清楚地看到 SQL 运行的概览，看到这个 SQL 是不是符合自己的预期，每一个算子是不是能够正常的运行。比如说红色可以优化的部分，收集 Profile 的时间耗时过大，我们就会给用户一些优化建议，去排查下有可能存在的问题。

第三个核心的功能是物化视图。物化视图是社区一个非常重点的方向，也是社区比较推荐的一种方案。物化视图底层对应的是 ETL 的作业，上层对应的是 CBO 的改写，能够进行一些透明加速。但是如果大家有实践经验的话会发现物化视图在写的好和写的不好的时候，对整个资源的耗费，整个查询的有效性，加速性是有非常大的不同的。所以在物化视图上，我们提出了三步走。

第一是物化视图的全链路可观测，我们先把物化视图监控起来，然后把一些核心的指标透传给用户，用户根据这些指标来看看我这个集群这个物化视图到底是不是符合预期的。

第二是低效物化视图的检测，比如说物化视图做出来了，但是物化视图没有被访问。那我们认为这个物化视图做的是一个比较低效的物化视图。

第三是物化视图的智能推荐，这个也是内部在做的一个新的一个尝试，我们会根据客户的 SQL 运行历史进行物化视图的推荐。比如说用户有三张表，这三张表做一个 join，然后这三张表的join是被更多的 SQL 语句来查询。那么我们推荐是不是可以把这个 SQL 做一个宽表物化视图，然后去进行加速。

核心能力-物化视图

EMR StarRocks 存算一体1.0经过我们一年多的落地，积累了一些经验，但是我们也看到了存算一体有一些非常难以解决的问题。

第一，现在数据湖是一种业界的标准，Lakehouse 也成为了一种既定事实，无论在北美市场还是在中国市场，但是在存算一体架构上，对于湖的访问实际上是一个不太优雅的过程。

第二，一些工作流和负载之间互相的影响。比如一个高频检查，要求的 SLA 是非常高的。比如说物化视图的 ETL 作业，它对整个集群的资源使用量是非常的大的。我们缺乏一个手段去把他们有效地分开完成复杂的隔离。

第三，没法做冷热数据分层。存算一体能够用 SSD 来存储所有数据，但是对于一些比较大的数据量，存储的数据成本是比较高的。现在客户如果有冷热分层的需求，一般是先把热的数据都导到 StarRocks 里，再不断通过 Spark 作业，或者一些其他的导出手段，把冷数据放到 OSS 里边。这个方案整体看起来也不是一个非常优雅的过程。

第四，主要是弹性和 Serverless。因为在存算一体里边，计算跟存储是绑定的。我们如果有弹性的资源，整个底下的 tablet 数据副本是需要迁移的，这个迁移过程实际上是一个再平衡的过程，整体上对于集群还是有一些影响的。

存算一体架构的挑战

三、阿里云 EMR Serverless StarRocks 2.0-存算分离版

基于以上考虑，我们也在从存算一体1.0的架构演化为存算分离2.0的架构。StarRocks 官方社区比较推荐的是这样一套 Lakehouse 架构。上半部分把 StarRocks 看作一个仓，也是我们在存算一体里面使用的方案，比如用 Flink CDC 直接把 Mysql 数据同步到StarRocks来做查询。下半部分指的是已经有了 EMR，或者有了湖格式的数据，希望用 OneCopy 的形式，省去导数据的步骤，直接用 StarRocks 查这个数据，也就是 StarRocks 对应的湖查询。

右半部分实际上是对于湖查询的加速过程，DWD 层到 ADS 层可以用刚才说过的内表物化视图，做到透明加速。而 ODS 层到 DWD 层用的是外表物化视图，本质上是通过 ETL 把外表数据加工到内表的一个过程。

这个组合场景实际上在存算一体里面完成是存在一些问题的，例如：不能够有效的划分和规划缓存磁盘进行数据湖数据的加速，以及无法有效隔离外表和内表查询等等。

所以当我们再回头去看这套 LakeHouse 解决方案时，我们认为存算分离架构才是湖仓分析场景比较终极的方案。通过内部半年的测试，我们也正式发布了商业化的 EMR Serverless StarRocks 存算分离版本。

EMR Serverless StarRocks 存算分离架构设计

EMR Serverless StarRocks 2.0的存算分离架构，先看一下下边的 StarRocks 存算分离集群。这个需要 highlight 几个点。

第一个从存算分离的角度上来看，已经没有 BE 的这个概念了，只有 CN 的概念。CN 的概念展开来说就是一个 Compute Node，顾名思义就是一个计算节点，没有存储数据的功能。

第二个计算和存储一旦分离开，直接体现出两个比较核心的特性，就是隔离性和弹性。因为隔离性在存算一体里面是没法做的，因为数据就在那儿了，没法物理上按照节点组去切开。弹性刚才也说了，一旦有弹性发生，存算一体里面有对应 tablet 数据变化，这个弹性是比较重的。

第三个就是成本问题。存算一体里边，提供 SLA 必须要用三副本，三副本的核心逻辑是可靠性和可用性。可用性就是说一台机器如果宕机了，其实这个查询是不受影响的，因为还有两副本可以去提供服务。可靠性就是说一旦机器里边某一台机器的磁盘遭受损坏，可以通过另外两份副本去进行正常的导入，也可以通过那两份副本去把数据恢复，所以说存算一体里面必须要用到三副本。但是在存算分离的架构中，推荐大家用的是单副本的缓存，再加上一副本 OSS。因为从可靠性来看，我们直接放到 OSS，它提供的多个9的可靠性是完全够用的。可用性的话一旦一台机器宕机了，我们可以从 OSS 里面拉数据，不会导致整个可用性中断。

上面是 Control Plane 层，元仓分析刚才已经讲过了。比如包括健康报表，实时分析，SQL 诊断等等，接下来我们重点来讲解下 StarOS。

核心能力-StarOS

StarOS 的 OS 其实就是操作系统的意思，里边核心对应的是两部分。第一部分对应的是调度，第二部分对应的是缓存。

我们去设想一下，假如说在存算分离里面，一台机器去宕机了，或者要做弹性，对应的调度是不一样的。一台机器宕机了之后，为了不影响可用性，会立马进行重试，因为 tablet 和存储是没有一个物理上的绑定关系，是一个逻辑上的绑定，一旦一个 tablet 本来是在 CN1 上，这个 CN1 宕机了，系统会把这个 tablet 调度到 CN2 上用 CN2 来算，整个调度就是由 StarOS 来完成的。

弹性的调度也会分为感知调度和热点调度，主要是一些场景的优化。比如说客户从10个节点弹到20个节点，一部分用户是希望把整个集群的资源都全部用上，还有一部分客户希望可以慢慢用，而不是一下子全用上，因为前10个节点已经有缓存了，客户不希望把20个节点全部用上，而导致缓存的迅速失效，希望业务是一个平滑的切换，。所以说 StarOS 会给客户一些配置，根据不同的业务状况，调不同的参数。

缓存管理就是一系列缓存的观测、管理、预热等。举例来说：比如一张分区表表，里边有一些冷的 partition，一些热的 partition。希望只查七天的数据，那我们就可以把七天的 partition load 到缓存里边。我们会 T+1 对 SQL 进行一个缓存命中率的判断。这样能够让大家看到缓存磁盘中到底是不是有效的缓存，昨天做的缓存的 load 预热操作是不是一个有效的操作。

核心能力- Multi-Warehouse（多计算组）

Multi-Warehouse 就是一种硬隔离的方式。在存算一体版本里用的是软隔离的方式，软隔离其实就是一个资源组的概念，是针对资源消耗来 accounting 记账的原理。一个 query 跑了多少的 CPU，多少的 IO，一旦达到了这个限制，就会 kill 掉，不再继续跑，达到隔离的作用。但是这个社区推了很长时间，客户在实际落地的工程中反馈不是很容易配置。另外软隔离用起来，坑还是比较多的，尤其在 IO 的方向上，很难起到一个非常好的隔离效果。所以说彻底解决该问题，是要在存算分离中，提供的是 Multi-Warehouse 这种硬隔离。我们这张片子里面看到的不同的2个资源组，一系列节点形成一个资源组。有一些 ETL 的作业在 warehouse1，有一些查询的作业在 warehouse 2。

Multi-Warehouse 使用的是同一份数据，但是一般是要搭配多种业务策略来使用。比如客户从 Presto、Impala、CK 直接全部都切到 StarRocks。在存算分离里，我们可以把 Presto 作为一个 warehouse，把 CK 作为一个 warehouse，把 Impala 作为一个 warehouse，3个 warehouse 面对的场景是不同的，配置和缓存的策略，弹性的策略也都是不一样的。比如说 Impala，希望的是一种半缓存的状态，因为时效性并不是那么高，配置一定的缓存盘就够了。比如说 CK 要求的是一个全缓存，切换到 StarRocks 全缓存的话，其实跟存算一体的性能是没有差距的。比如说 Presto 慢点是符合预期的，也不需要特别的缓存，为了节省成本，连缓存盘都不设置了。所以说在这个方案里边我们可以做3个 warehouse，设置不同的弹性，设置不同的缓存，去完成整个迁移的工作。

Multi-Warehouse 还有一些客户需求是多部门可以分开的记账。因为原来混用到一个集群里面，很多的情况下记账是一个不清晰的状态，用多计算组可以很好的解决这个问题。

核心能力-弹性伸缩

下面讲一下弹性。弹性其实是存算分离架构带来的最自然的一个结果，因为去掉了存储和计算的绑定关系，弹性起来是一个非常轻量的过程，配置的步骤也比较灵活。我们可以在一个 warehouse 里边做一个基于时间的一个弹性。比如说客户从8点到14点，原来他的固有资源是500CU，在这6个小时里边再弹性出来1000CU，变成1500C，还会给客户的一个事后的成本分析，弹性的1000CU资源有没有被很好的利用到，如果利用不好，明天可能是不是弹700CU资源就够了。如果利用率特别高，明天是不是还得再去多弹性一些资源，整体是一个非常灵活的、可追溯的过程。所以说从轻量的弹性、到资源使用量分析，到后续我们要推出的账单分析，实际上是对客户非常有帮助的。

核心能力- 内表优化

下面讲一下针对存算分离架构的性能优化，首先是针对 StarRocks 内表做的一些优化。从2022年上线半托管 StarRocks 以来，我们一直在做 StarRocks 内核的优化，包括一些核心算子方面。我们在 TPCH-10TB 标准测试集上也有打榜。这个打榜结果可能会在今年年底去进行公布，现在还在审核阶段。无论从性价比上还是从性能上，对比现在榜单的第一名都有非常大的提升。

存算分离中比较重要的是查询 OSS 冷存的性能，这部分我们对比开源社区也是有非常多的提升。首先客户已经看不到 OSS 了，不需要自己去指定 bucket。这里有几个好处，比如说客户不再用关心这个 bucket 的监控，包括延时、带宽、调用 QPS 等等。同时我们在 OSS 里边也做了很多的优化。包括一些基于 OSS 特性的优化，文件的合并，异步化，文件最佳大小适配，自适应算法等等。通过一些自适应的算法，我们会在不同的 workload 里去选取最选取比较好的优化手段。

最后说的是索引的优化，实际上自建 StarRocks 存算分离，门槛是特别的高的。包括一些我们看到的实际案例，例如 IO 交互非常多，但是数据量其实非常少，可能就只有几个 GB，但是为什么会这么慢呢？很多情况下是在做索引的获取，大家也容易忽略此过程。我们对这些 profile 的分析中看到，索引的优化对整个的 OSS 冷存阶段的性能优化，是一个至关重要的一部分。

在我们客户实际应用 EMR StarRocks 存算分离版本，对比原先的开源自建，收益也是非常的大的，平均性能可以提升40%，稳定性提升300%。查询的稳定性是指今天跑的冷查可能是3秒钟，但是明天可能会跑到20秒钟，这是一个实际发生过的案例。但是如果要是迁到 EMR StarRocks 存算分离版本上，针对 P99 的查询进行统计，均值和方差都是非常小的。

核心能力- 湖表优化

讲完内表的优化，接下来再看一下 EMR StarRocks 存算分离版本针对湖表的优化，Lakehouse 以及湖表是业界比较热门的话题，包括阿里云推出的 OpenLake，都在讲湖的故事。无论传统的数据湖三剑客，还是阿里云推的 Paimon，EMR StarRocks 都做了非常多针对湖表的优化，细节还是非常多的。

最大的点就是元数据的获取优化，大家如果使用过 StarRocks 去查 Paimon 或者 Iceberg，比较大的直观感受就是有的时候是查不动的。虽然说查出来的数据可能只有几条，或者说很小的数据量，但是为什么会查不动呢？大家可以去看一下 profile，耗时很有可能会花在元数据解析中。比如一张表特别大的情况下，如果元数据没有做一个非常好的治理，我们获取元数据的效率是非常低下的。实际上，无论是拉取 manifests 还是去解析这个 avro 形式的这个 manifest 都会有一个非常大的 overhead。很多情况下会导致 CBO 优化器已经超时了。

冷查优化其实跟刚才内表的冷查优化其实差不太多，然后 Paimon 是我们比较主推的湖格式，EMR StarRocks 在里面优化也是做的非常多的。除此之外，我们也会在这个湖表的物化视图里面做了很多的优化。

提到湖表，大家最常见的一个问题就是对比 Trino 怎么样，我们的结论是比 Trino 快，但是为什么会比 Trino 快？总结起来是三大核心，向量化计算，新一代 CBO 规划器，还有一个就是语言上的优势，用C++引擎去对比 Java 的引擎，优势还是比较大的。第二个问题就是说是不是可以非常方便地从 Trino 切到 StarRocks？这个答案也是肯定的，StarRocks 对 Trino 的语法兼容达到97%，业界也有相当多的迁移案例，大家可以自行查阅下。

业界还有一个常见的问题就是选择内表还是选择湖表。这个和 Snowflake 以及 Databricks 的整个的故事是相似的。Snowflake 是以仓为主体，然后加大 Iceberg 和湖的投入，这个可以类比 StarRocks 的内表的方式，还是以数仓为基础向数据湖演进的过程。然后 Databricks 从第一天就开始就做整个湖链路，无论是 DeltaLake 还是 Iceberg，还是从湖上去建仓的过程，数据规模相对也比较大。这个得看下企业的业务或者基础设施到了哪一阶段，会有不同的选择，这张图上我也总结了我自己的一些看法给到大家参考。

四、总结

阿里云 EMR Serverless StarRocks 2.0 存算分离版本是基于开源 StarRocks 进行了性能、弹性、隔离、管控、调优、成本等全方面的优化，目前已经正式发布。针对一些存算分离的新用户，我们也推出了开箱即用的案例，方便大家针对 TPC 标准测试集，各类湖表格式测试等等，欢迎大家开通体验。

如果对刚才介绍的阿里云 EMR StarRocks 感兴趣的话，可以登录的官网，提供免费试用以及一些测试资源包供企业和个人开通体验，使用中有什么问题也可以加群和我们交流。