Live-данные · обновлено 19 июля 2026 г.

ClickHouse: что это, зачем нужен и как работает аналитическая база

ClickHouse ставят рядом с обычной базой, когда отчёты по кликам, заказам, платежам и логам начинают мешать приложению. Он быстро читает большой слой накопленных событий и отвечает на вопросы по датам, статусам, источникам и суммам.

ДЛДенис Лукьянов·Технический редактор·Эксперт по Data Vault
Вакансий
637
активных в Москве
Медиана зарплаты
287 тыс. ₽
n = 106 вакансий с указанной зарплатой
Индекс спроса
94/100
#21 из 332 навыков
Доля IT-рынка
9.1%
41 профессий

Коротко о навыке

ClickHouse — колоночная аналитическая СУБД, созданная Яндексом; с 2016 года её код открыт. В московских вакансиях медиана по ClickHouse — одна из самых высоких на рынке. Технология входит в стек инженеров данных, DevOps и аналитиков, спрос устойчиво растёт.

Что такое ClickHouse

Что это

База для истории событий: клики, заказы, платежи, ошибки, логи. Не вместо PostgreSQL, а рядом с ним для отчётов.

Где нужен

Когда отчёты каждый день читают много старых данных и уже мешают базе, которая обслуживает приложение.

Что даёт

Даёт быстрый ответ по истории: что выросло, что просело, где ошибка, сколько было денег, заказов или событий.

История, а не текущее состояние

ClickHouse — открытая колоночная СУБД для OLAP-запросов, созданная командой Яндекса и выпущенная в с открытым исходным кодом в 2016 году. Вместо строчного хранения ClickHouse записывает каждый столбец отдельным блоком, при этом с диска читаются только нужные колонки — остальные не трогаются. Система обрабатывает запросы к миллиардам строк за секунды и масштабируется горизонтально через шардирование с репликацией.

Схема решает больше, чем синтаксис

Скорость зависит от колонок, ключа сортировки и того, какие вопросы команда задаёт каждый день. Один и тот же SQL ведёт себя по-разному на разных схемах.

Рабочий уровень начинается до первого запроса

Нужно заранее понять поток данных, дубли, опоздавшие события и типичные фильтры будущих отчётов. Иначе база быстро теряет главное преимущество.

Механика / Работа

Как работает ClickHouse в аналитическом слое

Типовая цепочка начинается не с SELECT, а с события. Данные нужно принять, положить в таблицу, отсортировать под будущие фильтры, дать запросу прочитать минимум лишнего и только потом показывать витрину пользователю. Если ошибка закладывается на этапе загрузки, быстрый запрос потом всё равно вернёт плохую цифру.

Шаг 01

События попадают в таблицу

Данные приходят из приложения, очереди, файла или соседнего хранилища. Важно сохранить время события, источник, идентификаторы и признаки для фильтров отчётов.

Шаг 02

MergeTree раскладывает части

Новые данные сохраняются частями, сортируются по ключу и сливаются в фоне. Плохой порядок сортировки заставит будущие запросы читать слишком широкий диапазон.

Шаг 03

Запрос читает нужные колонки

ClickHouse берёт только поля, нужные выражению, и пропускает лишние участки по сортировке. Поэтому аккуратный фильтр по времени, событию или ключу важнее длинного списка функций.

Шаг 04

Витрина ускоряет частые вопросы

Для регулярных отчётов можно заранее подготовить агрегаты или отдельную таблицу под нужный сценарий. Но у витрины должны быть владелец, задержка обновления и правило пересчёта.

Карьера / Роли

Карьерные треки с ClickHouse

ClickHouse переносится между ролями: Инженер данных, DevOps-инженер, Аналитик данных. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.

Роли с ClickHouse за период

Инженер данных держит 55.7% вакансий по навыку.

Ещё 7 ролей используют ClickHouse

Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.

Практика / Задачи

Частые задачи с ClickHouse

