Pentaho组合查找/更新未处理全部源行问题求助

我来帮你梳理下这个问题的排查和解决思路——这是PDI里使用Combination Lookup/Update组件时很常见的一个坑，别着急，咱们一步步来：

1. 先检查组件的「最大检索行数」设置 #

这大概率是问题的根源！默认情况下，Combination Lookup/Update组件的Maximum rows to retrieve（最大检索行数）默认值就是10000，刚好和你遇到的处理行数完全匹配。

修改方法很简单：

• 双击打开Combination Lookup/Update组件
• 切换到「Lookup」标签页
• 找到「Maximum rows to retrieve」选项，把数值改成比你的源数据行数更大的数（比如直接填20000，或者填0表示无限制）
• 保存配置后重新运行作业试试

2. 确认缓存模式的配置是否正确 #

你设置的缓存大小99999已经远大于源数据的19763行，这没问题，但要确保缓存模式选对了：

• 同样在「Lookup」标签页里，找到「Cache type」（缓存类型）
• 选择「Load all data into cache」（将所有数据加载到缓存），而不是「Use LRU cache」
• 这个模式会一次性把维度表的全部数据加载到内存缓存中，能保证所有源记录都能匹配到对应的代理键，不会因为LRU缓存的淘汰机制导致部分记录被跳过

3. 排查源数据输入环节的限制 #

有时候问题不在Lookup组件本身，而是源数据读取时就被限制了行数：

• 打开你的源表输入步骤（比如Table Input）
• 仔细检查SQL语句，看看末尾是不是不小心加了LIMIT 10000这样的限制条件
• 如果有，删掉这个限制，确保能读取到全部19763行数据

4. 验证提交大小的配置逻辑 #

你设置的提交大小100000是合理的（远大于源数据量），但还是要确认下配置是否生效：

• 切换到Combination Lookup/Update的「Options」标签页，确认「Commit size」确实是100000
• 另外，也可以检查下数据库连接的批量提交设置，不过这个一般不会导致刚好只处理10000行的问题

如果以上步骤都试过还是没解决，建议把PDI的日志级别调到「Detailed」，查看Combination Lookup/Update组件的日志输出——日志里会明确显示读取的行数、匹配成功的行数、插入/更新的行数，通过这些信息就能精准定位是哪一步出现了数据截断。

内容的提问来源于stack exchange，提问作者Kuldip.Das