Apache Cloudberry^™: что это за СУБД и почему её называют преемником Greenplum^®

Почему рынок ищет замену Greenplum

Apache Cloudberry появился как ответ на закрытие Greenplum, поэтому начнём с контекста. Больше десяти лет Greenplum оставался стандартом де-факто среди открытых аналитических СУБД: на нём строили корпоративные хранилища банки, ритейл и телеком. Осенью 2023 года репозиторий проекта неожиданно перестал принимать пулл-реквесты внешних разработчиков, а в мае 2024-го Broadcom, купившая VMware^® вместе с командой Greenplum, закрыла исходный код. Репозиторий на GitHub превратился в архив.

Кластеры продолжают работать, но патчи безопасности, поддержка нового железа и свежих форматов данных больше не приходят. Положение осложняет возраст ядра: большинство промышленных инсталляций работает на Greenplum 6, построенном на PostgreSQL 9.4, а поддержку этой версии прекратили ещё в феврале 2020 года.

Ответ пришёл из самого сообщества. Команда, которая когда-то создавала Greenplum, ещё в 2022 году начала развивать открытый форк — Apache Cloudberry. В октябре 2024 года проект приняли в инкубатор Apache Software Foundation, и сегодня именно его чаще других называют преемником Greenplum. Мы в Yandex Cloud участвуем в этой работе напрямую: наши инженеры контрибьютят в Cloudberry, в том числе на уровне комитета управления проектом.

Что такое Apache Cloudberry

Apache Cloudberry — это открытая MPP-СУБД для аналитики больших объёмов данных, созданная первоначальной командой разработчиков Greenplum. Идея проекта прямолинейна: сохранить проверенную распределённую платформу Greenplum, но заменить встроенное ядро на современную версию PostgreSQL. Код распространяется под лицензией Apache License 2.0 и открыт на GitHub.

Cloudberry совместим с Greenplum на уровне SQL, приложений и инструментов, поэтому командам, которые уже работают с Greenplum, не приходится переучиваться. При этом внутри немало нового: обновлённое ядро, гибридный формат хранения и векторный движок выполнения запросов. Обо всём этом — ниже.

Что такое MPP-архитектура

MPP — это massively parallel processing, массово-параллельная обработка данных: запрос делится между десятками независимых узлов, и каждый обрабатывает свой фрагмент данных одновременно с остальными. Так MPP-системы отвечают на аналитические запросы к терабайтам данных за секунды или минуты, а не часы.

В MPP-СУБД данные заранее распределены по узлам-сегментам. У каждого сегмента свои процессор, память и диск, общих ресурсов нет — такую схему называют shared-nothing. Отсюда горизонтальное масштабирование: когда нужно больше производительности, в кластер добавляют сегменты, а не наращивают один сервер.

Как устроен кластер на верхнем уровне

Кластер Cloudberry состоит из координатора и сегментов. Координатор принимает SQL-запрос и превращает его в распределённый план выполнения, сегменты хранят данные и параллельно выполняют свою часть работы, а промежуточными результатами узлы обмениваются через интерконнект — выделенный сетевой слой.

Что значит статус инкубации в Apache

Инкубатор — стандартный путь любого нового проекта в Apache Software Foundation: Cloudberry сейчас имеет статус Incubating (Podling). Проектом управляет комитет PPMC из разработчиков разных компаний и стран, решения принимаются открытым голосованием, а инфраструктура и торговые марки принадлежат фонду, некоммерческой организации. Для пользователей это страховка от повторения истории Greenplum: судьбу проекта не может единолично решить ни одна корпорация.

От Greenplum к Cloudberry: краткая история

Чтобы понять, почему Cloudberry появился и кому он нужен, достаточно посмотреть на хронологию:

