小编导读:
万物新生成立于2011年,定位为“互联网+环保”类型的循环经济企业,是中国最大的二手电子产品交易与服务平台。万物新生集团旗下4大业务线包含:爱回收、拍机堂、拍拍、海外业务 AHS Device。万物新生集团秉承“让闲置不用,都物尽其用”的使命,致力于打造 ESG (即“环境、社会和治理”) 样本企业,将社会责任融入到商业实践中。
在经历了 MySQL、Greenplum、Trino 等多种架构之后,为了在不进行扩容的前提下进一步增强用户的查询体验,并提高整个服务的性价比,万物新生引入了 StarRocks。目前,StarRocks 的应用主要集中在 Watcher 报表平台上,该平台负责承载万物新生集团内部的所有报表业务,涵盖了爱回收、拍机堂、拍拍、以及海外业务 AHS Device 等业务领域。每天,Watcher 平台需要应对几十万的查询请求。引入 StarRocks 之后,性能提升了3-10倍。
随着数据量和分析需求的不断增加,万物新生集团的计算引擎也顺应大数据技术发展的潮流,经历了从 MySQL 到 Greenplum 到 Hadoop 生态的变迁,并基于 Hive 构建了数据仓库。
在 OLAP 查询引擎的选择上,由于业务分析需求非常旺盛、灵活多变,查询甚至覆盖数仓内超过 50% 的数据,因此我们希望能够在保证灵活性的前提下最大程度提升用户的查询性能和体验。通常,业界的 OLAP 查询方案有两种:
将分析数据灌入独立的数据库是业界应用最广的加速方案。然而,由于灵活的查询特性,我们将会需要维护大量冗余数据,并需要维护导入任务、数据一致性检查等,造成大量机器和人力浪费。
直接查询虽然模式简单,节省了存储成本,但对查询引擎的性能提出了非常高的要求。在最初,我们引入了 Trino,利用其在交互式查询和复杂查询方面的优势为用户的数仓查询加速。Trino 的引入显著提升了查询响应速度和用户体验。
不过,还有没有更快、性价比更高的方式呢?我们开始在不扩容的前提下进一步调研提速方案。今年年初,我们接触到了 StarRocks。StarRocks 一直致力于将 Hive 外表直查性能逼近内表,为用户提供极速统一的数据分析体验。这也与我们的测试结果相符,在不导入数据的情况下,StarRocks 相较于 Trino 有数倍的性能提升。
因此我们决定引入 StarRocks 来对 Hive 数据进行直接加速查询。整个迁移过程非常丝滑。引入 StarRocks 后,我们在计算节点数量降低一半的情况下,将查询性能提升了3-10 倍,大大提升了整个集群的性价比。StarRocks的出现让我们更加坚信,数据架构的未来一定会朝着更加简单、优雅的方向发展。
Watcher 平台承载了万物新生集团内部所有报表业务,包含爱回收、拍机堂、拍拍、海外业务 AHS Device,每天需要响应几十万的查询请求。
Watcher 报表平台主要涵盖以下类型的报表:
固定报表:
固定报表通过预先加工完毕的 ADS 层数据在 Hive 内进行呈现。每张报表会包含多个模块,每个模块的计算逻辑由视图(view)进行封装。这些计算通常涉及多个 ADS 层表的关联查询。当报表页面刷新时,系统会根据用户的浏览速度向报表内不同模块对应的视图发起查询请求。
多维度筛选报表:
相对于固定报表,多维度筛选报表提供更大的灵活性。用户可以根据多个维度(如城市、区域、业务线)进行筛选,并能够进行指标的上卷和下钻操作。在这个类别中,我们还特别设计了细粒度的行列权限控制。当用户访问报表时,除了原有业务逻辑计算上,还需要与一张用户权限 mapping 表关联,以判断用户是否有权访问特定内容。因此,整体的计算逻辑变得更加复杂。
从上述的业务需求可以看出,Watcher 报表平台面临了诸多挑战:
在万物新生的内部,Trino 已经稳定运行了一年多的时间。引入 Trino 后,用户的查询体验和响应速度得到了显著提升。然而,若要进一步提升性能,必须考虑进行扩容。为了在降低成本的同时实现更高效的数据处理,我们进行了StarRocks 的调研和评估。
我们先在 TPC-DS 500G 标准测试集上对 StarRocks 的性能进行了初步验证。
注:图表中为整体查询耗时。
我们首先对同等数量的服务器进行了 Trino 和 StarRocks 的性能比较,如上图所示,结果显示 StarRocks 的整体性能大约是 Trino 的 4 倍。 随后,我们将 StarRocks 的 BE 节点数量减少到原先的 1/3,仍然发现 StarRocks 的性能仍然是 Trino 的大约 1.5 倍。
因此,我们深信通过采用 StarRocks 可以成功实现降低成本并提升效率的目标。
尽管在 TPC-DS 测试中取得了出色的结果,但考虑到我们的查询相对复杂,为了验证在真实业务场景中的实际效果,我们选择了 100 个典型业务 SQL 查询,并在相同配置的服务器上进行了实际试验。
结果如下:
注:图表中为整体查询耗时,已经刨除查询失败的部分。
在性能上,我们得出了以下结论:
综上所述,我们综合考虑各方面因素,选择了 StarRocks,主要基于以下几点考虑:
截至 8 月中旬,我们已成功将 StarRocks 3.1 版本成功部署在集团的 Watcher 报表平台上,上线了 20 个 BE 节点,这些节点替代了大约 40 个之前的 Trino 节点。现阶段,StarRocks 已经承担了线上 60% 的查询流量。报表的迁移工作仍在持续进行中。目前线上的性能结果如下:
暂时无法在飞书文档外展示此内容
注:这里是没有开启 Data Cache 的结果。
引入 StarRocks 后,尽管我们将计算节点数量减少了一半,但仍然有 94% 的查询在性能方面获得了提升。其中,近 80% 的查询性能提升幅度在 5 倍到 10 倍之间。
通过 StarRocks 强大的查询性能,Watcher 平台为业务提供了更加清晰和准确的数据支持。这不仅增强了业务对数据的理解和深入洞察,还加速了业务决策的过程,提升了团队的工作效率。通过有效的数据分析和决策支持,Watcher 报表平台为集团带来了更高的业务价值和竞争优势。
鉴于 StarRocks 在线上的优异表现,未来,我们计划逐步将查询层的流量全部迁移至 StarRocks。同时,我们也会持续关注社区的动态,并且着重关注以下几个方向:
StarRocks Feature Groups:
关注 StarRocks 公众号,进入 StarRocks 湖仓分析用户小组!