韩国互联网巨头 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，我们的分析系统是支撑两项关键任务的基石：

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

我们的系统旨在支持内部决策制定人员和技术团队，例如优化服务性能的工程师或制定战略的高管。为实现这一目标，我们处理和分析大量日志数据，包括用户代理（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 内存，用于处理高查询量和复杂分析工作负载。