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

简介: NAVER,作为韩国最大的搜索引擎和互联网公司,从ClickHouse迁移至StarRocks后,在多表JOIN处理、查询性能、无缝扩展及构建统一查询平台方面取得了显著优化。StarRocks不仅提升了实时数据处理能力,还支持多种数据源的兼容,助力NAVER提供更高效的分析系统,支持其庞大的生态系统中的数据驱动决策。通过StarRocks,NAVER实现了更快的查询响应、灵活的交互式查询以及更好的可扩展性,极大简化了工作流程,满足了不断增长的分析需求。未来,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 进行动态和管控数据查询。

推荐阅读:StarRocks 全球用户精选案例

其他交流:https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/515d5

相关文章
|
8月前
|
SQL 缓存 分布式计算
vivo 湖仓架构的性能提升之旅
聚焦 vivo 大数据多维分析面临的挑战、StarRocks 落地方案及应用收益。 在 **即席分析** 场景,StarRocks 使用占比达 70%,查询速度提升 3 倍,P50 耗时从 63.77 秒缩短至 22.30 秒,查询成功率接近 98%。 在 **敏捷 BI** 领域,StarRocks 已完成 25% 切换,月均查询成功数超 25 万,P90 查询时长缩短至 5 秒,相比 Presto 提升 75%。 在 **研发工具平台** 方面,StarRocks 支持准实时数据查询,数据可见性缩短至 3 分钟,查询加速使 P95 延迟降至 400 毫秒,开发效率提升 30%。
vivo 湖仓架构的性能提升之旅
|
7月前
|
存储 人工智能 自然语言处理
RAG 实战|用 StarRocks + DeepSeek 构建智能问答与企业知识库
本文由镜舟科技解决方案架构师石强与StarRocks TSC Member赵恒联合撰写,围绕RAG(检索增强生成)技术展开,结合DeepSeek和StarRocks构建智能问答系统。RAG通过外部知识检索与AI生成相结合,解决大模型知识静态、易编造信息的问题。文章详细介绍了系统组成、操作流程及优化方法,包括DeepSeek部署、StarRocks向量索引配置、知识存储与提取等环节,并通过代码示例演示了从文本向量化到生成回答的完整过程。最后,加入RAG机制后,系统性能显著提升,支持企业级知识库与智能客服场景。文中还提供了Web可视化界面实现方案,助力开发者快速上手。
|
7月前
|
运维 监控 数据库
[直播预告]StarRocks 小课堂 监控告警全覆盖,别等服务挂了才处理!
数据库告警不仅是发现问题,更是预防问题的关键。4月16日19:00-20:00,StarRocks小课堂特邀景丹解析FE/BE服务挂起、资源过载等监控与处理方案,助你掌握主动权。直播预约:https://mp.weixin.qq.com/s/H8e6scM-HQteS0MBQ8zgYw。参与互动还有机会赢取棒球帽、T恤等2025 StarRocks周边!回复“监控告警”或“T恤”获取专属海报,邀请好友助力赢好礼!
|
7月前
|
供应链 算法 BI
StarRocks 助力首汽约车精细化运营
本文由首汽约车大数据负责人任智红在StarRocks年度峰会上的演讲整理而成,分享了StarRocks在企业内部的应用实践。文章详细介绍了StarRocks如何助力首汽约车实现精细化运营,涵盖运效诊断、供需平衡联动及自助多维分析等核心业务场景。通过引入StarRocks,公司实现了秒级数据处理与查询性能提升,大幅降低了开发和维护成本,推动了数据驱动的业务发展。未来,首汽约车计划进一步整合系统、拓展应用场景,并优化存算分离与资源隔离策略,持续提升数据处理效率与业务稳定性。
|
8月前
|
SQL 分布式计算 运维
StarRocks 在爱奇艺大数据场景的实践
本文介绍了爱奇艺大数据OLAP服务负责人林豪在StarRocks年度峰会上的分享,重点讲述了爱奇艺OLAP引擎的演进及引入StarRocks后的显著效果。在广告业务中,StarRocks替换Impala+Kudu后,接口性能提升400%,P90查询延迟缩短4.6倍;在“魔镜”数据分析平台中,StarRocks替代Spark达67%,P50查询速度提升33倍,P90提升15倍,节省4.6个人天。未来,爱奇艺计划进一步优化存算一体和存算分离架构,提升整体数据处理效率。
StarRocks 在爱奇艺大数据场景的实践
|
8月前
|
SQL 算法 API
微信基于 StarRocks 的实时因果推断实践
本文介绍了因果推断在业务中的应用,详细阐述了基于 StarRocks 构建因果推断分析工具的技术方案,通过高效算子的支持,大幅提升了计算效率。例如,t 检验在 6亿行数据上的执行时间仅需 1 秒。StarRocks 还实现了实时数据整合,支持多种数据源(如 Iceberg 和 Hive)的无缝访问,进一步增强了平台的灵活性与应用价值。
|
8月前
|
存储 缓存 Apache
小红书湖仓架构的跃迁之路
小红书研发工程师李鹏霖(丁典)在StarRocks年度峰会上分享了如何通过结合StarRocks和Iceberg实现极速湖仓分析架构。新架构使P90查询性能提升了3倍,查询响应时间稳定在10秒以内,存储空间减少了一半。RedBI自助分析平台支持灵活、快速的即席查询,优化了排序键和Join操作,引入DataCache功能显著提升查询性能。未来将探索近实时湖仓分析架构,进一步优化处理能力。
|
9月前
|
数据挖掘 OLAP 云计算
[直播预约]StarRocks 2025 Roadmap 全面解读
2月19日19:00-20:30,StarRocks TSC Member赵恒、康凯森将解读2025 Roadmap,并邀请多位专家分享最新进展。欢迎参与交流!
|
8月前
|
存储 SQL 缓存
StarRocks 存算分离在京东物流的落地实践
本文分享了京东物流在StarRocks存算分离架构上的实践与成果。通过将UData平台从存算一体升级为存算分离,显著提升了查询性能和资源利用率,同时大幅降低了存储成本(90%)和计算资源成本(30%)。文章详细介绍了存算分离的背景、部署方案、性能表现及优化措施,包括联邦查询、实时写入、Compaction调优等关键技术点。未来,京东物流将持续推动存算分离的应用拓展,并探索更多降本增效策略,如Stream Load任务合并与主动缓存管理。
|
8月前
|
存储 JSON OLAP
StarRocks + Paimon 在阿里集团 Lakehouse 的探索与实践
阿里集团在推进湖仓一体化建设过程中,依托 StarRocks 强大的 OLAP 查询能力与 Paimon 的高效数据入湖特性,实现了流批一体、存储成本大幅下降、查询性能数倍提升的显著成效: A+ 业务借助 Paimon 的准实时入湖,显著降低了存储成本,并引入 StarRocks 提升查询性能。升级后,数据时效提前60分钟,开发效率提升50%;JSON列化存储减少50%,查询性能提升最高达10倍;OLAP分析中,非JOIN查询快1倍,JOIN查询快5倍。 饿了么升级为准实时Lakehouse架构后,在时效性仅损失1-5分钟的前提下,实现Flink资源缩减、StarRocks查询性能提升(仅5%