云计算

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

本文主要是介绍Hana 实时数据同步优化(3),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

简述

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

本轮优化主要包含:

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

优化点

任务级增量表

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

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

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

image.png

增量表定时清理

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

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

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

  • triggerDataCleanIntervalMin:增量表清理间隔(单位:分钟)
  • triggerDataRetentionMin:增量表数据保留时间(单位:分钟)

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

image.png

增量表自动演进

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

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

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

image.png

延迟判定优化

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 支持的目标端有 MySQLStarrocksDoris 等,接下来的版本将打通 TiDBOceanBaseAdbForMySQL 等目标链路,这个需求主要来自于用户。

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

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

这篇关于Hana 实时数据同步优化(3)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!