Что такое ClickHouse и почему его выбирают для аналитики

Короткий ответ

ClickHouse — open-source колоночная система управления базами данных для OLAP, то есть аналитической обработки. Её задача — отвечать на вопросы вроде «сколько покупок по каждому городу за каждый день за последний год» по очень большим таблицам, причём достаточно быстро для дашбордов и исследования данных на лету.

Аналитики выбирают её за сочетание высокой скорости запросов, сильного сжатия и привычного SQL.

Колоночное хранение: откуда скорость

Классическая база вроде PostgreSQL хранит данные по строкам: все поля одной записи лежат рядом. Это идеально для задачи «достать заказ №1042 и обновить статус».

ClickHouse хранит данные по колонкам: все значения city вместе, все значения amount вместе и так далее. Для аналитики это всё меняет:

• Запрос, которому нужны 3 колонки из 50, читает с диска только эти 3.
• Значения в одной колонке похожи друг на друга, поэтому отлично сжимаются.
• Обработка идёт пачками значений (векторное выполнение), процессор используется эффективно.

Сжатие настраивается для каждой колонки. По умолчанию LZ4; ZSTD сжимает сильнее, а специальные кодеки Delta, DoubleDelta или Gorilla помогают с временными метками и метриками.

MergeTree: основной движок таблиц

Большинство таблиц в ClickHouse используют движки семейства MergeTree:

• Каждая вставка создаёт на диске неизменяемый кусок (part); фоновые процессы сливают куски в более крупные.
• ORDER BY задаёт сортировку данных и строит разреженный первичный индекс — он указывает на блоки строк (гранулы), а не на каждую строку.
• PARTITION BY делит данные, обычно по месяцам или дням, чтобы старые партиции было легко удалять.

Специализированные варианты решают типовые задачи: ReplacingMergeTree (оставляет последнюю версию строки), SummingMergeTree и AggregatingMergeTree (предагрегация при слиянии), а также Replicated-версии для репликации.

CREATE TABLE events
(
    event_time DateTime,
    user_id    UInt64,
    event_type LowCardinality(String),
    url        String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time);

SELECT event_type, count() AS events, uniq(user_id) AS users
FROM events
WHERE event_time >= now() - INTERVAL 7 DAY
GROUP BY event_type
ORDER BY events DESC;

Типичные задачи

• Продуктовая и веб-аналитика: клики, просмотры, воронки, удержание.
• Логи событий приложений и сервисов.
• Observability: логи, метрики и трассировки в больших объёмах.
• Реклама и маркетинг: показы, атрибуция, отчёты по кампаниям.
• Бизнес-дашборды в BI-инструментах, которые должны оставаться быстрыми на длинной истории.

Общий признак: много событий, которые только добавляются, редкие изменения и запросы, агрегирующие много строк.

ClickHouse и PostgreSQL

На практике многие системы используют обе: PostgreSQL обслуживает продукт, а события и копии бизнес-данных попадают в ClickHouse через ETL или change data capture для отчётов.

Частые ошибки

• Вставлять по одной строке. Каждая вставка создаёт кусок, и тысячи мелких вставок перегружают слияния. Собирайте пачки или используйте асинхронные вставки.
• Небрежно выбирать ORDER BY. Первыми ставьте колонки, по которым чаще всего фильтруете.
• Использовать как OLTP-базу с частым обновлением отдельных строк.
• Переходить на ClickHouse слишком рано. Если PostgreSQL с хорошими индексами справляется с отчётами, вторая база может быть пока не нужна.