Федеральный ритейлер с сетью 800 магазинов по всей России накапливал транзакционные данные из торговых систем (чеки, движение товара, логистика) в реляционной PostgreSQL-базе, которая уже не справлялась с аналитическими запросами: BI-система формировала недельный отчёт по всем магазинам за 4,5 часа, а операционные аналитики ждали результатов срочных запросов по 25–40 минут. Объём данных за 5 лет работы превысил 18 ТБ, ежедневный прирост — около 60 ГБ. Архитектурное решение — мигрировать аналитическую нагрузку с PostgreSQL на Greenplum MPP-хранилище: параллельная обработка на нескольких узлах сокращает время аналитических запросов в 10–30 раз для больших объёмов данных.
Задача клиентаПоставить серверную инфраструктуру для кластера Greenplum: мастер-сервер + 8 сегментных узлов + standby-мастер. Каждый сегментный узел — 2U с большим числом CPU-ядер и быстрыми дисками для параллельного сканирования. Целевые характеристики: недельный аналитический отчёт — менее 15 минут, срочные аналитические запросы — менее 3 минут. Бюджет — 10,8 млн рублей. 25 GbE между всеми узлами кластера — требование Greenplum для interconnect трафика между сегментами.
Ограничения и требования- 25 GbE interconnect: Greenplum перемещает большие объёмы данных между сегментами при JOIN и GROUP BY — медленная сеть убивает преимущества MPP.
- Большое число ядер на сегментный узел: Greenplum использует до N×2 процессов на узел (N = число сегментов), нужно не менее 32 физических ядер на узел.
- Ёмкость хранения: 18 ТБ текущих данных + 3 года прироста × 22 ТБ/год = 84 ТБ минимум с учётом сжатия Greenplum (реальная экономия 3–4x для ритейловых данных).
- Standby-мастер для автоматического фейловера мастер-узла.
- Размещение в существующем ЦОД Москвы: две стойки 42U, питание 16А на стойку.
Мастер-сервер и standby-мастер: 2×сервер 2U, 2×Xeon Gold 6338 (64 ядра суммарно), 512 ГБ DDR4 ECC, 4×NVMe 3.84 ТБ RAID-10 (координатор Greenplum не хранит данные, но активно работает с метаданными и распределяет запросы — быстрые диски важны). Восемь сегментных узлов: 2U, 2×Xeon Gold 6354 (36 ядер, высокая частота 3,0 ГГц для сканирования), 256 ГБ DDR4 ECC, 12×SAS SSD 7.68 ТБ в JBOD (Greenplum управляет данными напрямую через AO-таблицы, RAID-контроллер не нужен — производительность лучше без дополнительного уровня абстракции).
Выбор SAS SSD вместо NVMe для сегментных узлов обоснован экономически: Greenplum выполняет последовательное сканирование больших таблиц, где разница задержки NVMe vs SAS SSD (0,1 мс vs 0,3 мс) практически не влияет на throughput последовательного чтения. Ограничивающим фактором для сканирования является полоса пропускания дисков, а не задержка. SAS SSD 7.68 ТБ обеспечивает 2 200 МБ/с последовательного чтения — практически на уровне NVMe при вдвое меньшей цене за терабайт, что позволяет разместить больше ёмкости в рамках бюджета.
Interconnect-сеть: два коммутатора 25 GbE 48-port в режиме стека с LACP, все 10 серверов подключены по 2 порта 25 GbE каждый (active-active bonding). Суммарная полоса interconnect: 10 серверов × 2×25 GbE = 500 Гбит/с доступной полосы — более чем достаточно для даже самых JOIN-тяжёлых аналитических запросов. Мастер-серверы подключены дополнительно к клиентской сети 10 GbE для подключения BI-инструментов (Tableau, Apache Superset).
Хранение «холодных» данных: партиционирование таблиц Greenplum по месяцу позволяет хранить данные старше 3 лет в сжатом формате ZSTD (коэффициент сжатия 4:1 для ритейловых данных) на более дешёвых полках. Ёмкость 8 сегментных узлов × 12 × 7.68 ТБ = 736 ТБ raw обеспечивает хранение 80+ ТБ несжатых данных с возможностью хранить весь 5-летний архив.
Настройка Greenplum под ритейловый профиль нагрузки включала несколько ключевых параметров. gp_vmem_protect_limit — ограничение памяти на процесс: при 256 ГБ RAM и 32 сегментах на узел (4 primary + 4 mirror) каждый сегментный процесс получает до 4 ГБ памяти для hash-агрегаций и sort-операций. Statement_mem увеличен до 2 ГБ для BI-запросов через Resource Queue. Параметр effective_cache_size выставлен на 80% от RAM узла: Greenplum использует это значение для планировщика при выборе между seq scan и index scan — правильное значение критично для эффективных планов выполнения.
Мониторинг Greenplum-кластера настроен через gpmetrics и Prometheus: утилизация CPU/RAM по каждому сегментному узлу, spill-файлы на диске (признак нехватки памяти для операции), время выполнения активных запросов, очередь Resource Queue. Дашборд в Grafana позволяет DBA в реальном времени видеть распределение нагрузки по узлам кластера и выявлять «горячие» сегменты — дисбаланс данных между сегментами, который деградирует производительность запросов. Алерт при spill свыше 100 ГБ за час: признак неоптимального SQL-запроса, требующего ревью.
Стратегия партиционирования таблиц фактов: ежедневные транзакционные таблицы (чеки, строки чеков, логи движения товара) партиционированы по дате создания с диапазоном partition 1 месяц. Это позволяет Greenplum пропускать целые партиции при запросах с фильтром по дате — partition pruning снижает объём сканируемых данных с 18 ТБ до 1–2 ТБ для типичного месячного отчёта. Без партиционирования тот же запрос сканировал бы всю таблицу — разница в скорости составляет 8–12 раз для стандартных BI-запросов аналитиков ритейлера.
Интеграция Greenplum с ETL-пайплайном ритейлера выполнена через Apache Airflow: ежедневная загрузка данных из транзакционных PostgreSQL-баз магазинов в Greenplum с трансформацией (нормализация форматов, обогащение справочниками). Производительность загрузки через gpfdist (Greenplum File Distribution Server): 18 ГБ сжатых данных за 8 минут против 4 часов при загрузке через стандартный COPY в PostgreSQL. gpfdist использует параллельную загрузку из всех сегментных узлов одновременно — пропускная способность масштабируется с числом узлов кластера.
Состав поставки по подсистемам- Мастер-узлы: 2×сервер 2U, 2×Xeon Gold 6338, 512 ГБ DDR4, 4×NVMe 3.84 ТБ RAID-10.
- Сегментные узлы: 8×сервер 2U, 2×Xeon Gold 6354, 256 ГБ DDR4, 12×SAS SSD 7.68 ТБ JBOD.
- Сеть: 2×коммутатор 25 GbE 48-port в стеке, 20 DAC-кабелей 25G, 4 патч-корда 10G.
- Питание: 10×ИБП 2 кВА он-лайн с SNMP, кабели питания C13/C19.
- День 1–3: Финализация Greenplum topology (число сегментов на узел, interconnect VLAN), счёт.
- День 4–14: Сборка партии, тест interconnect сети в стойке до отгрузки.
- День 15: Доставка в ЦОД Москвы.
- День 16–18: Монтаж, кабелирование, базовая настройка BIOS для Greenplum (NUMA, HT).
Greenplum-кластер принял нагрузку через 3 недели после поставки оборудования. Недельный аналитический отчёт по 800 магазинам формируется за 9 минут вместо 4,5 часов. Срочные аналитические запросы аналитиков — от 40 секунд до 2,5 минут в зависимости от сложности. Экономия к бюджету — 15%: выбор SAS SSD вместо NVMe на сегментных узлах снизил стоимость на 1,7 млн рублей без измеримой потери производительности для Greenplum-нагрузки.
Производительность превзошла ожидания заказчика: аналитики получили возможность запускать ad-hoc запросы напрямую из Tableau к Greenplum без предварительной подготовки агрегатов. До миграции любой нестандартный запрос требовал написания ETL-джобы и ожидания ночного запуска — процесс занимал 1–3 рабочих дня. Теперь аналитик получает ответ на нестандартный вопрос за 1–4 минуты.
Планирование расширения: архитектура Greenplum позволяет добавить сегментные узлы с автоматическим перераспределением данных. Через 2 года, при росте объёма данных или числа аналитиков, достаточно добавить 4 узла идентичной конфигурации — данные перераспределятся автоматически через команду gpexpand, производительность вырастет пропорционально числу узлов.
Почему выбрали нас- Опыт подбора серверов под Greenplum MPP: соотношение ядер, RAM и дискового IOPS под аналитическую нагрузку.
- Обоснование SAS SSD vs NVMe для сегментных узлов с конкретными замерами throughput — экономия 1,7 млн рублей без потери производительности.
- Тест interconnect-сети на стенде до отгрузки в ЦОД.
- Весь кластер поставлен одним заказом: серверы, коммутаторы, кабели, ИБП — единый счёт с НДС.
Данные приведены справочно и не являются публичной офертой. Актуальные цены, наличие и сроки поставки уточняйте при оформлении заказа.