StarRocks vs. Trino: 解密高性能背后的技术优势

原创
06/11 15:20
阅读数 755

Trino(之前称 PrestoSQL)项目最初由 Meta 开发,旨在让数据分析师能够在广泛的 Apache Hadoop 数据仓库上执行交互式查询。其高效处理大型数据集和复杂查询的能力,以及多数据源连接的灵活性,使其迅速成为大规模组织的首选数据分析工具。随着时间的推移,用户对数据分析的需求不断演变。移动互联网和 SaaS 应用的兴起,实时分析变得至关重要。因此,企业需要更高性能、更高并发、低延迟的数据分析引擎来满足不断增长的数据分析需求。在这种情况下,越来越多的用户开始寻找替代方案。

StarRocks 作为一种新兴的数据分析引擎,在业界已受到广泛的关注。它在性能、高并发和低延迟方面展现出了明显的优势,吸引了包括微信、小红书、携程、贝壳等大型企业的注意。那么,StarRocks 究竟如何构建其优势?与 Trino 相比,它有何异同之处?接下来,我们将围绕这些问题展开深入分析。

StarRocks 与 Trino 的相似之处

MPP 分布式架构

两个引擎都采用 MPP 作为其分布式执行框架,在这个框架中,一个查询请求被拆分为众多的逻辑和物理执行单元,并在多个节点上同时运行。与许多其他数据分析产品在其分布式计算框架中使用的 scatter-gather 模式不同,MPP 可以利用更多的资源来处理查询请求。得益于这个框架,两个引擎都可以在 PB 级的数据上使用,数百个大型用户已经在其生产环境中使用了这些引擎。

Cost-based Optimizer(CBO)

两个引擎都内置了高效的基于成本的优化器(CBO),这在处理多表 Join 查询时尤为关键。得益于 CBO,这两个引擎都能够处理包括复杂查询、Join 和聚合在内的多种 SQL 特性。此外,Trino 和 StarRocks 都通过了 TPC-H 和更难的 TPC-DS 基准测试,证明了两者都有极为出色的性能。

Pipeline 执行框架

两个引擎都有 Pipeline 执行框架。Pipeline 执行框架的主要目标是增强查询引擎在单机上利用多核资源的效率,其主要功能包括三个方面:

  • 降低查询引擎中各种计算节点的任务调度成本。

  • 提高 CPU 利用率,同时处理查询请求。

  • 自动调整查询执行的并行度,充分利用多核系统的计算能力,从而提升查询性能。

ANSI SQL支持

两个引擎都符合 ANSI SQL,分析师可以在日常工作中使用他们最熟悉的查询语言,而无需额外的学习成本。企业经常使用的 BI 工具也将非常容易地与 StarRocks 或 Trino 集成。

StarRocks 与 Trino 的区别

向量化查询引擎

图片

StarRocks 是 C++ 实现的 Native 向量化引擎,关键的导入、查询链路都实现了全面向量化;Trino 是 Java 实现的,使用了有限的向量化技术。向量化技术帮助 StarRocks 更高效地利用 CPU 处理能力。StarRocks 具有以下特点:

  • 可以充分利用列式数据管理的效率。StarRocks 从列式存储中读取数据,在内存中管理数据的方式,以及算子处理数据的方式都是列式的,从而可以更有效地利用 CPU 缓存,提高 CPU 执行效率。

  • 可以充分利用CPU支持的SIMD指令。这使得 CPU 可以在更少的时钟周期内完成更多的数据计算,StarRocks 使用向量化指令可以将整体性能提高 3-10 倍。

  • 可以更有效地压缩数据,从而大大减少内存占用。这使得这种类型的查询引擎更有能力处理大数据量的查询请求。

事实上,Trino 也在探索向量化技术。Trino 包含 SIMD 代码,但与 StarRocks 相比,在深度和覆盖率方面落后。Meta 的 Velox 项目旨在使用向量化技术来加速 Trino 查询。然而,到目前为止,很少有公司在生产环境中正式使用 Velox。

物化视图

图片

StarRocks 具有几个 Trino 没有的物化视图功能。物化视图是加速查询的常见优化手段,StarRocks 和 Trino 都支持创建物化视图,但是 StarRocks 能够:

  • 自动重写查询以增强查询性能。StarRocks 会自动选择合适的物化视图来加速查询,用户不需要重写 SQL。

  • 执行分区级别的物化视图刷新,在减少资源消耗的同时,让用户拥有更好的性能和可扩展性。

  • 可以选择将物化视图写入本地磁盘,而不是访问远程磁盘/存储。用户可以利用本地磁盘的高性能,本地存储采用 StarRocks 专有的列式存储格式,更好地支持向量化查询引擎的执行。

Trino 目前没有这些功能:

  • 没有自动查询改写功能。用户需要花费大量时间进行查询重写。

  • 在本地磁盘上写入物化视图。

缓存系统

StarRocks 基于自研的数据缓存库,提供高效的数据缓存功能:

  1. 支持内存和磁盘两级 Cache,和单纯的磁盘缓存相比,在内存管理上更加灵活、可控。

  2. 基于高效的磁盘空间管理结构,避免了许多系统基于独立 Block 文件而导致大量数据文件造成的文件句柄占用问题。

  3. 基于文件的更新信息来进行缓存校验,避免本地缓存读取的数据和远端不一致。

  4. 支持磁盘缓存数据的 checksum 校验,可以避免由于磁盘故障等问题导致读取到异常数据。

  5. 支持缓存 I/O 自适应,能够在 I/O 吞吐较高时自动将部分请求路由到远端,充分利用本地磁盘和网络带宽,增加整体 I/O 吞吐。

  6. 缓存预热功能,通过 cache select 语句对指定对象的数据进行单次或者周期缓存预热,避免首次冷读时的性能问题。

另外,在 3.3 版本即将支持:

  1. 缓存空间自适应调整。能够根据当前磁盘的剩余空间动态调整缓存空间大小,保证当磁盘剩余空间较低时,及时释放空间给其他高优模块;而当磁盘剩余空间较多时,自动增加缓存空间,利用剩余磁盘提升缓存命中率。

  2. 对指定的缓存对象设置优先级和 TTL 。用户能够根据实际需求以不同的优先级来缓存不同的数据对象。

与此相比,Trino 的 Cache 尚未被广泛采用。StarRocks 在 3.3 版本中的 Cache 功能已成熟并默认启用。

Join 性能


Trino 和 StarRocks 都可以支持复杂的 Join 操作。然而,StarRocks 能够提供更高的性能。这是因为,除了向量化查询引擎外,StarRocks 还拥有一些特殊的技术能力。

Join 重新排序(Join Reorder)是一种可用于提高涉及多表 Join 的数据库查询性能的技术,它通过更改 Join 执行的顺序来工作。

执行 Join 查询的成本取决于被连接的表的大小和连接执行的顺序,通过重新排序 Join,可以找到更高效的 Join 计划。Join 重新排序可以由优化器执行,也可以由用户手动指定。优化器通常会尝试重新排序 Join 以最小化查询的成本。

