开源项目 Kettle 介绍 ZT
说到ETL开源项目，Kettle当属翘首，因此，偶决定花点时间了解一下。
项目名称很有意思，水壶。按项目负责人Matt的说法：把各种数据放到一个壶里，然后呢，以一种你希望的格式流出。呵呵，外国人都很有联想力。
看了提供的文档，然后对发布程序的简单试用后，可以很清楚得看到Kettle的四大块：
Chef——工作(job)设计工具 (GUI方式)
Kitchen——工作(job)执行器 (命令行方式)
Spoon——转换(transform)设计工具 (GUI方式)
Span——转换(trasform)执行器 (命令行方式)
嗯，厨师已经在厨房里，勺子和盘子一应俱全，且看能做出如何的大餐？
一：Chef——工作(job)设计器
这是一个GUI工具，操作方式主要通过拖拖拉拉，勿庸多言，一看就会。
何谓工作？ 多个作业项，按特定的工作流串联起来，开成一项工作。正如：我的工作是软件开发。我的作业项是：设计、编码、测试！先设计，如果成功，则编码，否则继续设计，编码完成则开始设计，周而复始，作业完成。
来，看看Chef中的作业项：
1.1： 转换：指定更细的转换任务，通过Spoon生成。通过Field来输入参数。
1.2： SQL：sql语句执行，
1.3： FTP：下载ftp文件。
1.4： 邮件：发送邮件。
1.5： 检查表是否存在，
1.6： 检查文件是否存在，
1.7： 执行shell脚本。如：dos命令。
1.8： 批处理。(注意：windows批处理不能有输出到控制台)。
1.9： Job包。作为嵌套作业使用。
1.10：JavaScript执行。这个比较有意思，我看了一下源码，如果你有自已的Script引擎，可以很方便的替换成自定义Script，来扩充其功能。
1.11：SFTP：安全的Ftp协议传输。
1.12：HTTP方式的上/下传。
好了，看看工作流：
如上文所述，工作流是作业项的连接方式。分为三种：无条件，成功，失败。这个没啥好说的，从名字就能知道它的意图。
嗯，为了方便工作流使用，提供了几个辅助结点单元(你也可将其作为简单的作业项)：
1：Start单元，任务必须由此开始。设计作业时，以此为起点。
2：OK单元：可以编制做为中间任务单元，且进行脚本编制，用来控制流程。
3：ERROR单元：用途同上。
4：DUMMY单元：啥都不做，主要是用来支持多分支的情况。文档中有例子，不再多说。
存储方式：
支持XML存储，或存储到指定数据库中。
一些默认的配置(如数据库存储位置……)，在系统的用户目录下，单独建立了一个.Kettle目录，用来保存用户的这些设置。
LogView：可查看执行日志。
二：Kitchen——作业执行器
是一个作业执行引擎，用来执行作业。这是一个命令行执行工具，没啥可讲的，就把它的参数说明列一下。
-rep : Repository name 任务包所在存储名
-user : Repository username 执行人
-pass : Repository password 执行人密码
-job : The name of the job to launch 任务包名称
-dir : The directory (don't forget the leading / or /)
-file : The filename (Job XML) to launch
-level : The logging level (Basic, Detailed, Debug, Rowlevel, Error, Nothing) 指定日志级别
-log : The logging file to write to 指定日志文件
-listdir : List the directories in the repository 列出指定存储中的目录结构。
-listjobs : List the jobs in the specified directory 列出指定目录下的所有任务
-listrep : List the defined repositories 列出所有的存储
-norep : Don't log into the repository 不写日志
嗯，居然不支持调度。看了一下文档，建议使用操作系统提供的调度器来实现调度，比如：Windows可以使用它的任务计划工具。
三：Spoon——转换过程设计器
GUI工作，用来设计数据转换过程，创建的转换可以由Pan来执行，也可以被Chef所包含，作为作业中的一个作业项。
下面简单列举一下所有的转换过程。(简单描述，详细的可见Spoon文档)
3.1：Input-Steps：输入步骤
3.1.1：Text file input：文本文件输入，
可以支持多文件合并，有不少参数，基本一看参数名就能明白其意图。
3.1.2：Table input：数据表输入
实际上是视图方式输入，因为输入的是sql语句。当然，需要指定数据源(数据源的定制方式在后面讲一下)
3.1.3：Get system info：取系统信息
就是取一些固定的系统环境值，如本月最后一天的时间，本机的IP地址之类。
3.1.4：Generate Rows：生成多行。
这个需要匹配使用，主要用于生成多行的数据输入，比如配合Add sequence可以生成一个指定序号的数据列。
3.1.5：XBase Input：
3.1.6：Excel Input：
3.1.7：XML Input：
这三个没啥可讲的，看看参数就明了。
3.2：Output-Steps： 输出步聚
3.2.1：Text file output：文本文件输出。
这个用来作测试蛮好，呵呵。很方便的看到转换的输出。
3.2.2：Table output：输出到目的表。
3.2.3：Insert/Update：目的表和输入数据行进行比较，然后有选择的执行增加，更新操作。
3.2.4：Update：同上，只是不支持增加操作。
3.2.5：XML Output：
3.3：Look-up：查找操作
DataBase:
Stream：
Procedure：
Database join：
很简单，看看参数就明白了。
3.4：Transform 转换 (嗯，重点)
3.4.1：Select values： 对输入的行记录数据 的字段进行更改 (更改数据类型，更改字段名或删除)
数据类型变更时，数据的转换有固定规则，可简单定制参数。可用来进行数据表的改装。
3.4.2： Filter rows： 对输入的行记录进行 指定复杂条件 的过滤。
用途可扩充sql语句现有的过滤功能。但现有提供逻辑功能超出标准sql的不多。
3.4.3：Sort rows：对指定的列以升序或降序排序，当排序的行数超过5000时需要临时表。
3.4.4：Add sequence：为数据流增加一个序列，
这个配合其它Step(Generate rows, rows join)，可以生成序列表，如日期维度表(年、月、日)。
3.4.5：Dummy：不做任何处理，主要用来作为分支节点。
3.4.6：Join Rows：对所有输入流做笛卡儿乘积。
3.4.7：Aggregate：聚合，分组处理
3.4.8：Group by：分组
用途可扩充sql语句现有的分组，聚合函数。但我想可能会有其它方式的sql语句能实现。
3.4.9：Java Script value：使用mozilla的rhino作为脚本语言，并提供了很多函数，用户可以在脚本中使用这些函数。
3.4.10. Row Normaliser：该步骤可以从透视表中还原数据到事实表，
通过指定维度字段及其分类值，度量字段，最终还原出事实表数据。
3.4.11. Unique rows：去掉输入流中的重复行
在使用该节点前要先排序，否则只能删除连续的重复行。
3.4.12. Calculator：提供了一组函数对列值进行运算，
所介绍，使用该方式比用户自定义JAVA SCRIPT脚本速度更快。
3.4.13. Merge Rows：用于比较两组输入数据，一般用于更新后的数据重新导入到数据仓库中。
3.4.14. Add constants：增加常量值。
这个我没弄明白它的用法？？？
3.4.15. Row denormaliser：同Normaliser过程相反。
3.4.16. Row flattener：表扁平化处理
指定需处理的字段和扃平化后的新字段，将其它字段做为组合Key进行扃平化处理。
3.5：Extra：除了上述基本节点类型外还定义了扩展节点类型
3.5.1：SPLIT FIELDS， 按指定分隔符拆分字段
3.5.2：EXECUTE SQL SCRIPT，执行SQL语句
3.5.3：CUBE INPUT，
3.5.4：CUBE OUTPUT等。
这两个没明白是啥意思。
3.6：其它
存储方式： 与Chef相同。
数据源(Connection)；见后。
Hops：setp连接起来，形成Hops。
Plugin step types等节点：这个没仔细看，不知如何制作Plugin step。
LogView：可查看执行日志。
四：Pan——转换的执行工具
命令行执行方式，可以执行由Spoon生成的转换任务。
同样，不支持调度。
参数与Kitchen类似，可参见Pan的文档。
五：其它
Connection：
可以配置多个数据源，在Job或是Trans中使用，这意味着可以实现跨数据库的任务。
支持大多数市面上流行的数据库。
1：转换功能全，使用简洁。作业项丰富，流程合理。但缺少调度。
2：java代码，支持的数据源范围广，所以，跨平台性较好。
3：从实际项目的角度看，和其它开源项目类似，主要还是程序员的思维，缺少与实际应用项目(专业领域)的更多接轨，当然，项目实施者的专注点可能在于一个平台框架，而非实际应用(实际应用需要二次开发)。
4：看过了大多数源码，发现源码的可重用性不是太好(缺少大粒度封装)，有些关键部分好象有Bug。
比如：个别class过于臃肿，线程实现的同步有问题。
5：提供的工具有些小错，如参数的容错处理。
好，对Kettle有了浅浅的了解，其它的容后再说。