Автор: Вэй Нин, эксперт по разработке платформы больших данных Trip

Аннотация

В обширной системе данных Trip система UBT (User Behavior Tracking, система отслеживания пользовательского поведения) решает ключевые задачи по сбору и анализу пользовательских действий, с ежедневным приростом данных до 30 ТБ. Чтобы удовлетворить растущие требования к бизнесу и производительности, команда мигрировала UBT с ClickHouse на архитектуру StarRocks с разделением хранения и вычислений.

После миграции система совершила качественный скачок: среднее время ответа запросов сократилось с 1,4 секунды до 203 миллисекунд, 95‑й перцентиль задержки (P95) — до 800 миллисекунд; одновременно объем хранения уменьшился вдвое, а число узлов — с 50 до 40. В статье описано, как Trip с помощью StarRocks нашел эффективный баланс между производительностью и стоимостью.

Архитектура UBT

Ключевая функция UBT — трекинг пользовательских действий через встраиваемые точки (трекинг событий) и запросно-аналитическая обработка этих событий, например, анализ фактов возникновения ошибок. Система ориентирована на многоплатформенные сценарии, включая Android, iOS и Node.js. Через SDK события проходят предварительную обработку и фильтрацию и отправляются в нижележащие системы для дальнейшей обработки.

Система широко используется в сценариях статистики инцидентов и мониторинга; среднесуточный прирост данных — около 30 ТБ. Данные обычно хранятся 30 дней, по отдельным таблицам — до года. Типовые запросы: детализированные лог‑запросы по UID/VID с временным диапазоном и распространенные агрегированные аналитические запросы.

Схема архитектуры UBT в целом такова:

• Верхний уровень — клиенты: мобильные приложения, Web и ПК.

• После сбора на сервере события сначала записываются в Kafka.

• Дальнейшее потребление идет по двум контурам:

  • Путь 1: потребление через gohangout и запись в ClickHouse — контур данных в реальном времени, преимущественно для пользовательских расследований и простых статистик.

  • Путь 2: запись через Flink в Hive как в «холодное» хранилище для более сложной бизнес‑аналитики.

• Также ряд бизнес‑платформ потребляют и обрабатывают эти данные.

Фокус данной модернизации — связка gohangout + ClickHouse, замененная на Flink + StarRocks.

Проблемы, с которыми столкнулся UBT

Основными драйверами изменений стали трудности при эксплуатации ClickHouse.

• Проблемы записи:

  • При записи данных UBT в ClickHouse наблюдались потери данных и рост очереди потребления.

  • Помимо записи в реальном времени требовались подкачки исторических данных.

  • Исторические диапазоны широкие, провоцируют Compaction по старым партициям, что ведет к повышенной нагрузке на CPU и I/O и росту общего системного лода.

• Горизонтальное масштабирование:

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

  • В условиях огромных объемов ClickHouse предъявляет высокие требования к хранению и «железу»: конфигурации специфичны, сложны в адаптации; для надежности часто требуется три реплики, что кратно увеличивает стоимость хранения.

• Производительность:

  • На больших временных диапазонах скорость выполнения SQL в ClickHouse недостаточна для аналитики в реальном времени.

  • Проблема усугубляется при высокой конкуренции запросов и сверхбольших объемах.

Отдельно проявились и ограничения gohangout:

• Стабильность: однопроцессная модель, опора на внешние ретраи — недостаточная надежность. Flink, напротив, распределенный, поддерживает автоматический failover и авто‑масштабирование, обеспечивая высокую доступность.

• Удобство: конфигурационный синтаксис gohangout громоздок; бизнес‑командам приходится тратить усилия на обучение и сопровождение. Команда потоковой обработки (real‑time) разработала RTP — платформу управления Flink. Пользователи пишут Flink SQL прямо на платформе, фильтруют и трансформируют данные из Kafka, получая полностью самостоятельную конфигурацию и визуальное управление.

Переход от ClickHouse к StarRocks

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

