Kettle（PDI）部署全指南：从版本选择到JDK配置与启动验证

1. 别被"解压即用"骗了：先搞清楚Kettle的版本与发行渠道

1.1 Kettle和PDI、Pentaho Data Integration到底是什么关系

Kettle这个词在数据开发圈子里叫了十几年，但很多人第一次接触时还是会被一套名字绕晕：Kettle、PDI、Pentaho Data Integration、Spoon，这几个说法到底是不是同一个东西？

简单说，Kettle是开源ETL工具的早期项目名，后来项目并入Pentaho社区版，官方名称变成了Pentaho Data Integration，简称PDI。大家平时说的Kettle，指的就是PDI这个工具。而Spoon是PDI自带的图形化设计器，你双击打开的那个画转换、画作业的界面就是Spoon。下载回来的压缩包解压后，目录名叫data-integration，里面的spoon.sh（Linux/macOS）或Spoon.bat（Windows）就是图形界面的启动入口。

这个命名关系不搞清楚，后面部署时搜资料会非常痛苦。比如你搜"Kettle官网下载"，出来的可能是上古版本7.1；你搜"PDI下载"，结果是9.x的社区版；你要是照着某篇"Kettle 8.2部署教程"操作，下载的却是10.x的包，JDK版本对不上，启动直接失败。所以部署前先把名字对齐：你要装的是PDI社区版，入口是Spoon，底层跑在Java上。

1.2 版本与JDK的配对是部署的第一道坎

Kettle本质上是一个Java应用，所以它和JDK版本的匹配关系，几乎是部署环节里最容易翻车的地方。官网下载页和GitHub的Release说明里其实写得清清楚楚，但大多数人根本不看，直接下最新版，然后拿机器上已有的JDK去跑，结果Spoon窗口一闪而过，日志里报一堆UnsupportedClassVersionError或NoClassDefFoundError。

我按实际使用经验整理一下当前主流的配对关系：

这里有个关键点：JDK版本并不是越新越好。如果你选择8.2版本，却装了JDK 17，大概率启动时报错或者某些组件（尤其是老的非官方插件）直接失效。反过来，你选了10.x版本，机器上还是JDK 8，那连编译后的class文件都读不了，因为10.x的class文件版本号更高。

所以我的建议是：先定版本，再配JDK。如果你是为了接一个已有的老项目，优先沿用项目在用的Kettle版本；如果是新环境、新项目，建议直接用9.4配JDK 11或17，既不老也不激进，社区资料也够用。8.x虽然教程最多，但放到今天，很多新驱动和新数据类型支持已经跟不上了。

1.3 官方下载还是SourceForge：各版本怎么选

Kettle的下载渠道主要有两个：Pentaho官方下载页和SourceForge。国内很多博客给的链接五花八门，有的甚至指向第三方网盘，安全性完全没法保证。这里我建议只走两个正规渠道。

SourceForge上是Pentaho官方维护的发布目录，路径是pentaho/Data Integration/，里面有从老到新的所有版本，比如pdi-ce-8.2.0.0-342.zip、pdi-ce-9.3.0.0-428.zip等。如果你需要装历史版本，SourceForge是最稳定的选择。

Pentaho官网的下载页则主要提供最新社区版，需要填写一个简单的表单，然后会跳转到下载链接。官网的问题在于，它经常把社区版和商业版入口放在一起，新手容易点错。如果你只需要免费的社区版，认准"Community Edition"字样，不要看"Enterprise"。

另外，Maven中央仓库里也能找到部分PDI相关构件，但那是给二次开发用的，不是给你下载完整发行版的，直接跳过。还有一点值得说：下载时尽量选.zip或.tar.gz格式的完整安装包，不要选那种几MB的所谓"精简版"或"绿色版"，那通常是阉割过插件或依赖的，跑起来缺这缺那，排查起来比完整部署还痛苦。

2. 下载实操：从下载到解压，这几步别跳

2.1 下载渠道的完整路径与版本命名规则

很多第一次部署Kettle的人，卡在第一步"不知道去哪下"上。这里我把SourceForge的实际路径写清楚，你照着走就行。

打开SourceForge，搜索pentaho，进入Pentaho项目主页后，找到Files标签页，然后按路径依次进入：

code复制pentaho / Data Integration /

在这个目录下你会看到类似这样的文件列表：

• pdi-ce-8.2.0.0-342.zip
• pdi-ce-8.3.0.0-371.zip
• pdi-ce-9.0.0.0-423.zip
• pdi-ce-9.1.0.0-324.zip
• pdi-ce-9.3.0.0-428.zip
• pdi-ce-9.4.0.0-343.zip

