优化 Postgres 复制Postgres 是出色的操作型数据库但其变更数据捕获Change Data CaptureCDC功能仍有很大提升空间。许多数据管道最终变得脆弱不堪因为复制工具需要处理连续数据与模式变更、快照和故障之间的复杂交互。为给 Snowflake Postgres 用户提供可靠、开箱即用的体验必须彻底重新设计 Postgres 复制机制。数据镜像是 Snowflake Postgres 的新功能目前处于公开预览阶段它可以以低成本、低延迟和事务一致性的方式将数据高度可靠地复制到 Snowflake 中。其原理是将变更直接从 Postgres 以事务批次的形式推送到 Apache Iceberg™ 表中这些批次会自动以事务和无服务器的方式应用到 Snowflake 的表中。这种“将事务性数据推送到数据湖在 Snowflake 中进行事务性应用无需额外基础设施”的简单方式将复制从一个充满复杂故障情况的混乱过程变成了一个可以永远稳定运行的精准机制。只需按下一个按钮就能将 Postgres 表复制到 Snowflake 中。从拉取到推送将变更数据捕获引入 Postgres变更数据捕获是指从事务性数据库中捕获变更并以可在其他系统上重放的形式进行处理的过程。在 Postgres 中主要使用的是“[逻辑解码](https://www.postgresql.org/docs/current/logicaldecoding.html)”功能即将 [WAL](https://www.crunchydata.com/blog/postgres-wal-files-and-sequuence-numbers) 记录解码为逻辑行级别的插入、更新和删除操作这些操作会通过网络以流的形式暴露出来之后的处理就由客户端负责。实际上复制涉及更多步骤比如回填数据、处理模式变更、创建/添加/删除/丢弃表操作、新表快照、故障恢复、高效合并变更、保留事务边界、调整大小等。即使是 Postgres 内置的逻辑复制也只能处理其中的部分方面。逻辑解码方法存在一个问题即消费变更的外部系统对 Postgres 的状态一无所知。例如它不知道何时发生模式变更、表快照如何与变更对齐甚至不知道 Postgres 是否正常运行还是网络出现了故障。解决这个问题的方法很简单将变更从 Postgres 推送到数据湖在案例中是推送到 Iceberg 表使用压缩的 Parquet 格式。像 Amazon S3 这样的对象存储具有高度可扩展性和可靠性并且经常用于 Postgres 备份也是变更数据捕获的理想目标。镜像功能使用了名为 snowflake_cdc 的新 Postgres 扩展它会在后台持续将变更批次推送到每个表的变更日志和一个“元日志”中使用“[基础工作进程](https://github.com/Snowflake-Labs/pg_lake/tree/main/pg_extension_base#base-workers-extension-lifecycle-background-workers)”。使用扩展的好处是它能准确了解 Postgres 内部的情况可以精心协调模式变更以及复杂的数据操作语言DML和数据定义语言DDL事务。它可以在推送变更的同时进行快照并使快照与变更对齐。基于推送的变更数据捕获避免了一系列基础设施相关的问题并通过对象存储有效地解耦了生产者和消费者。理清复制时间线在构建像数据镜像这样的复制系统时数据库的时间线是重要方面。复制过程处理的是数据库过去的状态。每次向 Postgres 写入数据实际上要经过四个阶段每个阶段都代表着在同一时间线上的连续处理过程但处于不同的时间点写入写入操作会修改表并添加到 WAL 中即“当前”操作。解码将过去的 WAL 记录转换为行级别的变更。捕获将过去的行级变更分批捕获。应用将过去的变更批次合并到目标表中。解码过程依赖于 Postgres 中的一个特殊功能即读取写入时的目录表“历史快照”。这样即使在解码时表已经被更改或删除二进制 WAL 记录也能被理解为逻辑行变更。在数据镜像的情况下这些记录会被写入临时文件。解码器会定期收到信号要求完成当前批次并向捕获进程发送消息表示一个批次已准备好。捕获进程会将最终文件追加到 Iceberg 变更日志中在元日志中写入一条记录并跟踪复制的日志序列号LSN。模式变更也遵循相同的写入 → 解码 → 捕获路径并可能导致生成新的变更日志。新的元日志和变更日志记录会出现在 Iceberg 表中。Snowflake 中的应用进程会作为一个有限状态机执行元日志中的所有指令。当操作是变更批次时常见情况会为每个表一起处理所有相邻的变更批次。这种方法有助于确保模式变更能正确地按顺序融入变更流即使它们是作为执行了额外写入操作的事务的一部分发生的。如果发生意外故障导致 WAL 丢失Postgres 可以自动推送新的快照并指示 Snowflake 进行消费。由于使用了 [故障转移插槽](https://www.postgresql.org/docs/current/logical-replication-failover.html)这种情况在实际中很少发生。事务作为分布式系统的构建块数据库系统可以通过一个简单的原语——事务隐藏与系统和硬件故障相关的大量复杂性。如果一个事务因底层系统故障而失败那么不会有任何影响只需再次尝试。如果事务成功就能确保不会再次执行相同的操作。当处理提取、转换、加载ETL或 CDC 等过程时会感到沮丧因为此时事务机制失效不得不自己处理各种不同的故障模式。针对这个问题的第一个解决方案是适用于数据湖的 Postgres这是 [开源的 pg_lake 扩展](https://github.com/Snowflake-Labs/pg_lake) 的托管版本目前已全面可用。它使 Postgres 能够在 Postgres 表和 Iceberg 表之间执行事务。ETL 通常需要外部工具用户需要设计幂等性并进行仔细的记录管理。现在只需使用 SQL 从 Postgres 表中删除数据、插入到 Iceberg 表中并提交即可。此时这些数据就可以在 Snowflake 中进行查询。这种方法非常灵活但 SQL 并不适合高频更新的端到端复制而数据镜像功能则弥补了这一不足。实际上数据镜像充分利用了 pg_lake 和 Snowflake 的 Iceberg 实现。它会在一个 Postgres 端的事务中将 Postgres 表中的数据和模式变更批次推送到 Iceberg 中的多个变更日志中。然后Snowflake 会在一个 Snowflake 端的事务中一次性合并多个批次。这意味着所有 Snowflake 表会在一个事务中向前推进精确到 Postgres 事务边界同时保留外键和连接的正确性。这种事务性复制方法可以扩展到非常高的吞吐量并避免了传统跨系统复制中常见的大多数故障和竞争条件。高性能应用和实时视图事务还能实现另一个重要功能大规模数据的一致性。常见的复制方法是将每个操作转换为一种更新插入upsert操作。这样做的原因是很难解决表快照和变更之间的一致性问题以及故障后变更可能会多次重放的问题。然而更新插入方法存在几个问题目标表可能会出现不一致的中间状态特别是在添加表时。插入操作的复制成本变得非常高因为需要与目标表中的现有行进行匹配而在列式存储中这一操作成本很高。很难或无法有效地将近期变更与目标表合并。当将复制过程变为由 Postgres 控制的事务性过程时就不会受到这些限制。可以创建一个完美的删除和插入流这些操作只会执行一次不会出现插入操作已经出现在快照或其他变更批次中的风险。这意味着对于插入密集型工作负载通常是最大的表复制速度极快且成本效益高因为插入操作是追加的而不是更新插入的。近期变更可以与现有数据高效合并。这就引出了实时视图的概念。实时视图是数据镜像的一项功能它将每个表变更日志中未应用的变更与目标表中的数据相结合。重要的是查询中的任何过滤和投影操作都可以直接下推到存储层并对变更日志中的 Parquet 文件和基表进行表扫描。换句话说实时视图的查询速度很快。有了实时视图就不需要频繁应用变更来实现低延迟。即使应用变更的频率较低实时视图的延迟仍能控制在一分钟以内并且查询性能依然很高只是会有轻微的额外开销。像时钟一样精准的复制基于推送的 CDC、精心设计的时间线、两端的事务边界和实时视图这些因素相结合使镜像功能将复制从一个混乱的过程变成了一个精准的机制。没有会落后的外部连接器没有会与变更冲突的快照也没有随着表增长而变慢的更新插入操作。只有一个 Postgres 扩展将变更批次推送到对象存储Snowflake 进行应用两者都是事务性的、独立的并且可以无限期运行。只需设置一次它就能永远运行下去。Snowflake Postgres 的数据镜像功能过去操作型和分析型工作负载处于不同的环境中它们通过脆弱的管道和额外的系统连接在一起不仅增加了成本还带来了很多麻烦。目标是通过简单而精心设计的解决方案为双方奠定坚实的基础将这两个环境统一起来。有了 Snowflake Postgres可以使用值得信赖的生产级 Postgres现在还有两种方式可以灵活地统一工作负载数据镜像公开预览版提供了从 Postgres 到 Snowflake 的持续自动复制功能。只需设置一次表包括模式变更就会持续保持同步。适用于数据湖的 Postgres现已全面可用它允许使用 Iceberg 等开放格式在 Postgres 和 Snowflake 之间灵活地进行由开发者控制的数据移动。只需编写 SQL数据就会按照需求进行移动。开始使用 Snowflake Postgres如果准备开始使用可以查看以下链接设置数据镜像了解更多关于数据镜像的信息