Авторы:Youngjin Kim, руководитель команды, NAVER; Moweon Lee, инженер по данным, NAVER
NAVER основана в 1999 году, является материнской компанией мессенджера LINE, пятой по величине поисковой системой в мире, крупнейшим поиском и порталом в Южной Корее и интернет‑компанией с наибольшей капитализацией в стране.
Как команда платформы данных NAVER мы обеспечиваем аналитическую поддержку ведущему корейскому порталу. NAVER поддерживает экосистему из более чем 200 взаимосвязанных сервисов, включающих поиск, электронную коммерцию, медиа и приложения на базе искусственного интеллекта. По мере роста популярности платформы практически все жители Южной Кореи пользуются нашими сервисами.
Параллельно мы накопили более 20 ПБ данных в lakehouse на базе Apache Iceberg (Iceberg Lakehouse) и обрабатываем один из крупнейших в стране объемов трафика данных.
Чтобы обеспечивать плавный пользовательский опыт и своевременную поддержку принятия решений, аналитическая система должна предоставлять инсайты в реальном времени, обрабатывать сложные метрики и гибко масштабироваться под растущую нагрузку.
В этой статье мы расскажем, как мы справляемся с этими вызовами, какие стратегии внедряем для усиления аналитики и каких ключевых результатов достигаем.
Аналитическая система, которая движет принятием решений в NAVER
В NAVER аналитическая система является краеугольным камнем для двух ключевых задач:
Мониторинг производительности сервисов: гарантирует эффективную работу и соответствие ожиданиям пользователей.
Аналитика пользовательского поведения: показывает, как пользователи взаимодействуют с сервисами, и продвигает принятие решений на основе данных.
Система поддерживает внутренних стейкхолдеров и технические команды — от инженеров, оптимизирующих производительность, до руководителей, форм��рующих стратегию.
Для этого мы обрабатываем и анализируем большие объемы лог‑данных, включая 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:
Переписывание запросов (query rewrite): автоматическая оптимизация, при которой при возможности используются материализованные представления, снижая потребность ручной переработки SQL.
Автоматическое/периодическое обновление: поддержание актуальности представлений при минимальном ручном вмешательстве и с сохранением согласованности данных.
Для приведенных выше запросов мы создали денормализованное материализованное представление, чтобы обходить JOIN, что дало шестикратный прирост производительности. Важно, что такие представления можно добавлять по мере необходимости, и благодаря переписыванию запросов в StarRocks нам не пришлось изменять исходный SQL. Эта гибкость позволяет точечно оптимизировать производительность, сохраняя простоту рабочих процессов.
Результаты миграции
После перехода на StarRocks аналитическая платформа существенно улучшилась по следующим направлениям:
Гибкие интерактивные запросы: инженеры теперь могут напрямую писать SQL по сырым данным, что обеспечивает несравнимую гибкость по сравнению с фиксированными предопределенными метриками в ClickHouse.
Всеобщее ускорение: заметно ускорено выполнение многотабличных JOIN и многостолбцовых GROUP BY даже на наборах с обновлениями и удалениями в реальном времени.
Единая платформа запросов: StarRocks обеспечивает высокопроизводительные запросы через внутренний каталог, управляет внешними данными через внешний каталог Apache Iceberg (External Catalog) и поддерживает устаревшие изолированные наборы через внешний каталог Apache Hive — обеспечивая бесшовную и эффективную интеграцию всех источников.
Масштабируемость: горизонтальная масштабируемость StarRocks в связке с Kubernetes обеспечивает линейный рост вычислительной мощности и позволяет экономично обрабатывать динамичные и неоднородные нагрузки.
Эти преимущества упростили процессы и позволили платформе эффективнее и гибче поддерживать постоянно развивающиеся аналитические потребности NAVER.
Итоги
В NAVER способность эффективно выполнять многотабличные JOIN радикально изменила нашу аналитическую платформу. StarRocks помог преодолеть прежние ограничения, обеспечив более высокую скорость запросов, бесшовное масштабирование и единый слой запросов для интеграции разнообразных источников данных. Эти улучшения позволяют предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных по всей экосистеме.
Планы на будущее
В дальнейшем мы планируем развивать развертывание StarRocks по нескольким направлениям:
Оптимизация производительности: оптимизировать стратегию партиционирования и ускорить запросы, особенно по временным меткам, для более быстрого анализа.
Вклад в сообщество: делиться внутренними наработками с open‑source‑сообществом, расширяя возможности StarRocks и помогая более широкой аудитории.
Более широкая интеграция: расширить применение StarRocks для обработки большего числа внешних наборов данных и использовать Apache Iceberg для динамичных и управляемых запросов к данным.
