简介Kettle 7.1 是一款成熟的开源 ETL 工具后更名为 Pentaho Data Integration由 Java 开发、支持跨平台运行适合数据工程师、BI 开发人员及运维人员完成数据抽取、转换与加载。其核心亮点是无需编码、拖拽式开发数据管道可对接传统数据库、文件、大数据平台、接口及流数据并支持集成机器学习算法。压缩包内共包含 1928 个文件以 jar 依赖库、ktr 转换、kjb 作业、xml 配置、properties 配置及 bat/sh 启动脚本为主涵盖 Spoon 图形界面的完整运行环境与示例任务压缩后约 827MB目录结构清晰便于直接部署或参考学习。已有 1471 人学习下载。通过解压使用可以快速搭建 Kettle 开发环境熟悉转换与作业的设计流程理解各类插件与配置文件的作用也可基于自带脚本进行二次定制适合从入门到进阶的系统性学习。 上周有个朋友来找我说他们准备把二十多张业务表做成每日同步问我这个活儿到底用自研脚本还是买商业产品。我给出的建议很直接卡在预算和工期之间的时候开源ETL工具就是那条最现实的路。他第一反应是“Kettle 7.1这个项目还活着吗怎么还有人推”——这种反应我见太多了。Kettle 7.1确实不算新它是Pentaho Data Integration社区版在7.1代际的产品。但直到现在在不少传统企业、中小数据团队里它依然是干活的主力。这篇文章我不打算讲那些花里胡哨的新特性而是老实讲清楚Kettle 7.1能做什么、环境怎么搭、第一次怎么上手、性能怎么调、坑在哪以及为什么它在开源ETL工具的候选清单里至今还占着一个位置。1. Kettle 7.1到底是什么以及它的适用边界在哪1.1 它的正式身份Kettle的全称叫Pentaho Data Integration业内通常简称PDI。Kettle这个代号是项目早期流传下来的现在大家都叫顺口了。7.1是社区版Community Edition里被下载次数最多、中文资料最全的一个版本整个工具基于Java开发桌面端通过Spoon这个图形化设计器来完成数据流程的编排。我当时第一次接触这个工具时光是理解“Kettle、PDI、Spoon、Pentaho”这几个词的关系就绕了半天。简单说Pentaho是公司/产品家族名Data Integration是其中负责数据集成的套件Kettle是套件的旧代号Spoon是这个套件里的图形化客户端也就是你每天打开的那个界面。1.2 它解决的问题数据散落在Excel、CSV、各个关系型数据库、甚至Hadoop集群里要把它们汇总到一处做报表、做分析、做二次加工就必然涉及抽取、转换、加载三个动作也就是ETL。Kettle就是干这件事的通过图形化拖拽把“从哪读数据、怎么洗数据、写到哪去”表达成一条可执行的数据流。拿最典型的场景来说业务系统用的是MySQL数仓在PostgreSQL每天凌晨要把订单表、用户表同步过去中间还要做字段映射、去重、类型转换——用Kettle搭一个转换之后每天双击运行或配个定时任务就行了。1.3 和同类工具的粗略对比用Kettle之前我建议你先知道它为什么不适合所有场景。DataX阿里开源的数据同步框架偏向数据库之间的高吞吐同步性能好但几乎没有可视化编排能力配置靠JSON。Airflow偏工作流调度真正写数据加工逻辑还得靠Python或者其他工具来配合不是开箱即用的ETL工具。Informatica老牌商业ETL产品功能全面但license价格对中小企业不太友好。Kettle图形化编排、多数据源支持、开源免费团队里稍微有点SQL基础的人都能快速上手。短板也很明显不适合毫秒级实时流计算也不适合超大规模分布式调度。所以在技术选型时我的判断标准很简单如果是日级、小时级的批处理数据量在百万到千万级别Kettle 7.1完全能扛住如果业务要求实时性很高或者数据量到了亿级以上的离线计算那就要考虑Flink、Spark这类重器了。2. 环境准备JDK版本、Spoon启动和驱动放置三个容易翻车的地方2.1 JDK版本要卡准别盲目装新版Kettle 7.1大约是2017年左右发布的对应的Java版本是Java 8。不要在装了Java 11或者Java 17的机器上直接跑去启动Spoon轻则界面打不开重则直接报UnsupportedClassVersionError。我的建议是生产服务器上装一个独立的JDK 8专门给Kettle用不要动系统默认的Java环境。这样做的好处是避免影响机器上其他应用。你可以在启动脚本里显式指定JAVA_HOME这样这台机器上跑其他Java程序完全不受干扰。2.2 启动Spoon和命令行工具的区分Windows环境下启动图形界面是双击>SELECT id, username, email, phone, created_at FROM t_user WHERE update_time ?Kettle支持问号占位符可以在下方“插入”里绑定一个变量或者由外部传入参数。写完SQL后强烈建议先点一下“预览”按钮查看前1000行数据确认字段名和类型都符合预期再继续往下走。4.3 表输出类型映射一定要人工过一遍再拖一个“表输出”步骤选PG连接表名填t_user。如果目标表还不存在可以点“SQL”按钮让Kettle根据输入流生成建表语句。但这里要小心Kettle自动生成的类型映射不是100%可靠MySQL的TINYINT(1)经常被映射成PG的booleandatetime的精度也可能对不上。所以自动生成的建表语句一定要人工过一遍。在“数据库字段”页签里可以手动调整字段映射也可以点“获取字段”自动映射。提交记录大小建议设为500不要保持默认的1否则大批量同步时每条记录都要单独提交一次数据库事务慢到怀疑人生。4.4 运行与调试先局部验证再整体跑点运行按钮后看下方日志。如果报错先判断是连接问题还是字段映射问题。我自己的调试习惯很笨但很有效先把两个步骤之间的跳断开分别预览两侧数据确认输入侧的字段没问题了再接上跑。也可以用“日志”步骤把中间结果打印到控制台。不要一上来就全链路跑报错之后对着整条流水线猜问题那是效率最低的排错方式。把链路拆成小段逐段验证是Kettle调试的核心方法论。4.5 增量同步的简单思路全量同步适合小表。日增量同步最朴素的写法是在作业里定义一个变量last_time每次从控制表里查出上次同步的最大时间把它传给转换里的SQL参数。下次跑的时候WHERE update_time ${last_time}就会自动只捞新增和修改的数据。这种基于时间水印的增量方式对百万级用户表完全够用不需要上更复杂的CDC方案。5. 性能与稳定性批量提交、并行、内存的调优记录5.1 表输出的提交记录大小表输出步骤里的“提交记录大小”是关键参数。默认值有时是1也就是逐条插入几万行数据能跑出天荒地老的效果。实际项目里我常用500到1000这个区间。但也不是越大越好。比如一次提交十万条一旦中途报错回滚成本很高目标库还可能出现锁等待。500到1000是一个在性能和稳定性之间比较平衡的范围。5.2 并行执行与数据库连接池的配合转换属性里有一个“并发运行”的选项勾选后不同分支可以并行执行。并行确实能提速但有一个前提数据库连接数要够用。如果机器默认连接池只有10个连接而你在转换里并行开了8个分支每个分支又要抢连接那并发反而变成互相等待。我常用的小技巧是并行不要无脑全开先明确目标库能承受多少并发写入再决定开几个分支。目标库正在做索引重建时强行并行写入大概率会把任务拖垮。5.3 JVM内存Spoon和命令行要分开看Spoon的启动脚本里可以修改-Xmx参数默认可能只有512MB或1GB处理大文件时容易OOM内存溢出。我一般调成-Xmx2048m起步。但真正上生产跑任务时用的是Kitchen/Pan命令行它们的内存参数才是重点调优对象。命令行脚本同样可以设置PENTAHO_DI_JAVA_OPTIONS比如-Xmx4096m。很多人只在Spoon里调内存生产命令行用的是默认值结果一到半夜跑大数据量就挂找半天找不到原因。5.4 驱动侧参数对批量写入的影响MySQL连接串加rewriteBatchedStatementstruePG连接的JDBC参数里加reWriteBatchedInsertstrue对批量插入的提升不是一点半点。这两个参数可以直接在数据库连接的“选项”页签里配置或者在URL里拼上。我第一次优化同步任务时只调了提交记录大小从5000行跑到几万行仍然很慢后来加了rewriteBatchedStatementstrue写入耗时直接降了一个数量级。这个参数被忽略的频率非常高。5.5 失败重试与日志定位作业的“作业属性”里可以配置失败重试次数。生产环境里我的标准流程是转换失败后向一张日志表插入一条失败记录再由外部的定时调度平台决定是否补跑。Kettle自带的日志信息很多但全量日志翻起来很痛苦。我一般只关注步骤级别的日志用关键字过滤。例如搜索ERROR和Exception先定位报错发生在哪个步骤再去看那条数据本身能省下不少时间。6. 乱码、驱动冲突和连接超时三个高频坑的排查经验6.1 中文乱码URL参数和编码设置缺一不可现象是MySQL里显示正常的中文同步到PG后变成??。绝大多数原因是连接URL没有指定UTF-8。MySQL的连接串必须加useUnicodetruecharacterEncodingUTF-8PG端一般默认UTF-8问题不大。如果是读CSV或Excel文件出现乱码那就到文件输入步骤的“编码”选项里强制指定UTF-8。还有一个比较隐蔽的原因Linux系统级的LANG环境变量没有设置好会干扰Kettle对文件编码的默认判断。遇到乱码问题我建议先看连接URL再看文件步骤编码最后看系统环境变量按这个顺序排查最快。6.2 驱动冲突同族驱动只留一个现象是之前一切正常某天启动后突然报ClassNotFoundException或者“找不到类”。最常见的原因就是lib目录里放了多个版本的mysql-connector或ojdbc驱动。Kettle的类加载顺序并不完全可控两个同族驱动并存时就是在赌运气。我的处理方法是进入style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" /> Kettle 7.1实战：从环境搭建到数据同步的性能调优
简介Kettle 7.1 是一款成熟的开源 ETL 工具后更名为 Pentaho Data Integration由 Java 开发、支持跨平台运行适合数据工程师、BI 开发人员及运维人员完成数据抽取、转换与加载。其核心亮点是无需编码、拖拽式开发数据管道可对接传统数据库、文件、大数据平台、接口及流数据并支持集成机器学习算法。压缩包内共包含 1928 个文件以 jar 依赖库、ktr 转换、kjb 作业、xml 配置、properties 配置及 bat/sh 启动脚本为主涵盖 Spoon 图形界面的完整运行环境与示例任务压缩后约 827MB目录结构清晰便于直接部署或参考学习。已有 1471 人学习下载。通过解压使用可以快速搭建 Kettle 开发环境熟悉转换与作业的设计流程理解各类插件与配置文件的作用也可基于自带脚本进行二次定制适合从入门到进阶的系统性学习。 上周有个朋友来找我说他们准备把二十多张业务表做成每日同步问我这个活儿到底用自研脚本还是买商业产品。我给出的建议很直接卡在预算和工期之间的时候开源ETL工具就是那条最现实的路。他第一反应是“Kettle 7.1这个项目还活着吗怎么还有人推”——这种反应我见太多了。Kettle 7.1确实不算新它是Pentaho Data Integration社区版在7.1代际的产品。但直到现在在不少传统企业、中小数据团队里它依然是干活的主力。这篇文章我不打算讲那些花里胡哨的新特性而是老实讲清楚Kettle 7.1能做什么、环境怎么搭、第一次怎么上手、性能怎么调、坑在哪以及为什么它在开源ETL工具的候选清单里至今还占着一个位置。1. Kettle 7.1到底是什么以及它的适用边界在哪1.1 它的正式身份Kettle的全称叫Pentaho Data Integration业内通常简称PDI。Kettle这个代号是项目早期流传下来的现在大家都叫顺口了。7.1是社区版Community Edition里被下载次数最多、中文资料最全的一个版本整个工具基于Java开发桌面端通过Spoon这个图形化设计器来完成数据流程的编排。我当时第一次接触这个工具时光是理解“Kettle、PDI、Spoon、Pentaho”这几个词的关系就绕了半天。简单说Pentaho是公司/产品家族名Data Integration是其中负责数据集成的套件Kettle是套件的旧代号Spoon是这个套件里的图形化客户端也就是你每天打开的那个界面。1.2 它解决的问题数据散落在Excel、CSV、各个关系型数据库、甚至Hadoop集群里要把它们汇总到一处做报表、做分析、做二次加工就必然涉及抽取、转换、加载三个动作也就是ETL。Kettle就是干这件事的通过图形化拖拽把“从哪读数据、怎么洗数据、写到哪去”表达成一条可执行的数据流。拿最典型的场景来说业务系统用的是MySQL数仓在PostgreSQL每天凌晨要把订单表、用户表同步过去中间还要做字段映射、去重、类型转换——用Kettle搭一个转换之后每天双击运行或配个定时任务就行了。1.3 和同类工具的粗略对比用Kettle之前我建议你先知道它为什么不适合所有场景。DataX阿里开源的数据同步框架偏向数据库之间的高吞吐同步性能好但几乎没有可视化编排能力配置靠JSON。Airflow偏工作流调度真正写数据加工逻辑还得靠Python或者其他工具来配合不是开箱即用的ETL工具。Informatica老牌商业ETL产品功能全面但license价格对中小企业不太友好。Kettle图形化编排、多数据源支持、开源免费团队里稍微有点SQL基础的人都能快速上手。短板也很明显不适合毫秒级实时流计算也不适合超大规模分布式调度。所以在技术选型时我的判断标准很简单如果是日级、小时级的批处理数据量在百万到千万级别Kettle 7.1完全能扛住如果业务要求实时性很高或者数据量到了亿级以上的离线计算那就要考虑Flink、Spark这类重器了。2. 环境准备JDK版本、Spoon启动和驱动放置三个容易翻车的地方2.1 JDK版本要卡准别盲目装新版Kettle 7.1大约是2017年左右发布的对应的Java版本是Java 8。不要在装了Java 11或者Java 17的机器上直接跑去启动Spoon轻则界面打不开重则直接报UnsupportedClassVersionError。我的建议是生产服务器上装一个独立的JDK 8专门给Kettle用不要动系统默认的Java环境。这样做的好处是避免影响机器上其他应用。你可以在启动脚本里显式指定JAVA_HOME这样这台机器上跑其他Java程序完全不受干扰。2.2 启动Spoon和命令行工具的区分Windows环境下启动图形界面是双击>SELECT id, username, email, phone, created_at FROM t_user WHERE update_time ?Kettle支持问号占位符可以在下方“插入”里绑定一个变量或者由外部传入参数。写完SQL后强烈建议先点一下“预览”按钮查看前1000行数据确认字段名和类型都符合预期再继续往下走。4.3 表输出类型映射一定要人工过一遍再拖一个“表输出”步骤选PG连接表名填t_user。如果目标表还不存在可以点“SQL”按钮让Kettle根据输入流生成建表语句。但这里要小心Kettle自动生成的类型映射不是100%可靠MySQL的TINYINT(1)经常被映射成PG的booleandatetime的精度也可能对不上。所以自动生成的建表语句一定要人工过一遍。在“数据库字段”页签里可以手动调整字段映射也可以点“获取字段”自动映射。提交记录大小建议设为500不要保持默认的1否则大批量同步时每条记录都要单独提交一次数据库事务慢到怀疑人生。4.4 运行与调试先局部验证再整体跑点运行按钮后看下方日志。如果报错先判断是连接问题还是字段映射问题。我自己的调试习惯很笨但很有效先把两个步骤之间的跳断开分别预览两侧数据确认输入侧的字段没问题了再接上跑。也可以用“日志”步骤把中间结果打印到控制台。不要一上来就全链路跑报错之后对着整条流水线猜问题那是效率最低的排错方式。把链路拆成小段逐段验证是Kettle调试的核心方法论。4.5 增量同步的简单思路全量同步适合小表。日增量同步最朴素的写法是在作业里定义一个变量last_time每次从控制表里查出上次同步的最大时间把它传给转换里的SQL参数。下次跑的时候WHERE update_time ${last_time}就会自动只捞新增和修改的数据。这种基于时间水印的增量方式对百万级用户表完全够用不需要上更复杂的CDC方案。5. 性能与稳定性批量提交、并行、内存的调优记录5.1 表输出的提交记录大小表输出步骤里的“提交记录大小”是关键参数。默认值有时是1也就是逐条插入几万行数据能跑出天荒地老的效果。实际项目里我常用500到1000这个区间。但也不是越大越好。比如一次提交十万条一旦中途报错回滚成本很高目标库还可能出现锁等待。500到1000是一个在性能和稳定性之间比较平衡的范围。5.2 并行执行与数据库连接池的配合转换属性里有一个“并发运行”的选项勾选后不同分支可以并行执行。并行确实能提速但有一个前提数据库连接数要够用。如果机器默认连接池只有10个连接而你在转换里并行开了8个分支每个分支又要抢连接那并发反而变成互相等待。我常用的小技巧是并行不要无脑全开先明确目标库能承受多少并发写入再决定开几个分支。目标库正在做索引重建时强行并行写入大概率会把任务拖垮。5.3 JVM内存Spoon和命令行要分开看Spoon的启动脚本里可以修改-Xmx参数默认可能只有512MB或1GB处理大文件时容易OOM内存溢出。我一般调成-Xmx2048m起步。但真正上生产跑任务时用的是Kitchen/Pan命令行它们的内存参数才是重点调优对象。命令行脚本同样可以设置PENTAHO_DI_JAVA_OPTIONS比如-Xmx4096m。很多人只在Spoon里调内存生产命令行用的是默认值结果一到半夜跑大数据量就挂找半天找不到原因。5.4 驱动侧参数对批量写入的影响MySQL连接串加rewriteBatchedStatementstruePG连接的JDBC参数里加reWriteBatchedInsertstrue对批量插入的提升不是一点半点。这两个参数可以直接在数据库连接的“选项”页签里配置或者在URL里拼上。我第一次优化同步任务时只调了提交记录大小从5000行跑到几万行仍然很慢后来加了rewriteBatchedStatementstrue写入耗时直接降了一个数量级。这个参数被忽略的频率非常高。5.5 失败重试与日志定位作业的“作业属性”里可以配置失败重试次数。生产环境里我的标准流程是转换失败后向一张日志表插入一条失败记录再由外部的定时调度平台决定是否补跑。Kettle自带的日志信息很多但全量日志翻起来很痛苦。我一般只关注步骤级别的日志用关键字过滤。例如搜索ERROR和Exception先定位报错发生在哪个步骤再去看那条数据本身能省下不少时间。6. 乱码、驱动冲突和连接超时三个高频坑的排查经验6.1 中文乱码URL参数和编码设置缺一不可现象是MySQL里显示正常的中文同步到PG后变成??。绝大多数原因是连接URL没有指定UTF-8。MySQL的连接串必须加useUnicodetruecharacterEncodingUTF-8PG端一般默认UTF-8问题不大。如果是读CSV或Excel文件出现乱码那就到文件输入步骤的“编码”选项里强制指定UTF-8。还有一个比较隐蔽的原因Linux系统级的LANG环境变量没有设置好会干扰Kettle对文件编码的默认判断。遇到乱码问题我建议先看连接URL再看文件步骤编码最后看系统环境变量按这个顺序排查最快。6.2 驱动冲突同族驱动只留一个现象是之前一切正常某天启动后突然报ClassNotFoundException或者“找不到类”。最常见的原因就是lib目录里放了多个版本的mysql-connector或ojdbc驱动。Kettle的类加载顺序并不完全可控两个同族驱动并存时就是在赌运气。我的处理方法是进入style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />