kettle实现数据增量同步方案

1. 背景

我司目前数据库之间的数据同步都是oracle goldengate(ogg)方案,该方案的特点:
优点:

  • 基于数据库的变更日志同步(oracle redo\mysql binlog),速度很快,对数据库性能影响很小,适合大量数据同步的场景

缺点:

  • 同步表变更字段、新增表,需要修改数据库服务器上的很多配置文件,比较繁琐,在exact、pump、replicate进程很多的情况下,易误操作;
  • 如果某个表同步失败,重建配置比较复杂;
  • 需要在每个数据库服务器上安装软件;
  • 无界面,不直观,配置分散……

为了解决ogg的上述缺点,研究了新的同步方案:kettle
kettle是通过sql,基于主键、时间戳增量同步数据,不需在数据库服务器上做任何配置,只需在kettle服务器上创建配置JOB即可,有简单直观的CS平台。
今后将以kettle为主,同步数据量很大的表(如单表日同步100万记录以上),会考虑ogg。

2. 安装

版本:pdi8.3
OS:因为linux的界面失真,用起来实在蓝瘦香菇,而且每次启动spoon都很费时,因此用windows平台。
安装过程很简单:

  • 安装jdk1.8;
  • 解压pdi.zip;
  • 下载驱动oracle(ojdbc14.jar)、mysql(mysql-connector-java-5.1.9.jar、mysql-connector-java-6.0.6.jar)至目录pdi\data-integration\lib:

3. 配置

kettle的几个关键组件说明

  • SQL:顾名思义,就是执行一段SQL,可以包含多条
  • 转换:包含表输入、设置变量、排序、合并、switch、表输出、更新、插入/更新等功能,是kettle的精华所在,实现关键逻辑
  • 作业:一个同步的完整逻辑,包含SQL、转换等,用“作业定时调度”和“成功”分别开始和结束作业
  • DB连接:数据库连接,可以在转换或作业下创建,默认在该转换或作业下生效;支持“共享”,将该连接在全局范围生效

对表的要求

  1. 表有主键;
  2. 应用不能物理删除数据,只能逻辑删除数据,设置字段(delete_flag tinyint/number(1):0:未删除,1,已删除),可通过定时任务在源和目标端物理删除delete_flag=1的数据;
  3. 统一时间戳字段(update_time oracle:date/mysql datetime),所有数据变更(包含delete_flag)必须同时修改update_time;
  4. Oracle number类型同步到mysql bigint时,支持最大长度18位,不能用默认number(默认38位);
  5. 手动维护数据时需要源和目标端同时处理(truncate,delete,update without update_time);

原理说明

  1. 创建表sync_timestamp(table_name,time_stamp),记录每张表完成同步的时间戳,第一次同步前,手工设置为源表中update_time最小值;
  2. 每次同步时,先设置环境变量TIME_STAMP = sync_timestamp中的time_stamp;
  3. 将源表大于等于TIME_STAMP的数据对目标表插入/更新;
  4. 用目标表update_time字段的最大值,更新sync_timestamp中的time_stamp字段;

作业:job_sync_t1(oracle->mysql)

转换:trans_get_timestamp

表输入:

select DATE_FORMAT(time_stamp,'%Y-%m-%d %H:%i:%S') time_stamp
from sync_timestamp
where table_name='sync_t1'

设置变量:

转换:trans_sync_data

表输入:

select *
from sync_t1
where update_time >= to_date('${TIME_STAMP}','yyyy-mm-dd hh24:mi:ss')

插入/更新:

4. 调度

kettle job通过kitchen命令执行;每次执行JOB时,kitchen要初始化几百M的内存,耗时10秒以上,一个kitchen进程启动后只能执行1次JOB;如果大量kitchen同时启动,会消耗大量内存,对OS内存配置要求很高。

为了合理化利用资源,将JOB调度按调度频率划分到不同文件,每个文件根据具体同步数据的压力情况安排3-5个job:

1分钟执行1次的JOB:

file1: job_1min_1.bat,包含job1-job3

file2: job_1min_2.bat,包含job4-job6

file3: job_1min_3.bat,包含job7-job9

……

 job_1min_1.bat的内容:

e:
cd e:\pdi\data-integration
kitchen /file:e:\mykettle\job1\job.kjb /level:Error
kitchen /file:e:\mykettle\job2\job.kjb /level:Error
kitchen /file:e:\mykettle\job3\job.kjb /level:Error

通过kettle服务器的任务调度定期执行 job_1min_1.bat文件即可。

备注:kettle自身没有防止JOB并发执行的机制(如某JOB执行频率每分钟1次,但一次执行耗时超过1分钟,就会存在并发执行的情况);并发执行时,插入重复数据报错,可以监控到JOB错误,从而优化JOB或调度。

5. 监控

JOB配置日志表,记录JOB执行情况;

创建日志表

CREATE TABLE `sync_log` (
  `ID_JOB` bigint(20) NOT NULL,
  `JOBNAME` varchar(100) COLLATE utf8mb4_bin DEFAULT NULL,
  `STATUS` varchar(20) COLLATE utf8mb4_bin DEFAULT NULL,
  `ERRORS` bigint(20) DEFAULT NULL,
  `LOGDATE` datetime DEFAULT NULL,
  `LOG_FIELD` blob,
  `LINES_READ` bigint(20) DEFAULT NULL,
  `LINES_WRITTEN` bigint(20) DEFAULT NULL,
  `LINES_UPDATED` bigint(20) DEFAULT NULL,
  `LINES_INPUT` bigint(20) DEFAULT NULL,
  `LINES_OUTPUT` bigint(20) DEFAULT NULL,
  `LINES_REJECTED` bigint(20) DEFAULT NULL,
  `STARTDATE` datetime DEFAULT NULL,
  `DEPDATE` datetime DEFAULT NULL,
  `REPLAYDATE` datetime DEFAULT NULL,
  `ENDDATE` datetime DEFAULT NULL,
  PRIMARY KEY (`ID_JOB`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

job指定日志表:

sync_log

sync_timestamp

通过上述2个表的关联,确认JOB是否正常执行,配置到zabbix监控项。

判断标准:sync_timestamp表记录的table_name,在sync_log中都有最新的成功执行的日志(status=end,error=0,logdate<now-interval_seconds)

select count(*)-(select count(*) from dbcopy.sync_timestamp) errorjob
from dbcopy.sync_log a, dbcopy.sync_timestamp b
where (a.jobname,a.logdate) in  (select jobname,max(logdate) 
                                 from dbcopy.sync_log 
                                 where errors=0 and status='end' 
                                 group by jobname)
and a.jobname=b.table_name
and a.logdate > DATE_SUB(now(),INTERVAL (b.interval_seconds + 60) second)

以上SQL返回值>0即说明JOB执行有异常。

over ~

发布了24 篇原创文章 · 获赞 25 · 访问量 2万+

猜你喜欢

转载自blog.csdn.net/sdmei/article/details/103498493