За сухими датами заметна закономерность: пока Greenplum переходил из рук в руки и терял темп, форк набирал сообщество. Уже через два месяца после открытия кода у Cloudberry появились первые внешние контрибьюторы, а к 2026 году активность проекта обгоняет все остальные ветви наследия Greenplum вместе взятые. Историю проекта и детали архитектуры мы подробно разбирали в первой части гида по Cloudberry.

Архитектура Cloudberry

Архитектура Cloudberry повторяет проверенную схему Greenplum — координатор, сегменты и интерконнект между ними, — но с обновлённой начинкой.

Координатор (Coordinator Node) служит входной точкой кластера. Он принимает подключения, парсер разбирает запрос, оптимизатор строит распределённый план, а диспетчер раздаёт задания сегментам. Каждый сегмент — по сути самостоятельный экземпляр PostgreSQL: он хранит свою долю данных, которую определяет ключ распределения, и обсчитывает её локально.

Крупные таблицы внутри сегментов дополнительно делятся на части — партиционирование по диапазонам, спискам и хешу помогает отбрасывать лишние данные ещё на этапе планирования запроса.

Отказоустойчивость и репликация

Отказоустойчивость кластера строится на трёх механизмах: хранении метаданных о состоянии в etcd, резервном координаторе и зеркалировании сегментов.

Распределённое хранилище etcd знает актуальную топологию кластера и состояние каждого узла. Резервный координатор (Standby) постоянно синхронизирует журналы с основным, и если основной выходит из строя, управление переключается автоматически, без участия администратора. Данные сегментов защищает репликация через WAL-журнал: у каждого сегмента есть зеркало, которое подхватывает нагрузку при сбое. Схему резервирования можно выбрать: взаимное даёт больше надёжности, перекрёстное меньше теряет в производительности.

Обновлённое ядро PostgreSQL

Ядро — главное внутреннее отличие Cloudberry: версии 2.x построены на PostgreSQL 14, тогда как Greenplum 6 так и остался на PostgreSQL 9.4, разница между которыми — семь лет развития.

На практике это означает полноценную работу с JSON и JSONB, UPSERT через синтаксис INSERT … ON CONFLICT, хеш-партиционирование, неблокирующее перестроение индексов REINDEX CONCURRENTLY, инкрементальную сортировку и современную аутентификацию SCRAM-SHA-256.

Появился и нативный механизм внешних таблиц FDW — на нём в Cloudberry построен PXF, открывающий доступ к HDFS, S3, Hive и внешним базам по JDBC. Следующий шаг тоже виден: апгрейд ядра до PostgreSQL 16 уже выполнен в апстриме и проходит стабилизацию, в продакшен он придёт с мажорным релизом Cloudberry 3.x.

Чем Cloudberry отличается от Greenplum и других форков

Коротко: от Greenplum — современным ядром, форматом хранения и векторным движком; от других форков — вендор-нейтральной моделью управления и темпом разработки.

Начнём с совместимости, потому что для мигрирующих команд она важнее новинок. Приложения, SQL-запросы и инструменты Greenplum работают в Cloudberry без переделки, несовместимые изменения точечные — полный их список есть в официальном сравнении Cloudberry и Greenplum. Поэтому переход корректнее описывать не как миграцию на другую СУБД, а как апгрейд той же платформы до живой версии.

Производительность подтверждает независимый замер. Команда SynxData, которая продаёт дистрибутив на базе Cloudberry в Европе, прогнала бенчмарк TPC-DS: 99 аналитических запросов к данным объёмом 1 ТБ. При последовательном выполнении Cloudberry оказался примерно на 22% быстрее Greenplum 6 и на 12% быстрее Greenplum 7 — разбор бенчмарка и сравнение форков мы публиковали в статье на Хабре. У других форков публичных результатов TPC-DS нет.

Ключевые возможности Cloudberry

Сильные стороны Cloudberry удобно разбирать по слоям: как данные хранятся, как выполняются запросы и что происходит вокруг классического SQL.

Векторный движок и векторизация запросов