版本号的命名规则是：pdi-ce-主版本.次版本.补丁版本-构建号。比如9.3.0.0-428，主版本9，次版本3，构建号428。社区版（Community Edition）的标识是ce，商业版是ee。下载时认准ce。

选版本时我建议考虑下面几个因素：你团队里其他人用的什么版本，功能上你需要的组件（比如动态SQL、REST Client）在哪个版本开始完善，以及你机器上的JDK。如果拿不准，选9.3或9.4是目前比较稳妥的中间选择。

2.2 安装包类型怎么选：zip、tar.gz还是Windows安装版

在下载目录里你会看到同版本有不同后缀的文件，比如.zip和.tar.gz。这俩的本质区别是压缩格式不同，内容几乎一样，zip在Windows和Linux下都好解压，tar.gz在Linux/macOS下更常见。

Kettle官方没有那种带图形化安装向导的"安装版"，它就是一个绿色压缩包，解压即用。所以网上流传的"Kettle 8.2安装版"大多是第三方封装的，不建议用，因为你不知道里面被塞了什么。社区里还有一个误解，认为Windows下要双击一个setup.exe才能装Kettle，其实那完全是多余的。

你需要注意的只有三点：第一，确认下载文件完整，不要用下载工具开多个线程把文件搞坏；第二，解压路径不要带空格和中文，比如C:\Program Files\kettle这种路径在某些组件下会出问题，D:\data-integration或/opt/data-integration这种路径更省心；第三，解压后文件夹要保留在磁盘根目录或某个固定位置，不要放在桌面或者临时目录，Kettle运行时会产生不少缓存文件，路径不稳定会让你后面找问题找不到北。

2.3 解压路径、目录结构与文件校验

下载完后，我建议先做一次MD5或SHA256校验。SourceForge的下载页面会提供对应的checksum文件，或者你在包名旁边能看到指纹信息。Windows下可以用certutil -hashfile 文件名 SHA256命令，Linux下用sha256sum。这一步虽然烦，但能避免解压到一半报CRC错误或者运行时莫名其妙加载不了类的坑。

校验通过后，解压到规划好的目录，你会看到Kettle的主目录叫data-integration，里面有几个关键文件：

• spoon.sh / Spoon.bat：图形界面Spoon的启动入口
• kitchen.sh / Kitchen.bat：作业（Job）的命令行执行入口
• pan.sh / Pan.bat：转换（Transformation）的命令行执行入口
• lib/：Kettle核心依赖库
• libext/：扩展驱动和插件目录
• plugins/：插件目录
• .kettle/：用户配置目录（第一次启动后生成）

解压完成后，可以顺手检查一下lib目录下有没有launcher相关的jar包，如果解压不完整，这个目录会缺文件，启动时直接报"找不到主类"。这一步只需要两分钟，但能帮你提前排除解压损坏的问题。

3. 部署的三座山：JDK环境、启动脚本与内存参数

3.1 JDK安装与环境变量配置的正确姿势

Kettle部署中最核心的依赖就是JDK，但JDK的安装和环境变量配置，不同操作系统有不同的讲究。这里我分Windows和Linux两个场景说。

Windows下，下载JDK后直接安装，安装时记下安装路径，比如C:\Program Files\Java\jdk-17。然后配置环境变量：

• 新建JAVA_HOME，值填JDK安装路径；
• 在Path里追加%JAVA_HOME%\bin；
• 新建或修改CLASSPATH为.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar（注意最前面的点）。

配置完成后，打开命令行执行java -version和javac -version，确认输出的是你装的那个JDK版本。这里我踩过一个坑：机器上装了多个JDK，Path里前面的版本把后面的盖住了，结果Kettle启动时用了旧JDK。所以建议把JAVA_HOME指到确定版本，同时在Path里把%JAVA_HOME%\bin放在C:\Windows\System32前面，避免系统自带的java命令抢先。

Linux下，如果你是root或者有sudo权限，可以直接用包管理器装的OpenJDK。但要注意，不同发行版的默认JDK版本可能不同，比如CentOS 7用yum install java-1.8.0-openjdk装的是JDK 8，Ubuntu 22.04上apt install default-jdk装的可能是JDK 17。Kettle对版本敏感，装之前先想好Kettle版本，再决定JDK版本。装完后用update-alternatives --config java可以切换默认Java版本，这个命令在管理多版本JDK时特别好用。

