Автор: Юнь Ханьсюань, ведущий инженер по разработке Big Data в Hello

Вступление

Как один из ведущих в стране сервисов для поездок и локальных лайфстайл‑услуг, Hello в условиях мультибизнесовой синергии и сценариев онлайн‑диспетчинга в реальном времени предъявляет всё более высокие требования к производительности аналитики и стабильности системы.

Чтобы справиться с ростом объёма данных и вычислительной нагрузки, вызванными диверсификацией бизнеса, команда Hello провела крупномасштабную миграцию с ClickHouse на StarRocks и разработала собственный инструмент сравнения данных, который обеспечивает сквозную автоматическую валидацию (в дальнейшем планируется открыть его в формате open source).

После миграции производительность запросов выросла в 3–5 раз, совокупная стоимость владения системой сократилась более чем на 80%, латентность запросов снизилась с минут до секунд, а маркетинговый ROI увеличился примерно на 60%.

Сейчас в Hello в мультиоблачной среде развернуто 15 кластеров StarRocks, которые поддерживают ключевые направления бизнеса: инклюзивные финансовые сервисы, двухколёсную мобильность и алгоритмическую платформу.

Далее в статье — архитектурные решения, технические детали и практические эффекты от этой миграции.

Hello: от шеринга велосипедов к супер‑платформе

Hello начинала как сервис проката велосипедов, а сегодня превратилась в одного из лидеров рынка локальных сервисов для поездок и повседневной жизни.

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

Опираясь на уже устойчивый основной бизнес, Hello расширилась в сферу инклюзивных лайфстайл‑сервисов: запустила собственный бренд электроскутеров «Hello Электро», вместе с Ant Group и CATL создала совместное предприятие «Xiaoha Battery Swap» для обмена аккумуляторов двухколёсных электровелосипедов, а также построила агрегаторный каршеринг‑/рентал‑сервис «Hello Car Rental». Кроме того, Hello запустила «StreetCat» — интеллектуальную платформу для управления городскими бездомными кошками.

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

OLAP‑движком, который ранее использовали и маркетинговая платформа, и команда двухколёсной мобильности, был ClickHouse.

Маркетинговая стратегическая платформа — это ядро точечного маркетинга Hello. По мере развития бизнеса объём данных на платформе превысил 100 млрд записей. Платформа данных двухколёсной мобильности, являющейся ключевым бизнесом Hello, обслуживает такие критичные сценарии, как аналитика заказов, отслеживание пользовательского поведения и операционный мониторинг.

1. Бэкграунд: ограничения исходной архитектуры

Узкие места кластера ClickHouse

По мере непрерывного роста объёма данных исходный кластер ClickHouse стал проявлять всё более явные проблемы производительности и превращаться в тормоз развития бизнеса:

• Плохая масштабируемость кластера. Каждое расширение требовало остановки сервиса и полной перезаписи всех данных, что приводило к простоям и не позволяло поддерживать быстрый рост объёмов.

• Высокая нагрузка на ресурсы. В обычном режиме CPU и память были загружены более чем на 80%; фактически отсутствовал запас по ресурсам, в пиковые моменты часто возникали блокировки запросов.

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

• Ограниченные возможности запросов по data lake. Не удавалось полноценно запрашивать историю в Hive‑озере — были доступны только данные за последние 60 дней, что сдерживало долгосрочную аналитику эффективности маркетинга.

2. Переход к StarRocks

Чтобы решить эти проблемы, команда Hello после глубокой оценки разных опций решила внедрить StarRocks как основной OLAP‑движок.

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

Дополнительно StarRocks предоставляет:

• детализированный resource isolation и scheduling;

• несколько типов JOIN‑ов (distributed Hash Join, Broadcast Join, Colocate Join и др.) и умеет автоматически выбирать оптимальную стратегию исполнения в зависимости от размеров таблиц и распределения данных.

Кроме того, StarRocks обладает полноценными возможностями lakehouse‑запросов: он умеет не только эффективно обрабатывать локально хранимые данные, но и напрямую читать внешние таблицы в Hive, Iceberg, Delta Lake и т.д., обеспечивая единую аналитику и управление данными.

