因为公司需要使用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%,任务就会报错