ClickHouse важен не обещанием быстрых отчетов, а тем, как он устроен вокруг реального потока аналитических данных: колонночное хранение, MergeTree, фоновые merge-процессы и тяжелые read-path сценарии.
В инженерной работе эта глава помогает проектировать таблицы, сортировочные ключи, партиционирование и materialized views под вопросы бизнеса, а не под форму исходных событий, и тем самым заранее управлять свежестью данных и ценой ingest.
В интервью и архитектурных обсуждениях она особенно сильна там, где нужно четко развести OLAP и OLTP, а также показать, почему ClickHouse хорош для аналитики, но не заменяет систему записи.
Практическая польза главы
Модель аналитических данных
Проектируйте таблицы и партиционирование под реальные аналитические вопросы, а не по структуре источников.
Ingestion и merge
Закладывайте batching, sort keys и фоновые merge-процессы в расчет ingest latency и свежести данных.
Стоимость производительности
Оптимизируйте storage policy, compression и materialized views для баланса скорости и стоимости.
Interview perspective
Четко отделяйте ClickHouse как OLAP-движок от OLTP-сценариев и объясняйте компромисс eventual consistency загрузки.
Официальная документация
ClickHouse Docs
Базовые концепции: table engines, архитектура, SQL и операционные практики.
ClickHouse — колонночная OLAP СУБД для аналитики на больших объёмах. Её сильная сторона — быстрые агрегирующие запросы по событиям и логам при высоком throughput записи и эффективной компрессии данных.
История: ключевые вехи
Внутренний запуск в Яндексе
ClickHouse появляется как колонночная аналитическая база для высоконагруженных отчётов.
Open source релиз
Проект становится публичным и начинает развиваться в open-source экосистеме.
Выделение отдельной компании ClickHouse, Inc.
Команда запускает отдельную компанию вокруг проекта, фокус смещается на коммерческую экосистему и cloud-направление.
Cloud и экосистема
Развитие managed-предложений, object storage интеграций и экосистемы инструментов.
Ключевые принципы архитектуры
Column-oriented storage
Чтение только нужных колонок резко снижает I/O для аналитических запросов.
MergeTree family
Партиции, сортировка, фоновые merge-процессы и репликация — ядро большинства продакшен-инсталляций.
Vectorized execution
Запросы выполняются батчами, что повышает throughput и эффективность CPU-кеша.
Compression + skipping
Колоночная компрессия и data skipping индексы ускоряют scan-heavy workload.
High-Level Architecture
На high-level уровне ClickHouse разделяет client layer, coordinator layer и storage/background слой MergeTree. Запись и чтение идут через координаторы, а фактическое хранение и вычисления происходят на shard-репликах.
Sharded + Replicated
Канонический продакшен-профиль: шардирование по ключу, репликация через Keeper и параллельный scan.
Плюсы
- Горизонтальный масштаб под рост данных.
- Лучший read throughput и отказоустойчивость.
- Гибкая балансировка write/read пути по узлам.
Ограничения
- Выше операционная сложность.
- Нужен контроль lag, merge backlog и skew.
Workload Queue
Control Plane
Запросы распределяются по шардам, а реплики обеспечивают HA и масштаб чтения.
Готово к симуляции архитектуры ClickHouse.
Последнее решение
—
Активный шаг: idle
Shard A / R1
primary replica
parts: 36 | reads: 0 | writes: 0
Shard A / R2
secondary replica
parts: 35 | reads: 0 | writes: 0
Shard B / R1
primary replica
parts: 34 | reads: 0 | writes: 0
Shard B / R2
secondary replica
parts: 33 | reads: 0 | writes: 0
Replication & Merges
Keeper ops: 0
Репликация и merge-процессы держат parts и lag в управляемом диапазоне.
Cluster Counters
reads: 0 | writes: 0 | parts: 138 | Avg lag: 1.5
Контролируйте баланс между ingestion throughput, merge backlog и query latency.
Architecture Checklist
Write / Read Path через компоненты
Ниже интерактивная схема, где видно прохождение запросов через ключевые компоненты: coordinator, shard replicas, Keeper и background процессы.
Read/Write Path Explorer
Интерактивный разбор прохождения clickhouse-запросов через coordinator, shard replicas, Keeper и background процессы.
Write path
- Клиент отправляет INSERT батчами (обычно через HTTP/native protocol).
- Координатор маршрутизирует batch по shard key на нужные реплики.
- Данные пишутся в новые parts внутри MergeTree-таблиц и синхронизируются через Keeper.
- Background merge-процессы укрупняют parts, применяют TTL/mutations и оптимизируют хранение.
Практика моделирования данных
- Сначала проектируй под шаблоны чтения и агрегации, а не под OLTP-нормализацию.
- Выбирай ORDER BY так, чтобы ключевые фильтры максимально отсеивали данные.
- Используй партиционирование по времени/домену для управляемых retention и scan.
- Применяй materialized views для pre-aggregation горячих аналитических отчётов.
- Планируй TTL/retention заранее — объёмы в аналитике растут быстро.
Когда выбирать ClickHouse
Хорошо подходит
- Product analytics, BI-дашборды, observability/лог-аналитика.
- Событийные и time-series данные с очень высоким write throughput.
- Сложные агрегирующие запросы по большим историческим объёмам.
- Near-real-time витрины данных для команд продукта и аналитики.
Стоит избегать
- OLTP-сценарии с частыми point-updates и короткими транзакциями.
- Нагрузки, где критичны row-level lock и строгая transactional семантика.
- Системы с множеством мелких UPDATE/DELETE в реальном времени.
- Use cases, где ключевая задача — online serving по одной записи.
Связанные главы
- Database Selection Framework - Как понять, когда ClickHouse подходит как основная аналитическая платформа и где проходит граница с OLTP-системами.
- Как устроены системы хранения данных - Базовый контекст по типам хранилищ и компромиссам, в который укладывается колонночный OLAP-подход ClickHouse.
- YDB: distributed SQL база данных и архитектура - Практика построения OLTP + OLAP контура: транзакционный слой на distributed SQL и аналитический слой на ClickHouse.
- DuckDB: embedded OLAP база данных и архитектура - Сравнение distributed OLAP-кластера и embedded OLAP-движка для локальной аналитики и ETL/ELT задач.
- Time-Series Databases: выбор и архитектура - Граница между TSDB и ClickHouse для метрик, событий и high-cardinality аналитических запросов.
- ETL/ELT и архитектура data pipeline - Как организовать ingestion и трансформации данных перед загрузкой в ClickHouse для near-real-time и batch-аналитики.