Разделение вычислений и хранения в Greenplum: опыт использования S3 и проекта Yezzey
Современные аналитические платформы сталкиваются с двумя ключевыми вызовами: рост объема данных и рост затрат на их хранение. Традиционная архитектура Greenplum предполагает, что данные хранятся локально на дисках сегментных узлов. Это обеспечивает высокую скорость запросов, но при больших объемах данных расходы на локальное хранение становятся значительными.
Облачные хранилища, такие как Amazon S3, Yandex Object Storage или MinIO, предлагают в разы более дешевое хранение (до 10 раз дешевле, чем локальные диски SSD/HDD), а также практически неограниченный объем. Однако возникает вопрос: как использовать облако без потери производительности и при этом интегрировать его в Greenplum так, чтобы для пользователя ничего не менялось?
Ответом на этот вызов стало расширение Yezzey, позволяющее разделить вычислительные ресурсы Greenplum и хранение данных, вынеся “холодные” данные в S3.
Архитектура решения
Классическая схема Greenplum
В стандартной конфигурации Greenplum каждый сегмент хранит свою часть данных локально. Объем кластера напрямую зависит от объема доступных локальных дисков. Если данные растут быстрее, чем можно добавить дисков или узлов — возникают ограничения.
Архитектура с Yezzey
Проект Yezzey меняет эту картину. Он встраивается в Greenplum как расширение и:
- Позволяет хранить данные в S3, MinIO или другом совместимом хранилище.
- Прозрачно для пользователя подменяет источник данных: оптимизатор Greenplum видит таблицу так, будто она локальная.
- Поддерживает операции INSERT/SELECT/DELETE без переписывания запросов.
В основе подхода — идея, что данные не всегда нужны “под рукой”. Часть таблиц или старые партиции можно выгрузить в облако, при этом Greenplum продолжит к ним обращаться, загружая их по сети.
Автоматическое охлаждение данных
В ранней версии проекта была реализована функция автоматического охлаждения: данные, к которым не было обращений в течение заданного периода, автоматически перемещались в S3.
Однако на практике этот подход показал ряд минусов:
- Данные иногда «охлаждались» слишком рано, и их приходилось снова подгружать в оперативную работу.
- Сеть становилась узким местом при массовом возвращении данных.
- Пользователи не всегда понимали, почему запрос внезапно стал работать медленнее.
В итоге автоматическое охлаждение было выведено из эксплуатации, а перенос данных в облако стал выполняться по управляемому сценарию — например, для старых партиций или архивных таблиц.
Производительность
Замеры
- На обычных запросах (агрегации, фильтры по ключам) разница во времени выполнения между локальным хранением и S3 — около 25%.
- На сложных запросах с большими джойнами, агрегациями и фильтрами — разницы практически нет.
- Оптимизатор Greenplum не видит разницы между локальными и S3-данными — план выполнения строится одинаково.
Причина небольшой разницы
Производительность в первую очередь упирается в пропускную способность сети. При наличии 10GbE и выше работа с S3 практически не уступает локальным дискам, особенно если используется параллельная загрузка сегментами.
Восстановление и шифрование
При восстановлении кластера, использующего S3:
- Необходимо скачать данные из облака и заново выполнить их шифрование.
- Yezzey делает это автоматически, пользователю не нужно вручную восстанавливать файлы.
- Поддерживается работа с зашифрованными бакетами и KMS.
Автоматическое масштабирование
Пока что автоматическое масштабирование в Yezzey — в стадии проектирования. Планируется:
- Возможность сжимать кластер при малых нагрузках (отключать часть сегментов).
- Гибкое расширение вычислительных узлов для выполнения тяжелых запросов.
Требования к инфраструктуре
Для стабильной работы Greenplum с Yezzey и S3:
- Сеть — 10GbE и выше, стабильное подключение к S3.
- Балансировка нагрузки — чтобы исключить ситуации, когда один сегмент “ждет” данные дольше остальных.
- Совместимое хранилище — Amazon S3, MinIO, Yandex Object Storage или другое S3 API-совместимое решение.
- Мониторинг запросов — контроль за тем, какие таблицы и партиции часто читаются, чтобы не перегружать сеть.
Плюсы подхода
- Экономия — до 10 раз дешевле хранения на локальных дисках.
- Гибкость — можно хранить исторические данные в облаке, не загружая локальные ресурсы.
- Прозрачность — оптимизатор Greenplum не требует изменений запросов.
- Масштабируемость — объем данных не ограничен емкостью локальных дисков.
Минусы и ограничения
- Сеть — узкое место. При медленном канале S3-запросы будут выполняться дольше.
- Нет локального кэширования — каждый запрос читает данные заново.
- Автоматическое охлаждение оказалось неэффективным — перенос в облако лучше делать осознанно.
Практические кейсы
Кейс 1: Архивирование исторических данных
Крупный ритейлер переместил 5 лет транзакций в S3 через Yezzey. Экономия на хранении составила 1,2 млн ₽ в год. При этом аналитические запросы по этим данным выполнялись всего на 20% медленнее.
Кейс 2: Облачный резерв
Банк использует Yezzey для хранения бэкапов аналитических витрин в S3. Это позволило убрать необходимость расширения SAN и сократить затраты на DR-сайт.
Кейс 3: Гибридная архитектура
IT-компания хранит “горячие” данные последних 3 месяцев локально, а всё остальное — в MinIO. Greenplum прозрачно обрабатывает смешанные запросы.
Типичные ошибки внедрения
- Недооценка роли сети — при канале 1GbE пользователи сталкиваются с резким падением скорости.
- Охлаждение часто используемых данных — ведет к постоянным подгрузкам из облака.
- Отсутствие мониторинга — невозможно понять, какие данные нужно хранить локально, а какие — в S3.
- Отсутствие тестирования на больших объемах — на маленьких тестах все быстро, на проде — сетевой bottleneck.
Рекомендации
- Всегда начинайте с пилота на реальных данных.
- Настройте метрики по чтению таблиц — они помогут решить, что отправлять в облако.
- Используйте параллельные каналы для загрузки данных из S3.
- Планируйте сегментацию по “горячим” и “холодным” данным.
- Рассмотрите MinIO on-premise как вариант для изоляции от внешних облаков.
Разделение вычислений и хранения в Greenplum с использованием S3 через Yezzey — рабочая и перспективная архитектура, позволяющая существенно снизить затраты на хранение данных без критичных потерь в производительности.
Однако для успеха проекта необходимы:
- качественная сеть,
- мониторинг использования данных,
- правильная стратегия перемещения данных в облако.
Yezzey уже показал хорошие результаты на продакшн-проектах, но дальнейшие улучшения в области кэширования и масштабирования могут сделать его еще более привлекательным инструментом для аналитических платформ.
