一、StarRocks 背景介绍

1、StarRocks 定位

StarRocks 的定位两个比较关键的点，即 极速和统一：

“极速”是指其可以做到极致的性能，大大提升 OLAP 场景下查询的效率。从StarRocks 1.0版本开始打造的目标就是极致的速度，利用 CBO 及向量化的基础技术能力打造了一整套的极速底层计算框架。
“统一”起始于StarRocks 2.0，它包含两方面的内容：

首先，从业务场景来说，它融合了 OLAP 侧所有计算引擎所能覆盖的核心场景，如 OLAP 多维分析、实时分析、高并发查询、Ad-hoc 查询。从场景上来说，它使用一套技术栈架构统一 OLAP 层实现“统一”，工作运维人员只需重点维护一套架构即可，这样可以节省运维成本。
其次，StarRocks 极力推动的“统一”愿景，涵盖了对 OLAP 功能的深度融合与对数据湖生态的广泛适配。在当前数据湖盛行的趋势下，特别是如 EMR 这类数据湖系列产品，StarRocks 展现了其独特价值。它不仅顺应了数据湖开放、灵活的特点，还通过其高性能引擎，直接赋能于湖上数据的即时分析与高效查询，无需数据迁移或额外加工，极大简化了数据分析流程。更进一步来说，StarRocks 为数据分析提供了更加高效的利器，最初大家更多会使用 Impala 或 Trino、Druid、Kylin 等手段进行数据湖或数据仓库的加速分析，如今这些功能都可以在 StarRocks 上实现。StarRocks 主要的收益来自于其性能。与 Trino 相比，其性能约有3~5倍的提升。这也体现了 StarRocks 的定位，即极速。

在 StarRocks 3.x 后，其存储层可以使用 HDFS 存储或 OSS 等对象存储，也可以在批处理或流处理之后再写入 StarRocks 做上层的数据加速分析。

2、StarRocks 社区快速迭代

StarRocks 社区非常活跃，阿里云与 StarRocks 的紧密合作也已持续近三年。阿里云有很多在 StarRocks 社区活跃的人员，包括很多类似于 TSC 角色的人员也持续在社区做大量的贡献。

StarRocks 1.0版本实现了极速的特性，实现了对传统 OLAP 的高性能查询；StarRocks 2.0开始更多地兼容各类场景和生态，如数据湖分析场景；并开始大力融合更多的格式，如 json、Map/struct 等格式。此外，在融合更多场景之后出现了资源隔离 resource group 软隔离的能力，以初步解决多场景的资源隔离问题。

在2023年，StarRocks 正式发布了3.x版本，该版本实现了核心的存算分离架构，这一技术进步为 StarRocks 的应用场景扩展奠定了坚实基础。通过这一优化，StarRocks 得以在保持高性能的同时，灵活适应更多样化的工作负载，如数据预处理场景、数据湖分析、数据仓库建模，湖仓建模等场景，也就是 StarRocks 湖仓新范式的概念。StarRocks 3.x 版本所倡导的“湖仓融合”模式，是一种面向现代数据管理需求的策略升级。它在不牺牲性能的前提下，实现了存储与计算资源的解耦与灵活配置，为用户提供了既具备数据湖的灵活性，又兼具数据仓库分析效能的综合解决方案，是数据分析架构演进中的一个重要里程碑。

3、StarRocks 应用场景

StarRocks 广泛适用于六大类场景：第一，日常工作中的报表分析，服务于客户、运营团队、管理层等多角色，尤其擅长满足高实时性报表分析需求。第二，支持数据的实时写入与查询，适用于大屏展示及动态监控系统。第三，构建用户画像，助力精准营销，通过标签筛选细分市场，深化渠道分析。第四，订单分析、销售预测、订单追踪等实时写、实时查的业务场景，或是销售相关的业务场景，以及常见的 Ad-hoc 查询、自助报表平台，比如结合 StarRocks 的极致性能使用阿里云的 Quick BI 或 DataV 制作报表。第五，建立指标管理平台也可以通过 StarRocks 做底层的数据加速查询。第六，StarRocks 3.x后发展出了数据仓库等 ETL 场景。如垂直业务，若业务量较大，则某个小的垂直业务会使用 StarRocks 做数据仓库，这种新业务的突出特点就是其业务变化较为频繁，需要 StarRocks 极速的响应，同时也有效避免了传统数仓建立完整的标准分层的过程，可以快速进行数据的加工和处理，响应业务的实时变化。此外，从业务场景看，还有数据湖上的分析。严格来说，以上提到的六类场景中除数据仓库之外，都与数据湖分析相关。以往可能会使用 Trino 进行分析，在 StarRocks 3.x后，就可以使用 StarRocks 进行数据湖的查询和分析，整体性能提升有3-5倍。

