Greenplum: эксплуатация и тюнинг

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

1. #gp_operations1 / 5
   Чем resource groups отличаются от resource queues в управлении нагрузкой Greenplum?

   A)Resource groups и resource queues — полные синонимы одного механизма под разными названиями

   B)Resource queues ограничивают CPU через cgroups, а resource groups — число запросов и память

   C)Оба лимитируют конкуренцию/память; groups новее и лимитируют ещё и CPU

   D)Памятью они не управляют — оба лишь выстраивают приоритет запросов в очереди

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

   +C)Оба лимитируют конкуренцию/память; groups новее и лимитируют ещё и CPU

   // разбор: И resource queues, и resource groups решают проблему конкуренции: не дать нескольким тяжёлым запросам разом выесть память/ресурсы и уронить кластер, распределяя лимиты по классам пользователей/нагрузки. Resource queues — исторически первый механизм: лимиты на число одновременных запросов и память. Resource groups — более новый: помимо конкуренции и памяти, ограничивают ещё и CPU (опираясь на cgroups ОС), давая более полный контроль изоляции нагрузок (ETL против ad-hoc аналитики). В современных развёртываниях чаще выбирают resource groups; оба нельзя включить одновременно — выбирают схему.

2. #gp_operations2 / 5
   Как диагностируют перекос распределения (data skew) таблицы в Greenplum?

   A)Смотрят загрузку CPU координатора: высокая нагрузка на нём означает перекос данных по сегментам

   B)Перекос в Greenplum сложно измерить средствами SQL, нужны внешние системы мониторинга

   C)Считают общее число строк в таблице: чем оно больше, тем сильнее перекос распределения по сегментам

   D)Count(*) по gp_segment_id; большой разброс = плохой ключ распределения

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

   +D)Count(*) по gp_segment_id; большой разброс = плохой ключ распределения

   // разбор: Прямой способ увидеть перекос — распределение строк по сегментам: SELECT gp_segment_id, count(*) FROM t GROUP BY 1 ORDER BY 2 DESC. Если на одном-двух сегментах строк в разы больше, чем на остальных, — это data skew, и запросы по таблице тормозят из-за перегруженного сегмента. Есть и служебные представления gp_toolkit (например, gp_skew_coefficients) для оценки перекоса. Обнаружив skew, меняют ключ распределения на более равномерный (или составной), либо, если равного ключа нет, переходят на DISTRIBUTED RANDOMLY. Проверять перекос стоит после загрузки крупных таблиц.

3. #gp_operations3 / 5
   Почему в Greenplum массовую загрузку делают через gpfdist/gpload, а не через координатор?

   A)Параллельная загрузка сегментами мимо координатора вместо одноканальной

   B)Gpfdist грузит данные через координатор, но сжимает их, поэтому загрузка идёт быстрее обычной

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

   D)Через координатор загрузка параллельна по сегментам, а gpfdist, наоборот, делает её однопоточной

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

   +A)Параллельная загрузка сегментами мимо координатора вместо одноканальной

   // разбор: Если грузить данные через координатор (обычные INSERT/COPY к нему), весь поток идёт через один узел — он становится узким местом, а параллелизм сегментов простаивает. gpfdist — файловый сервер, отдающий данные, к которому сегменты подключаются и тянут свои части одновременно; загрузка идёт параллельно на всех сегментах, минуя координатор. Утилита gpload — обёртка над external table + gpfdist с YAML-конфигом. Так достигают высокой пропускной способности загрузки терабайтов, тогда как одноканальный путь через координатор упирается в его сеть и CPU.

4. #gp_operations4 / 5
   Чем VACUUM append-optimized таблицы отличается от VACUUM обычной heap?

   A)VACUUM на AO-таблице не нужен, потому что append-optimized хранилище не накапливает мусор

   B)AO-VACUUM компактирует файлы при доле удалённых выше порога, а не чистит MVCC-версии построчно

   C)VACUUM AO-таблицы чистит построчные MVCC-версии точно так же и тем же механизмом, что и heap

   D)VACUUM AO-таблицы физически удаляет её актуальные данные, поэтому его запускать опасно

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

   +B)AO-VACUUM компактирует файлы при доле удалённых выше порога, а не чистит MVCC-версии построчно

   // разбор: Heap-таблицы копят мёртвые версии от UPDATE/DELETE, и VACUUM освобождает это место в страницах. У append-optimized другая модель: данные пишутся дописыванием, а UPDATE/DELETE помечают строки логически удалёнными в служебных структурах, физически не убирая их из сегментных файлов. VACUUM по AO-таблице запускает компакцию: если доля логически удалённых строк в файле превысила порог, файл переписывается без них компактно, освобождая место. То есть на AO VACUUM — это про уплотнение после накопленных удалений, а не про построчную чистку MVCC. Ещё один довод не использовать AO под частые точечные правки.

5. #gp_operations5 / 5
   Почему изменение ключа распределения большой таблицы (ALTER ... SET DISTRIBUTED BY) — тяжёлая операция?

   A)Операция мгновенная: Greenplum лишь меняет запись в каталоге, физически данные никуда не переезжают

   B)Тяжесть в том, что операция пересчитывает статистику ANALYZE по всем столбцам таблицы заново

   C)Почти все строки меняют сегмент → физический перелив всей таблицы по сети

   D)Смена ключа затрагивает метаданные партиций и на физическое размещение строк не влияет

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

   +C)Почти все строки меняют сегмент → физический перелив всей таблицы по сети

   // разбор: Ключ распределения задаёт, на каком сегменте лежит строка. Сменив его, почти для всех строк меняется целевой сегмент, поэтому Greenplum вынужден физически перегнать (перераспределить) всю таблицу между сегментами по interconnect и переписать её заново — для большой таблицы это долгая, ресурсоёмкая операция (сеть, диск, блокировки). Отсюда важность выбрать распределение правильно при проектировании, а не «поправить потом». Если всё же меняют, планируют окно: это сравнимо с полной перезаливкой таблицы. Тот же по духу перелив происходит и при добавлении сегментов в кластер (расширение).