ClickHouse ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.

Задача 01

Собрать таблицу событий

Взять поток фактов и выбрать поля для фильтров и агрегатов.

Задача 02

Подобрать сортировку

Проверить, как меняется чтение при другом ключе.

Задача 03

Построить витрину

Собрать агрегат, который команда будет читать каждый день.

Задача 04

Проверить поздние события

Посмотреть, как опоздание влияет на итоговую цифру.

Задача 05

Сравнить запросы

Разобрать, почему один запрос читает мало, а другой слишком много.

Задача 06

Поймать дубли

Проверить ключ дедупликации до публикации отчёта.

Практика / Ошибки

Ошибки новичков

Ошибка 01

Тащить OLTP-модель без изменений

Схема из транзакционной базы редко хорошо работает на аналитике.

Ошибка 02

Выбирать сортировку наугад

Если ключ не помогает фильтрам, запросы быстро дорожают.

Ошибка 03

Игнорировать дубли и опоздание

База быстро считает, но команда не сможет доверять цифре.

Ошибка 04

Оценивать всё по одному SELECT

Нужно смотреть ещё на загрузку, хранение и поведение витрин.

Рынок / Контекст

Почему ClickHouse востребован

ClickHouse востребован там, где данных уже много, а вопросы к ним повторяются каждый день. Это продуктовая аналитика, наблюдаемость, рекламные факты, внутренние витрины и крупные отчёты. Такие команды быстро понимают, что одной обычной базы уже мало. Ценится не умение написать один запрос, а понимание полного пути события: как оно приехало, куда легло, почему отчёт тормозит и где схема начинает стоить слишком дорого. Особенно это видно на системах, где цифры нужны быстро и без споров о корректности. Здесь уже мало просто знать синтаксис и пару функций. Нужен человек, который понимает цену каждой архитектурной мелочи.

Даёт быстрый ответ по данным

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

Работает в нескольких ролях

Такой навык редко живёт в одной профессии: он остаётся полезным в аналитике, продукте, разработке и соседних data-сценариях.

Остаётся частью базового слоя

Инструменты вокруг меняются, но сама задача не исчезает, поэтому ClickHouse продолжает удерживать прикладной спрос.

Сигнал рынка
Высокий спрос

ClickHouse стабильно удерживается в активном прикладном слое рынка.

Рынок / Спрос

Спрос на ClickHouse на рынке

ClickHouse сохраняет высокий текущий спрос на рынке: 637 активных вакансий, #21 по рынку, 9.1% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.

Сила спроса
Высокий спрос
637
активных вакансий сейчас

#21 по рынку • 9.1% IT-вакансий

Месяц к месяцу
797
июль 2026 — предварительный накопительный срез

-101 вакансий и -11% к предыдущему месяцу.

Доход / Уровни

Зарплаты в вакансиях, где требуется ClickHouse

В московском IT медиана по ClickHouse — одна из самых высоких на рынке, но вилку задают роль и грейд, а не сама СУБД. Prometheus или Kubernetes в стеке дают заметную прибавку. Спрос растёт; актуальные цифры — в рыночном блоке этой страницы.

Медиана рынка
Ограниченная точность
287 000
₽ / месяц

106 вакансий с зарплатой в расширенной зарплатной выборке

Ориентир по грейду
328 000
₽ / месяц

Основной зарплатный ориентир по Senior-вакансиям

Основной уровень
Senior
по структуре рынка

Senior - основной уровень рынка (54%)

Связи / Навыки

Навыки в связке с ClickHouse

ClickHouse редко живёт изолированно: чаще всего рынок видит его рядом с PostgreSQL, Python, SQL. Самая плотная связка сейчас - PostgreSQL: оба навыка встречаются вместе в 66% вакансий.

Главная связка: PostgreSQL • 66% вакансий. Показываем общерыночные связки ClickHouse: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.

Рабочий стек вокруг ClickHouse

навыки, которые рынок чаще всего видит рядом в одной вакансии

Навык Зачем рядом Доля
Одна из самых плотных рыночных связок рядом с ClickHouse.
66%
Часто встречается рядом с ClickHouse в одном рабочем сценарии.
63%
SQL
Часто встречается рядом с ClickHouse в одном рабочем сценарии.
62%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
46%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
46%
Поддерживает соседние процессы и усиливает рабочий контур навыка.
44%

Связки, которые усиливают доход

не базовый минимум, а более сильные комбинации стека

1
Grafana
n = 34
+15% 329 000 ₽
2
Kubernetes
n = 51
+14% 328 000 ₽
3
Linux
n = 39
+14% 328 000 ₽
4
Microservices
n = 43
+13% 325 000 ₽
Вход / Старт

Порог входа

Сейчас на рынке 35 активных junior-вакансий с ClickHouse. Это 6.8% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.

Junior-вакансии сейчас
35
активных вакансий

6.8% всех вакансий по навыку • Senior / Junior 7.9x

Доля junior
6.8%
% всех вакансий по навыку

Окно входа узкое: рынок чаще нанимает с опытом.

Что нужно на старте

Стартовый стек

16
навыков в медианной вакансии

Медианная вакансия с ClickHouse ожидает около 16 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.

Чаще всего требуют вместе

навыки из junior-вакансий, где встречается ClickHouse

Навык Junior-вакансии
SQL
23
22
Apache Airflow
11
10
Сравнение / Инструменты

ClickHouse, PostgreSQL, DWH и Elasticsearch

Здесь чаще всего ошибаются в выборе роли. Смотреть нужно не на громкое название, а на тип нагрузки: транзакции, аналитика, общий слой данных или поиск.

Инструмент За что отвечает Когда нужен Граница

ClickHouse

Колоночная база для аналитики и больших чтений.

Когда нужны быстрые срезы по истории событий и фактов.

Плохо подходит для частых точечных изменений.

PostgreSQL

Транзакционная база для состояния приложения.

Когда важны записи, обновления, связи и ограничения.

На тяжёлой аналитике часто мешает боевой нагрузке.

DWH

Широкий слой хранилища с витринами и правилами качества.

Когда нужно объединять много источников на уровне компании.

ClickHouse может быть движком внутри, но не заменяет весь слой.

Elasticsearch

Поиск по тексту и документам.

Когда главный сценарий — найти запись или фрагмент текста.

Для тяжёлых агрегатов по фактам обычно слабее ClickHouse.

Навык / Применение

Где используется ClickHouse

ClickHouse нужен там, где команда постоянно считает аналитику по событиям, логам или метрикам, а обычная база приложения уже тяжело переносит такие чтения каждый день. Обычно это уже не разовый отчёт, а постоянная рабочая нагрузка.

Сценарий 01

Продуктовая аналитика

События приложения, воронки, сегменты и история поведения.

Сценарий 02

Логи и наблюдаемость

Ошибки, задержки, метрики и крупные разборы по времени.

Сценарий 03

Витрины отчётности

Финансовые, рекламные и операционные срезы по большому слою фактов.

Сценарий 04

Поток событий

Очереди, загрузки и append-heavy данные с контролем дублей.

По направлениям

ClickHouse заметен в 5 направлениях рынка с долей выше 5%.

Направление Контекст Доля
Разработка
Схема БД, запросы приложения и разбор производительности.
26.1%
Аналитика
Запросы, метрики, витрины и быстрые ответы по данным.
24.1%
Данные и ML
Трансформации, ETL и подготовка датасетов.
21.3%
Инфраструктура
Диагностика БД и служебные рабочие запросы.
16.4%
Направления показывают, в каких частях IT-рынка навык заметен чаще всего, без разбивки по ролям.
Инструмент / Возможности

Что нужно уметь в ClickHouse

Рабочий уровень в ClickHouse строится вокруг четырёх действий: спроектировать таблицу под реальные вопросы, загрузить данные без хаоса, убрать лишнее чтение и вовремя заметить рост цены эксплуатации.

Проектировать таблицы

Подбирать партицию, ключ сортировки, типы данных и порядок колонок под реальные фильтры, а не под абстрактную красивую схему.

Писать аналитические запросы

Считать агрегаты, процентили, срезы, воронки и отчёты так, чтобы запрос читал нужные колонки и понятный диапазон данных.

Настраивать загрузку

Понимать пакетную и потоковую загрузку, дубли, поздние события, порядок вставок и то, как ошибка источника проявится в отчёте.

Следить за эксплуатацией

Проверять тяжёлые запросы, слияния, дисковое место, репликацию, распределение нагрузки и стоимость хранения, пока проблема не стала постоянным пожаром.

Сравнение / Контекст

ClickHouse простыми словами

ClickHouse полезно держать в голове как базу для чтения истории, а не как место, где живёт текущее состояние приложения. Тогда проще не путать четыре разные вещи: OLAP, OLTP, колоночное хранение и поиск по тексту.

OLAP

Большие чтения, группировки, срезы и история событий. ClickHouse проектируют именно под такой режим.

OLTP

Транзакции, точечные записи и текущее состояние сущностей. Для этого чаще берут PostgreSQL или MySQL.

Колоночное хранение

Значения одного поля лежат рядом. Поэтому аналитический запрос не тянет весь набор данных.

MergeTree

Движок, где данные пишутся частями, сортируются и сливаются в фоне.

Данные / Стек

Какие данные обычно кладут в ClickHouse

В ClickHouse обычно кладут поток фактов: клики, показы, заказы, платежи, логи, сервисные метрики и готовые агрегаты. Эти записи почти не правят после загрузки. Главные решения принимают до первого тяжёлого отчёта: какой будет MergeTree, по каким полям сортировать, как ловить дубли и что делать с опоздавшими событиями.

Пользовательские события

Клики, просмотры, заказы, действия в продукте и результаты экспериментов.

Технические события

Логи, метрики, следы запросов, ошибки и состояния сервисов.

Финансовые и рекламные факты

Показы, списания, ставки, расчёты, операции и отчёты по большим таблицам.

Предагрегированные витрины

Материализованные представления и отдельные таблицы под частые отчёты, где дешевле подготовить агрегат заранее.

Навык / Границы

Когда ClickHouse не нужен

Не основная база приложения

Для транзакций и частых правок чаще нужен другой слой.

Не спасает грязный поток

Ошибки схемы и загрузки база сама не исправит.

Не равен DWH целиком

Он может быть частью хранилища, но не всей методологией данных.

Не нужен без устойчивого сценария

Если вопрос решается индексом в PostgreSQL, отдельный движок лишний.

Будущее / Роль

Перспективы ClickHouse

Перспективы ClickHouse завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.

Сигнал 01

ClickHouse останется сильным слоем быстрой аналитики

Событий и логов становится больше, а ожидание быстрых отчётов только растёт.

Сигнал 02

Ценность сместится к архитектуре таблиц

Умение выбрать схему, ключ сортировки и схему загрузки будет важнее знания отдельных функций.

Сигнал 03

Модели ИИ увеличат спрос на быстрые хранилища событий

Оценка качества, журналы запросов и наблюдаемость модельных функций требуют быстрых аналитических запросов.

Практика / Портфолио

Портфолио с ClickHouse: с чего начать

Проект 01

Аналитический пайплайн Kafka → ClickHouse

Настройка потока событий из Kafka в ClickHouse через движок Kafka Engine и MaterializedView. Реализация агрегированных витрин данных для бизнес-аналитики с задержкой обновления менее 5 секунд.

Проект 02

Дашборды реального времени на Grafana + ClickHouse

