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

2024-05-25 06:12

本文主要是介绍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
源端数据同步的优化,以及链路未来的方向,希望对读者有所帮助。

这篇关于Sap Hana 数据迁移同步优化(二)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1000696

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

服务器集群同步时间手记

1.时间服务器配置(必须root用户) (1)检查ntp是否安装 [root@node1 桌面]# rpm -qa|grep ntpntp-4.2.6p5-10.el6.centos.x86_64fontpackages-filesystem-1.41-1.1.el6.noarchntpdate-4.2.6p5-10.el6.centos.x86_64 (2)修改ntp配置文件 [r

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传