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

(StarRocks Docs)

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)

Создано при поддержке канала Слайдер Данные

ClickHouse уже не один: StarRocks показывает, что lakehouse-аналитика может быть проще и быстрее»