Что это
База для истории событий: клики, заказы, платежи, ошибки, логи. Не вместо PostgreSQL, а рядом с ним для отчётов.
ClickHouse ставят рядом с обычной базой, когда отчёты по кликам, заказам, платежам и логам начинают мешать приложению. Он быстро читает большой слой накопленных событий и отвечает на вопросы по датам, статусам, источникам и суммам.
База для истории событий: клики, заказы, платежи, ошибки, логи. Не вместо PostgreSQL, а рядом с ним для отчётов.
Когда отчёты каждый день читают много старых данных и уже мешают базе, которая обслуживает приложение.
Даёт быстрый ответ по истории: что выросло, что просело, где ошибка, сколько было денег, заказов или событий.
ClickHouse — открытая колоночная СУБД для OLAP-запросов, созданная командой Яндекса и выпущенная в с открытым исходным кодом в 2016 году. Вместо строчного хранения ClickHouse записывает каждый столбец отдельным блоком, при этом с диска читаются только нужные колонки — остальные не трогаются. Система обрабатывает запросы к миллиардам строк за секунды и масштабируется горизонтально через шардирование с репликацией.
Скорость зависит от колонок, ключа сортировки и того, какие вопросы команда задаёт каждый день. Один и тот же SQL ведёт себя по-разному на разных схемах.
Нужно заранее понять поток данных, дубли, опоздавшие события и типичные фильтры будущих отчётов. Иначе база быстро теряет главное преимущество.
Типовая цепочка начинается не с SELECT, а с события. Данные нужно принять, положить в таблицу, отсортировать под будущие фильтры, дать запросу прочитать минимум лишнего и только потом показывать витрину пользователю. Если ошибка закладывается на этапе загрузки, быстрый запрос потом всё равно вернёт плохую цифру.
События попадают в таблицу
Данные приходят из приложения, очереди, файла или соседнего хранилища. Важно сохранить время события, источник, идентификаторы и признаки для фильтров отчётов.
MergeTree раскладывает части
Новые данные сохраняются частями, сортируются по ключу и сливаются в фоне. Плохой порядок сортировки заставит будущие запросы читать слишком широкий диапазон.
Запрос читает нужные колонки
ClickHouse берёт только поля, нужные выражению, и пропускает лишние участки по сортировке. Поэтому аккуратный фильтр по времени, событию или ключу важнее длинного списка функций.
Витрина ускоряет частые вопросы
Для регулярных отчётов можно заранее подготовить агрегаты или отдельную таблицу под нужный сценарий. Но у витрины должны быть владелец, задержка обновления и правило пересчёта.
ClickHouse переносится между ролями: Инженер данных, DevOps-инженер, Аналитик данных. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
Инженер данных держит 55.7% вакансий по навыку.
Ещё 7 ролей используют ClickHouse
Текущий срез показывает активные вакансии сейчас. Распределение по ролям рассчитано по расширенной исторической выборке, поэтому значения могут быть выше текущего количества активных вакансий.
ClickHouse ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами — ниже они разобраны так, как встречаются в реальной работе.
Собрать таблицу событий
Взять поток фактов и выбрать поля для фильтров и агрегатов.
Подобрать сортировку
Проверить, как меняется чтение при другом ключе.
Построить витрину
Собрать агрегат, который команда будет читать каждый день.
Проверить поздние события
Посмотреть, как опоздание влияет на итоговую цифру.
Сравнить запросы
Разобрать, почему один запрос читает мало, а другой слишком много.
Поймать дубли
Проверить ключ дедупликации до публикации отчёта.
Схема из транзакционной базы редко хорошо работает на аналитике.
Если ключ не помогает фильтрам, запросы быстро дорожают.
База быстро считает, но команда не сможет доверять цифре.
Нужно смотреть ещё на загрузку, хранение и поведение витрин.
ClickHouse востребован там, где данных уже много, а вопросы к ним повторяются каждый день. Это продуктовая аналитика, наблюдаемость, рекламные факты, внутренние витрины и крупные отчёты. Такие команды быстро понимают, что одной обычной базы уже мало. Ценится не умение написать один запрос, а понимание полного пути события: как оно приехало, куда легло, почему отчёт тормозит и где схема начинает стоить слишком дорого. Особенно это видно на системах, где цифры нужны быстро и без споров о корректности. Здесь уже мало просто знать синтаксис и пару функций. Нужен человек, который понимает цену каждой архитектурной мелочи.
ClickHouse нужен там, где важно быстро проверить гипотезу, сверить метрику или подготовить данные для следующего шага.
Такой навык редко живёт в одной профессии: он остаётся полезным в аналитике, продукте, разработке и соседних data-сценариях.
Инструменты вокруг меняются, но сама задача не исчезает, поэтому ClickHouse продолжает удерживать прикладной спрос.
ClickHouse стабильно удерживается в активном прикладном слое рынка.
ClickHouse сохраняет высокий текущий спрос на рынке: 637 активных вакансий, #21 по рынку, 9.1% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#21 по рынку • 9.1% IT-вакансий
-101 вакансий и -11% к предыдущему месяцу.
В московском IT медиана по ClickHouse — одна из самых высоких на рынке, но вилку задают роль и грейд, а не сама СУБД. Prometheus или Kubernetes в стеке дают заметную прибавку. Спрос растёт; актуальные цифры — в рыночном блоке этой страницы.
106 вакансий с зарплатой в расширенной зарплатной выборке
Основной зарплатный ориентир по Senior-вакансиям
Senior - основной уровень рынка (54%)
ClickHouse редко живёт изолированно: чаще всего рынок видит его рядом с PostgreSQL, Python, SQL. Самая плотная связка сейчас - PostgreSQL: оба навыка встречаются вместе в 66% вакансий.
Главная связка: PostgreSQL • 66% вакансий. Показываем общерыночные связки ClickHouse: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
не базовый минимум, а более сильные комбинации стека
Сейчас на рынке 35 активных junior-вакансий с ClickHouse. Это 6.8% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
6.8% всех вакансий по навыку • Senior / Junior 7.9x
Окно входа узкое: рынок чаще нанимает с опытом.
Медианная вакансия с ClickHouse ожидает около 16 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
навыки из junior-вакансий, где встречается ClickHouse
Здесь чаще всего ошибаются в выборе роли. Смотреть нужно не на громкое название, а на тип нагрузки: транзакции, аналитика, общий слой данных или поиск.
Колоночная база для аналитики и больших чтений.
Когда нужны быстрые срезы по истории событий и фактов.
Плохо подходит для частых точечных изменений.
Транзакционная база для состояния приложения.
Когда важны записи, обновления, связи и ограничения.
На тяжёлой аналитике часто мешает боевой нагрузке.
Широкий слой хранилища с витринами и правилами качества.
Когда нужно объединять много источников на уровне компании.
ClickHouse может быть движком внутри, но не заменяет весь слой.
Поиск по тексту и документам.
Когда главный сценарий — найти запись или фрагмент текста.
Для тяжёлых агрегатов по фактам обычно слабее ClickHouse.
ClickHouse нужен там, где команда постоянно считает аналитику по событиям, логам или метрикам, а обычная база приложения уже тяжело переносит такие чтения каждый день. Обычно это уже не разовый отчёт, а постоянная рабочая нагрузка.
События приложения, воронки, сегменты и история поведения.
Ошибки, задержки, метрики и крупные разборы по времени.
Финансовые, рекламные и операционные срезы по большому слою фактов.
Очереди, загрузки и append-heavy данные с контролем дублей.
ClickHouse заметен в 5 направлениях рынка с долей выше 5%.
Рабочий уровень в ClickHouse строится вокруг четырёх действий: спроектировать таблицу под реальные вопросы, загрузить данные без хаоса, убрать лишнее чтение и вовремя заметить рост цены эксплуатации.
Подбирать партицию, ключ сортировки, типы данных и порядок колонок под реальные фильтры, а не под абстрактную красивую схему.
Считать агрегаты, процентили, срезы, воронки и отчёты так, чтобы запрос читал нужные колонки и понятный диапазон данных.
Понимать пакетную и потоковую загрузку, дубли, поздние события, порядок вставок и то, как ошибка источника проявится в отчёте.
Проверять тяжёлые запросы, слияния, дисковое место, репликацию, распределение нагрузки и стоимость хранения, пока проблема не стала постоянным пожаром.
ClickHouse полезно держать в голове как базу для чтения истории, а не как место, где живёт текущее состояние приложения. Тогда проще не путать четыре разные вещи: OLAP, OLTP, колоночное хранение и поиск по тексту.
Большие чтения, группировки, срезы и история событий. ClickHouse проектируют именно под такой режим.
Транзакции, точечные записи и текущее состояние сущностей. Для этого чаще берут PostgreSQL или MySQL.
Значения одного поля лежат рядом. Поэтому аналитический запрос не тянет весь набор данных.
Движок, где данные пишутся частями, сортируются и сливаются в фоне.
В ClickHouse обычно кладут поток фактов: клики, показы, заказы, платежи, логи, сервисные метрики и готовые агрегаты. Эти записи почти не правят после загрузки. Главные решения принимают до первого тяжёлого отчёта: какой будет MergeTree, по каким полям сортировать, как ловить дубли и что делать с опоздавшими событиями.
Клики, просмотры, заказы, действия в продукте и результаты экспериментов.
Логи, метрики, следы запросов, ошибки и состояния сервисов.
Показы, списания, ставки, расчёты, операции и отчёты по большим таблицам.
Материализованные представления и отдельные таблицы под частые отчёты, где дешевле подготовить агрегат заранее.
Для транзакций и частых правок чаще нужен другой слой.
Ошибки схемы и загрузки база сама не исправит.
Он может быть частью хранилища, но не всей методологией данных.
Если вопрос решается индексом в PostgreSQL, отдельный движок лишний.
Перспективы ClickHouse завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Событий и логов становится больше, а ожидание быстрых отчётов только растёт.
Умение выбрать схему, ключ сортировки и схему загрузки будет важнее знания отдельных функций.
Оценка качества, журналы запросов и наблюдаемость модельных функций требуют быстрых аналитических запросов.
Настройка потока событий из Kafka в ClickHouse через движок Kafka Engine и MaterializedView. Реализация агрегированных витрин данных для бизнес-аналитики с задержкой обновления менее 5 секунд.
Подключение ClickHouse к Grafana как источника данных. Создание дашбордов по метрикам продукта: DAU, retention, воронки. Настройка MaterializedView для предагрегации метрик по часам.
Проектирование таблиц MergeTree с партиционированием по дате для хранения сотен миллионов событий. Оптимизация запросов через sparse index и ReplicatedMergeTree для отказоустойчивости.
Развёртывание ClickHouse-кластера в Kubernetes с шардированием и репликацией через ClickHouse Keeper. Настройка Distributed-таблиц, мониторинга через Prometheus и автоматических резервных копий.
Учить ClickHouse лучше после уверенного SQL. Сначала полезно собрать простую таблицу событий и сравнить, как один и тот же отчёт ведёт себя при разной сортировке. Потом уже переходить к MergeTree, партициям, материализованным представлениям и загрузке данных. Такой путь быстрее показывает главное: скорость рождается из схемы, а не из названия OLAP. А ещё помогает увидеть цену лишнего чтения до того, как система вырастет. Следующий полезный шаг — добавить дубли и поздние события, чтобы увидеть реальную эксплуатацию. Тогда теория сразу связывается с ценой ошибки. И лучше видно, почему схему приходится продумывать заранее. Без этого первая же витрина начинает спорить с источником.
SQL и OLAP
Понять аналитические запросы, группировки, фильтры, процентили и отличие больших чтений от транзакций.
Таблицы и хранение
Разобраться с MergeTree, партициями, ключом сортировки, сжатием и фоновыми слияниями.
Загрузка и витрины
Освоить загрузку событий, материализованные представления и подготовку таблиц под частые вопросы.
Эксплуатация
Следить за тяжёлыми запросами, диском, распределёнными таблицами, репликацией и стоимостью хранения.
Соответствие — доля тем навыка, которые охватывает программа курса
Стартуйте с маленькой событийной таблицы и измеряйте, как схема влияет на скорость запроса. Соберите таблицу с временем, пользователем, типом события, источником и числовым значением. Выполните запрос по периоду и событию, затем измените порядок сортировки и сравните, сколько строк и байт читает база. Так видно простую вещь: скорость рождается из схемы. Не из слова OLAP. Дальше постройте агрегат по дням и источникам, добавьте материализованное представление и проверьте задержку витрины. Затем загрузите данные с дублями или неверной датой и посмотрите, как меняется отчёт. ClickHouse быстро считает то, что ему дали. Поэтому в учебной практике нужно проверять скорость. И отдельно проверять, можно ли верить итоговой цифре.
Подготовьте поля времени, пользователя, события, источника и числового значения.
Сопоставьте его с фильтрами, которые чаще всего будут в запросах.
Проверьте, почему запрос с правильным фильтром читает меньше данных.
Посмотрите, какие колонки и части таблицы реально читаются, прежде чем ускорять запрос случайными настройками.
ClickHouse — аналитическая база данных для больших чтений. Её используют, когда нужно быстро считать отчёты, срезы и агрегаты по большому слою событий, логов или фактов. Обычно она живёт рядом с основной базой приложения, а не вместо неё.
Транзакционная база чаще держит текущее состояние приложения и частые точечные изменения. ClickHouse отвечает за историю, крупные сканы и быстрые агрегаты по данным, которые почти не меняются после записи. Поэтому это обычно не две прямые замены одной и той же роли.
MergeTree хранит данные частями, сортирует их и сливает в фоне. На практике это один из главных слоёв, от которого зависит, сколько данных прочитает тяжёлый запрос. Ошибка в этом выборе быстро бьёт по скорости и стоимости чтения.
Чаще всего в продуктовой аналитике, логах, наблюдаемости, рекламных фактах, финансовых витринах и внутренних отчётах. То есть там, где фактов много, а читать их нужно быстро и регулярно. Особенно хорошо он чувствует себя на потоках, которые почти не меняются после записи.
Если SQL уже понятен, старт вполне прямой. Сложность появляется чуть позже: нужно подобрать схему, сортировку, правила дедупликации и понять, как отчёт зависит от потока данных. Именно здесь заканчивается учебный SQL и начинается рабочий уровень. Без этого ClickHouse быстро превращается в дорогую коробку для запросов.
Если задача решается обычной базой, индексом или небольшой витриной, отдельный аналитический движок может только усложнить архитектуру. Он оправдан там, где действительно есть тяжёлые чтения и длинная история. И где команда готова сопровождать ещё один слой данных.
Greenplum — MPP-база на основе PostgreSQL со строчной архитектурой и классическим SQL-планировщиком. ClickHouse — колоночная СУБД с векторной обработкой запросов. На аналитических агрегациях ClickHouse в 5–20 раз быстрее Greenplum при заметно меньших затратах на эксплуатацию кластера.
Spark — вычислительный фреймворк для batch-обработки, а не СУБД. ClickHouse хранит данные самостоятельно и отдаёт результаты за миллисекунды в интерактивном режиме. Spark лучше для сложных ETL-пайплайнов, ClickHouse — для дашбордов и разовых аналитики с малыми задержками.
BigQuery — управляемый сервис Google без self-hosted-варианта с оплатой за объём сканируемых данных. ClickHouse запускается на собственных серверах или в облаке с предсказуемой стоимостью. На сложных агрегациях ClickHouse нередко выигрывает по скорости при больших объёмах.
Cassandra оптимизирована под write-heavy нагрузки и точечные чтения по ключу. ClickHouse создан для аналитических сканов миллиардов строк с агрегациями. Задачи разные — их нередко используют вместе: Cassandra хранит сырые события, ClickHouse считает отчёты.
Строчная база хранит все поля записи рядом — удобно для операций с отдельными строками (INSERT, UPDATE). Колоночная хранит каждый столбец отдельным блоком: при аналитике выборка 3–5 столбцов из таблицы с 50 полями читает в 10–15 раз меньше данных с диска.
ClickHouse не подходит, если нужны частые UPDATE и DELETE одиночных строк, полный ACID или высококонкурентные OLTP-запросы. Для интернет-магазина, CRM или банковских транзакций правильный выбор — PostgreSQL или MySQL, а не ClickHouse.
Данные пишутся кусками (parts) — каждый кусок сортирован по первичному ключу и хранится как набор колоночных файлов. В фоне куски сливаются (merge). Sparse index помогает ClickHouse пропускать нерелевантные диапазоны без полного сканирования и ускоряет агрегации на больших таблицах.
ReplicatedMergeTree синхронизирует данные между несколькими репликами через ZooKeeper или ClickHouse Keeper. Каждая реплика хранит полную копию шарда. При отказе ноды запросы автоматически переходят на живую реплику без ручного вмешательства.
Кластер делится на шарды, каждый хранит часть данных. Поверх шардов создаётся Distributed-таблица, которая распределяет запрос по всем нодам параллельно и агрегирует результат. Правильный ключ шардирования критичен: неудачный выбор делает каждый запрос распределённым и непредсказуемым по времени.
Для аналитических нагрузок — да. ClickHouse перекрывает большинство OLAP-возможностей Oracle и Greenplum при значительно меньших затратах на лицензии и железо. Популярный сценарий импортозамещения: мигрируют ETL-пайплайны, аналитические витрины и отчётные запросы.
Джуниор-вакансии с ClickHouse составляют лишь 7,8% рынка — технология встречается намного реже, чем SQL или Python. Оптимальный путь: сначала PostgreSQL и базовый SQL, ClickHouse добавлять на уровне middle. Понять принципы колоночного хранения полезно уже на старте карьеры.
Медиана по вакансиям с ClickHouse — одна из самых высоких на аналитическом рынке, но вилку задают роль и грейд. Добавление Prometheus или Kubernetes к стеку заметно поднимает предложения. Актуальные цифры — в рыночном блоке этой страницы.
MaterializedView — таблица, которая заполняется автоматически при каждой вставке в таблицу-источник. Она хранит предагрегированные данные на диске: запросы к ней работают в разы быстрее, чем агрегация «на лету» по миллиардам строк.
Полного ACID ClickHouse не обеспечивает. INSERT атомарен на уровне блока, но UPDATE и DELETE медленные и не рассчитаны на OLTP-нагрузку. ClickHouse — OLAP-система, дополнение к транзакционным базам, а не их замена.
Под каждый столбец в DDL задаётся кодек: LZ4 по умолчанию, ZSTD для максимального сжатия, Delta или DoubleDelta для временных рядов. Колоночная укладка делает сжатие особенно эффективным: похожие значения лежат рядом, итоговый объём в 5–10 раз меньше, чем в PostgreSQL.
Партиционирование делит таблицу на физически независимые куски по значению колонки — чаще всего по дате. ClickHouse пропускает партиции, не попавшие в фильтр запроса: при выборке за конкретную неделю данные за прошлый год не читаются вовсе.
Операционно ClickHouse проще Greenplum, но требует внимания к merge-политикам, мониторингу очереди слияний и грамотному выбору шард-ключей. Типовой стек: ClickHouse Keeper вместо ZooKeeper + Prometheus + Grafana. В московских вакансиях Prometheus встречается рядом с ClickHouse с 15%-ным бонусом к зарплате.
Да, через встроенный движок таблиц Kafka. ClickHouse читает топики напрямую и складывает события в MergeTree-таблицу без дополнительного брокера. В московских вакансиях с ClickHouse Kafka встречается в 44% позиций, а стек ClickHouse + Kafka поднимает медианный оффер примерно на 7%.
Self-hosted на bare-metal или в Kubernetes, ClickHouse Cloud (официальный managed), Altinity Cloud. В московских вакансиях Kubernetes встречается рядом с ClickHouse в 42% позиций, а k8s-навыки поднимают предложения на 15%, до 345k.