Debezium 基础教程

内容：它是什么 -> 原理 -> 架构 -> 支持的数据库 -> 数据格式 -> 与 Kafka/ES 的集成 -> 生产最佳实践 -> 常见坑

🚀 Debezium 是什么？

Debezium 是一个基于 CDC（Change Data Capture，变更数据捕获）的开源组件，用于实时捕获数据库中 INSERT / UPDATE / DELETE 的变化，并将变化事件发送到 Kafka（或 Kafka Connect Sink）。

Debezium = 把数据库的 binlog / WAL，实时变成结构化事件流

☘️ Debezium 解决什么问题？

传统方案（轮询 DB）的问题：

性能差（反复扫表）
延迟高（分钟级）
无法感知 DELETE
难保证顺序和一致性

Debezium 的优势：

能力	Debezium
实时性	秒级
数据来源	数据库日志（不是 SQL）
DELETE 感知	✅
顺序保证	✅（分区内）
可回放	✅（Kafka）
对 DB 压力	极低

🧩 Debezium 的整体架构

MySQL / PostgreSQL
   │
   │  binlog / WAL
   ▼
Debezium Connector
   │
   │  Change Event（JSON / Avro）
   ▼
Kafka Topic
   │
   ├── Elasticsearch Sink
   ├── Flink / Spark
   ├── Cache / Search / BI

Debezium 本身不是一个服务，而是 Kafka Connect 的一个 Source Connector。

🔍 Debezium 工作原理（非常重要）

1️⃣ 初始化（Snapshot）

第一次启动：

Debezium 会对表做一次一致性快照
把当前表的所有数据发送到 Kafka
同时记录当前 binlog / WAL 位点

⚠️ Snapshot 只发生一次（可配置）

2️⃣ 实时变更捕获（CDC）

之后：

Debezium 持续监听 binlog / WAL
任何 INSERT / UPDATE / DELETE
都会生成一条事件写入 Kafka

3️⃣ 位点管理（Offset）

Debezium 会记录：

binlog 文件名 + position（MySQL）
LSN（PostgreSQL）

保证：

不丢数据
不重复消费
可断点恢复

🗄️ Debezium 支持哪些数据库？

数据库	方式
MySQL	binlog
PostgreSQL	WAL
Oracle	redo log
SQL Server	CDC / log
MongoDB	oplog
DB2	log

你关心的重点：

MySQL：ROW 格式 binlog
PostgreSQL：logical replication + WAL

🐬 Debezium + MySQL（重点）

MySQL 必须满足

[mysqld]
server-id = 223344
log-bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL

为什么必须是 ROW？

Debezium 需要拿到 每一行的前后变化

MySQL Connector 核心参数

{
  "connector.class": "io.debezium.connector.mysql.MySqlConnector",
  "database.hostname": "mysql",
  "database.port": "3306",
  "database.user": "debezium",
  "database.password": "pwd",
  "database.server.id": "184054",
  "database.server.name": "mysql01",
  "database.include.list": "app_db",
  "table.include.list": "app_db.users",
  "snapshot.mode": "initial"
}

🐘 Debezium + PostgreSQL（重点）

PostgreSQL 必须配置

wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

并创建 replication slot。

PG Connector 示例

{
  "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
  "database.hostname": "pg",
  "database.port": "5432",
  "database.user": "debezium",
  "database.password": "pwd",
  "database.dbname": "app",
  "slot.name": "debezium_slot",
  "publication.name": "dbz_pub",
  "table.include.list": "public.users"
}

📦 Debezium 事件格式

一条 UPDATE 事件结构

{
  "before": {
    "id": 1,
    "name": "Tom"
  },
  "after": {
    "id": 1,
    "name": "Tommy"
  },
  "op": "u",
  "ts_ms": 1710000000000
}

op 类型

值	含义
c	insert
u	update
d	delete
r	snapshot

🔄 Debezium -> Elasticsearch 同步

推荐方式（生产级）

