PentahoETL工具Kettle转换实现原理

PentahoETL工具Kettle转换实现原理
关于Pentaho ETL工具Kettle转换实现原理的研究·ETL和Kettle 简介
ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程。

它是构建数据仓库的重要环节。

数据仓库是面向主题的、集成的、稳定的且随时间不断变化的数据集合，用以支持经营管理中的决策制定过程。

Kettle 是”Kettle E.T.T.L. Envirnonment”只取首字母的缩写，这意味着它被设计用来帮助你实现你的ETTL 需要：抽取、转换、装入和加载数据；翻译成中文名称应该叫水壶，名字的起源正如该项目的主程序员MATT 在一个论坛里说的哪样：希望把各种数据放到一个壶里然后以一种指定的格式流出。

Kettle的四大块：
Chef——工作(job)设计工具(GUI方式)
Kitchen——工作(job)执行器(命令行方式)
Spoon——转换(transform)设计工具(GUI方式)
Pan——转换(trasform)执行器(命令行方式)
Spoon 是一个图形用户界面，它允许你运行转换或者任务，其中转换是用Pan 工具来运行，任务是用Kitchen 来运行。

Pan 是一个数据转换引擎，它可以执行很多功能，例如：从不同的数据源读取、操作和写入数据。

Kitchen 是一个可以运行利用XML 或数据资源库描述的任务。

通常任务是在规定的时间间隔内用批处理的模式自动运行。

下面将具体介绍Pan,和Kitchen在ETL中的实现过程。

·数据转换原理及具体实现过程
大致步骤如下：
转换的过程中（在windows环境下），首先会调用Pan.bat，这一步主要是做一些初始化，连接验证，环境设置，检查之类；然后在Pan的最后一步会调用launcher.jar包，这个包用于启动JDBC驱动，并向JDBC传入相关连接信息和参数，然后开始传数据，最后是完成数
据传输，关闭相关协议，写入日志。

首先来看Kitchen的实现，Kitchen在一个job中一般包含以下几个步骤：
转换：指定更细的转换任务，通过Spoon生成。

通过Field来输入参数；
SQL：sql语句执行；
FTP：下载ftp文件；
邮件：发送邮件；
检查表是否存在；
检查文件是否存在；
执行shell脚本：如dos命令。

批处理：(注意：windows批处理不能有输出到控制台)。

Job包：作为嵌套作业使用。

SFTP：安全的Ftp协议传输；
HTTP方式的上/下传。

以下是一个简单的ETL过程：
转换一开始就
会调用Pan
下面一段代码是基于JDBC的数据库访问的经典总结，简单地说，JDBC 可做三件事：与数据库建立连接、发送SQL 语句并处理结果：Connection con = DriverManager.getConnection("jdbc：odbc：wombat"，"login"，"password")；
Statement stmt = con.createStatement()；
ResultSet rs = stmt.executeQuery("SELECTa，b，c FROM Table1")；
while (rs.next()) {
int x = rs.getInt("a")；
String s = rs.getString("b")；
float f = rs.getFloat（"c"）；
}
JDBC 是个"低级"接口，也就是说，它用于直接调用SQL 命令。

在这方面它的功能极佳，并比其它的数据库连接API 易于使用，但它同时也被设计为一种基础接口，在它之上
可以建立高级接口和工具。

高级接口是"对用户友好的"接口，它使用的是一种更易理解和更为方便的API，这种API在幕后被转换为诸如JDBC 这样的低级接口。

在关系数据库的"对象/关系"映射中，表中的每行对应于类的一个实例，而每列的值对应于该实例的一个属性。

·总结
Kettle实现数据转换，主要是通过JDBC驱动，建立连接，加载数据，传输数据，在这个过程中可能会调用XML脚本或批处理，大文件的话会用到FTP或HTTP方式上传/下传数据。

·关于JDBC导致内存溢出的问题
通过网上查阅资料和自己的理解得出了JDBC导致内存溢出的问题的几个原因Oracle JDBC 驱动, 在大数据量查询时会使用大量的内存, 如果控制不好很容易导致Java出现Out of memory错误.耗内存有多方面的原因:
1. Oracle JDBC在从后台取数据时, 为每行所设置的 buffer 是以列的最大size来计算分配内存的.当没有定义size, 就取最大值，这导致某些字段，例如AGE之类，在加载到buffer 中的时候本来只需要很小的内存开销，这里就花了更多的内存去读该行数据。

但是，针对于可以指定大小的字段，ORACLE还是会根据具体SIZE分配内存。

由些可见, 作为一个数据库表的设计者, 在定义表的列类型时, 不能随便: 应该遵循最小使用原则, 否则会数据库的使用者带来不少的麻烦.
比如能用varchar2的就不要用clob, 用varchar2时不要随便定义一个很大的size, 比如username varchar(1024), username是不可能定义为这么长的.
2. 新的JDBC标准, 增加了statement client pool功能.对于一个处理业务的JDBC程序, 这个功能肯定是一个很好的, 以内存换速度的方法. 不过毕竟不是所有的JDBC使用程序都是这样的
3. JVM最大内存设置。

另JVM启动时最大内存也不能太小了.有一个到现在可能还误导的问题: 就是jvm最大内存设置不能超过4G, 很显然这个是32bit的jvm和OS的问题, 如果你是64bit OS加上64bit 的JVM当然没有这个限制了.
当然内存溢出不是一个简单的问题，还有其他很多方面导致，比如，查询的效率，类型转换这些都可能导致内存开销过大。