|
执行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 的值)
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 的方式来传数据 ，文件要压缩。（只要不是局域网都可以认为是远程连接）
描述物理环境
源数据库的操作系统，硬件环境，是单数据源还是多数据源，数据库怎么分布的，做ETL的那台机器放在哪，操作系统和硬件环境是什么，目标数据仓库的数据库是什么，操作系统，硬件环境，数据库的字符集怎么选，数据传输方式是什么，开发环境，测试环境和实际的生产环境有什么区别，是不是需要一个中间数据库(staging 数据库) ，源数据库的数据库版本号是多少，测试数据库的版本号是多少，真正的目标数据库的版本号是多少……. 这些信息也许很零散，但是都需要一份专门的文档来描述这些信息，无论是你遇到问题需要别人帮助的时候描述问题本身，还是发现测试环境跟目标数据库的版本号不一致,这份专门的文档都能提供一些基本的信息
procedure
为什么我不能触发procedure?
这个问题在官方FAQ里面也有提到，触发procedure 和 http client 都需要一个类似与触发器的条件，你可以使用generate row 步骤产生一个空的row,然后把这条记录连上procedure 步骤，这样就会使这条没有记录的空行触发这个procedure (如果你打算使用无条件的单次触发) ，当然procedure 也可以象table input 里面的步骤那样传参数并且多次执行.
另外一个建议是不要使用复杂的procedure 来完成本该ETL任务完成的任务，比如创建表，填充数据，创建物化视图等等.
字符集
Kettle使用Java 通常使用的UTF8 来传输字符集，所以无论你使用何种数据库，任何数据库种类的字符集，kettle 都是支持的，如果你遇到了字符集问题，也许下面这些提示可以帮助你：
1. 单数据库到单数据库是绝对不会出现乱码问题的，不管原数据库和目标数据库是何种种类，何种字符集
2. 多种不同字符集的原数据库到一个目标数据库，你首先需要确定多种源数据库的字符集的最大兼容字符集是什么，如果你不清楚，最好的办法就是使用UTF8来创建数据库.
3. 不要以你工作的环境来判断字符集：现在某一个测试人员手上有一个oracle 的基于xxx 字符集的已经存在的数据库，并且非常不幸的是xxx 字符集不是utf8 类型的，于是他把另一个基于yyy字符集的oracle 数据库要经过某一个ETL过程转换到oracle,后来他发现无论怎么样设置都会出现乱码，这是因为你的数据库本身的字符集不支持，无论你怎么设置都是没用的. 测试的数据库不代表最后产品运行的数据库，尤其是有时候为了省事把多个不同的项目的不相关的数据库装在同一台机器上，测试的时候又没有分析清楚这种环境，所以也再次强调描述物理环境的重要性.
4. 你所看到的不一定代表实际储存的：mysql 处理字符集的时候是要在jdbc 连接的参数里面加上字符集参数的，而oracle 则是需要服务器端和客户端使用同一种字符集才能正确显示，所以你要明确你所看到的字符集乱码不一定代表真的就是字符集乱码，这需要你检查在转换之前的字符集是否会出现乱码和转换之后是否出现乱码，你的桌面环境可能需要变动一些参数来适应这种变动
5. 不要在一个转换中使用多个字符集做为数据源.
预定义时间维 （编辑：厦门站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
