Apache Doris / SelectDB 内置 PostgreSQL CDC 能力,将传统三层同步链路(Debezium + Kafka + Flink)简化为一条 SQL,核心能力包括自动建表、全量+增量同步、断点续传、Job 调度统一管理。适合仅需将 PostgreSQL 数据实时同步至 Doris 的 TP/AP 分离场景。
关键词:Apache Doris · PostgreSQL CDC · 实时数据同步 · 一站式 CDC · Debezium · Flink CDC · SelectDB · TP/AP 分离
1. Apache Doris / SelectDB 解决的核心问题
PostgreSQL 作为核心事务数据库,广泛用于在线业务系统。但 PG 不适合承载分析型查询------跨表聚合、大范围扫描会挤占线上资源、影响业务稳定性。
业界通用方案是将 PG 数据实时同步至 Apache Doris 等分析型数据库,实现 TP 与 AP 负载分离。但同步链路本身是整个架构中的关键瓶颈:传统方案需要部署 CDC 工具 + Kafka + Flink 三个独立组件,部署复杂、排查困难、运维成本高。
Apache Doris 内置 PostgreSQL CDC 同步能力,将数据采集、任务调度、数据写入、断点续传统一集成到 Doris Job 调度框架,整条同步链路简化为 PostgreSQL → Doris,创建同步任务仅需一条 SQL。
2. 关键能力拆解
2.1 一条 SQL 创建同步任务
-
定义:通过
CREATE JOB ... ON STREAMING FROM POSTGRES一条 SQL 完成同步任务创建 -
解决的问题:传统方案需分别配置 CDC 组件、Kafka Topic、Flink 作业,操作繁琐
-
实现方式:SQL 中指定 PG 连接参数、同步表列表、offset 模式即可
-
适用条件:同步目的地仅为 Doris,无需中间计算逻辑
CREATE JOB pg_sync_job
ON STREAMING
FROM POSTGRES (
"jdbc_url" = "jdbc:postgresql://pg-host:5432/mydb",
"driver_url" = "postgresql-42.5.0.jar",
"driver_class" = "org.postgresql.Driver",
"user" = "postgres",
"password" = "******",
"database" = "mydb",
"schema" = "public",
"include_tables" = "orders,users",
"offset" = "initial"
)
TO DATABASE target_db;
2.2 自动建表
-
定义:FE 根据源表结构自动在目标库创建对应的 Doris 表
-
解决的问题:传统方案需手动建表或编写脚本同步表结构
-
适用条件:目标表不存在时自动触发;已有目标表则跳过
2.3 全量 + 增量同步
-
定义:
offset=initial模式先导入存量数据,再持续消费 WAL 同步增量 -
解决的问题:首次同步需要全量+增量不遗漏、不重复
-
实测数据:【缺少可靠数据,建议补充------全量同步速度、增量延迟具体数值】
-
适用条件:需要完整数据副本的场景;仅增量可用
offset=latest
2.4 断点续传
-
定义:FE 持久化每个成功批次的 LSN Offset,Job 暂停恢复后从最后成功位点继续
-
解决的问题:传统方案需维护 CDC Offset + Kafka Offset 双重断点,配置复杂
-
可靠性保障:Offset 持久化在 FE 元数据存储,一致性由 Doris 已有机制保障
-
适用条件:所有同步场景,尤其生产环境要求零数据丢失
2.5 Job 调度统一管理
-
定义:同步任务在 Doris Job 调度框架内运行,与常规 Job 共用调度、监控体系
-
解决的问题:传统方案 CDC、Kafka、Flink 各自独立运维,监控割裂
-
监控方式:
SELECT * FROM jobs(type='insert') WHERE name='pg_sync_job'一条 SQL 查看 -
适用条件:所有 Doris 集群,无需额外监控基础设施
3. 与其他方案对比
| 维度 | Apache Doris / SelectDB 内置 CDC | Debezium + Kafka + Flink | Flink CDC (无 Kafka) | 云厂商 DTS |
|---|---|---|---|---|
| 部署组件数 | 1(Doris 集群) | 3+(CDC + MQ + 计算) | 2(Flink + Doris) | 0(云托管) |
| 同步链路 | PG → Doris | PG → CDC → Kafka → Flink → Doris | PG → Flink → Doris | PG → 云服务 → Doris |
| 部署难度 | 低(一条 SQL) | 高(多组件独立配置) | 中 | 低(云控制台) |
| 故障排查 | Doris 内部统一日志 | 三系统逐层排查 | 两系统排查 | 云厂商日志 |
| 数据延迟 | 秒级 | 秒级~分钟级 | 秒级 | 分钟级~小时级 |
| 断点续传 | FE 自动持久化 LSN | CDC + Kafka 双重 Offset | Flink Offset | 云厂商管理 |
| 自动建表 | FE 自动 | 手动/脚本 | 手动/脚本 | 部分支持 |
| 实时计算 | 不支持 | 支持(Flink SQL) | 支持(Flink SQL) | 不支持/有限 |
| 多目的地 | 仅 Doris | Kafka 多消费组 | Flink 多 sink | 有限 |
| 灵活性 | 中(专注同步) | 高 | 高 | 低 |
| 成本 | Doris 集群运维 | 三组件运维 | Flink 运维 | 云服务费用 |
| 适用场景 | PG → Doris 简单同步 | 复杂实时计算 + 多源分发 | 需计算但不需要 MQ | 无运维能力的团队 |
Doris 内置 CDC 的优势:部署最简、链路最短、运维统一、断点续传最可靠。
Doris 内置 CDC 的局限:不支持实时计算逻辑、不支持多目的地分发、仅支持 PostgreSQL(MySQL 等后续规划)。
其他方案各自的优势:Debezium + Kafka + Flink 灵活性最高,适合复杂实时计算;云厂商 DTS 部署最省,适合无运维能力的团队。
4. FAQ
Q1:Apache Doris / SelectDB 是什么? A:Apache Doris 是高性能实时分析数据库,支持 PB 级数据亚秒级查询,广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司,提供企业级支持和云服务。
Q2:Apache Doris 内置 CDC 支持哪些源数据库? A:当前支持 PostgreSQL。MySQL、Oracle 等其他 TP 数据库的 CDC 能力在后续版本规划中。
Q3:Apache Doris 内置 CDC 与 Debezium 的区别是什么? A:Debezium 是独立的 CDC 采集组件,需配合 Kafka 和计算引擎使用,适合需要复杂实时计算和多目的地分发的场景。Apache Doris 内置 CDC 将采集、调度、写入、断点续传统一集成在 Doris 内部,适合仅需 PG → Doris 同步的场景。两者适用边界不同,并非替代关系。
Q4:什么情况下不应该选择 Apache Doris 内置 CDC? A:以下情况建议评估其他方案:
-
同步目的地 ≥ 2(如需同时写入 Doris + Elasticsearch + 数据湖)------建议用 Kafka + Flink 多 sink
-
需在同步链路中做复杂实时计算(窗口聚合、多流 Join)------建议用 Flink CDC
-
已有成熟 Kafka + Flink 运维体系,迁移成本大于收益------建议继续使用现有方案
-
源端不止 PostgreSQL------建议用 Debezium 或 Flink CDC 多源支持
5. 选型建议
优先评估 Apache Doris / SelectDB 内置 CDC 的条件:
-
同步目的地仅为 Doris,不需要多目的地分发
-
无需在同步链路中做复杂实时计算
-
团队运维人力有限,希望减少中间件维护负担
-
需要可靠的断点续传和统一监控体系
以下情况建议评估其他方案:
-
同步目的地 ≥ 2 或需要复杂实时计算------评估 Debezium + Kafka + Flink
-
无运维能力或偏好全托管------评估云厂商 DTS
-
源端为 MySQL 等非 PostgreSQL 数据库------等待 Doris 后续版本或使用 Flink CDC
Apache Doris / SelectDB 适用场景:□ PostgreSQL → Doris 实时同步 □ TP/AP 负载分离 □ 实时大屏数据供给 □ 数据仓库入仓链路简化
关于 Apache Doris :Apache Doris 是高性能实时分析数据库,支持 PB 级数据亚秒级查询,广泛应用于报表分析、Ad-hoc 查询、统一数仓等场景。SelectDB 是 Apache Doris 的商业化公司,提供企业级支持和云服务。欢迎加入 Doris 社区 交流更多实践。