С распространением сценариев real-time аналитики, lakehouse & modern BI всё чаще сталкиваются две флагманские аналитические СУБД: ClickHouse и StarRocks. Одна из ключевых конкурирующих битв ведётся не на маркетинговом поле, а в производительности, гибкости архитектур и удобстве поддержки сложных аналитических схем.
ClickHouse, будучи зрелым и широко используемым решением, зарекомендовал себя как очень быстрый колонковый движок, оптимизированный для агрегаций, фильтров и чтения узкого поднабора колонок из огромных объёмов данных. Он эффективен в задачах логов, телеметрии, веб-аналитики и других OLAP-нагрузках, где схемы часто «расстилаются» — с минимальным числом джоинов и высокой степенью денормализации.
Однако подход ClickHouse — оптимизация работы с плоскими таблицами и минимизация связанных таблиц — становится ограничением, когда бизнес-сценарии требуют моделирования звёздной схемы (fact + dimension) и выполнения динамических запросов с join’ами. В таких случаях ClickHouse часто вынужден либо смягчать нагрузку через ETL денормализацию, либо сталкиваться с трудоёмкими запросами.
Вот где StarRocks начинает оспаривать лидерство. Он предлагает архитектуру, ориентированную на эффективные join и агрегации “на лету”, поддерживая материализованные представления (MV), которые автоматически обслуживаются и подменяются при выполнении запросов. В бенчмарках StarRocks часто показывает преимущество: в тестах на SSB (набор из 13 запросов) StarRocks в среднем быстрее ClickHouse почти вдвое.

