企业官网建设流程全解析

简介：这是一份Pentaho Data Integration（Kettle）8.2社区版完整安装包，面向ETL开发、数据仓库建设及数据库间数据迁移场景，适合需要在Windows、Linux或Unix环境下手动部署Kettle并开展数据抽取、转换、加载工作的工程师。包体共1884个文件，大小约979.51MB，以jar运行库为主体，同时包含200个ktr转换文件、19个kjb作业文件，以及xml、properties、cfg等配置文件，另有bat/sh启动脚本、readme说明文档及少量示例数据文件，既可用于跨平台作业调度，也可作为学习Kettle工程结构的参考范例。已有463人学习下载。借助这份资源可快速搭好一套离线可用的Kettle运行环境，内置Spoon图形化设计器、Kitchen作业调度、Pan转换执行等常用工具入口，便于直接开展开发、调试与运维；同时大量配置和示例文件能帮助读者理解Kettle的目录组织、类型定义和跨平台部署要点，对想要系统掌握ETL流程的中高级数据工程师尤其有价值。

1. 拿到 pdi-ce-8.2.0.0-11.zip 之后：先别急着解压，先搞清楚它能干吗

做数据开发的人大概率都听过 Kettle，现在官方叫法 Pentaho Data Integration，简称 PDI。这个 pdi-ce-8.2.0.0-11.zip 就是 PDI 社区版 8.2 的整套发行包，大概 1GB 出头的压缩体积，解压出来是一个完整的 ETL 工具箱，不需要安装，改改配置文件就能跑。它能做的事很直白：把数据从 A 库抽出来，清洗、转换、合并，再灌进 B 库，全程用图形化拖拽完成，不写 Java、不写 Python 也能搭出稳定跑批的数据管道。适合谁？比如你在维护一个传统数仓，每天要从好几套业务库同步数据，或者你刚接手一个别人用 Kettle 做的存量调度任务，想本地复现、改改逻辑看看效果——这个版本就是那个「别人家的生产环境」最常见的版本之一。先说明白一点，这是个老版本，网上资料最多、坑基本都被踩平了，拿来学习或者接手存量项目反而比追新版更稳。

2. 部署与启动：JDK 8 匹配、环境变量和内存参数一次说清

2.1 解压结构与目录职责

这个 zip 解压后会出现一个># 解压（Linux 环境示例） mkdir -p /opt/etl && cd /opt/etl unzip pdi-ce-8.2.0.0-11.zip cd># Linux / macOS export PENTAHO_JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export PENTAHO_JAVA_HOME=/opt/jdk1.8.0_202 # 按实际路径改

Windows 用户在系统环境变量里新建PENTAHO_JAVA_HOME，值填 JDK 8 的安装根目录，比如C:\Program Files\Java\jdk1.8.0_202，不要带\bin。配置完之后建议先跑一下Spoon.bat看启动日志，也可以直接看spoon.log文件确认它用的是哪个 Java。

2.3 内存参数调优：默认配置不够用的时候

Kettle 默认的 JVM 堆内存比较保守，Spoon.bat里初始堆是 512MB，最大堆 1GB。处理几十万行数据没问题，但如果你要预览一张千万级表，或者跑大事务、复杂流查询，很容易直接 OutOfMemoryError。改内存的方法不是去改spoon.bat里的 JVM 参数（虽然也能改），更正规的是去改># Windows set PENTAHO_DI_JAVA_OPTIONS="-Xmx4096m" "-Xms1024m" "-XX:MaxPermSize=256m" # Linux / macOS export PENTAHO_DI_JAVA_OPTIONS="-Xmx4096m -Xms1024m -XX:MaxPermSize=256m"

注意 8.2 版本已经不需要MaxPermSize了，这个是 JDK 7 时代的遗产，写了也不报错但也没意义。生产环境我一般给到 4GB 到 8GB，取决于你机器的物理内存。如果你是拿笔记本调试 50 万行以内的数据，默认的 1GB 反而够用，不要一上来就堆大内存，GC 停顿反而会让界面卡顿。

3. 跑通第一个 ETL 流程：从数据库到数据库的完整链路

3.1 理解转换、作业和步骤这三个核心概念

在动手拖拽之前，必须先把 Kettle 的三个层次概念理清。转换（Transformation）是最小的 ETL 流程单元，它描述数据怎么从一个或多个输入步骤流经若干处理步骤，最终到达输出步骤。作业（Job）是编排层，它串行或并行地执行多个转换，还能做条件判断、发送邮件、FTP 下载这些转换做不到的事。步骤（Step）就是画布上那些方框，每一个负责一件具体的事：读表、过滤、字段选择、写表。

