Пиксельная схема передачи данных PostgreSQL в S3 с замками доступа

ЛонгридРазработкаБезопасностьДанныеCDC

pg-cdc: перенос логов PostgreSQL WAL в хранилище AWS S3 в формате Iceberg

Инструмент pg-cdc обеспечивает односторонний стриминг логов предзаписи WAL из СУБД PostgreSQL в аналитические таблицы Apache Iceberg на AWS S3. Решение устраняет необходимость выдавать учетные данные базы данных конечным пользователям, обеспечивая разграничение доступа на уровне AWS IAM.

pg-cdc: перенос логов PostgreSQL WAL в хранилище AWS S3 в формате Iceberg

Предоставление аналитическим системам и ИИ-агентам прямого доступа к транзакционной БД создает риски безопасности и производительности. Традиционные read-only реплики снижают нагрузку, но требуют передачи реквизитов СУБД и усложняют аудит прав.

Проект pg-cdc от сообщества Burnside предлагает асинхронный однонаправленный стриминг логов предзаписи (WAL) PostgreSQL в формат Apache Iceberg на AWS S3. Управление доступом к данным полностью переносится на уровень политик AWS IAM и меток AWS Lake Formation, исключая прямые подключения к СУБД.

Почему прямое подключение к базе данных — это риск

Предоставление внешним потребителям прямого доступа к транзакционной базе данных связано со следующими архитектурными и эксплуатационными рисками:

Утечка учетных записей: Каждое новое интеграционное решение или BI-сервис требует создания строки подключения. В случае компрометации одного из клиентов злоумышленник получает доступ к сетевому порту СУБД.
Непредсказуемая нагрузка: Аналитические запросы часто включают тяжелые сканирования таблиц и группировки. Запуск такого запроса на транзакционной базе или ее реплике может привести к исчерпанию ресурсов и деградации производительности основного приложения.
Отсутствие гибкого разграничения доступа: Настройка Row-Level Security (безопасности на уровне строк) и ограничение доступа к конкретным столбцам внутри СУБД — сложный процесс, который трудно синхронизировать с общекорпоративными политиками безопасности.
Отсутствие истории изменений (Time Travel): Аналитическим моделям часто требуется знать, как выглядели данные в определенный момент в прошлом. Реализация этого механизма внутри СУБД требует создания сложных исторических таблиц или триггеров.

pg-cdc устраняет эти проблемы, вынося аналитическую зону за пределы сетевого контура базы данных. Потребители работают с неизменяемыми Parquet-файлами в S3, используя привычные движки запросов (например, Athena, Spark или DuckDB), вообще не имея сетевого доступа к PostgreSQL.

Архитектура pg-cdc: один бинарный файл без JVM

Популярные инструменты класса CDC (например, Debezium) обычно строятся на базе платформы Apache Kafka и требуют развертывания тяжелой инфраструктуры: JVM (Java Virtual Machine), ZooKeeper и кластера Kafka Connect. Это создает значительную эксплуатационную нагрузку на небольшие команды.

pg-cdc спроектирован как легковесный демон на языке Go, распространяемый в виде одного бинарного файла. Ему не нужны дополнительные зависимости или запуск Java-окружения. Утилита подключается к PostgreSQL по стандартному протоколу логической репликации, выступая в роли стандартного подписчика (replica).

Архитектурно решение разделено на несколько слоев:

Слой чтения (Replication Reader): Go-процесс непрерывно считывает поток WAL из слота репликации PostgreSQL.
Слой локального состояния: pg-cdc использует встроенную СУБД SQLite для отслеживания текущего LSN (Log Sequence Number), обработанных транзакций и структуры таблиц.
Слой хранения (Storage Tier): Данные преобразуются в Parquet-файлы и загружаются в бакет AWS S3.
Слой каталога и прав доступа: Каждая таблица регистрируется в каталоге данных AWS Glue Catalog, а права доступа разграничиваются через AWS Lake Formation.

Такое разделение позволяет полностью изолировать транзакционную базу. pg-cdc не внедряется в ядро PostgreSQL как расширение (C extension), не требует добавления библиотек в параметр shared_preload_libraries и не нуждается в перезапуске СУБД для начала работы.

Как WAL превращается в snapshots Apache Iceberg

Процесс переноса изменений состоит из последовательного захвата транзакций и их периодического сброса (flush) на S3 в формате Apache Iceberg. Этот процесс разбит на эпохи:

