Waterdrop中Oracle-CDC到ClickHouse数据同步的类型转换问题解析

问题背景

在使用Waterdrop(现更名为SeaTunnel)进行Oracle到ClickHouse的数据同步过程中，开发人员遇到了一个典型的数据类型转换问题。当使用Oracle-CDC连接器从Oracle读取数据并写入ClickHouse时，系统报错"java.math.BigDecimal cannot be cast to java.lang.Integer"，而直接使用Oracle源连接器则能正常运行。

问题现象

在Oracle数据库中定义了一个包含INT类型字段的表：

CREATE TABLE test
(
ID       INT,
NAME     VARCHAR(32),
QUANTITY INT,
PRIMARY KEY (id)
);

对应的ClickHouse表结构为：

CREATE TABLE test (
`ID`       Int32,
`NAME`     String,
`QUANTITY` Int32
) ENGINE = MergeTree
PRIMARY KEY ID
ORDER BY ID;

当使用Oracle-CDC连接器同步数据时，系统抛出类型转换异常，提示无法将BigDecimal转换为Integer。

问题分析

CDC连接器与普通连接器的差异

1. 数据捕获机制不同：Oracle-CDC连接器通过捕获数据库变更日志来获取数据，而普通Oracle连接器直接执行查询获取数据

2. 数据类型处理差异：CDC连接器在捕获变更时，Oracle的INT类型会被转换为Java的BigDecimal类型，而普通连接器会保持为Integer类型

3. ClickHouse接收处理：ClickHouse的JDBC驱动期望接收的是与目标字段类型匹配的数据类型，当接收到BigDecimal时无法自动转换为Int32

根本原因

Oracle数据库中的INT/NUMBER类型在CDC模式下被Debezium等CDC工具统一处理为BigDecimal，以确保能够容纳各种精度的数值。而ClickHouse的Int32类型期望接收的是Java的Integer类型数据，导致类型不匹配。

解决方案

方案一：修改Oracle表结构

将Oracle表中的INT类型明确指定为NUMBER类型并定义精度：

CREATE TABLE test
(
ID       number(8),
NAME     varchar(32),
QUANTITY number(8),
PRIMARY KEY (id)
);

这种修改可以确保CDC连接器捕获数据时保持数值的整数特性，便于ClickHouse正确接收。

方案二：使用Waterdrop的类型转换功能

在Waterdrop配置中添加类型转换规则，将BigDecimal显式转换为Integer：

transform {
  convert {
    source_field = "ID"
    target_field = "ID"
    target_type = "int"
  }
  convert {
    source_field = "QUANTITY"
    target_field = "QUANTITY"
    target_type = "int"
  }
}

方案三：调整ClickHouse表结构

将ClickHouse表中的Int32改为Decimal类型以匹配CDC输出的数据类型：

CREATE TABLE test (
`ID`       Decimal(10,0),
`NAME`     String,
`QUANTITY` Decimal(10,0)
) ENGINE = MergeTree
PRIMARY KEY ID
ORDER BY ID;

最佳实践建议

1. 数据类型一致性：在设计跨数据库同步方案时，应预先考虑源库和目标库的数据类型映射关系

2. CDC特殊处理：使用CDC工具时要注意其数据类型处理方式可能与普通JDBC连接器不同

3. 明确精度定义：对于数值类型，建议在源库中明确定义精度和范围，避免隐式转换

4. 测试验证：在生产环境部署前，应对数据类型转换进行充分测试

总结

Waterdrop/SeaTunnel作为数据集成工具，在处理不同类型数据库间的数据同步时，数据类型转换是一个常见挑战。特别是在使用CDC模式时，数据捕获机制会引入额外的类型转换层。通过理解底层机制并采取适当的类型映射策略，可以确保数据同步的稳定性和准确性。本文提供的解决方案不仅适用于当前问题，也为类似的数据集成场景提供了参考思路。