Подключение ClickHouse к Grafana как источника данных. Создание дашбордов по метрикам продукта: DAU, retention, воронки. Настройка MaterializedView для предагрегации метрик по часам.

Проект 03

Event log система для сбора пользовательских событий

Проектирование таблиц MergeTree с партиционированием по дате для хранения сотен миллионов событий. Оптимизация запросов через sparse index и ReplicatedMergeTree для отказоустойчивости.

Проект 04

OLAP-кластер на Kubernetes с шардированием

Развёртывание ClickHouse-кластера в Kubernetes с шардированием и репликацией через ClickHouse Keeper. Настройка Distributed-таблиц, мониторинга через Prometheus и автоматических резервных копий.

Обучение / Маршрут

Как изучить ClickHouse

Учить ClickHouse лучше после уверенного SQL. Сначала полезно собрать простую таблицу событий и сравнить, как один и тот же отчёт ведёт себя при разной сортировке. Потом уже переходить к MergeTree, партициям, материализованным представлениям и загрузке данных. Такой путь быстрее показывает главное: скорость рождается из схемы, а не из названия OLAP. А ещё помогает увидеть цену лишнего чтения до того, как система вырастет. Следующий полезный шаг — добавить дубли и поздние события, чтобы увидеть реальную эксплуатацию. Тогда теория сразу связывается с ценой ошибки. И лучше видно, почему схему приходится продумывать заранее. Без этого первая же витрина начинает спорить с источником.

Этап 01

SQL и OLAP

Понять аналитические запросы, группировки, фильтры, процентили и отличие больших чтений от транзакций.

Этап 02

Таблицы и хранение

Разобраться с MergeTree, партициями, ключом сортировки, сжатием и фоновыми слияниями.

Этап 03

Загрузка и витрины

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

Этап 04

Эксплуатация

Следить за тяжёлыми запросами, диском, распределёнными таблицами, репликацией и стоимостью хранения.

Курсы · по данным рынка

Как выбирать обучение по ClickHouse

Соответствие — доля тем навыка, которые охватывает программа курса

Практика / Первый запуск

С чего начать ClickHouse

Стартуйте с маленькой событийной таблицы и измеряйте, как схема влияет на скорость запроса. Соберите таблицу с временем, пользователем, типом события, источником и числовым значением. Выполните запрос по периоду и событию, затем измените порядок сортировки и сравните, сколько строк и байт читает база. Так видно простую вещь: скорость рождается из схемы. Не из слова OLAP. Дальше постройте агрегат по дням и источникам, добавьте материализованное представление и проверьте задержку витрины. Затем загрузите данные с дублями или неверной датой и посмотрите, как меняется отчёт. ClickHouse быстро считает то, что ему дали. Поэтому в учебной практике нужно проверять скорость. И отдельно проверять, можно ли верить итоговой цифре.

Шаг 01

Возьмите таблицу событий

Подготовьте поля времени, пользователя, события, источника и числового значения.

Шаг 02

Выберите ключ сортировки

Сопоставьте его с фильтрами, которые чаще всего будут в запросах.

Шаг 03

Сравните два запроса

Проверьте, почему запрос с правильным фильтром читает меньше данных.

Шаг 04

Разберите план и объём чтения

Посмотрите, какие колонки и части таблицы реально читаются, прежде чем ускорять запрос случайными настройками.

Частые вопросы

Вопросы и ответы

Что такое ClickHouse простыми словами?

ClickHouse — аналитическая база данных для больших чтений. Её используют, когда нужно быстро считать отчёты, срезы и агрегаты по большому слою событий, логов или фактов. Обычно она живёт рядом с основной базой приложения, а не вместо неё.

Чем ClickHouse отличается от обычной транзакционной базы?

Транзакционная база чаще держит текущее состояние приложения и частые точечные изменения. ClickHouse отвечает за историю, крупные сканы и быстрые агрегаты по данным, которые почти не меняются после записи. Поэтому это обычно не две прямые замены одной и той же роли.