Захват изменений: pg-cdc читает лог WAL и накапливает изменения (вставки, обновления, удаления) в виде небольших дельт (delta files) в Parquet-формате.
Создание снимка (Snapshot): При достижении лимита по времени (flush.interval_sec) или количеству строк (flush.max_rows), накопленные изменения записываются на S3, и в каталоге Apache Iceberg создается новый снимок таблицы.
Компакция (Compaction): Поскольку частая запись мелких файлов снижает производительность чтения, фоновый процесс compact периодически объединяет мелкие дельты в крупные базовые Parquet-файлы, применяя операции удаления (с поддержкой tombstone TTL для мягкого удаления записей).

Благодаря структуре Apache Iceberg, система поддерживает механизм Time Travel (путешествие во времени). Каждый сброс дельт фиксируется как новая версия состояния данных. Аналитики могут выполнять исторические запросы вида SELECT * FROM table FOR SYSTEM_TIME AS OF <timestamp>, обращаясь к иммутабельным тегам raw@<ts>, без необходимости создавать физические копии или ветвления базы данных.

Управление доступом на уровне AWS Lake Formation

Одним из ключевых преимуществ pg-cdc является перенос безопасности на уровень облачной инфраструктуры. Вместо логинов и паролей базы данных потребители используют аутентификацию через AWS IAM (Identity and Access Management).

Для тонкой настройки прав используется AWS Lake Formation. Платформа регистрирует таблицы в AWS Glue Catalog и навешивает на них мета-теги Lake Formation. Это позволяет:

Скрыть неразмеченные данные: По умолчанию в режиме строгой безопасности (strict governance) любые данные без явных тегов доступа невидимы для пользователей.
Настроить доступ до уровня столбца: Можно разрешить аналитической группе видеть таблицу клиентов, но запретить доступ к столбцам с персональными данными (например, телефонами или хэшами паролей).
Исключить запись: Поскольку поток данных является строго односторонним, потребители физически не могут выполнить команду UPDATE или DELETE в отношении исходной базы данных PostgreSQL — у них просто нет интерфейса для записи.

Командный интерфейс и жизненный цикл пайплайна

Управление pg-cdc осуществляется через CLI-интерфейс, который поддерживает полный жизненный цикл репликации:

pg-cdc preflight: Выполняет предварительную проверку базы данных PostgreSQL на готовность к логической репликации (проверяет уровень wal_level, наличие прав суперпользователя или роли репликации у учетной записи).
pg-cdc init: Создает начальный снимок выбранных таблиц, загружает базовые Parquet-файлы на S3, создает метаданные в AWS Glue и настраивает политики доступа в Lake Formation.
pg-cdc start: Запускает фонового демона репликации, который начинает слушать слот репликации PostgreSQL и стримить изменения.
pg-cdc status: Отображает текущее состояние пайплайна: активный слот, отставание репликации (lag), текущий LSN, количество обработанных эпох и транзакций.
pg-cdc compact: Запускает слияние накопленных мелких Parquet-файлов в оптимальные блоки для ускорения последующего чтения движками запросов.
pg-cdc reconcile: Синхронизирует схему данных в AWS Glue после выполнения команд ALTER TABLE на источнике в PostgreSQL, предотвращая сбои при изменении структуры таблиц.
pg-cdc serve --http: Запускает REST API (по умолчанию на 127.0.0.1:8080) для мониторинга, отдачи метрик в формате Prometheus (/metrics) и проверки работоспособности (/healthz). При доступе из внешних сетей эндпоинт защищается Bearer-токеном.
pg-cdc teardown: Безопасно завершает репликацию, удаляет слот репликации и публикацию в PostgreSQL, а также очищает локальное состояние SQLite.

Ограничения, риски и особенности эксплуатации

При планировании внедрения pg-cdc необходимо учитывать ограничения и риски, свойственные ранним стадиям развития проектов:

Ранняя стадия проекта: Проект является очень молодым (буквально единицы звезд на GitHub) и представляет собой инициативу сообщества Burnside Project. Его использование в production-окружении требует обязательного предварительного тестирования на тестовых стендах.
Привязка к облаку AWS: Основные преимущества платформы (интеграция с Glue Catalog, Lake Formation, авторизация через IAM) работают только в облаке Amazon Web Services. При использовании других облачных провайдеров или on-premise инфраструктур ценность инструмента снижается.
Риск переполнения диска WAL: pg-cdc удерживает слот логической репликации PostgreSQL. Если демон pg-cdc будет остановлен или зависнет, PostgreSQL перестанет удалять сегменты WAL, что может привести к быстрому переполнению диска СУБД. В конфигурации pg-cdc необходимо обязательно настраивать лимит max_retained_wal_bytes (например, ограничить его 10 ГБ) для предотвращения аварийных ситуаций.
Мониторинг отставания: Администраторам инфраструктуры необходимо непрерывно отслеживать метрики отставания репликации (slot lag) через эндпоинт /metrics, чтобы своевременно реагировать на сетевые сбои или замедление записи на S3.