StarRocks x 金山办公：湖仓架构实现成本与效率的双赢

文章作者：杨宏强资深后端研发工程师，周晓威资深大数据工程师

导读：

在数字化时代，金山办公凭借近 6 亿的月度活跃设备数，正面临日益增长的数据处理挑战。如何提升效率、降低成本成为关键。本文将介绍金山办公如何通过引入 StarRocks 3.0，优化其报表平台，实现技术架构的革新和业务性能的飞跃。从存算一体到存算分离，从多引擎运维到统一平台，StarRocks 3.0 的引入不仅提升了查询效率，还简化了运维流程，为金山办公带来了成本效益和技术优势的双重收益。

金山办公是一家办公软件和服务提供商，主要从事 WPS Office 办公软件产品及服务的设计研发及销售推⼴。产品包括 WPS Office 办公软件、⾦⼭⽂档等协同办公产品、⾦⼭词霸等，可在 Windows、Linux、macOS、Android、iOS 、Harmony 等众多主流操作平台上应⽤。

报表平台早期架构与挑战

报表平台作为公司大数据平台组的核心服务，其架构在早期迭代中引入了 Tez、Spark、Trino、ClickHouse 等多种开源技术，以满足业务需求和应用场景的多样性。然而，随着平台的发展，一些挑战也逐渐显现：

SQL 兼容性 问题：不同计算引擎的 SQL 语法存在差异，用户在配置 SQL 任务时需要根据所使用的计算引擎调整语法或函数。这一操作不仅增加了用户的学习及使用成本，也降低了平台的易用性。
运维成本高昂：维护多个计算集群需要投入大量的精力。特别是 ClickHouse 采用的存算一体模式，其节点的扩缩容过程复杂，进一步推高了运维成本。
资源协调困难：由于各个集群相互独立，计算资源无法实现统一调度，导致资源利用不均衡，部分资源可能处于闲置状态，未能充分发挥其价值。

技术调研与 StarRocks 3.0 的引入

基于“降本增效”的核心理念，我们在对现有技术架构进行全面审视和统一规划后，选择对当前技术架构做调整优化。

在调研的过程中我们发现 StarRocks 3.0 展现出了巨大潜力，这引起了我们极大的兴趣。在调研过程中，我们重点关注了以下几个方面：

存算分离架构

StarRocks 3.0 除了原有的存算一体架构外，支持了存算分离的架构设计，在存储层面兼容 S3 协议的对象存储。在架构设计上，与我们存算分离的优化方向完全一致；在数据存储上，我们的基础数据存放在金山云上，与现有存储策略相契合。

查询效率

我们关注到 StarRocks 在官方公布的 TPC-DS 性能测试中的优异表现，无论是在本地存储还是 Hive 外表查询场景下，其性能均优于当前在用的Trino方案。

在实际调研过程中，我们侧重验证了 StarRocks 数据湖外表查询性能。测试团队基于现有线上任务进行分类抽样，在测试环境 同等资源下进行耗时对比测试，结果显示在整体耗时上 StarRocks 优于现有技术方案，且在大部分场景下耗时更低。

以下为测试报告部分截图:

测试结果：

在本地存储和 Hive 外表查询两个场景上，我们基于线上任务做部分抽样，多轮测试汇总均值后的最终测试结果显示：StarRocks 整体优于现有方案，其查询性能达到了现有方案的 2.3 倍。

迁移成本

StarRocks3.0 版本中增加了 sql_dialect 参数配置，通过将其设置为 'trino'，我们可以在查询中直接使用 Trino 特有的 SQL语法和函数。这为我们将现有的 Trino 任务平滑迁移到 StarRocks 上提供了便捷途径，有望进一步提升查询效率。

在数据接入方面，目前在 ClickHouse 我们主要利用 Kafka 进行数据流的接入，以支持实时的查询和计算需求。StarRocks 则提供了更为灵活的数据模型选择，除了支持通过 RountineLoad 方式接入 Kafka 数据外，也提供了四种数据模型，可满足大部分业务场景，有效替代了当前报表平台中 ClickHouse 所承担的功能。

运维成本

