Вопросы по Greenplum на собеседовании

Greenplum встречается в российских хранилищах достаточно часто, чтобы вопросы про него стали стандартом для дата-инженера. Всё сводится к одному: как разложены данные по сегментам и что произойдёт при неудачном ключе распределения.

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Распределение по сегментам13
• Хранение таблиц13
• Эксплуатация и тюнинг13
• Motion и выполнение12
• MPP-архитектура12

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• MPP-архитектура12 вопросов
• Greenplum: распределение по сегментам13 вопросов
• Motion и выполнение12 вопросов
• Greenplum: эксплуатация и тюнинг13 вопросов
• Greenplum: хранение таблиц13 вопросов

Примеры вопросов с разбором

1. #gp_architecture1 / 9
   Что такое Greenplum на уровне архитектуры?

   A)MPP-хранилище на базе PostgreSQL: shared-nothing кластер, где данные и вычисления распределены по многим сегментам

   B)Это плагин к PostgreSQL, ускоряющий обычную одноузловую базу без какого-либо распределения данных

   C)Это документо-ориентированная NoSQL-база без поддержки SQL и реляционной модели данных

   D)Это система потоковой обработки сообщений вроде Kafka, а не хранилище для аналитики

   показать ответ и разбор

   +A)MPP-хранилище на базе PostgreSQL: shared-nothing кластер, где данные и вычисления распределены по многим сегментам

   // разбор: Greenplum — массивно-параллельная (MPP) аналитическая СУБД на базе PostgreSQL. Архитектура shared-nothing: кластер из координатора (в GP6 — мастер) и множества сегментов, каждый со своим CPU, памятью и диском. Таблица разложена по сегментам, и запрос выполняется на всех них параллельно, а результаты собираются. Так обрабатывают объёмы, недоступные одному Postgres. Это OLAP-движок под большие сканы и агрегации, а не под OLTP.

2. #gp_distribution2 / 9
   Что задаёт секция DISTRIBUTED BY при создании таблицы в Greenplum?

   A)По какому столбцу (хешу) строки раскладываются по сегментам — ключ распределения таблицы

   B)Порядок сортировки строк внутри каждого сегмента для ускорения диапазонных запросов

   C)Столбец, по которому таблица делится на партиции по диапазонам значений (например, по дате)

   D)Столбец, значения которого обязаны быть уникальными, как первичный ключ в обычной СУБД

   показать ответ и разбор

   +A)По какому столбцу (хешу) строки раскладываются по сегментам — ключ распределения таблицы

   // разбор: DISTRIBUTED BY (col) задаёт ключ распределения: Greenplum берёт хеш от значения столбца и по нему определяет сегмент для строки. Так таблица равномерно (при хорошем ключе) раскладывается по сегментам, обеспечивая параллелизм. Ключ распределения — не то же, что первичный ключ или партиционирование: он про то, НА КАКОМ сегменте лежит строка. Плохой выбор ключа даёт перекос (skew) или лишний сетевой обмен при джойнах.

3. #gp_motion_exec3 / 9
   Что такое motion (движение) в плане запроса Greenplum?

   A)Пересылка строк между сегментами по сети для джойна/агрегации/сбора

   B)Motion — это операция сортировки строк внутри одного сегмента перед выдачей результата

   C)Motion — это чтение данных с диска сегмента в его оперативную память перед обработкой

   D)Motion — перемещение таблицы между разными базами данных внутри одного кластера Greenplum

   показать ответ и разбор

   +A)Пересылка строк между сегментами по сети для джойна/агрегации/сбора

   // разбор: Motion — узел плана, отвечающий за перемещение строк между сегментами (или на координатор) по interconnect. Он появляется, когда данные лежат «не там, где нужно» для следующего шага: джойн по не-ключу распределения, агрегация не по ключу, сбор финала наверх. Motion — самая дорогая часть распределённого плана (сеть + сериализация), поэтому цель оптимизации — минимизировать его: хорошим распределением, co-location, репликацией мелких таблиц. В EXPLAIN motion-узлы обычно наверху плана.