Зачем нужен MergeTree?

MergeTree хранит данные частями, сортирует их и сливает в фоне. На практике это один из главных слоёв, от которого зависит, сколько данных прочитает тяжёлый запрос. Ошибка в этом выборе быстро бьёт по скорости и стоимости чтения.

Где обычно используют ClickHouse?

Чаще всего в продуктовой аналитике, логах, наблюдаемости, рекламных фактах, финансовых витринах и внутренних отчётах. То есть там, где фактов много, а читать их нужно быстро и регулярно. Особенно хорошо он чувствует себя на потоках, которые почти не меняются после записи.

Сложно ли начать учить ClickHouse?

Если SQL уже понятен, старт вполне прямой. Сложность появляется чуть позже: нужно подобрать схему, сортировку, правила дедупликации и понять, как отчёт зависит от потока данных. Именно здесь заканчивается учебный SQL и начинается рабочий уровень. Без этого ClickHouse быстро превращается в дорогую коробку для запросов.

Когда ClickHouse добавлять не стоит?

Если задача решается обычной базой, индексом или небольшой витриной, отдельный аналитический движок может только усложнить архитектуру. Он оправдан там, где действительно есть тяжёлые чтения и длинная история. И где команда готова сопровождать ещё один слой данных.

Чем ClickHouse отличается от Greenplum?

Greenplum — MPP-база на основе PostgreSQL со строчной архитектурой и классическим SQL-планировщиком. ClickHouse — колоночная СУБД с векторной обработкой запросов. На аналитических агрегациях ClickHouse в 5–20 раз быстрее Greenplum при заметно меньших затратах на эксплуатацию кластера.

Чем ClickHouse отличается от Apache Spark?

Spark — вычислительный фреймворк для batch-обработки, а не СУБД. ClickHouse хранит данные самостоятельно и отдаёт результаты за миллисекунды в интерактивном режиме. Spark лучше для сложных ETL-пайплайнов, ClickHouse — для дашбордов и разовых аналитики с малыми задержками.

Чем ClickHouse отличается от BigQuery?

BigQuery — управляемый сервис Google без self-hosted-варианта с оплатой за объём сканируемых данных. ClickHouse запускается на собственных серверах или в облаке с предсказуемой стоимостью. На сложных агрегациях ClickHouse нередко выигрывает по скорости при больших объёмах.

Чем ClickHouse отличается от Cassandra?

Cassandra оптимизирована под write-heavy нагрузки и точечные чтения по ключу. ClickHouse создан для аналитических сканов миллиардов строк с агрегациями. Задачи разные — их нередко используют вместе: Cassandra хранит сырые события, ClickHouse считает отчёты.

В чём разница между колоночным и строчным хранением данных?

Строчная база хранит все поля записи рядом — удобно для операций с отдельными строками (INSERT, UPDATE). Колоночная хранит каждый столбец отдельным блоком: при аналитике выборка 3–5 столбцов из таблицы с 50 полями читает в 10–15 раз меньше данных с диска.

Когда ClickHouse не нужен?

ClickHouse не подходит, если нужны частые UPDATE и DELETE одиночных строк, полный ACID или высококонкурентные OLTP-запросы. Для интернет-магазина, CRM или банковских транзакций правильный выбор — PostgreSQL или MySQL, а не ClickHouse.

Как устроен движок MergeTree в ClickHouse?

Данные пишутся кусками (parts) — каждый кусок сортирован по первичному ключу и хранится как набор колоночных файлов. В фоне куски сливаются (merge). Sparse index помогает ClickHouse пропускать нерелевантные диапазоны без полного сканирования и ускоряет агрегации на больших таблицах.

Что такое ReplicatedMergeTree и как работает репликация?

ReplicatedMergeTree синхронизирует данные между несколькими репликами через ZooKeeper или ClickHouse Keeper. Каждая реплика хранит полную копию шарда. При отказе ноды запросы автоматически переходят на живую реплику без ручного вмешательства.

