В разборах ниже свяжите задачу с механизмом ClickHouse и объясните поведение после сбоя или изменения нагрузки.
Ситуации для собеседования
Попробуйте сначала объяснить решение вслух, затем откройте разбор.
Чем аналитический журнал отличается от транзакционной записи приложения?
Аналитический журнал обычно читают большими диапазонами по нескольким колонкам и агрегируют. Колоночное хранение, сжатие и параллельное выполнение сокращают такую работу. Транзакционная запись приложения часто требует точечных изменений и согласованности связанных записей. Выбор зависит от реального договора данных; утверждать, что ClickHouse вообще не умеет изменения, неверно.
В MergeTree один ID встречается дважды. Это ошибка PRIMARY KEY?
Нет: ключ определяет организацию чтения и разреженный индекс, но не уникальное ограничение. Нужно выяснить договор событий и повторы загрузки. Если требуется последнее состояние, возможна версионная модель со стабильным ORDER BY; если нужны все события, повторный ID может быть допустим или потребуется event_id.
Запрос по источнику читает почти всю таблицу. Что проверить первым?
Фактический DDL и план EXPLAIN: начало ORDER BY, предикат, выбранные parts и гранулы. Затем read_rows/read_bytes, память и время из query_log. Увеличение max_threads не устраняет лишнее чтение; skipping index помогает только при возможности отсечь блоки.
Почему один INSERT создал несколько parts, а две части не сливаются?
Один INSERT может охватывать разные партиции. Parts разных партиций не объединяются. Также учитываются разбиение вставки и физическое устройство. Фоновые merges не обещают одну часть всей таблицы к фиксированному времени.
Дневная витрина хранит средние блоков. Можно ли усреднить их?
Только если корректно учесть число наблюдений каждого блока. Надёжнее хранить сумму и количество либо avgState, а на чтении объединять их. То же внимание к объединению нужно для распределённого запроса; суммы локальных unique counts тоже неверны при пересечении пользователей.
Kafka lag равен нулю. Данные полные?
Это ещё не доказано. Нужно проверить стартовую позицию группы, ошибки и пропуски, landing и витрину, контрольные события и повторы. Сбой между записью и подтверждением offsets способен повторить блок. Живой процесс не подтверждает живой consumer loop.
После merge Replacing источник правильный, но витрина завышена. Почему?
Incremental view обработала обе вставленные версии. Merge источника не триггерит пересчёт истории target. Нужно обеспечить корректный вход агрегата или выбрать процедуру пересчёта; FINAL в источнике задним числом не отменит прежние вклады.
После TTL строк не видно. Диск уже освобождён?
Нужно различать правило TTL, его фоновое применение, логическую видимость и физические файлы. Для lightweight DELETE маска может скрыть строки до освобождения байтов merge. Дополнительно учитываются реплики и резервные копии, если есть требование физического удаления.
Поддерживает ли ClickHouse JOIN по неравенству?
Да. Для 25.8 условия между колонками разных таблиц поддерживают hash и grace_hash, без join_use_nulls. Современная документация также перечисляет parallel_hash. Нужно назвать версию, тип соединения и алгоритм. ASOF выбирает ближайшее совпадение и не заменяет ALL-соединение со всеми подходящими интервалами.
Когда sorting merge JOIN может сэкономить ресурсы?
Когда входы уже упорядочены совместимо с ключами соединения, полную сортировку может удаваться пропустить. При других данных сортировка сама стоит времени и диска. Такой алгоритм есть в ClickHouse; его преимущество определяется планом и ресурсами, а не названием СУБД.
Как корректно ответить на вопрос о CAP для ClickHouse?
Уточнить путь записи и чтения, репликацию, quorum-настройки и вид отказа. Асинхронная копия может отставать; ожидание кворума может уменьшать доступность записи. Keeper отвечает за координацию, инициатор — за запрос. Одна безусловная метка CP или AP не описывает все эти механизмы.
Итоговый тест
Что уметь объяснить
Для знакомого запроса объясните, какие колонки и диапазоны нужно читать, какие состояния объединяются и где появляется финальный результат. Для загрузки назовите границу подтверждения и место возможного повтора. Для витрины объясните, как исправление исходной истории попадёт в сохранённый результат. Эти ответы связывают устройство ClickHouse с корректностью данных.