4. #gp_operations4 / 9
   Зачем в Greenplum регулярно выполняют VACUUM heap-таблиц?

   A)Чистит мёртвые версии MVCC, борется с bloat и деградацией сканов

   B)VACUUM физически удаляет актуальные данные таблицы для экономии места на дисках сегментов

   C)VACUUM нужен, чтобы заново вычислить статистику для планировщика запросов Greenplum

   D)VACUUM в Greenplum не требуется, так как MVCC здесь не оставляет мёртвых версий строк

   показать ответ и разбор

   +A)Чистит мёртвые версии MVCC, борется с bloat и деградацией сканов

   // разбор: Greenplum наследует MVCC от PostgreSQL: UPDATE/DELETE не затирают строку сразу, а помечают старую версию мёртвой и создают новую. Без очистки мёртвые версии копятся — таблица и индексы распухают (bloat), сканы читают лишние мёртвые строки и замедляются, растёт место. VACUUM освобождает пространство мёртвых версий для повторного использования (а VACUUM FULL перестраивает таблицу компактно, но с блокировкой). Особенно важен для heap-таблиц с активными UPDATE/DELETE; на них же держат разумный autovacuum/регламент. Длинные транзакции мешают очистке, удерживая старые версии.

5. #gp_storage5 / 9
   Какой тип хранения таблицы в Greenplum используется по умолчанию и для чего он хорош?

   A)Heap (строковый, как в PostgreSQL) — годится для таблиц с частыми UPDATE/DELETE и точечными вставками

   B)По умолчанию используется колоночное хранение, оптимальное для точечных обновлений отдельных строк

   C)По умолчанию append-optimized, поэтому частые UPDATE и DELETE выполняются в heap-таблице быстрее всего

   D)Тип хранения по умолчанию отсутствует: его обязательно указывают явно при создании каждой таблицы

   показать ответ и разбор

   +A)Heap (строковый, как в PostgreSQL) — годится для таблиц с частыми UPDATE/DELETE и точечными вставками

   // разбор: По умолчанию таблица в Greenplum — heap (строковое хранение, унаследованное от PostgreSQL с его MVCC). Heap хорош для данных, которые часто меняются: итеративные UPDATE, DELETE, одиночные INSERT работают нормально. Обратная сторона — MVCC оставляет «мёртвые» версии строк, поэтому heap-таблицы пухнут (bloat) и требуют VACUUM. Для больших, преимущественно дописываемых и читаемых аналитических таблиц берут append-optimized хранение, которое компактнее и быстрее на bulk-нагрузке.

6. #gp_architecture6 / 9
   Какова роль координатора (в GP6 — мастера) в Greenplum?

   A)Координатор хранит все пользовательские данные кластера, а сегменты лишь кэшируют их копии

   B)Вход/парсинг/планирование/координация; данные лежат на сегментах

   C)Координатор — это резервная копия одного из сегментов, включаемая при его падении

   D)Координатор выполняет все вычисления запроса сам, а сегменты отдают ему сырые строки

   показать ответ и разбор

   +B)Вход/парсинг/планирование/координация; данные лежат на сегментах

   // разбор: Координатор — единственная точка, к которой подключаются клиенты и шлют SQL. Он парсит запрос, строит распределённый план, раздаёт его сегментам, собирает их результаты и возвращает клиенту. Сам он пользовательских данных не хранит — они на сегментах. Есть standby-координатор на случай отказа. Практическое следствие: тяжёлые операции, стягивающие все данные на координатор, — узкое место; их избегают.

