ClickHouse для аналитики

01Идея: колонки, а не строки

Представьте таблицу с миллиардом просмотров страниц. Чтобы ответить на вопрос «просмотры по странам за прошлую неделю», строковое хранилище должно прочитать каждую строку со всеми её двадцатью колонками. Колоночное хранилище держит каждую колонку в отдельном файле: оно читает только дату и страну, а это крошечная доля данных. Значения в одной колонке похожи (много повторяющихся стран), поэтому они очень хорошо сжимаются, а CPU может обрабатывать их пачками с помощью векторных инструкций. Компромисс: получить или обновить одну полную строку медленнее, и ClickHouse не рассчитан на множество мелких транзакционных обновлений. OLTP (заказы, пользователи) остаётся в реляционной базе; OLAP (вопросы по истории) — сюда.

• OLTP: много мелких чтений и записей отдельных записей, с транзакциями.
• OLAP: немного больших запросов, которые сканируют и агрегируют множество записей.
• Векторное выполнение: обработка блока значений за одну операцию CPU вместо одного значения за раз.

02Таблицы MergeTree и ключ сортировки

Почти каждая таблица использует движок из семейства MergeTree. Каждая вставка записывает неизменяемый part, отсортированный по ключу ORDER BY, а фоновые слияния объединяют мелкие parts в крупные. Первичный индекс разреженный: он хранит одну запись на гранулу (по умолчанию 8,192 строки), поэтому достаточно мал, чтобы оставаться в памяти. Когда запрос фильтрует по ведущим колонкам ORDER BY, ClickHouse пропускает гранулы, которые не могут подойти. Поэтому выбор ORDER BY — самое важное проектное решение: сначала колонки с низкой кардинальностью, по которым вы фильтруете всегда (тенант, тип события), затем время. PARTITION BY нужен для управления данными (удаления старых месяцев), а не для скорости; держите партиции крупными.

1CREATE TABLE events
2(
3    tenant_id   UInt32,
4    event_type  LowCardinality(String),
5    event_time  DateTime64(3, 'UTC'),
6    user_id     UInt64,
7    url         String,
8    country     LowCardinality(String),
9    properties  JSON
10)
11ENGINE = MergeTree
12PARTITION BY toYYYYMM(event_time)
13ORDER BY (tenant_id, event_type, event_time)
14TTL toDateTime(event_time) + INTERVAL 13 MONTH DELETE;

03Как правильно вставлять данные

ClickHouse любит большие пачки и ненавидит мелкие вставки. Каждый INSERT создаёт как минимум один part, а тысячи однострочных вставок в секунду создают тысячи parts, что вызывает знаменитую ошибку «too many parts». Группируйте на клиенте (от тысяч до сотен тысяч строк на вставку, примерно раз в секунду) или включите асинхронные вставки, чтобы сервер буферизовал мелкие записи за вас. Данные обычно приходят через очередь (Kafka, воркер на Redis, HTTP-коллекторы) и сбрасываются пачками. Форматы вроде JSONEachRow, CSV, Parquet и нативный формат поддерживаются по HTTP (порт 8123) или по нативному протоколу (9000).

1# Batch insert over HTTP from a file of JSON lines
2curl -u your_user:your_password \
3  'http://localhost:8123/?query=INSERT%20INTO%20events%20FORMAT%20JSONEachRow' \
4  --data-binary @events.ndjson
5 
6-- Or let the server batch small inserts
7INSERT INTO events SETTINGS async_insert = 1, wait_for_async_insert = 1
8FORMAT JSONEachRow {"tenant_id":1,"event_type":"page_view","event_time":"2026-11-05 10:00:00","user_id":7,"url":"/","country":"AM","properties":{}}

04Аналитический SQL

ClickHouse говорит на SQL с множеством аналитических дополнений. uniq() и uniqExact() считают уникальных пользователей (uniq приближённый и намного быстрее), quantile() вычисляет перцентили, countIf() и sumIf() фильтруют внутри агрегатов, а windowFunnel() и retention() напрямую отвечают на продуктовые вопросы. Массивы и map — полноценные типы, а тип JSON хранит полуструктурированные свойства как типизированные подколонки. Всегда фильтруйте по ведущим колонкам ORDER BY и диапазону времени, выбирайте только нужные колонки (никогда не делайте SELECT * по широкой таблице) и используйте LIMIT при исследовании данных.

1SELECT
2    toStartOfDay(event_time)                      AS day,
3    uniq(user_id)                                 AS visitors,
4    countIf(event_type = 'purchase')              AS purchases,
5    round(purchases / visitors * 100, 2)          AS conversion_pct
6FROM events
7WHERE tenant_id = 1
8  AND event_time >= now() - INTERVAL 30 DAY
9GROUP BY day
10ORDER BY day;

05Materialized views для быстрых дашбордов

Materialized view в ClickHouse — это триггер на вставку: когда строки приходят в исходную таблицу, view выполняет свой SELECT только над этой новой пачкой и пишет результат в целевую таблицу. Вместе с SummingMergeTree или AggregatingMergeTree это поддерживает предагрегированные rollup-таблицы (по часам, по тенантам) всегда актуальными, и дашборды читают тысячи строк вместо миллиардов. При записи используйте комбинаторы -State, а при чтении -Merge, потому что частичные агрегаты из разных parts нужно сливать. Помните, что view видит только новые вставки; исторические данные заполняйте отдельно через INSERT INTO ... SELECT.

