Kettle的一些常见问题

摘要：本文主要介绍使用kettle设计一些ETL任务时一些常见问题，这些问题大部分都不在官方FAQ上，你可以在kettle的论坛上找到一些问题的答案
　　1. Join

　　我得到A 数据流（不管是基于文件或数据库），A包含field1 ， field2 ， field3 字段，然后我还有一个B数据流，B包含field4 ， field5 ， field6 ， 我现在想把它们 ‘加’ 起来， 应该怎么样做.

　　这是新手最容易犯错的一个地方，A数据流跟B数据流能够Join，肯定是它们包含join key ，join key 可以是一个字段也可以是多个字段。如果两个数据流没有join key ，那么它们就是在做笛卡尔积，一般很少会这样。比如你现在需要列出一个员工的姓名和他所在部门的姓名，如果这是在同一个数据库，大家都知道会在一个sql 里面加上where 限定条件，但是如果员工表和部门表在两个不同的数据流里面，尤其是数据源的来源是多个数据库的情况，我们一般是要使用Database Join 操作，然后用两个database table input 来表示输入流，一个输入是部门表的姓名，另一个是员工表的姓名，然后我们认为这两个表就可以 ”Join” 了，我们需要的输出的确是这两个字段，但是这两个字段的输出并不代表只需要这两个字段的输入，它们之间肯定是需要一个约束关系存在的。另外，无论是在做Join ， Merge ， Update ， Delete 这些常规操作的时候，都是先需要做一个compare 操作的，这个compare 操作都是针对compare key 的，无论两个表结构是不是一样的，比如employee 表和department 表，它们比较的依据就是employee 的外键department_id ， 没有这个compare key 这两个表是不可能连接的起来的.. 对于两个表可能还有人知道是直接sql 来做连接，如果是多个输入数据源，然后是三个表，有人就开始迷茫了，A表一个字段，B表一个字段，C表一个字段，然后就连Join操作都没有，直接database table output ， 然后开始报错，报完错就到处找高手问，他们的数据库原理老师已经在吐血了。如果是三个表连接，一个sql 不能搞定，就需要先两个表两个表的连接，通过两次compare key 连接之后得到你的输出，记住，你的输出并不能代表你的输入. 下面总结一下:

　　1. 单数据源输入，直接用sql 做连接

　　2. 多数据源输入，（可能是文本或是两个以上源数据库），用database join 操作.

　　3. 三个表以上的多字段输出.

　　2. Kettle的数据库连接模式

　　Kettle的数据库连接是一个步骤里面控制一个单数据库连接，所以kettle的连接有数据库连接池，你可以在指定的数据库连接里面指定一开始连接池里面放多少个数据库连接，在创建数据库连接的时候就有Pooling 选项卡，里面可以指定最大连接数和初始连接数，这可以一定程度上提高速度.

　　3. transaction

　　我想在步骤A执行一个操作（更新或者插入），然后在经过若干个步骤之后，如果我发现某一个条件成立，我就提交所有的操作，如果失败，我就回滚，kettle提供这种事务性的操作吗？

　　Kettle里面是没有所谓事务的概念的，每个步骤都是自己管理自己的连接的，在这个步骤开始的时候打开数据库连接，在结束的时候关闭数据库连接，一个步骤是肯定不会跨session的（数据库里面的session）， 另外，由于kettle是并行执行的，所以不可能把一个数据库连接打开很长时间不放，这样可能会造成锁出现，虽然不一定是死锁，但是对性能还是影响太大了。ETL中的事务对性能影响也很大，所以不应该设计一种依赖与事务方式的ETL执行顺序，毕竟这不是OLTP，因为你可能一次需要提交的数据量是几百GB都有可能，任何一种数据库维持一个几百GB的回滚段性能都是会不大幅下降的.

　　4. 我真的需要transaction 但又不想要一个很复杂的设计，能不能提供一个简单一点的方式

