阿里云 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）