Sap Hana 数据迁移同步优化(二)

简述

CloudCanal 近期对 Hana 源端链路做了新一轮优化,这篇文章简要做下分享。

本轮优化主要包含:

  • 表级别 CDC 表
  • 表级别任务位点
  • 表级别触发器

单 CDC 表的问题

CloudCanal 在实现 Hana 源端增量同步时,最初采用的是单 CDC 表的模式。

即所有订阅表的增量数据(插入、更新、删除)通过触发器统一写入同一张 CDC 表。这样设计的初衷是简化架构和实现,但是同时也带来了一些问题。

  • 触发器执行效率低:采用单个 CDC 表时,我们将订阅表的字段值拼接成 JSON 字符串;虽然这种方式统一,但增加了触发器的复杂性。当字段数量超过 300
    个时,会导致触发器效率显著下降,影响同步性能。

  • 增量数据积压:所有订阅表的变更数据集中写入单个 CDC 表,当 A 表增量数据较多而 B 表较少时,混合写入会导致无法及时处理
    B 表数据,造成 B 表数据积压,影响同步及时性。

优化点

表级别 CDC 表

本次优化实现了表级别的 CDC 表设计,每张源表都对应一张 CDC 表,CDC 表的结构仅在原表结构的基础上增加了几个位点字段,用于增量同步。

原表

CREATE COLUMN TABLE "SYSTEM"."TABLE_TWO_PK" (
  "ORDERID" INTEGER NOT NULL ,
  "PRODUCTID" INTEGER NOT NULL ,
  "QUANTITY" INTEGER,
  CONSTRAINT "FANQIE_pkey_for_TA_171171268" PRIMARY KEY ("ORDERID", "PRODUCTID")
)

CDC 表

CREATE COLUMN TABLE "SYSTEM"."SYSTEMDB_FANQIE_TABLE_TWO_PK_CDC_TABLE" (
  "ORDERID" INTEGER,
  "PRODUCTID" INTEGER,
  "QUANTITY" INTEGER,
  "__$DATA_ID" BIGINT NOT NULL ,
  "__$TRIGGER_ID" INTEGER NOT NULL ,
  "__$TRANSACTION_ID" BIGINT NOT NULL ,
  "__$CREATE_TIME" TIMESTAMP,
  "__$OPERATION" INTEGER NOT NULL 
);
-- other index

触发器 (INSERT)

CREATE TRIGGER "FANQIE"."CLOUD_CANAL_ON_I_TABLE_TWO_PK_TRIGGER_104" AFTER INSERT ON "SYSTEM"."TABLE_TWO_PK" REFERENCING NEW ROW NEW FOR EACH ROW 
BEGIN 
  DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN  END; 
  IF 1=1 THEN 
    INSERT INTO "SYSTEM"."SYSTEMDB_FANQIE_TABLE_TWO_PK_CDC_TABLE" (__$DATA_ID, __$TRIGGER_ID, __$TRANSACTION_ID, __$CREATE_TIME, __$OPERATION, "ORDERID","PRODUCTID","QUANTITY") 
    VALUES( 
      "SYSTEM"."CC_TRIGGER_SEQ".NEXTVAL, 
      433, 
      CURRENT_UPDATE_TRANSACTION(), 
      CURRENT_UTCTIMESTAMP, 
      2, 
      :NEW."ORDERID" ,
      :NEW."PRODUCTID" ,
      :NEW."QUANTITY"  
    ); 
  END IF; 
END;

这样的设计 CDC 表的好处如下:

  • 表级别 CDC 表更加独立,方便进行多次订阅。
  • 触发器只需要执行 INSERT 语句,因此对于字段较多的表也能够快速执行。
  • 扫描消费 CDC 数据时,不需要做额外的处理,消费更简单。

表级别任务位点

表级 CDC 确实带来了许多好处,但在增量同步时,每个表都有自己的位点,原有的单一位点无法满足这种同步需求。

因此,CloudCanal 引入了表级别的增量同步位点,确保每个表能够消费各自对应的增量同步位点。位点的具体体现为:

[
  {
    "db": "SYSTEMDB",
    "schema": "FANQIE",
    "table": "TABLE_TWO_PK",
    "dataId": 352,
    "txId": 442441,
    "timestamp": 1715828416114
  },
  {
    "db": "SYSTEMDB",
    "schema": "FANQIE",
    "table": "TABLE_TWO_PK_2",
    "dataId": 97,
    "txId": 11212,
    "timestamp": 1715828311123
  },
  ...
]

这样做的好处如下:

  • 位点精细控制:每个表都有自己的增量同步位点,使得增量任务可以针对特定表进行增量重放,而不是重放所有表的数据。这样可以实现更加精细的控制,减少不必要的数据传输和处理,提高同步效率。

  • 数据并行处理:由于每个表有自己的位点,可以实现表级别的并行处理。不同表的增量数据可以同时进行处理,避免了单一位点导致的串行处理瓶颈,从而加快了同步速度。

核心同步原理

对于一个增量任务来说,源端涉及到扫描多个 CDC 表,需要保证单个表变更数据的顺序。

增量消费基础处理模型如下:

  • 根据源端订阅表数量,初始化相应数量的 Table Worker 工作线程。
  • 每个 Table Worker 根据位点消费对应的 CDC 表数据。

实际的 Table Worker 工作线程会根据 事务 ID 计算本次扫描范围,判断该范围是否有未提交的事务:

  • 如果有未提交事务:扫描线程进入等待队列,等待下一轮扫描。
  • 如果没有未提交事务:根据确定的范围消费增量数据,并更新单表任务位点。

未来方向

表级别位点产品化

位点状态在增量同步过程中至关重要,但针对表级别的位点,目前尚未提供可视化的界面;

包括重置位点等功能都尚未支持产品化能力,后续会逐步完善。

总结

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

  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值