kettle经验篇：数据同步限制问题处理研究

项目场景

IT人的苦命之处在于：这一周其实我都在调休，但项目现场还是没有放过我。今天本来在思考该给老丈人丈母娘买什么见面礼，项目现场的甲方突然来了一电话：某个ETL的同步卡住了，啥原因？

我：怎么个卡住？

甲方：kettle转换中的过滤记录组件之前的数据同步正常；但在过滤记录组件开始，数据量达到20000时，同步就卡在这里，卡了一个半小时还没有结束。（如下图）

过滤记录组件

出问题转换的步骤度量

问题分析

从上面的截图中可以看到过滤记录这个步骤开始卡住了（虽然我打马赛克了，但是我告诉你们了嘿嘿）。

出问题的这个kettle转换，当时肯定是经过测试才上线的。所以可以排除在语法上或者在整体转换框架逻辑上的问题。

我们再仔细看开始卡住的这条记录，从20000开始，数据同步就停滞了。据现场甲方描述，20000这个数值持续了已经一个多小时了。

那么可以开始怀疑，这个kettle转换是受到了某个参数限制。

所以首先双击转换空白处，查看转换属性。我们可以看到在【杂项】模块，有个 “ 记录集合里的记录数” 参数，这里设置的是10000。我们将它改成30000。

可以提前和大家汇报的是：改完此参数，问题已经解决了。

问题总结

这次的问题其实是个很简单的问题。是kettle为了避免单个转换本身同步的数据量过大影响到整体资源的所设置的一个限制，当达到了限制时，转换就会卡住。

但如果我们已经清楚资源够用，且数据同步就是在这个数据量时效率相对最高的情况下，是可以适当修改该参数的。

现在可能会有朋友在疑惑一个问题：

为什么过滤组件前面的数据已经超过2万了，但却没有受到限制。

这个问题，就需要大家整体的去观察这个转换了，大家请看下图：

数字1是数据库查询组件，数字2是过滤组件和空操作；数字3是 在内存中分组 组件 。数字3的组件是要对前面的所有数据进行分组处理，但此时转换的限制是只能处理10000条数据；所以大家也可以看结合上图看到此步骤就卡在10000条数据。

所以我们现在可以做出最后总结了：

【杂项】模块中的 “ 记录集合里的记录数” 参数 不会限制数据库组件查询出的记录数，但会限制转换实际处理的记录数。