ClickHouse: сценарии, сильные стороны, лучшие практики работы в 2026 году

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. 

Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

Начнем с погружения в детали: что такое ClickHouse

ClickHouse разработан для быстрой обработки аналитических запросов и получил широкое распространение благодаря своей высокой производительности и простоте использования. Причем часто ClickHouse рассматривают как универсальное решение для аналитиков, считая, что он способен заменить традиционные базы данных, такие как PostgreSQL. Однако, чтобы понять истинные возможности и ограничения ClickHouse, необходимо рассмотреть его место среди различных классов СУБД.

Так, все СУБД можно условно разделить на несколько классов по разным признакам. Например:

• По модели данных. СУБД могут быть реляционными, документными, графовыми, поисковыми, векторными, а также для работы с временными рядами.

• По нагрузке. Выделяют OLTP (оперативная обработка транзакций), OLAP (аналитическая обработка) и HTAP (гибридная обработка).

• По консистентности. СУБД могут обеспечивать консистентность посредством ACID-транзакций, eventual consistency и гибридных подходов.

• По хранению. СУБД могут реализовывать строковое, колоночное, резидентное или гибридное хранение данных.

• По архитектуре. Можно встретить архитектуры single-серверные, high availability, MPP shared nothing и shared something.

В подобной классификации ClickHouse относится к классу колоночных OLAP-СУБД. То есть он объединяет преимущества OLAP и колоночного хранения. И здесь стоит остановиться подробнее.

Что дает OLAP

OLAP (Online Analytical Processing) — это подход к обработке данных, ориентированный на выполнение аналитических запросов. В отличие от OLTP, где акцент делается на короткие транзакции, OLAP специализируется на обработке больших объемов данных и выполнении сложных аналитических операций.

ClickHouse поддерживает основные возможности OLAP, в том числе:

• Группировка данных. Решение умеет группировать данные по различным измерениям и выполнять агрегатные функции, такие как SUM, AVG, MAX и MIN.

• Многомерный анализ. ClickHouse поддерживает многомерный анализ данных, что позволяет рассматривать информацию с разных точек зрения.

• Детализация и обобщение. Система предоставляет возможность переходить от общих данных к более детальным уровням анализа.

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

Что дает колоночное хранение

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

Это формирует определенные издержки. Например:

• Каждая колонка хранится в отдельном файле, что увеличивает общее количество файлов в хранилище.

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

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

Но разделение данных по колонкам дает несколько существенных преимуществ:

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

• Колоночное хранение позволяет эффективно отсекать ненужные данные по естественным границам, таким как даты или категории, что ускоряет выполнение запросов.

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

Однако в ClickHouse все организовано еще сложнее: для обеспечения высокой производительности и гибкости в ClickHouse данные хранятся в виде так называемых кусков (data parts), которые состоят из файлов, содержащих данные по каждой колонке. Каждый кусочек сортируется по ключу, что облегчает объединение данных и поддержание упорядоченности.

Более того, в отличие от Parquet, где данные упакованы в единый файл, в ClickHouse каждый кусок данных представлен несколькими файлами. Например, если в Parquet 100 колонок упакованы в один файл, то в ClickHouse для каждой колонки создается два файла: один для данных и один для индекса. Таким образом, для 100 колонок в каждом куске данных будет 200 файлов.

Работа с Data parts

Куски данных в ClickHouse управляются механизмом MergeTree, который отвечает за объединение мелких кусочков в более крупные. Реализуется это по следующему алгоритму:

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

• Со временем мелкие кусочки объединяются в более крупные, что снижает количество файлов и улучшает производительность.

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

Таким образом, ClickHouse позволяет эффективно хранить данные в больших пакетах, сохраняя при этом возможность принимать малые порции данных, а уже под капотом система самостоятельно объединяет эти мелкие кусочки в более крупные, что отличает ее от классических баз данных. 

Но схлопывание кусков — это не единственная функция MergeTree. Помимо простого объединения данных, механизм MergeTree позволяет выполнять дополнительные операции в процессе слияния кусочков. Например:

