Предварительные требования

Этот курс посвящён глубокому изучению ClickHouse — от устройства storage engine до production operations. Он предполагает, что вы уже свободно работаете с реляционными базами данных и знакомы с базовыми концепциями аналитических систем. Если нет — это не приговор, но значит, что часть материала потребует дополнительного изучения параллельно.

Что вы должны знать

SQL: уверенный уровень

ClickHouse использует SQL как основной интерфейс. Вы должны уверенно писать и читать:

SELECT с агрегацией:

SELECT
    toDate(created_at) AS day,
    status,
    count() AS total_orders,
    sum(amount) AS revenue,
    avg(amount) AS avg_order
FROM orders
WHERE created_at >= '2026-01-01'
GROUP BY day, status
HAVING total_orders > 100
ORDER BY day DESC, revenue DESC
LIMIT 50

Если вы понимаете, что делает каждая строка этого запроса и почему HAVING применяется после GROUP BY — с SQL у вас всё в порядке.

JOIN между таблицами:

SELECT
    d.category,
    count() AS fact_count,
    sum(f.revenue) AS total_revenue
FROM fact_sales AS f
INNER JOIN dim_products AS d ON f.product_id = d.id
WHERE f.sale_date >= today() - 30
GROUP BY d.category

Подзапросы и CTE (Common Table Expressions):

WITH daily_revenue AS (
    SELECT
        toDate(event_time) AS day,
        sum(amount) AS revenue
    FROM events
    GROUP BY day
)
SELECT
    day,
    revenue,
    avg(revenue) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS revenue_7day_avg
FROM daily_revenue
ORDER BY day

OLAP-концепции: базовые

Схема “звезда” (Star Schema). Таблица фактов в центре содержит числовые метрики (revenue, quantity, duration). Таблицы измерений вокруг хранят описательные атрибуты (customer_name, product_category, region). JOIN между ними для аналитических запросов.

      dim_customers
           |
dim_products -- fact_orders -- dim_time
           |
       dim_regions

Схема “снежинка” (Snowflake Schema). Расширение схемы звезды: измерения нормализованы — таблица dim_products ссылается на dim_categories, которая ссылается на dim_departments. Снижает дублирование данных, но увеличивает количество JOIN.

Кардинальность (Cardinality). Количество уникальных значений в столбце. Высокая кардинальность: user_id (миллионы уникальных). Низкая кардинальность: status (5–10 уникальных значений). Кардинальность критически важна для выбора первичного ключа, skip-индексов и алгоритмов агрегации в ClickHouse.

Измерения (Dimensions) и факты (Facts). Факты — то, что вы измеряете: revenue, count, duration. Измерения — то, по чему вы группируете: дата, география, категория продукта. В аналитических запросах факты агрегируются (SUM, AVG, COUNT), измерения группируют (GROUP BY) или фильтруют (WHERE).

Командная строка: базовый уровень

Вы должны уметь:

• Запускать Docker-контейнеры: docker compose up -d
• Выполнять команды внутри контейнера: docker compose exec clickhouse clickhouse-client
• Читать вывод терминала и разбирать ошибки

Docker: установлен и работает

На вашей машине должен быть установлен Docker Desktop (Mac/Windows) или Docker Engine + Docker Compose v2 (Linux). Проверка:

docker --version
# Docker version 27.x.x, build ...

docker compose version
# Docker Compose version v2.x.x

Самодиагностика готовности

Если вы можете уверенно ответить на следующие вопросы — вы готовы к курсу:

SQL:

• Чем отличается WHERE от HAVING? (WHERE фильтрует строки до агрегации, HAVING — группы после)
• Что такое LEFT JOIN в отличие от INNER JOIN? (LEFT сохраняет все строки левой таблицы, INNER — только совпадения)
• Как написать запрос, который найдёт топ-10 категорий по выручке за последний месяц? (GROUP BY + ORDER BY + LIMIT)

OLAP:

• Что такое схема звезды и чем она отличается от схемы снежинки?
• Объясните термин “кардинальность” в контексте аналитических запросов
• Если есть таблица fact_orders(order_id, customer_id, product_id, amount, date) и dim_products(id, name, category) — как посчитать суммарную выручку по категориям?

Если хотя бы часть вопросов вызвала затруднение — рекомендуем сначала пройти курсы по основам SQL и OLAP на платформе.

Что этот курс НЕ охватывает

Основы SQL. Синтаксис SELECT, DDL (CREATE TABLE, ALTER TABLE), типы данных — предполагаются известными. В курсе объясняется поведение SQL-конструкций применительно к ClickHouse, а не SQL как язык.

Основы реляционной теории. Нормальные формы (1NF, 2NF, 3NF), концепция FK-связей, ACID-свойства реляционных СУБД. Эти темы предполагаются фоновыми знаниями.

Администрирование операционных систем. Курс предполагает, что вы можете работать с Linux/macOS терминалом. Администрирование ОС, сетевые настройки, файловые системы — выходят за рамки.

Java/Scala/Go. ClickHouse взаимодействует через SQL и HTTP-интерфейс — знание специфических языков не требуется. Code challenges в браузере используют Python и SQL.

Рекомендуемые смежные курсы на платформе

Если хотите углубиться в смежные темы, пройдите параллельно или после курса:

Storage Formats Deep-Dive — Форматы хранения данных (Parquet, ORC, Avro), компрессия, колоночные vs строчные форматы на уровне байтов. Понимание этого курса значительно обогатит восприятие устройства ClickHouse MergeTree parts.

Apache Kafka — Kafka является основным источником данных для многих ClickHouse-развёртываний. В курсе (Phase 60) разбирается Kafka Table Engine. Базовое понимание Kafka полезно, но не обязательно для прохождения курса.

Ключевые выводы

1. Курс предполагает уверенный SQL: GROUP BY, HAVING, JOIN, подзапросы, CTE
2. Необходимо понимание OLAP-концепций: схема звезды/снежинки, факты и измерения, кардинальность
3. Docker должен быть установлен — все lab-упражнения используют clickhouse/clickhouse-server:26.3
4. Курс не учит SQL и не охватывает администрирование ОС — это фоновые знания
5. Самодиагностика: если можете написать GROUP BY с HAVING и объяснить звёздную схему — вы готовы