有许多不同的算法可用于重新排序 Join。StarRocks 实现的一些最常见的算法包括:

  • 贪心算法**(Greedy algorithm):贪心算法通过重复选择具有最低 Join 成本的表对,并将它们连接在一起来工作。

  • **动态规划算法(Dynamic programming algorithm):动态规划算法的工作原理是先构建一个包含每对表的连接成本的表,然后基于该表找到最优的 Join 计划。

  • **穷举算法(Exhaust algorithm):一种执行数据连接的技术,特别适用于大型数据集。它通过将 Join 操作分解为更小、更易于管理的任务来工作。这使得原先因数据量过大而无法装入内存的数据集也能执行 Join 操作。

  • **左深 Join 重新排序(Left-deep join reordering):一种启发式算法,用于优化查询中的 Join 顺序。该算法通过递归构建左深 Join 树来工作,其中树中的每个节点代表一个 Join 操作。该算法从最小的表开始,然后递归地将其与下一个最小的表连接,直到所有表都已连接。

  • Join 结合律(Join Associativity algorithm):通过多表结合律实现 Join Reorder,同时支持 Inner/Semi/Cross/Anti/Outer Join 的结合律运算,在维度表之间数据量差异大,多个维度表和事实表关联谓词匹配性不一致时,能自动调整 Join 顺序以提升计算性能。

  • Join 交换算法(Join Commutativity algorithm):一种优化查询中 Join 顺序的技术,通过利用 Join 的交换性属性来工作,该属性指出可以在不影响结果的情况下更改 Join 操作数的顺序。

StarRocks 相较于 Trino,提供了更丰富的 Join 实现算法。它根据 Join 节点的数量,采用不同的 Join Reorder 策略:在节点较少时,采用枚举法;当节点数不超过 10 个时,使用动态规划和贪心算法;而当节点数超过 10 个时,仅使用贪心算法。这种多样化的算法应用,使得 StarRocks 在 Join 节点较少时能够找到最优执行计划,在节点较多时也能快速生成高效的执行计划。

为了确保执行计划不仅在单机上是最优的,StarRocks 还保留了多种算法生成的 Join 顺序,以便于在 Memo 结构中寻找到分布式环境下的最优执行计划。

高可用性

StarRocks 有两种类型的节点,每种节点都能够通过特定的策略实现高可用。前端 (FE)节点是无状态的,可以通过部署奇数个前端节点来实现高可用,节点之间使用 Raft 协议进行 leader 选举;后端(BE)节点支持多副本机制,保证任何一个节点的故障都不会影响系统的运行。因此 StarRocks 可以实现系统的热升级,在系统升级期间,系统的在线服务不会受到影响。

Trino 没有内置的高可用性(HA)支持。Trino 的协调器是系统中的单点故障,如果这个节点发生故障,整个系统就会变得不可用。这意味着每当系统升级时,Trino 的在线服务都需要停止一段时间。到目前为止,Trino 项目还没有提供解决这个问题的方案。

数据源和开放表模式

作为 Data Mesh 概念的倡导者,Trino 社区一直致力于整合更多的数据源。到目前为止,Trino 已经开发了 60 多个不同的连接器,实现了与各种数据源的连接,包括关系型数据库、数据湖等。这使得 Trino 可以作为企业的统一查询引擎,促进对来自不同来源的数据进行联合分析。这对于拥有多个业务和多样化数据源的大型企业特别有用。目前,StarRocks 更专注于查询 Open Data Lakes,而其他数据源的连接器较少。

图片

StarRocks 支持 Apache Iceberg、Apache Hudi、Apache Hive 、Apache Paimon 和 Delta Lake 的读取。StarRocks 具有一定的 Apache Iceberg/Hive 写入能力。从下文的 Benchmarks 可见, **StarRocks 作为数据湖的查询引擎更快。**Trino 支持 Apache Iceberg、Apache Hudi、Apache Hive 和 Delta Lake 的读取和写入。根据 StarRocks 的 Roadmap,开放数据湖的写入能力将很快得到增强。

Benchmarks

采用 TPC-DS1TB 数据集进行测试,分别使用 StarRocks 和 Trino 查询以 Apache Iceberg 表格式存储的 Parquet 文件的相同数据副本,结果是 StarRocks 的整体查询响应时间比 Trino 快 5.54倍

图片

基于 StarRocks 构建 Lakehouse

基于 StarRocks 存算分离架构,以及物化视图、极速湖仓分析等独特的技术特性,可以帮助用户更方便的构建 Lakehouse。基于统一开放的数据湖存储,采用 StarRocks 直接查询数据湖,可以实现媲美数据仓库的性能,使得许多业务应用可以直接构建在数据湖上,无需将数据导入数仓进行分析。