1CREATE TABLE events_hourly
2(
3    tenant_id UInt32, hour DateTime, event_type LowCardinality(String),
4    events UInt64, users AggregateFunction(uniq, UInt64)
5)
6ENGINE = AggregatingMergeTree ORDER BY (tenant_id, event_type, hour);
7 
8CREATE MATERIALIZED VIEW events_hourly_mv TO events_hourly AS
9SELECT tenant_id, toStartOfHour(event_time) AS hour, event_type,
10       count() AS events, uniqState(user_id) AS users
11FROM events GROUP BY tenant_id, hour, event_type;
12 
13-- Read: SELECT hour, sum(events), uniqMerge(users) FROM events_hourly WHERE tenant_id = 1 GROUP BY hour;

06Как запускать: один узел, кластер или облако

Один сервер ClickHouse выдерживает гораздо больше, чем ожидает большинство команд, — часто миллиарды строк на одной машине с быстрыми NVMe-дисками. Для высокой доступности используйте таблицы ReplicatedMergeTree, которые координирует ClickHouse Keeper (встроенная замена ZooKeeper); для большей ёмкости шардируйте данные по узлам через таблицу Distributed. ClickHouse Cloud отделяет хранение (объектное хранилище) от вычислений и снимает большую часть этой работы — за цену по потреблению. Что бы вы ни выбрали: создавайте пользователей с минимальными правами, не открывайте порты 8123 и 9000 в публичный интернет, задавайте лимиты на запросы (max_memory_usage, max_execution_time) для каждого пользователя и делайте бэкапы через BACKUP TO S3 или snapshot вашего провайдера.

07Parts, гранулы и как запрос пропускает данные

Каждый part на диске — это директория с отдельным файлом на каждую колонку (wide-формат) плюс primary.idx и файлы засечек (marks). Засечки указывают на начало каждой гранулы внутри сжатых файлов колонок. При выполнении запроса ClickHouse бинарным поиском по primary.idx находит диапазон гранул, чьи значения ORDER BY могут подойти, читает только засечки для этих гранул и распаковывает только эти блоки запрошенных колонок. Индексы пропуска данных (minmax, set, bloom_filter) добавляют сводки по гранулам для колонок вне ключа сортировки. Используйте EXPLAIN indexes = 1, чтобы увидеть, сколько parts и гранул выбрано из общего числа; фильтр, выбирающий 95% гранул, — это замаскированное полное сканирование.

1EXPLAIN indexes = 1
2SELECT count() FROM events
3WHERE tenant_id = 1 AND event_time >= now() - INTERVAL 1 DAY;
4 
5-- A skipping index for a column outside ORDER BY
6ALTER TABLE events ADD INDEX idx_url url TYPE bloom_filter GRANULARITY 4;
7ALTER TABLE events MATERIALIZE INDEX idx_url;

08Дедупликация и меняющиеся данные: ReplacingMergeTree и родственники

ClickHouse не обеспечивает уникальность ключей. ReplacingMergeTree оставляет последнюю строку для каждого ключа ORDER BY, выбирая её по колонке версии, но только после слияний, которые происходят в непредсказуемый момент. Запросы, которым нужны точные результаты, используют FINAL (слияние во время чтения; в последних версиях оно намного быстрее, но всё равно стоит ресурсов) или агрегируют через argMax(value, version). CollapsingMergeTree и VersionedCollapsingMergeTree обрабатывают обновления вставкой отменяющей строки с sign -1. Вставки в реплицируемые таблицы дедуплицируются по хэшу блока в течение окна, поэтому повтор той же пачки после таймаута безопасен, если пачка идентична.

1CREATE TABLE users_dim
2( user_id UInt64, plan LowCardinality(String), updated_at DateTime64(3) )
3ENGINE = ReplacingMergeTree(updated_at)
4ORDER BY user_id;
5 
6SELECT plan, count() FROM users_dim FINAL GROUP BY plan;

09JOIN-ы, словари и projections

ClickHouse выполняет JOIN-ы, и его планировщик JOIN-ов сильно улучшился в последних релизах, но hash join по умолчанию всё ещё строит правую таблицу в памяти, поэтому держите меньшую таблицу справа и фильтруйте обе стороны до соединения. Для небольших медленно меняющихся таблиц-измерений (страны, тарифы, названия товаров) лучше словари: они загружаются в память и запрашиваются через dictGet(), часто намного быстрее JOIN-а. Projections хранят дополнительную, иначе отсортированную или предагрегированную копию таблицы внутри тех же parts, и оптимизатор использует их автоматически, когда запрос подходит. Они стоят места на диске и времени вставки, поэтому добавляйте их только для доказанно горячих запросов.

10Горизонтальное масштабирование и защита кластера

Сначала масштабируйтесь вертикально: больше ядер и быстрые NVMe дают почти линейный прирост. Когда нужно больше, шардируйте по ключу, соответствующему тенантам (например, cityHash64(tenant_id)), чтобы большинство запросов попадали на один шард, и реплицируйте каждый шард через ReplicatedMergeTree и ClickHouse Keeper (три узла Keeper для кворума). Таблица Distributed рассылает запросы и объединяет результаты. Для multi-tenant аналитики защищайте кластер профилями настроек и квотами: max_memory_usage, max_execution_time, max_rows_to_read и max_concurrent_queries для каждого пользователя, плюс row policies, чтобы пользователь каждого тенанта видел только свои строки. Мониторьте system.query_log, system.parts (parts на партицию) и system.merges и ставьте алерты на количество parts и отставание репликации.