企业官网建设流程全解析

简介：pdi_ce7.1.0.0-12.zip 是 Pentaho Data Integration（PDI）7.1 社区版（Kettle）的打包发布版，面向数据集成、ETL 开发与运维人员，用于完成多源数据抽取、清洗、转换与加载，属于 2018 年的免费开源发行版。包内共收录 1928 个文件，大小约 861.99MB；1302 个 jar 库文件构成运行主体，200 个 ktr 转换与 19 个 kjb 作业提供了可直接参考的流程样例，并配有 xml/cfg/properties 等配置、bat/sh 启动脚本以及 png、md 等文档资源，整体目录组织清晰。这一安装包已有 3430 人学习下载。解压并配置>sha256sum pdi_ce7.1.0.0-12.zip

输出一串 64 位十六进制字符串，和发布方给的摘要比对。一致再继续，不一致直接重传，别在坏包上浪费时间。

第二件事是测压缩包本身的完整性。我一般用 unzip 的测试模式：

unzip -t pdi_ce7.1.0.0-12.zip

这个命令会把包内所有文件解压到内存并校验 CRC，不落盘。如果输出末尾是No errors detected in compressed data，说明包结构完好。如果出现missing zip entry或者bad CRC，说明包已经损坏，解压动作再华丽也是白搭。

2.3 解压后目录结构确认命脉文件

完整性验证过了再解压。解压出来你会看到一个>ls -l>java -version

期望看到类似：

openjdk version "1.8.0_392" Java(TM) SE Runtime Environment (build 1.8.0_392-b03)

如果输出的是 17 或 21，别犹豫，装 JDK 8。内网机器上可以一个机器共存多个 JDK，不影响，关键是把 PDI 启动时要用的 JAVA_HOME 指对。

3.2 解压位置和目录权限：别放根目录，别用 root 跑

我一般把 PDI 解压到/opt/pdi/下，用专门的服务账号运行，而不是直接拿 root 跑。原因不是安全问题，而是 Kettle 会在运行时写.kettle缓存目录和日志文件，如果拿 root 跑，生成的临时文件后续会变成别的问题。

mkdir -p /opt/pdi cp pdi_ce7.1.0.0-12.zip /opt/pdi/ cd /opt/pdi unzip pdi_ce7.1.0.0-12.zip mv>export PENTAHO_JAVA_HOME=/usr/lib/jvm/java-1.8.0 export PENTAHO_HOME=/opt/pdi/pdi-ce-7.1

然后让环境变量生效：

source /etc/profile.d/pdi.sh

验证能不能起来。先跑命令行工具，不启动图形界面，因为服务器上往往没装 X11：

cd /opt/pdi/pdi-ce-7.1 ./kitchen.sh -version

能打印版本信息说明基础环境没问题。随后再验证 Spoon 图形界面，在有桌面环境的机器上执行：

./spoon.sh

第一次启动会慢一些，等日志刷完出现主窗口就成功了。如果开始窗口都不出现，看.kettle/spoon.log里的异常栈。

3.4 把 Kitchen 注册成本地服务：让 zip 包不再是临时工

热词里有一类提问是“如何在 Windows 中手动把 zip 包设置成本地服务”，这个需求在 PDI 这里非常典型：你不可能每天手动点 Spoon 执行定时任务，要让 ETL job 自己跑起来。常见做法是用 systemd 管理 Kitchen 命令。

写一个 service 单元文件/etc/systemd/system/pdi-kitchen.service：

[Unit] Description=Pentaho Data Integration Kitchen After=network.target [Service] Type=oneshot User=etl Environment=PENTAHO_JAVA_HOME=/usr/lib/jvm/java-1.8.0 Environment=KETTLE_HOME=/opt/pdi/pdi-ce-7.1 WorkingDirectory=/opt/pdi/pdi-ce-7.1 ExecStart=/opt/pdi/pdi-ce-7.1/kitchen.sh -file=/data/etl/jobs/main_job.kjb -level=Basic -logfile=/var/log/pdi/etl.log [Install] WantedBy=multi-user.target

注意Type=oneshot，因为 Kitchen 执行完 job 会正常退出，不是常驻进程。配好之后systemctl start pdi-kitchen手动跑一次，配合 crontab 的定时调用，PDI 就有了本地任务调度能力。

4. 调参：内存、编码、时区这三个参数决定 PDI CE 稳不稳

PDI 7.1 装好能启动只是第一步，实际跑数据的时候才会暴露问题。遇到最多的三类问题分别是内存溢出、中文乱码、时间差 8 小时。全部能在启动参数层面提前规避。

4.1 JVM 内存：调整 spoon.sh 和 kitchen.sh 里的启动参数

PDI 默认的 JVM 堆内存是 256 MB 起步，跑生产数据转换时远远不够。数据量大一点的表输入，几千行缓存就能把堆撑爆，然后报java.lang.OutOfMemoryError: Java heap space。

修改spoon.sh，找到PENTAHO_JAVA_OPTIONS这一段，建议改成：

PENTAHO_JAVA_OPTIONS="-Xmx2048m -Xms512m -XX:MaxMetaspaceSize=512m"