基于存算分离的架构设计，StarRocks 能够将数据存储在兼容 S3 协议的对象存储中（如 AWS S3、OSS、MinIO 等）或 HDFS 中，而将本地盘作为热数据缓存来加速查询。这种设计大大降低了运维成本，尤其是在集群扩缩容时无需考虑本地数据的迁移问题，极大地增强了集群的弹性扩展能力。此外，在节点配置选择上， StarRocks CN 节点的选择可以更着重考虑计算能力的需求，这为我们后续的资源规划和部署提供了更多灵活性。

社区活跃度与生态支持

在技术调研期间，我们积极与 StarRocks 社区成员进行互动和交流。社区对于我们的技术调研给予了高度关注和及时响应，提供了关键的技术支持。特别是在解决 Ks3 与 StarRocks S3 SDK 版本兼容性问题上，社区开发团队给予了迅速而专业的支持，与金山云团队共同协作调试将问题解决。StarRocks 社区的活跃和不断发展的生态也为我们后续的技术合作和持续创新提供了有力保障。

依托调研的结果，StarRocks可以替代我司当前技术架构中的ClickHouse及Trino，在服务维护及计算效率提升上，都有助力。

调研的结果充分显示 StarRocks 可以替代我们技术架构中的 ClickHouse 及 Trino，并且在服务维护及计算效率提升上都将有所助力。基于这些发现，我们开始着手将报表计算、人群与标签等关键业务场景迁移至 StarRocks。

技术实践与业务融合

作为早期采纳存算分离架构的团队之一，我们根据 StarRocks 当时版本的性能特点和我们的业务需求，成功在物理机和 K8S 环境中部署了两套 StarRocks 集群，分别服务于两大业务场景：

StarRocks K8 s 集群：专门用于处理数据湖外部的查询任务，利用 K8s 的弹性和自动化管理优势，优化了资源调度和查询性能。
StarRocks 物理机集群：针对业务需求，通过内表构建数据分层架构，以支持复杂的 OLAP 查询，确保了查询效率和数据的实时性。

报表计算

根据我们测试团队的抽样测试结果，StarRocks 在执行相同批次的线上 SQL 任务时，其耗时普遍低于原有方案。此外，StarRocks 对 Trino 的大部分特有函数都提供了支持，这大大降低了任务迁移的整体难度。

鉴于 StarRocks 社区已将 Helm 部署模式作为生产环境的推荐部署方式，我们迅速在 K8s 环境中上线 StarRocks 集群，并开始了 Trino 任务的迁移工作。截至去年年底，已有近 80% 的任务(12000+ SQL 任务)成功迁移至 StarRocks。

人群与标签

在设计新的标签平台时，我们确立了以下关键需求：

多 数据源 兼容性：确保平台能够无缝接入不同来源的数据。
亿级用户标签处理能力：平台必须能够高效生产和存储亿级用户标签。
高效查询性能：通过 Bitmap 存储类型和相关函数的支持，实现快速查询。
实时场景支持：满足实时数据处理和分析的需求。
便捷的数据导入导出功能：简化数据的迁移和交换过程。

StarRocks 作为一款专注于 One Data, All Analytics （一份数据，全场景使用）理念的数据引擎，可以兼容多种应用场景，并且在存算分离架构下不受数据量的限制。这些特性与我们构建标签平台的需求完美契合，所以我们在构建新标签平台的时候，使用了 StarRocks 作为计算引擎并规划了以下的数据流程。

数据流程说明

在构建新的标签平台时，我们面临了复杂的上游数据源集成挑战，数据来源包括 Hive、业务库、文件上传和 Kafka 等。StarRocks 凭借其数据湖功能和强大的联邦查询能力，为我们提供了高效便捷的数据访问解决方案：

数据源 集成：StarRocks 通过 Catalog 功能简化了对 Hive 和业务数据库的查询；Stream Load 功能使得本地文件能够快速上传至 StarRocks；而 Routine Load 功能则允许我们从 Kafka 实时消费消息。
查询性能：StarRocks 的全面向量化引擎和基于代价的 CBO（Cost-Based Optimizer）优化器显著提升了查询性能，使我们能够在分钟级别完成亿级标签的生产，满足业务需求。
存储优化：我们选择为每个标签存储一张 Bitmap 类型的物理表，这不仅减少了标签间的干扰，还降低了存储成本。Bitmap 函数的配合使用，进一步简化了后续分析场景中的标签和人群运算。
实时处理能力：StarRocks 的 Routine Load 功能支持主键模型，适配了实时数据处理场景。
数据导出：Export 命令提供了便捷的数据导出功能。

