PostgreSQL 和 Iceberg 近几年都是现代数据栈中热度持续上升的技术。前者在 OLTP 场景中应用广泛，后者凭借开放表格式和不断扩大的计算引擎生态，正被越来越多企业用于建设数据湖。将事务数据库中的业务数据持续写入 Iceberg，也因此成为一种常见的数据入湖需求。
但要把两者持续打通并不容易。将 PostgreSQL 的新增、更新和删除及时写入 Iceberg，通常需要借助 CDC。可选的工具和路径不少，但真正落地远非开箱即用：全量与增量衔接、避免数据丢失或重复、故障恢复、Schema 演进、写入一致性和多组件运维，都需要逐项验证。
本文对比三条具有代表性的路径：Debezium + Kafka + Flink 的开源自建方案、CloudCanal 的私有部署方案，以及 Fivetran 的 SaaS 方案。下文将从全量与增量衔接、更新删除语义、Schema 演进、故障恢复、部署运维及数据安全等维度进行评估。
方案一：Debezium + Kafka + Flink（开源自建 CDC 栈）
架构
Debezium 通过 PostgreSQL 逻辑解码读取 WAL，并将变更事件写入 Kafka；Flink 消费事件、完成转换，再以流式方式写入 Iceberg。Apache Iceberg 的 Flink Connector 支持批量与流式写入；要使用 Upsert，需要 Iceberg v2 表，并配置主键或 identifier fields。分区表的分区源列还必须包含在 equality fields 中。
使用前需要在 PostgreSQL 中开启逻辑复制，并配置 replication slot 和 publication。同步任务停滞时，复制槽会继续保留 WAL，因此还要监控复制延迟和磁盘占用。
优势
- 组件均有成熟的开源生态，架构可控
- Kafka 可作为缓冲层，让源端 CDC 与下游计算解耦
- Flink 适合复杂过滤、关联、窗口计算和多路分发
- 可针对吞吐、延迟和一致性要求进行深度调优
局限
- 需要维护 Debezium、Kafka、Flink、Catalog 和对象存储等多个组件
- 必须持续监控复制槽积压、Kafka Lag、Flink Checkpoint 和 Iceberg Commit
- Debezium 快照、Kafka 位点与 Flink Checkpoint 共同参与恢复，全量与增量衔接及重放行为需要联调验证
- Schema 变更要同时考虑 CDC 事件结构、Flink 作业和 Iceberg 表结构
- 低延迟写入容易产生小文件，需要额外安排 Compaction
适用场景
适合已有 Kafka/Flink 平台、具备大数据工程团队，并且需要复杂实时计算或多下游分发的企业。
方案二：CloudCanal（私有部署数据同步平台）
架构
CloudCanal 提供 PostgreSQL → Iceberg 的直接数据链路，无需在中间部署 Kafka 和 Flink。它把 PostgreSQL WAL（逻辑复制）增量读取、目标表创建、历史全量迁移、增量 DML 落湖、监控和故障恢复集中在一个产品中，并可部署在企业自己的服务器、VPC 或内网环境中。数据链路和运行组件由企业掌控，适合不能将数据库连接或业务数据交给外部 SaaS、同时又不希望自行拼装和维护开源 CDC 栈的场景。
同步流程
- 检查源端 PostgreSQL 账号权限与逻辑复制准备（
wal_level=logical等），并确认源表有主键或已设置REPLICA IDENTITY FULL，以保证增量 UPDATE/DELETE 能取得完整的变更前值 - 添加 PostgreSQL 源端和 Iceberg 对端数据源
- 选择增量同步并勾选"全量初始化"实现"历史全量 + 持续增量"一体化，并选择要同步的库、表和列
- 启动任务，观察同步进度、延迟与 WAL 积压，再对比源表与 Iceberg 查询结果验证数据
与 CloudCanal 各数据源链路的"创建任务"流程一致，通常几分钟即可完成配置。详细操作可参考官方文档：创建增量同步任务（含全量初始化）；Iceberg 对端支持的 Catalog（AWS Glue / Nessie / REST）与存储（S3 / MinIO）组合见 Iceberg 数据源配置。
优势
- PostgreSQL 直接写入 Iceberg，减少 Kafka、Flink 等中间组件及其数据落地、位点和运维成本
- 结构迁移、历史全量和 WAL 增量在同一任务中衔接，降低自建链路处理切换位点的复杂度
- 对有主键的表原生处理增量 INSERT、UPDATE、DELETE（覆盖写入），无主键表按追加写入；比只追加 Parquet 文件更符合数据库入湖语义
- 可视化完成选表、选列、映射、过滤、运行监控与任务恢复，便于批量表和多任务统一管理
- 支持私有部署，可直接连接企业内网中的 PostgreSQL、Catalog 和对象存储，降低数据库暴露与数据出域风险
- 相比开源组件组合，产品化交付减少开发、联调和多组件运维；相比纯 SaaS，部署位置、网络边界和数据流向更可控
局限
- 处理能力的侧重不同：支持过滤、映射、虚拟列、自定义代码和可视化打宽表（主表 + 关联表拼接）；对于复杂窗口计算、持续多表流式 Join 和多路分发，Flink 等流计算框架通常更灵活
- Iceberg 为攒批写入，增量延迟通常为分钟级（内存攒批容量、刷出间隔等参数可调），不适合对秒级实时有硬性要求的场景
- 数据同步工具不负责 Iceberg 表维护（compaction、快照过期清理等仍需外部工具配合）
适用场景
适合对数据安全、内网访问、合规和部署位置有明确要求，同时希望用成熟产品替代开源组件拼装、减少自研代码并统一监控的企业。
如果还在选型阶段，可以先使用 CloudCanal 社区版搭建测试链路，用真实业务表验证全量与增量衔接、更新删除和故障恢复，再决定是否投入生产。
方案三：Fivetran（SaaS 托管服务）
架构
Fivetran 的 PostgreSQL Connector 支持全量初始化，并通过逻辑复制或 Query-Based CDC 定期捕获新增和变更数据。Managed Data Lake Service 将数据写成 Parquet 文件，同时维护 Iceberg 表元数据，可使用 Fivetran Iceberg REST Catalog，也可在 AWS 环境中集成 Glue Catalog。作为 SaaS 路径，其主要价值是把连接器运行、扩缩容和日常维护交给服务商，企业无需自行部署同步平台。
优势
- PostgreSQL 数据抽取和 Iceberg 表维护均由托管服务完成
- 无需在企业环境内安装和维护同步平台，上手快、运维投入低
- 支持 S3、ADLS 和 GCS 等数据湖存储
- 可通过 Spark、Trino、DuckDB 等引擎查询 Iceberg 表
局限
- 成本会随月度活跃行数和服务套餐增长
- 源端连接、数据出域、跨境传输和第三方托管可能受到企业安全与合规要求限制
- Iceberg 表由 Fivetran 管理，不适合由其他写入端同时修改
- Catalog 和存储组合受 Managed Data Lake Service 支持范围约束
适用场景
适合接受纯 SaaS 交付、允许服务商托管同步链路，并希望尽量减少部署和运维投入的团队。
三种 PostgreSQL 到 Iceberg 方案对比
| 维度 | Debezium + Kafka + Flink | CloudCanal | Fivetran |
|---|---|---|---|
| 核心定位 | 开源自建 CDC 栈 | 私有部署数据同步平台 | SaaS 托管服务 |
| 部署与数据边界 | 部署在自有环境，完全自主控制 | 部署在企业服务器、VPC 或内网，数据链路自主可控 | 服务商托管，需评估连接与数据出域 |
| 架构复杂度 | 高，需组合多个组件 | 低，单一产品直连 | 低 |
| 自定义处理能力 | 很高，适合复杂流式计算 | 支持过滤、映射、虚拟列、自定义代码和部分可视化宽表处理 | 较低，转换能力依赖平台配套服务 |
| 基础设施运维 | 需维护 Debezium、Kafka、Flink 等多个组件 | 企业负责基础运行环境，CloudCanal 提供产品化任务管理与监控 | 主要由服务商负责 |
| 全量 + 增量衔接 | 自行配置、开发和验证 | 在同一任务中产品化配置 | 托管服务完成 |
| Upsert / Delete | 需 Iceberg v2、主键/标识字段及正确的 Sink 配置 | 支持增量 UPDATE / DELETE，结构迁移可自动将源表主键设为 Iceberg Identifier Fields | 在受管 Iceberg 表中按平台机制应用源端变更 |
| Schema 演进 | 需协调 CDC 事件、Flink 作业与 Iceberg 表 | 支持结构迁移和自动建表 | 自动检测并按平台规则落表 |
| 主要成本 | 软件许可费为 0，承担基础设施、开发和多组件运维成本 | 社区版免费；商业版按任务数和时长计费） | 按 MAR 和套餐持续付费 |
| 更适合 | 有成熟大数据团队、需要深度定制 | 重视私有化、内网访问和数据可控，又希望降低自建复杂度 | 接受 SaaS 和数据托管、追求免部署 |
PostgreSQL 同步到 Iceberg 方案如何选择
| 你的情况 | 优先评估 |
|---|---|
| 已经稳定运行 Kafka 和 Flink，需要复杂实时 ETL | Debezium + Kafka + Flink |
| 数据库位于内网，强调数据不出域、部署自主可控，同时希望少写代码和统一监控 | CloudCanal 私有部署 |
| 不希望部署同步系统，且能够接受第三方 SaaS 托管、数据出域和持续按量付费 | Fivetran Managed Data Lake Service |
| 只有追加数据，没有更新和删除 | 可同时评估批量或微批入湖，不一定需要完整 CDC 栈 |
| 强依赖更新、删除和严格一致性 | 优先验证主键、Upsert、乱序处理和失败恢复 |
建议用一组真实业务表完成 PoC，并至少测试：
- 历史全量导入期间持续写入源库，检查全量与增量的衔接边界，以及是否出现丢失或重复。
- 对同一主键连续执行插入、更新和删除，检查最终状态。
- 执行加列、改类型等 DDL，验证兼容范围和任务行为。
- 中断网络或重启任务，检查是否重复、丢失以及能否从位点恢复。
- 制造下游阻塞，检查 PostgreSQL 复制槽和 WAL 磁盘增长。
- 连续运行数天，观察 Iceberg 小文件、快照数量和查询性能。
总结
已有 Kafka/Flink 基础设施、具备研发运维能力且需要复杂实时计算，可以选择 Debezium 开源自建栈；如果数据库和数据湖位于企业内网，对安全合规、网络边界和部署位置有要求，又希望避免自行拼装多个开源组件，CloudCanal 私有部署更契合这一定位；希望免部署、接受第三方托管和数据出域，可以选择 Fivetran 纯 SaaS 服务。