韩国互联网巨头 NAVER 如何借助 StarRocks 实现实时数据洞察

作者：

Youngjin Kim Team Leader, NAVER

Moweon Lee Data Engineer, NAVER

导读：开源无国界，在“StarRocks 全球用户精选案例”专栏中，我们将介绍韩国互联网巨头 NAVER 的 StarRocks 实践案例。 NAVER 成立于 1999 年，是著名社交软件 LINE 的母公司，世界第五大搜索引擎网站 ，也是韩国最大的搜索引擎和门户网站、韩国市值最高的互联网公司。业务遍布韩国、日本、中国台湾及东南亚 。 从 ClickHouse 迁移至 StarRocks 后，NAVER 在多表 JOIN 处理上取得了显著优化。StarRocks 提升了查询性能，实现无缝扩展，并构建了统一查询平台，兼容多种数据源。这些改进让 NAVER 能够提供实时洞察，支持其生态系统中的数据驱动决策。

作为 NAVER 的数据平台团队，我们为韩国领先的门户网站提供分析支持。NAVER 支持着超过 200 个互联服务的生态系统，包括搜索、电商、媒体以及人工智能驱动的应用。随着平台在韩国的普及，几乎所有韩国人都在使用我们的服务。与此同时，我们在 Iceberg Lakehouse 中积累了超过 20PB 的数据，并处理着韩国最高的数据流量之一。

为了提供流畅的用户体验和及时的决策支持，我们的分析系统必须提供实时洞察，处理复杂的指标，并能够灵活扩展以应对不断增长的流量。

在本文中，我们将分享如何应对这些挑战，我们实施了哪些策略来提升分析能力，以及在这一过程中取得的关键成果。

推动 NAVER 决策制定的数据分析系统

在 NAVER，我们的分析系统是支撑两项关键任务的基石：

1. 服务性能监控：确保服务高效运行，始终满足用户期望。
2. 用户行为分析：洞察用户与服务的互动方式，推动数据驱动的决策。

我们的系统旨在支持内部决策制定人员和技术团队，例如优化服务性能的工程师或制定战略的高管。为实现这一目标，我们处理和分析大量日志数据，包括用户代理（user agents）、服务 URL 和点击流（clickstreams），将原始数据转化为可执行的洞察，推动 NAVER 不断前进。

原有技术栈—— ClickHouse 所带来的挑战

在构建第一个版本的分析平台时，我们希望能够快速搭建，因此选择了ClickHouse 作为最初的解决方案。其快速的聚合查询性能让我们在初期能够迅速交付结果。然而，随着平台的发展，我们遇到了不少显著的限制。

固定维度

ClickHouse 缺乏 JOIN 支持，我们不得不依赖反范式化的表格（denormalized tables），这限制了用户只能使用固定维度，并阻碍了实时分析。面对众多数据源和表，扩展变得不切实际，导致我们只能提供一小部分数据服务。

可扩展性问题

另一个主要挑战是 ClickHouse 的扩展性。将数据均匀分配到各个节点需要手动干预，过程既耗时又缺乏自动化。随着数据量的增加，保持这种平衡变得愈加复杂，且资源消耗也越来越大。

有限的数据更新/删除

ClickHouse 通过“merge on read”来处理实时可变数据（mutable data）。尽管这种方式能保持数据的新鲜度，但它严重影响了性能，这是我们无法接受的。这一限制使得许多场景难以支持，甚至完全无法实现，特别是在需要可变数据和复杂架构的分析工作流中。

随着分析需求的扩展，尤其是涉及动态维度、原始数据查询和无缝可扩展性时，这些限制变得愈加明显。我们意识到，必须找到一个更强大、更灵活的解决方案来支撑 NAVER 的分析平台。

技术选型 — Trino、Pinot、Druid、StarRocks

我们对 Trino、Pinot、Druid 和 StarRocks 等几种解决方案进行了评估与基准测试，并根据以下标准进行了对比：

• 多表 JOIN：能够处理跨多个表的复杂查询，而无需依赖反范式化。
• 实时聚合查询性能：确保动态实时分析的查询执行快速高效。
• 扩展能力：支持无缝地横向扩展，处理不断增长的数据量，同时保持最低的运维开销。
• 数据更新：支持实时数据更新而不影响查询性能。

经过广泛测试，我们选择了StarRocks，原因如下：

• 开箱即用的多表查询：StarRocks 原生支持复杂的多表 JOIN，消除了对反范式化表格的需求。
• 联邦分析：通过与 Apache Iceberg 及其他开放格式的集成，我们能够无缝分析内部和外部数据集，提供统一且灵活的查询接口。
• 卓越的聚合查询性能：即使在动态工作负载下，StarRocks 的聚合查询性能也能与 ClickHouse 媲美，甚至表现更优。
• 云原生扩展性：其解耦的存储计算架构简化了扩展过程，支持跨节点共享数据，并实现高效的资源管理。

StarRocks 成为了满足我们不断发展需求的理想平台，使我们能够为 NAVER 构建一个强大、可扩展且高性能的分析系统。