二、StarRocks3.x特性介绍

1、存算分离

（1）架构升级

在早期的2.x及1.x版本架构（见上图左侧）中，系统由前端节点（FE）和后端节点（BE）组成。BE 节点承担双重职责：一方面执行数据计算任务，另一方面管理本地数据存储，确保数据高可用性通过维持每份数据的三个副本。自StarRocks 3.0起，架构显著升级，实现 BE 节点的功能拆分。数据存储层被外置到 OSS 或 HDFS 等系统上，阿里云用户倾向于选择效益高、存储成本低廉的 OSS 服务。这一调整使计算节点（CN）专注于数据处理任务，转变为无状态设计，增强了系统的灵活性与可扩展性，并能有效利用缓存数据加速查询响应，这对于 StarRocks 擅长的高实时性 OLAP 场景尤为重要，确保了 cache 数据的必要性和高效利用。同时，FE 节点保持与前代版本的兼容性。后续内容将进一步探讨存算分离后，Warehouse 层面能力的增强与优化。

（2）收益体现

存算分离前，存储成本占总开支（计算+存储）的30%-40%，尤其在大数据量下更为显著。而StarRocks 3.0后，通过将三副本减至单副本并采用 OSS 存储，存储成本节省可达70%-80%。尽管增加 cache 盘带来一定开销，但相比原先的多副本存储费用，增加的成本微乎其微。简言之，改用 OSS 单副本存储配合局部 cache，大幅削减了存储成本。

在计算成本控制方面，StarRocks 集成 Warehouse 管理和弹性分析功能，尤其当采用 EMR Serverless StarRocks 时，能充分利用其新推出的弹性能力。该能力根据时间或负载调整计算节点数量，在高峰期增加节点以应对高并发需求，低谷期则减少节点以节约资源，有效实现成本优化，达到按需计费的高效经济运行模式。

就可靠性而言，StarRocks 依托 OSS 服务的高可用架构，确保数据安全无忧。计算层面，无状态的 CN 节点设计支持弹性扩展，实现资源的随需启用，进一步增强了系统的稳定性和效率。

资源隔离是 StarRocks 的一大改进点，尤其是在存算分离后，CN 节点能够实施更精细的管理。CN 节点通过分组形成独立的资源单元，每个组专属于特定的 Warehouse，避免了资源争抢现象，如同上图展示。这意味着导入作业、Ad-hoc 查询和固定报表等任务可被分配给不同的 Warehouse，实现物理上的隔离，每个 Warehouse 既能独立运作又能弹性伸缩，针对如 Ad-hoc 查询在流量波动大的情况下自动调整资源，减少不必要的计算开销。这一设计针对 StarRocks 追求的极速与统一性，有效解决了资源竞争的潜在痛点，确保数据导入、查询操作以及其他业务间互不干扰，通过多 Warehouse 机制在存算分离框架下，达成了高效且有序的资源调度与利用，进一步巩固了其在高性能数据分析领域的优势地位。

在性能考量上，存算分离场景下未命中缓存时，性能比存算一体略逊，比例约为1:3。但若能有效利用本地缓存，即使需保留一份数据副本导致轻微的存储成本上升，总体费用仍远低于存算一体方案。更重要的是，当查询完全命中本地缓存时，其性能可媲美存算一体架构。因此，存算分离不仅在保证性能不减的前提下降低了成本，还强化了资源隔离和弹性伸缩能力，进一步优化了整体系统效能与成本效益。