　　Kettle 在3.0.2GA版中将推出一种新功能，在一个table output 步骤中有一个Miscellaneous 选项卡，其中有一个Use unique connections 的选项，如果你选中的话就可以得到一个transaction 的简单版，

　　由于是使用的单数据库连接，所以可以有错误的时候回滚事务，不过要提醒一点是这种方式是以牺牲非常大的性能为前提条件的，对于太大的数据量是不适合的(个人仍然不建议使用这种方式)

　　5. temporary 表如何使用

　　我要在ETL过程中创建一个中间表，当某个条件成立的时候，我要把中间表的数据进行转换，当另一条件成立的时候我要对中间表进行另一个操作，我想使用数据库的临时表来操作，应该用什么步骤。

　　首先从temp 表的生命周期来分，temp分为 事务临时表和会话临时表，前面已经解释过了，kettle是没有所谓事务的概念的，所以自然也没有所谓的事务临时表。Kettle的每个步骤管理自己的数据库连接，连接一结束，kettle也就自然丢掉了这个连接的session 的handler ， 没有办法可以在其他步骤拿回这个session 的handler ， 所以也就不能使用所谓的会话临时表，当你尝试再开一个连接的时候，你可以连上这个临时表，但是你想要的临时表里面的数据都已经是空的(数据不一定被清除了，但是你连不上了)，所以不要设计一个需要使用临时表的转换

　　之所以会使用临时表，其实跟需要 ”事务” 特性有一点类似，都是希望在ETL过程中提供一种缓冲。临时表很多时候都不是某一个源表的全部数据的镜像，很多时候临时表都是很小一部分结果集，可能经过了某种计算过程，你需要临时表无非是基于下面三个特性：

　　1. 表结构固定，用一个固定的表来接受一部分数据。

　　2. 每次连接的时候里面没有数据。你希望它接受数据，但是不保存，每次都好像执行了truncate table 操作一样

　　3. 不同的时候连接临时表用同一个名字，你不想使用多个连接的时候用类似与temp1 ， temp2 ， temp3 ， temp4 这种名字，应为它们表结构一样。

　　既然临时表不能用，应该如何设计ETL过程呢？（可以用某种诡异的操作搞出临时表，不过不建议这样做罢了）

　　如果你的ETL过程比较的单线程性，也就是你清楚的知道同一时间只有一个这样的表需要，你可以创建一个普通的表，每次连接的时候都执行truncate 操作，不论是通过table output 的truncate table 选项，还是通过手工执行truncate table sql 语句（在execute sql script 步骤）都可以达到目的（基于上面的1，2 特性）

　　如果你的ETL操作比较的多线程性，同一时间可能需要多个表结构一样并且里面都是为空的表（基于上面1，2，3特性），你可以创建一个 “字符串+序列”的模式，每次需要的时候，就创建这样的表，用完之后就删除，因为你自己不一定知道你需要多少个这种类型的表，所以删除会比truncate 好一些。

　　下面举个例子怎么创建这种表：

　　你可以使用某种约定的表名比如department_temp 作为department 的临时表。或者

　　把argument 传到表名，使用 department_${argument} 的语法，

　　如果你需要多个这种表，使用一个sequence 操作+execute sql script 操作，execute sql script 就下面这种模式

　　Create table_?(…………..)

　　在表的名字上加参数，前面接受一个sequence 或类似的输入操作.

　　需要注意的是这种参数表名包括database table input 或者execute sql script ，只要是参数作为表名的情况前面的输入不能是从数据库来的，应为没有办法执行这种preparedStatement语句，从数据库来的值后面的操作是 “值操作” ，而不是字符串替换，只有argument 或者sequence 操作当作参数才是字符串替换. (这一点官方FAQ也有提到)

　　6. update table 和execute sql script 里面执行update 的区别

