Как JOIN изменил наш подход к инфраструктуре данных в NAVER

Авторы:Youngjin Kim, руководитель команды, NAVER; Moweon Lee, инженер по данным, NAVER

NAVER основана в 1999 году, является материнской компанией мессенджера LINE, пятой по величине поисковой системой в мире, крупнейшим поиском и порталом в Южной Корее и интернет‑компанией с наибольшей капитализацией в стране.

Как команда платформы данных NAVER мы обеспечиваем аналитическую поддержку ведущему корейскому порталу. NAVER поддерживает экосистему из более чем 200 взаимосвязанных сервисов, включающих поиск, электронную коммерцию, медиа и приложения на базе искусственного интеллекта. По мере роста популярности платформы практически все жители Южной Кореи пользуются нашими сервисами.

Параллельно мы накопили более 20 ПБ данных в lakehouse на базе Apache Iceberg (Iceberg Lakehouse) и обрабатываем один из крупнейших в стране объемов трафика данных.
Чтобы обеспечивать плавный пользовательский опыт и своевременную поддержку принятия решений, аналитическая система должна предоставлять инсайты в реальном времени, обрабатывать сложные метрики и гибко масштабироваться под растущую нагрузку.
В этой статье мы расскажем, как мы справляемся с этими вызовами, какие стратегии внедряем для усиления аналитики и каких ключевых результатов достигаем.

Аналитическая система, которая движет принятием решений в NAVER

В NAVER аналитическая система является краеугольным камнем для двух ключевых задач:

1. Мониторинг производительности сервисов: гарантирует эффективную работу и соответствие ожиданиям пользователей.

2. Аналитика пользовательского поведения: показывает, как пользователи взаимодействуют с сервисами, и продвигает принятие решений на основе данных.

   

Система поддерживает внутренних стейкхолдеров и технические команды — от инженеров, оптимизирующих производительность, до руководителей, формирующих стратегию.
Для этого мы обрабатываем и анализируем большие объемы лог‑данных, включая User‑Agent, URL сервисов и clickstreams, превращая сырые данные в прикладные инсайты, которые двигают NAVER вперед.

Изначальный стек — вызовы ClickHouse

Создавая первую версию аналитической платформы, мы ориентировались на быстрый запуск и выбрали ClickHouse. Его высокая скорость агрегирующих запросов позволила быстро показать результат на старте. Однако по мере развития платформы выявились существенные ограничения.

Фиксированные измерения

Из‑за ограниченной поддержки JOIN в ClickHouse нам приходилось опираться на денормализованные таблицы (denormalized tables), что фиксировало доступные измерения и мешало аналитике в реальном времени. При множестве источников и таблиц масштабирование становилось непрактичным, поэтому мы могли предоставлять лишь ограниченный набор дата‑сервисов.

Проблемы масштабируемости

Важный вызов — масштабирование ClickHouse. Равномерное распределение данных по узлам требовало ручных действий, что трудозатратно и слабо автоматизируется. С ростом данных поддерживать баланс становилось все сложнее, а потребление ресурсов — выше.

Ограниченные обновления и удаления

ClickHouse обрабатывает изменяемые в реальном времени данные (mutable data) через подход merge‑on‑read. Хотя это сохраняет свежесть данных, он заметно снижает производительность, что для нас неприемлемо. В результате многие сценарии становились трудновыполнимыми или невозможными, особенно там, где нужны изменяемые данные и сложная архитектура конвейеров.

По мере роста потребностей в динамических измерениях, запросах к сырым данным и бесшовной масштабируемости эти ограничения усиливались. Мы поняли, что нужна более мощная и гибкая платформа для аналитики NAVER.

Выбор технологий — Trino, Pinot, Druid, StarRocks

Мы провели оценку и бенчмарки Trino, Pinot, Druid и StarRocks по следующим критериям:

• Многотабличный JOIN: выполнение сложных запросов по нескольким таблицам без необходимости денормализации.

• Производительность агрегирующих запросов в реальном времени: быстрое и эффективное выполнение для динамической аналитики.

• Масштабирование: бесшовное горизонтальное масштабирование с ростом данных при минимальных операционных издержках.

• Обновления данных: поддержка обновлений в реальном времени без деградации производительности запросов.

  

По итогам тестов мы выбрали StarRocks по следующим причинам:

• Многотабличные запросы «из коробки»: нативная поддержка сложных JOIN устраняет потребность в денормализованных таблицах.

• Федеративная аналитика: интеграция с Apache Iceberg и другими открытыми форматами позволяет бесшовно анализировать внутренние и внешние наборы данных в рамках единого гибкого интерфейса запросов.

• Выдающаяся производительность агрегирующих запросов: даже при динамических нагрузках агрегации в StarRocks сопоставимы с ClickHouse или превосходят его.

• Облачно‑нативная масштабируемость: разделение хранения и вычислений (decoupled storage and compute) упрощает масштабирование, обеспечивает общий доступ к данным между узлами и эффективное управление ресурсами.

StarRocks стал оптимальной платформой под наши эволюционирующие требо��ания, позволив построить мощную, масштабируемую и высокопроизводительную аналитическую систему для NAVER.

Миграция на StarRocks

Мы провели всесторонние испытания на реальных запросах и датасетах, чтобы определить оптимальную конфигурацию ресурсов и подтвердить производительность StarRocks. Тесты включали многостолбцовые агрегирующие запросы, многотабличные JOIN и проверку горизонтальной масштабируемости.

Производительность и конфигурация ресурсов