存算分离带来的关键益处在于显著降低了存储成本，这为 StarRocks 处理更庞大的数据集打开了新的可能。随着StarRocks 3.x及以后版本的“湖仓新范式”确立，其应用范畴超越了传统的OLAP领域，延伸至更多样化的计算与分析场景，展现出更强的灵活性与扩展性。

2、Multi-Warehouse

Multi-Warehouse 设计确保了硬件资源的物理隔离，涵盖 CPU、内存、网络及磁盘I/O等关键领域，为不同工作负载提供专属资源池。结合资源弹性伸缩能力，有效管控计算成本。该能力目前仍未上线，EMR Serverless StarRocks 正式版本计划于2024年6月发布。

3、极速统一的湖仓分析

在StarRocks 2.5中已经有了湖仓分析的能力，如读 Hive 表、HDFS 表，或湖格式相关的一些表（如 Iceberg、Paimon）等读取相关的能力。在 StarRocks 3.x之后重点对 Hive Catalog 进行了统一，即在湖仓使用体验、场景支持等方面进行了增强。

首先，通过统一的 Catalog，同时管理和分析外表的数据。以往我们需要对 Hive 和 Paimon 分别建立一个 Catalog，而在3.x后，用户可以通过1个 Catalog 把 Hive、Paimon，以及湖格式相关的表进行统一管理，很大程度上降低了用户对外表 Catalog 的维护难度，利于用户随时进行湖分析。其次，StarRocks 3.x开始支持湖上的写入能力。它支持将 StarRocks 加工、计算后的数据重新写回到湖上。此外，3.x的版本之后提供了一套新的 RBAC 权限机制。相较于3.x版本，2.5版本提供的较为简单，且很多流程较为困难。而3.x版本的权限体系的建立较为标准化，同时适用于外表和内表，实现了权限和安全部分内外表的统一，更加便捷。外表无需再通过 ranger 等方式管理，当然3.x也提供了 ranger 相关的能力，对外表和内表进行管理，虽然应用相对较少，但其已具备了这项能力。

4、极致数据湖分析性能

3.x后在 Catalog 的使用、管理、拓展新场景等方面均提供了更好的能力，在性能上也有进一步提升。我们经常需要建立数据湖，如查询 HDFS、OSS 上的一些数据，该场景下 StarRocks 的性能比 Trino 快了3-5倍。其核心的关键技术是 StarRocks 的全面向量化（底层所有算子的向量化），包括CBO、延迟物化等技术点，这保证数据湖分析场景下的极致性能查询。StarRocks 最擅长的，也是阿里云与社区在早期的版本中共建的特性，即 EMR 数据湖产品上做数据湖分析。因此，StarRocks 在数据湖分析的性能上有巨大的提高。同时，要达到同样的性能，StarRocks 数据湖分析场景使用的资源相对于 Trino 或 Presto 也要更少，可以节省1/3左右的资源。因此，越来越多的客户开始把 Impala、Trino、Presto 等传统的数据湖分析场景的计算引擎切换为 StarRocks，实现性能和成本的双赢。另外，上图中的 Block cache 也值得注意。在使用数据湖分析时，如认为性能提升3-5倍远还不够。要获得更极致的性能，还可以使用其 Block cache。在 Block cache 开启的情况下，数据湖的查询约有额外3倍的提升。这样，其性能基本可与 StarRocks 的内表持平。

5、Trino兼容，无缝切换

前面提到了 Trino 迁移的场景。原来用户做数据湖分析，大多使用 Trino 或 Presto 等引擎。 StarRocks 在3.x版本后推出的一个特性是 Trino gateway 或理解为 Trino SQL 的转译，可以通过 hint 的语句 set sql_dialect = “trino”，启用该语句后，就会自动按照 Trino 的语法进行解析，其兼容度约在90%以上（除一些特定函数不兼容）。常用函数及SQL语法层面兼容，只要启用即可将原来 Trino 相关的业务平滑迁移到 StarRocks 3.x。

6、数据建模透明查询加速

数仓建模与湖仓新范式强相关，StarRocks 有现代化物化视图的管理能力。物化视图其实是从2.5版本就开始发展了，但在3.x之后稳定性、性能、能力等方面有很大提升，如透明加速能力。透明加速是指用提前建立物化视图，原业务在 select a 转移 b 两个表时，只要提前预置了物化视图，其很大程度上会提升客户 select a 转移 b 场景的性能。而业务使用方则无感知，该透明加速能力在数据湖分析及传统的 OLAP 场景提速的条件下都可以考虑使用，其物化视图能力提升其查询性能。该功能与原来的分析场景结合也较为紧密。从3.x之后，StarRocks 社区在强调湖仓新范式。按照传统数仓，会分为 ADS、DWS、DWD、ODS 四层，但在3.x的湖仓新范式概念中，不建议进行太细的分层。因为，在大量的数据场景下，可以使用 StarRocks 直接查底层 ODS、DWD 相关的表，也可以满足日常机器查询 Ad-hoc 场景的分析，或对报表查询性能要求较低的场景下，可以直接分析原始的数据，无需提前把部分内容做加工预处理，可根据实际业务情况进行相应的取舍。在3.x后，可以使用 StarRocks 的物化视图管理机制，通过物化视图相关的能力，如设置定时刷新能力，这样免去了原本复杂的 ETL、调度等相关管理的能力，可以通过物化视图实现类似原来 ETL、调度的能力。当然，不建议像传统数仓，分很多层，建很多任务，定时调度非常复杂的场景。但如果是做简单的加工，分少量的层的场景，则可以考虑使用物化视图加刷新的能力简化复杂的 ETL 功能。同时，3.x也支持从湖上直接加载数据到内表的场景，即可以基于外表建立 catalog 的物化视图，通过物化视图把外表变成内表，进行提速，包括像建仓分层场景等。假设湖是 ODS，则要把 ODS 上的数据通过物化视图把外表的数据写入到内表，放到 DWD，然后再做一些建仓分层，简单的可以分两层。在以上提到的数仓数据建模的场景使用的特性就是物化视图。

三、基于 StarRocks 构建湖仓新范式

StarRocks 讲述的湖仓新范式，是指它既能连接湖，也能连接仓，即通过 StarRocks 进行湖和仓的融合。假设有很大的湖或仓，垂直业务即可使用 StarRocks 快速打通这两套业务。或对于小的业务，如业务数仓的体量在100TB以下，甚至可以完全考虑用 StarRocks 构建一整套新的湖仓体系。

1、统一开放的 Lakehouse 架构

它与开源的Lake house架构相似，如下图所示：

计算节点（CN 节点）类似开源的 Spark 和 Flink，负责整体的数据计算。FE 节点负责元数据，和计划相关，FE 节点类比于阿里云的 DLF、AWS 的 Glue 或开源的 HMS。对于 StarRocks 自身，StarRocks 内表有一套自己的 Table format 和 File format，这套 Format 现在仍属于内表，仍未开放，这两项基本也可以与开源社区类比。存储层，用户可以使用 OSS 或者 HDFS 等存储构建整个湖的存储介质。StarRocks 3.x推出了湖仓 Lakehouse，其技术架构与开源的 Lakehouse 架构完全对齐。该过程实现了各服务之间的完全解耦，使得每层的资源配置可以更加灵活，按需使用。

2、湖仓新范式的概念

第一，我们可以将数据实时写入 StarRocks（包括更新），直接使用物化视图进行预处理后，提供给业务系统直接查询使用。第二，我们可以将数据实时写到湖上（使用湖格式），通过 StarRocks 可以直接通过物化视图对湖上数据进行加工写入 StarRocks，也可以通过 StarRocks 进行数据加工后写回湖上(这个是新特性，还在不断迭代)。第三，离线场景下，也可以通过 Spark 或其他的数据集成工具（Dataworks）把数据从湖上写入 StarRocks。这些链路目前都是可以打通的。因此，基本上可使用 StarRocks 作为 Lakehouse 的核心计算引擎，帮助用户快速进行数据的分析和处理。物化视图机制极大简化了湖仓建模流程，省却了繁琐的 ETL 步骤，直接促进数据湖的即时分析与高效查询。StarRocks 凭借其强大的加速能力，无论是在数据湖环境还是传统数据仓库场景下，均能显著提升数据处理与分析的速度。StarRocks 湖仓新范式的能力，无缝融合数据湖与数据仓库的能力，实现湖上数据的直接读取并在 StarRocks 内部构建高效数据仓库，为用户提供了一站式、高性能的湖仓融合解决方案。