Благодаря высокой пропускной способности, высокой доступности и гибкому масштабированию StarRocks стал фундаментом нового поколения платформы аналитики в реальном времени в Hello.

Сегодня, в рамках мультиоблачной стратегии, Hello развернула 15 кластеров StarRocks в различных средах — собственные ЦОДы, Alibaba Cloud, Tencent Cloud, Volcano Engine и др. Суммарно они обрабатывают в среднем около 692 700 запросов в день, обеспечивая стабильную и эффективную data‑поддержку для инклюзивных финансовых сервисов, двухколёсной мобильности и алгоритмической платформы.

После перехода к единой архитектуре команда дополнительно выполнила по‑сценарное разбиение и оптимизацию, чтобы при одновременном соблюдении требований к аналитике в реальном времени и открытому lakehouse‑доступу добиться максимального использования ресурсов.

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

• Многоуровневое хранилище DWH. Данные в реальном времени пишутся напрямую в StarRocks, все запросы к «горячим» данным выполняются по внутренним таблицам StarRocks. Верхнеуровневые data‑приложения при выполнении запросов с высоким QPS и жёсткими SLA по латентности ходят напрямую во внутренние таблицы StarRocks.

• Ускорение запросов к data lake. Данные слоя ODS пишутся в lake (Hive и т.п.), а слои DWD, DWS, ADS хранятся в StarRocks.

  

3. Построение аналитической платформы в реальном времени: от ClickHouse к StarRocks

3.1. Схема миграции данных

Для бесшовного перехода с ClickHouse на StarRocks команда спроектировала двухуровневую схему: массовая миграция исторических данных + синхронизация инкрементальных данных в реальном времени.

Исторические данные

1. Экспорт исторических данных из ClickHouse в CSV.

2. На основе интерфейса StarRocks Stream Load был написан shell‑скриптовый инструмент, который заменил традиционные ETL‑тулы (Flink, DataX и др.) и позволил напрямую заливать исторические данные из ClickHouse в StarRocks.

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

• не нужно поднимать и поддерживать дополнительный middleware, снижается сложность системы;

• за счёт высокой пропускной способности Stream Load и управляемого параллелизма в скриптах удаётся эффективно использовать ресурсы и быстро мигрировать более 20 ТБ исторических данных.

Инкрементальная синхронизация

Инкрементальные данные синхронизируются в StarRocks через Flink‑job’ы, что гарантирует отсутствие потерь и низкую задержку в процессе миграции — бизнес переезжает на новый движок практически незаметно.

По сравнению с классическими ETL‑схемами, эта миграция даёт три ключевых преимущества:

1. Меньшая сложность системы. Взаимодействие ведётся напрямую из shell‑скриптов с интерфейсом StarRocks Stream Load, нет необходимости в развёртывании и сопровождении промежуточных компонентов, уменьшается число точек отказа.

2. Лучшее использование ресурсов. Stream Load спроектирован под high throughput, а скриптовые обёртки позволяют гибко настраивать количество параллельных задач и ритм их запуска, что предотвращает перерасход ресурсов.

3. Низкая стоимость сопровождения. Логика shell‑скриптов прозрачна, порог вхождения низкий; для поддержки не требуются отдельные ETL‑инженеры, уходят проблемы сложной конфигурации и крутого learning curve традиционных ETL‑инструментов.

3.2. Обеспечение согласованности данных

Чтобы гарантировать корректность и согласованность результатов в процессе миграции, команда Hello разработала лёгкий инструмент сравнения данных, который точно валидирует результаты запросов до и после переноса.

Основные технические вызовы:

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

• Сложная бизнес‑логика. Многотабличные JOIN‑ы, вычислительные функции (агрегации, конвертация дат и др.), маппинг типов полей (например, TINYINT → BIGINT) могут приводить к расхождениям и требуют точной валидации.

Ядро решения: собственный инструмент сравнения

