ClickHouse — колоночная СУБД для аналитики. В ней хранят данные и выполняют SQL, но проектировали её прежде всего для запросов, которые фильтруют и агрегируют много строк. Например: сколько загрузок завершилось ошибкой за неделю, сколько данных принёс каждый источник и как менялась длительность обработки.
В работе дата-инженера ClickHouse часто находится ближе к выдаче результата: сюда поступают события из Kafka, журналы сервисов или подготовленные файлы, а аналитики и приложения читают показатели. Он может служить аналитическим хранилищем, слоем витрин или базой для оперативных отчётов. Выбор роли зависит от требований к данным, а не от названия технологии.
Для чтения модуля достаточно знать SELECT, WHERE, GROUP BY и JOIN. Сначала разберём колоночное хранение, части MergeTree и ключи, затем — загрузку, витрины и кластер. Установить сервер и получить первый результат можно в практических уроках в конце модуля.
История ClickHouse
Веб-аналитика собирает события о посещениях. Заранее посчитать все возможные сочетания сайта, периода, региона и устройства трудно: пользователь отчёта сам выбирает фильтры. Хранить только готовые суммы тоже недостаточно — новый разрез потребует исходных событий.
ClickHouse появился в Яндексе как эксперимент с расчётом отчётов по неагрегированным данным, которые продолжали поступать. Разработка началась в 2009 году, первые применения в production относятся к 2012 году, открытый исходный код опубликован в 2016 году. Эта исходная задача объясняет сочетание двух требований: быстро принимать новые пачки событий и быстро читать большие объёмы для отчёта.
Тот же характер нагрузки встречается у журналов запросов, телеметрии, рекламных событий и истории запусков ETL.
OLAP и OLTP
OLTP — обработка коротких операций приложения: зарегистрировать запуск, поменять его статус, проверить уникальность идентификатора. Обычно операция затрагивает мало строк и требует согласованных изменений.
OLAP — аналитическая обработка: прочитать историю запусков за месяц, сгруппировать её по источникам и вычислить показатели. Вход может содержать миллионы строк, а результат — десяток строк.
| Задача | Почему подходит PostgreSQL или другая OLTP-база | Почему подходит ClickHouse |
|---|---|---|
| Зарегистрировать один запуск и изменить связанные записи в транзакции | Ограничения, уникальные индексы и транзакции выражают правила приложения | Обычно это не основная роль аналитической базы |
| Найти одну запись по уникальному ключу | Индекс удобен для точного поиска | Возможно, но разреженный индекс MergeTree читает диапазоны строк |
| Посчитать длительность запусков по дням за год | Выполнимо, иногда хватает PostgreSQL | Колоночное чтение, сжатие и параллельная агрегация рассчитаны на такую нагрузку |
| Хранить поток неизменяемых событий | Выполнимо, требуется оценка объёма | Хорошо соответствует модели больших вставок и последующего чтения |
PostgreSQL тоже умеет аналитику, а ClickHouse умеет JOIN, оконные функции, обновления и удаления. Сравнивать нужно стоимость типичной работы и требуемые гарантии. Нельзя считать PRIMARY KEY в ClickHouse заменой ограничения уникальности из PostgreSQL.
Что делает запрос быстрым
Ускорение складывается из нескольких механизмов. Колоночное хранение позволяет читать нужные столбцы. Сортировка и индекс помогают пропустить ненужные диапазоны. Сжатие уменьшает объём чтения с диска. Операции над блоками значений и использование нескольких ядер ускоряют вычисление. Готовая витрина сокращает объём повторной работы.
Стоимость запроса зависит от работы с данными. SELECT * по всей таблице читает и передаёт большой результат; JOIN крупных наборов расходует память; миллионы групп увеличивают состояние агрегации. Частые мелкие вставки нагружают фоновые слияния.
Где проходят границы
ClickHouse стоит рассматривать, когда есть история событий, поток новых данных и регулярные аналитические запросы. Перед выбором полезно выписать объём, скорость поступления, важные фильтры, допустимую задержку и правила обработки повторов.
Если главным требованием является транзакционное изменение нескольких сущностей с немедленной проверкой внешних ключей и уникальности, логичнее оставить эту часть в OLTP-системе. Аналитическую копию можно передавать отдельно. Если данные помещаются в небольшой файл, а анализ выполняется локально, для задачи может быть достаточно DuckDB. Другие аналитические СУБД и облачные хранилища сравнивают по нагрузке, стоимости и условиям эксплуатации; колоночный формат сам по себе не делает их одинаковыми.