小编导读：

万物新生成立于2011年，定位为“互联网+环保”类型的循环经济企业，是中国最大的二手电子产品交易与服务平台。万物新生集团旗下4大业务线包含：爱回收、拍机堂、拍拍、海外业务 AHS Device。万物新生集团秉承“让闲置不用，都物尽其用”的使命，致力于打造 ESG (即“环境、社会和治理”) 样本企业，将社会责任融入到商业实践中。

在经历了 MySQL、Greenplum、Trino 等多种架构之后，为了在不进行扩容的前提下进一步增强用户的查询体验，并提高整个服务的性价比，万物新生引入了 StarRocks。目前，StarRocks 的应用主要集中在 Watcher 报表平台上，该平台负责承载万物新生集团内部的所有报表业务，涵盖了爱回收、拍机堂、拍拍、以及海外业务 AHS Device 等业务领域。每天，Watcher 平台需要应对几十万的查询请求。引入 StarRocks 之后，性能提升了3-10倍。

一 、分析更极速、架构更简单，万物新生的选型之路

随着数据量和分析需求的不断增加，万物新生集团的计算引擎也顺应大数据技术发展的潮流，经历了从 MySQL 到 Greenplum 到 Hadoop 生态的变迁，并基于 Hive 构建了数据仓库。

在 OLAP 查询引擎的选择上，由于业务分析需求非常旺盛、灵活多变，查询甚至覆盖数仓内超过 50% 的数据，因此我们希望能够在保证灵活性的前提下最大程度提升用户的查询性能和体验。通常，业界的 OLAP 查询方案有两种：

1. 分层治之：分析数据出仓加速

将分析数据灌入独立的数据库是业界应用最广的加速方案。然而，由于灵活的查询特性，我们将会需要维护大量冗余数据，并需要维护导入任务、数据一致性检查等，造成大量机器和人力浪费。

2. 合而一统：高效引擎直查 Hive

直接查询虽然模式简单，节省了存储成本，但对查询引擎的性能提出了非常高的要求。在最初，我们引入了 Trino，利用其在交互式查询和复杂查询方面的优势为用户的数仓查询加速。Trino 的引入显著提升了查询响应速度和用户体验。

不过，还有没有更快、性价比更高的方式呢？我们开始在不扩容的前提下进一步调研提速方案。今年年初，我们接触到了 StarRocks。StarRocks 一直致力于将 Hive 外表直查性能逼近内表，为用户提供极速统一的数据分析体验。这也与我们的测试结果相符，在不导入数据的情况下，StarRocks 相较于 Trino 有数倍的性能提升。

因此我们决定引入 StarRocks 来对 Hive 数据进行直接加速查询。整个迁移过程非常丝滑。引入 StarRocks 后，我们在计算节点数量降低一半的情况下，将查询性能提升了3-10 倍，大大提升了整个集群的性价比。StarRocks的出现让我们更加坚信，数据架构的未来一定会朝着更加简单、优雅的方向发展。

二、Watcher 报表平台的业务挑战

Watcher 平台承载了万物新生集团内部所有报表业务，包含爱回收、拍机堂、拍拍、海外业务 AHS Device，每天需要响应几十万的查询请求。

Watcher 报表平台主要涵盖以下类型的报表：

• 固定报表：

  固定报表通过预先加工完毕的 ADS 层数据在 Hive 内进行呈现。每张报表会包含多个模块，每个模块的计算逻辑由视图（view）进行封装。这些计算通常涉及多个 ADS 层表的关联查询。当报表页面刷新时，系统会根据用户的浏览速度向报表内不同模块对应的视图发起查询请求。

• 多维度筛选报表：

  相对于固定报表，多维度筛选报表提供更大的灵活性。用户可以根据多个维度（如城市、区域、业务线）进行筛选，并能够进行指标的上卷和下钻操作。在这个类别中，我们还特别设计了细粒度的行列权限控制。当用户访问报表时，除了原有业务逻辑计算上，还需要与一张用户权限 mapping 表关联，以判断用户是否有权访问特定内容。因此，整体的计算逻辑变得更加复杂。