3.2 Spoon启动脚本里的内存参数怎么改

Kettle是Java应用，默认堆内存设置有时候并不适合你机器的情况。Spoon在启动时会读取启动脚本里的PENTAHO_DI_JAVA_OPTIONS环境变量，这个变量不设置的话，有些低配机器会卡到打不开图形界面，高配机器又发挥不出性能。

Windows下编辑Spoon.bat，找到类似这样的段落：

code复制set PENTAHO_DI_JAVA_OPTIONS="-Xmx2048m" "-XX:MaxPermSize=256m"

如果没找到，可以在脚本开头手动加一行：

code复制set PENTAHO_DI_JAVA_OPTIONS="-Xmx4096m" "-Dfile.encoding=utf-8"

Linux下编辑spoon.sh，找到：

code复制PENTAHO_DI_JAVA_OPTIONS="-Xmx2048m"

改成你需要的值，比如-Xmx4096m或-Xmx8192m。这里有个原则：堆内存上限不要超过物理内存的一半，尤其当你同时还要跑数据库和浏览器时。8G内存的笔记本，给Kettle 4G已经比较宽裕了。

还有一个细节：-XX:MaxPermSize只在JDK 8及以前有效，JDK 11、17里已经移除了PermGen，加了反而会启动时报Unrecognized VM option。所以如果你的JDK是11或17，脚本里如果还带着MaxPermSize，记得删掉，否则Spoon起不来。

3.3 中文乱码与Locale问题：很多人部署完才发现的坑

Kettle部署完成、界面能打开后，很多国内用户会立刻遇到另一个问题：界面乱码。明明系统是中文环境，Kettle的菜单和日志却显示成方块或问号。

这个问题通常出在JVM的默认字符集上。Windows下JDK 8及以后版本的默认字符集是GBK或系统区域设置决定的，而Kettle内部很多资源文件是UTF-8编码，两边一冲突就乱码。

解决办法是在启动脚本里显式指定文件编码，上文我写的-Dfile.encoding=utf-8就是干这个用的。你把它加进PENTAHO_DI_JAVA_OPTIONS后重启Spoon，乱码问题基本能解决。

另外Linux下还有一个Locale问题：如果你机器的LANG环境变量不是en_US.UTF-8或zh_CN.UTF-8，Kettle的某些组件（尤其是日期解析、数字格式化）会按系统默认Locale走，导致数据结果跟你预期的格式不一样。我的习惯是部署Kettle的机器统一设置LANG=en_US.UTF-8，等数据跑完了再在Kettle内部用组件指定格式，这样能避免很多隐形的数据格式坑。

4. 第一次启动：图形界面和命令行验证要做哪些事

4.1 图形界面启动成功不等于万事大吉

Spoon能打开，很多人的部署就宣告结束了。但我的经验是，这一步只代表基础环境没问题，很多深层的坑还没暴露出来。

第一次启动时，你会看到Spoon的欢迎界面，然后进入主工作区。此时需要做几个验证动作：

• 检查左下角或帮助菜单里的版本信息，确认是你要的版本；
• 新建一个转换，随便拖入一个"生成记录"和"表输出"组件，跑一个最简单的空转换，看是否能正常执行；
• 打开"视图"面板，查看数据库连接列表，确认能正常弹出连接配置窗口，而不是直接报错。

这三步都过了，才叫真正的启动成功。很多人的Kettle只在欢迎界面转圈，或者一打开就白屏，这类问题大多是显卡驱动或SWT库的问题，和JDK无关，需要更新图形库或调整Spoon的启动参数。

还有一个很容易忽略的点：首次启动后，Kettle会在用户目录下生成.kettle配置文件夹。如果你在Windows下，这个目录一般在C:\Users\用户名\.kettle；Linux下在/home/用户名/.kettle。里面有一个kettle.properties文件，很多全局变量、数据库连接参数都可以写在这里。部署完成后顺手看一眼这个文件是否存在，能确认用户配置目录有没有权限问题。

4.2 命令行模式（Kitchen、Pan）怎么验证部署

Spoon图形界面只是Kettle的一部分，真正的生产环境通常用命令行方式跑作业和转换。所以在部署验证阶段，我强烈建议你同时测试Kitchen和Pan。

Linux下进入data-integration目录，执行：

bash复制./kitchen.sh -version
./pan.sh -version

Windows下执行：

bat复制Kitchen.bat -version
Pan.bat -version

如果能看到版本号输出，说明命令行执行环境没问题。更完整的验证是把一个最简单的转换用Pan跑一遍：