3、极致的湖仓分析性能

无论分析湖或是分析仓（用户可能使用开源或 Spark 构建仓，写到 HDFS，可能将湖存到OSS），如果要对这些湖和仓上的数据进行分析，以往用户可能会使用 Trino/Impala 等开源的引擎，在3.x之后，我们期望也确实有很多客户把这部分业务迁移到 StarRocks，因为其收益很明显。如上图所示。假设原本使用 Presto 查询，性能为1倍；使用外表查，性能可提升3倍；如果再加一层 local cache，性能可提升6倍；若期望更极速的性能，则可以把外表的数据直接写到 StarRocks 内表，性能可提升10倍。该性能的提升是平均值，特定场景的提升会优于这个值。这就是 StarRocks 目前最擅长、也是性能提升非常明显的一个业务场景，即极致的湖仓分析的性能。若与 Presto/Trino 等相比，两者有明显的一些能力差异。

因此，要进行湖上的分析，用户就会把业务从 Presto、Trino 迁移到 StarRocks。因为，无论从能力或性能，以及成本收益上来说，StarRocks 都要远优于 Presto、Trino。

4、湖仓分析架构

分析湖仓新范式的整套架构可以看到，在湖仓分析架构中有两种用法。

第一种如下图左侧所示：使用 StarRocks 做数据湖的查询加速，首先使用外表将数据写到湖上，然后直接使用 StarRocks 做报表或分析。这个过程相当于使用 StarRocks 进行了提速，相较于使用 Spark 查询，性能可提升5倍左右。因此，数据湖的查询加速采用直接查询。第二种如上图右侧所示。该种方式采用间接查，即先将数据写到湖上，然后使用物化视图加工，写入 StarRocks 内表，再去查询。这种查询方式性能约提升10倍。换言之，该过程是通过数据湖、StarRocks 构建写入内表，内表再做数据入仓的分层建模。若使用 EMR Serverless StarRocks 后面提供的弹性能力,也会帮助用户实现计算资源的零负载、零成本。这样，在日常使用过程中，就可以根据实际的使用，制定弹性计算相关的规则实时弹出相应的计算资源。同时，也会提供全方位的负载诊断和 SQL 层面诊断的能力。Cache 管理能力，后续的内容中将会对该部分知识进行讲解，即 StarRocks 在缓存方面做了相应的优化，以帮助用户做外表查询以及存算分离之后的查询。Cache 管理的优劣直接影响最终的查询性能，因此，Cache 管理在湖仓分析的场景下也非常重要。

5、数据仓库批处理场景架构

使用 StarRocks 建仓的场景主要包括两种。

一种是左侧 All in StarRocks，是指从数据写入的源头开始就写到 StarRocks 内表，写完后再通过物化视图做上层的分层调度。另一种用法是 All in DataLake，如上图右侧所示。该链路目前仍不够完整，但这可能是后续发展过程中较为常见的场景。该方法首先将数据写到湖上，然后通过 StarRocks 物化视图或外部 insert、all right 加上调度工具进行加工，再用 StarRocks 处理，处理完成后再写回湖上，如 Paimon、Iceberg 等。目前，社区已经支持写回 Iceberg，Paimon 和其他的湖格式在后续的版本中会相继被支持。StarRocks 在3.x后进行了与 Spill 相关的算子落盘，保证了整个 ETL 的稳定性。All in StarRocks 可以结合 Flink VVP 产品，实现 CTAS/CDAS 场景，实现 MySQL 的整库同步，也可以使用 Dataworks 的实时数据集成实时写入的场景，使用会更顺滑。

四、EMR Serverless StarRocks 产品介绍

1、适用场景及其与开源的差异

