Trino（之前称 PrestoSQL）项目最初由 Meta 开发，旨在让数据分析师能够在广泛的 Apache Hadoop 数据仓库上执行交互式查询。其高效处理大型数据集和复杂查询的能力，以及多数据源连接的灵活性，使其迅速成为大规模组织的首选数据分析工具。随着时间的推移，用户对数据分析的需求不断演变。移动互联网和 SaaS 应用的兴起，实时分析变得至关重要。因此，企业需要更高性能、更高并发、低延迟的数据分析引擎来满足不断增长的数据分析需求。在这种情况下，越来越多的用户开始寻找替代方案。
StarRocks 作为一种新兴的数据分析引擎，在业界已受到广泛的关注。它在性能、高并发和低延迟方面展现出了明显的优势，吸引了包括微信、小红书、携程、贝壳等大型企业的注意。那么，StarRocks 究竟如何构建其优势？与 Trino 相比，它有何异同之处？接下来，我们将围绕这些问题展开深入分析。
StarRocks 与 Trino 相似之处
Massively Parallel Processing (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 基于自研的数据缓存库，提供高效的数据缓存功能：
-
支持内存和磁盘两级 Cache， 和单纯的磁盘缓存相比，在内存管理上更加灵活、可控。
-
基于高效的磁盘空间管理结构， 避免了许多系统基于独立 Block 文件而导致大量数据文件造成的文件句柄占用问题。
-
基于文件的更新信息来进行缓存校验， 避免本地缓存读取的数据和远端不一致。
-
支持磁盘缓存数据的 checksum 校验， 可以避免由于磁盘故障等问题导致读取到异常数据。
-
支持缓存 I/O 自适应。 能够在 I/O 吞吐较高时自动将部分请求路由到远端，充分利用本地磁盘和网络带宽，增加整体 I/O 吞吐。
-
缓存预热功能： 通过 cache select 语句对指定对象的数据进行单次或者周期缓存预热，避免首次冷读时的性能问题。
另外，在 3.3 版本即将支持：
-
缓存空间自适应调整。 能够根据当前磁盘的剩余空间动态调整缓存空间大小，保证当磁盘剩余空间较低时，及时释放空间给其他高优模块；而当磁盘剩余空间较多时，自动增加缓存空间，利用剩余磁盘提升缓存命中率。
-
对指定的缓存对象设置优先级和 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 倍以上。
云览科技
以前云览科技 OLAP 使用了 Trino、ClickHouse、StarRocks。其中，Trino 给业务同学提供即席查询用途，当并发量大、大查询多时，Trino 很容易出现内存溢出，稳定性不足，目前统计线上查询失败的情况约有10%左右由内存溢出导致。ClickHouse 则无法处理高并发场景，很容易因 CPU 打满导致服务重启。StarRocks 社区在 3.0.0 版本推出了存算分离版本后，云览科技第一时间进行了调研测评，在后续的存算分离实践中，降本增效收益显著，数据团队已计划基于 StarRocks 实现一套 Lakehouse 新架构，去掉当前多套 OLAP 服务，只保留 StarRocks 作为计算引擎，节约大量计算资源。
详见《数仓成本下降近一半，StarRocks 存算分离助力云览科技业务出海》
携程
Artnova 是携程内部统一的报表平台，自 2022 年起，携程就开始采用 StarRocks 作为加速 Artnova 报表的新引擎，第一阶段把 StarRocks 当作 OLAP 数据库使用，只选取了最重要、性能最需要提升的业务进行了迁移，剩余业务仍旧通过 Trino 来进行湖上查询加速。3.0 版本发布之后，StarRocks 不仅在查湖的性能、稳定性上进行了增强，外表物化视图的能力更是让人眼前一亮，而且社区还支持了 Trino 的语法，大大降低了迁移门槛。根据携程数据团队的测试， StarRocks 在直接查湖的性能上非常优异，在开启 Data Cache 后性能是 Trino 的 7 倍，某些场景下创建物化视图后甚至有几十倍性能提升。 此外，使用生产 SQL 反复测试得出其内置语法兼容性已经超过 99%，比例非常之高。因此携程开始持续推动存量 Trino 查询迁移到 StarRocks 外表+物化视图的查询方式。
芒果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 在贝壳找房的极速统一实践》
中信建投
中信建投在 2019 年搭建了基于 Hadoop 体系的数据湖，将大量历史数据迁移到 Hadoop 上，用 Hive 对数据进行加工处理，所有的查询计算都通过 Presto 执行。但是，该方案在最近两年数据量快速增长、业务场景多样化发展的趋势下逐渐无法适用。具体而言，Presto 在大数据量、多表关联查询时会出现响应比较慢，甚至无法获得查询结果的问题，无法满足单表及多表复杂查询场景下响应的及时性。此外， Presto 因为资源隔离不足会出现应用抢占资源的情况，不能很好支持高并发的查询请求。后来，中信建投选择引入 StarRocks 来构建统一的查询服务平台，满足各部门的用数需求。采用 StarRocks 内部表加速明细数据关联查询，实现了上亿级别数据量大表关联秒级响应， 内表查询效率提升10倍以上，外表查询效率提升1倍以上， 完全满足大数据量下查询分析及时响应的需求。