一、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 的定位，即极速。
在
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 广泛适用于六大类场景：
第一，日常工作中的报表分析，服务于客户、运营团队、管理层等多角色，尤其擅长满足高实时性报表分析需求。
第二，支持数据的实时写入与查询，适用于大屏展示及动态监控系统。
第三，构建用户画像，助力精准营销，通过标签筛选细分市场，深化渠道分析。
第四，订单分析、销售预测、订单追踪等实时写、实时查的业务场景，或是销售相关的业务场景，以及常见的
第五，建立指标管理平台也可以通过
第六，StarRocks 3.x后发展出了数据仓库等 ETL 场景。如垂直业务，若业务量较大，则某个小的垂直业务会使用 StarRocks 做数据仓库，这种新业务的突出特点就是其业务变化较为频繁，需要 StarRocks 极速的响应，同时也有效避免了传统数仓建立完整的标准分层的过程，可以快速进行数据的加工和处理，响应业务的实时变化。
此外，从业务场景看，还有数据湖上的分析。严格来说，以上提到的六类场景中除数据仓库之外，都与数据湖分析相关。以往可能会使用
二、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 节点设计支持弹性扩展，实现资源的随需启用，进一步增强了系统的稳定性和效率。
资源隔离是
在性能考量上，存算分离场景下未命中缓存时，性能比存算一体略逊，比例约为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 进行了统一，即在湖仓使用体验、场景支持等方面进行了增强。
首先，通过统一的
其次，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，实现性能和成本的双赢。
另外，上图中的
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之后稳定性、性能、能力等方面有很大提升，如透明加速能力。
透明加速是指用提前建立物化视图，原业务在
从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 快速打通这两套业务。或对于小的业务，如业务数仓的体量在100TB以下，甚至可以完全考虑用 StarRocks 构建一整套新的湖仓体系。
1、统一开放的 Lakehouse 架构
它与开源的Lake house架构相似，如下图所示：
计算节点（CN 节点）类似开源的 Spark 和 Flink，负责整体的数据计算。
FE 节点负责元数据，和计划相关，FE 节点类比于阿里云的 DLF、AWS 的 Glue 或开源的 HMS。
对于
存储层，用户可以使用
StarRocks 3.x推出了湖仓 Lakehouse，其技术架构与开源的 Lakehouse 架构完全对齐。该过程实现了各服务之间的完全解耦，使得每层的资源配置可以更加灵活，按需使用。
2、湖仓新范式的概念
第一，我们可以将数据实时写入
第二，我们可以将数据实时写到湖上（使用湖格式），通过
第三，离线场景下，也可以通过
这些链路目前都是可以打通的。因此，基本上可使用
物化视图机制极大简化了湖仓建模流程，省却了繁琐的
3、极致的湖仓分析性能
无论分析湖或是分析仓（用户可能使用开源或
若与
因此，要进行湖上的分析，用户就会把业务从
4、湖仓分析架构
分析湖仓新范式的整套架构可以看到，在湖仓分析架构中有两种用法。
第一种如下图左侧所示：使用
第二种如上图右侧所示。该种方式采用间接查，即先将数据写到湖上，然后使用物化视图加工，写入
若使用
Cache 管理能力，后续的内容中将会对该部分知识进行讲解，即 StarRocks 在缓存方面做了相应的优化，以帮助用户做外表查询以及存算分离之后的查询。Cache 管理的优劣直接影响最终的查询性能，因此，Cache 管理在湖仓分析的场景下也非常重要。
5、数据仓库批处理场景架构
使用
一种是左侧
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 的集成，该集成使得湖格式的性能及能力更优。同时，还包括查询改写、物化视图，查询改写可以帮助用户在数据分析时提升查询性能，降低运维难度。
此外，阿里云在平台层面做了易用性和云原生的集成，如与
在云原生方面，其云上资源即开即用、分钟级交付以及扩缩容的性能均有极致的保障，还包括
全托管还有一个突出特点，即免运维和
2、产品架构
如上图，EMR StarRocks 最底层，可以使用 OSS 存储或云盘存储，无论何种存储方式，可以使用开源的湖格式，也可以使用 StarRocks 内表，最终都可以使用 StarRocks 进行相应的分析，再结合 Warehouse 进行资源隔离，以及资源的弹性。StarRocks 还提供了一些产品能力，如即开即用的 SQL Editor、导入任务、权限管理、诊断审计，以及实例的基本管理、配置管理、监控告警，还包括 StarRocks 面临最大的问题—自动升级。它可以实现自动升级，这项能力也可以实现全自动升级，只需点击按钮即可实现无感知的升级。
3、创建实例-3个版本说明
在实际使用
如果是查询性能要求较高的
存算分离版本目前仍处于
数据湖分析可以平替
因此，关于版本的问题，需要用户结合自身业务场景，在创建
4、实例管理
关于实例的基本管理，控制台部分可以直接看到。
它包括实例的扩缩容配置、云盘的扩缩容配置，以及黑、白名单，公网的开通，自动升级等能力，还有可视化的配置管理、监控告警（相关的图表告警模板）、审计（控制台的操作审计、数据审计，这些审计可以在一键开启审计日志后，在
5、健康报告
SQL 相关的健康报告，可以排查慢 SQL 或占资源较多的 SQL。
热表和导入任务分析会分析相关的使用较频繁或小文件较多的表，或是导入任务占用资源较大，或是不符合预期的导入任务的数据，这些都可以在该健康报告中看到相应的统计分析报告，帮助用户进行实例治理或数据治理。
6、即开即用的 SQL Editor 工具
在
7、可视化导入任务
导入任务的可视化，即所有相关的导入任务，无论是
8、可视化元数据管理
Manager 中还可以看到元数据的信息，包括缓存的分布情况、存储分区分桶。
9、SQL 诊断分析与归因
会给出
10、安全及权限便捷管理
提供了权限管理的可视化管理能力，也可以使用开源的命令行维护。
直播回放链接：https://developer.aliyun.com/live/253996
欢迎钉钉扫码加入EMR Serverless StarRocks交流群（搜索钉钉群号加群：24010016636）
