6 мая 2026 г.·6 мин чтения

ClickHouse и DWH на собеседовании Data Engineer

Готовишься к собесу Data Engineer?
Spark, Airflow, ClickHouse, SQL для DE — вопросы с разборами в Telegram
Тренировать DE в Telegram

Содержание:

Что спрашивают про DWH

Хранилища данных — фундамент DE-роли. На собесе проверяют:

  • Понимание классов хранилищ: OLTP, OLAP, NoSQL, lake, lakehouse
  • Глубину знания одной OLAP-СУБД (обычно ClickHouse в РФ)
  • Моделирование: star schema, snowflake, Data Vault, dbt
  • Trade-offs: когда какое хранилище выбрать

OLAP vs OLTP

OLTP (Online Transaction Processing) — оптимизирован для коротких транзакций (INSERT/UPDATE/DELETE по одной записи). Postgres, MySQL, Oracle. Хорош для: банковские операции, регистрации, корзины.

OLAP (Online Analytical Processing) — оптимизирован для аналитических запросов (SELECT с агрегациями по миллионам строк). ClickHouse, Greenplum, Vertica, Snowflake. Хорош для: дашборды, отчёты, A/B-аналитика.

Главные отличия:

Параметр OLTP OLAP
Запросы Короткие, точечные Долгие, агрегационные
Записи INSERT/UPDATE по одной Bulk INSERT
Хранение Row-based Column-based
Индексы B-tree на колонках поиска Sparse, sort key
Размер До терабайт Терабайты, петабайты
ACID Полный Часто ослабленный

На собесе спросят: «Зачем OLAP отдельно? Почему не использовать Postgres для аналитики?» Ответ: на агрегациях по миллиардам строк Postgres медленный из-за row-based хранения и B-tree индексов. Колоночное хранение читает только нужные колонки и сжимает их в десятки раз эффективнее.

Колоночные хранилища

Принцип: данные одной колонки хранятся вместе, а не строки целиком. Это даёт:

  • Сжатие — данные одной колонки часто похожи (повторяются категории, последовательные даты)
  • Быстрое чтение нужных колонок — SELECT user_id, count FROM events не читает остальные 50 колонок
  • Эффективные агрегации — SUM/COUNT/AVG считаются на сжатом столбце без декомпрессии целиком

Примеры: ClickHouse, Greenplum, Vertica, Snowflake, BigQuery, Parquet (формат).

Цена:

  • INSERT по одной строке — медленнее, чем в OLTP. Все колоночные хранилища предпочитают bulk-INSERT
  • UPDATE — обычно дорогая операция или невозможна
  • Транзакции часто ослаблены

ClickHouse: движки и MergeTree

ClickHouse — главная OLAP-СУБД в РФ. На собесе DE её знают почти всегда.

Движок MergeTree

Базовый движок. Данные хранятся в виде сортированных партов (кусков), которые периодически мержатся в фоне. Главные параметры:

  • PARTITION BY — крупные партиции (обычно по месяцам или дате). Помогает фильтрации.
  • ORDER BY — sort key. По нему данные физически отсортированы внутри парта. Критично для скорости запросов.
  • PRIMARY KEY — обычно равен ORDER BY. Используется для разреженного индекса.

Создание таблицы:

CREATE TABLE events (
  event_date DATE,
  user_id UInt64,
  event_type String,
  properties Map(String, String)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

Варианты MergeTree

  • ReplacingMergeTree — при мерже оставляет последнюю запись по ORDER BY. Подходит для дедупликации.
  • SummingMergeTree — суммирует значения числовых колонок при мерже. Для агрегатных таблиц.
  • AggregatingMergeTree — для произвольных агрегаций через AggregateFunction.
  • CollapsingMergeTree — для упрощённых апдейтов через флаг sign (+1 / -1).
  • VersionedCollapsingMergeTree — то же, но с версионированием для распределённых сценариев.

На собесе спросят: «Когда использовать ReplacingMergeTree vs SummingMergeTree?» Ответ: Replacing — когда нужна последняя запись по ключу (например, актуальное состояние юзера). Summing — когда нужна агрегация (например, daily counters).

Distributed таблицы

Для шардирования между серверами. Distributed-таблица сама не хранит данные, а маршрутизирует запросы к шардам.

CREATE TABLE events_distributed AS events
ENGINE = Distributed(cluster_name, current_database, events, rand());
Готовишься к собесу Data Engineer?
Spark, Airflow, ClickHouse, SQL для DE — вопросы с разборами в Telegram
Тренировать DE в Telegram

Greenplum и MPP

Greenplum — MPP (Massive Parallel Processing) на основе Postgres. Данные распределены между сегментами, запросы параллелятся автоматически.

Когда выбирают Greenplum:

  • Сложные SQL-запросы с многочисленными JOIN
  • Регулярные апдейты данных
  • Нужна полная совместимость с Postgres-экосистемой

ClickHouse быстрее на простых агрегациях, Greenplum гибче на сложных аналитических запросах.

Моделирование DWH

Кимбалл (star schema)

  • Fact таблицы — события, измерения метрик. Большие, append-mostly.
  • Dim таблицы — справочники. Маленькие, обновляются.
  • Star schema — один fact, несколько dim, JOIN по PK/FK.

Inmon (3NF)

  • Полностью нормализованное хранилище
  • Лучше для интеграции данных из разных систем
  • Запросы дороже из-за множества JOIN

Data Vault

  • Hubs (бизнес-объекты), Links (связи), Satellites (атрибуты)
  • Хорошо для постоянно меняющейся структуры
  • Сложно в обращении для аналитиков — поверх делают star schema marts

dbt и материализации

dbt — инструмент управления трансформациями в DWH. Главные материализации:

  • view — SQL-вьюха
  • table — таблица, перезаписывается каждый раз
  • incremental — таблица, обновляется только новыми данными
  • ephemeral — CTE, не материализуется

На собесе спросят: «Когда incremental, когда table?» Ответ: incremental для больших fact-таблиц с append-mostly паттерном. Table для маленьких dimension-таблиц или агрегатов, которые перерасчитываются каждый день.

Выбор технологии под задачу

«У нас events 100 ГБ/день, нужна аналитика. Что выберешь?» Ответ зависит от:

  • Объёмы — до 1 ТБ Postgres ещё ок; 10+ ТБ — обязательно OLAP
  • Запросы — агрегации → ClickHouse; сложные JOIN → Greenplum
  • Записи — потоковые → ClickHouse + Kafka; батчевые → можно DWH через Airflow
  • Команда — какие компетенции есть
  • Бюджет — Snowflake дорого, ClickHouse дешевле

Частые ошибки

Использовать ClickHouse для OLTP-задач. UPDATE/DELETE в ClickHouse тяжёлые. Если нужны частые апдейты — это OLTP-кейс, не OLAP.

Не партиционировать большие таблицы. Отсутствие partitioning — главная причина медленных запросов в OLAP.

Игнорировать ORDER BY в ClickHouse. Sort key определяет, насколько быстро будут работать запросы. Без хорошего sort key даже партиционированная таблица медленная.

Делать звезду из transactional БД. Star schema на Postgres = много JOIN на агрегациях. На объёмах это медленно. Используйте OLAP.

Сложные UDF в OLAP-СУБД. OLAP оптимизированы для встроенных функций. Кастомные UDF часто работают на порядки медленнее.

FAQ

Snowflake / BigQuery — стоит учить?

В РФ почти не используются (санкции). Концептуально — да, для понимания cloud DWH. Для собеса в российской компании — Greenplum/ClickHouse приоритетнее.

Iceberg / Delta Lake — что это?

Lakehouse-форматы. Хранят данные в Parquet поверх S3/HDFS, добавляют ACID-транзакции и schema evolution. Тренд 2024-2026, в РФ внедряется в крупных компаниях (X5, Сбер).

Сколько ClickHouse-практики нужно?

Один реальный проект с правильным MergeTree, partition, sort key. Уметь дебажить медленные запросы через EXPLAIN PIPELINE.

Это официальная информация?

Нет. Статья основана на публичных источниках и опыте кандидатов.

Ещё по теме