С распространением сценариев 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)