Hana 实时数据同步优化(3)

简述

CloudCanal 近期对 Hana 源端链路做了新一轮优化，优化点主要来自用户实际场景使用，这篇文章简要做下分享。

本轮优化主要包含:

• 新增任务级增量表
• 新增增量表定时清理能力
• 新增增量表表结构自动演进能力
• 任务延迟判定优化
• Hana 1.x 的兼容
• 产品化和文档优化

优化点

任务级增量表

CloudCanal Hana 源端任务原本不支持修改默认增量表，导致不同任务的触发器将增量数据写入同一个表，不同任务将相互影响。

比如，A 任务订阅的表积压大量数据，将影响B,C,D等订阅相同表的任务增量同步效率。

为解决这一问题，本轮优化支持 每个任务可单独设置增量表 ，以此确保任务之间互不影响。

增量表定时清理

触发器将增量数据写入增量表后，若未及时清理，可能导致空间占用增加。

在之前的版本中，用户只能手动定期清理，过程繁琐且具备一定风险(清理错)。

本轮优化增加设置任务参数 triggerDataCleanEnabled 打开自动定时清理增量表功能，并提供两个参数进行控制：

• triggerDataCleanIntervalMin：增量表清理间隔（单位：分钟）
• triggerDataRetentionMin：增量表数据保留时间（单位：分钟）

通过这套机制，用户能够灵活控制增量表的清理操作，同时确保未消费的增量数据不会被意外清除。

增量表自动演进

Hana 增量任务创建时自动生成增量表，CloudCanal 依赖于增量表实现各种能力，但随着 CloudCanal 版本更新，可能对增量表进行变更(比如加入新字段)。

由此带来的问题是：用户在更新 CloudCanal 后需要手动执行 DDL 以适应增量表结构的变化，若存在大量增量表，操作相当复杂。

为解决此问题，CloudCanal 新增 增量表结构 DIFF 能力，在任务启动时 自动生成差异 DDL 实现对增量表的自动演进。

延迟判定优化

Hana 源端增量同步使用位点(增量表自增ID)来判断延迟，当位点向前推进时可准确获取延迟，但若无变更事件导致位点不更新，延迟会持续增大，实际上并未发生延迟。

为解决这一问题，本轮优化 通过查询增量表来判断是否存在延迟，具体逻辑为:

• 若存在数据，系统根据增量数据的时间戳计算延迟。
• 若无数据，任务获取当前时间发送心跳事件，并根据心跳上的时间戳计算延迟。

时间戳仅在重置位点时才用于数据查找，且在查找时进行时区转换处理。

Hana 1.x 的兼容

CloudCanal 之前版本只支持 Hana 2.x 版本，但是随着用户使用，我们发现一些用户还是在使用 Hana 1.x 版本。

Hana 1.x 版本的触发器和 2.x 存在一定的差异，且元信息获取逻辑也不同。

本轮优化对上述差异点进行了兼容性优化，使 CloudCanal 能够比较全面的支持 Hana 1.x 和 2.x 版本的数据同步。

产品化增强

本轮优化除了内核层面增强，对产品能力和文档做了一系列优化，有效解决用户在数据源添加、任务创建等环节中常见的权限问题。

• 完善 Hana 权限准备文档、数据源创建 FAQ
• 创建任务时预检 Schema、增量表的权限
• 创建任务勾选表时，自动过滤当前任务增量表

这些优化举措让用户创建迁移同步链路更加流畅，节省时间。

未来方向

更多目标链路

目前 Hana 支持的目标端有 MySQL、Starrocks、Doris 等，接下来的版本将打通 TiDB、OceanBase、AdbForMySQL 等目标链路，这个需求主要来自于用户。

优化多字段触发的处理速度

在处理多字段表（单个表 300+ 字段）时，目前触发器的执行效率不满足预期，导致 DML 操作速度较慢，我们后续将对触发器模板进行性能优化，以提高处理速度。

总结

本文简要介绍 CloudCanal 近期对 Hana 源端数据同步的优化，以及链路未来的方向，希望对读者有所帮助。