CDC 入湖怎么落地

难度与前置

难度：进阶
前置：知道 CDC 是「抓变更」而非「定时全量」；能读表主键与分区设计。
读完能做什么：从业务表到 ODS 定 CDC 链路（工具、位点、主键、DDL 策略），并用对账与演练验收。

适用场景

当你要把业务库变更近实时进仓（订单、账户、配置维），供实时/准实时主题或加速离线 ODS，而不是每天全量抽数。

不适用：

源表无主键、无稳定唯一键且无法补（先治理模型）
仅需 T+1 且源可稳定抽全量（批量更简单）
源库禁止开 binlog / 无权连（先过安全与架构评审）

真实场景（一条）

订单表日批入 ODS，运营要「分钟级订单状态」。上 Debezium → Kafka → Flink 写 Iceberg ODS 后，出现：高峰延迟 15 分钟；一次 DDL 加列导致连接器挂；对账发现更新变插入重复。

改法：主键 upsert 入湖；DDL 变更走「停写→演进 schema→再追位点」；源库隔离只读账号与带宽；用增量对账验收。目标：延迟进 SLA，主键不重复，DDL 可演练。

怎么做（步骤清单）

1. 选型边界

方案	适合	注意
Debezium / Canal / Flink CDC	标准 MySQL/PG binlog	权限、GTID、大字段
云厂商 DTS	托管、少运维	锁定厂商能力与费用
业务双写	源侧强控	易漏写、难一致，不推荐当主路径

默认推荐：成熟 CDC 连接器 → Kafka Topic → 入湖作业（Flink/Spark）。

2. 表与 Topic 契约

项	示例
主键	`order_id`
变更类型	insert/update/delete 是否都要
目标	`ods_order_rt`（主键 upsert）或明细 append
分区	Kafka：按主键或业务键；湖表：按日/小时
SLA	端到端 P95 < 3min
责任人	源库 DBA + 数据 owner

text

cdc.order.order_info
cdc.order.order_item

3. 源库侧准备

开启 binlog（ROW）与必要 GTID
只读账号：最小权限（按工具文档）
评估大事务、超宽表、无主键表：先治理再接
网络与限流：避免 CDC 拖垮主库（必要时跟从库）

4. 入湖语义

目标语义	做法
当前镜像（SCD1）	按主键 upsert / 处理 delete 事件
变更流水	append 全量变更；下游再建快照
拉链表（SCD2）	另文；CDC 只保证变更完整

sql

CREATE TABLE ods_order_rt (
  order_id STRING,
  status STRING,
  pay_amount DECIMAL(18,4),
  updated_at TIMESTAMP(3),
  PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
  'connector' = 'upsert-kafka',
  ...
);

5. 位点与故障恢复

连接器位点（binlog offset / GTID）进可持久存储
故障恢复：从保存位点续传，禁止无评估地从 latest 跳
Kafka 保留时长覆盖补救窗口；否则要具备重新快照能力
首次上线：全量快照 + 增量切换的窗口要对账

6. DDL 变更 Playbook

源库发起加列/改类型前通知数据侧
评估连接器兼容性；不兼容则短暂停 CDC
下游表 schema 演进（Iceberg/Hudi 或重建）
从约定位点恢复；跑增量对账
禁止「源库先上 DDL、下游事后发现字段丢失」

消息侧兼容级别与 Registry 纪律见 Schema 演进。

7. 监控与告警

项	示例
连接器存活	进程/任务 Down 立即告警
位点延迟	binlog 延迟 > 阈值
Kafka lag	CDC 下游消费组 lag
入湖错误	upsert 失败率、DDL 异常
对账任务	小时级主键抽样 diff

8. 与实时排查的衔接

端到端慢时，先确认 CDC 段延迟，再进实时链路延迟排查。不要一上来重启入湖作业导致位点跳跃。

常见坑（至少牢记这些）

无主键表做 upsert 入湖
无法定义「同一行」，重复与删除都会乱。先补主键或改 append 流水。
把 CDC Topic 当业务广播随便多人消费改位点
一组一职责；监控消费滞后。
忽略大字段与大事务
单条变更巨大导致延迟与内存爆。裁剪字段或拆表。
只用全量 count 对账
count 相同仍可能内容错。要抽主键内容比对 + 增量窗口金额。
从库延迟当 CDC 延迟排查唯一手段
还要看连接器、Kafka、入湖作业三环。

如何验收（可量化）

合并前 checklist，全勾才算本篇实践落地：

[ ] 源表清单：主键、字段裁剪、SLA、负责人齐全
[ ] 首次快照 + 增量切换有对账记录
[ ] 人为 update/delete 后，湖表镜像与源库一致
[ ] 连接器重启后位点续传，无全表重刷（除非演练快照）
[ ] DDL 演练通过或书面豁免
[ ] 端到端延迟与落库错误率进监控

sql

SELECT s.order_id, s.status AS src_status, o.status AS ods_status
FROM src_order_db.order_info s
LEFT JOIN ods_order_rt o ON s.order_id = o.order_id
WHERE s.updated_at >= '${start}' AND s.updated_at < '${end}'
  AND (o.order_id IS NULL OR s.status <> o.status)
LIMIT 100;

bash

kafka-consumer-groups.sh --bootstrap-server ${brokers} \
  --describe --group cdc_order_ingest

初始化完成后保留位点快照与全量导出校验和，便于半年后审计「当时为何认为一致」。

首次上线检查单（可复制）

[ ] 源库 binlog/权限/从库策略确认
[ ] Topic 命名、分区键、保留时长评审通过
[ ] 快照窗口与增量切换 runbook 演练一次
[ ] upsert 主键与 delete 语义写进表注释
[ ] 对账 SQL 与告警挂上
[ ] 回滚：停连接器 + 保留位点路径已知

CDC 入湖怎么落地 ​

适用场景 ​

真实场景（一条） ​

怎么做（步骤清单） ​

1. 选型边界 ​

2. 表与 Topic 契约 ​

3. 源库侧准备 ​

4. 入湖语义 ​

5. 位点与故障恢复 ​

6. DDL 变更 Playbook ​

7. 监控与告警 ​

8. 与实时排查的衔接 ​

常见坑（至少牢记这些） ​

如何验收（可量化） ​

首次上线检查单（可复制） ​

相关面试题 ​