7. #gp_distribution7 / 9
   Какое распределение выберет Greenplum, если DISTRIBUTED BY не указан явно?

   A)Строго случайное (RANDOMLY) распределение, независимо от наличия первичного ключа

   B)Хеш по первичному ключу, если он есть, иначе по первому подходящему столбцу; при отсутствии такого — случайное

   C)Реплицирует таблицу целиком на все сегменты, раз ключ распределения не задан явно

   D)Отказывается создавать таблицу с ошибкой, требуя обязательно указать ключ распределения

   показать ответ и разбор

   +B)Хеш по первичному ключу, если он есть, иначе по первому подходящему столбцу; при отсутствии такого — случайное

   // разбор: Если DISTRIBUTED BY опущен, Greenplum по умолчанию выбирает хеш-распределение: по первичному ключу, если он объявлен, иначе по первому столбцу таблицы. Если подходящего столбца нет — распределяет случайно (RANDOMLY). Это опасно: первый столбец легко оказывается плохим ключом (низкая кардинальность, часто NULL) и даёт перекос, а неявный выбор маскирует проблему. Хорошая практика — всегда задавать DISTRIBUTED BY осознанно (поведение по умолчанию ещё зависит от параметра gp_create_table_random_default_distribution).

8. #gp_motion_exec8 / 9
   Что делает gather motion в плане Greenplum?

   A)Рассылает копию данных с координатора на все сегменты перед началом их параллельной работы

   B)Собирает строки со всех сегментов на координатор — обычно финальный шаг, отдающий результат клиенту

   C)Перераспределяет строки между сегментами по новому ключу для последующего джойна

   D)Сортирует итоговый результат на каждом сегменте независимо, не пересылая строки никуда

   показать ответ и разбор

   +B)Собирает строки со всех сегментов на координатор — обычно финальный шаг, отдающий результат клиенту

   // разбор: Gather motion стягивает строки со всех сегментов на координатор — как правило, последний шаг плана, после которого результат уходит клиенту. Небольшой финальный gather нормален. Проблема — когда наверх собирают большой несжатый объём (нет предварительной агрегации/фильтрации на сегментах): координатор становится узким местом. Поэтому эффективные планы максимально агрегируют и фильтруют на сегментах, а gather'ят уже компактный результат. В EXPLAIN «Gather Motion N:1» означает сбор с N сегментов в одну точку.

9. #gp_operations9 / 9
   Зачем в Greenplum нужен ANALYZE и что случится без актуальной статистики?

   A)Без статистики запросы выполняются чуть медленнее, но план остаётся оптимальным

   B)Свежая статистика → верные оценки → хороший план (джойн/motion)

   C)ANALYZE физически перераспределяет данные по сегментам для устранения перекоса распределения

   D)ANALYZE нужен обычному PostgreSQL, а планировщик Greenplum в статистике не нуждается

   показать ответ и разбор

   +B)Свежая статистика → верные оценки → хороший план (джойн/motion)

   // разбор: ANALYZE собирает статистику по таблицам (кардинальность, гистограммы, доли значений), на которую опирается планировщик, оценивая размеры промежуточных результатов и стоимость. В MPP это критично вдвойне: от оценок зависит выбор стратегии джойна и типа motion — например, решение сделать broadcast «маленькой» таблицы. Устаревшая статистика (после массовой загрузки без ANALYZE) ведёт к грубым ошибкам оценки: планировщик разошлёт broadcast'ом реально большую таблицу или выберет неоптимальный redistribute — запрос деградирует на порядки. Поэтому ANALYZE запускают после значимых загрузок.

Частые вопросы

• Что такое перекос данных и чем он опасен?

  Неравномерное распределение строк по сегментам: один узел работает за всех, запрос ждёт его. Ключ распределения выбирают так, чтобы значения были высококардинальными и равномерными.

• Чем Greenplum отличается от обычного PostgreSQL?

  Это MPP-система из мастера и сегментов: данные распределены, а запрос выполняется параллельно с пересылкой данных между узлами. Отсюда и особые операции в плане запроса.