在一些面向用户的数据分析场景中,需要更低的查询延迟和更高的查询并发,StarRocks 的物化视图可以发挥重要作用,实现按需的建模加速。物化视图不仅利用计算节点的本地存储加速相关查询,其数据更新是自动的,无需人工干预。此外,物化视图的自动重写功能允许用户在不重写任何 SQL 的情况下享受视图的加速效果。

图片

用户案例

Trino 是一个非常受欢迎的开源查询引擎。当企业拥有多个数据源,需要以统一的方式分析这些来源的数据时,Trino 是一个合适的选择。与 Trino 相比,使用 StarRocks 客户可以轻松实现更高性能的查询体验。接下来,我们将探讨一些用户选择 StarRocks 作为替代 Trino/Presto 的实际案例。

小红书

在自助分析场景下,以前采用了 Presto 来优化整体的查询性能,但是随着小红书自助分析场景需求的不断增长,Presto 已不能满足日益增长的降本增效需求。在 Adhoc 场景下,Presto 上遇到了几个问题:Presto 的性能优化困难;Presto 的主从模式还存在单点故障问题,有潜在的稳定性风险。

最终小红书 OLAP 团队决定从 Presto 迁移到 StarRocks 上。在基于实际业务进行验证时,从线上过去的实际查询中抽取 3000 个查询,分别进行了串行 10 并发、20 并发、30 并发的压力测试。对比 Presto,96% 的查询都有非常明显的性能优化效果。同时,在所有的并发度下,StarRocks 的查询性能相比 Presto 都有 4 倍以上的提升。

详见《StarRocks 在小红书自助分析场景的应用与实践

微信

实现湖仓一体的其中一种技术路线是湖上建仓,即在数据湖基础上实现数仓的功能,代替传统数仓,构建 Lakehouse。在微信内部,湖上建仓的架构经历了从 Presto + Hive 到 StarRocks + Iceberg 的演变过程,通过使用 StarRocks 替代 Presto,数据的时效性从小时/天级提高到了分钟级,同时查询效率从分钟级提高到了秒级/分钟级,其中 80% 的大查询用 StarRocks 解决,秒级返回,剩下的超大查询通过 Spark 来解决。与 Presto 相比,StarRocks 直接查湖的性能提升 3-6 倍以上。

详见《微信基于 StarRocks 的湖仓一体实践

携程

Artnova 是携程内部统一的报表平台,自 2022 年起,携程就开始采用 StarRocks 作为加速 Artnova 报表的新引擎,第一阶段把 StarRocks 当作 OLAP 数据库使用,只选取了最重要、性能最需要提升的业务进行了迁移,剩余业务仍旧通过 Trino 来进行湖上查询加速。3.0 版本发布之后,StarRocks 不仅在查湖的性能、稳定性上进行了增强,外表物化视图的能力更是让人眼前一亮,而且社区还支持了 Trino 的语法,大大降低了迁移门槛。根据携程数据团队的测试,**StarRocks 在直接查湖的性能上非常优异,在开启 Data Cache 后性能是 Trino 的 7 倍,某些场景下创建物化视图后甚至有几十倍性能提升。**此外,使用生产 SQL 反复测试得出其内置语法兼容性已经超过 99%,比例非常之高。因此携程开始持续推动存量 Trino 查询迁移到 StarRocks 外表+物化视图的查询方式。

详见《无需数据搬迁,10倍性能提升!携程的统一分析之旅

芒果TV