bash复制./pan.sh -file:/path/to/test.ktr -level:Basic

命令行能跑通，说明部署环境对以后的定时调度、脚本调用都是可用的。很多生产事故都是"图形界面好好的，命令行一跑就缺驱动",原因就是图形界面加载了用户手动添加的类路径，而命令行模式没有。所以在首次部署时就把命令行模式验证到位，能省掉后面调度时的很多惊吓。

4.3 三个高频启动失败场景的排查链路

Kettle启动失败，症状五花八门，但根因相对集中。我总结了三个最高频的场景，以及我实际排查时的链路。

场景一：Spoon窗口一闪而过。 这是最常见的情况。首先确认JDK版本和Kettle版本是否匹配，然后打开命令行手动执行spoon.sh，直接观察输出的错误日志。如果日志显示UnsupportedClassVersionError，就是JDK版本太旧；如果显示Unable to detect SWT library，可能是操作系统位数和Kettle发行版不匹配（32位系统跑64位包）。排查完这两项，九成问题能解决。

场景二：启动后卡在欢迎界面。 这类问题多为内存不足或SWT/JFace组件加载异常。先看PENTAHO_DI_JAVA_OPTIONS中-Xmx是否设置过大（超过物理内存）或过小（低于512M）。另外，Windows下如果开启了高DPI缩放，Spoon在4K屏幕上也可能出现白屏或卡顿，解决方案是右键Spoon.bat，在兼容性设置里勾选"替代高DPI缩放行为"。

场景三：提示找不到或加载不了数据库驱动。 这其实不算启动失败，但很多人误以为Kettle没装好。如果你打开一个转换，数据连接里选了MySQL却报ClassNotFoundException: com.mysql.cj.jdbc.Driver，那就是驱动jar没放进libext目录，跟Kettle本身无关。把对应的驱动jar放进去，重启Spoon即可。

5. 部署后马上要做的配置：驱动、资源库与数据库连通性

5.1 数据库驱动统一放哪里：lib、libext还是driver目录

Kettle部署完成后，第一件正事就是配数据库驱动。但很多新手会陷入一个困惑：驱动jar到底放哪个目录？网上有的说放lib，有的说放libext，有的说放到用户目录。我的实践结论是：第三方数据库驱动统一放libext目录下。

Kettle的类加载机制是先加载lib下的核心库，再加载libext下的扩展库。如果你把MySQL驱动放到lib里，理论上能加载，但Kettle升级或重新解压时，lib目录会被覆盖，驱动就丢了。libext目录本身就是设计给第三方驱动的，放这里最合适，升级时也不会被覆盖。

放置驱动后，需要重启Spoon才能生效。你可以在"连接"配置页面测试连接，如果还报错，进入data-integration/libext目录，确认jar文件权限和完整性，以及jar版本是否过老。比如连接MySQL 8.x，必须用mysql-connector-java-8.0.x.jar，用5.1.x版会报Public Key Retrieval is not allowed之类的连接错误。

还有个小技巧：可以在kettle.properties里设置custom.lib.dir变量，指定额外的驱动加载目录。这样驱动就不用全部堆在安装目录下，尤其是团队多人共用一套部署时，能避免互相覆盖。

5.2 连接达梦、MySQL等常见数据库的实测说明

近几年国产数据库的使用场景明显多了起来，很多人部署完Kettle后第一件事就是连接达梦数据库。Kettle本身不自带达梦驱动，需要先下载达梦官方JDBC驱动（DmJdbcDriver18.jar），放到libext目录。

连接时，数据库连接类型如果下拉列表里找不到"达梦"，可以选"Generic database"或直接选"Other"类型，然后手动填JDBC URL。达梦的JDBC URL格式一般是：

code复制jdbc:dm://host:5236/dbname

驱动类填：

code复制dm.jdbc.driver.DmDriver

我实测的过程中发现两个坑：一是达梦的驱动和Kettle版本有兼容性差异，新版Kettle用旧版驱动可能报UnsupportedOperationException，最好从达梦官网下载最新的JDBC 8驱动；二是达梦的默认端口是5236，不是很多人想当然的1521或3306，填错端口连不上不说，还会浪费时间排查网络问题。

MySQL的配置相对简单，选"MySQL"类型，填jdbc:mysql://host:3306/dbname?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，驱动类选com.mysql.cj.jdbc.Driver（MySQL 8.x）或com.mysql.jdbc.Driver（MySQL 5.x）。这里要特别提醒：连接串里务必带上serverTimezone参数，否则Kettle向MySQL写入日期时间时，会有时区偏移问题，导致数据时间对不上。