Debezium -> Kafka -> Elasticsearch Sink

关键点

DB 主键 -> ES _id
UPDATE -> index
DELETE -> delete
Kafka consumer group 实现并行

ES Sink 示例逻辑

transforms=unwrap
transforms.unwrap.type=io.debezium.transforms.ExtractNewRecordState
transforms.unwrap.drop.tombstones=true

⚠️ Debezium 常见坑（非常重要）

1️⃣ 表必须有主键

没有主键：

无法生成稳定事件
ES 无法幂等写入

2️⃣ WAL / binlog 积压

下游消费慢 -> binlog/WAL 不会被清理 -> 磁盘爆满

👉 必须监控 lag

3️⃣ Snapshot 期间压力

首次 snapshot：

会扫全表
需避开业务高峰

4️⃣ Schema 变更

ALTER TABLE 会产生 schema change 事件
下游需要能容忍字段变化

🧪 Debezium vs 其它方案

方案	实时性	压力	DELETE	复杂度
Logstash JDBC	低	高	❌	低
自研轮询	低	高	❌	中
Debezium	高	极低	✅	高
官方 Connector	中	低	部分	低

☘️ 总结

Debezium 是一个基于 CDC 的数据同步组件，通过监听 MySQL 的 binlog 或 PostgreSQL 的 WAL，实时捕获 INSERT / UPDATE / DELETE，以事件流的形式发送到 Kafka。

相比轮询数据库，它延迟低、对源库压力极小、支持 delete、支持回放，非常适合构建实时同步到 Elasticsearch、缓存或数据仓库的架构。

补充

Debezium 是一个基于 CDC（Change Data Capture，变更数据捕获）的开源工具，用来实时监听数据库的增删改（DML）以及部分 DDL 变化，并把这些变化以事件流的形式发送出去（通常到 Kafka）。

Debezium = 把数据库的 binlog / WAL 变成实时事件流

核心能力

✅ 实时捕获 INSERT / UPDATE / DELETE
✅ 顺序一致、至少一次（at-least-once）语义
✅ 崩溃可恢复（基于 offset）
✅ 支持表结构变更（部分 DDL）
✅ 不侵入业务代码

支持的数据库

常用的：

MySQL / MariaDB（binlog）
PostgreSQL（WAL / logical replication）
MongoDB（oplog）
Oracle
SQL Server
Db2

架构组成

[ Database ]
     ↓  (binlog / WAL)
[ Debezium Connector ]
     ↓
[ Kafka Topic ]
     ↓
[ 下游系统 ]

Debezium 本质是 Kafka Connect 的一类 Source Connector。

事件数据格式（典型）

{
  "before": { "id": 1, "name": "old" },
  "after":  { "id": 1, "name": "new" },
  "op": "u",
  "ts_ms": 1730000000000
}

op 含义：

c -> create（insert）
u -> update
d -> delete
r -> snapshot（快照）

常见使用场景

🔁 数据同步（MySQL -> Elasticsearch / ClickHouse）
☘️ 事件驱动架构
📊 实时数仓 / 实时分析
🔌 微服务解耦（数据库事件化）
🧪 审计 / 数据变更追踪

Debezium vs 传统方案

方案	问题
定时全量同步	延迟高、压力大
业务代码发消息	强侵入、易漏
Debezium	✅ 实时、低侵入、可靠

PostgreSQL 特别注意（你常用）

必须开启 logical replication
使用 wal_level = logical
为 Debezium 创建 replication slot
表必须有主键

常见坑

⚠️ 表没主键 -> update/delete 会有问题
⚠️ binlog/WAL 保留策略不当 -> slot 堆积
⚠️ 大表 snapshot 阶段压力大
⚠️ exactly-once ≠ 事务级一致（需下游处理）

典型组合

Debezium + Kafka + Kafka Streams / Flink
Debezium + Kafka + Elasticsearch
Debezium + Kafka + ClickHouse
Debezium + Kafka + FastAPI 消费