datax采坑体验

因为公司需要使用greenplum,而官方的datax版本在导数据到greenplum时,速度是非常慢的(严格说是datax导数据到postgresql,在导入到GP时,数据走的是master,一条一条insert的,当然是慢)。

所以,这里采用了别人开发好的支持GP 的datax版本:https://github.com/HashDataInc/DataX

首先来说一下GP,GP作为一种数据仓库工具,是比较特殊的,因为一般的etl工具在往GP中导数据普遍是比较慢的。

GP底层就是多个postgresql数据库组成的postgresql集群,由一个master来管理,当然可以有一个standby的master。而一般的etl工具在向GP导数据时,会走master,再由master来分发,效率极其低下。

要用好GP,就需要顺应GP。用GP最喜欢的导入方式去导数据,比如 通过使用copy命令,通过使用gpfdist工具,当然阿里有相应的收费软件也支持快速导入。

本次使用的datax版本,其实是封装了GP的copy方式。

mysql导数据到GP:

{
	"content":[
		{
			"reader":{
				"name":"mysqlreader",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":[
								"jdbc:mysql://*******:3306/*********?characterEncoding=utf8"
							],
							"table":[
								"********"
							]
						}
					],
					"password":"******",
					"username":"dev",
					"where":""
				}
			},
			"writer":{
				"name":"gpdbwriter",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":"jdbc:postgresql://*********:5432/**",
							"table":[
								"**********"
							]
						}
					],
					"password":"******",
					"postSql":[],
					"preSql":[
						"**********"
					],
					"segment_reject_limit":0,
					"username":"admin"
				}
			}
		}
	],
	"setting":{
		"speed":{
			"channel":"1"
		}
	}
}

  通过测试,1715万条数据355秒

而如果是mysql导入到hdfs,通过测试,1715万条数据211秒

可以看到,使用该版本的datax,导入还是非常快的。

坑:

在往hdfs上导数据时,需要提前将hdfs的目录路径建好,如果路径不存在,会报任务失败。

 

最大的一个坑下面一个。事情是这样的:

我需要测试一下sqlserver导数据到GP。然而,公司的测试环境中没有sqlserver,所以我在本机中装了一个。

当时装的是sqlserver2005,具体的job的json文件如下:

{
	"content":[
		{
			"reader":{
				"name":"mysqlreader",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":[
								"jdbc:mysql://*********:3306/******?characterEncoding=utf8"
							],
							"table":[
								"******"
							]
						}
					],
					"password":"****************",
					"username":"dev",
					"where":""
				}
			},
			"writer":{
				"name":"sqlserverwriter",
				"parameter":{
					"column":[
						"*"
					],
					"connection":[
						{
							"jdbcUrl":"jdbc:sqlserver://**********:1433;DatabaseName=sjtb",
							"table":[
								"*********"
							]
						}
					],
					"password":"**",
					"username":"sa"
				}
			}
		}
	],
	"setting":{
		"speed":{
			"channel":"1"
		}
	}
}

  在job执行的过程中,出现如下问题:

 

 

 当时我的磁盘空间还有200多个G,所以该问题大概的原因是SQL数据库日志文件满了导致的。结果却让人很意外:

 

 

 当任务有57万条数据失败时,整个job任然显示success,这样就不会触发邮件报警。这个本身应该是sqlserverver2005的一个限制,需要更换sqlserver的版本到2008就可以了,但是,我们也需要datax做点什么来防止这种情况下任务依旧成功

这里需要配置的是datax的errorlimit

 

 

job.setting.errorLimit(脏数据控制)

Job支持用户对于脏数据的自定义监控和告警,包括对脏数据最大记录数阈值(record值)或者脏数据占比阈值(percentage值),当Job传输过程出现的脏数据大于用户指定的数量/百分比,DataX Job报错退出。

上图中的配置的意思是当脏数据大于10条,或者脏数据比例达到0.05%,任务就会报错

 

转载于:https://www.cnblogs.com/tianyafu/p/9945603.html

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值