我们如何将 CDC 推入 Postgres

将事务数据库中的数据提供给分析数据库是任何现代数据架构的重要组成部分。这也是一场与脆弱工具、高成本和复杂操作的持久战。当我们开始在 Snowflake 构建 Postgres 服务时，解决这个问题自然成为我们的首要任务。这篇文章深入探讨了数据镜像背后的工程：我们如何从头开始重新构想 Postgres 复制。优化 Postgres 复制 Postgres 是一个令人惊叹的操作数据库，但它的变更数据捕获 (CDC) 故事仍然有很多不足之处。许多管道最终变得脆弱，因为复制工具需要处理连续数据和模式更改、快照和故障之间复杂的相互作用。为了为 Snowflake Postgres 构建可靠、开箱即用的体验，我们必须从头开始重新发明 Postgres 复制。数据镜像是公共预览版中的一项新的 Snowflake Postgres 功能，可以以低成本、低延迟和事务一致性的方式将高弹性数据复制到 Snowflake 中。在幕后，它的工作原理是通过事务批处理将更改直接从 Postgres 推送到 Apache Iceberg™ 表中。这些批次会自动应用于 Snowflake 中的表——以事务方式且无服务器方式。 “事务性推入数据湖，事务性应用在 Snowflake 中，无需额外的基础设施”的简单性将复制从具有许多复杂故障条件的混乱过程转变为将永远运行的简单发条装置。你按下一个按钮，你的 Postgres 表就会出现在 Snowflake 中。从拉到推：将变更数据捕获移至 Postgres 变更数据捕获是从事务数据库捕获变更的过程，其形式允许它们在另一个系统上重放。在 Postgres 中，可用的主要工具称为“逻辑解码”，它指的是将 WAL 记录解码为逻辑行级插入/更新/删除操作。这些操作在网络上以流的形式公开。从那时起，负担就落在了客户身上。实际上，复制涉及更多步骤。回填、模式更改、处理创建/添加/删除/删除表操作、新表快照、失败时重新启动、有效合并更改、保留事务边界、调整大小等。即使是 Postgres 中内置的逻辑复制也只能处理其中的几个方面。逻辑解码方法的问题之一是使用更改的外部系统对 Postgres 的状态一无所知。例如，它不知道架构何时发生更改、表快照如何与更改保持一致，或者 Postgres 是否还活着，或者网络是否已关闭。这个问题的解决方案非常简单：将 Postgres 中的更改推送到数据湖中，在我们的例子中推送到 Iceberg 表中（使用压缩的 Parquet）。 Amazon S3 等对象存储具有高度可扩展性和可靠性，并且一直用于 Postgres 备份。它也是变更数据捕获的正确目的地。镜像使用一个名为 Snowflake_cdc 的新 Postgres 扩展，它不断地将批量更改推送到每个表的更改日志和后台的“元日志”中（使用“基础工作人员”）。使用扩展的好处是它确切地知道 Postgres 中发生了什么。它可以仔细协调架构更改以及复杂的数据操作语言 (DML) 和数据定义语言 (DDL) 事务。它可以拍摄快照，同时推送更改并使快照与更改保持一致。