从上述的业务需求可以看出，Watcher 报表平台面临了诸多挑战：

• 面向大规模数据： 随着集团业务的不断扩张，业务数据量也在不断增长，整个报表流程需要处理海量数据。这对数据的存储、处理以及查询都提出了更高要求。
• 灵活的筛选条件： 平台支持的查询方式多样、灵活，允许按多种维度和时间范围进行数据的筛选、上卷以及下钻。这种灵活性给数据查询和处理带来了复杂性，查询引擎需要能够高效地处理各种组合的筛选条件，并实时生成准确的查询结果。
• 复杂的 SQL 查询：无论是固定报表还是自助查询，实际发给查询引擎的 SQL 通常比较复杂。涉及多表关联、子查询、聚合等复杂操作。在 Watcher 平台上，5-6 个表进行关联查询、生成上百行的 SQL 是很常见的操作。因此需要查询引擎能够高效地处理这类请求。
• 高并发、低延迟性能要求： 在报表分析场景下，用户对查询响应的要求通常比较高，希望能够实时获取查询结果。特别是在高峰时期，可能会有大量并发查询请求，QPS 峰值达到 200+。需要查询引擎具备高并发处理能力，以保证查询的实时响应性能。

三、为什么选择 StarRocks？

在万物新生的内部，Trino 已经稳定运行了一年多的时间。引入 Trino 后，用户的查询体验和响应速度得到了显著提升。然而，若要进一步提升性能，必须考虑进行扩容。为了在降低成本的同时实现更高效的数据处理，我们进行了StarRocks 的调研和评估。

TPC-DS 初步验证

我们先在 TPC-DS 500G 标准测试集上对 StarRocks 的性能进行了初步验证。

• 版本：Trino403，StarRocks 2.4.1
• 测试方式：机器配置相同的情况下完整测试三次，取三次的平均延时。分别测试 10、20、30 并行提交的场景。测试过程中 Trino 和 StarRocks 查询的均为 Hive 上的同一份数据，均未开启本地缓存。

注：图表中为整体查询耗时。

我们首先对同等数量的服务器进行了 Trino 和 StarRocks 的性能比较，如上图所示，结果显示 StarRocks 的整体性能大约是 Trino 的 4 倍。 随后，我们将 StarRocks 的 BE 节点数量减少到原先的 1/3，仍然发现 StarRocks 的性能仍然是 Trino 的大约 1.5 倍。

因此，我们深信通过采用 StarRocks 可以成功实现降低成本并提升效率的目标。

真实业务查询验证

尽管在 TPC-DS 测试中取得了出色的结果，但考虑到我们的查询相对复杂，为了验证在真实业务场景中的实际效果，我们选择了 100 个典型业务 SQL 查询，并在相同配置的服务器上进行了实际试验。

结果如下：

注：图表中为整体查询耗时，已经刨除查询失败的部分。

在性能上，我们得出了以下结论：

1. 对于非常复杂的大查询，StarRocks 在查询成功率方面优于 Trino。在串行测试中，有 8 个查询在 Trino 中因内存超限而出错，而在 StarRocks 中可以成功执行。随着并发查询量增加，StarRocks 的查询成功率逐渐降低，这与我们的预期相符。
2. 总体而言，StarRocks 的查询性能整体优于 Trino。在串行测试中，StarRocks 的性能是 Trino 的 6.77 倍，在 10 并行测试中是 Trino 的 10.96 倍，在 20 并行测试中是 Trino 的 16.03 倍。

综上所述，我们综合考虑各方面因素，选择了 StarRocks，主要基于以下几点考虑：