　　执行update table 操作是比较慢的，它会一条一条基于compare key 对比数据，然后决定是不是要执行update sql ， 如果你知道你要怎么更新数据尽可能的使用execute sql script 操作，在里面手写update sql （注意源数据库和目标数据库在哪），这种多行执行方式（update sql）肯定比单行执行方式（update table 操作）快的多。

　　另一个区别是execute sql script 操作是可以接受参数的输入的。它前面可以是一个跟它完全不关的表一个sql :

　　select field1， field2 field3 from tableA

　　后面执行另一个表的更新操作：

　　update tableB set field4 = ? where field5=? And field6=?

　　然后选中execute sql script 的execute for each row .注意参数是一一对应的.(field4 对应field1 的值，

　　field5 对应field2 的值， field6 对应field3 的值)

　　7. kettle的性能

　　kettle本身的性能绝对是能够应对大型应用的，一般的基于平均行长150的一条记录，假设源数据库，目标数据库以及kettle都分别在几台机器上（最常见的桌面工作模式，双核，1G内存），速度大概都可以到5000 行每秒左右，如果把硬件提高一些，性能还可以提升 ， 但是ETL 过程中难免遇到性能问题，下面一些通用的步骤也许能给你一些帮助.

　　尽量使用数据库连接池

　　尽量提高批处理的commit size

　　尽量使用缓存，缓存尽量大一些（主要是文本文件和数据流）

　　Kettle 是Java 做的，尽量用大一点的内存参数启动Kettle.

　　可以使用sql 来做的一些操作尽量用sql

　　Group ， merge ， stream lookup ，split field 这些操作都是比较慢的，想办法避免他们.，能用sql 就用sql

　　插入大量数据的时候尽量把索引删掉

　　尽量避免使用update ， delete 操作，尤其是update ， 如果可以把update 变成先delete ，后insert .

　　能使用truncate table 的时候，就不要使用delete all row 这种类似sql

　　合理的分区

　　如果删除操作是基于某一个分区的，就不要使用delete row 这种方式（不管是delete sql 还是delete 步骤），直接把分区drop 掉，再重新创建

　　尽量缩小输入的数据集的大小（增量更新也是为了这个目的）

　　尽量使用数据库原生的方式装载文本文件(Oracle 的sqlloader ， mysql 的bulk loader 步骤)

　　尽量不要用kettle 的calculate 计算步骤，能用数据库本身的sql 就用sql ，不能用sql 就尽量想办法用procedure ， 实在不行才是calculate 步骤.

　　要知道你的性能瓶颈在哪，可能有时候你使用了不恰当的方式，导致整个操作都变慢，观察kettle log 生成的方式来了解你的ETL操作最慢的地方。

　　远程数据库用文件+FTP 的方式来传数据 ，文件要压缩。（只要不是局域网都可以认为是远程连接）

　　8. 描述物理环境

　　源数据库的操作系统，硬件环境，是单数据源还是多数据源，数据库怎么分布的，做ETL的那台机器放在哪，操作系统和硬件环境是什么，目标数据仓库的数据库是什么，操作系统，硬件环境，数据库的字符集怎么选，数据传输方式是什么，开发环境，测试环境和实际的生产环境有什么区别，是不是需要一个中间数据库(staging 数据库) ，源数据库的数据库版本号是多少，测试数据库的版本号是多少，真正的目标数据库的版本号是多少……. 这些信息也许很零散，但是都需要一份专门的文档来描述这些信息，无论是你遇到问题需要别人帮助的时候描述问题本身，还是发现测试环境跟目标数据库的版本号不一致，这份专门的文档都能提供一些基本的信息

　　9. procedure

　　为什么我不能触发procedure?

　　这个问题在官方FAQ里面也有提到，触发procedure 和 http client 都需要一个类似与触发器的条件，你可以使用generate row 步骤产生一个空的row ，然后把这条记录连上procedure 步骤，这样就会使这条没有记录的空行触发这个procedure (如果你打算使用无条件的单次触发) ，当然procedure 也可以象table input 里面的步骤那样传参数并且多次执行.

