ClickHouse тормозит не из-за терабайтов, а из-за кривого запроса к ним

ClickHouse тормозит не из-за терабайтов, а из-за кривого запроса к ним

Если аналитика по трафику начинает «думать» по минуте, сначала смотрим не на железо, а на SQL. Типовые убийцы производительности:
— SELECT * вместо узкого списка колонок
— фильтрация после JOIN, а не до
— функции по полю партиции в WHERE
— GROUP BY по сырому UUID там, где хватает campaign_id

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

Дальше — дедупликация и агрегации. Не тащите сырые события в финальный дашборд, если можно собрать витрину на уровне pre-aggregated таблиц. Для постбеков и логов это особенно важно: сначала нормализация, потом join по справочникам, потом уже метрики. Иначе любой отчёт превращается в full scan с красивым названием.

Проверяем сходимость дельты в трекере и кабинете, а потом уже оптимизируем SQL-запрос на лету. Всё, что не автоматизировано — это потенциальный убыток.