这里有个新手特别容易混淆的点：转换内部是并行流式的，步骤之间通过「跳」（Hop）连接，数据是一行一行往下游推的；但作业内部默认是串行的，只有通过「成功」跳线才能形成流程控制。所以你在作业里拖五个转换，它们不会同时跑，如果你的业务预期是并行执行，记得再补一条「并行」跳线。

首次打开 Spoon，它会问你资源库怎么配，我建议选「没有资源库」，直接把转换保存成.ktr文件、作业保存成.kjb文件。文件即配置，这样用 Git 能追踪每个人的改动，比存在数据库资源库里清楚得多。

3.2 新建转换：表输入到表输出的最小配置

打开 Spoon，文件 → 新建 → 转换，左侧面板找到「输入」分类下的「表输入」，拖一个到画布；再在「输出」分类下找「表输出」，拖一个。用 Shift 键点击表输入步骤的下边缘，拖出一条连线到表输出步骤的上边缘，跳就建立好了。

先双击「表输入」，点「新建」按钮配置数据库连接。这里填的是源数据库的连接参数：

连接名称: 源业务库 连接类型: MySQL 主机名: 192.168.1.10 数据库名称: oa_db 端口: 3306 用户名: etl_user 密码: xxxxx

填完之后点「测试」，Kettle 会去加载 MySQL 驱动。这里注意：PDI 8.2 自带的是老版本 MySQL 驱动，Connector/J 5.1.x，连 MySQL 5.7 没问题，但连 MySQL 8.x 经常报Public Key Retrieval is not allowed或者Communications link failure。这不是你参数填错了，是驱动太老。

表输入步骤里写 SQL 的地方，支持直接写带参数的原生 SQL：

SELECT order_id, user_id, total_amount, status FROM orders WHERE create_time >= '2024-01-01' AND create_time < '2024-02-01'

写完 SQL 可以点「预览」按钮，Kettle 会真的去执行并返回前 1000 行数据，这一步是排查 SQL 写没写错的最高效手段，别跳过。

再双击「表输出」，同样新建一个目标数据库连接，目标表名填ods_orders，点「SQL」按钮让 Kettle 帮你自动生成建表语句（它会把源字段类型按照自己的映射规则转换成目标库类型），确认后执行建表。

3.3 字段映射与数据流预览：先跑通再优化

保存转换，点击工具栏的「运行」按钮，Kettle 会执行整个流程。如果一切顺利，你会看到步骤上出现绿色的对勾和运行计数。但第一次跑不顺太正常了，最大的坑是字段映射不匹配——比如源库字段是total_amount类型 decimal(10,2)，目标表建成了 int，数据精度就丢了。

Kettle 里查字段映射的位置是「表输入」步骤的预览结果里，点左下角的「获取字段」按钮，它会列出 SQL 返回的字段名、类型、长度。然后去「表输出」步骤里点「输入字段映射」，人工对齐两边的字段，这一步别偷懒。自动映射只认同名同类型，不同名的一律忽略，你如果源是user_id目标是uid，不手动映射它就直接丢字段，不会报错。

跑通一次之后，建议在表输出步骤勾选「Truncate table」选项，这样每次测试跑完，目标表会被清空再写入，保证测试可重复。正式环境记得取消这个勾选项，否则你的增量策略会被这行配置直接毁掉。

4. 生产环境逃不过的坑：驱动、编码、时区和调度

4.1 坑一：MySQL 8 驱动不兼容，报表不是报错就是连不上

现象：数据库连接测试永远失败，报SSL connection error或者Unable to load authentication plugin 'caching_sha2_password'。原因：PDI 8.2 内置的 JDBC 驱动是 MySQL 5.x 时代的，而 MySQL 8 默认的认证插件是 caching_sha2_password，老驱动不支持。解决：手动下载mysql-connector-java-8.0.22.jar，放到>./kitchen.sh -file=/opt/etl/jobs/daily_sync.kjb -level=Basic -logfile=/var/log/etl/daily_sync.log

5. 参数化与命令行调度：把 Spoon 里点得动的流程变成服务器上自动跑的任务

5.1 变量与参数：让同一个转换服务多张表

调试阶段你可能是为orders表专门写了一个转换，但生产上每个月都要新增一张分表，或者同一套抽数逻辑要套在users、products上。这时候就得做参数化。

Kettle 里的参数机制分三层：命令行参数、全局变量、变量作用域。最常用的是命令行参数，在转换或作业的「属性 → 参数」里定义参数名，然后在 SQL 里用${PARAM_NAME}引用。比如表输入的 SQL 写成：

SELECT * FROM ${source_table} WHERE modify_time >= str_to_date('${start_time}','%Y-%m-%d %H:%i:%s')

在 Spoon 里点运行，会弹出参数输入框，填当前值就行。命令行调度的价值才真正体现出来，不需要打开界面：

