gta5网站建设中,温州建设局老网站,健康网站 模板,沈阳建设工程信息网 采购甲方都在中项网简述
CloudCanal 近期对 Hana 源端链路做了新一轮优化#xff0c;这篇文章简要做下分享。
本轮优化主要包含:
表级别 CDC 表表级别任务位点表级别触发器
单 CDC 表的问题
CloudCanal 在实现 Hana 源端增量同步时#xff0c;最初采用的是单 CDC 表的模式。
即所有订阅表…简述
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 11 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 源端数据同步的优化以及链路未来的方向希望对读者有所帮助。
