Snowflake переработала CDC-репликацию Postgres: push вместо pull через Iceberg

Snowflake опубликовала инженерный разбор того, как она перестроила захват изменений (CDC, change data capture) из Postgres для своей аналитической платформы. Речь о новой функции «зеркалирование данных» (data mirroring) для сервиса Snowflake Postgres, сейчас она в открытом бета-тесте (public preview).

Классический CDC в Postgres построен на «вытягивании» (pull): база отдаёт поток логического декодирования (logical decoding), WAL превращается в построчные изменения, а вся остальная работа ложится на внешний клиент: бэкфилл, обработка изменений схемы, повторные снапшоты, восстановление после сбоев, сохранение границ транзакций. При этом внешняя система ничего не знает о состоянии Postgres, не видит, изменилась ли схема, синхронизированы ли снапшоты с изменениями, жив ли вообще Postgres или просто упала сеть.

Snowflake развернула поток в обратную сторону. Новое расширение Postgres snowflake_cdc само в фоне толкает пакеты изменений в таблицы Apache Iceberg (формат Parquet) через «базовых воркеров» (base workers), по одному журналу изменений на таблицу плюс общий «мета-журнал». Поскольку расширение работает внутри Postgres, оно точно знает, что происходит с базой, и может согласованно обрабатывать изменения схемы и DDL/DML-транзакции, а также аккуратно совмещать снапшоты с потоком изменений.

Каждая запись в Postgres проходит четыре стадии одного конвейера: запись (write) в журнал упреждающей записи (WAL), декодирование (decode) WAL в построчные изменения, захват (capture) изменений в пакеты и применение (apply) пакетов в целевых таблицах Snowflake. На стороне Snowflake применение работает как конечный автомат (state machine) поверх мета-журнала в Iceberg, это гарантирует, что изменения схемы попадут в поток строго в правильном порядке, даже если они были частью транзакции с другими записями. Если WAL неожиданно потерян из-за сбоя, Postgres автоматически делает новый снапшот и сообщает об этом Snowflake, по словам компании, благодаря failover-слотам на практике это происходит очень редко.

Вместо типичного для CDC-систем подхода через upsert, он дорог для колоночного хранилища и может создавать промежуточные несогласованные состояния, Snowflake применяет вставки и удаления ровно один раз, потоком, без повторного сопоставления с уже существующими строками. По словам компании, это делает репликацию таблиц с интенсивной вставкой (обычно самых больших) особенно быстрой и дешёвой.

Отдельная возможность, live views: они «на лету» объединяют ещё не применённые изменения из журнала с данными в целевой таблице, проталкивая фильтры и проекции прямо в слой хранения и сканы Parquet-файлов. Благодаря этому задержка (лаг) между Postgres и Snowflake остаётся заметно меньше минуты, даже если пакеты применяются редко.

Параллельно с data mirroring в статус общедоступности (generally available) перешла фича «Postgres for your data lake», управляемая версия открытого расширения pg_lake. Она даёт выполнять транзакции сразу между таблицами Postgres и Iceberg прямо на SQL: удалить строку из таблицы Postgres, вставить её в таблицу Iceberg и закоммитить одной транзакцией, без внешних ETL-инструментов и ручной идемпотентности.

Ключевые факты

Snowflake выпустила data mirroring (открытый бета-тест, public preview), расширение snowflake_cdc толкает пакеты изменений из Postgres прямо в таблицы Apache Iceberg, а Snowflake применяет их транзакционно
Каждая запись в Postgres проходит четыре стадии конвейера: запись, декодирование, захват (capture) и применение (apply), синхронизированные по границам транзакций
Вместо upsert используется поток вставок и удалений, применяемых ровно один раз, это ускоряет и удешевляет репликацию таблиц с интенсивной вставкой
Live views объединяют неприменённые изменения из журнала с базовой таблицей на лету: лаг остаётся заметно меньше минуты даже при редком применении пакетов
Одновременно в статус GA (общедоступно) перешла «Postgres for your data lake», управляемая версия открытого pg_lake для SQL-транзакций между Postgres и Iceberg

Почему это важно

Классический CDC в Postgres построен на «вытягивании»: клиент сам разбирает поток логического декодирования и берёт на себя бэкфилл, изменения схемы, перезапуск после сбоев и согласование снапшотов с потоком изменений, а внешняя система даже не знает, жив ли Postgres. Snowflake перевернула схему на push: расширение внутри Postgres само толкает готовые транзакционные пакеты в объектное хранилище (Iceberg), развязывая производителя и потребителя данных через хранилище и убирая целый класс инфраструктурных отказов. Это превращает репликацию из хрупкого процесса с множеством точек отказа в предсказуемый механизм, который, по описанию компании, «настраиваешь один раз, и он работает всегда».

Кому это важно

Инженерам и дата-командам, которые держат Postgres как транзакционную базу, а аналитику ведут отдельно, классическая связка OLTP и OLAP. В первую очередь это касается пользователей сервиса Snowflake Postgres: для них зеркалирование данных работает «из коробки», вместе со схемой, без ручной настройки внешних конвейеров репликации. Также это релевантно командам, которые раньше вручную боролись с идемпотентностью и сложным учётом состояния в ETL-процессах, именно эту боль решает связка pg_lake и data mirroring.

Как это применить

Data mirroring сейчас в открытом бета-тесте (public preview): включается для таблиц Snowflake Postgres и дальше работает автоматически, вместе со схемой, без дополнительной настройки внешних инструментов. Рядом в статусе GA доступна «Postgres for your data lake», управляемая версия pg_lake: она даёт делать транзакции прямо через SQL между таблицами Postgres и Iceberg, когда нужен ручной, а не постоянный перенос данных. Для чтения без ожидания применения пакетов есть live views, запрос сразу видит и применённые данные, и ещё не влитые изменения, с задержкой заметно меньше минуты. Источник не называет ни цену, ни конкретные лимиты, только то, что это встроенные функции сервиса Snowflake Postgres.

Можно ли доверять

Это первичный источник, инженерный блог самой Snowflake, а не независимый разбор: компания описывает собственную архитектуру и подаёт её сильные стороны. Технические детали, устройство WAL-декодирования, четыре стадии конвейера, механика live views, изложены конкретно и проверяемо, но количественных бенчмарков в тексте почти нет: единственная цифра производительности, «задержка заметно меньше минуты», без чисел по пропускной способности или стоимости. Автор поста в тексте не назван. Материал вызвал живое обсуждение на Hacker News (115 баллов, 23 комментария), но это не независимая верификация заявленных характеристик.

Риски и подводные камни

Технология привязывает пользователя к экосистеме Snowflake: Postgres-сервис, Iceberg-репликация и pg_lake, части одной платформы, и миграция с них потребует отдельного инженерного проекта. Data mirroring, public preview, то есть ещё не финальный статус: поведение и гарантии могут измениться до общей доступности. В посте нет ни имени автора, ни независимых замеров производительности, оценивать заявленные «низкую стоимость» и «низкий лаг» можно пока только на слово компании.

«Зеркалирование данных, новая функция Snowflake Postgres в открытом бета-тесте (public preview) для устойчивой репликации данных в Snowflake с низкой стоимостью, малой задержкой и транзакционной согласованностью.»

— блог Snowflake Engineering