Векторизация означает, что движок обрабатывает данные не по одной строке, а пакетами, батчами. Это позволяет задействовать SIMD-инструкции современных процессоров и полнее утилизировать CPU, а вместо процессов Cloudberry использует более лёгкие потоки.

Векторный движок включён по умолчанию (параметр vector.enable_vectorization), поддерживает основные типы данных и операторы: сканирование, агрегации, соединения, сортировку. Заметнее всего выигрыш на тяжёлых агрегациях поверх колоночного хранения.

PAX: гибридный формат хранения

PAX (Partition Attributes Across) — формат хранения, который объединяет удобство строковых таблиц с колоночной скоростью чтения; идейно он близок современным Lakehouse-форматам.

Колоночный формат AOCO из Greenplum упирается в файловую механику: таблица на тысячу столбцов означает тысячу файлов и дорогие операции их открытия и закрытия. PAX хранит данные блоками, сгруппированными по столбцам внутри файла, поэтому читает только нужные колонки, а min-max-статистика и bloom-фильтры позволяют пропускать нерелевантные блоки целиком. Добавьте современные кодеки сжатия — и получится формат, на котором векторному движку есть где разогнаться.

Оптимизации исполнения запросов

Несколько движковых оптимизаций работают в связке с оптимизатором, который сравнивает стоимость планов и выбирает самый дешёвый. Aggregation Pushdown выполняет агрегацию до соединения, ближе к данным, поэтому по сети передаётся меньше промежуточных результатов — для OLAP-нагрузок это один из главных источников ускорения.

RuntimeFilter строит bloom-фильтр параллельно с хеш-таблицей и отсеивает лишние кортежи ещё до hash join. Параллельное выполнение задействует несколько ядер CPU под один запрос, причём число воркеров подбирается динамически по объёму данных, а не ограничено числом сегментов. Свою долю добавляют BRIN-индексы с режимами multi-minmax и bloom.

Аналитика почти в реальном времени

В Greenplum свежие витрины данных означали внешние пайплайны и оркестраторы. Cloudberry закрывает часть этих сценариев штатно. Динамические таблицы — это результат запроса, который сам актуализируется по расписанию: дашборд остаётся свежим без ручных ETL-джобов (чем ETL-подход отличается от ELT, мы разбирали в отдельной статье).

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

Интеграции: внешние данные, Kubernetes^® и ИИ-агенты

Через FDW Cloudberry выполняет запросы между несколькими кластерами, причём соединения и агрегации уезжают на целевой кластер, чтобы не гонять промежуточные данные по сети.

Directory tables приводят в порядок неструктурированные данные: документы, изображения и другие файлы в локальном или объектном хранилище получают метаданные и становятся доступны прямо из SQL. Кластер можно разворачивать в Kubernetes. Есть и примета времени — MCP-сервер, через который базой управляют ИИ-агенты и LLM-инструменты: первый шаг к аналитическим ассистентам поверх хранилища.

Безопасность и шифрование

Корпоративные требования аудита Cloudberry закрывает штатными средствами. Прозрачное шифрование данных (TDE) с алгоритмами AES и SM4 защищает файлы на диске, pgcrypto добавляет шифрование на уровне отдельных полей.

Динамическое маскирование скрывает чувствительные значения в тестовых и аналитических средах, а Row-Level Security ограничивает доступ к строкам без обходных представлений. Со стороны аутентификации — SCRAM-SHA-256, Kerberos, LDAP и политики паролей с блокировкой учётной записи после серии неудачных попыток входа.

Для каких задач используют Cloudberry

Основной сценарий — корпоративное хранилище данных и OLAP-аналитика поверх него; сверх этого Cloudberry берёт на себя векторный поиск для задач машинного обучения.

