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

本文涉及的产品
EMR Serverless StarRocks,5000CU*H 48000GB*H
EMR Serverless Spark 免费试用,1000 CU*H 有效期3个月
简介: 阿里云 E-MapReduce Serverless StarRocks 版是阿里云提供的 Serverless StarRocks 全托管服务,提供高性能、全场景、极速统一的数据分析体验,具备开箱即用、弹性扩展、监控管理、慢 SQL 诊断分析等全生命周期能力。内核 100% 兼容 StarRocks,性能比传统 OLAP 引擎提升 3-5 倍,助力企业高效构建大数据应用。本篇文章对阿里云EMR Serverless StarRocks OLAP 数据分析场景进行解析、存算分离架构升级以及 Trino 兼容,无缝替换介绍。

内容导读 :


主题: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 应运而生,其目标是实现通过一个产品满足用户所有数据分析需求,从而降低用户的选择成本和维护成本。

幻灯片4.PNG


2、StarRocks 应用场景

StarRocks 能满足以下数据分析场景

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

幻灯片5.PNG

3、StarRocks 社区快速迭代

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

幻灯片6.PNG


二、StarRocks OLAP 分析核心特性

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

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

幻灯片8.PNG


2、性能:全面向量化

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

幻灯片9.PNG


3、性能:全新CBO

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

幻灯片10.PNG


4、性能:现代物化视图

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

幻灯片11.PNG


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, 能够非常好的实现高效读写的实时更新引擎。

幻灯片12.PNG


6、高并发:Pipeline引擎

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


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

幻灯片13.PNG


7、灵活:分布式 Join

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


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

幻灯片14.PNG


三、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节点可以增加一些磁盘热数据的缓存这也能实现热数据的查询,性能不会有明显降低。目前看,存算分离架构是适合有一些冷热特性的业务场景。

幻灯片16.PNG


2、存算分离收益

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


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


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


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

幻灯片17.PNG


3、极速统一的湖仓分析

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

幻灯片18.PNG


4、Trino兼容,无缝替换

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

幻灯片19.PNG


4、极致的湖仓分析性能

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

幻灯片20.PNG


四、阿里云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引擎就能满足其业务需求,避免引入更多技术栈,增加太多的维护成本和学习成本。

幻灯片22.PNG




产品导航



EMR Serverless StarRocks钉钉交流群(群号:24010016636)

相关实践学习
基于EMR Serverless StarRocks一键玩转世界杯
基于StarRocks构建极速统一OLAP平台
快速掌握阿里云 E-MapReduce
E-MapReduce 是构建于阿里云 ECS 弹性虚拟机之上,利用开源大数据生态系统,包括 Hadoop、Spark、HBase,为用户提供集群、作业、数据等管理的一站式大数据处理分析服务。 本课程主要介绍阿里云 E-MapReduce 的使用方法。
目录
打赏
0
11
13
3
1228
分享
相关文章
千万级数据秒级响应!碧桂园基于 EMR Serverless StarRocks 升级存算分离架构实践
碧桂园服务通过引入 EMR Serverless StarRocks 存算分离架构,解决了海量数据处理中的资源利用率低、并发能力不足等问题,显著降低了硬件和运维成本。实时查询性能提升8倍,查询出错率减少30倍,集群数据 SLA 达99.99%。此次技术升级不仅优化了用户体验,还结合AI打造了“一看”和“—问”智能场景助力精准决策与风险预测。
170 69
美的楼宇科技基于阿里云 EMR Serverless Spark 构建 LakeHouse 湖仓数据平台
美的楼宇科技基于阿里云 EMR Serverless Spark 建设 IoT 数据平台,实现了数据与 AI 技术的有效融合,解决了美的楼宇科技设备数据量庞大且持续增长、数据半结构化、数据价值缺乏深度挖掘的痛点问题。并结合 EMR Serverless StarRocks 搭建了 Lakehouse 平台,最终实现不同场景下整体性能提升50%以上,同时综合成本下降30%。
375 58
阿里云 EMR Serverless StarRocks3.x,极速统一的湖仓新范式
阿里云 EMR Serverless StarRocks3.x,极速统一的湖仓新范式
EMR Serverless StarRocks 全面升级:重新定义实时湖仓分析
本文介绍了EMR Serverless StarRocks的发展路径及其架构演进。首先回顾了Serverless Spark在EMR中的发展,并指出2021年9月StarRocks开源后,OLAP引擎迅速向其靠拢。随后,EMR引入StarRocks并推出全托管产品,至2023年8月商业化,已有500家客户使用,覆盖20多个行业。 文章重点阐述了EMR Serverless StarRocks 1.0的存算一体架构,包括健康诊断、SQL调优和物化视图等核心功能。接着分析了存算一体架构的挑战,如湖访问不优雅、资源隔离不足及冷热数据分层困难等。
活动实践 | 基于EMR StarRocks实现游戏玩家画像和行为分析
基于阿里云EMR Serverless StarRocks,利用其物化视图和DLF读写Paimon等能力,构建游戏玩家画像和行为分析平台。通过收集、处理玩家行为日志,最终以报表形式展示分析结果,帮助业务人员决策。
鹰角网络:EMR Serverless Spark 在《明日方舟》游戏业务的应用
鹰角网络为应对游戏业务高频活动带来的数据潮汐、资源弹性及稳定性需求,采用阿里云 EMR Serverless Spark 替代原有架构。迁移后实现研发效率提升,支持业务快速发展、计算效率提升,增强SLA保障,稳定性提升,降低运维成本,并支撑全球化数据架构部署。
179 56
鹰角网络:EMR Serverless Spark 在《明日方舟》游戏业务的应用
Serverless MCP 运行时业界首发,函数计算让 AI 应用最后一公里提速
作为云上托管 MCP 服务的最佳运行时,函数计算 FC 为阿里云百炼 MCP 提供弹性调用能力,用户只需提交 npx 命令即可“零改造”将开源 MCP Server 部署到云上,函数计算 FC 会准备好计算资源,并以弹性、可靠的方式运行 MCP 服务,按实际调用时长和次数计费,欢迎你在阿里云百炼和函数计算 FC 上体验 MCP 服务。
233 29
云大使 X 函数计算 FC 专属活动上线!享返佣,一键打造 AI 应用
如今,AI 技术已经成为推动业务创新和增长的重要力量。但对于许多企业和开发者来说,如何高效、便捷地部署和管理 AI 应用仍然是一个挑战。阿里云函数计算 FC 以其免运维的特点,大大降低了 AI 应用部署的复杂性。用户无需担心底层资源的管理和运维问题,可以专注于应用的创新和开发,并且用户可以通过一键部署功能,迅速将 AI 大模型部署到云端,实现快速上线和迭代。函数计算目前推出了多种规格的云资源优惠套餐,用户可以根据实际需求灵活选择。
Serverless MCP 运行时业界首发,函数计算让 AI 应用最后一公里提速
Serverless MCP 运行时业界首发,函数计算支持阿里云百炼 MCP 服务!阿里云百炼发布业界首个全生命周期 MCP 服务,无需用户管理资源、开发部署、工程运维等工作,5 分钟即可快速搭建一个连接 MCP 服务的 Agent(智能体)。作为云上托管 MCP 服务的最佳运行时,函数计算 FC 为阿里云百炼 MCP 提供弹性调用能力。
193 0
 Serverless MCP 运行时业界首发,函数计算让 AI 应用最后一公里提速
Serverless + AI 让应用开发更简单,加速应用智能化
Serverless + AI 让应用开发更简单,加速应用智能化
106 5
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等