 8.2 从安装到实战：数据迁移与增量同步指南)
简介Kettle社区版8.2.0.0-11完整安装包即Pentaho Data Integration面向数据仓库与ETL开发人员用于多源数据抽取、清洗、转换和加载。纯Java编写可在Windows、Linux、Unix上运行适合大规模集成任务与跨数据库同步。压缩包共1884个文件大小约979.51MB核心为1335个jar运行库辅以200个ktr转换、19个kjb作业、111个xml配置以及bat/sh启动脚本等涵盖Spoon、Kitchen、Pan、Carte等模块完整运行组件便于图形化开发与命令行调度。已有456人学习下载。包内自带各模块启动脚本和默认配置解压即可搭建运行环境省去依赖收集与编译环节。同时保留大量示例转换与作业文件可参考其数据流设计、参数配置和日志输出对理解Kettle内部机制、快速上手生产级ETL流程及后续组件扩展都有实际帮助。 先收好这个文件名pdi-ce-8.2.0.0-11.zip。如果你跟ETL打交道早晚会遇到类似的包。这是Pentaho Data Integration社区版的安装包圈内人更习惯叫它Kettle。虽然现在网上铺天盖地是云原生调度、实时数仓但这套老牌开源工具还在无数企业的批处理任务里默默跑着尤其是那些需要快速搞定异构数据库之间数据搬迁的场景。这篇文章我就围绕这个具体版本聊聊它从解压到投入实战的全过程包括环境坑、性能调优、增量同步思路以及我在使用过程中遇到的各种典型问题。1. 文件名里的信息量pdi-ce-8.2.0.0-11 到底怎么读1.1 名字拆解一段解压就能用的经历并不存在拿到pdi-ce-8.2.0.0-11.zip这个文件很多人第一反应是解压、双击启动然后就能连数据库导数据。我第一次用的时候也这么想结果连启动界面都没等到直接在环境检查环节卡住了。先说说这个名字本身。pdi-ce是 Pentaho Data Integration Community Edition 的缩写社区版免费开源这意味着你不需要授权文件解压完就能用只是某些企业级功能比如调度中心、企业控制台被移除了。8.2.0.0是版本号按 Pentaho 的规则前两位 8.2 是主版本线2019年初发布的这个大版本线至今仍被大量数据平台采用。后面的0.0是维护更新号到-11则是具体的构建序号表示这是 8.2 主版本线的第 11 次构建。这个构建号很关键它通常包含了一些 bug 修复和驱动更新比你随便从某个第三方渠道下载的同类版本更稳定。看清楚这个版本再决定你要不要用它而不是拿到包就一股脑解压。对于学习 ETL 逻辑、做中小规模数据同步、或者维护老平台8.2 社区版完全够用。它跑得动也稳定社区资料也多一个问题一搜就有答案。1.2 为什么现在还有人坚持 8.2明明 Pentaho 早就迭代到了 9.x、10.x为什么还有人在用 8.2我观察到几个原因。第一个原因是 JDK 版本兼容性。8.2 对 Java 8 的支持非常成熟而新版本对高版本 JDK 的要求更高有些老服务器上还跑着 JDK 8硬上新版反而要处理一些环境冲突。第二个原因是稳定性。社区版的迭代节奏在快但同时伴随一些新功能的调试期。对于已经在生产环境跑了两三年作业的团队来说工具稳定不挑食比追新更重要。我在维护一个老数据仓库时调度里所有同步作业都基于 8.2 开发换版本意味着回归测试、作业兼容性验证这个成本在业务压力面前很不划算。当然还有一个非常实际的原因8.2 对内存的占用相对温和默认的 JVM 参数在老机器上也能跑不像后面的大版本动不动就需要 4G 以上的堆空间。如果你的开发机配置有限或者服务器资源紧张8.2 反而是一个聪明的选择。2. 安装与首次启动不是解压就能直接跑2.1 环境准备JDK8 和目录规划解压后你会得到一个>sudo apt install libgtk-3-0 libcanberra-gtk-module libcanberra-gtk3-moduleRedHat/CentOS 系执行sudo yum install gtk3 libcanberra-gtk3我个人在 CentOS 7 上跑过几十次装了libcanberra-gtk3之后基本上没有再遇到过界面起不来的情况。2.3 给 PDI 分配合理的内存进入工作台之前建议先看一个文件>PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx2048m -XX:MaxPermSize256m这是 PDI 的 JVM 启动参数。默认给 2G 的堆内存对中小数据量够用但如果你要处理百万行以上的数据流转或者同时打开多个转换建议把这个值调到 4GPENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -XX:MaxPermSize512m有一点要注意这里调的是 Spoon 图形界面工具的内存不是最终执行作业的内存。如果你用 Kitchen命令行执行作业跑生产任务需要在kitchen.sh里单独改参数而且生产服务器上的内存分配要跟 JVM 参数匹配别设一个超出物理内存的堆否则机房机器会直接卡死。3. 吃透核心机制转换与任务的差别3.1 Spoon 工作台先搞清楚两种文件的本质启动 Spoon 后你会看到一个空白画布。这个画布上能建两种东西转换Transformation和作业Job。很多初学者混淆这两者觉得不就是画个流程吗其实差别很大。转换是数据处理单元强调的是并行流。你在画布上拖一个「表输入」再接一个「字段选择」最后接一个「表输出」这三个步骤在运行时是并行执行的数据以行流的形式在步骤之间传递。转换里的步骤之间是流式推进关系前一步产生了第一批数据后面的步骤就开始处理而不是等全部数据抽完再处理。这个特性让 PDI 在处理大表时不需要把所有数据加载进内存吞吐量比全量载入的方式高很多。作业是流程编排单元强调的是串行控制。在作业里你按顺序排列多个「转换」节点还可以加「判断」、「循环」、「发送邮件」、「执行 SQL」等节点。作业里的每个节点按顺序执行前一个成功了才走下一个。比如每天晚上两点先执行「抽数转换」抽完执行「邮件通知」邮件发送成功后再执行「后续处理」。这就是一个典型的作业。所以标准做法是用转换实现具体的数据抽取/清洗/加载逻辑用作业把这些转换按顺序编排起来。两者通过结果对象传递元数据比如上一个转换里设置了变量下一个转换读这个变量来决定抽取范围。3.2 高频步骤的使用逻辑与组合日常工作里以下几步组合出镜率最高。表输入Table Input。这是几乎所有数据抽取的起点作用是从数据库读取数据。它支持写 SQL也支持使用变量。关键点是替换 SQL 中的变量和从查询里获取字段类型两个选项。第二个选项建议勾选这样后续步骤才能确定字段类型否则可能出现隐式类型转换错误。字段选择Select Values。别被名字骗了它不只是选择字段还能做字段重命名、类型转换、删除字段。我几乎在每个转换里都会用到它因为源库的字段命名风格五花八门到了目标库要统一规范。表输出Table Output。数据写入数据库的出口。这里有个非常重要的参数提交记录数量。默认是 1000意思是每攒够 1000 条记录执行一次批量提交。对于大批量数据这个值建议调大到 5000 甚至 10000能显著减少数据库交互次数提升写入速度。插入/更新Insert/Update。这是我最常用的增量操作步骤它通过指定一个查询键判断某条记录在目标表里存在还是不存在存在就更新不存在就插入。适用于有主键同步的业务场景。合并记录Merge Rows。这是做数据比对的好手。输入源数据流和目标数据流指定关键字段输出新增、已删除、已修改、不变的标记后面再接「同步」或「Switch/Case」步骤来处理标记。典型用法是每天把源表全量拉下来跟目标表比对只同步有差异的部分实现伪增量。组合逻辑一般是表输入 → 字段选择 → 插入/更新是最朴素的三段式。复杂一点是表输入 → 排序 → 合并记录 → Switch/Case → 表输出这种方式能精确控制每条记录的变更方向性能也不错。4. 一个完整实战从 MySQL 到 PostgreSQL 的数据迁移4.1 数据抽取流程与关键参数讲原理不落地等于白说。我拿一个最典型的场景演示一下把 MySQL 的一张订单表同步到 PostgreSQL每天全量一次并且用「插入/更新」保证重复执行不会出重复数据。第一步在 Spoon 里新建一个转换拖入「表输入」。双击打开配置 MySQL 连接。选择 MySQL 驱动后JDBC URL 需要明确加上时区参数jdbc:mysql://192.168.1.100:3306/sales?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai如果不加serverTimezoneMySQL 8 连接时会直接报The server time zone value...错误。这也是 8.2 时代最常见的报错之一因为包里自带的驱动版本比较旧对 MySQL 8 的协议支持不完整更不认识新版服务器默认的CST时区。SQL 我习惯写成SELECT order_id, order_sn, customer_name, amount, create_time FROM t_order WHERE create_time 2024-01-01第二步接一个「字段选择」把order_sn保留customer_name统一转成 UTF-8 编码的字符串amount转成Number类型位数和小数位分别设成 12 和 2。第三步接「插入/更新」。目标表设为 PostgreSQL 的表名查找字段选定order_id更新字段把业务字段逐个映射上去。运行这个转换后每次执行都会先SELECT判断这条记录在不在不在就INSERT在就UPDATE天然满足幂等。4.2 批量提交与性能调优同样一段数据性能差异可能有好几倍关键就在「表输出」的参数上。提交记录数量这个参数决定了一个事务内包含的行数。把它从默认的 1000 调到 10000我实测 MySQL → PostgreSQL 的同步速度从每分钟 8 万行提升到 22 万行左右提升了近三倍。数据库连接上的连接池大小保持默认值 1 即可除非你要并行处理多个分片。还有个容易忽略的点不使用批量插入这个选项千万不要勾选。默认不勾选才使用批量插入addBatch如果误勾了一行一行提交慢到怀疑人生。对于超大规模数据建议在「表输入」里加上分页逻辑。比如用LIMIT 100000 OFFSET ?配合变量循环抽取每一轮 10 万行避免一次把几百万行数据全拉进内存。这个方案可以有效降低内存压力也方便追踪每一步的执行情况。4.3 增量同步思路全量同步在数据量小的时候没问题但到了百万级还每天全量就是在给数据库上刑。增量同步的思路通常在作业层面解决。常见方案是时间戳增量。源表里有一个update_time字段我们只要抽取update_time 上次同步时间的数据。上次同步时间存哪可以存在一张控制表里比如sync_controltable_name last_sync_time t_order 2024-06-01 00:00:00在作业里第一步用一个「Table Input」读取last_sync_time到变量第二步执行主转换时在 SQL 里引用变量SELECT * FROM t_order WHERE update_time ${LAST_SYNC_TIME}第三步转换执行完再用一个「SQL 脚本」步骤执行UPDATE sync_control SET last_sync_time NOW()把本次同步时间写回去。这样形成一个闭环每天只处理变化的数据跑得飞快。另一种思路是自增主键增量。如果源表有单调递增的主键id维护max_id值即可。但这方案有个缺陷更新老记录时不会触发新增所以适合日志、流水类只增不改的表。5. 实测中踩过的坑与排查链路5.1 MySQL 8 驱动不兼容的完整排查PDI 8.2 自带的 MySQL 驱动是 5.1.x 版本这个古董面对 MySQL 8 新认证插件caching_sha2_password直接报Unable to load authentication plugin caching_sha2_password。当时在生产环境遇到这个问题时我第一反应是搜索驱动版本然后下载了mysql-connector-java-8.0.x.jar放到>jdbc:mysql://192.168.1.100:3306/sales?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue这个坑的根本原因在于PDI 8.2 与 MySQL 8 属于不同时代的产物驱动和工作机制不匹配。遇到类似问题优先检查驱动的版本别一上来就觉得是 SQL 写错了。5.2 大表抽取内存溢出的定位过程我接手过一个每天同步千万级流水表的任务运行到一半Kitchen 进程直接OutOfMemoryError退出。日志里能看到Java heap space字样。当时我的第一反应是调大 JVM 堆内存改成-Xmx8192m后重跑照样崩。这说明问题不在堆大小而在于数据流的处理机制。仔细检查了一遍转换发现「表输入」和「表输出」之间没有任何中间步骤理论上应该是流式传输为什么会内存炸掉后来意识到表输入有一个隐藏参数每一行都执行一次 SQL。如果勾选了PDI 会把 SQL 当成每来一个输入行就执行一次的子查询结果集存在内存里。我那个转换里没输入行理论上不该有问题但当表输入输出几千个字段的宽表时PDI 内部构建RowMeta结构的内存开销相当大。最终为了解决我给转换加了分页机制每轮只抽 50 万行同时把表输入的Lazy conversion选项勾选这个选项让字段延迟转换减少内存中的对象创建。重跑之后4G 堆就能稳稳跑完全量任务。5.3 中文乱码从源头定位再解决做 ETL 遇到中文乱码排查顺序需要从源头一层层往下找。先看数据源字符集。MySQL 表是否utf8mb4编码连接 URL 是否带了characterEncodingUTF-8。再看 PDI 转换内部的字符集设置。在「字段选择」里对目标字段可以指定编码属性统一设成 UTF-8。之后检查目标库的字符集。PostgreSQL 默认可能是SQL_ASCII写入中文后就变成?或乱码。解决方法是建库时指定UTF8编码并且在「表输出」的添加批量插入选项里确认字符集参数没被覆盖。最后看日志。Spoon 的日志窗口里乱码有时候只是显示问题此时去改style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" /> Kettle (PDI) 8.2 从安装到实战：数据迁移与增量同步指南
简介Kettle社区版8.2.0.0-11完整安装包即Pentaho Data Integration面向数据仓库与ETL开发人员用于多源数据抽取、清洗、转换和加载。纯Java编写可在Windows、Linux、Unix上运行适合大规模集成任务与跨数据库同步。压缩包共1884个文件大小约979.51MB核心为1335个jar运行库辅以200个ktr转换、19个kjb作业、111个xml配置以及bat/sh启动脚本等涵盖Spoon、Kitchen、Pan、Carte等模块完整运行组件便于图形化开发与命令行调度。已有456人学习下载。包内自带各模块启动脚本和默认配置解压即可搭建运行环境省去依赖收集与编译环节。同时保留大量示例转换与作业文件可参考其数据流设计、参数配置和日志输出对理解Kettle内部机制、快速上手生产级ETL流程及后续组件扩展都有实际帮助。 先收好这个文件名pdi-ce-8.2.0.0-11.zip。如果你跟ETL打交道早晚会遇到类似的包。这是Pentaho Data Integration社区版的安装包圈内人更习惯叫它Kettle。虽然现在网上铺天盖地是云原生调度、实时数仓但这套老牌开源工具还在无数企业的批处理任务里默默跑着尤其是那些需要快速搞定异构数据库之间数据搬迁的场景。这篇文章我就围绕这个具体版本聊聊它从解压到投入实战的全过程包括环境坑、性能调优、增量同步思路以及我在使用过程中遇到的各种典型问题。1. 文件名里的信息量pdi-ce-8.2.0.0-11 到底怎么读1.1 名字拆解一段解压就能用的经历并不存在拿到pdi-ce-8.2.0.0-11.zip这个文件很多人第一反应是解压、双击启动然后就能连数据库导数据。我第一次用的时候也这么想结果连启动界面都没等到直接在环境检查环节卡住了。先说说这个名字本身。pdi-ce是 Pentaho Data Integration Community Edition 的缩写社区版免费开源这意味着你不需要授权文件解压完就能用只是某些企业级功能比如调度中心、企业控制台被移除了。8.2.0.0是版本号按 Pentaho 的规则前两位 8.2 是主版本线2019年初发布的这个大版本线至今仍被大量数据平台采用。后面的0.0是维护更新号到-11则是具体的构建序号表示这是 8.2 主版本线的第 11 次构建。这个构建号很关键它通常包含了一些 bug 修复和驱动更新比你随便从某个第三方渠道下载的同类版本更稳定。看清楚这个版本再决定你要不要用它而不是拿到包就一股脑解压。对于学习 ETL 逻辑、做中小规模数据同步、或者维护老平台8.2 社区版完全够用。它跑得动也稳定社区资料也多一个问题一搜就有答案。1.2 为什么现在还有人坚持 8.2明明 Pentaho 早就迭代到了 9.x、10.x为什么还有人在用 8.2我观察到几个原因。第一个原因是 JDK 版本兼容性。8.2 对 Java 8 的支持非常成熟而新版本对高版本 JDK 的要求更高有些老服务器上还跑着 JDK 8硬上新版反而要处理一些环境冲突。第二个原因是稳定性。社区版的迭代节奏在快但同时伴随一些新功能的调试期。对于已经在生产环境跑了两三年作业的团队来说工具稳定不挑食比追新更重要。我在维护一个老数据仓库时调度里所有同步作业都基于 8.2 开发换版本意味着回归测试、作业兼容性验证这个成本在业务压力面前很不划算。当然还有一个非常实际的原因8.2 对内存的占用相对温和默认的 JVM 参数在老机器上也能跑不像后面的大版本动不动就需要 4G 以上的堆空间。如果你的开发机配置有限或者服务器资源紧张8.2 反而是一个聪明的选择。2. 安装与首次启动不是解压就能直接跑2.1 环境准备JDK8 和目录规划解压后你会得到一个>sudo apt install libgtk-3-0 libcanberra-gtk-module libcanberra-gtk3-moduleRedHat/CentOS 系执行sudo yum install gtk3 libcanberra-gtk3我个人在 CentOS 7 上跑过几十次装了libcanberra-gtk3之后基本上没有再遇到过界面起不来的情况。2.3 给 PDI 分配合理的内存进入工作台之前建议先看一个文件>PENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx2048m -XX:MaxPermSize256m这是 PDI 的 JVM 启动参数。默认给 2G 的堆内存对中小数据量够用但如果你要处理百万行以上的数据流转或者同时打开多个转换建议把这个值调到 4GPENTAHO_DI_JAVA_OPTIONS-Xms1024m -Xmx4096m -XX:MaxPermSize512m有一点要注意这里调的是 Spoon 图形界面工具的内存不是最终执行作业的内存。如果你用 Kitchen命令行执行作业跑生产任务需要在kitchen.sh里单独改参数而且生产服务器上的内存分配要跟 JVM 参数匹配别设一个超出物理内存的堆否则机房机器会直接卡死。3. 吃透核心机制转换与任务的差别3.1 Spoon 工作台先搞清楚两种文件的本质启动 Spoon 后你会看到一个空白画布。这个画布上能建两种东西转换Transformation和作业Job。很多初学者混淆这两者觉得不就是画个流程吗其实差别很大。转换是数据处理单元强调的是并行流。你在画布上拖一个「表输入」再接一个「字段选择」最后接一个「表输出」这三个步骤在运行时是并行执行的数据以行流的形式在步骤之间传递。转换里的步骤之间是流式推进关系前一步产生了第一批数据后面的步骤就开始处理而不是等全部数据抽完再处理。这个特性让 PDI 在处理大表时不需要把所有数据加载进内存吞吐量比全量载入的方式高很多。作业是流程编排单元强调的是串行控制。在作业里你按顺序排列多个「转换」节点还可以加「判断」、「循环」、「发送邮件」、「执行 SQL」等节点。作业里的每个节点按顺序执行前一个成功了才走下一个。比如每天晚上两点先执行「抽数转换」抽完执行「邮件通知」邮件发送成功后再执行「后续处理」。这就是一个典型的作业。所以标准做法是用转换实现具体的数据抽取/清洗/加载逻辑用作业把这些转换按顺序编排起来。两者通过结果对象传递元数据比如上一个转换里设置了变量下一个转换读这个变量来决定抽取范围。3.2 高频步骤的使用逻辑与组合日常工作里以下几步组合出镜率最高。表输入Table Input。这是几乎所有数据抽取的起点作用是从数据库读取数据。它支持写 SQL也支持使用变量。关键点是替换 SQL 中的变量和从查询里获取字段类型两个选项。第二个选项建议勾选这样后续步骤才能确定字段类型否则可能出现隐式类型转换错误。字段选择Select Values。别被名字骗了它不只是选择字段还能做字段重命名、类型转换、删除字段。我几乎在每个转换里都会用到它因为源库的字段命名风格五花八门到了目标库要统一规范。表输出Table Output。数据写入数据库的出口。这里有个非常重要的参数提交记录数量。默认是 1000意思是每攒够 1000 条记录执行一次批量提交。对于大批量数据这个值建议调大到 5000 甚至 10000能显著减少数据库交互次数提升写入速度。插入/更新Insert/Update。这是我最常用的增量操作步骤它通过指定一个查询键判断某条记录在目标表里存在还是不存在存在就更新不存在就插入。适用于有主键同步的业务场景。合并记录Merge Rows。这是做数据比对的好手。输入源数据流和目标数据流指定关键字段输出新增、已删除、已修改、不变的标记后面再接「同步」或「Switch/Case」步骤来处理标记。典型用法是每天把源表全量拉下来跟目标表比对只同步有差异的部分实现伪增量。组合逻辑一般是表输入 → 字段选择 → 插入/更新是最朴素的三段式。复杂一点是表输入 → 排序 → 合并记录 → Switch/Case → 表输出这种方式能精确控制每条记录的变更方向性能也不错。4. 一个完整实战从 MySQL 到 PostgreSQL 的数据迁移4.1 数据抽取流程与关键参数讲原理不落地等于白说。我拿一个最典型的场景演示一下把 MySQL 的一张订单表同步到 PostgreSQL每天全量一次并且用「插入/更新」保证重复执行不会出重复数据。第一步在 Spoon 里新建一个转换拖入「表输入」。双击打开配置 MySQL 连接。选择 MySQL 驱动后JDBC URL 需要明确加上时区参数jdbc:mysql://192.168.1.100:3306/sales?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/Shanghai如果不加serverTimezoneMySQL 8 连接时会直接报The server time zone value...错误。这也是 8.2 时代最常见的报错之一因为包里自带的驱动版本比较旧对 MySQL 8 的协议支持不完整更不认识新版服务器默认的CST时区。SQL 我习惯写成SELECT order_id, order_sn, customer_name, amount, create_time FROM t_order WHERE create_time 2024-01-01第二步接一个「字段选择」把order_sn保留customer_name统一转成 UTF-8 编码的字符串amount转成Number类型位数和小数位分别设成 12 和 2。第三步接「插入/更新」。目标表设为 PostgreSQL 的表名查找字段选定order_id更新字段把业务字段逐个映射上去。运行这个转换后每次执行都会先SELECT判断这条记录在不在不在就INSERT在就UPDATE天然满足幂等。4.2 批量提交与性能调优同样一段数据性能差异可能有好几倍关键就在「表输出」的参数上。提交记录数量这个参数决定了一个事务内包含的行数。把它从默认的 1000 调到 10000我实测 MySQL → PostgreSQL 的同步速度从每分钟 8 万行提升到 22 万行左右提升了近三倍。数据库连接上的连接池大小保持默认值 1 即可除非你要并行处理多个分片。还有个容易忽略的点不使用批量插入这个选项千万不要勾选。默认不勾选才使用批量插入addBatch如果误勾了一行一行提交慢到怀疑人生。对于超大规模数据建议在「表输入」里加上分页逻辑。比如用LIMIT 100000 OFFSET ?配合变量循环抽取每一轮 10 万行避免一次把几百万行数据全拉进内存。这个方案可以有效降低内存压力也方便追踪每一步的执行情况。4.3 增量同步思路全量同步在数据量小的时候没问题但到了百万级还每天全量就是在给数据库上刑。增量同步的思路通常在作业层面解决。常见方案是时间戳增量。源表里有一个update_time字段我们只要抽取update_time 上次同步时间的数据。上次同步时间存哪可以存在一张控制表里比如sync_controltable_name last_sync_time t_order 2024-06-01 00:00:00在作业里第一步用一个「Table Input」读取last_sync_time到变量第二步执行主转换时在 SQL 里引用变量SELECT * FROM t_order WHERE update_time ${LAST_SYNC_TIME}第三步转换执行完再用一个「SQL 脚本」步骤执行UPDATE sync_control SET last_sync_time NOW()把本次同步时间写回去。这样形成一个闭环每天只处理变化的数据跑得飞快。另一种思路是自增主键增量。如果源表有单调递增的主键id维护max_id值即可。但这方案有个缺陷更新老记录时不会触发新增所以适合日志、流水类只增不改的表。5. 实测中踩过的坑与排查链路5.1 MySQL 8 驱动不兼容的完整排查PDI 8.2 自带的 MySQL 驱动是 5.1.x 版本这个古董面对 MySQL 8 新认证插件caching_sha2_password直接报Unable to load authentication plugin caching_sha2_password。当时在生产环境遇到这个问题时我第一反应是搜索驱动版本然后下载了mysql-connector-java-8.0.x.jar放到>jdbc:mysql://192.168.1.100:3306/sales?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue这个坑的根本原因在于PDI 8.2 与 MySQL 8 属于不同时代的产物驱动和工作机制不匹配。遇到类似问题优先检查驱动的版本别一上来就觉得是 SQL 写错了。5.2 大表抽取内存溢出的定位过程我接手过一个每天同步千万级流水表的任务运行到一半Kitchen 进程直接OutOfMemoryError退出。日志里能看到Java heap space字样。当时我的第一反应是调大 JVM 堆内存改成-Xmx8192m后重跑照样崩。这说明问题不在堆大小而在于数据流的处理机制。仔细检查了一遍转换发现「表输入」和「表输出」之间没有任何中间步骤理论上应该是流式传输为什么会内存炸掉后来意识到表输入有一个隐藏参数每一行都执行一次 SQL。如果勾选了PDI 会把 SQL 当成每来一个输入行就执行一次的子查询结果集存在内存里。我那个转换里没输入行理论上不该有问题但当表输入输出几千个字段的宽表时PDI 内部构建RowMeta结构的内存开销相当大。最终为了解决我给转换加了分页机制每轮只抽 50 万行同时把表输入的Lazy conversion选项勾选这个选项让字段延迟转换减少内存中的对象创建。重跑之后4G 堆就能稳稳跑完全量任务。5.3 中文乱码从源头定位再解决做 ETL 遇到中文乱码排查顺序需要从源头一层层往下找。先看数据源字符集。MySQL 表是否utf8mb4编码连接 URL 是否带了characterEncodingUTF-8。再看 PDI 转换内部的字符集设置。在「字段选择」里对目标字段可以指定编码属性统一设成 UTF-8。之后检查目标库的字符集。PostgreSQL 默认可能是SQL_ASCII写入中文后就变成?或乱码。解决方法是建库时指定UTF8编码并且在「表输出」的添加批量插入选项里确认字符集参数没被覆盖。最后看日志。Spoon 的日志窗口里乱码有时候只是显示问题此时去改style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />