阿里云 EMR Serverless StarRocks OLAP 数据分析场景解析

内容导读 ：

主题：EMR StarRocks 线上公开课第 3 期 - EMR Serverless StarRocks OLAP 数据分析场景解析讲师：周康（榆舟），阿里云高级技术专家 &开源大数据 OLAP 引擎团队负责人、StarRocks TSC Member

内容框架：

• StarRocks 背景介绍

• StarRocks OLAP 分析核心特性

• StarRocks 3.X - OLAP 分析新范式

• 阿里云 EMR Serverless StarRocks

直播回放链接：

https://developer.aliyun.com/live/254055

一、StarRocks 背景介绍

1、StarRocks 定位：极速统一的数据分析

在过去十年，用户对 OLAP 实时分析的需求日益增长，为满足需求诞生了 ClickHouse、Druid、Kylin、Presto/Trino、Impala、Kudu 等多种数据分析产品。随着产品增加，带来的困扰也很明显，应该选择什么产品？不同场景选择不同的产品，导致运维成本提高。在这个背景下，StarRocks 应运而生，其目标是实现通过一个产品满足用户所有数据分析需求，从而降低用户的选择成本和维护成本。

2、StarRocks 应用场景

StarRocks 能满足以下数据分析场景：首先，根据过去服务阿里云上数百企业客户的经验，StarRocks 目前能应用于 OLAP 及绝大部分的分析场景，包括面向用户的报表分析，面向经营的报表、用户画像、数据建仓、订单分析以及自助的 ad-hoc 分析。

3、StarRocks 社区快速迭代

在服务这些客户的过程中，社区通过用户场景的打磨，在过去几年迅速发展。从 1.x 版本支持向量化引擎、CBO 的核心能力，到 3.x 版本开始真正实现存量分离、支持更大规模的分析场景。1.x 和 2.x 都是在湖仓一体的架构上去演进和迭代的。

二、StarRocks OLAP 分析核心特性

1、OLAP 分析场景面临的挑战

首先是为满足通用 OLAP 分析场景的需求会面临的挑战。对于一些面向用户或经营报表分析方向的业务场景，大部分场景存在性能不足的问题；对于实时场景，很多产品存在数据新鲜度低的问题；对于面向业务的场景，并发能力又会成为瓶颈；最后不能灵活建模的问题也经常困扰大家。接下来是 StarRocks 的解决办法。

2、性能：全面向量化

在 3.x 版本以前，StarRocks 做了一些关键工作。在性能方面，StarRocks 实现全面向量化能力。通过向量化能力，相较于传统的火山模型，能够实现按列存储和计算、减少了虚函数的调用、对 CPU 缓存更加友好、还能更好地利用 SIMD 指令。基于向量化能力，常用的 Filter、AGG 以及 join 的算子的性能都有数倍的提升。

3、性能：全新 CBO

向量化能力能提升单机计算引擎的性能，为提升多表关联查询的能力，StarRocks 实现了全新 CBO 优化器。在 StarRocks 中，一个 SQL 语句进入系统，会先后经过 Parser、Analyzer、Transformer、Rewriter 以及 Optimizer 阶段。其中 Transformer、Rewriter 阶段可以实现一系列固定的优化规则，如常量折叠等。到 Optimizer 阶段，可选择的执行计划很多，比如有十个，而在此阶段就是基于成本，以 Memo 为中心的思路，高效选择、推导出新的规划。同时在查询规划的集合里选择出相对最优的执行计划，从而能最大化地降低执行阶段的网络和 CPU 等开销。

4、性能：现代物化视图

在实际支持业务发展过程中，发现通过向量化和 CBO 的能力，大部分用户查询都有明显提升，但对部分场景直接裸查原始数据，可能还是存在性能无法满足预期的情况。所以 StarRocks 内部也实现了物化视图的能力。物化视图能通过自动构建、自动刷新以及自动改写的能力，让用户在不修改业务 SQL 语句的前提下，实现透明加速。

5、实时：存储引擎

向量化、CBO、物化视图这几个关键特性的落地，能够极大解决 OLAP 分析性能不足的问题。不过，仅优化查询引擎的性能还是不够，实际用户还存在对于数据时效性的需求，比如金融、保险类业务。在阿里云上，StarRocks 也有很多类似业务的客户，他们对于数据时效性要求非常高。

可通过以下方式满足这类需求：通常来说，为满足实时更新的需求或方案，Merge-on-read 方案特点是写入性能较高，但查询时，如果有大量的历史数据，就会影响查询效率。Copy-on-write 方案特点是写入吞吐低，查询性能相对 Merge-on-read 会好一点。而 Delta store 的方案类似于 kudu，其索引维护的成本会比较高。StarRocks 未选择前三种方案，而是选择了一套基于 Delete+insert 方案来实现实时更新的存储引擎。这套方案和常见的 SQLserver 以及阿里云自研的 hologras 都有类似的思想。通过 Delete-and-insert 方案，引入 primary index,和 delete BitMap, 能够非常好的实现高效读写的实时更新引擎。

6、高并发：Pipeline 引擎

在实际客户场景中，还有部分场景对并发查询和并发场景的性能有要求。

为此 StarRocks 实现了一套用户态调度的 pipeline 执行引擎。如下面两张图的对比。左边是非 pipeline 模式下的查询执行的实际数据流情况。在非 pipeline 模式下 Fragment 下发到执行节点后会独占整个 CPU， 如果有 IO 阀门或其他阻塞操作，会导致 CPU 没法高效地给其他查询使用。而右边 pipeline 引擎的设计，核心思想是通过解耦，IO 调度和计算调度，同时把 Fragment 力度拆分更细，是用 pipeline 以及 pipeline driver 做拆分。这样能最大化提升 CPU 的利用率。

7、灵活：分布式 Join

最后一个关键特性是分布式 Join。过去，一些高性能引擎不支持灵活 Join，给业务方造成很大的使用困扰。前面讲遇到的四大痛点里也提到：业务方对灵活分析的需求是非常旺盛的。

StarRocks 通过内置的分布式 Join，能够在前面提到的向量化、CBO 等优化技术上提供高效灵活的分析体验。

三、StarRocks 3.X - OLAP 分析新范式

前面讲的是 StarRocks 在 1.x 到 2.x 版本为实现 OLAP 分析的技术统一所做的关键工作。通过这些特性，StarRocks 在 2.x 版本在性能方面已经满足了很多用户的业务需求，解决了很多痛点。相信大家在实际使用或了解社区发展的过程中，也能感受到 StarRocks 在蓬勃发展。在阿里云的客户实践来看，2.x 版本以前还有两个需求没法很好的满足。

1、存算分离架构升级

第一是成本，在存算一体架构下，大部分的部署需求都是需要本地的 SSD 磁盘，或是阿里云的 ESSD 盘, 当数据规模增长到几百 T，那存储成本就会占比较高。第二，EMR 在做数据湖生态，发现很多用户，在湖仓一体的 OLAP 场景下达到高性能计算引擎带来的收益后，希望 StarRocks 高性能分析的能力能够应用到数据湖数据的分析上。

针对这两类需求，在 StarRocks3.x 之后，推出了存算分离的架构和高效的湖仓分析方案。存算分离架构相对于存算一体架构最大的变化可看下图，是存储引擎部分。

存算一体在 BE 侧可以看到角色的变化，名字由 BE 变成了 CN，这变化是存算一体的数据都是按分区存储在 BE 的本地磁盘或云盘上。而演进到存算分离架构之后，所有原始数据都会在 OSS 或是文件系统 HDFS 上有一部分数据。CN 主要负责计算层，这样，它有一些弹性能力。这有一个较大的问题，以前查询是访问本地的 SSD,性能能够得到保证，数据在 OSS 上后查询性能能否保证。在存算分离架构下，最核心的是在 CN 节点可以增加一些磁盘作热数据的缓存，这也能实现热数据的查询，性能不会有明显降低。目前看，存算分离架构是适合有一些冷热特性的业务场景。

2、存算分离收益

对存算分离架构的收益也做了一些总结，整体上可以分为几块。

第一，最大的收益是成本，在存算一体架构下，为保证数据的可靠性，必须是三副本的数据。存算分离后，只需对象的一副本，或再加一些热数据缓存，存储的数据量以及存储介质本身的成本都有明显降低。同时，因为存储已放到 OSS，可把计算资源缩容，从而达到计算层面成本的明显降低。

第二，数据的可靠性。StarRocks 在存算一体情况下，可能因为部分原因导致副本丢失或源数据损坏，数据就需要重新导入。有了存算分离架构后，数据能够落到 OSS 上，OSS 本身的可用性非常高，所以数据的可靠性也会明显提升。

第三，比较大的收益是资源隔离问题。在 2.5 版本及以前，很多客户反馈集群大的查询会影响其他业务的导入或查询。从 2.3 开始，整个社区都一起推 resource group 的解决方案，到 2.4、2.5 才默认开启。实际上 resource group 能解决的隔离层面问题相对来说有限。像 IO、CPU 等都是一些软隔离机制，无法完全避免业务间的相互影响。所以在存算分离上推的方案是 Multi-Warehouse，通过多 warehouse 能够实现数据共享，计算负载如说导入、AD-hoc 的报表类查询通过不同的 Warehouse,实现物理隔离。同时， workload 内部可以根据需求进行扩展。在和社区共同打磨存算分离架构的情况下，目前达到了热数据、查询的性能能够和存算一体持平。在冷查方面也做了很多的 IO 相关的优化。本质上在对象存储上做存算分离，核心目标是怎么利用对象存储的带宽优势，降低查询延时。对象存储相对于本地 SSD 不那么好的点就是延时会高，但吞吐方面好很多。所以我们也做了很多 feature，包括 IO 合并、并行化等。相对于最早一年以前的版本，有非常明显的冷差性能的提升。

3、极速统一的湖仓分析

在过去两年我们看到一个趋势，即用户对 StarRocks 的查询性能越来越认可。进而很多用户希望把查询加速应用到海量的数据湖的数据分析上。为满足这个需求，StarRocks 实现了统一 Catalog 机制。在 2.3、2.4 开始，我们和社区共创已经做了很多湖分析相关的工作。最早是基于外表，如果有几百张表需在 hive 表/数据库里，需要创建的维护成本较高，所以推出了 catalog 机制。但真正推数据湖分析场景会基于 3.x， 3.x 版本后在 DLA 这块的 block cache 能力以及 native Parquet Reader、ORC Reader 的优化。外表物化视图、catalog 机制等在 3.x 版本都有很大提升。对于用户数据湖需求，我们建议并引导他使用 3.x 版本。StarRocks 内置 catalog 机制，内表有 internal catalog 实现，外表可以有这种 JDBC、paimon，创建好 catalog 后，可以直接对外表分析，甚至可做内外表联合的查询分析。

4、Trino 兼容，无缝替换

在数据湖分析引擎领域，目前流行的引擎是 Trino，StarRocks 为能更好的实现湖仓分析的统一，内置 Trino 语法，用户能非常方便的实现业务迁移。

5、极致的湖仓分析性能

迁移到 StarRocks 带来最大的收益是查询性能明显的提升。如果裸查 OSS，StarRocks 相对于 Trino 有三倍的提升。在 3.1、3.2 版本以后，在 block cache 也达到了生产可用的状态。如果查询数据能够命中缓存，缓存里数据整体查询效率相对于直接裸查 OSS 有几倍的提升。如果性能依旧无法完全满足需求，还可通过建物化视图把湖上的数据自动同步为一个内表数据。这样还能用到很多类似 StarRocks 本身的 colocate 以及更完备的统计信息等能力。使整体有着数倍的提升。

四、阿里云 EMRServerlessStarRocks

前面整体上介绍 StarRocks 最早在支持这个产品时遇到的一些 OLAP 分析痛点，为解决这些痛点，从存算一体做了哪些关键的特性，主要包括 CBO、向量化、物化视图等。随着服务客户越来越多，存算分离、数据湖分析、平替 Trino，核心逻辑是基于 StarRocks 本身引擎的能力非常强大，用户也希望它能解决更多的问题，也存在一些痛点。所以从最早支持向量化、CBO 到实时存储引擎 PK 表，演变到存算分离架构。StarRocks 内核在支撑过去几年客户的整体需求做的一些关键演进。在阿里云 EMRServerlessStarRocks，简单介绍后续的产品方向。

过去已在产品 Serverless 形态上面做了很多优化，以及企业级的特性。未来，还会继续在下面三种形态上做更多的工作。首先是存算一体，这部分比较重点的有两个方向，一是性能优化，在实际客户场景下，也遇到一些并发性能的问题，还有提升空间，部分查询 Join、runtime filter 都有一些潜在的优化空间，这是我们持续优化的工作方向。对于存量的用户来说，在存算一体形态下，能方便的享受到这些优化。在 Serverless 形态下升级版本比较方便。第二，有很多客户反馈，对于 StarRocks 之间基于 flink 的数据同步、数据备份恢复能力有更方便、更企业级的解决方案，所以重点做 Change Data Feed。第二个形态是存算分离，我们会持续在 IO 优化上投入。基于对象存储做存算分离，应利用对象存储的带宽能力。业界也有非常明显的趋势是大家对于在对象存储上做数据库或 OLAP 引擎等，会共同探索怎么在对象存储上做更多工作实现 IO 性能，相对于本地存储影响降到最低。第二重点做企业级的 Warehouse，用户希望有一套集群负载之间有隔离。第三部分就是弹性，也会实现企业级的能力。在存算分离情况下，数据成本降低，整个计算成本通过弹性能力降低，在低峰期或说在固定的时间段不预留过多计算资源。第三，数据湖分析，重点是 StarRocks 结合 Paimon 方案实现实时湖仓分析解决方案，不管是在内部还是社区，越来越多的用户使用。数据湖分析希望能平替 Trino，用户通过 StarRocks 引擎就能满足其业务需求，避免引入更多技术栈，增加太多的维护成本和学习成本。

产品导航

• EMR Serverless StarRocks 版官网：https://www.aliyun.com/product/bigdata/starrocks
  

• 产品控制台：https://emr-next.console.aliyun.com/
  

• 产品文档：https://help.aliyun.com/zh/emr/emr-serverless-starrocks/
  

EMR Serverless StarRocks 钉钉交流群（群号：24010016636）