迁移到 StarRocks

我们进行了全面的测试，使用真实查询和数据集来确定最佳资源配置，并验证 StarRocks 的性能表现。测试内容包括多列聚合查询、多表 JOIN 查询以及横向扩展性。

测试性能与资源配置

为了确定最佳资源配置，我们使用真实查询和数据测试了 StarRocks 的性能，并将其与 ClickHouse 在1小时、6小时、12小时、18小时和24小时的数据表现进行了对比。

多列聚合查询

第一个基准测试聚焦于多列 GROUP BY 查询。我们在两种配置下对 StarRocks 和 ClickHouse 进行了评估：Kubernetes 上的小型集群和大型集群。结果显示，StarRocks 在这两种配置下的表现始终优于 ClickHouse。

JOIN 查询

接下来，我们测试了 StarRocks 和 ClickHouse 在上述集群配置下处理多表 JOIN 操作的能力。

横向扩展性

我们的基础设施完全容器化并运行在 Kubernetes 上，因此，横向扩展性是确保性能一致性和优化成本的关键因素。

下图对比了 StarRocks 和 ClickHouse 在横向扩展时的表现：

如上图所示，随着资源的增加，StarRocks 表现出线性增长。这种扩展性使我们能够高效地处理不断增长的工作负载，同时保持可预测的性能。

资源配置

根据测试结果，我们对 StarRocks 基础设施进行了优化，配置如下：

• 5个前端（FE）Pod：负责查询解析、计划和协调，确保高效执行。
• 80个后端（BE）Pod：专门用于数据存储，每个 Pod 配备48个 CPU、50Gi 内存和 10TB 的 SSD 存储，确保快速可靠的数据访问。
• 70个无状态计算节点（CN）Pod：根据需要动态分配计算资源，每个 Pod 配备48个 CPU 和 50Gi 内存，用于处理高查询量和复杂分析工作负载。

监控设置

监控是确保我们分析平台可靠性和性能的关键组件。通过 StarRocks，借助其文档中提供的预配置 Grafana 模板，监控设置变得更加简便。

该模板包含安装指南和预定义的仪表板，用于监控集群状态、合并状态以及 BE 和 FE 的各项指标。这些指标使我们能够实时监控系统的健康状况和性能，从而实现主动维护和快速解决问题。

通过物化视图进一步加速查询

为进一步提升查询性能，我们使用了 StarRocks 的物化视图。这些物化视图作为基础表的中间缓存，加速了查询执行，且无需手动维护。

StarRocks 中物化视图的关键特性包括：

1. 查询重写：自动优化查询，在适用时使用物化视图，从而减少手动重写 SQL 的需求。
2. 自动/定时刷新：通过最小的人工干预保持视图的最新状态，确保数据的一致性。

对于上述查询，我们创建了一个反范式化的物化视图来绕过 JOIN 操作，从而实现了 6 倍的性能提升。尤为值得一提的是，这些物化视图可以按需添加，且得益于 StarRocks 的查询重写功能，我们无需修改原始 SQL。这种灵活性使我们能够随时优化查询性能，同时保持工作流的简洁性。

迁移结果

迁移至 StarRocks 后，我们的分析平台在以下方面实现了显著提升：

• 灵活的交互式查询

工程师现在可以直接使用 SQL 查询原始数据，与 ClickHouse 的固定预定义指标相比，提供了无与伦比的灵活性。

• 全面提升的性能

多表JOIN和多列GROUP BY查询的执行速度大幅提升，即使在包含实时数据更新和删除的数据集上也是如此。

• 统一查询平台

StarRocks 通过内部 catalog 提供高性能查询，利用 Apache Iceberg 的外部 catalog 管理外部数据，并通过 Apache Hive 外部 catalog 支持遗留的（legacy）孤立数据集，从而实现了所有数据源之间的无缝、高效整合。

• 可扩展性

StarRocks 的横向扩展能力与 Kubernetes 结合，确保了处理能力的线性增长，使平台能够以具有成本效益的方式处理动态和异构的工作负载。

这些优势简化了我们的工作流程，使平台能够更高效、更灵活地支持 NAVER 不断发展的分析需求。

总结：

在 NAVER，高效处理多表 JOIN 的能力彻底改变了我们的分析平台。StarRocks 帮助我们突破了以往的限制，实现了更快的查询性能、无缝扩展性，以及与多元数据源集成的统一查询平台。这些改进使我们能够提供实时洞察，支持整个生态系统中的数据驱动决策。

未来规划

未来，我们计划进一步提升 StarRocks 的部署，具体包括以下几方面：

1. 性能优化：优化分区策略，提升查询效率，尤其是针对基于时间戳的查询，实现更快的分析处理。
2. 社区贡献：将我们的内部进展贡献给开源社区，帮助增强 StarRocks 的功能，为更广泛的用户群体提供支持。
3. 更广泛的集成：扩大 StarRocks 的应用范围，处理更多外部数据集，利用 Apache Iceberg 进行动态和管控数据查询。