Чтобы определить оптимальные ресурсы, мы сравнили StarRocks и ClickHouse на реальных запросах и данных за 1, 6, 12, 18 и 24 часа.

Многостолбцовые агрегирующие запросы

Первый бенчмарк сфокусирован на GROUP BY по нескольким столбцам. Мы оценивали StarRocks и ClickHouse в двух конфигурациях: небольшой кластер и крупный кластер в Kubernetes. Результаты показали, что StarRocks стабильно превосходит ClickHouse в обеих конфигурациях.

JOIN‑запросы

Затем мы протестировали выполнение многотабличных JOIN в тех же конфигурациях кластеров. StarRocks успешно выполнил все JOIN‑запросы с низкой задержкой. В ClickHouse четыре из пяти запросов не завершились.

Горизонтальная масштабируемость

Наша инфраструктура полностью контейнеризована и работает в Kubernetes, поэтому горизонтальное масштабирование критично для стабильной производительности и оптимизации затрат. На диаграмме ниже сравнивается масштабирование StarRocks и ClickHouse при наращивании ресурсов.

Как видно, с ростом ресурсов StarRocks демонстрирует линейный прирост производительности. Такая масштабируемость позволяет эффективно обрабатывать растущие нагрузки и сохранять предсказуемую производительность.

Распределение ресурсов

По результатам тестов мы оптимизировали инфраструктуру StarRocks и настроили ее следующим образом:

• 5 подов FE: разбор, планирование и координация запросов для эффективного выполнения.

• 80 подов BE: хранилище данных; каждый под оснащен 48 CPU, 50 ГиБ памяти и SSD‑накопителем 10 ТБ для быстрого и надежного доступа к данным.

• 70 подов CN (stateless): динамически масштабируемые вычислительные ресурсы; каждый под имеет 48 CPU и 50 ГиБ памяти для обработки высокого объема запросов и сложных аналитических нагрузок.

Настройка мониторинга

Мониторинг — ключевой компонент надежности и производительности аналитической платформы. В StarRocks он упрощен за счет преднастроенных шаблонов Grafana из документации.

Шаблон включает инструкцию по установке и предопределенные дашборды для мониторинга состояния кластера, состояния слияний и метрик BE и FE. Эти метрики позволяют в реальном времени отслеживать здоровье и производительность системы, обеспечивая проактивное обслуживание и быстрое устранение проблем.

Дополнительное ускорение запросов с помощью материализованных представлений

Чтобы еще больше ускорить запросы, мы используем материализованные представления StarRocks. Они служат промежуточным кэшем над базовыми таблицами и ускоряют выполнение без ручного сопровождения.
Ключевые возможности материализованных представлений в StarRocks:

1. Переписывание запросов (query rewrite): автоматическая оптимизация, при которой при возможности используются материализованные представления, снижая потребность ручной переработки SQL.

2. Автоматическое/периодическое обновление: поддержание актуальности представлений при минимальном ручном вмешательстве и с сохранением согласованности данных.

   

Для приведенных выше запросов мы создали денормализованное материализованное представление, чтобы обходить JOIN, что дало шестикратный прирост производительности. Важно, что такие представления можно добавлять по мере необходимости, и благодаря переписыванию запросов в StarRocks нам не пришлось изменять исходный SQL. Эта гибкость позволяет точечно оптимизировать производительность, сохраняя простоту рабочих процессов.

Результаты миграции

После перехода на StarRocks аналитическая платформа существенно улучшилась по следующим направлениям:

• Гибкие интерактивные запросы: инженеры теперь могут напрямую писать SQL по сырым данным, что обеспечивает несравнимую гибкость по сравнению с фиксированными предопределенными метриками в ClickHouse.

• Всеобщее ускорение: заметно ускорено выполнение многотабличных JOIN и многостолбцовых GROUP BY даже на наборах с обновлениями и удалениями в реальном времени.

• Единая платформа запросов: StarRocks обеспечивает высокопроизводительные запросы через внутренний каталог, управляет внешними данными через внешний каталог Apache Iceberg (External Catalog) и поддерживает устаревшие изолированные наборы через внешний каталог Apache Hive — обеспечивая бесшовную и эффективную интеграцию всех источников.

• Масштабируемость: горизонтальная масштабируемость StarRocks в связке с Kubernetes обеспечивает линейный рост вычислительной мощности и позволяет экономично обрабатывать динамичные и неоднородные нагрузки.

Эти преимущества упростили процессы и позволили платформе эффективнее и гибче поддерживать постоянно развивающиеся аналитические потребности NAVER.

Итоги

В NAVER способность эффективно выполнять многотабличные JOIN радикально изменила нашу аналитическую платформу. StarRocks помог преодолеть прежние ограничения, обеспечив более высокую скорость запросов, бесшовное масштабирование и единый слой запросов для интеграции разнообразных источников данных. Эти улучшения позволяют предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных по всей экосистеме.

Планы на будущее

В дальнейшем мы планируем развивать развертывание StarRocks по нескольким направлениям:

1. Оптимизация производительности: оптимизировать стратегию партиционирования и ускорить запросы, особенно по временным меткам, для более быстрого анализа.

2. Вклад в сообщество: делиться внутренними наработками с open‑source‑сообществом, расширяя возможности StarRocks и помогая более широкой аудитории.

3. Более широкая интеграция: расширить применение StarRocks для обработки большего числа внешних наборов данных и использовать Apache Iceberg для динамичных и управляемых запросов к данным.