Инструмент позиционируется как лёгкий и высоко совместимый. Он поддерживает как полное, так и выборочное (sample‑based) сравнение между источником (ClickHouse) и приёмником (StarRocks) и позволяет быстро валидировать результаты миграции без заметного воздействия на продакшен‑кластера.

Ключевые элементы дизайна:

Многодатасорсная адаптация и малозаметный коннект

• Кросс‑сорсная совместимость. Обёртка над JDBC‑драйверами ClickHouse (ru.yandex.clickhouse) и StarRocks (com.starrocks.jdbc) с унифицированным интерфейсом источника данных и возможностью динамически переключать конфигурации source/target.

• Оптимизация connection pool. Использование HikariCP с ограничением числа конкурентных соединений и таймаутами (например, 30 секунд), чтобы частые проверки не «кладили» продакшен‑кластера.

Движок правил маппинга типов полей

С учётом различий в типах данных в СУБД заранее задаются правила сопоставления, чтобы избежать ошибок при сравнении:

• Целочисленные типы. Допускается сравнение, например, TINYINT/INT на стороне источника с BIGINT на стороне приёмника.

• Floating point. Поддерживается конфигурируемый порог, например: abs(source_val - target_val) < 0.001 — значения считаются совпадающими (решение проблем с точностью float).

• Деление на ноль. ClickHouse возвращает infinity, а StarRocks — NULL; для таких кейсов инструмент считает результаты сопоставимыми.

3.3. Непрерывная оптимизация

Для дальнейшего повышения стабильности, производительности запросов и эффективности затрат команда Hello системно оптимизировала архитектуру и исполнительный движок StarRocks по четырём основным направлениям.

Разделение хранения и вычислений: минус 80% к стоимости

В платформе двухколёсной мобильности (кодовое название Hook) суточный объём записи по одной таблице достигает примерно 1 ТБ. Чтобы справиться с высокими объёмами записи и снизить стоимость хранения, команда приняла архитектуру separation of storage and compute, используя Alibaba Cloud OSS как слой хранения.

По расчётам, по сравнению с монолитной архитектурой «storage + compute на одних узлах» общая стоимость снизилась более чем на 80%.

При этом при сопоставимой нагрузке по concurrency производительность StarRocks в сценарии с разделением хранения и вычислений остаётся выше, чем у ClickHouse.

Bitmap‑индексы: ускорение запросов по высококардинальным признакам

Для столбцов с высокой кардинальностью (user ID, device ID и т.п.) используется Bitmap‑хранение. За счёт эффективных битовых операций (AND/OR) удаётся заменить классические дорогие COUNT DISTINCT.

На практике это дало:

• увеличение производительности запросов в 3–5 раз;

• минимальные затраты на доработку со стороны DWH‑команды.

Механизм «предохранителя» на тяжёлые запросы: стабильный кластер

На основе StarRocks Resource Group для маркетинговой платформы выделен отдельный ресурсный пул с настройками:

• таймаут запросов — 600 секунд;

• лимит памяти — 80%;

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

Если единичный запрос выходит за пределы, он автоматически обрубается механизмом предохранителя, что не даёт отдельным задачам выедать все ресурсы и поддерживает стабильность всего кластера.

SQL‑совместимость

При миграции критично обеспечить совместимость SQL. Пока синтаксис не выровнен, невозможно безболезненно перенести существующие аналитические инструменты и бизнес‑логику на новую платформу.

