Why Coinbase and Pinterest Chose StarRocks: Lakehouse-Native Design and Fast Joins at Terabyte Scale

StarRocks продолжает набирать популярность у команд, которым нужны быстрые аналитические запросы на больших объёмах данных.
Автор поста разобрался в том, как StarRocks используется в продакшене, взял интервью у инженеров и разобрал технические кейсы из таких компаний, как Coinbase, Pinterest, Fresha.

У всех компаний возникла похожая проблема: аналитика для пользователей, построенная на Snowflake, со временем стала слишком медленной.
Обновление данных раз в 15–20 минут уже не устраивало, а сервисам нужен был отклик быстрее секунды, без сложной предварительной денормализации во Flink или Spark.

В Coinbase почти вся аналитика работала на Snowflake, но для криптосервисов понадобился более быстрый Operational Data Store.
TiDB посчитали слишком радикальным изменением архитектуры.
В сравнении с ClickHouse, Pinot и Druid выбрали StarRocks, из-за сочетания быстрого приёма данных, нормальной работы JOIN’ов и возможности обслуживать запросы почти в реальном времени.
Плюс стоимость Snowflake и Databricks для такого сценария оказалась слишком высокой.

В Fresha ситуация была похожей: аналитика на dbt и Snowflake обновлялась каждые 20 минут и стала узким местом.
Они просто взяли существующие SQL-запросы с большим количеством CTE и JOIN’ов и запустили их в StarRocks.
Первый результат около четырёх секунд на сложных запросах, стал хорошей отправной точкой для дальнейшей оптимизации.
С ClickHouse добиться такого старта оказалось сложнее.

Pinterest использует StarRocks для инструмента Partner Insights - это аналитические дашборды для рекламодателей, которые отслеживают эффективность кампаний на аудитории более 500 миллионов активных пользователей в месяц.

Изначально система работала на Apache Druid, но со временем возникли ограничения по задержкам и эффективности инфраструктуры. После миграции на StarRocks компания добилась снижения p90 latency примерно на 50%.
При этом новая система использует около 32% от прежнего объёма инфраструктуры.
В пересчёте на соотношение цена/производительность это примерно трёхкратное улучшение.

Архитектура кластера включает 70 backend-узлов и 11 frontend-узлов.
Поддержка MySQL-совместимого протокола упростила интеграцию с существующими инструментами и сервисами.
Важным фактором стала и нативная загрузка данных в StarRocks - это позволило отказаться от тяжёлых MapReduce-задач в пайплайне, которые ранее использовались вместе с Druid.

В обсуждениях этой миграции на Reddit пользователи Druid и ClickHouse отмечали различия в подходах к архитектуре и работе с JOIN’ами, подчёркивая, что выбор движка во многом зависит от характера нагрузки и требований к задержке.

Главный технический аргумент в пользу StarRocks - производительность JOIN’ов.
Он использует распределение данных по хэш-ключам и colocation, чтобы минимизировать сетевые пересылки, а также кэширование и cost-based optimizer.
Кроме того, StarRocks может работать напрямую с данными в lakehouse (Iceberg, Delta Lake, Hudi, Hive), не требуя их переноса.

При этом у технологии есть ограничения: сообщество меньше, чем у ClickHouse, узнаваемость ниже, а экосистема менее зрелая.

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

@tldr_data