kettle 运行这样的错怎么办？

因为kettle70是基于jdk18的，所以你用17的时候会报错，你可以运行SpoonDebugbat，把完整的报错输出出来。
然后18 已经不支持MaxPermSize，所以你要在Spoonbat中把XX:MaxPermSize修改为MaxMetaspaceSize。

Kettle插入/更新的组件在日常的抽取任务中使用频率相当的高，自己对这部分的了解也仅限于输出中的“插入/更新”。最近公司正在开展BI数据仓库建设，Kettle中输出部分的“ 插入/更新 ”和数据仓库菜单中的“ 维度查询/更新 ”存在使用上的差异，因此下面主要介绍这两组件应用的情况。

如下图，把该组件划分为三个部分，第一部分为组件属性定义，第二部分为Keys，第三部分为Fields。

1、目标模式：即Schema，对应表的所属拥有对象

2、不执行任何更新：如果勾选，则只根据查询匹配结果进行插入 *** 作；未勾选，则执行更新和插入 *** 作；

该部分为查询匹配条件，需根据具体业务场景进行设置定义。其中，表字段即属性定义中的目标表；流里的字段X即整个Transactions数据流中最后输出的字段；

只有当Keys部分中的所有匹配结果为True时，才算是匹配成功；如果其中一个或多个匹配条件为False时，则为匹配失败。

该部分为包含两个作用：1、匹配表字段与流字段；2、判断是更新表字段还是插入表字段；如果“不行执行更新”勾选了，则均执行插入 *** 作，Keys域无意义。当未勾选时，包含以下情况：

此时不管Fields域中“更新”字段是Y or N，都执行插入 *** 作。

(1)当Fields域中所有字段匹配相同时，则不做更新、插入

(2)当Fields域中存在字段匹配不一致时，则会对字段继续进行更新。如果字段“更新”属性为Y则更新，为N则不更新。

综上，该组件基本可以应对所有数据的“插入/更新” *** 作。

该组件主要涉及数据仓库中的缓慢变化维的概念。缓慢变化维，是由于维度在实际业务场景中并不是静态的，只是会随着时间发生缓慢的变化，相比于事实表或者业务表，主要区别在于维度表变化慢，频率低，特定场景下需要记录数据变化的过程。具体的说明及应用场景，可通过各类搜索引擎查找，资料较为丰富。

如下图，维度查询/更新组件可分为四个部分，第一部分为组件属性定义，第二部分为keys和Fields，第三部分同为数据记录的属性定义。

1、更新维度：如果勾选，则进行插入/更新 *** 作；如果未勾选，则该组件仅作查询用途，查询条件：a、keys域中的对比字段；b、第三部分记录域中时间流查询条件，开始日期<=stream日期字段<=截止日期字段

2、使用缓存：使用缓存目的为了提升插入或更新的效率，该选项和“缓存行数”同步使用

此部分尽讨论组件属性“更新维度”勾选的情况，未勾选的情况已上面阐述。

在第二部分，Keys域为查询条件，Fields域为更新插入区域。

此时无论Fields中更新属性的值如何，都执行插入 *** 作；

 (a)Fields字段中存在不同项，且更新属性为插入选项，则插入一条新数据行记录

 (b)Fields字段中存在不同项，且更新属性为‘punch through',则所有version版本的数据记录都会发生更新

 (c)Fields字段中存在不同项，且更新属性为'update'，则最后一个version记录的属性发生更新

 (d)Fields字段中所有都相同，则不发生变化。

1、代理关键字段：由于会记录数据变化的历史过程信息，因此需在表设计初期定义代理键

2、version字段：每次keys相同的记录发生新增时，version字段自动+1，最大的verison为最新的记录

3、stream日期字段：记录数据流的日期范围，通常为设置为开始日期字段值即可。

4、开始日期字段：数据流导入的开始日期

5、结束日期字段：数据流导入结束日期

综上，如使用“维度查询/更新”组件最好的应用场景是维度表需要记录历史变化数据时，并非所有维度表都需要使用该组件。同时，在决定使用“维度查询/更新”组件时，至少需定义四个字段：KEYS_SEQ_ID(代理键)、VERSION_NO(版本号)、BEGIN_DATE(开始日期)、END_DATE(结束日期)。正常非特殊需求时，使用“插入/更新”组件即可。

但是在以上的介绍过程中可以发现，在该组件中并没有 时间戳的利用 ，即Keys域在做比较时，是 把Transaction流中的数据和维度表中的所有数据进行核对 ，需考虑在对比核对中可能存在的性能问题。

以上，如有说明错误或不明白之处，烦请指出。

在kettle常常有处理从一个源数据中做转换做转换的时候, 需要去查另一个数据库
这种问题遇到数据小时候还好办 但是数据魇 时候就麻烦来了
下面针对三种情况做具体情况的选择办法
1 当需要转换的数据特别大的时候, 例如: 10W条以上或者100W条以上时
上图中,hadoop数据导入,导入的数据如果够多,例如100W条以上,其中一个字段需要查询数据库中查询,而这个字段的类型并不多,例如只有10个类
型或者数据库中就只有这10个类型那么,可以走线路2, 并且线路2中的 "使用缓存"
可以打勾,也可以不打当然你这个源里的数据太多,打上当然最好了因为省得再去你的数据库里再查
但是当源里的数据类型还是只有10个类型,但是你的数据库里面存了有10000条记录时,怎么办
有两种解决办法:
1)线路2:并且查询节点中的 "使用缓存" 不能打勾
2)线路1,并在"带条件的结果查询供流查询使用" 这个结点中,用一个SQL,过滤一下数据,然后尽可能地把那里包括的这些记录查出来这样在流里的比对时也很快很多必竟是在内存里做运算了
2 查另一个数据库的数据量大时,而你的源数据不大
最好的选择是
线路1,并在"带条件的结果查询供流查询使用" 这个结点中,用一个SQL,过滤一下数据,然后尽可能地把那里包括的这些记录查出来这样在流里的比对时也很快很多必竟是在内存里做运算了
3 当两个数据源都非常大时(最不想遇到的)
这种情况是最不想遇到的办法
一种选择:
1)线路2中的 "使用缓存" 打勾

---