作者:杨宏强 金山办公资深后端研发工程师，周晓威 金山办公资深大数据工程师
小编导读：
迁移后，计算任务性能提升了 48.84%，耗时缩短至原有方案的一半。同时，StarRocks 在空闲时段的资源利用率提高，报表执行效率和任务处理能力显著改善。
金山办公是一家办公软件和服务提供商，主要从事 WPS Office 办公软件产品及服务的设计研发及销售推⼴。产品包括 WPS Office 办公软件、⾦⼭⽂档等协同办公产品、⾦⼭词霸等，可在 Windows、Linux、macOS、Android、iOS 、Harmony 等众多主流操作平台上应⽤。
报表平台作为公司大数据平台组的核心服务，其架构在早期迭代中引入了 Tez、Spark、Trino、ClickHouse 等多种开源技术，以满足业务需求和应用场景的多样性。然而，随着平台的发展，一些挑战也逐渐显现：
SQL 兼容性问题：不同计算引擎的 SQL 语法存在差异，用户在配置 SQL 任务时需要根据所使用的计算引擎调整语法或函数。这一操作不仅增加了用户的学习及使用成本，也降低了平台的易用性。 运维成本高昂：维护多个计算集群需要投入大量的精力。特别是 ClickHouse 采用的存算一体模式，其节点的扩缩容过程复杂，进一步推高了运维成本。 资源协调困难：由于各个集群相互独立，计算资源无法实现统一调度，导致资源利用不均衡，部分资源可能处于闲置状态，未能充分发挥其价值。
基于“降本增效”的核心理念，我们在对现有技术架构进行全面审视和统一规划后，选择对当前技术架构做调整优化。
在调研的过程中我们发现 StarRocks 3.0 展现出了巨大潜力，这引起了我们极大的兴趣。在调研过程中，我们重点关注了以下几个方面：
存算分离架构
存算分离架构
查询效率
查询效率
在实际调研过程中，我们侧重验证了 StarRocks 数据湖外表查询性能。测试团队基于现有线上任务进行分类抽样，在测试环境同等资源下进行耗时对比测试，结果显示在整体耗时上 StarRocks 优于现有技术方案，且在大部分场景下耗时更低。
以下为测试报告部分截图:
测试结果：
在本地存储和 Hive 外表查询两个场景上，我们基于线上任务做部分抽样，多轮测试汇总均值后的最终测试结果显示：StarRocks 整体优于现有方案，其查询性能达到了现有方案的 2.3 倍。
迁移成本
迁移成本
在数据接入方面， 目前在 ClickHouse 我们主要利用 Kafka 进行数据流的接入，以支持实时的查询和计算需求。StarRocks 则提供了更为灵活的数据模型选择，除了支持通过 RountineLoad 方式接入 Kafka 数据外，也提供了四种数据模型，可满足大部分业务场景，有效替代了当前报表平台中 ClickHouse 所承担的功能。
运维成本
运维成本
社区活跃度与生态支持
社区活跃度与生态支持
调研的结果充分显示 StarRocks 可以替代我们技术架构中的 ClickHouse 及 Trino，并且在服务维护及计算效率提升上都将有所助力。基于这些发现，我们开始着手将报表计算、人群与标签等关键业务场景迁移至 StarRocks。
作为早期采纳存算分离架构的团队之一，我们根据 StarRocks 当时版本的性能特点和我们的业务需求，成功在物理机和 K8s 环境中部署了两套 StarRocks 集群，分别服务于两大业务场景：
StarRocks K8s 集群：专门用于处理数据湖外部的查询任务，利用 K8s 的弹性和自动化管理优势，优化了资源调度和查询性能。 StarRocks 物理机集群：针对业务需求，通过内表构建数据分层架构，以支持复杂的 OLAP 查询，确保了查询效率和数据的实时性。
报表计算
报表计算
鉴于 StarRocks 社区已将 Helm 部署模式作为生产环境的推荐部署方式，我们迅速在 K8s 环境中上线 StarRocks 集群，并开始了 Trino 任务的迁移工作。截至去年年底，已有近 80% 的任务(12000+ SQL 任务)成功迁移至 StarRocks。
人群与标签
人群与标签
多数据源兼容性：确保平台能够无缝接入不同来源的数据。 亿级用户标签处理能力：平台必须能够高效生产和存储亿级用户标签。 高效查询性能：通过 Bitmap 存储类型和相关函数的支持，实现快速查询。 实时场景支持：满足实时数据处理和分析的需求。 便捷的数据导入导出功能：简化数据的迁移和交换过程。
数据流程说明
在构建新的标签平台时，我们面临了复杂的上游数据源集成挑战，数据来源包括 Hive、业务库、文件上传和 Kafka 等。StarRocks 凭借其数据湖功能和强大的联邦查询能力，为我们提供了高效便捷的数据访问解决方案：
数据源集成：StarRocks 通过 Catalog 功能简化了对 Hive 和业务数据库的查询；Stream Load 功能使得本地文件能够快速上传至 StarRocks；而 Routine Load 功能则允许我们从 Kafka 实时消费消息。 查询性能：StarRocks 的全面向量化引擎和基于代价的 CBO（Cost-Based Optimizer）优化器显著提升了查询性能，使我们能够在分钟级别完成亿级标签的生产，满足业务需求。 存储优化：我们选择为每个标签存储一张 Bitmap 类型的物理表，这不仅减少了标签间的干扰，还降低了存储成本。Bitmap 函数的配合使用，进一步简化了后续分析场景中的标签和人群运算。 实时处理能力：StarRocks 的 Routine Load 功能支持主键模型，适配了实时数据处理场景。 数据导出：Export 命令提供了便捷的数据导出功能。
计算效率：标签和人群的计算效率从基于 Hive 的小时级别提升至分钟级别。 时效性：标签的时效性得到增强，支持从纯离线到离线与实时标签的结合。 数据集成：数据集成能力从单一的 Hive 数据源扩展到了包括业务数据库在内的多数据源。 标签分析：标签分析从难以分析的状态转变为适配多种分析主题，提高了数据的可用性和分析深度。
在 StarRocks 集群上线观察期间，线上 SQL 任务总量增加 34%。为应对线上任务增加，集群资源(StarRocks+Trino)随之扩增 23% 。
观察期截止时的数据显示：
StarRocks：集群资源占比 35.8%，承担 70% 的计算任务 Trino：集群资源占 64.2%，承担 30% 的计算任务 在查询性能上：大部份场景 StarRocks 平均耗时仅有 Trino 的 1/2
与单纯扩展 Trino 相比，StarRocks 的引入带来了以下优势：
提升了用户的查询体验，提供了更快的查询返回。 通过更高效的执行效率缓解了集群居高不下的资源占用，甚至有一定空闲资源可承载更多的计算任务。 对平台来说，灵活的扩缩容能力不仅能够更好的应对业务挑战，也能降低运维压力。
查询效率提升
查询效率提升
报表平台任务排队减少
报表平台任务排队减少
（迁移前）
（迁移后）
集群资源富余增加
集群资源富余增加
架构简化
架构简化
目前，我们的团队使用 ClickHouse 集群来处理 Kafka 数据的实时消费和执行 OLAP 查询任务。StarRocks 同样具备处理这两项任务的能力，并且在运维成本方面，StarRocks 展现出了比 ClickHouse 更低的优势。
综合来看，StarRocks 完全能够覆盖我们在 Trino 和 ClickHouse 上的业务需求，它不仅简化了我们的技术架构，还降低了运维成本。
成本下降
成本下降
在集群维护方面，由于 CN 节点不承担数据存储任务，扩缩容过程变得更加简洁，无需考虑节点上的数据迁移或平衡问题。这允许我们在服务器配置选择上更加专注于计算性能的优化。同时，当前的架构支持服务的容器化部署，这进一步降低了运维的复杂性和成本。
展望未来，我们对 StarRocks 充满了无限的期待。在最近版本中，StarRocks 已支持 Multi-Warehouse 功能，实现物理资源隔离。这一新增功能将为我们带来更多的便利与可能。我们可以将 ETL、OLAP、Routine Load 等计算场景进行隔离，互不干扰，从而提升资源的利用率和计算效率。我们计划将现有物理机集群逐步合并至 K8s 集群里，实现单个服务的支持。这一举措将大大降低我们的组件维护成本，提升服务的稳定性与可靠性。在 StarRocks 的助力下，我们相信未来的大数据平台将更加高效、灵活与强大。
关于 StarRocks
Linux 基金会项目 StarRocks 是新一代极速全场景 MPP 数据库，遵循 Apache 2.0 开源协议。
StarRocks 全球开源社区也正飞速成长。目前，StarRocks 的 GitHub star 数已达 8400，吸引了超过 350 位贡献者和数十家国内外行业头部企业参与共建，用户社区也有过万人的规模。凭借其卓越的表现，StarRocks 荣获了全球著名科技媒体 InfoWorld 颁发的 2023 BOSSIE Award 最佳开源软件奖项。