5.3 文件型资源库与数据库资源库的选择

Kettle里有"资源库"（Repository）的概念，用来保存转换、作业等元数据。部署完成后，很多人不配置资源库，直接使用文件方式保存.ktr和.kjb，这在小项目里没什么问题，但团队协作时就会乱了套。

资源库有两种主要形式：文件型资源库和数据库资源库。

文件型资源库就是指定一个共享目录（比如NFS或Samba挂载的目录），所有转换文件以XML形式存到这个目录里，团队多人共用时用版本控制工具管理。这种方式的优点是简单、不依赖数据库，缺点是并发写文件时会有锁冲突，而且没有审计日志。

数据库资源库则是把元数据存到数据库表里，Kettle会创建一组专门的表来管理转换、作业、日志等。优点是集中管理、支持多人协作和权限控制，缺点是需要提前建库，而且资源库数据库挂了，所有人都没法干活。

我的建议是：单机使用或个人开发直接用文件型资源库；生产团队协作、有正式调度平台的情况下，优先配数据库资源库。数据库资源库可以选用MySQL或PostgreSQL，创建时在Kettle的资源库配置向导里填好连接信息，它会自动建表，不需要你手动执行SQL脚本。

5.4 大数据量迁移场景：从TDengine到MySQL的实操注意点

项目搜索词里出现了"kettle支持taos数据库迁移到mysql"，这类需求现在很常见，尤其是工业物联网场景下，原来时序数据存在TDengine里，现在要批量同步到MySQL做业务分析。

Kettle本身没有内置TDengine的数据源类型，但有两条路可以走。第一种是通过JDBC驱动直接连TDengine，TDengine官方提供了JDBC连接器，把它放到libext目录后，在Kettle里选Generic database，填驱动类和URL。TDengine的JDBC URL一般是jdbc:TAOS://host:6030/dbname，具体细节以官方文档为准。这种方案适合TDengine部署节点数不多、数据量可控的场景。

第二种是先将TDengine的数据查询导出为CSV文件，再用Kettle的"CSV文件输入"组件读入，写入MySQL。这种方案的优点是绕开了驱动兼容性问题，缺点是多了中间文件，实时性差一些。

无论哪种方案，从TDengine到MySQL的迁移都要注意字段类型映射。TDengine的时间戳类型在Kettle里会被读成Timestamp，写入MySQL的datetime字段时要有意识地进行格式转换，否则会出现时间偏移或者秒级精度丢失。还有一点是TDengine查询大表时必须走时间范围过滤，直接select *会把内存打爆，Kettle里的"表输入"步骤建议用变量或参数拼上时间窗口，分批次抽取。

6. 热搜词背后的进阶用法：从"能启动"到"能用起来"

6.1 用REST Client循环读取API分页数据

搜索词里有一组"kettle循环api读取"、"kettle用post组件获取api分页数据"，这类问题在接口对接场景里非常典型。部署完Kettle，很多人发现最常用的操作不是拖几个表输入和表输出，而是对接外部HTTP API拉数据，而API通常都有分页限制。

Kettle里对接HTTP接口常用的组件是"REST Client"（旧版叫"HTTP client"）和"HTTP Post"。你可以新建一个转换，结构大致是：先用"生成记录"生成一个序列，作为页码参数；然后每页调用一次REST Client；再用"JSON输入"或"XML输入"解析响应；最后写入目标表。

核心实现思路是：在REST Client的URL或请求体里使用变量，比如${page}，然后通过循环或者"复制记录到结果"的方式，把每次请求的页码变量传入。我在实际项目中用的方式是：

• 用一个"表输入"或"生成记录"步骤生成从1到N的页码列表；
• 用"JavaScript代码"或"字段选择"处理分页参数；
• REST Client的URL配置为类似http://api.example.com/list?page=${page}&size=100；
• 下接"JSON输入"，把响应里的data数组解析成行；
• 最后写入目标表。

这里最容易被忽略的是请求头设置。很多API要求带Authorization或Content-Type头，如果不在REST Client的Header里配好，返回401或415，会让你以为是分页逻辑写错了。另外，分页接口通常返回totalPages，你需要先请求一次拿到总页数，再确定循环次数，否则只能写死一个较大的值，白白请求很多空页。

6.2 动态SQL到底怎么写：变量、替换与执行脚本