1. 天然高可用：与 Trino 的主从模式相比，StarRocks 通过多个 FE 和多 BE 的设计实现了查询计划生成、元数据管理和数据计算的高可用性，从而显著提升了整个集群的可用性。
2. 开箱即用：StarRocks 的查询操作简单，无需额外配置。只需一个 SQL 查询语句，即可创建 Catalog 并直接对 Hive 中的数据进行查询。
3. 复杂查询的优化能力：StarRocks 的向量化引擎以及 CBO 优化器使复杂查询能够更高效快速地执行。此外，StarRocks 针对 Hive 查询进行了多项优化，如 I/O 合并、谓词下推等，进一步提升了查询效率。
4. 多表关联能力：StarRocks 的多表关联性能非常优秀，这与 Watcher 平台灵活的查询场景非常契合。即便是 5-6 个表进行关联查询也可以轻松应对。
5. 迁移过程简单：由于 StarRocks 支持 Trino 方言模式，迁移过程中的报表改造成本较低，使得系统的过渡可以更加迅速和平稳进行。

四、迁移过程

1. 通过设置 session/global 变量 ，如set sql_dialect =‘trino’;，即可轻松地将 SQL 方言设置为 Trino。由于高度的 SQL 兼容性，我们能够顺利地将绝大多数原本在 Trino 查询引擎上的 SQL 直接迁移到 StarRocks ，从而优化了迁移过程，节省了时间和资源。同时，我们保留了 Trino 作为备用引擎，以备 StarRocks 异常情况下的应急使用，确保业务持续运行并降低了迁移所带来的风险。后续我们会建设 StarRocks 的主备集群来提升整个服务的健壮性。
2. 通过引入 Apache Ranger 组件的支持，我们实现了数据权限的统一管理，确保数据的安全性和合规性。这将为业务提供更可靠的数据访问控制和更高层次的数据安全保障。同时，在数据分析和查询的过程中，对数据权限的管理也变得更加灵活和细致，提升了数据使用的效率和准确性。

五、线上效果验收，StarRocks 极速查询不止于 Benchmark

截至 8 月中旬，我们已成功将 StarRocks 3.1 版本成功部署在集团的 Watcher 报表平台上，上线了 20 个 BE 节点,这些节点替代了大约 40 个之前的 Trino 节点。现阶段，StarRocks 已经承担了线上 60% 的查询流量。报表的迁移工作仍在持续进行中。目前线上的性能结果如下：
暂时无法在飞书文档外展示此内容

注：这里是没有开启 Data Cache 的结果。

引入 StarRocks 后，尽管我们将计算节点数量减少了一半，但仍然有 94% 的查询在性能方面获得了提升。其中，近 80% 的查询性能提升幅度在 5 倍到 10 倍之间。

通过 StarRocks 强大的查询性能，Watcher 平台为业务提供了更加清晰和准确的数据支持。这不仅增强了业务对数据的理解和深入洞察，还加速了业务决策的过程，提升了团队的工作效率。通过有效的数据分析和决策支持，Watcher 报表平台为集团带来了更高的业务价值和竞争优势。

六、未来展望

鉴于 StarRocks 在线上的优异表现，未来，我们计划逐步将查询层的流量全部迁移至 StarRocks。同时，我们也会持续关注社区的动态，并且着重关注以下几个方向：

1. 存算分离：存算分离模式下，可以通过计算节点快速地弹性扩缩容来更好地面对业务的波峰与波谷，尤其是在重大活动期间应对突然增加的数据分析需求。
2. 支持 Hive 写入，算子落盘完善跑批能力：StarRocks 在 3.1 版本中已经支持了 Iceberg 的写入能力，并且最近社区也开始支持 Hive 的写入能力。结合算子落盘功能，相信未来 StarRocks 可以完善整个湖仓一体的能力架构，以支持更多计算分析场景。
3. Data Cache：尽管目前线上环境尚未启用 Data Cache，但社区中的许多用户已经在开启 Cache 的情况下获得了更好的性能。未来 Data Cache 还将具备黑白名单的能力，可以指定库、表、分区，确保重要数据不受缓存淘汰的影响。
4. Apache Ranger 对接：近期社区正在筹备官方的 Apache Ranger Plugin，该插件不仅可以用于管理 StarRocks 内部表的权限，还可以直接复用湖上已有的权限服务来管理外部表的权限，这是一个备受期待的功能。

💬 StarRocks Feature Groups：
关注 StarRocks 公众号，进入 StarRocks 湖仓分析用户小组！