./pan.sh -file=/opt/etl/trans/extract_orders.ktr \ -param:source_table=orders_2024 \ -param:start_time="2024-02-01 00:00:00" \ -level:Basic \ -logfile=/var/log/etl/extract_orders.log

这里注意-param和-level的写法：-param:K=V中间没有空格，日志级别参数是-level而不是-log-level，大小写也敏感。拼错的时候 Kettle 不一定报错，可能只是静默忽略参数，导致 SQL 里出现字面量${start_time}，这个最坑——转换还是能跑，但抽出来的数据不是你想的。参数名建议全小写下划线，别带特殊字符，否则在 Linux shell 单引号嵌套上可能出各种幺蛾子。

5.2 作业编排：串行、并行与失败重试

转换之间通常有顺序依赖：先抽明细表，再基于明细宽表做汇总，最后把汇总结果推送到报表库。这个编排逻辑写在作业里，而不是靠 cron 串一串脚本。

新建作业，拖入「START」步骤作为起点，再加「转换」步骤（注意是作业分类下的，不是转换里的步骤），双击配置选择对应的.ktr文件。START → 转换 → 转换 → 成功跳线连到最后再拖一个「成功」输出。作业默认串行，如果某个环节失败，会沿「失败」跳线运行，此时可以加一个「发送邮件」步骤通知值班的人。

我遇到过一种特殊情况：两个转换确实没有依赖关系，但业务上希望尽量在窗口期内跑完。这时候把「START」设为并行，用多条跳线分别指向两个转换即可。不过并行对资源的要求高，8 核 16GB 以下的小服务器并行两个大转换不见得比串行快，GC 还会跳动造成假死，一般配置 2 到 3 个并发就是甜蜜点。

5.3 cron 调度与日志轮转：注意环境变量继承

到了这一步，ETL 基本算能自动跑了。cron 配置：

# 每天凌晨 1 点执行作业 0 1 * * * /opt/etl/data-integration/kitchen.sh -file=/opt/etl/jobs/daily_sync.kjb -level:Basic -logfile=/var/log/etl/daily_$(date +\%Y\%m\%d).log

有一个细节值得记住：cron 执行时的 PATH 和 SHELL 环境比你终端登录时少很多，JAVA_HOME经常没继承过来。所以要么在kitchen.sh执行前面先 sourcing 一个环境变量脚本，要么在.bashrc里 export 完后用bash -lc包一层。否则你会看到 cron 日志里写着Java not found，但在终端手动执行完全正常——这个排查起来血压容易升高。

6. 数据比对验证：一种靠日志和计数就能定位同步偏差的技巧

我每次写完一个 Kettle 同步流程，不会直接用 join 去比对两边数据是否一致——大表 join 一次开销不小，跑批窗口也紧张。我的习惯做法是在转换里挂两个「统计」途径，一个在表输入末尾数据流上，一个在表输出末尾数据流上：

在表输入步骤后面拖「数量统计」步骤，它会读通过的总行数和字段总和；表输出成功后拖一个「复制记录到结果」步骤，在下游接一个「获取变量」读取刚才的计数。这样每次跑完，日志里就能看到src_rows=123456和dst_rows=123456两行，数字不一致说明中间丢了数据，直接缩小范围到转换的清洗逻辑里。

更进一步，做增量同步时数据校验可以落在 SQL 上，不用每次全量拉出来比。我在目标库里建一张校验表，记录每个任务本次执行的min(id)和max(id)，下次跑批前拿出来与源库的MIN(MAX)对比，超出边界就发警告。这种思路不需要在 Kettle 里做复杂配置，派一个「执行 SQL 脚本」步骤，在作业开始前跑一条对比 SQL，返回结果集第一条当条件变量判断即可：

SELECT CASE WHEN (SELECT MIN(id) FROM ods_orders WHERE batch_date = '${batch_date}') < (SELECT MIN(update_id) FROM src_orders WHERE last_update >= '${start_time}') THEN 'gap_detected' ELSE 'ok' END AS check_flag

Kettle 作业里拖一个「检查字段」步骤，如果字段值等于gap_detected就走失败跳线发警告，否则继续跑后面正常流程。这样做的好处是：你不需要停业务，也不用等跑批结束才发现问题，数据边界出问题的瞬间就能在日志里暴露。

从那以后，我每次部署 Kettle 批量流程，第一件事不是看界面能不能拖通，而是先确认日志输出和计数校验路径是完整的——宁可流程晚 10 分钟上线，也不能让一个错误数据在报表里躺一整天没人知道。这是不是最优雅的方案我不敢说，但至少帮我在无数次凌晨的告警电话里保住过睡眠。希望这些经验对你有用。

本文还有配套的精品资源，点击获取