构建数据库多版本 Schema 仓库
· 阅读需 5 分钟
简介
本文主要介绍通过 CloudCanal 快速构建一条 MySQL -> Kafka 同步链路,以订阅源端数据库 DDL 变更和相关 schema 信息来构建数据库的多版本Schema仓库。
技术点
轻量便利的 SCHEMA 管理
常见的 Schema 管理方式如 Schema Registry, 用来管理 Schema 的演变历史,所有数据序列化反序列化需要用到的 Schema 保存在注册表里(构成一个多版本 Schema 仓库)。
每一个数据引用 Schema ID ,序列化或反序列化时从注册表里拉取对应的 Schema 进行相应动作。
CloudCanal 使用的是一种相对轻巧便利的解决方案:将 DDL 消息携带上最新的 Schema 信息直接发送到指定的 DDL Topic 上,有如下好处:
- 集中化管理:DML消息会发送到对应的 Topic 中,DDL 变更发送到指定的 DDL Topic,更加集中。
- 消费者无需解析DDL:下游不需要做任何处理直接消费(不需要做 SQL 解析,不需要序列化等前置操作)。
- Schema信息实时复用:多个应用程序可以直接复用实时的 Schema 信息。
- 简单轻巧:不需要依赖第三方组件,轻巧方便,自主可控。
新增 SCHEMA 元信息字段
CloudCanal 2.3.x 版本之前之前的 DDL 只是携带了对应的 DDL SQL,用户侧一些数据入湖的场景需要有数据的 Schema,否则数据湖的消费者要从每条消息去解析 Schema 信息,十分浪费计算资源,也不能给其他应用复用。
2.3.x 版本之后,发送到 Kafka 的 DDL 消息携带了整个表的结构化数据(Schema信息),并且支持将 DDL 同步到指定的 Topic 中,方便下游的 DDL 的统一化管理。
在CloudCanal发给消息系统的消息体中, tableChanges 字段携带的就是具体的源数据库的 Schema 信息,该 tableChanges 字段包含一个数组,其中包含表中每一列的元信息。由于结构化数据以 JSON 呈现数据,因此消费者无需先通过 DDL 解析器处理消息即可轻松读取消息。具体信息如下,其他字段详情见 Kafka 消息同步格式。