WalShadow：从物理WAL亚秒级复制Postgres

今天，我们宣布推出 WalShadow，这是一个开源引擎，可直接从物理 WAL 将 Postgres 数据复制到 ClickHouse。

在我们的基准测试中，在 Postgres 中提交的事务大约 200 毫秒后即可在 ClickHouse 中可见，同时 WalShadow 持续维持每秒 289K 行的吞吐量，实际上与源 Postgres 实例保持同步。

与传统基于 CDC 的系统不同，WalShadow 不使用 Postgres 逻辑复制。它消费 Postgres 副本所使用的同一物理 WAL 流，在源数据库之外对其进行解码，并将 ClickHouse 原生块直接写入 ClickHouse。其结果是一种接近 Postgres 物理备库的延迟和吞吐量的复制架构，同时使数据可立即在 ClickHouse 中用于分析。

WalShadow 支持完整的复制生命周期，包括初始加载、持续复制、模式演进、重启恢复以及计划的源切换。

通过直接消费物理 WAL，WalShadow 消除了对逻辑复制槽的需求，移除了与逻辑复制相关的大量运维开销，并显著降低了源 Postgres 实例上的资源消耗。它还支持复杂的模式变更，例如 ADD COLUMN、RENAME COLUMN、DROP COLUMN 以及 CREATE TABLE。

WalShadow 完全开源，现已在 GitHub 上提供。

将 WalShadow 引入 ClickHouse Managed Postgres

为了提供完全托管的体验，我们还为 ClickHouse Managed Postgres 推出了 WalShadow 的私有预览版。

物理 WAL 是 WalShadow 架构的关键，但大多数托管 Postgres 服务不向客户暴露它，导致无法使用 WalShadow。ClickHouse Managed Postgres 管理堆栈的两端，使我们能够将 WalShadow 直接集成到 Postgres 复制层中，并提供从 Postgres WAL 到 ClickHouse 的原生路径。

架构：从物理 WAL 到 ClickHouse 原生块

WalShadow 采用了一种全新的 Postgres 到 ClickHouse 复制方法，实际上将 ClickHouse 转变为分析型物理备库。

WalShadow 消费 Postgres 为物理复制和恢复所生成的同一 WAL 流。它不要求源数据库将变更解码为逻辑事件，而是在源之外通过四个阶段处理 WAL：

1. 跟踪实时模式。 WalShadow 过滤目录 WAL 记录，并将其重放到一个仅包含模式的影子 Postgres 实例中。随着源模式演进，这会维护一个包含表、列和 Postgres 类型的最新目录。
2. 并行解码数据变更。 堆记录被分发到一个基于 Rust 的解码器池，而不经过影子 Postgres 实例。
3. 构建 ClickHouse 原生块。 批处理器按表将已解码的行分组为完整的 ClickHouse 原生块，在不进行中间格式转换的情况下保持数据保真度。
4. 并行插入。 一个独立的插入器池并发地将多个块写入 ClickHouse，使解码和插入能够独立扩展。

这创建了一条从 Postgres 到 ClickHouse 的直接路径：没有逻辑解码输出插件，没有 Kafka，也没有 JSON 序列化或单独的规范化步骤。

由于 WalShadow 并行处理块，它们可能以乱序到达 ClickHouse。WalShadow 通过将源 WAL 位置（_lsn）附加到每一行来保持正确性，使 ClickHouse 能够为每个键保留最新版本。需要严格排序的操作（例如模式变更和截断）会引入屏障，等待所有先前数据持久化后才应用。

源只需要发送物理 WAL，从而产生类似于物理备库的负载特征，同时允许变更在一秒内到达 ClickHouse。

有关架构的详细概述，请参阅 架构文档。要了解影响性能和功能的各种可用调优设置，请参阅 配置指南。

性能基准测试

我们将 WalShadow 与 PeerDB 进行了基准对比，后者是我们由逻辑复制驱动的最先进的 Postgres 到 ClickHouse CDC 工具，为 ClickPipes 提供支持。

对我来说，这种比较是苦乐参半的。我们为我们创建的 PeerDB 服务于数千名客户而感到自豪。WalShadow 通过直接从物理 WAL 重新构想复制，推动这一旅程向前，使我们更接近统一的 Postgres 和 ClickHouse 堆栈。

该基准测试复制来自单个表的持续变更流，Postgres、ClickHouse 和每个复制工具都在同一区域内运行。我们使用了适中的 c8i.2xlarge 实例，每个实例有 8 个 vCPU。性能会因工作负载而异，但这些结果提供了 WalShadow 所能提供的有用指示。

约 200 毫秒的提交到可见延迟

提交到可见延迟衡量从事务在 Postgres 中提交到其行在 ClickHouse 中可见的时间。原生 Postgres 物理副本建立了约 50 毫秒的实际基线。WalShadow 达到了约 200 毫秒，而 PeerDB 约为 10 秒，在此基准测试中延迟约低 50 倍。

每秒 289,000 行的持续吞吐量

源 Postgres 实例持续维持大约每秒 290,000 行的插入，确立了复制管道可以处理的最大速率。WalShadow 每秒复制 289,000 行，实际上与源匹配，而没有成为瓶颈。PeerDB 持续维持大约每秒 120,000 行，约为源速率的 40%。

这些结果表明，低延迟不必以吞吐量为代价：WalShadow 在接近源全速运行的同时保持数据实时。

结论与愿景

在 ClickHouse，我们采取了几个重大步骤来拉近 Postgres 与 ClickHouse 之间的距离：收购 PeerDB，推出 ClickPipes 中的 Postgres CDC，以及引入 ClickHouse Managed Postgres，这是一项基于本地 NVMe 存储构建的企业级 Postgres 服务，用于快速 OLTP，并与 ClickHouse 原生集成以实现快速 OLAP。

这些努力有着同一个目标：为开发者提供一个统一的数据栈，将用于事务处理的 Postgres 与用于分析的 ClickHouse 结合起来，而不增加复杂性。

WalShadow 是实现这一愿景的重要里程碑。通过将物理 WAL 直接复制为 ClickHouse 原生块，它提供亚秒级分析能力，消除了逻辑复制的大部分运维开销，并支持通过传统逻辑解码管道难以处理的复杂 schema 变更。

在未来几个月内，我们将与客户紧密合作，在真实工作负载中加固 WalShadow。我们已经在与首批设计合作伙伴协作，现在准备扩大访问范围。