ClickHouse 在 9 月 10 日发了 WalShadow：从 Postgres 物理 WAL 解码，直接写出 ClickHouse native block，而不是走经典 logical decoding CDC。官宣数字很刺眼——提交后约 200ms 量级可见，基准里能顶到约 29 万行/秒，并声称跟得上源库节奏。完整生命周期也谈到了：初始全量、持续复制、schema 变更、重启恢复、计划内主库切换。
对后端来说，这不是又一个「Postgres 能同步到分析库」的新闻，而是复制链路的取数位置变了。
物理 WAL 和 logical CDC 差在哪
多数 Postgres → OLAP 管道吃的是 logical replication：publication、decoding plugin、slot、中间件把 insert/update/delete 变成消息。好处是语义清晰、过滤表方便；坏处也熟悉——slot 堆积、大事务、DDL 脾气、源库 CPU 被 decoding 咬一口。
WalShadow 吃的是和物理备库同一类 WAL 流，在源外解码，再写成 ClickHouse 侧块。叙事是：延迟和吞吐往物理 standby 靠，数据却立刻能在 ClickHouse 里分析。
这意味着你要换一套心智：
- 依赖的是 WAL 保留与读取路径，不只是
wal_level=logical和 slot - 表过滤、类型映射、主键/替换合并策略仍在目标侧设计，但源侧「逻辑变更流」不再是唯一真相
- 和现有 Debezium / PeerDB / 云厂商 CDC 的运维手册不能整本复印
ClickHouse Managed Postgres 方向也在叠同一故事：托管 PG + 低延迟进 CH。自建的人则要自己扛 WAL 运输和解码器版本。
图：机柜近景——理线与状态灯的特写，和通道全景封面区分开。
什么负载真的该动心
值得认真看的：
- 交易库已经在扛 logical slot 延迟或 decoding CPU
- 分析要「刚写完就能查」，分钟级滞后不够
- 你本来就维护物理备库或 WAL 归档，再多一个消费者的边际成本可控
- 主路径是 append-heavy 或可接受 ReplacingMergeTree 语义的宽表
先别跟风的：
- 只要几张表、日更报表，现有 logical CDC 稳得像老黄牛
- 重度依赖 logical 特有中间件生态（复杂变换、多下游扇出已建成）
- 合规要求「复制必须可解释为行级逻辑变更审计」，而物理解码链路的审计表述还没写进你们的模板
- 源库小版本/扩展组合怪异，解码器支持矩阵未验证
换复制引擎的成本，往往高于换一个连接串。
设计时我会盯的五件事
-
RPO/RTO 与可见性
200ms 是基准叙事，不是你的 SLO。量的是：源提交时间戳 → CH 可查时间；以及故障时重放进度。把「分析可见」和「备库可 failover」分开写。 -
DDL
官宣支持 ADD/RENAME/DROP COLUMN、CREATE TABLE 等。预发用你们真实迁移工具打一遍：锁、长 DDL、在线改表工具是否会让解码器愣住。 -
初始全量
存量拷贝窗口、一致性点、切连续复制的缝。大库最怕「全量末尾 + 增量开头」重复或空洞。 -
下游表引擎
当前态用 ReplacingMergeTree +__current视图一类模式，还是 append-only 事件表，决定查询怎么写。别假设 CH 里天然等于 PG 行快照。 -
源库压力
物理 WAL 消费声称更轻，仍要在高峰看 IO、WAL 盘、网络。复制从来不是免费的读者。
和「湖上建索引 / BM25 回主库」怎么摆
向量检索外置、关键词回 PG、OLAP 外溢——今年后端一直在拆「一个库扛所有查询」。WalShadow 是 OLTP → OLAP 这一跳的加速器。它不取消你对主键、事务、权限模型的责任；它只是让分析副本更接近「刚发生的事实」。
若团队已经在聊 HTAP，先画查询清单：哪些必须见最新提交，哪些可以 5 分钟。只有前者才配为 WalShadow 付运维复杂度。
小结
WalShadow 把 Postgres 到 ClickHouse 的管道从「逻辑变更流」推近「物理 WAL 旁路解码」。延迟叙事漂亮，但后端落地仍是老问题：DDL、全量缝、表引擎语义、SLO 和源库成本。
先在预发用真实 schema 变更和高峰流量打穿，再谈换掉稳妥的 logical CDC。复制链路没有情绪价值，只有故障时你能不能说清楚数据在哪一秒。
