Greenplum на собеседовании Data Engineer

Зачем Greenplum в РФ

Greenplum — open-source MPP-СУБД на основе Postgres. В РФ доминирует в Сбере, X5, банках, телекоме как корпоративный DWH-стек. Если идёшь на собес DE в финтех/ритейл из top-30 — обязательно спросят.

Главная боль без понимания GP — кандидат пишет SQL «как в Postgres», DBA смотрит план — distribution motion на каждом JOIN, кластер ложится. На собесе нужно отличать GP от обычного Postgres именно по этим деталям.

MPP-архитектура

Massively Parallel Processing — данные физически разделены по N segment-серверам. Один master (или standby) координирует, segments хранят данные и выполняют запросы параллельно.

                 [Master]
                    |
        ┌───────────┼───────────┐
    [Segment 1] [Segment 2] [Segment N]

Каждый segment — отдельный Postgres-инстанс со своей частью таблиц. Запрос распараллеливается на сегменты, master агрегирует.

Master не хранит данных — только метаданные и план запроса.

Distribution keys

Для каждой таблицы DE задаёт distribution policy — как строки распределяются по сегментам.

CREATE TABLE orders (
    order_id BIGINT,
    user_id BIGINT,
    amount DECIMAL,
    event_date DATE
)
DISTRIBUTED BY (user_id);

Виды distribution:

• DISTRIBUTED BY (col) — hash по колонке (стандарт)
• DISTRIBUTED RANDOMLY — случайно (для маленьких справочников или вспомогательных таблиц)
• DISTRIBUTED REPLICATED — полная копия на каждом сегменте (для малых dimension)

Правила выбора distribution key:

• Высокая кардинальность (миллионы значений) → равномерное распределение
• Часто используется в JOIN → JOIN сегмент-локальный, без motion
• Стабильность бизнес-смысла (не меняется)

Плохие кандидаты: gender (низкая кардинальность → 99% строк на 2 сегментах), nullable колонки (всё с NULL едет на один сегмент).

Motion-операторы

Когда данные нужно перераспределить — motion. В EXPLAIN видно три типа:

• Redistribute Motion — перераспределение по новому ключу (для JOIN с другим distribution)
• Broadcast Motion — рассылка одной (маленькой) стороны на все сегменты
• Gather Motion — сбор результата на master (финал запроса, ORDER BY)

                Gather Motion
                     ↑
              Hash Join (user_id)
              ↑               ↑
  Redistribute Motion    [orders] (DISTRIBUTED BY user_id)
              ↑
     [users] (DISTRIBUTED BY id)  -- нужен redistribute по user_id

Цель оптимизации — минимизировать motion. JOIN двух таблиц с одинаковым distribution key — без motion, мгновенно. С разными — redistribute, дорого.

На собесе классический вопрос: «как ускорить JOIN orders и users?» — ответ: «выровнять distribution_key (например, user_id у обеих)».

Партиционирование

Дополнительно к distribution каждая таблица может быть партиционирована (как в Postgres):

CREATE TABLE events (
    event_id BIGINT,
    user_id BIGINT,
    event_date DATE
)
DISTRIBUTED BY (user_id)
PARTITION BY RANGE (event_date) (
    START ('2025-01-01') END ('2027-01-01')
    EVERY (INTERVAL '1 month')
);

Distribution + partitioning:

• Distribution делит между сегментами (горизонтальное масштабирование)
• Partitioning делит логически на одном сегменте (партиционное pruning)

WHERE по partition_key → partition pruning, читаются только нужные партиции на каждом сегменте параллельно.

Скос данных и грабли

Skew (скос) — distribution key с неравномерным распределением. На GP это видно командой:

SELECT gp_segment_id, count(*)
FROM orders
GROUP BY 1
ORDER BY 2 DESC;

Если на одном сегменте 80% данных — это skew, запросы будут медленные. Один сегмент работает, остальные ждут.

Решения:

• Поменять distribution key на колонку с более равномерным распределением
• Добавить salt: (user_id, salt) где salt = hash % 10
• DISTRIBUTED REPLICATED для маленькой таблицы

Vacuum / analyze: GP — это Postgres под капотом. Дохлые tuples (после UPDATE/DELETE) висят, статистика устаревает. Регулярный VACUUM ANALYZE обязателен.

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

Не указывать DISTRIBUTED BY. GP по умолчанию использует первую колонку с уникальным constraint, иначе random. Random distribution = motion на каждый JOIN.

Distribution key c низкой кардинальностью. Skew гарантирован. Минимум — несколько тысяч уникальных значений.

Распределённые JOIN без выравнивания keys. Самая частая причина медленных запросов в GP. Проверять EXPLAIN: если видишь Redistribute Motion под JOIN — выравнивай keys.

Игнорировать gp_segment_id в диагностике. Без него не видишь skew. Регулярно мониторить.

ANALYZE забыт. Без актуальной статистики оптимизатор берёт плохие планы (broadcast вместо redistribute и наоборот).

ORDER BY на огромной таблице без LIMIT. Gather Motion стягивает всё на master → master OOM. ORDER BY + LIMIT, или агрегаты вместо сортировки.

Менять distribution key на проде. ALTER TABLE ... SET DISTRIBUTED BY переписывает всю таблицу. На терабайтах — часы downtime.

Связанные темы

• DWH ClickHouse на собесе DE
• Партиционирование в ClickHouse для DE
• Star schema vs Snowflake schema
• Подготовка к собесу Data Engineer
• Spark shuffle и skew

FAQ

Greenplum vs ClickHouse — что выбрать?

GP — традиционный MPP, лучше для сложных JOIN, ACID-гарантий, аналитики банковского уровня. CH — лучше для time-series, append-only fact tables, простых aggregations. В РФ часто используют параллельно: GP — core DWH, CH — горячая аналитика.

Что такое interconnect в Greenplum?

Сетевой слой между master и segments. Передача данных при motion идёт через interconnect. Узкое место на больших кластерах — UDP/TCP параметры важны.

Polar Greenplum или Apache Greenplum?

Apache Greenplum — open-source с 2015, активно развивается. Различные форки (PostgreSQL Pro, Arenadata GP, Tantor) — российские дистрибутивы. На собесе достаточно знать концепты, дистрибутив уточняется по компании.

Bitmap-индексы в GP — стоит использовать?

Для аналитических запросов на низко-кардинальных колонках (gender, status) — да, экономят место и быстрее B-tree на equality. Для high-cardinality — обычный B-tree.

Что такое resource queues?

Механизм управления параллелизмом GP: каждой группе пользователей назначается очередь с лимитами по active queries и memory. Нужен для предотвращения OOM на shared-кластере.

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

Нет. Статья основана на документации Apache Greenplum, опыте DE-команд в РФ. Конкретные настройки зависят от версий и компании.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.