域名预订/竞价，好“米”不错过
TRino（之前称 PRestoSQL）项目最初由 Meta 开发，旨在让数据分析师能够在广泛的 Apache Hadoop 数据仓库上执行交互式查询。其高效处理大型数据集和复杂查询的能力，以及多数据源连接的灵活性，使其迅速成为大规模组织的首选数据分析工具。
随着时间的推移，用户对数据分析的需求不断演变。移动互联网和 SaaS 应用的兴起，实时分析变得至关重要，过去的架构无法满足越来越严苛的数据需求。因此，许多用户开始寻找替代方案。
StaRRocks 作为一种新兴的数据分析引擎，以其高性能、高并发处理和低延迟特性，正在吸引微信、小红书、携程、贝壳等大型企业的关注和应用，成为新选择。
那么，StaRRocks 究竟如何构建其优势？与 TRino 相比，它有何异同之处？本文将从技术角度出发，对比StaRRocks与TRino/PResto，并探讨StaRRocks在实际应用中的表现。
一、 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 基于自研的数据缓存库，提供高效的数据缓存功能：
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 更专