自 2018 年起,芒果TV 全面采用 Hadoop 架构,并引入 Trino 作为主要的查询引擎,以满足各种数据需求。然而,随着平台接入的业务越来越多,数据量越来越大,业务分析需求也变得更加实时、更加复杂和精细,Trino 的性能逐渐出现瓶颈。在 2022 年 11 月,芒果 TV 开始了 OLAP 迭代选型工作,并最终选择了 EMR StarRocks 与线上的 Trino 环境进行了性能比对测试。根据测试,在资源相差很多、且没有打开 Data Cache 的情况下,StarRocks 的性能还明显优于 Trino,**平均效率是原有的 2-3 倍。**迁移成本上,StarRocks 兼容 Trino 语法,更加易于迁移。我们将 Trino 的历史 SQL 进行了回放,SQL 语法兼容程度到达了 90%。因此芒果 TV 决定最终选择 StarRocks 作为新的统一分析引擎。

详见《在不断进化中披荆斩棘,芒果TV 基于 StarRocks 的云原生湖仓架构升级

万物新生

在经历了 MySQL、Greenplum、Trino 等多种架构之后,为了在不进行扩容的前提下进一步增强用户的查询体验,并提高整个服务的性价比,万物新生引入了 StarRocks。根据万物新生在真实业务场景中的测试,StarRocks 的查询性能整体优于 Trino。在串行测试中,StarRocks 的性能是 Trino 的 6.77 倍,在 10并行测试中是 Trino 的 10.96 倍,在 20 并行测试中是 Trino 的 16.03 倍。

详见《10 倍性价比,万物新生基于 StarRocks 无缝直替 Trino!

贝壳

贝壳内部的 BI 产品 ODIN 分析平台中提供基于 Hive 的分析能力,底层通过 Presto 引擎查询,用户通过 PrestoSQL 进行建模分析,模型和引擎耦合非常紧密,无法轻易的转换成到其他引擎的查询。StarRocks 支持了 Hive 外表的功能,**同时相比 Presto 有 3 倍以上的性能提升,使得 StarRocks 在贝壳有能力统一OLAP 场景。目前已开始将分流到 StarRocks 做测试验证,后续随着 StarRocks Trino/Presto 兼容能力的进一步提升,会继续提升 StarRocks 的流量占比,实现 StarRocks 在分析层的完全统一。

详见《性能全面飙升!StarRocks 在贝壳找房的极速统一实践

云览科技

以前云览科技 OLAP 使用了 Trino、ClickHouse、StarRocks。其中,Trino 给业务同学提供即席查询用途,当并发量大、大查询多时,Trino 很容易出现内存溢出,稳定性不足,目前统计线上查询失败的情况约有10%左右由内存溢出导致。ClickHouse 则无法处理高并发场景,很容易因 CPU 打满导致服务重启。StarRocks 社区在 3.0.0 版本推出了存算分离版本后,云览科技第一时间进行了调研测评,在后续的存算分离实践中,降本增效收益显著,数据团队已计划基于 StarRocks 实现一套 Lakehouse 新架构,去掉当前多套 OLAP 服务,只保留 StarRocks 作为计算引擎,节约大量计算资源。

详见《数仓成本下降近一半,StarRocks 存算分离助力云览科技业务出海

中信建投

中信建投在 2019 年搭建了基于 Hadoop 体系的数据湖,将大量历史数据迁移到 Hadoop 上,用 Hive 对数据进行加工处理,所有的查询计算都通过 Presto 执行。但是,该方案在最近两年数据量快速增长、业务场景多样化发展的趋势下逐渐无法适用。具体而言,Presto 在大数据量、多表关联查询时会出现响应比较慢,甚至无法获得查询结果的问题,无法满足单表及多表复杂查询场景下响应的及时性。此外, Presto 因为资源隔离不足会出现应用抢占资源的情况,不能很好支持高并发的查询请求。后来,中信建投选择引入 StarRocks 来构建统一的查询服务平台,满足各部门的用数需求。采用 StarRocks 内部表加速明细数据关联查询,实现了上亿级别数据量大表关联秒级响应,**内表查询效率提升 10 倍以上,外表查询效率提升 1 倍以上,**完全满足大数据量下查询分析及时响应的需求。

详见《化繁为简|中信建投基于StarRocks构建统一查询服务平台

更多交流,联系我们:https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/2b42f

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部