Также StarRocks активно развивается, дополняя свою экосистему интеграциями (Iceberg, Hudi, dbt, Flink и др.) и стремясь закрыть разрыв в зрелости экстеншенов, где ClickHouse уже имеет широкую поддержку.
Таким образом, конкурентная точка между ними — это не “кто быстрее агрегацию”, а “насколько ты готов работать со схемами, join’ами и изменениями бизнес-логики без ломки архитектуры”. В следующих частях мы детально посмотрим, в каких сценариях выбирать StarRocks, а где по-прежнему разумнее использовать ClickHouse.
TL;DR: StarRocks — открытый MPP-движок для субсекундной ad-hoc аналитики «на своих таблицах и прямо на озере» (Iceberg/Hudi/Delta). Сильные стороны: векторизированный/pipeline-исполнитель, умные (авто-выбор и авто-обновление) материализованные представления, простая загрузка (Stream Load), и совместимость с MySQL-клиентами. Для старта: запустите all-in-one контейнер, подключитесь mysql-клиентом, создайте БД/таблицы и загрузите CSV через Stream Load.
Обзор решения — что это и зачем
Класс системы. MPP-OLAP/«lakehouse query engine» с субсекундным откликом для многомерной аналитики, real-time и ad-hoc запросов; проект Linux Foundation, лицензия Apache-2.0. (GitHub)
Ключевые фичи.
Векторизированный конвейерный исполнитель и cost-based оптимизация.
Интеллектуальные материализованные представления: автоматическое освежение и автовыбор подходящего MV при выполнении SQL без изменения запроса. Это снимает необходимость в «ручном» денормализованном моделировании и ускоряет тяжёлые join/agg. (StarRocks Docs)
Гибкая загрузка данных: Stream Load (HTTP + curl), Kafka Routine Load, коннекторы к Flink/dbt и прямой доступ к озеру (Iceberg/Hudi/Delta).
Режимы развертывания: от «один контейнер для демо» до кластеров (shared-nothing / shared-data), Kubernetes/Helm и AWS Quick Start.
Активность и зрелость. Живой репозиторий с регулярными релизами/фикcами (поддержка Kafka 4.0, оптимизации cloud-native таблиц, инвертированные индексы и др.). (GitHub)
Архитектура в двух словах
FE (Frontend): метаданные, планирование и маршрутизация запросов.
BE (Backend): хранение сегментов (tablet’ов) и исполнение планов.
В all-in-one образе всё уже собрано, чтобы быстро «пощупать» SQL и загрузку. Для продакшена — FE-HA + BE-шарды (или shared-data через CN).
Первые шаги — самый короткий практический путь
Ниже — полностью воспроизводимый минимальный сценарий с конкретными командами без плейсхолдеров, ориентирован на Linux/macOS с установленным Docker.
1) Запуск all-in-one контейнера
docker run -p 9030:9030 -p 8030:8030 -p 8040:8040 -itd \ --name quickstart starrocks/allin1-ubuntu
9030 — MySQL-порт FE; 8030 — HTTP-порт FE (админ/Stream Load); 8040 — web-UI BE.
Требования минимума для демо: ~4 ГБ RAM и ~10 ГБ диска, выделенные Docker. (StarRocks Docs)
2) Подключение SQL-клиентом (mysql CLI из контейнера)
docker exec -it quickstart \ mysql -P 9030 -h 127.0.0.1 -u root --prompt="StarRocks > "
Пароль по умолчанию не задан — просто нажмите Enter. Можно также использовать DBeaver/MySQL Workbench, указав
127.0.0.1:9030, пользовательroot. (StarRocks Docs)
3) Создание БД и таблиц (минимальный пример)
CREATE DATABASE demo; USE demo; -- Факт-таблица (упрощённая схема под CSV) CREATE TABLE crashes ( crash_date DATETIME, borough VARCHAR(32), zipcode VARCHAR(16), latitude DOUBLE, longitude DOUBLE ) DUPLICATE KEY(crash_date) DISTRIBUTED BY HASH(crash_date) BUCKETS 4 PROPERTIES("replication_num"="1"); CREATE TABLE weather ( obs_time DATETIME, temp_c DOUBLE, vis_km DOUBLE ) DUPLICATE KEY(obs_time) DISTRIBUTED BY HASH(obs_time) BUCKETS 4 PROPERTIES("replication_num"="1");
В Quick Start на docs есть подробный пошаговый сценарий с готовыми схемами и пояснениями. Я привёл компактную версию для быстрого старта.
4) Скачивание демо-датасетов (NYC crashes + NOAA weather)
curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/NYPD\_Crash\_Data.csv curl -O https://raw.githubusercontent.com/StarRocks/demo/master/documentation-samples/quickstart/datasets/72505394728.csv
5) Загрузка через Stream Load (HTTP на порт 8030)
Откройте новый терминал на хосте (не в mysql), выполните:
# Загрузка NYC crashes в таблицу demo.crashes curl --location-trusted -u root: -T NYPD_Crash_Data.csv \ -H "label:crash-load-1" \ -H "column_separator:," \ -H "skip_header:1" \ -H "enclose:\"" \ -H "columns:tmp_CRASH_DATE, tmp_CRASH_TIME, BOROUGH, ZIP_CODE, LATITUDE, LONGITUDE, \ CRASH_DATE=str_to_date(concat_ws(' ', tmp_CRASH_DATE, tmp_CRASH_TIME), '%m/%d/%Y %H:%i'), \ BOROUGH, ZIP_CODE, LATITUDE, LONGITUDE" \ http://127.0.0.1:8030/api/demo/crashes/\_stream\_load # Загрузка NOAA weather в demo.weather (схема под ваш CSV) curl --location-trusted -u root: -T 72505394728.csv \ -H "label:weather-load-1" \ -H "column_separator:," \ -H "skip_header:1" \ -H "columns:obs_time,temp_c,vis_km" \ http://127.0.0.1:8030/api/demo/weather/\_stream\_load
Обратите внимание на
columns:— здесь можно встраивать трансформации (например,str_to_date+concat_ws) прямо во время загрузки.
6) Пробные запросы и join-аналитика
-- Простой фильтр: SELECT borough, COUNT(*) AS n FROM crashes WHERE crash_date >= '2019-01-01' GROUP BY borough ORDER BY n DESC LIMIT 10; -- Джоин с погодой по минутной/часовой агрегации (пример): SELECT c.borough, DATE_TRUNC('hour', c.crash_date) AS h, AVG(w.vis_km) AS avg_vis FROM crashes c LEFT JOIN weather w ON DATE_TRUNC('hour', c.crash_date) = DATE_TRUNC('hour', w.obs_time) GROUP BY c.borough, h ORDER BY h DESC LIMIT 50;
Что делать дальше (короткая «дорожная карта»)
Материализованные представления (MV).
Создайте async MV поверх часто используемых join/agg — StarRocks сам будет подменять план на MV и поддерживать его в актуальном состоянии. Это даёт резкое ускорение без переписывания запросов.Хранилища данных озера.
Подключите внешние таблицы Iceberg/Hudi/Delta и ускоряйте их MV-слоем — без ETL-перекладки.Интеграции.
dbt-adapter (
dbt-starrocks) — для декларативных моделей/трансформаций.Flink-коннектор — стриминг в/из StarRocks.
Продакшн-развёртывание.
Перейдите с all-in-one на кластер: FE-HA + BE (shared-nothing) или FE + CN (shared-data), Helm/Operator или AWS Quick Start.Сборка из исходников / дев-среда.
Есть готовый Docker-образstarrocks/dev-env-ubuntu:latestи скрипты для воспроизводимой сборки.
Где читать / смотреть
Quick Start / Docker-демо (официально): запуск, загрузка CSV, разбор Stream Load. (StarRocks Docs)
Особенности и MV: обзор фич и роль MV в ускорении/упрощении моделей. (StarRocks Docs)
GitHub (основной репо, релизы): активность проекта и изменения. (GitHub)