　　另外一个建议是不要使用复杂的procedure 来完成本该ETL任务完成的任务，比如创建表，填充数据，创建物化视图等等.

　　10. 字符集

　　Kettle使用Java 通常使用的UTF8 来传输字符集，所以无论你使用何种数据库，任何数据库种类的字符集，kettle 都是支持的，如果你遇到了字符集问题，也许下面这些提示可以帮助你：

　　1. 单数据库到单数据库是绝对不会出现乱码问题的，不管原数据库和目标数据库是何种种类，何种字符集

　　2. 多种不同字符集的原数据库到一个目标数据库，你首先需要确定多种源数据库的字符集的最大兼容字符集是什么，如果你不清楚，最好的办法就是使用UTF8来创建数据库.

　　3. 不要以你工作的环境来判断字符集：现在某一个测试人员手上有一个oracle 的基于xxx 字符集的已经存在的数据库，并且非常不幸的是xxx 字符集不是utf8 类型的，于是他把另一个基于yyy字符集的oracle 数据库要经过某一个ETL过程转换到oracle ， 后来他发现无论怎么样设置都会出现乱码，这是因为你的数据库本身的字符集不支持，无论你怎么设置都是没用的. 测试的数据库不代表最后产品运行的数据库，尤其是有时候为了省事把多个不同的项目的不相关的数据库装在同一台机器上，测试的时候又没有分析清楚这种环境，所以也再次强调描述物理环境的重要性.

　　4. 你所看到的不一定代表实际储存的：mysql 处理字符集的时候是要在jdbc 连接的参数里面加上字符集参数的，而oracle 则是需要服务器端和客户端使用同一种字符集才能正确显示，所以你要明确你所看到的字符集乱码不一定代表真的就是字符集乱码，这需要你检查在转换之前的字符集是否会出现乱码和转换之后是否出现乱码，你的桌面环境可能需要变动一些参数来适应这种变动

　　5. 不要在一个转换中使用多个字符集做为数据源.

　　11. 预定义时间维

　　Kettle提供了一个小工具帮助我们预填充时间维，这个工具在kettle_home / samples / transformations / General – populate date dimension. 这个示例产生的数据不一定能满足各种需要，不过你可以通过修改这个示例来满足自己的需求.

　　12. SQL tab 和 Options tab

　　在你创建一个数据库连接的时候除了可以指定你一次需要初始化的连接池参数之外（在Pooling 选项卡下面），还包括一个Options 选项卡和一个 SQL 选项卡， Options 选项卡里面主要设置一些连接时的参数，比如autocommit 是on 还是off ， defaultFetchSize ， useCursorFetch (mysql 默认支持的)，oracle 还支持比如defaultExecuteBatch ， oracle.jdbc.StreamBufferSize， oracle.jdbc.FreeMemoryOnEnterImplicitCache ，你可以查阅对应数据库所支持的连接参数，另外一个小提示：在创建数据库连接的时候，选择你的数据库类型，然后选到Options 选项卡，下面有一个Show help text on options usage ， 点击这个按钮会把你带到对应各个数据库的连接参数的官方的一个参数列表页面，通过查询这个列表页面你就可以知道那种数据库可以使用何种参数了.

　　对于SQL 选项卡就是在你一连接这个Connection 之后，Kettle 会立刻执行的sql 语句，个人比较推荐的一个sql 是执行把所有日期格式统一成同一格式的sql ，比如在oracle 里面就是:

　　alter session set nls_date_format = xxxxxxxxxxxxx

　　alter session set nls_xxxxxxxxx = xxxxxxxxxxxx

　　这样可以避免你在转换的时候大量使用to_date() ， to_char 函数而仅仅只是为了统一日期格式，对于增量更新的时候尤其适用.

　　13. 数据复制

