ClickHouse — это высокопроизводительная колоночная система управления базами данных (СУБД), предназначенная в первую очередь для аналитических запросов (OLAP): быстрых агрегаций, фильтрации и построения отчётов на больших объёмах данных (события, логи, метрики, клики, транзакции).
В отличие от классических “транзакционных” баз (OLTP), которые оптимизируются под частые точечные записи/обновления строк, ClickHouse оптимизирован под сценарий: записали много событий → быстро и часто читаем и агрегируем.
Подписывайтесь на мой канал в Телеграмм, чтобы ничего не пропустить.
Ну или на канал в VK, если хотите видеть новые статьи у себя в ленте.
Как работает: колоночное хранение
Ключевая идея ClickHouse — колоночное хранение: данные физически хранятся не “строками”, а “столбцами”.
Это даёт два больших выигрыша для аналитики:
- Читается только то, что нужно запросу
Если запрос использует 3 столбца из 50 — ClickHouse может прочитать с диска в основном эти 3 столбца, а не всю строку целиком. - Сильное сжатие + быстрые агрегации
В одном столбце часто лежат однотипные значения (например, country, status, event_type), поэтому данные хорошо сжимаются, а агрегировать их эффективнее.
Для каких задач ClickHouse обычно выбирают
Типичные сценарии, где ClickHouse особенно хорош:
- продуктовая аналитика (события пользователей, клики, воронки);
- логи и наблюдаемость (observability): логи, метрики, трассировки;
- BI-отчётность и дашборды, где много GROUP BY, COUNT, SUM, перцентилей;
- аналитика нагрузочного тестирования: хранение результатов прогонов, latency, ошибок, таймингов.
Чем ClickHouse отличается от PostgreSQL/MySQL (в двух словах)
- PostgreSQL/MySQL (OLTP): отлично для транзакций, консистентных обновлений строк, связей, небольших выборок по индексам.
- ClickHouse (OLAP): отлично для сканирования больших массивов, агрегаций и быстрых отчётов; обновления/удаления строк — не его “любимая” операция (обычно данные добавляют батчами/потоком событий).
Чем ClickHouse отличается от Olap кубов
OLAP‑кубы и ClickHouse решают одну “аналитическую” задачу, но находятся на разных уровнях стека и по‑разному отвечают на вопрос: где лежат данные и как быстро получить агрегации.
1) Что это вообще такое (уровень абстракции)
ClickHouse — это колоночная аналитическая СУБД (движок хранения + SQL + выполнение запросов). Ты загружаешь “сырые” факты (events/логи/транзакции) и делаешь запросы с агрегациями на лету или через материализации.
OLAP‑куб — это обычно предагрегированная многомерная модель (семантический слой), где данные организованы как меры (measures) и измерения (dimensions), а многие агрегаты считаются заранее (или кэшируются), чтобы интерактивно “крутить” срезы (slice/dice, drill‑down).
То есть грубо:
- ClickHouse = “база/движок”.
- Куб = “модель + заранее посчитанные (или кэшируемые) агрегаты для BI”.
2) Как достигается скорость
ClickHouse
- ускоряет за счёт колоночного хранения, сжатия, пропусков данных (data skipping), параллелизма, векторизации;
- агрегаты обычно считаются по запросу (ad‑hoc) на больших объёмах;
- можно ускорять через материализованные представления / агрегирующие таблицы, но это опционально и гибко.
OLAP‑куб
- ускоряет за счёт предагрегаций (и/или специального хранилища куба, индексов, кэшей);
- “плата” за интерактивность — ограничения в гибкости запросов и необходимость заранее спроектировать измерения/иерархии/меры.
3) Гибкость запросов и “ad‑hoc аналитика”
- В ClickHouse ты можешь задавать очень разнообразные SQL‑запросы (включая новые фильтры/группировки), пока это укладывается в данные и схему. Хорошо подходит, когда вопросы меняются часто: “а давай посмотрим ещё по новому параметру”.
- Куб хорош, когда у тебя стабильный набор бизнес‑измерений и типовых разрезов (“страна → регион → город”, “продукт → категория”, “дата → месяц → квартал”) и нужно, чтобы BI летал для многих пользователей. Но “внезапно добавить новое измерение/метрику” может означать перерасчёт/перестройку.
4) Данные: сырые vs подготовленные
- ClickHouse часто хранит сырые факты (event‑лог), плюс отдельные витрины/агрегаты при необходимости.
- Куб обычно строится поверх подготовленной модели (звезда/снежинка, витрина), где уже определены измерения, ключи, иерархии, меры и правила агрегации.
5) Консистентность, обновления, latency
- ClickHouse часто используют для near‑real‑time аналитики: данные можно заливать потоково, и они почти сразу доступны для запросов (зависит от пайплайна и настроек).
- Кубы часто обновляются пакетно (ночные/часовые обновления), хотя есть и варианты с near‑real‑time, но сложность и цена обычно выше.
6) Типичный паттерн “как это выглядит в архитектуре”
На практике это не взаимоисключающие вещи:
- Вариант A (без кубов):
ClickHouse → BI (Metabase/Superset/Grafana) напрямую, отчёты и дашборды строятся SQL‑запросами/вьюхами. - Вариант B (с кубом/семантическим слоем):
ClickHouse как хранилище фактов → сверху куб/semantic layer (например, чтобы стандартизировать метрики, дать self‑service, ускорить типовые срезы, разграничить доступ и т.п.).
Как это на практике?
Допустим в Clickhouse мы будем хранить результаты тестовых прогонов.
1) Простая схема: события тестов (таблица фактов)
Представим, ты хочешь хранить результаты автотестов/прогонов.
Что здесь важно:
- PARTITION BY toYYYYMM(ts) — удобно для TTL/удаления старых данных и ускорения запросов по времени.
- ORDER BY (...) — определяет “кластеризацию” данных на диске; это сильно влияет на скорость фильтрации.
- LowCardinality(String) — полезно для строк с небольшим числом уникальных значений (статусы, проект, ветка, suite).
- DateTime64(3) — миллисекунды.
- CODEC(...) — пример компрессии/кодеков (не обязателен, но типичен).
Пример вставки данных
INSERT INTO qa.test_runs
(ts, run_id, suite, test_name, status, duration_ms, project, branch, commit_sha, runner, error_type, error_message)
VALUES
(now64(3), generateUUIDv4(), 'smoke', 'login_should_work', 'passed', 1200, 'web', 'main', 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa', 'runner-1', '', ''),
(now64(3), generateUUIDv4(), 'smoke', 'checkout_should_work', 'failed', 5400, 'web', 'main', 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb', 'runner-1', 'assert', 'expected 200 got 500');
2) (Опционально) справочник: информация о тестах
Если хочешь метаданные отдельно (owner, component, severity):
В ClickHouse справочники не обязательны, но часто удобны для джойнов/обогащения отчётов.
Примеры SQL‑запросов (типовые для ClickHouse)
A) Сколько прогонов и каков процент падений за сутки
B) Топ тестов по числу падений за 7 дней
C) Самые “медленные” тесты (p95) за неделю
Перцентиль в ClickHouse — частая штука для latency.
D) Динамика p95 по часам (для графика)
quantile(0.95) — быстрее, чем quantileExact, но приблизительно.
E) Разрез по причинам ошибок (error_type)
F) JOIN с “измерением” (справочником) тестов
Например, посмотреть падения по компонентам:
Как визуально представить себе ClickHouse?
Визуально ClickHouse удобнее всего представлять как набор “частей” (parts) на диске, где каждый столбец хранится отдельно, а данные внутри этих частей отсортированы по ключу ORDER BY. Плюс обычно есть партиции по времени.
Ниже — на примере таблицы qa.test_runs рассмотренного выше.
1) Как выглядит таблица “логически” (как ты её видишь в SQL)
У тебя как будто обычная таблица:
2) Как это “физически” хранится: колонки отдельно + части
В ClickHouse нет “одного файла на таблицу”. Таблица состоит из множества частей (parts), которые появляются от вставок (INSERT) и потом фоном сливаются (merge).
Если у тебя:
- PARTITION BY toYYYYMM(ts) (партиция = месяц)
- ORDER BY (project, suite, test_name, ts) (сортировка внутри)
То визуально можно думать так:
Грубо:
- каждый part — это кусок данных (обычно много строк);
- внутри part каждый столбец лежит в своём файле (поэтому “column-store”).
3) Как выглядят данные внутри part: не строки, а “колоночные куски”
Один и тот же набор строк, но хранится примерно так (упрощённо):
Главный эффект: запросу, который использует только ts, status, duration_ms, не нужно читать error_message и т.п.
4) “Где магия ускорения”: сортировка + marks (гранулы)
ClickHouse внутри part делит данные на гранулы (granules) — блоки строк, например по ~8192 строк (зависит от настроек). Для каждой гранулы есть “метки” (marks), которые помогают быстро прыгать к нужному месту.
Визуально так:
И для каждой гранулы можно представить “минимальные/максимальные” значения ключа сортировки (упрощённо):
Когда ты делаешь:
ClickHouse может пропустить целые гранулы, которые точно не подходят, и читать только нужные диапазоны в нужных колонках.
5) Чем это отличается от “таблички строками” (Row-store)
В классическом row-store (не ClickHouse) (упрощённо) дисковый блок выглядит как:
В ClickHouse — скорее:
Поэтому:
- аналитика (GROUP BY, агрегации) — очень быстро;
- “прочитать одну строку по первичному ключу” — не основной сценарий (хотя иногда возможно эффективно, если совпадает с ORDER BY и данных мало).
Краткое заключение
ClickHouse — это колоночная аналитическая СУБД, заточенная под быстрые запросы на больших объёмах данных: агрегации, фильтрацию, расчёт перцентилей и построение отчётов почти в реальном времени. Её производительность в типичных OLAP‑сценариях достигается не “магией кубов”, а инженерно понятными механизмами: хранение по столбцам, сильное сжатие, сортировка данных по ORDER BY, разбиение на партиции по времени и возможность пропускать ненужные блоки данных при чтении.
В отличие от OLAP‑кубов, ClickHouse чаще выступает базовым слоем хранения и вычислений: он сохраняет сырые факты (события, логи, метрики, результаты тестов) и позволяет задавать гибкие ad‑hoc запросы на SQL. Кубы же обычно добавляют поверх предопределённую многомерную модель и предагрегации для максимально быстрых типовых срезов в BI — то есть решают больше задачу стандартизации и интерактивности, чем универсального хранения и вычислений.
Практически это означает: если тебе нужен надёжный “аналитический склад” с высокой скоростью запросов и свободой в постановке вопросов — ClickHouse хорошо подходит как основа. А когда набор метрик стабилизируется и появляется потребность в унификации расчётов и мгновенном self‑service для широкой аудитории, поверх ClickHouse можно (и часто имеет смысл) добавить семантический слой или куб.
Если Вам интересно, что еще можно найти на канале QA Helper, прочитайте статью: Вместо оглавления. Что вы найдете на канале QA Helper - справочник тестировщика?
Если Вам интересны статьи про базы данных, посмотрите раздел: Базы данных и SQL
Не забудьте подписаться на канал, чтобы не пропустить полезную информацию: QA Helper - справочник тестировщика