"kettle动态sql语句"也是搜得很勤的词。什么是动态SQL？就是SQL的查询条件或表名不是写死的，而是根据上一步的数据动态拼出来的。比如你要对几十张结构相同但表名不同的表做同样的统计，每张表都建一个转换就太蠢了，正确做法是写一个转换，动态传入表名。

Kettle里实现动态SQL有几种方式：

第一种是在"表输入"步骤的SQL里直接使用变量，比如：

sql复制SELECT * FROM ${table_name} WHERE create_time >= '${start_date}'

前提是"表输入"步骤勾选了"替换SQL中的变量"选项。变量可以来自kettle.properties，也可以来自转换里已有的字段。这种方式最直观，适合变量数量不多、拼接逻辑简单的场景。

第二种是用"执行SQL脚本"步骤，在脚本内容里用变量拼接：

sql复制DROP TABLE IF EXISTS ${temp_table};
CREATE TABLE ${temp_table} AS SELECT * FROM source_table;

注意"执行SQL脚本"步骤默认是每条语句单独提交，如果你要在一个事务里执行多条SQL，需要设置"提交间隔"和"使用单条语句"等选项。

第三种是配合JavaScript或Java代码步骤，把一个字符串字段拼成完整的SQL，再用"表输入"把SQL字符串作为入参。这种方式最灵活，适合复杂规则拼接，但调试成本也高。我的体会是：能用变量替换解决的，不要写JavaScript；必须写脚本时，在脚本里多做日志输出，方便排查拼出来的SQL长什么样。

6.3 字段校验组件：检验字段的值应该怎么配置

"kettle检验字段的值组件怎么使用"——这个组件在中文版里叫"数据校验"或"验证"，英文是Validator。它的作用是按规则检查字段是否符合预期，不通过的记录会被移到错误流，或者写入日志表。

配置的关键步骤是：在转换里拖入"检验字段的值"组件，双击打开后，点击"字段"选项卡，设置要校验的字段、规则和错误提示信息。常用规则包括：非空、数据类型、数值范围、正则表达式、日期格式等。

我举个例子。假设你要校验一个订单表里的amount字段，要求必须大于0且不能为空。配置方式：

• 字段名：amount
• 规则：最大值（或最小值），设置最小值为0.01；
• 错误消息："金额必须大于0"；
• 失败处理：把错误记录写到"校验失败"的流里，或写入错误日志表。

配置完成后，组件会有两个输出步骤：一个是通过校验的正常流，一个是未通过的错误流。你可以把错误流接到"文件输出"或"表输出"上，记录问题数据。我在实际项目里经常把这个组件放在数据进入仓库之前的最后一个检查点，配合邮件组件，失败了就发告警，效果很好。

需要提醒的是，Validator的校验规则是基于Java类型系统的。你从"表输入"里读出来的字段类型可能不是目标类型，比如手机号被读成了BigDecimal，导致正则匹配永远失败。所以配置校验前，先用"字段选择"或"数据转换"把字段类型规范化，再进Validator，否则你会被莫名其妙的校验失败搞到崩溃。

6.4 部署完成后的验收清单：我每次都会过一遍的检查项

写到这里，回到部署本身。经过多次在不同环境下的安装部署，我沉淀了一个简单的验收清单，分享给大家参考：

• 版本信息：kitchen.sh -version能输出正确的PDI版本号；
• JDK匹配：java -version能输出与Kettle版本匹配的JDK版本；
• 驱动就位：libext目录下已放入项目所需的数据库驱动，并在Spoon中测试连接成功；
• 命令行可用：用Pan执行一个最简单的转换，能正常跑完；
• 编码正常：Spoon界面无乱码，日志输出中文字符正常；
• 内存参数合理：PENTAHO_DI_JAVA_OPTIONS的-Xmx与机器物理内存适配；
• 资源库模式确定：个人用文件型资源库还是团队用数据库资源库，已经决定并配置好。

这几项全部通过，Kettle部署这一关就算彻底过了。很多人部署Kettle时喜欢跳过命令行验证，只开Spoon看一眼就收工，结果一到生产调度就各种驱动缺失、内存不足、编码错误，最后又回头翻部署文档。提前花十分钟做一遍完整验收，后续使用会踏实很多。

最后再分享一个我自己的习惯：把Kettle的安装目录、JDK路径、kettle.properties的核心配置、以及PENTAHO_DI_JAVA_OPTIONS的内存参数都记在一个Markdown文件里，放到data-integration目录下。换机器、换团队、升级版本时，直接照着文件重新部署一遍，基本不会再踩同一个坑。