执行转换时如何让Kettle记录错误并继续执行?——记一种解决方案

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_22073849/article/details/71809243

  如题,近几天在利用Kettle进行数据迁移的工作(也就是把数据全量导入到新数据库中,其中有些字段有些许调整),在写好脚本并执行后发现一个很严重的问题——每次脚本在执行到某个位置的时候就会意外停止,如下两图所示

这里写图片描述
这里写图片描述

而自带的日志中提示类似如下:

2017/05/12 14:43:07 - 表输出.0 - ORA-12592: TNS: 包错误

2017/05/12 11:37:46 - 表输出。0 Caused by : java.sql.BatchUpdateException: ORA-01438:值大于为此列指定的允许精度

  百度谷歌了一下这种错误,是属于Oracle的错误,在关于kettle的提问当中也有人遇到类似错误,但是在楼下回复的内容中并没有找到太多有用的信息。
  
  所以猜想其中可能有部分数据是“脏数据”,导致插入到新数据库中时报错,至于图中在表输出时数量都是整百是因为在脚本的“表输出”环节中设置了默认为1000条提交一次,也就是1000条commit一次,而当这一千条中有数据插不进去的时候,当然会报错了,那么我们现在大概知道了错误的原因,我们要想怎么解决它……

  下面有两个疑问:

  • 我怎么能越过错误数据并记录下来直接进行下面数据的提交
  • 我怎么能找出来这些错误数据?具体到每条?

      后来专程因为这个去我的两个kettle群里问了一下,结果有一个人回答了我说让我用日志,后来私聊他问具体情况的时候他过半小时没回我于是我用出了杀手锏——给红包,把我QQ钱包里仅有的四块钱塞在了里面,这样他处于好奇心一定会点开,那么在中国,拿了钱你还能不办事吗(滑稽),虽然最后他也没有给出特别有建设性的建议,但是我修改了一下脚本,至少解决了出了错就越过的需求

    这里写图片描述
    这里我们看到了表输入的地方输入时有28W,是因为我中间进行强制暂停了,实际上源数据大概有128W
    我在后面加了这个 表输入的地方填的是500 现在空操作里有31000条数据 就是大概有至少62个错误 ,也就是说现在的这个脚本可以实现的功能就是—— 遇到错误可以略过,但是连同错误数据一起提交的其他数据也上传不了
      这当然也不是我们想要的
    因为在使用kettle的转换过程中 我们发现在连接每两个步骤的时候如果慢一点松开鼠标我们是可以看到有输出步骤和错误输出步骤的选项,而后者就是为了我们这种需求而存在的,在这个步骤中一旦遇到了错误 ,我们可以让它去执行下面的语句。
      总结一下可以理解成:之前版本的没有错误处理的相当于只有一个if语句,那么如果一旦不满足 就跳出来报错,而我们第二种解决方案也就是上图 ,加了一个else功能,如果不满足,那么还有备选,或者这里理解成一个try块也是一样的。
      那么我们是不是可以继续增加功能呢 比如把下面的空操作换成别的 比如。。。日志?
      但是在接下来的实践中,kettle转换中的“写日志”步骤貌似是要链接数据库的,那么问题就来了,我只是想知道这些错误数据是哪些,然后找出来,改正它,再导入到新的数据库而已,我为了找出这几个错误数据还要建表??,想想公司配的电脑,想想链接Oracle时那缓慢的速度于是瞬间打消了念头,。。
      那么。。。

我们为啥不在它后面加上别的输出呢,比如txt?excel???

于是我先使用了txt 并把日志类型设置成详细日志(其它的还有 没有日志 最小日志基本日志调试行级日志等),执行了一会后发现实在是太多太多了, ——瞬间清屏了,,一个可拉的滚动条只能看见两秒钟内的数据传输,而且包括输出成功的数据(真是够详细的=。=),而且txt在看数据的时候特别不方便,于是下面又用了错误日志 + excel输出
考虑到每次提交都会把连带一起commit的数据也扔掉,所以在“表输入”的时候选项改成了1,为了找出错误就是如此丧心病狂,已经无所谓效率了

这里写图片描述

这里写图片描述

最后如下

这里写图片描述

也就是这128W的数据中有62个脏数据来阻止我们正常进行数据迁移,好可恨啊!

这里写图片描述
  
那么我们下面只要好好分析一下这些脏数据到底是哪里出了问题,然后改正它们,最后再把所有的数据重新导入,问题就应该全部解决了。。


但是这里还有个最后的问题,这种解决方案是最优的吗?我们为了保证正确数据的不缺失而让每次提交的数据量为1 ,这样大大降低了效率,但是目前我还没有更好的解决方案,也不知道该问谁,但是最后看问题解决了就很好,如果有哪位大牛在看到这里,如果有更好的解决方案请与本人联系,本人一定虚心学习。

没有更多推荐了,返回首页