kitchen.sh、pan.sh、carte.sh同理，各自改各自的。注意 7.1 版本跑在 JDK 8 上，所以不存在 PermGen 的问题，用的是 Metaspace。如果你在网上搜到-XX:MaxPermSize=256m这种老参数，那是 JDK 7 时代的，JDK 8 里已经不认识这个参数了。

-Xmx的取值要看机器内存。数据转换如果是基于内存的流式处理，2 GB 够用；如果涉及大数据量的排序和分组，建议 4 GB 起步。别一次性把机器内存全给 JVM，PDI 本身还要留内存给操作系统和 JDBC 驱动的网络缓冲。

4.2 统一字符集：乱码的表名、字段名和文件内容

PDI 7.1 默认字符集跟随系统，也就是file.encoding取系统默认值。内网服务器很多配的是 POSIX 或 C locale，默认编码是 ASCII，中文直接变问号。

解决方法是强制 JVM 用 UTF-8。在spoon.sh的PENTAHO_JAVA_OPTIONS里追加：

-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8

同时，在 Spoon 图形界面的转换设置里，把“表输入”“文本文件输入”这些步骤的编码统一指定为 UTF-8。特别是文本文件输入步骤，它自带一个文件编码选项，不指定就按系统默认来，CSV 里的中文大概率乱。

还有一种隐蔽情况：数据库表里数据正常，但 SQL 语句里带中文条件查不到。这种通常是 JDBC URL 里没指定字符集参数。连接 MySQL 时 URL 里加上characterEncoding=utf8，这个参数的作用是告诉驱动以 UTF-8 编码发送 SQL 和读取结果。

检查当前 PDI 实际运行的编码，可以在转换里用“生成行”步骤输出Java 系统属性 file.encoding的值确认。

4.3 时区与 JDBC 驱动：时间差了 8 小时，问题不在 PDI

PDI 从 MySQL、PostgreSQL 读 timestamp 类型时，JDBC 驱动会按 JVM 默认时区解析。如果 JVM 时区和数据库实例时区不一致，读出来的时间就会偏移。

统一改法，在PENTAHO_JAVA_OPTIONS里显式指定时区：

-Duser.timezone=Asia/Shanghai

同时，MySQL 连接串上加参数：

jdbc:mysql://host:3306/db?useSSL=false&serverTimezone=Asia%2FShanghai&characterEncoding=utf8

这里serverTimezone是给 MySQL Connector/J 8.x 用的参数，告诉驱动数据库服务器时区，避免驱动自动探测时区失败而报错。注意 URL 里时区要用 URL 编码，Asia/Shanghai里的斜杠要写成%2F。

时区和编码问题都是那种“平时没事、一到跨时区任务或者双字节数据就抽风”的坑，统一在启动参数里锁死，比在每一个转换步骤里单独设置可靠得多。

下面是 7.1 版本我常用的启动参数速查表：

5. 避坑：pdi_ce7.1.0.0-12.zip落地时最常翻车的五个点

这个 zip 包本身不算复杂，但把它变成一台稳定运行的数据处理服务，中间有不少坑。我按自己的踩坑频率排了个序，每条都按现象、原因、解决的路径说明。

5.1 zip 伪加密：解压时要求输密码，但包其实没密码

现象：用 unzip 解压pdi_ce7.1.0.0-12.zip，报错要求输入密码。网上搜这个问题能搜到一堆“zip 密码移除”的教程，但实际上很多不是真加密。

原因：zip 文件头的 general purpose bit flag 里第 0 位表示加密。有些传输工具或杀毒软件扫描会把这位置位，但文件数据实际没加密，就成了伪加密。另一种常见情况是包在传输过程中头部字节损坏，被 unzip 误判为加密。

解决：先用zipinfo -v pdi_ce7.1.0.0-12.zip看加密标志位。如果显示Encryption: none但 unzip 仍要密码，说明是伪加密，可以用 7-Zip 解压——它对伪加密的容忍度高很多。如果 7-Zip 认不了，包修复风险大，直接回去重新下载并比对 sha256。

5.2 解压中途报 CRC 错误或 missing zip entry

现象：unzip 解压到一半，突然报CRC error ... missing zip entry，解压出来的目录里文件不全。

原因：下载过程文件偏移被破坏。FTP 传输时用了 ASCII 模式会把二进制数据搞坏，或者断点续传工具在服务端不支持 resum 的情况下续传出了错。

解决：删除解压出的残缺目录，重新传输，传输结束后先unzip -t验证再解压。对内网大文件传输，建议对比源文件的 sha256 和接收文件的 sha256，两个值一致再进入解压流程。

5.3 spoon.sh 双击没反应或一闪而过

现象：Linux 桌面环境下执行./spoon.sh，终端没有任何输出，窗口没起来；或者窗口闪一下就没了。

原因：绝大部分是 JAVA_HOME 环境变量没设置，或者指向了错误的 JDK 版本。Kettle 启动脚本spoon.sh里对 Java 的检测逻辑是，找不到PENTAHO_JAVA_HOME就找JAVA_HOME，两个都没有就直接退出。另外如果 DISPLAY 环境变量没设置，Spoon 会尝试无头模式启动失败。

