1 KETTLE 概述
Kettle是 “KETTLE E.T.T.L. ENVIRONMENT”只取首字母的缩写，这意味着它被设计用来帮助你实现ETTL的需要：抽取、转换、装入和加载数据。中文名称叫水壶，正如该项目的主程序员Matt在一个论坛里说的那样：希望把各种数据放到一个壶里然后以一种指定的格式流出。
Kettle 是一款国外开源的 ETL 工具，纯Java编写；使用突破性的元数据驱动方法，提供强大的提取、转换和加载(ETL)功能；绿色无需安装，解压即可；可以运行在Windows、Linux等多个平台；其数据抽取高效稳定。
1.1起源
Kettle是一个Java编写的ETL工具，主作者是Matt Casters，2003年就开始了这个项目，最新稳定版为8.2。
2005年12月，Kettle从2.1版本开始进入了开源领域，一直到4.1版本遵守LGPL协议，从4.2版本开始遵守Apache Licence 2.0协议。Kettle在2006年初加入了开源的BI公司Pentaho, 正式命名为：Pentaho Data Integeration，简称“PDI”。自2017年9月20日起，Pentaho已经被合并于日立集团下的新公司： Hitachi Vantara。
总之，Kettle可以简化数据仓库的创建、更新和维护，使用Kettle可以构建一套开源的ETL解决方案。
1.2 架构
Kettle是一个组件化的集成系统，包括如下几个主要部分。
1.2.1 Spoon
图形化界面工具(GUI方式)，Spoon通过图形界面来设计Job和Transformation。也可以直接在Spoon图形化界面中运行Job和Transformation。
1.2.2 Pan
Transformation执行器(命令行方式)，Pan用于在终端执行Transformation，没有图形界面。
1.2.3 Kitchen
Job执行器(命令行方式)，Kitchen用于在终端执行Job，没有图形界面。
1.2.4 Carte
嵌入式Web服务，用于远程执行Job或Transformation，Kettle通过Carte建立集群。
1.2.5 Encr
Kettle用于字符串加密的命令行工具，如：对在Job或Transformation中定义的数据库连接参数进行加密。
1.3 Kettle 使用场景
Kettle的使用场景很多，不仅限于这些：
- 在应用程序或数据库之间进行数据迁移；
- 从数据库导出数据到文件；
- 导入大规模数据到数据库；
- 数据清洗；
- 集成应用程序。
1.4 基础结构
1.4.1 Job（作业）
负责将设计好的Transformation组织在一起进而完成某一工作。
通常我们需要把一个大的任务分解成几个逻辑上隔离的Job，当这几个Job都完成了，也就说明这项任务完成了。
1.4.2 Transformation（转换）
定义对数据操作的容器，数据操作就是数据从输入到输出的一个过程。
可以理解为将一个或多个不同的数据源组装成一条数据流水线，然后最终输出到一个地方（文件、数据库等）。
比Job粒度更小一级的容器，我们将任务分解成Job，然后需要将Job分解成一个或多个Transformation，每个Transformation只完成一部分工作。
1.4.3 Step（步骤）
Transformation内部的最小单元，每一个Step完成一个特定的功能。
1.4.4 Job Entry（作业实体）
Job内部的执行单元，每一个Job Entry用于实现特定的功能，如：验证表是否存在，发送邮件等。
可以通过Job来执行另一个Job或者Transformation，也就是说Transformation和Job都可以作为Job Entry。
1.4.5 Data Stream（数据流）
反映数据在 Step 之间的流向，分为输入流和输出流：
- Input Stream：是进入一个 Step 时行的堆栈；
- Output Stream：是离开一个 Step 时行的堆栈。
1.4.6 Hop（节点连接）
用于在Transformation中连接Step，或者在Job中连接Job Entry，是一个数据流的图形化表示，实际上就是执行顺序的体现。
- Transformation-Hop：主要表示数据的流向，即从输入、过滤等转换操作，最后到输出。
- 一个 Hop 代表两个 Step 之间的一个或多个数据流;
- 一个 Hop 总是代表着一个步骤的输出流和一个步骤的输入流。
- Job-Hop：可设置执行条件：
- 无条件执行；
- 当上一个Job执行结果为True时执行；
- 当上一个Job执行结果为False时执行。
一个 Hop 总是代表着两个 Job Entry 之间的连接，并且能够被原始的 Job Entry 设置，无条件地执行下一个 Job Entry，直到成功或者失败。
1.4.7 Kettle结构的一些思考
不知道你通过上面的Kettle这种架构有怎么样的理解？或者说有没有学到某种思想？有的话，说明你的理解能力很好，我需要夸夸你：是个懂得思考的好孩子。没有的话，也不用着急，也许你平时一直都在用，只是没有总结而已。
其实就是复杂问题简单化，分而治之的思想。将一个大任务，分解成不同的小任务，再将小任务分解为一个个的小问题，逐一解决，然后逆向思考或者组装，最后完成大任务。
也许你会不以为然，说这都是些废话，我们平时都是这么解决问题的呀。
我要说的是，还真不一定。我就碰到过很多这样的人，他们看似也是按照上面的步骤在解决问题，但是他们的思维或者思路是顺向的。当然不是说他们遇到选择的时候不做判断，一摸眼走到黑。而是说缺少了那么点儿抽象能力，缺点儿想象力。他们总是不能将一些有共性的东西抽象出来，将一些顺序执行的事抽象成同一层级的事等等，让事与事之间是独立的，只在需要时才把它们串联起来。反而只是顺序的执行，让事与事之间紧密结合，无法重复利用。
说了好多，有点儿绕哈！差点儿自己都绕迷糊了，都讲了点儿啥！封装与复用？
所以，好好体会下，Kettle的结构设计吧，思想是不变的，可以借鉴到多处使用。Kettle的整体结构设计完全就采用了“组件化”的产品思维模式，也符合程序员对自己的要求—“不重复造轮子”。
1.4.8 Kettle 结构图
1.4.9 官网呈现图
1.4.10 实际应用呈现图
1.5 文件格式
设计用户设计好的Transformation 和 Job 可以保存在Xml文件中或某一个特定的数据库中。
Transformation 的设计文件以 .ktr 结尾，保存所有配置好的数据库连接、文件相对路径、字段映射关系等信息。
下面是一个调用已经设计好的转换的Transformation文件的开头部分：
<?xml version="1.0" encoding="UTF-8"?>
<transformation>
<info>
<name>CCTA随访数据导出</name>
<description/>
<extended_description/>
<trans_version/>
<trans_type>Normal</trans_type>
<trans_status>0</trans_status>
<directory>/</directory>
<parameters>
<parameter>
<name>password</name>
<default_value>Di13M@43</default_value>
<description>数据库密码</description>
</parameter>
</parameters>
复制代码Job 的设计文件以 .kjb 结尾。
转载于:https://juejin.im/post/5cff457b6fb9a07ec9560421