共计 4667 个字符，预计需要花费 12 分钟才能阅读完成。
小编导读：
万物新生成立于 2011 年，定位为“互联网 + 环保”类型的循环经济企业，是中国最大的二手电子产品交易与服务平台。万物新生团体旗下 4 大业务线蕴含：爱回收、拍机堂、拍拍、海内业务 AHS Device。万物新生团体秉承“让闲置不用，都物尽其用”的使命，致力于打造 ESG (即“环境、社会和治理”) 样本企业，将社会责任融入到商业实际中。
在经验了 MySQL、Greenplum、Trino 等多种架构之后，为了在不进行扩容的前提下进一步加强用户的查问体验，并进步整个服务的性价比，万物新生引入了 StarRocks。目前，StarRocks 的利用次要集中在 Watcher 报表平台上，该平台负责承载万物新生团体外部的所有报表业务，涵盖了爱回收、拍机堂、拍拍、以及海内业务 AHS Device 等业务畛域。每天，Watcher 平台须要应答几十万的查问申请。引入 StarRocks 之后，性能晋升了 3 -10 倍。
一、剖析更极速、架构更简略，万物新生的选型之路
随着数据量和剖析需要的一直减少，万物新生团体的计算引擎也适应大数据技术倒退的潮流，经验了从 MySQL 到 Greenplum 到 Hadoop 生态的变迁，并基于 Hive 构建了数据仓库。
在 OLAP 查问引擎的抉择上，因为业务剖析需要十分旺盛、灵便多变，查问甚至笼罩数仓内超过 50% 的数据，因而咱们心愿可能在保障灵活性的前提下最大水平晋升用户的查问性能和体验。通常，业界的 OLAP 查问计划有两种：
分层治之：剖析数据出仓减速
将剖析数据灌入独立的数据库是业界利用最广的减速计划。然而，因为灵便的查问个性，咱们将会须要保护大量冗余数据，并须要保护导入工作、数据一致性查看等，造成大量机器和人力节约。
合而一统：高效引擎直查 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 查问，并在雷同配置的服务器上进行了理论试验。
后果如下：
注：图表中为整体查问耗时，曾经刨除查问失败的局部。
在性能上，咱们得出了以下论断：
- 对于非常复杂的大查问，StarRocks 在查问成功率方面优于 Trino。在串行测试中，有 8 个查问在 Trino 中因内存超限而出错，而在 StarRocks 中能够胜利执行。随着并发查问量减少，StarRocks 的查问成功率逐步升高，这与咱们的预期相符。
- 总体而言，StarRocks 的查问性能整体优于 Trino。 在串行测试中，StarRocks 的性能是 Trino 的 6.77 倍，在 10 并行测试中是 Trino 的 10.96 倍，在 20 并行测试中是 Trino 的 16.03 倍。
综上所述，咱们综合思考各方面因素，抉择了 StarRocks，次要基于以下几点思考：
- 人造高可用：与 Trino 的主从模式相比，StarRocks 通过多个 FE 和多 BE 的设计实现了查问打算生成、元数据管理和数据计算的高可用性，从而显著晋升了整个集群的可用性。
- 开箱即用：StarRocks 的查问操作简略，无需额定配置。只需一个 SQL 查问语句，即可创立 Catalog 并间接对 Hive 中的数据进行查问。
- 简单查问的优化能力：StarRocks 的向量化引擎以及 CBO 优化器使简单查问可能更高效疾速地执行。此外，StarRocks 针对 Hive 查问进行了多项优化，如 I/O 合并、谓词下推等，进一步晋升了查问效率。
- 多表关联能力：StarRocks 的多表关联性能十分优良，这与 Watcher 平台灵便的查问场景十分符合。即使是 5-6 个表进行关联查问也能够轻松应答。
- 迁徙过程简略：因为 StarRocks 反对 Trino 方言模式，迁徙过程中的报表革新老本较低，使得零碎的过渡能够更加迅速和安稳进行。
四、迁徙过程
- 通过设置 session/global 变量，如 set sql_dialect =’trino’;，即可轻松地将 SQL 方言设置为 Trino。因为高度的 SQL 兼容性，咱们可能顺利地将绝大多数本来在 Trino 查问引擎上的 SQL 间接迁徙到 StarRocks，从而优化了迁徙过程，节俭了工夫和资源。同时，咱们保留了 Trino 作为备用引擎，以备 StarRocks 异常情况下的应急应用，确保业务继续运行并升高了迁徙所带来的危险。后续咱们会建设 StarRocks 的主备集群来晋升整个服务的健壮性。
- 通过引入 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。同时，咱们也会继续关注社区的动静，并且着重关注以下几个方向：
- 存算拆散：存算拆散模式下，能够通过计算节点疾速地弹性扩缩容来更好高空对业务的波峰与波谷，尤其是在重大流动期间应答忽然减少的数据分析需要。
- 反对 Hive 写入，算子落盘欠缺跑批能力：StarRocks 在 3.1 版本中曾经反对了 Iceberg 的写入能力，并且最近社区也开始反对 Hive 的写入能力。联合算子落盘性能，置信将来 StarRocks 能够欠缺整个湖仓一体的能力架构，以反对更多计算剖析场景。
- Data Cache：只管目前线上环境尚未启用 Data Cache，但社区中的许多用户曾经在开启 Cache 的状况下取得了更好的性能。将来 Data Cache 还将具备黑白名单的能力，能够指定库、表、分区，确保重要数据不受缓存淘汰的影响。
- Apache Ranger 对接：近期社区正在筹备官网的 Apache Ranger Plugin，该插件不仅能够用于治理 StarRocks 外部表的权限，还能够间接复用湖上已有的权限服务来治理内部表的权限，这是一个备受期待的性能。
💬 StarRocks Feature Groups：
扫描下方二维码，进入 StarRocks 湖仓剖析用户小组！
本文由 mdnice 多平台公布
