StarRocks дал аналитикам право строить витрины без тестовых кластеров

Компания перешла с Oracle на StarRocks, Airflow и dbt, чтобы 25 аналитиков могли сами собирать витрины через Git, а три инженера данных обслуживали всю платформу. Запросы, которые раньше работали десятки минут, теперь укладываются в 14 секунд в 99 процентах случаев. Главное изменение — отказ от отдельных dev-стендов и передача контроля над трансформациями аналитикам при сохранении безопасности через ресурсные группы и ревью кода.

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

Двухлетняя история началась с Oracle, где запросы занимали от 20 минут до часа, а процедуры на тысячи строк кода жили без контроля изменений. Рост клиентской базы и продуктов делал ситуацию критической. При выборе OLAP-решений отвергли Vertica и Redshift из-за закрытого кода и растущей стоимости. Greenplum тоже не подошёл: требовались однотипные серверы, RAID из быстрых дисков и отдельный DBA, а два форка зависели от одной компании каждый.

В итоге сравнили StarRocks, ClickHouse и TiDB. StarRocks прошёл тест на запросы с десятками JOIN, где ClickHouse упал по OOM, а TiDB показал худшее время. Дополнительно помогла совместимость с MySQL-протоколом, так что аналитики продолжили работать привычными клиентами и BI-инструментами. В ClickBench StarRocks также обошёл TiDB на большинстве конфигураций железа.

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

Как устроили самообслуживание на одном кластере

Кластер работает в режиме shared-nothing. Оркестрация идёт через Airflow с Cosmos, трансформации — через dbt, визуализация — DataLens, каталог — OpenMetadata. Ресурсные группы делят CPU по принципу коммуналки: аналитики получают максимум, пока не стартует продовый пайплайн, тогда приоритет сдвигается в пропорции 1:2 через cpu_weight. При достижении лимита RAM промежуточные результаты сбрасываются на диск, а слишком тяжёлые запросы автоматически останавливаются.

Аналитики могут создавать таблицы только в общей песочнице. В продовых слоях остаётся только чтение. Каждое изменение проходит ревью и апрув инженеров данных. Права на доступ к сырым таблицам описываются в YAML dbt-проектов, что даёт версионирование и возможность проверки. Такой подход убрал необходимость в отдельном dev-кластере: все эксперименты происходят на одном проде под жёсткими квотами.

Архитектура shared-nothing подразумевает независимые узлы без общего хранилища, что упрощает горизонтальное расширение и снижает точки отказа. Ресурсные группы позволяют динамически перераспределять вычислительные мощности между фоновыми процессами и интерактивными запросами, предотвращая взаимные блокировки. Песочница с ограниченным доступом к записи даёт аналитикам свободу экспериментов, но требует строгого контроля через ревью кода, чтобы ошибки не повлияли на основные данные. Использование dbt для описания прав и трансформаций обеспечивает traceability изменений и упрощает аудит доступа, что критично при оценке соответствия внутренним политикам безопасности. Отказ от тестового кластера сокращает затраты на оборудование, однако повышает важность точной настройки лимитов и мониторинга, чтобы нестабильные запросы не снижали общую доступность.

Что изменилось в работе команды и где риски

Три инженера данных теперь тратят время не на выполнение запросов аналитиков, а на поддержку пайплайнов и ревью. 25 аналитиков самостоятельно разрабатывают витрины, а основные отчёты отдаются за секунды вместо десятков минут. При этом не потребовалось нанимать новых людей и покупать тестовое железо.

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

Ограничения подхода и когда он не подойдёт

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

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

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: StarRocks дал аналитикам право строить витрины без тестовых кластеров.

Курс по теме — Проектирование Online-хранилищ данных на StarRocks