Первое что мы смотрим — на какой версии работает кластер и есть ли план её обновления.

Greenplum 6.x основан на PostgreSQL 9.4, поддержка которого завершена. Это означает отсутствие патчей безопасности, устаревший оптимизатор запросов и невозможность использовать современные расширения. Greenplum 7.x (Arenadata DB 7.x) переходит на PostgreSQL 12, что даёт принципиально новый планировщик, улучшенную работу с партиционированием и долгосрочную поддержку вендора.

Что проверяем:

• Версия ядра: PostgreSQL и Greenplum/ADB, дата выхода из поддержки
• План миграции: Наличие утверждённого плана обновления версии

Риск: Уязвимости безопасности, деградация производительности, невозможность получить поддержку вендора при инцидентах.

Один из самых частых источников проблем в реальных кластерах — избыточное количество сегментов на хост.

Каждый сегментный процесс потребляет память, файловые дескрипторы и CPU. При выполнении запроса мастер координирует все сегменты одновременно — чем их больше, тем выше накладные расходы на межсегментное взаимодействие. На практике мы видели кластеры с 30+ сегментами на хост, где тяжёлые запросы вызывали OOM и каскадное падение сегментов.

Рекомендуемая формула: 1 сегмент на каждые 4 vCPU. Для хоста с 64 vCPU оптимально 16 сегментов.

Что проверяем:

• Сегментов на хост: Количество primary и mirror, соотношение к числу CPU
• Топология зеркалирования: Group mirror vs spread mirror

Риск: Исчерпание памяти при пиковой нагрузке, высокие накладные расходы на координацию, нестабильность кластера.

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

HugePages. Без HugePages ядро тратит значительные ресурсы на управление таблицами страниц для сотен сегментных процессов. Включение HugePages снижает накладные расходы и предотвращает фрагментацию памяти.

Swap. Использование swap на сегментном хосте — это почти всегда инцидент. Один медленный сегмент из-за свопирования замедляет весь распределённый запрос. Мы устанавливаем vm.swappiness=10 и следим чтобы swap не использовался в штатном режиме.

gp_vmem_protect_limit. Это главный параметр защиты от OOM в Greenplum. Формула: (RAM × 0.9) / количество сегментов на хост. Для хоста с 377 GB RAM и 16 сегментами — примерно 21 GB на сегмент.

pgBouncer — пулер соединений. В Greenplum каждое клиентское соединение с мастером порождает дерево процессов на всех сегментах одновременно. При 24 активных соединениях и 192 сегментах в кластере это более 4600 процессов — каждый потребляет память на каждом хосте.
pgBouncer в режиме Transaction Pooling решает эту проблему радикально: сотни клиентских подключений (DBeaver, Cognos, ETL-скрипты) мультиплексируются в небольшой пул реальных соединений с мастером.

Это снижает потребление памяти, устраняет «шторм соединений» при одновременном старте множества клиентов и защищает кластер от зависания при исчерпании лимита max_connections.

Мы рассматриваем отсутствие pgBouncer в production кластере Greenplum как архитектурный риск, а не просто упущенную оптимизацию.

Что проверяем:

• HugePages: Состояние, количество выделенных страниц
• Swap: Текущее использование, vm.swappiness, vm.overcommit_memory
• gp_vmem_protect_limit: Текущее значение, соответствие формуле расчёта
• pgBouncer: Наличие, режим работы, количество реальных соединений с мастером

Риск: OOM на сегментных хостах, деградация всех запросов при свопировании, зависание кластера при шторме соединений.

Удивительно часто мы обнаруживаем кластеры с терабайтами данных без актуального резервного копирования. Причины разные: gpbackup установлен, но не настроен; есть cron-задачи, но они выполняют maintenance, а не полноценный backup; последний успешный бэкап был несколько месяцев назад.

Для Greenplum используется нативный инструмент gpbackup/gprestore. Важно не просто наличие бэкапа, но и регулярная проверка возможности восстановления.

Что проверяем:

• Регулярность: Наличие и расписание gpbackup в crontab
• Актуальность: Дата последнего успешного бэкапа
• RTO/RPO: Целевое время и точка восстановления
• Тест восстановления: Наличие процедуры проверки gprestore

Риск: При отказе кластера или ошибке миграции без актуального бэкапа восстановление данных невозможно.

Параметры конфигурации Greenplum требуют тонкой настройки под конкретное железо и нагрузку. Мы проверяем ключевые параметры памяти, планировщика и отказоустойчивости.

Память: shared_buffers (стартово 1 GB на сегмент), effective_cache_size (стартово 20–40 GB), statement_mem и max_statement_mem (память на запрос и потолок).

Планировщик: random_page_cost (для SSD снижается до 1.1, но только после тестирования планов), параметры ORCA-оптимизатора.

Отказоустойчивость FTS: gp_fts_probe_timeout и gp_fts_probe_retries — параметры системы мониторинга состояний сегментов. При высокой нагрузке на CPU сегменты могут не успевать отвечать на опросы FTS в стандартный тайм-аут, что приводит к ложным срабатываниям и каскадному падению. Мы рекомендуем увеличить timeout до 60 секунд и retries до 5.