Команда расширила инструмент SQLTransformer из сообщества (https://github.com/StarRocks/SQLTransformer), добившись глубокого соответствия синтаксиса ClickHouse и StarRocks. В результате аналитики могут практически «как есть» использовать старые скрипты и привычный стиль запросов без масштабной переработки.

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

Переход на StarRocks дал Hello многомерный прирост по производительности, бизнес‑эффекту, архитектуре и операционной эффективности.

• Серьёзный прирост производительности: ускорение аналитики в 3–5 раз. Ключевые запросы, которые в ClickHouse выполнялись на уровне минут, теперь в большинстве случаев укладываются в секунды. Аналитика пользовательских профилей и сегментации аудитории в режиме, близком к реальному времени, стала существенно быстрее, маркетинг оперативнее реагирует на изменения в бизнесе и корректирует стратегии.

• Существенный рост маркетингового ROI. За счёт роста эффективности обработки данных улучшились качество сегментации, точность таргетинга и скорость исполнения кампаний. Конверсия и повторные покупки выросли примерно на 60%, заметно повысив эффективность использования маркетинговых бюджетов.

• Единая OLAP‑платформа и сквозная аналитика по нескольким источникам.После консолидации в StarRocks система выдерживает высокую конкуррентность и низкую латентность запросов, объединяет данные бизнес‑БД, лог‑систем и других источников, обеспечивая кросс‑бизнесовую и кросс‑сценарную аналитику и ликвидируя data silos.

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

5. Построение стандартизированной системы управления StarRocks

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

Поэтому Hello разработала собственную OLAP‑управляющую платформу, основной принцип которой — сквозной контроль процессов и покрытие всех сценариев. Она обеспечивает визуальное управление кластерами StarRocks и стандартизирует операционные процессы.

Платформа сфокусирована на четырёх ключевых областях:

1. управление кластерами;

2. управление активами;

3. управление правами;

4. сервисы кластера.

За счёт модульной архитектуры и стандартизированных процессов платформа покрывает весь жизненный цикл эксплуатации кластеров StarRocks.

Ключевые модули:

• Модуль управления кластерами. Точное ведение информации по узлам ECS, FE‑нодам и BE‑нодам, полный обзор состояния узлов.

• Модуль управления активами. Единое управление вычислительными и storage‑ресурсами разных бизнес‑подразделений, а также прозрачная фиксация data lineage для таблиц StarRocks (откуда и как в них пишутся данные).

• Модуль управления правами. Двухуровневый контроль: ограничения на доступ к кластерам и отдельные права на запросы к конкретным таблицам StarRocks — для гарантии безопасности данных.

• Модуль сервисов кластера. Интеграция всего набора инструментов, необходимых для эксплуатации StarRocks и поддержки бизнес‑команд. Это one‑stop‑платформа, которая существенно снижает издержки на переключение между разными системами.

  

  Основные функции:

  • Интеграция инструментов data ingestion. Встроенные визуальные интерфейсы для Hive2StarRocks, Kafka2StarRocks и прочих инструментов. Можно сконфигурировать задачи синхронизации (выбор источника, частота синка, маппинг полей) и в реальном времени видеть статус выполнения.

  • Поиск по аудит‑логам. Быстрая аналитика логов для оперативного нахождения проблем и узких мест (например, медленных запросов).

  • Databox для ad‑hoc‑запросов. Упрощённый процесс «взять данные прямо сейчас» — бизнес‑команды могут быстро получить и использовать нужные данные без тяжёлых ETL‑цепочек.

6. Эффект и ценность

Масштабное применение StarRocks в ключевых бизнес‑сценариях не только помогло Hello решить боль Big Data сразу по нескольким направлениям, но и позволило выстроить повторно используемую технологическую и управленческую основу.

• Усиление бизнес‑поддержки. От аналитики профилей в реальном времени в маркетинговой платформе до оптимизации сложных запросов в платформе двухколёсной мобильности — StarRocks сократил время отклика по ключевым сценариям с минут до секунд. Это переводит бизнес с режима постфактум‑аналитики на принятие решений в (почти) реальном времени, повышая маркетинговый ROI и операционную эффективность.

• Оптимизация архитектуры и снижение затрат. За счёт мультиоблачного развёртывания и архитектуры с разделением хранения и вычислений StarRocks удовлетворяет стратегическим требованиям Hello по мультиокружениям, обеспечивая сокращение затрат и рост эффективности использования ресурсов. В среднем ресурсная эффективность выросла примерно на 40%.

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

В дальнейшем Hello планирует ещё глубже интегрировать StarRocks и исследовать его потенциал в сценариях real‑time DWH, lakehouse‑архитектуры и Data + AI, чтобы ещё сильнее раскрыть ценность данных и поддержать инновации и рост бизнеса в сфере мобильности.