Как я перенес Greenplum в расширение для PostgreSQL 19 с помощью LLM

Занимаясь аналитическими хранилищами данных с 2017 года, я перенес Apache Cloudberry — самую свежую open source версию Greenplum — в виде набора расширений поверх актуальной версии PostgreSQL 19. До этого экосистема Greenplum неизменно отставала от релизов базового постгреса на несколько мажорных версий из-за колоссального объема правок в монолитном форке.

Мною была поставлена задача: заставить сложный массивно-параллельный движок работать поверх ванильной СУБД, не ломая ее стандартное поведение и совместимость при отключенных модулях. Используя агентов Claude Code в параллельных git worktree под моим архитектурным контролем, мне удалось реализовать этот амбициозный проект всего за 12 дней и 629 коммитов.

Почему расширение

Исторически сложилось так, что Greenplum всегда сильно отставал от актуальных релизов PostgreSQL. Например, Greenplum 6 основывался на старой ветке 9.4, седьмая версия перешла на PG 12, а актуализировать Apache Cloudberry до версии 16.9 разработчикам удалось только весной 2026 года. Причиной тому служит монолитный подход: репозиторий проекта содержал сотни тысяч измененных строк исходного кода и тяжелый оптимизатор ORCA, из-за чего процесс слияния новых версий постгреса превращался в многомесячную головную боль.

Вместо того чтобы вливать исходники базы данных в Greenplum, я пошел от обратного — спроектировал архитектуру, где Cloudberry работает как набор расширений поверх чистой СУБД. При этом ядро базы данных с моими патчами сохраняет абсолютную побайтовую ванильность и идентичную производительность, если модули расширения не активированы. Такой подход позволяет безболезненно переходить на свежие версии постгреса, адаптируя лишь небольшие патчи общим объемом около 1,5 тысяч строк.

Преимущества для существующих и новых пользователей

Для действующих пользователей Greenplum и Cloudberry такое решение открывает массу преимуществ. Во-первых, появляется доступ к современному PostgreSQL со всеми его фишками: от синтаксиса MERGE и SQL/JSON до асинхронного ввода-вывода и параллельного автовакуума. Во-вторых, отпадает необходимость использовать устаревшие форки сторонних расширений — на узлах кластера отлично запускаются актуальные апстримные сборки PostGIS 3.7 и pgvector 0.8.8, поскольку ABI ядра остается неизменным.

Новичкам в мире распределенных вычислений расширение дает возможность развернуть полноценный MPP-кластер, не меняя привычный стек драйверов, BI-инструментов и экосистему PostgreSQL. Даже в одноузловом режиме после загрузки модулей становятся доступны инкрементальные материализованные представления, табличные пространства append-optimized, колоночное хранилище PAX и мощный стоимостной планировщик ORCA.

Cloudberry как совместимое с PostgreSQL MPP хранилище данных

Распределенный оптимизатор строит единый план запроса, который передается на узлы в бинарном виде и исполняется на всех сегментах параллельно. Перемещение данных между хостами обеспечивается механизмом Motion, при этом строго соблюдаются ACID-транзакции в масштабах всего кластера. Типичным сценарием использования остаются крупные хранилища данных на десятки и сотни терабайт, схемы «звезда» и «снежинка», а также выполнение тяжелых ELT-процессов прямо на SQL и PL/pgSQL.

Если сопоставлять мое решение с другими актуальными расширениями для постгреса, то порт Cloudberry выделяется возможностью выполнять сложные комплексные запросы по огромным таблицам как единый конвейерный план с общим распределенным снимком. В отличие от систем вроде Citus или pg_duckdb, здесь полностью сохраняется поддержка пространственных типов PostGIS и векторов pgvector непосредственно в колоночных таблицах с возможностью проведения операций UPDATE и MERGE.

Правила разработки

Весь процесс кодирования строился на строгом своде правил, который я сформулировал для ИИ-агентов. В первую очередь задействовались штатные точки расширения PostgreSQL: хуки, табличные методы доступа, CustomScan, менеджер ресурсов WAL, фоновые процессы, метки безопасности и FDW. Если стандартных средств не хватало, создавались минимальные собственные хуки в виде указателей на функции, равных по умолчанию NULL, без изменения сигнатур базовых структур.

