★ FEATURED ARTICLE 做数据开发这几年我手上最离不开的工具就是 Kettle。不管是从业务库往数据仓库抽数还是清洗一堆乱七八糟的日志又或者是把异构系统的数据整合成统一格式Kettle 基本都是我第一个想到的解决方案。这个工具虽然名字听着老派现在官方叫 Pentaho Data Integration缩写 PDI但实实在在解决了 ETL 过程中绝大部分的脏活累活。这篇文章我不打算只甩一套安装命令就完事而是把 ETL 的基本理论、Kettle 的核心概念以及从零开始的安装部署完整地梳理一遍。适合刚接触大数据、准备做数据仓库或者数据集成开发的朋友也适合那些已经在用 Kettle 但想系统理解一遍原理的人。1. ETL基本理论先把概念讲透1.1 ETL到底在干什么ETL 是 Extract-Transform-Load 的缩写翻译过来就是抽取、转换、加载。你把它看成一套处理数据的流水线先把原始数据从各个地方“拿”出来然后按照业务需求“加工”成目标模样最后把成品“送”到指定的存储位置。这个过程听起来简单实际做起来全是细节。抽取Extract阶段要解决的是“数据从哪里来”的问题。来源可能是关系型数据库比如 MySQL、Oracle、SQL Server也可能是文本文件、Excel 表格、接口返回的 JSON 数据甚至可能是另一套系统的消息队列。这个阶段的核心难点在于数据源的数据量大不大、增量还是全量、抽取过程会不会影响业务系统的正常使用。转换Transform阶段是 ETL 的灵魂。原始数据往往不干净可能出现空值、格式混乱、编码不一致、重复记录、字段含义不清晰等问题。在这个阶段你要做的是清洗、过滤、去重、格式转换、字段映射、值替换、表关联、聚合计算等一系列操作。转换规则通常由业务逻辑决定这也是 ETL 开发中工作量最大的部分。加载Load阶段就是把处理好的数据写入目标系统。目标系统可以是数据仓库、数据集市、分析型数据库甚至只是另一个文本文件。加载方式有两种一种是全量加载直接把旧数据覆盖掉另一种是增量加载只把新增或变更的数据写进去。增量加载相对复杂需要依靠时间戳、主键比对或者日志捕获来实现。给你打个比方ETL 就好比把一个混乱的仓库改造成规范的商品陈列室。抽取是把货物从各个供应商那里运过来转换是拆包、检查、分类、贴标签加载是按顺序摆上货架。没有这套流程货物再多也是一团乱麻。1.2 主流的ETL实现形态ETL 的实现方式没有标准答案不同团队、不同场景下选择差异很大。我大致归纳成三类编码型、工具型、平台型。各有优劣并不存在谁完全替代谁。编码型就是直接用 Python、Java、Scala 或 SQL 写脚本和程序。这种方式灵活度最高能处理极其复杂的逻辑而且不用额外引入独立系统。但缺点也很明显开发周期长、维护成本高、业务人员看不懂、易出错。很多团队用 Python 的 Pandas 写数据处理脚本数据量小的时候很顺手一旦数据量上来性能和稳定性都会成为问题。工具型就是使用专门的 ETL 工具来完成工作Kettle 属于这一类同类还有 DataX、Informatica、Talend 等。工具型方案把常见的抽取、转换、加载逻辑封装成了可视化组件开发者通过拖拽和配置就能完成大部分工作上手门槛低、开发效率高、易于维护。Kettle 在这类工具里的特点是开源免费、插件丰富、社区成熟、跨平台。平台型则是依托大数据平台自带的同步或计算组件比如云服务商提供的数据集成服务、大数据平台的离线同步模块等。这类方案通常集成了调度、监控、权限控制等配套能力省心省事但定制能力往往受限而且可能被特定平台绑定。下面这张表可以直观对比三种方式实现形态灵活性开发效率维护成本适用场景编码型最高低高复杂逻辑、大规模定制工具型中等高中低日常数据集成、报表数据准备平台型最低高低云环境、标准化同步场景我自己的经验是大多数企业的数据仓库建设场景里工具型是最划算的选择。Kettle 尤其适合那种数据量在千万到亿级、转换逻辑以清洗和关联为主、需要频繁调整规则的项目。它的可视化界面让调试变得很直观出问题能快速定位是哪个环节。1.3 ETL与ELT怎么选最近几年 ELTExtract-Load-Transform这个概念越来越流行也有人喜欢拿出来和传统 ETL 做对比。两者本质区别在于转换发生的时机和位置。ETL 是在数据写入目标之前完成转换ELT 则是先把原始数据一股脑加载进目标系统再借助目标系统的计算能力来完成转换。ELT 的好处在于利用数据仓库或大数据平台的强大算力比如在云数仓、数据湖里直接跑 SQL 做转换性能往往比在 ETL 服务器上处理更强。而且只需要完成一次加载后续可以根据需求反复加工数据不需要重新抽取。但 ELT 也并非银弹。如果目标系统本身性能普通把所有转换压力都丢给它反而会拖垮查询性能。而且 ELT 模式下目标存储会堆积大量未加工的原始数据如果缺乏分层治理很容易变成数据沼泽。我给团队做技术选型时的基本判断标准是这样如果目标系统是分布式数仓或者云数据平台存储和计算资源充足那么优先考虑 ELT 思路简单直接如果目标系统是传统关系型数据库计算资源有限而转换逻辑又比较重那就老老实实用 ETL把清洗和转换放在真正的“处理层”完成。Kettle 其实两种思路都支持。你既可以把它当作 ETL 工具完成抽取、转换后再加载也可以把它当作数据搬运工只负责抽取和加载把转换交给目标数据库的 SQL 去处理。实际项目中我经常混合使用简单的清洗在 Kettle 里处理复杂的聚合计算下沉到目标库执行。2. Kettle核心概念与体系2.1 从Kettle到PDIKettle 是这套工具最初的名称后来项目被收购后改名为 Pentaho Data Integration简称 PDI。但国内用户习惯了 Kettle 这个名字社区里搜索资料时用“Kettle”反而能搜到更多内容所以它属于那种官方改名但民间一直沿用旧名的典型工具。很多初学者会疑惑Kettle、PDI、Spoon 这几个名称到底什么关系简单说Kettle 是项目名PDI 是产品名而 Spoon 是 PDI 里负责图形化设计开发的工作台界面。平时我们说的“打开 Kettle 画图”本质上打开的是 Spoon。类似的关系就像一辆车PDI 是这辆车的完整型号Spoon 是这辆车的驾驶舱。Kettle 分为社区版Community Edition和企业版Enterprise Edition。社区版完全开源免费功能上足够应对绝大多数 ETL 开发需求企业版增加了数据集成服务、调度集群、版本管理、技术支持等商业化能力。对个人学习和中小企业来说社区版就是首选没必要为那些附加能力多花钱。开源工具的优势在于插件体系。Kettle 本身的步骤组件已经很多社群还贡献了大量第三方插件比如连接各种 NoSQL 数据库、云存储、大数据组件的扩展。需要什么功能先搜一搜插件往往能省掉自己开发的一大堆时间。2.2 转换Transformation与作业JobKettle 里最核心、最容易混淆的两个概念就是转换和作业。我面试数据开发岗位时经常会问这个问题能说得清楚的人不到一半。实际上这两个概念搞清楚Kettle 的使用就理解了八成。转换Transformation是数据处理的最小容器里面放的是步骤Step和跳Hop。它描述的是“数据怎么从一个步骤流到另一个步骤”。转换的特点是步骤之间是并行执行的数据像流水一样在步骤之间流动。只要前一个步骤有数据产出后一个步骤就可以立即开始处理而不是等待全部数据完成后再开始。这种流式设计提升了处理效率但也意味着你在转换里做的“先排序后去重”之类的操作不能简单理解成按顺序执行必须通过步骤之间的跳来构造数据流。作业Job则是流程控制容器里面放的是作业项Job Entry和作业跳Job Hop。作业强调的是执行顺序和流程控制比如先执行一个转换等它成功了再执行下一个转换如果失败了就发送报警邮件某些流程走完还可以做分支判断。作业里的条目是串行执行的上一个条目的执行结果决定下一个条目的走向。两者的关系我常用车间来比喻转换是一条生产流水线上的具体工序每个工位处理一点事情产品从流水线上源源不断流过作业是整个车间的调度系统决定哪些流水线先开、哪些后开、出了问题怎么处理。实际做项目时你通常是在作业里编排多个转换并配置好顺序和异常处理逻辑。下面这个表格帮你快速区分对比项转换 Transformation作业 Job最小单位步骤 Step作业项 Job Entry连接方式数据流跳 Hop流程控制跳 Hop执行方式并行流水线串行调度核心作用数据加工处理流程编排控制文件后缀.ktr.kjb2.3 Spoon、Kitchen、Pan、Carte四件套Kettle 不只是 Spoon 这一个图形界面它由多个组件组成每个组件有不同的适用场景。了解这些组件尤其是生产环境下的调度方式非常重要。Spoon 是图形化设计工具用来创建、编辑、测试转换和作业。日常开发工作基本都在 Spoon 里进行。Spoon 的可视化界面让你可以拖拽步骤、连线配置、运行预览结果调试效率很高。这也是 Kettle 初学者最先接触的组件。Kitchen 是作业的命令行执行工具。生产环境里不可能一直开着一个图形界面去点运行按钮通常是通过调度平台定时调用 Kitchen 命令来执行作业。它读取 .kjb 文件并按照流程串行执行支持传入参数输出日志。Pan 是转换的命令行执行工具对应执行 .ktr 文件。有时候你只想跑一个转换而不需要作业的调度逻辑直接调 Pan 就行。Kitchen 和 Pan 的真正区别就是执行对象不同一个跑作业一个跑转换。Carte 是一个轻量级的 Web 服务组件。它可以把一个转换或作业发布为一个可供远程调用和监控的服务也能用于构建集群环境下的分布式执行。Carte 的出现解决了跨服务器调度的问题在某些自动化运维框架里会用它来远程触发 ETL 任务。实际项目中我常用的组合是用 Spoon 做开发调试然后在调度平台上通过 Linux 的 crontab 或者 Azkaban 之类的工具定时执行 Kitchen 命令。至于 Pan 和 Carte根据实际需要选择使用但理解它们的定位对后续运维排错很有帮助。2.4 核心步骤与跳Step Hop在转换里步骤是构成数据流的最小单元。步骤的数量和类型非常丰富粗略统计有几百种。对于刚入门的朋友不需要全部掌握先把最核心的一批步骤用好就足以应对大部分场景。表输入是最常用的抽取步骤它通过 JDBC 连接源数据库执行一条 SQL 语句来读取数据。写到这一步要特别注意Kettle 的查询逻辑很大程度靠 SQL能下推到数据库做的过滤和关联计算尽量在 SQL 里完成会大幅减少数据传输量提升整体性能。表输出是加载步骤把流里的数据写入目标表。这个步骤里有一个提交批次Commit Size参数决定了每累积多少条数据提交一次事务。这个参数非常影响写入性能默认配置往往不是最优值我在调优部分会专门说到。其他常用的还有字段选择控制字段顺序和保留哪些列、排序记录按指定字段排序、去除重复记录去重、字符串替换清洗字符、值映射把字典值翻译成业务含义、表输入输出之外的各种数据库步骤、文件输入输出、HTTP 客户端等。跳Hop是步骤之间的数据连接线它定义了数据的流向。跳还可以设置条件实现数据路由比如根据某字段的值把数据分到不同的处理分支。这种条件跳在复杂清洗场景里很实用可以避免一个步骤里写死太多逻辑。理解步骤和跳的关系核心是要理解数据流是单向的、并行流动的。你在 Spoon 里看到的是一个有向图数据从上游步骤进入下游步骤每个步骤对经过的数据做一次或多次处理然后继续传给下一个步骤。3. 安装部署全流程实录3.1 环境准备JDK版本的坑Kettle 是基于 Java 开发的工具所以安装前必须先准备好 Java 环境。这一步最容易被忽略也是安装失败率最高的环节。很多朋友装好 Kettle 后双击启动图标没反应打开日志一看全是 Java 相关的报错。Kettle 8.x 和 9.x 版本通常要求 JDK 8。官方文档推荐的版本是 Java 8并不是说更高版本完全不能用但实践中用 JDK 9 以上会遇到一些依赖库兼容性问题比如某些组件调用已被移除的 API导致连接数据库或运行某些插件时报错。如果你上生产环境我建议直接装 JDK 8省心稳定。安装 JDK 之前先检查系统里是否已经有 Java。在命令行执行java -version如果系统输出的版本不是 1.8 系列或者提示命令找不到就需要自己安装。Linux 环境下可以用包管理器安装 OpenJDK 8比如 CentOS 上用 yumUbuntu 上用 apt。Windows 环境则需要从官网下载安装包并配置 JAVA_HOME 环境变量。安装完成后在命令行再次验证版本。注意要确认 JAVA_HOME 指向的是 JDK 安装目录而不是 JRE 目录。Kettle 启动脚本里会依赖 JAVA_HOME 来定位 Java 可执行文件路径不对就会启动失败。内存方面Kettle 默认堆内存设置并不大数据量稍大就容易出现内存溢出的问题。建议给运行 Kettle 的机器预留至少 4GB 内存后续根据实际数据量调整 JVM 堆内存参数。具体怎么调我放在后面的性能调优部分细说。3.2 下载安装分平台操作Kettle 社区版的下载渠道主要是两个Pentaho 官网的下载页面和各种开源镜像站。官网下载需要注册账号而且下载速度在国内不算理想镜像站更方便一些速度也更快但要注意选择官方发布的稳定版本别下到来路不明的改动版。如果你是做普通的数据集成开发选择最新的稳定版本就行不必追求每周发布的快照版本。下载文件通常有两种格式Windows 对应 .zipLinux 和 macOS 对应 .tar.gz。这里以 Linux 环境为例演示完整的安装流程。把下载好的压缩包上传到服务器上的某个目录比如 /opt 下。然后执行解压命令tar -zxvf pdi-ce-9.4.0.0-343.tar.gz -C /opt解压完成后会生成一个类似>chmod x /opt/data-integration/*.shWindows 上的安装更简单下载 .zip 压缩包后直接解压到指定目录然后双击 Spoon.bat 即可。不需要写注册表也不需要额外安装服务真正的绿色软件。macOS 用户和 Linux 操作基本一致只是个别脚本后缀可能有差异按官方文档处理即可。3.3 启动Spoon与验证启动 Spoon 有两种方式有图形界面的环境下直接运行启动脚本打开操作界面纯命令行环境下可以通过 Pan 和 Kitchen 运行已编写的转换和作业。这里先说图形界面的启动。在 Windows 上进入解压目录后双击 Spoon.bat。在 Linux 的桌面环境下在终端进入>./spoon.sh首次启动会有一个初始化过程需要加载插件和组件可能等待十几秒甚至更久耐心等就好。启动成功后你会看到 Spoon 的主界面左边是组件面板中间是画布区域右边可以显示数据库连接等资源信息。界面能打开只是第一步强烈建议你做一个最简单的转换验证整个链路是否真的可用。在 Spoon 里新建一个转换从输入分类里拖出一个“生成随机数”步骤运行它查看输出结果。如果这一步能正常生成数字并预览出来说明 Kettle 的核心运行环境是好的。接下来再测试数据库连接。在左侧主对象树里找到数据库连接右键新建一个连接填好连接类型、主机、端口、数据库名、用户名和密码点击测试按钮。如果提示连接成功恭喜你整个部署链路基本完成。如果测试失败大概率是驱动或者 URL 格式的问题下面的小节我会专门讲驱动部署。3.4 数据库驱动放在哪里Kettle 通过 JDBC 连接数据库所以每种数据库都需要对应的驱动 Jar 包。Kettle 自带了一些常见的驱动但版本往往比较老连接新版数据库时经常会出现找不到驱动类或者版本不兼容的报错。解决方法是手动下载对应数据库的驱动 Jar 包放到 Kettle 的 lib 目录下然后重启 Spoon。这个目录是 Kettle 存放运行时依赖库的固定位置所有步骤都会从这个目录加载类。以最常用的 MySQL 为例。如果你连接的 MySQL 是 5.x 版本使用驱动 mysql-connector-java-5.1.48.jar 一般没问题。如果连接的是 MySQL 8.x就要使用 8.0 系列的驱动比如 mysql-connector-java-8.0.20.jar。用 5.x 驱动去连 MySQL 8通常会在连接时报错说认证方式或者通信协议不支持。连接 MySQL 8 时的 JDBC URL 也要留意Kettle 里数据库连接那里需要填写的 URL 大致是jdbc:mysql://主机地址:3306/数据库名?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingUTF-8serverTimezone 参数尤其重要不设置的话很可能报错说无法识别服务器时区。allowPublicKeyRetrieval 是 MySQL 8 的认证机制问题某些场景下不加也会连不上。这两个参数是我踩过坑之后总结出来的。Oracle 数据库则是把 ojdbc 系列驱动放到 lib 目录下。注意不同的 Oracle 数据库版本要匹配不同的驱动版本最简单的办法是直接从目标数据库的安装目录里拷贝正在使用的驱动 Jar。数据库连接配置完成后一定要在 Spoon 里点测试按钮验证确认无误再开始建转换、写任务。很多人跳过这一步结果等到执行的时候才发现驱动有问题排查起来更费时间。4. 常见问题与排查实录4.1 新手高频问题速查表Kettle 部署和使用过程中有不少共性问题我整理了一张速查表都是实际项目中反复出现的高频坑。现象常见原因解决办法双击 Spoon 没反应或启动闪退JAVA_HOME 配置错误、JDK 版本不匹配、内存不足检查 JDK 版本确认 JAVA_HOME 指向正确目录调大 JVM 内存参数界面或日志中文乱码默认字符集不是 UTF-8在启动脚本中设置 UTF-8 编码参数或配置系统默认编码连接 MySQL 报 ClassNotFound驱动 Jar 没有放到 lib 目录或驱动版本不匹配下载匹配版本的驱动放入 lib 目录后重启连接 Oracle 报驱动异常ojdbc 版本与数据库版本不匹配从数据库所在服务器上获取对应版本的 ojdbc预览或运行时内存溢出堆内存配置过小、加载数据量过大调整 JVM 的 -Xms 和 -Xmx 参数优化转换减少一次性加载找不到资源库或默认资源库异常用户没有 .kettle 目录下的资源库配置文件重新配置资源库或恢复到文件资源库模式作业执行失败但日志不明显作业项本身没有配置错误处理逻辑在作业里为每个作业项增加失败处理分支和日志输出4.2 内存与并发调优Kettle 的默认内存配置比较保守处理稍大规模的数据就会出现内存溢出的问题。我之前帮某公司排查过一批定时任务频繁报错最后定位就是堆内存太小默认只有 256MB 左右根本跑不动百万级别的数据。调优的方法是修改启动脚本里的 JVM 参数。在 Linux 下编辑 spoon.shWindows 下编辑 Spoon.bat。脚本里有一段类似如下的配置PENTAHO_DI_JAVA_OPTIONS-Xms512m -Xmx1024m把 -Xmx 调整到适合当前机器的值比如 4GB 的机器可以设置成PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx3072m -XX:MaxPermSize256m需要注意的一点是调整的参数是给 Spoon 图形界面用的。如果你是在生产环境通过 Kitchen 或 Pan 命令行执行任务它们各自也有对应的启动脚本需要分别调整。除了堆内存还要学会从转换设计上减少内存压力。比如表输入步骤里如果数据量很大尽量在 SQL 里完成过滤和聚合只把真正需要的数据拉回来。不要在 Kettle 里加载全表再做过滤那是把问题从数据库转移到了 ETL 工具里。表输出的提交批次 Commit Size 也很重要。数据量大时默认每提交一次事务带来的开销会非常明显。我通常会把 Commit Size 设置成 1000 或 2000实测下来写入性能会有明显提升。但要根据目标数据库的事务能力来调整某些数据库对大事务比较敏感设太大会占用过多锁资源需要权衡。多个转换并行执行时要留意 CPU 和数据库连接数。在作业里并行启动多个转换虽然能缩短总耗时但可能把数据库的连接池打满反而拖垮源库。合理的做法是控制并发度或者把不同任务的执行时间错开。4.3 资源库选型文件库还是数据库库Kettle 里的转换和作业可以保存在两种地方本地文件系统和数据库资源库。这个选择直接影响团队协作模式和版本管理方式建议一开始就规划清楚。文件资源库是 Kettle 的默认方式。你新建的转换和作业会以 .ktr 和 .kjb 文件保存在本地。好处是简单、直观单机开发毫无压力也方便拷贝给其他人还能直接纳入 Git 做版本管理。我就是把这个目录当成代码目录来管理的每次修改都提交版本库出问题可以随时回退。数据库资源库则是把转换和作业的元数据存到数据库里适合团队多人协作。所有成员连接到同一个资源库就能看到彼此开发的作业和转换。它的好处是有权限控制、可以锁定编辑状态多个同事不会互相覆盖。但缺点是依赖数据库可用性资源库本身如果挂了所有人的开发工作都会受影响。我的建议是个人学习、单机测试、或者团队规模比较小且开发规范成熟优先用文件资源库加 Git 的方式。它最灵活也最容易备份恢复。如果团队人数多、需要集中管理和控制权限那就部署数据库资源库。两者并不互斥你可以同时在本地保留文件资源库和数据库资源库的连接按项目需要切换。Kettle 的资源库配置文件默认存放在用户主目录下的 .kettle 文件夹里比如 Linux 的 /root/.kettle。如果迁移机器把整个 .kettle 目录拷贝过去大部分配置就能跟着走包括数据库连接信息。这里提醒一下数据库连接密码在配置文件中是可逆加密的迁移时要确保源配置文件的密钥一致性否则连接密码会验证失败。我在实际项目里还发现一个很实用的小技巧转换和作业里尽量用变量和参数来配置数据库连接、文件路径等信息比如数据库连接配置里使用 ${DB_HOST} 这种占位符在执行时动态传入。这样开发环境和生产环境之间切换时就只需要改参数不用改动作业本身。配合资源库使用效果特别好。最后再分享一个让我印象很深的小经验。某次线上执行任务一直失败日志里没有任何明显异常后来发现是目标数据库表结构发生了迁移字段名和转换里配置的完全对不上。这种问题其实最好防每次发布作业前在 Spark 上… 不对在 Spoon 里做一次完整的执行测试确认输入输出都正常再部署到生产调度平台。Kettle 这个工具本身不复杂但围绕它的工程习惯和细节决定了你在数据开发这条路上能走多快、走多稳。
阅读完成 · 觉得有帮助？
