10 
Содержание
- Что такое федерация данных StarRocks и ClickHouse и зачем она нужна
- Разделение ролей: холодное хранилище и вычислительный слой
- Практика: подключаем ClickHouse к StarRocks
- Готовим таблицу-источник на стороне ClickHouse
- Создаем внешний каталог JDBC в StarRocks
- Кросс-системный запрос с джойном двух баз из StarRocks и ClickHouse
- Анализ проброса предикатов Predicate Pushdown
- Заключение
- Референсные ссылки
Выбор между StarRocks и ClickHouse часто ставят как или-или. Но зрелый ландшафт данных строят иначе: две базы не конкурируют, а дополняют друг друга. ClickHouse отлично держит холодные петабайты логов и событий, а StarRocks выступает вычислительным слоем для сложных ad-hoc запросов BI. Связать их позволяет федерация данных. В этой статье поднимем внешний каталог StarRocks к ClickHouse, выполним кросс-системный запрос с джойном таблиц из двух баз и разберем проброс предикатов, за счет которого фильтрация уходит на сторону ClickHouse.
Статья завершает серию про StarRocks и опирается на стенд из первой публикации, где обе базы содержат схему shop. Ничего заново грузить не нужно, все таблицы уже на месте. Стать востребованным архитектором данных можно, только понимая сильные стороны разных инструментов, поэтому по ходу отмечаем, какую роль играет каждая база.
Что такое федерация данных StarRocks и ClickHouse и зачем она нужна
Федерация данных это подход, при котором запрос обращается к данным в нескольких системах так, будто они лежат в одной. Движок-инициатор не копирует данные к себе заранее, а читает их из внешнего источника на лету и объединяет с локальными таблицами. Для StarRocks внешним источником может быть Hive, Iceberg, а также другая СУБД через JDBC, в том числе ClickHouse.
Смысл в том, чтобы не устраивать дорогую миграцию. Если исторические логи уже годами копятся в ClickHouse, переливать их в StarRocks дорого и часто бессмысленно. Проще оставить их там, где они есть, а StarRocks научить читать их по запросу. Тогда свежие оперативные данные живут в StarRocks, холодная история в ClickHouse, а аналитик пишет один запрос, который джойнит и то, и другое.
Технически федерация в StarRocks работает через внешний каталог. Каталог это описание подключения и отображение метаданных чужой базы на структуры StarRocks. Данные при этом не копируются и не дублируются, движок читает их из источника в момент запроса. Этим федерация отличается от репликации и классического ETL, где создается вторая физическая копия данных, которую надо поддерживать в актуальном состоянии. Здесь копии нет, а значит нет и расхождения между источником и витриной.
Построение DWH на ClickHouse
Код курса
CLICH
Ближайшая дата курса
12 октября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
76 800
Разделение ролей: холодное хранилище и вычислительный слой
У каждой базы своя сильная сторона, и федерация позволяет использовать обе, не выбирая одну. Ниже роли, которые они играют в гибридном ландшафте.
- ClickHouse как холодное или теплое хранилище. Он дешево и плотно хранит огромные плоские таблицы логов и событий, сканирует их с высокой скоростью и служит архивом истории.
- StarRocks как вычислительный слой. Он берет на себя сложные ad-hoc запросы BI со множеством соединений, работает по нормализованной схеме и через свой оптимизатор строит эффективные распределенные планы.
Таким образом, миграция перестает быть страшной. Не нужно выбирать между базами и переносить терабайты. Достаточно соединить их каталогом и распределить нагрузку по сильным сторонам каждой.
Чтобы решение было осознанным, полезно сравнить федерацию с полной миграцией в одну базу.
| Критерий | Федерация через каталог | Полная миграция в одну базу |
|---|---|---|
| Стоимость внедрения | низкая, только описание каталога | высокая, перелив терабайтов данных |
| Свежесть данных | читает актуальные данные источника | зависит от расписания переливки |
| Дублирование хранения | копии нет, данные остаются в источнике | появляется вторая копия |
| Скорость тяжелых кросс-запросов | ограничена сетью и пробросом предикатов | максимальная, все данные локально |
| Когда уместно | история запрашивается редко, миграция дорога | кросс-запросы часты и критичны по скорости |
Практика: подключаем ClickHouse к StarRocks
Все команды StarRocks собраны в файл ~/article05/federation.sql и выполняются через MySQL-клиент. Команды ClickHouse запускаем через клиент в контейнере.
Готовим таблицу-источник на стороне ClickHouse
Роль холодного хранилища сыграет большая таблица order_items, которая уже загружена в ClickHouse в первой статье. В реальном ландшафте на ее месте были бы петабайты логов. Убедимся, что таблица на месте и в ней есть строки.
# протестировано для ClickHouse 26.3 docker exec -it clickhouse clickhouse-client --user default --password Str0ngPass \ --query "SELECT count() FROM shop.order_items"
Создаем внешний каталог JDBC в StarRocks
Внешний каталог это описание подключения к другой базе. StarRocks через него видит таблицы ClickHouse как свои внешние. Драйвер clickhouse—jdbc скачивают ноды FE и BE по ссылке driver_url, поэтому им нужен доступ к этому адресу. Хост clickhouse это имя сервиса в docker—compose, по нему StarRocks дотягивается до ClickHouse внутри общей сети стенда.
-- протестировано для StarRocks 3.5.0, драйвер clickhouse-jdbc 0.4.6
CREATE EXTERNAL CATALOG clickhouse_catalog
PROPERTIES (
"type" = "jdbc",
"user" = "admin",
"password" = "Str0ngPass",
"jdbc_uri" = "jdbc:clickhouse://clickhouse:8123?autoCommit=true&compress=0",
"driver_url" = "https://repo1.maven.org/maven2/com/clickhouse/clickhouse-jdbc/0.4.6/clickhouse-jdbc-0.4.6-all.jar",
"driver_class" = "com.clickhouse.jdbc.ClickHouseDriver"
);
После создания каталога можно ходить по ClickHouse, не покидая консоль StarRocks. Команда SET CATALOG переключает активный каталог.
SHOW CATALOGS; SET CATALOG clickhouse_catalog; SHOW DATABASES; SHOW TABLES FROM clickhouse_catalog.shop; -- возвращаемся к локальным таблицам StarRocks SET CATALOG default_catalog;
Каталог создается один раз и хранится в метаданных StarRocks, его видят все пользователи кластера. Работает он на чтение: через JDBC-каталог удобно выбирать и джойнить данные ClickHouse, но писать в них из StarRocks не следует, источник остается под управлением своей базы. Переключение между каталогами командой SET CATALOG стоит копейки, это операция с метаданными, а не с данными. Отдельно отметим, что JDBC-каталог к ClickHouse в StarRocks помечен как экспериментальный, поэтому на проде его стоит обкатать на своих запросах.
Кросс-системный запрос с джойном двух баз из StarRocks и ClickHouse
Теперь главное. Соединяем локальную таблицу orders из StarRocks с холодной order_items из ClickHouse в одном запросе. Полное имя вида каталог, база, таблица однозначно говорит, где лежат данные. StarRocks сам решает, что прочитать из ClickHouse, а что взять локально, и объединяет результат.
SELECT
o.status,
COUNT(*) AS items_cnt,
SUM(ci.quantity) AS total_qty
FROM default_catalog.shop.orders o
JOIN clickhouse_catalog.shop.order_items ci ON o.order_id = ci.order_id
WHERE o.order_date >= '2025-04-01'
AND o.status = 'paid'
AND ci.quantity >= 8
GROUP BY o.status;
Запрос при этом обычный. Никакого специального синтаксиса федерации в нем нет, только полные имена таблиц с указанием каталога. Всю остальную работу, распределение чтения между базами и объединение результатов, StarRocks берет на себя. Для аналитика граница между двумя системами становится прозрачной, он думает о задаче, а не о том, где физически лежат данные.
Конечно нужно учитывать что обе базы StarRocks и ClickHouse запущенны на одном хосте в докере и «делят» (конкурируют за) общие ресурсы, поэтому производительность (28.62 сек) здесь не главное!?
Проектирование Online-хранилищ данных на StarRocks.
Код курса
STAR
Ближайшая дата курса
7 сентября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
76 800
Анализ проброса предикатов Predicate Pushdown
Наивная федерация выкачала бы всю внешнюю таблицу по сети и фильтровала бы уже у себя. Это медленно и дорого. StarRocks поступает умнее и пробрасывает предикат на сторону ClickHouse. Условие ci.quantity больше или равно 8 уезжает в ClickHouse, тот фильтрует строки у себя и отдает по сети только подходящие. Смотрим план.
EXPLAIN
SELECT
o.status,
COUNT(*) AS items_cnt,
SUM(ci.quantity) AS total_qty
FROM default_catalog.shop.orders o
JOIN clickhouse_catalog.shop.order_items ci ON o.order_id = ci.order_id
WHERE o.order_date >= '2025-04-01'
AND o.status = 'paid'
AND ci.quantity >= 8
GROUP BY o.status;
В плане у скана внешней таблицы order_items ( внизу таблицы 2:SCAN JDBC) ищите проброшенное условие quantity больше или равно 8. Если оно там есть, значит фильтрация выполняется на стороне ClickHouse до передачи по сети, и по проводу едет меньше данных. Важно знать границу: StarRocks пробрасывает сравнения, IN, IS NULL и BETWEEN, но не пробрасывает вызовы функций. Поэтому фильтр стройте на простых сравнениях по колонкам, а не на функциях, если хотите, чтобы он уехал в ClickHouse.
mysql> explain SELECT
-> o.status,
-> COUNT(*) AS items_cnt,
-> SUM(ci.quantity) AS total_qty
-> FROM default_catalog.shop.orders o
-> JOIN clickhouse_catalog.shop.order_items ci ON o.order_id = ci.order_id
-> WHERE o.order_date >= '2025-04-01'
-> AND o.status = 'paid'
-> AND ci.quantity >= 8
-> GROUP BY o.status;
| PARTITION: UNPARTITIONED |
| |
| RESULT SINK |
| |
| 10:EXCHANGE |
| |
| PLAN FRAGMENT 1 |
| OUTPUT EXPRS: |
| PARTITION: HASH_PARTITIONED: 12: status |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 10 |
| UNPARTITIONED |
| |
| 9:Decode |
| | <dict id 12> : <string id 4> |
| | |
| 8:AGGREGATE (merge finalize) |
| | output: count(9: count), sum(10: sum) |
| | group by: 12: status |
| | |
| 7:EXCHANGE |
| |
| PLAN FRAGMENT 2 |
| OUTPUT EXPRS: |
| colocate exec groups: ExecGroup{groupId=1, nodeIds=[0, 1, 4, 5, 6]} |
| PARTITION: RANDOM |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 07 |
| HASH_PARTITIONED: 12: status |
| |
| 6:AGGREGATE (update serialize) |
| | STREAMING |
| | output: count(*), sum(8: quantity)
| | |
| 4:HASH JOIN |
| | join op: INNER JOIN (BROADCAST) |
| | colocate: false, reason: |
| | equal join conjunct: 11: cast = order_id |
| | |
| |----3:EXCHANGE |
| | |
| 1:Project |
| | <slot 11> : CAST(1: order_id AS LARGEINT) |
| | <slot 12> : 12: status |
| | |
| 0:OlapScanNode |
| TABLE: orders |
| PREAGGREGATION: ON |
| PREDICATES: 3: order_date >= '2025-04-01', DictDecode(12: status, [<place-holder> = 'paid']) |
| partitions=1/1 |
| rollup: orders |
| tabletRatio=48/48 |
| tabletList=13063,13065,13067,13069,13071,13073,13075,13077,13079,13081 ... |
| cardinality=9154400 |
| avgRowSize=34.666664 |
| |
| PLAN FRAGMENT 3 |
| OUTPUT EXPRS: |
| PARTITION: UNPARTITIONED |
| |
| STREAM DATA SINK |
| EXCHANGE ID: 03 |
| UNPARTITIONED |
| |
| 2:SCAN JDBC |
| TABLE: order_items |
| QUERY: SELECT order_id, quantity FROM order_items WHERE (quantity >= 8) |
+---------------------------------------------------------------------------------------------------+
Отсюда вытекает главное правило производительности федерации. Узкое место это сеть между базами, а не сами базы. Задача инженера сделать так, чтобы через сеть ехало как можно меньше строк. Помогают три приема: держите фильтры на простых сравнениях, чтобы они пробрасывались, ограничивайте выборку из холодной таблицы по времени или ключу, и не тяните колонки, которые не нужны в результате. Если один и тот же кросс-запрос выполняется часто и остается тяжелым, разумно материализовать нужный срез холодных данных в StarRocks отдельной таблицей или материализованным представлением, а федерацию оставить для редких обращений к глубокой истории.
Заключение
Федерация снимает ложный выбор между StarRocks и ClickHouse. Внешний каталог связывает две базы, кросс-системный запрос джойнит их таблицы в одном SELECT, а проброс предикатов держит трафик по сети минимальным, отдавая тяжелую фильтрацию туда, где лежат холодные данные. В таком ландшафте ClickHouse остается быстрым архивом логов, а StarRocks становится вычислительным слоем для сложной аналитики. Миграция уступает место интеграции.
На этом серия завершается. Мы прошли путь от сравнения движков и настройки оптимизатора до потоковой загрузки, витрин и федерации. Строить подобные распределенные ландшафты умеет архитектор, который знает сильные стороны обоих инструментов. Изучить StarRocks и построение online-хранилищ можно на курсе Проектирование Online-хранилищ данных на StarRocks (код STAR), а глубже разобраться в ClickHouse на курсе по ClickHouse (код CLICH). Обсудить построение гибридных хранилищ вживую можно на митапе Школы Больших Данных.
Референсные ссылки
- StarRocks, JDBC-каталог, документация 2026
- StarRocks, обзор каталогов и федерации, документация 2026
- StarRocks version 3.5, release notes, май 2026
- ClickHouse JDBC driver, документация 2026