• Collapsing MergeTree. Позволяет удалять избыточные данные путем их автоматического удаления при слиянии кусочков. 

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

• Coalescing MergeTree. Добавляет новую информацию в существующий набор данных, объединяя ее с предыдущими значениями.

• Aggregating, Summing MergeTree. Осуществляет автоматическое суммирование данных при слиянии кусочков, что экономит место и ускоряет последующие запросы.

Таким образом, MergeTree дает широкие возможности для автоматизации обработки данных.

Но тут важно понимать, что вся эта магия работает только при схлопывании кусочков данных. Типичная ошибка новичка — думать, что это работает всегда для любых данных.

Примечание: Механизм MergeTree в ClickHouse объединяет кусочки данных (data parts) только внутри одной партиции. Например, данные за январь не сольются с данными за февраль. Из‑за этого на границах периодов (дней, месяцев) может возникать неконсистентность. 

Более того, надо помнить, что, если какая‑то партиция не оптимизирована (например, из‑за высокой нагрузки), ее данные остаются в виде мелких кусочков. Но при запросах, охватывающих несколько партиций, система обрабатывает оптимизированные и неоптимизированные данные по‑разному — это может привести к ошибкам в движках Collapsing MergeTree или Replacing MergeTree: дубликаты не удалятся, старые версии записей сохранятся, а агрегации дадут неверный результат.

О кластерах ClickHouse

Специфика ClickHouse проявляется и на уровне кластеров — в разных СУБД под «кластером» понимаются разные сущности. Например:

• В PostgreSQL кластер — это, по сути, согласованные копии одних и тех же данных: мастер, синк-реплика, асинк-реплики. То есть существует один главный мастер, а все остальное — подстраховка. 

• Кластер Greenplum подразумевает, что данные разбиты на шарды (сегменты) с репликацией и все строго контролирует специально выделенный мастер. То есть формируется некий строй под четкой командой.

• В ClickHouse же кластер формируют равноправные инстансы, которые могут общаться друг с другом, а могут и не общаться. Причем кластером эти инстансы становятся только в том случае, если явно указана соответствующая конфигурация в движке таблицы (например, с использованием Replicated*). И эта «кластерность» распространяется только в рамках конкретной задачи и конкретного объекта — в остальных случаях инстансы ведут себя как независимые узлы.

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

• В погоне за производительностью ClickHouse жертвует гарантиями консистентности — их нет по умолчанию.

• Консистентность зависит от движка (Replicated*) и того, куда идет вставка: в локальную таблицу или в Replicated, Distributed.

• Консистентность зависит от режима вставки (quorum).

• Если СУБД сообщила, что данные приняты, это не значит, что они приняты везде, повсюду, в одинаковом виде.

На практике же подобные нюансы с отсутствием строгой консистентности могут приводить к вполне реальным проблемам, среди которых:

• отсутствие четкого понимания, вставились данные или нет, особенно при распределенной вставке;

• появление дубликатов от ретраев со сбоями;

• возможные разные результаты на разных репликах (eventual consistency!) — если есть балансировщик, можно записать данные в одну реплику, а через секунду обратиться к другой и понять, что данных нет;

• неатомарность операций на разных шардах.

Таким образом, за сохранением консистентности в ClickHouse надо следить тщательно и непрерывно.

Лучшие практики применения ClickHouse 

Как и в случае с другими СУБД, при выборе сценариев применения ClickHouse и вариантов его интеграции в инфраструктуру для работы с данными, в первую очередь учитываются сильные и слабые стороны. Так, ClickHouse плохо справляется с OLTP с высокими требованиями к консистентности, конкурентными UPDATE, полнотекстовым поиском и очередями.

Вместе с тем он способен обеспечить:

• очень высокий ingress;

• дешевые агрегации по миллиардам строк;

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

В связи с этим он оптимален, а порой и вовсе незаменим в кейсах, где подразумевается:

• лог-аналитика: API, CDN;

• кликстрим, ивент-стрим, продуктовая аналитика, Security Audit, логи безопасности;

• BI, воронки, self-service;

• Time-Series на большом объеме, телеметрия, работа с IoT.

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

Data Last Mile

Архитектура Data Last Mile подразумевает размещение ClickHouse в качестве завершающего звена цепочки хранения данных перед конечными потребителями, такими как BI-системы, встроенные аналитические модули и клиентские приложения. Это позволяет обеспечить высокую скорость обработки запросов и удобный доступ к аналитическим данным.

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

Поскольку архитектура Data Last Mile сочетает в себе надежность и контроль данных на уровне традиционного хранилища с высокой скоростью и гибкостью на уровне аналитической обработки, подобная реализация подойдет, когда одновременно важна как точность данных, так и скорость отклика BI/аналитики.

Быстрый Ingress 

Подобная архитектура предполагает прямую передачу данных в ClickHouse, который, благодаря своей масштабируемости и эффективной модели данных, способен быстро принимать и обрабатывать большие объемы информации. Источниками данных могут служить очереди сообщений, стриминговые сервисы (например, Apache Kafka или Spark Streaming), крупные корпоративные приложения или системы интернета вещей с многочисленными датчиками.

Работает это следующим образом:

• Входящий поток данных поступает непосредственно в ClickHouse, который обеспечивает быструю запись и первичную обработку.

• Данные агрегируются в ClickHouse для формирования оперативной картины текущего состояния.

Здесь также стоит отметить, что при необходимости данные из ClickHouse могут передаваться в другие системы, такие как Lakehouse или MPP-движки, для проведения более глубоких анализов. Причем после завершения обработки данные могут возвращаться обратно в ClickHouse для предоставления пользователям в виде готовых аналитических витрин.

Но стоит понимать, что архитектуру Fast Ingress лучше применять только тогда, когда скорость получения данных сильно важнее точности. 

Примечание: ClickHouse также можно эффективно применять в системах для работы с метриками и логами. Например, с его использованием выстроена архитектура VK StatsHouse — основной системы мониторинга vk.com, которая по состоянию на июнь 2024 года принимала более 1,6 миллиарда измерений в секунду от 28 000 серверов. Подробнее о ней можно почитать на GitHub и узнать из нашего доклада на HighLoad. 

Выводы и рекомендации

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

Конечно, ClickHouse — это не решение для всех проблем с большими данными, и его не стоит выбирать в ситуациях, когда есть тяжелый ETL, высокие требования по качеству данных (нет возможности потерять даже 0,1% данных) и полноценная AD-HOC аналитика.

Вместе с тем система будет оптимальным выбором во многих сценариях. Например:

• Классические RDBMS (Postgres, sq-sql) уже не тянут по скорости. Много колонок в итоговых данных: OLAP витрины 20–50 и более колонок.

• Есть нагруженный BI. Большое количество параллельных подключений к СУБД. Live Connect BI: Superset, Datalans.

• Осуществляется объемная вставка данных в фиксированном формате. Embedded-аналитика, бэкенд для приложений с большими данными (АБ-тесты и подобные).

• Реализуется работа с логами и метриками. Есть необходимость подключаться разными способами: SQL, JDBC, HTTP, RPC.

Но для эффективной работы стоит придерживаться некоторых рекомендаций:

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

• Не стоит злоупотреблять сложными engines. Всегда важно учитывать возможную неконсистентность данных между шардами и репликами.

• Полезно тщательно изучить дополнительные функции ClickHouse SQL и обучить им команду. То же с приемами DE: словари, карты и другие.

Если вы еще не работаете с ClickHouse, можете протестировать его в рамках сервиса VK Data Platform. Для этих целей VK Cloud предоставляет бонус в размере 20 тысяч рублей. Если же уже имеете опыт взаимодействия и построения архитектур с ClickHouse, пожалуйста, поделитесь им в комментариях, будет полезно.