Модуль 18. ClickHouse в Kubernetes
ClickHouse — колоночная OLAP-СУБД с высокой скоростью агрегаций. В k8s — нативный сценарий через оператор (Altinity ClickHouse Operator/совместимые). Подходит для витрин, телеметрии, real-time аналитики, CDC-хвостов, логов.
Архитектурные принципы
- Топология: shards × replicas (например, 2×2), ZooKeeper/ClickHouse Keeper для координации.
- Тома: RWO-блок на быстрых SSD/NVMe; размер партиций — крупнее (день/неделя), чтобы снизить количество кусков.
- Tiered Storage (опционально): «холод» в S3 (HDD/объектное) через диски типа s3 — экономия TB при умеренном SLA чтения.
Оператор и кластерация
-
Оператор управляет:
- раскладкой шардов/реплик,
- users/quotas/row-policies,
- шаблонами хранилищ, бэкапами (через clickhouse-backup), обновлениями.
- Раскладка по зонам: topologySpread + anti-affinity; реплики в разных зонах; шард-локальность данных.
Схемотехника и производительность
- Движки: MergeTree/ReplicatedMergeTree для фактов; Aggregating/ Summing/ Replacing по задаче; Distributed — для фан-аут на шарды.
- Партиционирование: по дате/бизнес-ключу; ORDER BY — по селективности (ключ запросов).
- Материализованные представления: pre-agg/rollup; снижает нагрузку на онлайн агрегации.
- TTL/мутации: чистка старых партиций/строк, фоновые OPTIMIZE.
- Kafka-интеграция: Kafka engine + Materialized View → ingestion потоков.
Эксплуатация
- Бэкапы: clickhouse-backup в S3; регулярные restore-учения.
- Наблюдаемость: system.tables/parts/merges/replication_queue; метрики latency/parts size/merges backlog.
- Квоты/лимиты: у пользователей/BI ограничивайте max_concurrent_queries, max_memory_usage, read_overflow_mode=break.
Безопасность/сеть
- NetworkPolicy: BI/Trino/оркестрация — по allow-list, запрет cross-ns.
- SSO: через прокси/Ingress; в самом CH — роли и политики строк (Row Policy) для RLS.
- Секреты: External Secrets + Vault; TLS к клиентам/между репликами по возможности.
Риски и анти-паттерны
|
Риск |
Проявление |
Что делать |
|---|---|---|
|
Много «мелких файлов» (частые вставки маленькими батчами) |
Медленные запросы/мерджи |
Увеличить batch size, настроить max_partitions_per_insert_block, плановые OPTIMIZE |
|
Merges backlog |
Рост диска/латентность |
Достаточный CPU/IO, ограничить конкурирующие тяжёлые запросы |
|
Непродуманное ORDER BY |
Плохой «seek», CPU вспышки |
Перепроектировать ключ под типовые запросы |
|
Keeper SPOF/нехватка |
Задержки DDL/репликаций |
HA Keeper, мониторинг очередей репликации |
|
«Расшитые» права BI |
Прямой доступ ко всем базам |
Роли, row policies, отдельные users per-app |
Интеграция с Lakehouse/Trino
- Trino каталог clickhouse (или jdbc) — единая точка доступа для BI и смешанных джойнов (CH + Iceberg/PG).
- Для дешёвого хранения — S3 + S3 disks в CH (cold tier) или полностью Iceberg + Trino, а в CH держать «горячие» представления/агрегаты.
Практика (мини-лаб)
- Развернуть кластер 2×2 (два шарда, по две реплики) оператором.
- Создать таблицу ReplicatedMergeTree с партиционированием по дню и ORDER BY (customer_id, event_time).
- Завести Materialized View для дневных агрегатов; включить TTL на «хвост» старше 180 дней.
- Настроить бэкап/restore в S3 и проверить восстановление в тестовый namespace.
- Подключить Trino → SELECT по Distributed таблице; замерить p95, отрегулировать max_threads/квоты.
