Модуль 17. Greenplum в Kubernetes
Контекст и когда это уместно
Greenplum — MPP-движок (master/standby + N сегментов/зеркала) поверх PostgreSQL. В k8s это возможно, но требует строгой работы со стойками/зональной раскладкой, быстрых дисков и оператора/автоматизации жизненного цикла. Если есть «железные» требования по последовательной пропускной способности и фиксированным хостам, иногда выгоднее остаться на VM/бэр-металле (или делать гибрид).
Архитектурные принципы в k8s
- Роли кластера: master + standby master, segment primary + segment mirror, PXF/ETL-узлы.
- Пулы нод: pool=gp-seg (сегменты, высокие IOPS/пропускная), pool=gp-master (мастера), pool=stateless (PXF/оркестрация).
- Сторидж: RWO-блок с низкой латентностью (NVMe/SSD). Для бэкапов — объектное S3 (MinIO/облако). Избегайте сетевых томов с непредсказуемой задержкой.
- Сеть: межсегментная interconnect должна быть быстрой и предсказуемой (10/25 GbE), минимизируйте кросс-AZ трафик.
- Раскладка: topology spread + podAntiAffinity, чтобы primaries и их mirrors шли на разные ноды/зоны.
Операционка и жизненный цикл
-
Деплой/скейлинг: используйте оператор/автоматизацию, которая:
- создаёт master/standby как StatefulSet с отдельными PVC,
- управляет N сегментами (StatefulSet со стабильно индексируемыми именами),
- оркестрирует gprecoverseg, gpinitstandby, gpexpand.
- Апгрейды: rolling для сегментов (с зеркалами) и контролируемый переключатель мастера.
- Бэкапы/DR: gpbackup/gprestore в S3; журнал WAL не заменяет логического DR — продумайте active-passive на уровне площадок (копия бэкапов + automation на развертывание compute).
- Наблюдаемость: gp_toolkit + экспортеры: ожидания/блокировки, skew по сегментам, очередь запросов, interconnect retransmits.
Производительность и схемотехника
- Дистрибуция: правильный DISTRIBUTED BY (минимум data skew), HASH по ключу фактов.
- Партиционирование: по дате/бизнес-срезам; не дробите сверх меры (избыточные партиции = много метаданных).
- Resource Groups/Queues: лимитируйте «шумных соседей» (BI/ад-hoc против ETL).
- PXF/внешние таблицы: используйте для чтения S3/HCatalog, но для SLA-витрин лучше материализовывать.
Сетевые и безопасные контуры
- Namespace «gp» с default-deny и явными разрешениями к IdP/S3/мониторингу.
- SSO в BI/оркестрацию — отдельно; к Greenplum доступ через pgBouncer/прокси и роле-модель.
Риски и анти-паттерны
|
Риск |
Проявление |
Что делать |
|---|---|---|
|
Interconnect «гуляет» |
Всплески latency, деградация джоб |
Закрепить сегменты в одном AZ/стойке; быстрый fabric; ограничить кросс-зонные маршруты |
|
Сегмент+зеркало на одной ноде |
Потеря узла = потеря данных |
Anti-affinity/топология, контроль при автоскейле |
|
Сетевой/Ceph-блок медленный |
Merge/scan тормозят |
NVMe локально/высокопроизводительный блок; проверить RF/журнал |
|
Сильный skew |
Один сегмент «горит» |
Пересмотреть ключ дистрибуции; переразбивка |
|
Нет автоматики recover/expand |
Долгое восстановление |
Оператор/скрипты на gprecoverseg/gpexpand, runbook |
Практика (мини-лаб)
- Спроектировать кворум: 1 master + 1 standby, 4 primaries + 4 mirrors (8 сегментов) на 4 нодах пула gp-seg.
- Настроить topology spread: primaries и их mirrors на разных нодах/зонах.
- Прогнать тестовые TPC-DS запросы, снять skew/время, скорректировать ключи распределения.
- Настроить gpbackup в S3 и сделать пробное gprestore в отдельный namespace.
