北京
同样是跑分析查询，为什么你的Postgres主库一跑`GROUP BY`就喘不上气，而同事的看板却能在几亿行数据上亚秒级刷新？答案不只在查询引擎，更在数据搬运的管道上。我们选择ClickHouse做列式存储加速，但真正棘手的是如何让在线事务库与列存分析库保持准实时同步——这恰是变更数据捕获要解的题。
原理其实很“物理”：Postgres为了崩溃恢复，会把每一次增、删、改写入预写日志。CDC通过逻辑复制槽读取这份日志，把它转成有序的事件流，然后重放进另一个系统。相比用`WHERE updated_at > $last`轮询，读日志不仅能看到删除记录、不额外增加负载，还避免了时间列漏标的可靠性陷阱。所以基本前提是：别轮询，读日志。
打通Postgres和ClickHouse的CDC管道，业界常见三种走法。我们评估了全部，并在生产环境中实际跑过其中两种，代价与取舍都来自实测。不论选哪条路，源头Postgres的参数要先行：wal_level = logical开启逻辑复制，合理设置发送者数、槽数以及WAL留存上限，避免失速的槽吃爆磁盘。再建一个带复制权限的用户，创建发布并纳入需要同步的表，注意无主键表必须设置`REPLICA IDENTITY FULL`——这会让更新和删除时把整行旧值写进WAL，写入成本更高，所以能加主键的表尽量加上。
第一条路是Kafka加Debezium。Debezium通过复制槽订阅WAL变更，把事件直接推入Kafka主题。独立的消费者再从Kafka拉取数据写入ClickHouse。这条链路的核心价值在于同一主题能扇出给搜索引擎、审计日志、数仓等多个下游，正因如此，团队才愿意接受它实实在在的运维成本：Kafka集群、连接器、Schema注册、监控、容量规划，以及能搞定分区重分配的轮值。我们的判断很明确——如果公司已经有Kafka技术栈，或需要事件流多路复用，这条路才划算。不过，要特别注意连接方式：若采用ClickPipes这类组件，必须直连Postgres，PgBouncer事务模式、RDS Proxy或Supabase连接池都不可用。
另外两条路径同样在考量之中：一条偏向轻量托管，另一条则是同构系统的直接对接。它们的取舍各不相同，但都绕不开对数据一致性、延迟和运维负担的平衡。站在选择的路口，真正需要解答的不是“能不能连上”，而是“哪套链路能和现有基础设施摩擦最小”，这往往比单纯的性能指标更值得反复推敲。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