Код самого Cloudberry не подвергался прямым правкам — весь порт изолирован в отдельном каталоге, а ванильность ядра постоянно проверялась через автоматизированные тесты и утилиту abidiff. Первый же тест нового хука combo-CID наглядно продемонстрировал важность таких проверок, мгновенно уронив тестовый сервер.

Там где существующих хуков не хватало, пришлось добавить 22 новых

Для полноценной работы распределенной СУБД стандартных точек интеграции оказалось недостаточно. Чтобы кластер разделял единые OID, транзакции и снимки, в ядро PostgreSQL было внедрено 22 патча. Среди них — хук выделения OID, механизмы адаптации транзакций для параллельных читателей и писателей, а также специализированные обработчики табличных блокировок и парсера синтаксиса.

Пять предварительных патчей в ходе рефакторинга удалось успешно перенести в обычные модули, а четыре новых хука получились настолько универсальными, что их можно смело предлагать в апстрим самого PostgreSQL. Системные метаданные при этом были аккуратно перенесены в стандартные метки безопасности СУБД.

Архитектура

Внешне архитектура полностью повторяет классический Greenplum: координатор хранит каталог и строит планы запросов, а сегменты представляют собой полноценные экземпляры PostgreSQL 19 со своими порциями данных. Разбор специфического синтаксиса реализован без изменения грамматики ядра — специальный модуль разбивает операторы токенами и приводит их к стандартному виду, сохраняя позицию в тексте запроса при ошибках.

Оптимизатор ORCA компилируется без единой модификации и связывается с ядром через специальный транслятор DXL-планов. Связь между узлами и диспетчером запросов увязана через стандартный клиентский протокол libpg, передающий фрагменты планов внутри служебных вызовов, а распределенные снимки и межсегментный обмен строками через механизмы Motion завершают общую картину масштабируемого кластера.

Компоненты

Функциональность расширения разбита на логические модули. Ядро `gp_core` отвечает за управление кластером, диспетчер, интерконнект Motion, двухфазную фиксацию и распределенные снимки. Модуль `gp_orca` интегрирует оптимизатор и транслятор запросов, а `gp_sql` управляет синтаксическими преобразованиями и служебными тегами.

Для работы с хранилищами предусмотрены отдельные компоненты: `gp_ao` и `pax` реализуют колоночные таблицы append-optimized со сжатием, в то время как набор модулей вроде `pxf_fdw` и `datalake_fdw` заведует внешними источниками данных и интеграцией с озерами данных. За административные задачи, квоты, группы ресурсов и отказоустойчивость отвечают специализированные управляющие службы.

Особенности реализации

Наследуя стандарты PostgreSQL 19, параметры конфигурации расширения используют обязательную точку в названиях (например, `gp.*`), а теги команд жестко зафиксированы. Из-за архитектурных ограничений базового движка курсоры с постраничной выборкой не выполняются параллельно, а уровень изоляции SERIALIZABLE на кластере функционирует в режиме REPEATABLE READ, аналогично классическому Greenplum.

На коротких запросах планирование через тяжеловесную ORCA обходится дороже стандартного планировщика, поэтому простые операции выполняются по альтернативным маршрутам. Кроме того, координатор остается единственной точкой входа для всех запросов, а добавление новых физических узлов в кластер требует неизбежного перераспределения пользовательских данных.

Процесс разработки

Разработка велась итеративно: на первом этапе исследовательские агенты проанализировали исходный код Cloudberry, после чего кодинг был разбит на четкие вехи от создания базового каркаса до отладки кластерных транзакций, зеркалирования и внешних таблиц. Каждый этап сопровождался интенсивными параллельными прогонами регрессионных тестов в контейнерах Docker.

Не обошлось и без курьезных технических сюрпризов: на старте одноузловой режим из-за особенностей деления на ноль в отладочных сборках рапортовал о нуле сегментов, а слишком агрессивный параллельный запуск тестов исчерпал всю оперативную память, из-за чего системный OOM killer периодически завершал сеанс моего графического рабочего стола в Linux.

В результате

Проведенный эксперимент доказал принципиальную возможность реализации сложной массивно-параллельной СУБД в виде расширения для современной версии PostgreSQL. Почти весь функционал Cloudberry успешно портирован, сторонние расширения вроде PostGIS и pgvector продолжают работать без сбоев, а архитектурный подход, построенный на строгом инженерном контроле и автоматизации с помощью LLM, позволил преодолеть многолетнее отставание проекта от актуальных апстримных релизов базы данных.