解决：先确认环境变量：

echo $PENTAHO_JAVA_HOME echo $JAVA_HOME

再手动带参数启动看报错信息：

./spoon.sh -debug

把启动过程的完整输出打出来，就能看到是 Java 没找到还是 X 窗口连接失败。我遇到最多的是直接在 SSH 会话里执行./spoon.sh，没有-X转发或本地 DISPLAY，Spoon 根本没地方画窗口。

5.4 PDI 7.1 里选中“表输入”步骤但看不到 Oracle/DB2 驱动

现象：Spoon 里建了个数据库连接，选 Oracle 驱动时下拉列表是空的，或者连 Database 类型里根本找不到 Oracle 分类。

原因：PDI 社区版出于许可证考虑，默认不带 Oracle JDBC 驱动（ojdbc）。DB2 也是类似的情况。所以不是你没安装对，是驱动根本没在包里。

解决：从 Oracle 官方下载对应 JDK 8 的 ojdbc8.jar，放到lib/目录下，重启 Spoon。注意 7.1 版本对应 ojdbc8，不是 ojdbc11。放错版本会在连接时报ORA-01017或类版本冲突。

5.5 Kitchen 跑 job 到一半内存溢出，之前明明调大过 Xmx

现象：kitchen.sh启动时终端里显示-Xmx4096m生效了，但 job 跑到一半还是报OutOfMemoryError: Java heap space。

原因：修改的PENTAHO_JAVA_OPTIONS可能写在set-env.sh里面，而kitchen.sh启动时读取配置的优先级和spoon.sh不一样。另外有些 job 里嵌套了子转换，每个子转换会在独立的 JVM 里跑起来，这时需要给所有可能启动子进程的脚本都加上同样参数。

解决：检查/etc/profile.d/pdi.sh之外，还要在kitchen.sh头部确认实际读到的参数：

echo $PENTAHO_JAVA_OPTIONS

我一般把 JVM 参数固化在所有脚本的公共配置里，确保 spoon、pan、kitchen、carte 用的是同一套内存策略。检查参数实际生效位置时看日志里Java ... -Xmx那行，比看配置文件更可靠。

6. 进阶：把 PDI CE 从手工点按钮变成可重复调用的数据管道

PDI 的图形界面很直观，但生产环境里没人天天打开 Spoon 点执行。真正的用法是把它当作一个可编程的数据管道引擎，让 job 和转换通过命令行被外部系统调度。

我这里最常用的套路是四个：固定路径的工作目录、Kitchen 命令行参数标准化、Carte 做轻量级集群、二次开发接口预留。

工作目录的固定很重要。在kitchen.sh执行时指定-rep仓库会引入额外的配置负担，我习惯用纯文件方式的 job，目录结构固定为：

/data/etl/ ├── jobs/ # kjb 作业文件 ├── transforms/ # ktr 转换文件 ├── logs/ # 执行日志 └── tmp/ # 中间文件

然后写一个统一的执行脚本包装：

#!/bin/bash export PENTAHO_JAVA_HOME=/usr/lib/jvm/java-1.8.0 export PENTAHO_HOME=/opt/pdi/pdi-ce-7.1 cd $PENTAHO_HOME /opt/pdi/pdi-ce-7.1/kitchen.sh \ -file=/data/etl/jobs/daily_sync.kjb \ -level:Basic \ -logfile=/data/etl/logs/daily_sync_$(date +%Y%m%d_%H%M%S).log

-level:Basic是日志级别，生产环境没必要用 Debug，Basic 级别记录 job 开始、结束和错误信息，日志文件大小可控。-logfile的路径里加了时间戳，避免每天的执行日志互相覆盖。

如果你处理的量已经大到单机内存不够、需要横向扩展两个节点，可以用 Carte 做简单集群。启动一个 Carte 实例：

./carte.sh 0.0.0.0 8081

然后在 Spoon 里配置集群 schema 指向这台机器的 IP 和端口，PDI 会把转换里的步骤分发到 Carte 执行。这个方案比上真正的 Hadoop 轻量得多，是两个内网节点间做分布式转换的入门方案。

对于有 Java 背景的团队，PDI 7.1 的二次开发入口在lib/里的kettle-enginejar。你可以写自定义插件，放到plugins/目录下，Spoon 就会在左侧步骤面板里显示你的自定义步骤。这个扩展机制是 Kettle 社区最活跃的部分，数据源连接、清洗步骤、目标库写入都可以封装成团队内部插件复用。

说回到开头那个 zip 包。pdi_ce7.1.0.0-12.zip不是什么需要敬畏的神秘工具，它就是一个可以被命令行调用、可以写插件、可以分布式执行的数据管道引擎。把这套玩透了，你会越来越习惯用kitchen.sh而不是打开图形界面，因为每次执行都可预期、可回放、可排错。这也是我被生产环境反复教育出来的习惯：ETL 脚本要能随时重跑，而不是依赖某个人在某个终端里点了一堆按钮。希望这篇笔记里的部署路径和参数，能帮你少走几步我走过的弯路。

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