EMR Serverless StarRocks 发展至今已有近三年的时间，逐渐从半托管发展至如今的全托管，它实现了几大重要特性。在开源版本中，包括 OLAP 多维分析、即席分析、数据湖分析，这些分析场景在 StarRocks 上都可以实现高并发的点查，以及实时写、实时查，或构建实时数仓，以及构建简单的小型数仓，并结合湖构建湖上的数仓。

全托管产品从“极速”的角度进行了些优化，如针对主键的表或点查的 QPS，以及部分性能的提升，这主要是在存算分离的场景下。同时，在资源拉起和配置默认的情况下，较于开源版本 Doris，StarRocks 的性能要优于它2~3倍，这也是 EMR 选择 StarRocks 作为全托管 OLAP 引擎的原因。从“统一”的角度，StarRocks 也进行了优化。这一部分，更多地倾向于湖格式相关的内容，如与 Paimon 的集成，该集成使得湖格式的性能及能力更优。同时，还包括查询改写、物化视图，查询改写可以帮助用户在数据分析时提升查询性能，降低运维难度。此外，阿里云在平台层面做了易用性和云原生的集成，如与 DataWorks 的深度集成，可以使用 DataWorks 实时地将数据写到 StarRocks，可以离线批量写，也可以整库同步数据到 StarRocks，实现数据的入仓或入湖。利用 StarRocks 的小型建仓场景，也可以通过 DataWorks 的调度实现。这样的集成可直接供给用户使用，无需自行搭建。EMR StarRocks 平台还提供了导入可视化、元数据可视化、权限可视化、数据审计、即开即用的能力，降低用户的运维和使用成本。同时还会提供一些健康诊断分析的内容，如集群健康报告，帮助用户更好地管理和使用集群。此外，还有一些 SQL 的归因分析等能力。在云原生方面，其云上资源即开即用、分钟级交付以及扩缩容的性能均有极致的保障，还包括 Multi-Warehouse 和弹性伸缩（后续上线），Cache manage 提供可观测性能力，后续会提供 Cache 可管理的能力，帮助用户在存算分离和数据湖分析的场景下更好地管理 Cache 相关的内容。全托管还有一个突出特点，即免运维和 SLA 保障，该技术由阿里云全方位托管。

2、产品架构

如上图，EMR StarRocks 最底层，可以使用 OSS 存储或云盘存储，无论何种存储方式，可以使用开源的湖格式，也可以使用 StarRocks 内表，最终都可以使用 StarRocks 进行相应的分析，再结合 Warehouse 进行资源隔离，以及资源的弹性。StarRocks 还提供了一些产品能力，如即开即用的 SQL Editor、导入任务、权限管理、诊断审计，以及实例的基本管理、配置管理、监控告警，还包括 StarRocks 面临最大的问题—自动升级。它可以实现自动升级，这项能力也可以实现全自动升级，只需点击按钮即可实现无感知的升级。

3、创建实例-3个版本说明

在实际使用 Serverless StarRocks 过程中可能还会面临一定的问题，即其有三个版本。这三个版本包括存算一体，存算分离和数据湖分析，它们适用的场景不同。

如果是查询性能要求较高的 OLAP 场景，比如 OLAP 场景是 toC 情况，它会要求毫秒级别的响应，则使用存算一体版本。但该版本也会存在限制，即无法实现弹性，无法进行 Warehouse 资源隔离。其优点在于其性能的极致。存算分离版本目前仍处于 beta 阶段，但其能力基本不存在问题。它采用了 StarRocks 3.x架构。若要搭建简单的小型数仓，或做内部的报表（要求是秒级以上的响应），即可使用存算分离的版本。它可以提供弹性、Warehouse，以及 cache 管理的以及近远端 IO、cache 的分析报告。数据湖分析可以平替 Trino/Presto 场景，只能使用外表相关能力，但其在管控平台层面的能力基本上与存算分离保持一致，也可以进行弹性和 Multi-Warehouse。因此，关于版本的问题，需要用户结合自身业务场景，在创建 StarRocks 集群时自行选择适用于自身业务场景的版本。