StarRocks эволюционировал к архитектуре с разделением хранения и вычислений:

• Вычислительные узлы становятся без состояния, содержат только вычислительный движок (compute engine), что позволяет гибко оркестрировать ресурсы под нагрузку.

• Хранение вынесено в удаленное объектное хранилище (OSS/S3), обеспечивая полную развязку вычислений и хранения.

• Для ускорения запросов включается DataCache на вычислительных узлах.

Преимущества:

• Более эффективное использование ресурсов, отсутствие простоя, заметное снижение стоимости хранения.

• Сохранение высокой скорости запросов.

• В отличие от трех реплик в совмещенной архитектуре, в разделенной модели достаточно одной копии для обеспечения надежности.

В архитектуре с разделением хранения и вычислений масштабирование вычислительных узлов не связано с миграцией фактических данных, выполняется за секунды, крайне гибко и не мешает бизнесу. В продакшене одна операция масштабирования в UBT заняла около 5 секунд.

Стабильность и оптимизация

1. Проектирование хранения

Общий объем данных UBT — порядка 1 ПБ; крупнейшая таблица — 400 ТБ и 1,8 трлн строк. Нагрузка на запись очень высока: совокупно ~3 млн строк/с и ~10 ГБ/с; по одной таблице максимум ~1 млн строк/с и ~3,5 ГБ/с.

Сценарии чтения:

• Детализированные запросы по полям вроде VID.

• Распространенные агрегированные запросы.

Около 90% запросов попадают в интервал последних 7 дней, поэтому дизайн хранения оптимизирован под эту особенность — как для записи, так и для чтения.

Ключевые решения:

• Ключ партиционирования: в StarRocks используется партиционирование по системному времени; запись идет только в текущую партицию. Это снижает фрагментацию и повышает стабильность записи. В ClickHouse применялось партиционирование по бизнес‑времени с записью сразу в партиции последних трех дней — большой охват порождал много фрагментов и нестабильность записи.

• Табличная схема: часовые партиции. При больших нагрузках это позволяет контролировать объем данных на одну операцию Compaction.

• Число бакетов — 128, чтобы повысить конкурентную способность на запись.

• Сжатие: zlib вместо LZ4. При сравнимой производительности экономия ~30% дискового пространства, заметное снижение стоимости хранения.

• DataCache: объем кэша спланирован под объем сканирования за 7 дней. Поскольку >90% запросов приходятся на последние 7 дней, большинство запросов ускоряются за счет кэширования.

2. Compaction

Оптимизация Compaction велась по трем направлениям:

• Разумная настройка параметров Compaction (ограничения числа файлов, количества потоков и т. п.).

• Снижение частоты и ресурсоемкости Compaction за счет часовых партиций и корректного числа бакетов.

• Включение MergeCommit во время записи для склейки мелких версий в крупные и сокращения фрагментации.

Мониторинг и управление:

• Таблица native_compactions показывает детальный прогресс каждой подзадачи Compaction на узлах CN (Compute Node) и помогает выявлять узлы с повышенной нагрузкой.

• Таблица partitions_metas позволяет отслеживать Compaction Score по таблицам и выявлять возможные проблемы в дизайне партиций или трансформациях.

• Команда SHOW PROC compactions дает информацию по задачам Compaction: время начала/окончания, общую длительность, объемы сканирования локальных и удаленных данных. Например, повышенное сканирование удаленных данных указывает на слишком маленькую конфигурацию DataCache.

• Метрики интегрированы в Grafana и визуализируются SQL‑графиками. Как правило, при Compaction Score < 100 система в оптимальном состоянии.

Примечание: FE (Frontend) — координатор запросов и метаданных; CN (Compute Node) — вычислительный узел.

3. Подкачка исторических данных

Поток записи разделен на две части. Первая — миграция и подкачка накопленных данных. В рамках модернизации требовалось перенести около 300 ТБ из ClickHouse. Эти данные также были в HDFS, поскольку исторически потоки писались параллельно в ClickHouse и Hive.