Что проверяем:

• shared_buffers: Значение на сегмент, соответствие RAM
• gp_vmem_protect_limit: Расчётное vs фактическое
• statement_mem: Значение, соответствие resource groups
• FTS параметры: gp_fts_probe_timeout и gp_fts_probe_retries
• archive_mode: Статус WALarchiving (осознанно off или настроен)

В этой области мы регулярно обнаруживаем системные проблемы, которые никак не проявляются в ежедневной работе — до первого инцидента.

SUPERUSER. Типичная картина: SUPERUSER выдан не только gpadmin, но и сервисным аккаунтам (загрузчик данных, мониторинг) и персональным пользователям. Компрометация любого из них даёт полный контроль над кластером.

pg_hba.conf. Метод аутентификации trust означает что любой процесс из указанной подсети подключается без пароля. Мы переводим аутентификацию на scram-sha-256.

Объектные права. Широкие права INSERT/UPDATE/DELETE/TRUNCATE у аналитических пользователей — источник случайных и намеренных повреждений данных.

PXF-секреты. Credentials к внешним источникам (HDFS, S3, JDBC) часто хранятся в открытом виде в конфигурационных файлах.

Что проверяем:

• SUPERUSER: Список ролей с привилегией суперпользователя
• pg_hba.conf: Методы аутентификации, наличие trust
• Объектные права: Матрица прав по ролям и схемам
• PXF server profiles: Наличие секретов в открытом виде

Риск: Компрометация сервисного аккаунта = полный доступ к кластеру. Подключение без пароля из любого процесса в подсети.

Это один из наиболее специфичных для Greenplum аспектов аудита, который при этом оказывает прямое влияние на производительность.

Greenplum распределяет строки таблицы между сегментами по ключу распределения (DISTRIBUTED BY). Если ключ выбран неудачно — данные концентрируются на нескольких сегментах, а остальные простаивают.
Запрос выполняется со скоростью самого загруженного сегмента.

Коэффициент перекоса (skew coefficient) выше 1.5 требует внимания. Мы видели таблицы с коэффициентом 700–900, где 50–65% всех данных находилось на 1–2 сегментах из 192.

Отдельная проблема — таблицы с DISTRIBUTED RANDOMLY. Это допустимо для небольших справочников, но для крупных фактовых таблиц лишает Greenplum возможности выполнять collocated join без перемешивания данных по сети.

Что проверяем:

• Топ таблиц по skew: Коэффициент перекоса, размер, частота использования
• DISTRIBUTED RANDOMLY: Список крупных таблиц без явного ключа
• Соответствие ключей: Ключи распределения vs бизнес-логика запросов

Риск: Запросы к перекошенным таблицам выполняются в разы медленнее вне зависимости от количества сегментов.

В аналитических хранилищах таблицы растут быстро и без контроля. Мы анализируем топ таблиц по размеру в каждой базе и оцениваем наличие политик управления данными.

Характерные находки:

• Временные таблицы (mart_tmp, stg) в production базе объёмом десятки гигабайт без автоматической очистки
• Dev-база сопоставимого с production размера — признак отсутствия lifecycle-политики
• Системная база gpperfmon без retention policy — растёт неограниченно и в конечном счёте заполняет диск
• Крупные таблицы без секционирования по дате — затрудняют архивирование и удаление устаревших данных

Что проверяем:

• Топ таблиц: Топ-20 по размеру в каждой базе
• Секционирование: Наличие партиций по дате для исторических таблиц
• Retention policy: Для gpperfmon, devdb, mart_tmp и временных схем

pg_stat_statements — первое что мы проверяем. Без него невозможен анализ топ запросов по потреблению ресурсов. В большинстве аудируемых кластеров это расширение не установлено, хотя доступно.

Мониторинг. Типичная картина — мониторинг собран из разнородных скриптов и cron-задач без единой observability-модели. Мы рекомендуем стек Prometheus + Grafana + greenplum_exporter + node_exporter как минимальную основу для production кластера.

diskquota — расширение для ограничения дискового пространства по схемам и ролям. Особенно актуально при совместном использовании кластера prod и dev командами.

Что проверяем:

• pg_stat_statements: Установлено / не установлено в dwhprod и devdb
• pxf / pxf_fdw: Регистрация в БД с external tables
• Мониторинг: Наличие единого стека, покрытие метрик
• diskquota: Наличие квот по схемам и ролям

В Greenplum ресурсные группы (resource groups) позволяют изолировать различные типы нагрузки: ETL-процессы, BI-запросы, разработческие запросы, ad-hoc аналитику.

Типичная картина в аудируемых кластерах: вся нагрузка идёт через default_group и admin_group. Это означает что тяжёлый ETL может полностью заблокировать интерактивные запросы аналитиков, а разработческий запрос без ограничений может занять всю память кластера.

Что проверяем:

• Текущие группы: Параметры CPU, памяти, concurrency
• Назначение ролей: Какие роли в каких группах
• Изоляция нагрузки: Разделение prod/dev/ETL/BI/ad-hoc