基于 StarRocks 计算引擎开发的新标签平台，相较于旧画像平台，在多个关键方面实现了显著提升：

计算效率：标签和人群的计算效率从基于 Hive 的小时级别提升至分钟级别。
时效性：标签的时效性得到增强，支持从纯离线到离线与实时标签的结合。
数据集成：数据集成能力从单一的 Hive 数据源扩展到了包括业务数据库在内的多数据源。
标签分析：标签分析从难以分析的状态转变为适配多种分析主题，提高了数据的可用性和分析深度。

收益

在 StarRocks 集群上线观察期间，线上 SQL 任务总量增加 34%。为应对线上任务增加，集群资源(StarRocks+Trino)随之扩增 23% 。

观察期截止时的数据显示：

StarRocks ： 集群资源 占比 35.8% ，承担 70% 的计算任务
Trino ： 集群资源占 64.2% ，承担 30% 的计算任务
在查询性能上： 大部份场景 StarRocks 平均耗时仅有 Trino 的 1/2

总体来看，StarRocks以较低的资源消耗和成本承担了更多的任务量，同时提供了更优质的查询体验。在上线观察期间，StarRocks从查询效率、计算资源、架构升级上都带来了明显的收益。

与单纯扩展 Trino 相比，StarRocks 的引入带来了以下优势：

提升了用户的查询体验，提供了更快的查询返回。
通过更高效的执行效率缓解了集群居高不下的资源占用，甚至有一定空闲资源可承载更多的计算任务。
对平台来说，灵活的扩缩容能力不仅能够更好的应对业务挑战，也能降低运维压力。

查询效率提升

依照采样对比，迁移后的计算任务得到 48.84% 的提升。原有方案的平均耗时是 StarRocks 的 2 倍。

报表平台任务排队减少

在报表计算上，在迁移至 StarRocks 之前，Trino 集群会在报表集中的某几个时间段满负荷运行，报表任务排队时间较长，导致报表整体执行时间延长；迁移到 StarRocks 之后，我们观察到集群在空闲或非满载时段的资源利用率有所提高，这直接促进了报表执行效率的提升，并显著减少了任务排队现象。

迁移前

迁移后

集群资源富余增加

迁移后，StarRocks K8s 集群资源空闲或非满载时间段增长，从而能够接入更多计算任务。

架构简化

部署 StarRocks 集群后，我们显著提升了人群与标签业务的查询效率，确保了新标签平台项目按计划顺利推进。StarRocks 不仅满足了关键的查询性能需求，还展现出了在其他业务场景中的潜力。

目前，我们的团队使用 ClickHouse 集群来处理 Kafka 数据的实时消费和执行 OLAP 查询任务。StarRocks 同样具备处理这两项任务的能力，并且在运维成本方面，StarRocks 展现出了比 ClickHouse 更低的优势。

综合来看，StarRocks 完全能够覆盖我们在 Trino 和 ClickHouse 上的业务需求，它不仅简化了我们的技术架构，还降低了运维成本。

成本下降

在成本方面，相较于原有集群存算一体的模式，存算分离后可以让数据存储在成本更低的云端，整体成本下降，且无需顾虑存储上限。

在集群维护方面，由于 CN 节点不承担数据存储任务，扩缩容过程变得更加简洁，无需考虑节点上的数据迁移或平衡问题。这允许我们在服务器配置选择上更加专注于计算性能的优化。同时，当前的架构支持服务的容器化部署，这进一步降低了运维的复杂性和成本。

未来规划

展望未来，我们对 StarRocks 充满了无限的期待。在最近版本中，StarRocks 已支持 Multi-Warehouse 功能，实现物理资源隔离。这一新增功能将为我们带来更多的便利与可能。我们可以将 ETL、OLAP、Routine Load 等计算场景进行隔离，互不干扰，从而提升资源的利用率和计算效率。我们计划将现有物理机集群逐步合并至 K8s 集群里，实现单个服务的支持。这一举措将大大降低我们的组件维护成本，提升服务的稳定性与可靠性。在 StarRocks 的助力下，我们相信未来的大数据平台将更加高效、灵活与强大。

更多交流，联系我们： https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/2b42f