Как аналитическая платформа уровня Data Warehouse Cloudberry рассчитан на десятки и сотни терабайт: shared-nothing-архитектура позволяет наращивать кластер по мере роста данных, а утилита gpshrink — уменьшать его, когда пиковая нагрузка спала. BI-отчётность и дашборды работают через стандартный SQL, поэтому инструменты, настроенные на Greenplum или PostgreSQL, подключаются без переделки.

Отдельный пласт — миграция с закрытого Greenplum. Здесь у Cloudberry заметное преимущество перед аналогами: совместимость сохраняется, команда продолжает работать привычными методами, а для переноса данных у проекта есть утилита cbcopy.

Наконец, сценарии ML и ИИ. Расширение pgvector превращает хранилище в векторную базу: эмбеддинги хранятся рядом с бизнес-данными, поиск ближайших соседей (k-NN) работает через обычный SQL, размерность векторов — до 16 тыс. Этого достаточно для рекомендательных систем и RAG-сценариев без отдельной векторной СУБД; advanced-возможности проекта мы подробно разбирали во второй части гида.

Управляемые кластеры Cloudberry в Yandex Cloud

Собрать MPP-кластер своими руками — заметная инженерная работа: спланировать топологию, настроить зеркалирование и резервное копирование, обновлять десятки узлов и следить за их здоровьем. Управляемый сервис забирает эту часть себе, оставляя команде работу с данными.

В Yandex Cloud кластеры на базе Greenplum версии 6 и выше и Apache Cloudberry разворачивает Yandex MPP Analytics Engine for PostgreSQL. Мы берём на себя обслуживание: обновления, резервные копии, мониторинг и восстановление после сбоев. Холодные данные сервис автоматически переносит в объектное хранилище Yandex Object Storage, а визуализировать результаты аналитики можно в Yandex DataLens. За сервисом стоит та же команда, которая контрибьютит в опенсорсный Cloudberry, поэтому новые возможности СУБД появляются в облаке без большого лага.

При выборе платформы стоит смотреть шире списка фич СУБД: значение имеют регулярность управляемых обновлений, гарантии отказоустойчивости, встроенный мониторинг и то, как хранилище стыкуется с остальной инфраструктурой — от ETL-инструментов до BI. Не забудьте и про полную стоимость владения: мы считали её для своей базы и управляемого сервиса на горизонте трёх лет.

Каким будет Cloudberry дальше

Дорожная карта проекта открыта, и по ней видно, куда движется разработка. Ближайшая веха — мажорный релиз 3.x с ядром PostgreSQL 16; дальше сообщество намерено держать отставание от актуальной версии PostgreSQL в пределах двух мажорных релизов.

Развивается Lakehouse-направление: запросы к данным в форматах Apache Iceberg^® и Apache Hudi^™, интеграция Flink CDC для загрузки данных в режиме, близком к реальному времени. По линии ИИ — обновления pgvector и интеграция с Ray. Параллельно проект идёт к выходу из инкубатора: статус top-level подтвердит зрелость процессов сообщества.

Есть и внешний фактор. Уход западных вендоров и закрытие исходного кода привычных продуктов подталкивают компании к вендоронезависимым решениям, и открытая MPP-СУБД под управлением Apache в этом смысле устойчивее вендорской модели: решения здесь принимает сообщество, а не совет директоров.

Частые вопросы про Apache Cloudberry

Что в итоге

История с закрытием Greenplum наглядно показала цену вендорской модели даже для формально открытого проекта. Apache Cloudberry отвечает на неё по существу: тот же MPP-фундамент и совместимость, но современное ядро PostgreSQL, формат PAX, векторизация и управление через сообщество Apache вместо одной корпорации.

Для команд, которые работают с Greenplum, это редкий случай, когда смена СУБД ощущается как обновление версии: приложения переносятся как есть, а производительность и функциональность растут. Начать проще всего с управляемого кластера — Yandex MPP Analytics Engine for PostgreSQL поднимет Greenplum-совместимую инфраструктуру и возьмёт сопровождение на себя, пока команда занимается данными.