Как устроено шардирование в ClickHouse?

Кластер делится на шарды, каждый хранит часть данных. Поверх шардов создаётся Distributed-таблица, которая распределяет запрос по всем нодам параллельно и агрегирует результат. Правильный ключ шардирования критичен: неудачный выбор делает каждый запрос распределённым и непредсказуемым по времени.

Можно ли заменить Oracle Exadata или Greenplum на ClickHouse?

Для аналитических нагрузок — да. ClickHouse перекрывает большинство OLAP-возможностей Oracle и Greenplum при значительно меньших затратах на лицензии и железо. Популярный сценарий импортозамещения: мигрируют ETL-пайплайны, аналитические витрины и отчётные запросы.

Нужно ли изучать ClickHouse джуниору?

Джуниор-вакансии с ClickHouse составляют лишь 7,8% рынка — технология встречается намного реже, чем SQL или Python. Оптимальный путь: сначала PostgreSQL и базовый SQL, ClickHouse добавлять на уровне middle. Понять принципы колоночного хранения полезно уже на старте карьеры.

Какая зарплата у специалиста с ClickHouse в московских вакансиях?

Медиана по вакансиям с ClickHouse — одна из самых высоких на аналитическом рынке, но вилку задают роль и грейд. Добавление Prometheus или Kubernetes к стеку заметно поднимает предложения. Актуальные цифры — в рыночном блоке этой страницы.

Что такое MaterializedView в ClickHouse и зачем она нужна?

MaterializedView — таблица, которая заполняется автоматически при каждой вставке в таблицу-источник. Она хранит предагрегированные данные на диске: запросы к ней работают в разы быстрее, чем агрегация «на лету» по миллиардам строк.

Поддерживает ли ClickHouse транзакции и ACID?

Полного ACID ClickHouse не обеспечивает. INSERT атомарен на уровне блока, но UPDATE и DELETE медленные и не рассчитаны на OLTP-нагрузку. ClickHouse — OLAP-система, дополнение к транзакционным базам, а не их замена.

Как ClickHouse сжимает данные?

Под каждый столбец в DDL задаётся кодек: LZ4 по умолчанию, ZSTD для максимального сжатия, Delta или DoubleDelta для временных рядов. Колоночная укладка делает сжатие особенно эффективным: похожие значения лежат рядом, итоговый объём в 5–10 раз меньше, чем в PostgreSQL.

Что такое партиционирование в ClickHouse и зачем оно нужно?

Партиционирование делит таблицу на физически независимые куски по значению колонки — чаще всего по дате. ClickHouse пропускает партиции, не попавшие в фильтр запроса: при выборке за конкретную неделю данные за прошлый год не читаются вовсе.

Насколько сложно администрировать ClickHouse в продакшене?

Операционно ClickHouse проще Greenplum, но требует внимания к merge-политикам, мониторингу очереди слияний и грамотному выбору шард-ключей. Типовой стек: ClickHouse Keeper вместо ZooKeeper + Prometheus + Grafana. В московских вакансиях Prometheus встречается рядом с ClickHouse с 15%-ным бонусом к зарплате.

Работает ли ClickHouse с Kafka?

Да, через встроенный движок таблиц Kafka. ClickHouse читает топики напрямую и складывает события в MergeTree-таблицу без дополнительного брокера. В московских вакансиях с ClickHouse Kafka встречается в 44% позиций, а стек ClickHouse + Kafka поднимает медианный оффер примерно на 7%.

Какие варианты развёртывания ClickHouse существуют?

Self-hosted на bare-metal или в Kubernetes, ClickHouse Cloud (официальный managed), Altinity Cloud. В московских вакансиях Kubernetes встречается рядом с ClickHouse в 42% позиций, а k8s-навыки поднимают предложения на 15%, до 345k.