Для импорта выбран SparkLoad (Hive → StarRocks). Перед решением сравнили три метода:

• StreamLoad — для загрузок масштаба ГБ, обычно для логов в реальном времени.

• BrokerLoad — для ТБ‑уровня, обычно минутные окна, подходит для ежедневных офлайн‑пакетов.

• SparkLoad — для объемов свыше ТБ, с минимальным воздействием на кластер: Spark‑задача очищает и обрабатывает данные, складывает результат в HDFS, а узлы CN StarRocks напрямую подтягивают подготовленные данные из HDFS в хранилище.

Такой механизм обходит путь MemoryStore → диск, существенно снижает издержки Compaction и минимально влияет на кластер. Итог: SparkLoad — оптимальный выбор для крупной миграции и плавного переноса накопленных данных из Hive в StarRocks.

4. Инкрементальная запись в реальном времени

Для инкрементальной записи в реальном времени используется связка Flink → StarRocks с включенным MergeCommit. По сравнению с традиционным режимом Commit, MergeCommit дает значимые улучшения:

• Управление версиями: в традиционном режиме n мелких запросов порождают n коммитов и n версий. MergeCommit агрегирует их в один коммит и создает одну версию — меньше версий, ниже нагрузка на метаданные.

• Compaction: частые коммиты в традиционном режиме создают много мелких файлов (КБ/МБ), часто триггерят Compaction и повышают издержки. В MergeCommit каждый коммит обычно создает крупные файлы МБ‑уровня, что снижает число файлов и частоту Compaction.

• I/O‑эффективность: мелкие записи — это случайный I/O и частые открытия файлов при чтении. MergeCommit превращает запись в крупные последовательные батчи; файлов меньше, лучше используется последовательное чтение — ниже IOPS и задержки.

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

Практический эффект: без MergeCommit IOPS StarRocks обычно около 140; с MergeCommit — за счет агрегации — падает ниже 10, что дает почти 10‑кратное улучшение. Средний I/O Size также вырастает примерно в 10 раз.

5. Запросы

Оптимизация запросов опирается на два типовых сценария.

• Детализированные запросы:

  • Пользователь должен указывать партицию и использовать префиксный индекс.

  • Это резко сокращает область сканирования (отсечение по партициям, partition pruning) и повышает эффективность.

  • Комбинация отсечения и префиксного индекса обеспечивает стабильную производительность для лог‑аналитики на детальном уровне.

• Агрегированные запросы:

  • Частая потребность — статистика по часовым партициям.

  • Под такие запросы заранее строятся материализованные представления на уровне партиций (Partition MV) и выполняется предагрегация.

  • Partition MV обновляет только те партиции, где есть изменения, что минимально влияет на кластер.

Алгоритмическая оптимизация обновления MV:

• Изначально при каждом обновлении MV проверялись все партиции MV и все партиции базовой таблицы; фактически каждая партиция MV опрашивала все партиции базы — сложность M*N.

• После оптимизации партиции базовой таблицы запрашиваются один раз — сложность M+N.

• На масштабе десятков тысяч партиций эффект значителен: без оптимизации время отклика узлов FE резко растет.

Результаты и выгоды

После миграции с ClickHouse на StarRocks и комплекса оптимизаций достигнуты заметные улучшения:

• Хранение: за счет модели с одной репликой объем сократился с 2,6 ПБ (ClickHouse, 2 реплики) до 1,2 ПБ (StarRocks, 1 реплика), что существенно снизило стоимость.

• Ресурсы: число узлов уменьшено с 50 до 40, выросла эффективность использования.

• Производительность: средняя задержка снизилась с 1,4 с до 203 мс (≈ 1/7 прежнего значения); 95‑й перцентиль задержки (P95) — с 8 с до 800 мс (≈ 1/10).

• Запись: кривая записи в StarRocks стабильно держится на уровне ~3 млн строк/с; система работает ровно и предсказуемо.

  

Взгляд в будущее

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