　　有的时候可能我们需要的是类似数据复制或者一个备份数据库，这个时候你需要的是一种数据库私有的解决方案，Kettle 也许并不是你的第一选择，比如对于Oracle 来说，可能rman ， oracle stream ， oracle replication 等等， mysql 也有mysql rmaster / slave 模式的replication 等私有的解决方法，如果你确定你的需求不是数据集成这方面的，那么也许kettle 并不是一个很好的首选方案，你应该咨询一下专业的DBA人士也会会更好.

　　14. 如何控制版本变更

　　Kettle 的每一个transformation 和job 都有一个version 字段（在你保存的时候）， 不过这个功能还不实用，如果你需要版本控制的话，还是建议你将transformation 和job 转换成文本文件保存，然后用svn 或cvs 或任意你熟悉的版本控制系统将其保存，kettle 将在下一个版本加入版本控制的功能（做的更易用）.

　　15. 支持的数据源

　　Kettle 支持相当广的数据源，比如在数据库里面的一些不太常见的Access ， MaxDB (SAP DB) ， Hypersonic ， SAP R/3 system ， Borland Interbase ， Oracle RDB ， Teradata和3.0新加入的Sybase IQ .

　　另外还包括Excel ， CSV ， LDAP ，以及OLAP Server Mondrian ， 目前支持Web Service 不过暂时还不支持SOAP.

　　16. 调试和测试

　　当ETL转换出现不可预知的问题时，或是你不清楚某个步骤的功能是什么的情况下，你可能需要创建一个模拟环境来调适程序，下面一些建议可能会有所帮助：

　　尽量使用generate row 步骤或者固定的一个文本文件来创建一个模拟的数据源

　　模拟的数据源一定要有代表性，数据集一定尽量小（为了性能考虑）但是数据本身要足够分散.

　　创建了模拟的数据集后你应该清楚的知道你所要转换之后的数据时什么样的.

　　17. 错误处理

　　在ETL任务中由于数据问题出现转换错误是一件非常正常的事情，你不应该设计一个依赖于临时表或者拥有事务特点的ETL过程，面对数据源质量问题的巨大挑战，错误处理是并不可少的，kettle同样提供非常方便的错误处理方式，在你可能会出错的步骤点击右键选择Define Error handing ， 它会要求你指定一个处理error 的步骤，你可以使用文本文件或者数据库的表来储存这些错误信息，这些错误信息会包含一个id 和一个出错的字段，当你得到这些错误信息之后就需要你自己分析出错的原因了，比如违反主键约束可能是你生成主键的方式有错误或者本身的数据有重复，而违反外键约束则可能是你依赖的一些表里面的数据还没有转换或者外键表本身过滤掉了这些数据. 当你调整了这些错误之后，确定所有依赖的数据都被正确的处理了.kettle user guide 里面有更详细的解释，里面还附带了一个使用javascript 来处理错误的示例，这种方式可以作为处理简单数据质量的方式.

　　18. 文档，文档，文档

　　Kettle 提供了丰富的文档和使用手册，小到一个数据库连接怎么连，大到一个功能怎么实现，所有的参数列表，对话框的每一个输入输出代表什么意思都有解释，所以当你遇到问题你应该第一时间翻阅这些文档，也许上面已经告诉你怎么做了. 另外kettle 还有一个非常活跃的社区，你可以到上面提问，但是记住在你提问之前先搜索一下论坛看有没有类似的问题已经问过了，如果没有记得描述清楚你的问题

　　总结

　　本系列文章主要讨论了如何使用kettle 来处理数据仓库中的缓慢增长维，动态ETL如何设计，增量更新的一些设计技巧，在应用程序中如何集成kettle 以及在使用kettle 时的一些常见问题. 如果你正在寻找一个工具来帮助你解决数据库的集成问题或是你打算建立一个商业智能项目的数据仓库，那么kettle是一个不错的选择，你不用支付任何费用就可以得到很多很多数据集成的特性，大量文档和社区支持. 难道这些不就是你希望从一个商业工具上的到的吗？还在等什么 ，开始你的数据集成之旅吧