本文发表于： &{ new Date(1717603200000).toLocaleDateString() }

主角介绍：

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

StarRocks：Linux 基金会项目 StarRocks 是新一代极速全场景 MPP 数据库。作为一种新兴的数据分析引擎，在业界已受到广泛的关注。它在性能、高并发和低延迟方面展现出了明显的优势，吸引了包括微信、小红书、携程、贝壳等大型企业的注意。目前，全球 380 家以上市值超过 70 亿元人民币的顶尖企业选择用 StarRocks 来构建新一代数据分析能力。

镜舟科技：镜舟科技是一家专注开源商业化的中国本土公司。基于开源 StarRocks ，镜舟打造了符合国家标准并适配国内外生态体系的企业级分析型（OLAP）数据库，在行业适配度、场景成熟度、产品稳定性等方面有着卓越表现。作为 StarRocks 社区中国最大贡献者，镜舟大力参与社区推广工作，未来也将持续与各大头部厂商一起，创造世界顶级的开源项目。

正文

那么，StarRocks 究竟如何构建其优势？与 Trino 相比，它有何异同之处？接下来，我们将围绕这些问题展开深入分析。

StarRocks 与 Trino 的相似之处

1. MPP 分布式架构

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

2. Cost-based Optimizer（CBO）

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

3. Pipeline 执行框架

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

1. 降低查询引擎中各种计算节点的任务调度成本。
2. 提高 CPU 利用率，同时处理查询请求。
3. 自动调整查询执行的并行度，充分利用多核系统的计算能力，从而提升查询性能。

4. ANSI SQL 支持

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

StarRocks 与 Trino 的区别

1. 向量化查询引擎

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。

2. 物化视图

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

• 自动重写查询以增强查询性能。StarRocks 会自动选择合适的物化视图来加速查询，用户不需要重写 SQL。
• 执行分区级别的物化视图刷新，在减少资源消耗的同时，让用户拥有更好的性能和可扩展性。

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

Trino 目前没有这些功能：

• 没有自动查询改写功能。用户需要花费大量时间进行查询重写。
• 在本地磁盘上写入物化视图。

3. 缓存系统

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

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

1. 基于高效的磁盘空间管理结构，避免了许多系统基于独立 Block 文件而导致大量数据文件造成的文件句柄占用问题。
2. 基于文件的更新信息来进行缓存校验，避免本地缓存读取的数据和远端不一致。
3. 支持磁盘缓存数据的 checksum 校验，可以避免由于磁盘故障等问题导致读取到异常数据。
4. 支持缓存 I/O 自适应，能够在 I/O 吞吐较高时自动将部分请求路由到远端，充分利用本地磁盘和网络带宽，增加整体 I/O 吞吐。

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

另外，在 3.3 版本即将支持：

1. 缓存空间自适应调整。能够根据当前磁盘的剩余空间动态调整缓存空间大小，保证当磁盘剩余空间较低时，及时释放空间给其他高优模块；而当磁盘剩余空间较多时，自动增加缓存空间，利用剩余磁盘提升缓存命中率。
2. 对指定的缓存对象设置优先级和 TTL。用户能够根据实际需求以不同的优先级来缓存不同的数据对象。

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

4. 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 结构中寻找到分布式环境下的最优执行计划。

5. 高可用性

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

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

6. 数据源和开放表模式

作为 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 的实际案例。

1. 小红书

在自助分析场景下，以前采用了 Presto 来优化整体的查询性能，但是随着小红书自助分析场景需求的不断增长，Presto 已不能满足日益增长的降本增效需求。在 Adhoc 场景下，Presto 上遇到了几个问题：Presto 的性能优化困难；Presto 的主从模式还存在单点故障问题，有潜在的稳定性风险。最终小红书 OLAP 团队决定从 Presto 迁移到 StarRocks 上。在基于实际业务进行验证时，从线上过去的实际查询中抽取 3000 个查询，分别进行了串行 10 并发、20 并发、30 并发的压力测试。对比 Presto，96% 的查询都有非常明显的性能优化效果。同时，在所有的并发度下，StarRocks 的查询性能相比 Presto 都有 4 倍以上的提升。

2. 微信

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

3. 携程

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

4. 芒果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 作为新的统一分析引擎。

5. 万物新生

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

6. 贝壳

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

7. 云览科技

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

8. 中信建投

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