简介这份PPT讲解聚焦ETL工具Kettle即PDI的基础知识与项目落地面向具备一定编程基础、工作一至三年的研发人员尤其适合需要对接MySQL、Oracle等数据库并处理数据同步任务的开发者。内容从“什么是ETL、什么是Kettle”展开逐步覆盖Kettle安装、目录结构、转换与作业、步骤与跳、数据行及数据类型、数据库连接与注意事项等核心概念配合PDI 9.2演示关键操作能让读者明白转换与作业的差异、步骤之间的数据流动方式了解Kettle在实际项目中的实现路径、常见不足点以及数据同步调优思路。资源包内含1个pptx文件共26页PPT压缩包仅859KB体积轻量适合按页学习或团队内部分享。目前已有1463人学习下载对正在入门ETL、需要系统梳理Kettle使用要点并规避常见坑点的开发者有较高参考价值整体内容较完整图文结合便于快速建立Kettle整体认知。1. ETL 与 Kettle为什么数据搬运这件事最耗人力做了几年数据项目之后我发现一个反直觉的规律数据接入最累的从来不是“从 A 库拷到 B 库”那一下而是拷贝之前那些没人愿意管的脏活——字段对不上、空值乱飞、编码不统一、同一张表在两个系统里含义不同。ETL 就是把这摊杂活标准化的一套流程Kettle 则是这套流程里新手最容易拿起来就用的图形化工具。这篇文章按我平时给团队讲 Kettle 基础课的思路写适合刚接触数据接入、想在本地快速验证抽取清洗方案的开发者和运维。下面不重复官方文档只讲动手时会真正遇到的东西。2. Kettle 基础转换、作业和两类流的最小认知模型开始点鼠标之前先把 Kettle 里最容易把新人绕晕的三个概念分清转换Transformation、作业Job和跳Hop。理解这三样后面配步骤就不是在黑匣子里瞎试而是知道每一步到底在做什么。2.1 转换与作业一个有图形界面的两个容器转换对应磁盘上的.ktr文件作业对应.kjb文件。这个后缀很重要因为命令行跑批时靠它区分用哪个执行器。转换的核心特征是数据处理流水线。转换里的执行单元叫步骤Step步骤之间用连线Hop连接数据像水一样从上游步骤流到下游步骤。转换的特点一是步骤之间默认并行运行而不是像写程序一样一行一行顺序执行二是每条数据经过连线时Kettle 会把它放在内存的行集Row Set里缓冲。这个机制带来的直接后果是如果下游处理太慢上游不会无限读数据缓冲满了会自然背压。作业则完全不是这套逻辑。作业里的执行单元叫作业条目Job Entry它管的是“什么时候该做什么事”的控制流比如先执行转换 A、再发送邮件、成功了才执行转换 B。作业条目的连线是“上一个做完、并且结果满足条件才走这条线”的关系连线上有成功、失败、无条件之分。基础阶段可以简单记转换管数据处理作业管流程编排。这里插一句选型上的常见误区很多教材强调一定要用作业来调度转换但实际做数仓接入时单次一次性同步直接用转换跑就够了只有涉及多步依赖、失败重试、定时循环时才需要套一层作业。作业是执行框架不是所有转换的必需品。2.2 数据流与控制流Kettle 里最容易混淆的边界我见过不少新同事把作业当成“能处理数据的转换”去用想在作业里直接拖一个“表输入”步骤来做查询结果发现作业条目列表里根本没有表输入只有“SQL 脚本”“转换”“发送邮件”这些执行型条目。原因就是刚才说的作业只管控制流不做逐行数据处理。反过来转换里也不是完全不能有控制逻辑。每个步骤下方有“主输出”“错误处理”两种输出流比如“表输出”写目标表失败时错误行会沿错误流走你可以接一个“文本文件输出”把坏行单独落盘。这算转换内部的轻量分支但复杂度马上上来基础阶段不建议一上来就玩多输出流先把单条主链路跑通。连线Hop上还有一个在图形界面里常被忽略的属性在连线上“右击 → 编辑跳”→ 修改“发送”和“接受”状态。默认是单向且启用如果误取消了启用数据不会流动现象是跑完转换后目标表没数据而日志里也没有任何报错。这种“没有报错但没数据”的情况排查顺序里一定要有“看连线是否停用”这一项。2.3 一个最小 .ktr 文件长什么样图形界面拖完保存后Kettle 会生成 XML。很多新人以为只能靠鼠标操作一旦要批量生成或做版本对比就无从下手。其实你完全可以打开一个.ktr文件直接看结构。一个只有“CSV 输入 → 表输出”的转换骨架大概是这样的transformation info nameuser_csv_to_db/name /info step nameread_csv/name typeCsvInput/type encodingUTF-8/encoding filename${INPUT_FILE}/filename delimiter,/delimiter enclosure/enclosure headerY/header bufferSize50000/bufferSize /step step namewrite_db/name typeTableOutput/type connectionlocal_mysql/connection tableods_user/table commitSize1000/commitSize /step hop fromread_csv/from towrite_db/to enabledY/enabled /hop /transformation这个片段里typeCsvInput/type是步骤类型的内部名称connection指向我们在数据库连接里配置的连接名${INPUT_FILE}则是一个变量占位符运行时通过命令行传入真实路径。建议每次保存转换后都顺手打开 XML 看一遍字段名很多界面上的问题其实是配置名写错了比如连接名带空格导致执行时找不到连接。理解了这个结构后面用命令行跑转换时-param传参对到哪里心里就有数了。3. 从零跑通第一个转换CSV 入库的六步操作链纸上概念讲完直接做第一个能跑出结果的东西把一份 CSV 文件读进来简单清洗写进数据库表。整个过程走通之后Kettle 的套路就摸到一半了。3.1 新建转换与输入步骤配置打开 Kettle 图形界面后新建一个转换先把“CSV 文件输入”拖到画布这是基础课里最推荐作为起点的步骤。它比“文本文件输入”配置简单没有繁琐的正则切割规则适合第一次上手。双击进入配置需要定几个核心参数文件路径、分隔符、是否首行作为标题、编码格式。我一般会把文件路径写成变量比如${INPUT_FILE}而不是写死本机路径。原因很简单同一个转换在开发机、测试机、生产机上跑路径一定不一样写死路径等于每换一次环境就改一次文件。编码这个选项容易被无视。手头 CSV 是从 Windows 导出的很可能是 GBK 或 GB18030从线上 Linux 导出的一般是 UTF-8。这里选错不会报错而是导入后字符串字段全变乱码属于 Kettle 新手第一坑后面避坑章节专门展开。参数列表大致如下配置项建议值说明文件/目录${INPUT_FILE}用变量代替硬编码路径分隔符,与 CSV 实际分隔符严格一致头部是首行当列名可省去后续字段映射编码UTF-8 / GBK看文件本身别猜用命令 file 看并行读文件否小文件别开会改变行顺序3.2 字段映射、值映射与输出配置输入步骤读出来的字段不一定直接能写进目标表。常见差异有三类源字段多余目标字段、类型不匹配、值域需要归一化。我通常会在输入之后拖一个“字段选择”步骤把不需要的字段裁掉同时在这里改类型和长度。比如 CSV 里所有字段解析出来默认可能是 String目标表age是整数就在这里把age改为 Integer8长度。如果源数据里性别存的是1/0而目标表要求男/女就在字段选择后面加一个“值映射”步骤源值1映射为男0映射为女目标值是空或异常的保留原值后面再单独处理。最后把“表输出”拖进来配置数据库连接和目标表名。需要注意“表输出”步骤默认行为是追加写入不是清空重建。如果希望同步前清掉旧数据要么在转换最前面加一个“执行 SQL 脚本”步骤先TRUNCATE要么在作业里用作业条目的“SQL 脚本”完成。很多新人直接跑两次转换发现目标表数据翻倍就是这个默认行为没搞清楚。3.3 在命令行用 Pan 跑转换图形界面里点“运行”能直接看到结果但真实场景中转换要被定时任务调用必须学会命令行执行。Kettle 安装目录下有两个执行器pan.sh对应 Windows 的pan.bat跑转换kitchen.sh对应kitchen.bat跑作业。# 切换到 Kettle 安装目录 cd /opt/kettle/data-integration # 执行转换传入输入文件变量日志级别用 Basic ./pan.sh -file:/data/etl/user_csv_to_db.ktr \ -param:INPUT_FILE/data/etl/input/user.csv \ -level:Basic参数说明-file指定转换文件绝对路径-param用来传变量格式是-param:变量名值一个-param只能传一个变量多个变量就写多个-param-level控制日志明细基础运行用Basic排查数据问题时切到Rowlevel但逐行输出日志在数据量大时能把人卡死平时不要用。这里还有个容易踩的位置在 Windows 上跑要写pan.bat而且路径里有空格时最好用引号把-file值包起来。如果嫌命令行输出乱码先执行chcp 65001切换到 UTF-8 代码页再运行。4. 高频步骤的参数取舍表输入、排序合并与增量同步第一个转换跑通之后接下来你接触最多的业务场景大概率的不是 CSV而是库表之间的搬运和比对。这一章讲三组高频步骤表输入与表输出、排序与去重、合并记录并给出参数到底该怎么设。4.1 表输入与表输出SQL 写在哪、分页怎么设如果你面对的数据在数据库里就别绕道 CSV 了直接用“表输入”步骤。“表输入”的本质是一个 SQL 查询执行器查询结果就是数据流。配置时分两步选好数据库连接然后写 SQL。在实际项目里我很少在表输入里写整张表SELECT *而是把过滤条件尽量留在 SQL 里下推给数据库。比如同步updated_at大于上次时间的增量数据就直接写进 SQLSELECT id, user_name, age, updated_at FROM source_user WHERE updated_at ${LAST_RUN}这段 SQL 里的${LAST_RUN}是 Kettle 变量运行时会被替换成上次同步时间戳。原则是“能在 SQL 里过滤的不要等数据全量拉回来再用步骤过滤”Kettle 的过滤步骤虽然好用但数据已经过一次网络传输了性能差距在高并发拉大表时非常明显。表输出的参数是性能核心重点看提交记录大小和批量插入两个配置参数名作用我常用的设置提交记录大小攒够多少行一次性提交事务5002000小表 500大表 2000使用批量插入走 JDBC 批处理大幅减少网络往返开启表名目标表名写完整表名不要带库名前缀忽略插入错误出错时跳过继续跑默认关闭留着错误流接日志提交记录大小的道理和批量插入类似默认值偏保守每次写一行就提交一次事务开销全耗在提交上。调大后目标表的写入表现会明显上一个台阶。但如果你用的是 MySQL 且对端开了 binlog批量插入会产生大量单条 binlog 事件同步期间目标库的从库延迟可能升高这属于要权衡的副作用。4.2 排序去重与合并记录什么时候交给内存什么时候退给数据库Kettle 里做去重有两种常见组合一种是“排序去重”先按主键排序再用“唯一行”步骤去重另一种是“按字段值去重”它不要求排序但只能保留首次出现的行。前者适合大表后者适合小数据量、且不关心顺序的场景。排序步骤有个关键参数排序缓冲区大小也就是内存里最多缓存多少行。默认配置偏保守几十万行以内没事上千万行不做调优就可能触发内存问题。直接用“排序”步骤时我一般先看数据量估算单表超过 500 万行优先在表输入的 SQL 里ORDER BY并用数据库的索引来排而不是拉回来让 Kettle 排。数据库擅长的事别买 单这是 ETL 调优的第一原则。合并记录Merge Rows是增量同步和表对比里最常用的步骤。它要求两个输入一个是参考流一个是对比流两路都先按关键字排序然后逐行比较。配置要点如下配置项含义注意点参考输入Reference一般是目标表已有数据必须与对比流排序规则一致对比输入Comparison一般是源表新数据字段集合要和参考流一致关键字段Keys业务主键如 user_id只做匹配不比较差异比较字段Values需要比对内容的字段如 name空值会被视为不相等先预处理标志字段Flag输出差异标记列值为 identical / new / changed / deleted这个步骤是理解 Kettle 数据流的好样本它不改变数据本身而是给每行打标签。真正的动作在标签之后的“过滤记录”步骤里把 flag 为new的行导到表输出做插入changed的行导到更新步骤deleted的行按需处理。没有这一步合并记录只是看个热闹。4.3 数据校验与空值处理脏数据就地拦截数据清洗里最烦的是空值。Kettle 里空值不是统一的NULL可能是空字符串、空格、字符串NULL三种形态。基础阶段用一个“值映射” 一个“空值替换”步骤组合处理值映射把NULL这类字面量映射成空串然后再把空串统一替换成真正的NULL或业务默认值。这里容易犯的毛病是在转换中间某一步处理了空值却发现下游步骤里的空值又回来了。原因多半是“计算器”或“字段选择”步骤重新生成了字段新字段默认不继承上游的空值处理。字段选择里改名、改类型后建议立即接一个“空值替换”步骤再把关一道别指望流程后面还有机会补救。5. Kettle 避坑手册编码、提交、驱动与合并的四场实战这一章是血泪经验汇总。前四章讲怎么做这一章讲的是做了之后为什么翻车以及翻车时看哪里。5.1 中文乱码CSV 读进来到处都是“?”现象CSV 里的中文通过“CSV 文件输入”读进来预览时已经乱码写进数据库后变成???或者彻底不可读。排查半天最后发现三个地方的编码没对齐CSV 文件本身是 GBK、输入步骤里设的是 UTF-8、数据库连接字符集又是 latin1 之类。原因Kettle 每个步骤、每个数据库连接都有独立的字符集设置任何一个环节断掉就乱码。很多人只改输入步骤忽略了数据库连接 URL 里的字符集参数。解决先把 CSV 文件用文本编辑器或file命令确认真实编码输入步骤选对应编码再把数据库连接的连接参数里加上characterEncodingutf8。实践中我遇到最多的组合是“文件 GBK 数据库 UTF-8”这种场景不要在输入步骤里写死 UTF-8直接把文件另存为 UTF-8 再做省得中间步骤反复转码。5.2 表输出慢得离谱几千行写了几分钟现象一个只有 3000 行的转换前几步秒完到表输出像卡死一样日志里没有任何错误。原因表输出的提交记录大小用了默认值并且“使用批量插入”没开。Kettle 每攒够一次提交就发一次事务逐行提交时数据库端每行都要同步一次落盘几千行就产生几千次事务往返慢是必然的。解决把提交记录大小调到 1000 以上打开批量插入再跑一次基本能快一到两个数量级。这里要提醒批量插入对目标端数据类型隐式转换容忍度低如果源数据类型和目标字段类型不一致会从“慢”变成“报错”。所以先保证字段映射类型正确再开批量。5.3 数据库驱动与连接参数连不上 MySQL 的经典翻车现象新建 MySQL 连接时点测试报Class not found或者提示The server time zone value ...无法识别。原因一是 Kettle 自带的 lib 目录里没有对应版本驱动 jarMySQL 8 的驱动类名和旧版都不一样二是新版 MySQL 驱动要求 URL 带上时区参数。解决先把对应版本的 JDBC 驱动 jar 放进style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
简介这份PPT讲解聚焦ETL工具Kettle即PDI的基础知识与项目落地面向具备一定编程基础、工作一至三年的研发人员尤其适合需要对接MySQL、Oracle等数据库并处理数据同步任务的开发者。内容从“什么是ETL、什么是Kettle”展开逐步覆盖Kettle安装、目录结构、转换与作业、步骤与跳、数据行及数据类型、数据库连接与注意事项等核心概念配合PDI 9.2演示关键操作能让读者明白转换与作业的差异、步骤之间的数据流动方式了解Kettle在实际项目中的实现路径、常见不足点以及数据同步调优思路。资源包内含1个pptx文件共26页PPT压缩包仅859KB体积轻量适合按页学习或团队内部分享。目前已有1463人学习下载对正在入门ETL、需要系统梳理Kettle使用要点并规避常见坑点的开发者有较高参考价值整体内容较完整图文结合便于快速建立Kettle整体认知。1. ETL 与 Kettle为什么数据搬运这件事最耗人力做了几年数据项目之后我发现一个反直觉的规律数据接入最累的从来不是“从 A 库拷到 B 库”那一下而是拷贝之前那些没人愿意管的脏活——字段对不上、空值乱飞、编码不统一、同一张表在两个系统里含义不同。ETL 就是把这摊杂活标准化的一套流程Kettle 则是这套流程里新手最容易拿起来就用的图形化工具。这篇文章按我平时给团队讲 Kettle 基础课的思路写适合刚接触数据接入、想在本地快速验证抽取清洗方案的开发者和运维。下面不重复官方文档只讲动手时会真正遇到的东西。2. Kettle 基础转换、作业和两类流的最小认知模型开始点鼠标之前先把 Kettle 里最容易把新人绕晕的三个概念分清转换Transformation、作业Job和跳Hop。理解这三样后面配步骤就不是在黑匣子里瞎试而是知道每一步到底在做什么。2.1 转换与作业一个有图形界面的两个容器转换对应磁盘上的.ktr文件作业对应.kjb文件。这个后缀很重要因为命令行跑批时靠它区分用哪个执行器。转换的核心特征是数据处理流水线。转换里的执行单元叫步骤Step步骤之间用连线Hop连接数据像水一样从上游步骤流到下游步骤。转换的特点一是步骤之间默认并行运行而不是像写程序一样一行一行顺序执行二是每条数据经过连线时Kettle 会把它放在内存的行集Row Set里缓冲。这个机制带来的直接后果是如果下游处理太慢上游不会无限读数据缓冲满了会自然背压。作业则完全不是这套逻辑。作业里的执行单元叫作业条目Job Entry它管的是“什么时候该做什么事”的控制流比如先执行转换 A、再发送邮件、成功了才执行转换 B。作业条目的连线是“上一个做完、并且结果满足条件才走这条线”的关系连线上有成功、失败、无条件之分。基础阶段可以简单记转换管数据处理作业管流程编排。这里插一句选型上的常见误区很多教材强调一定要用作业来调度转换但实际做数仓接入时单次一次性同步直接用转换跑就够了只有涉及多步依赖、失败重试、定时循环时才需要套一层作业。作业是执行框架不是所有转换的必需品。2.2 数据流与控制流Kettle 里最容易混淆的边界我见过不少新同事把作业当成“能处理数据的转换”去用想在作业里直接拖一个“表输入”步骤来做查询结果发现作业条目列表里根本没有表输入只有“SQL 脚本”“转换”“发送邮件”这些执行型条目。原因就是刚才说的作业只管控制流不做逐行数据处理。反过来转换里也不是完全不能有控制逻辑。每个步骤下方有“主输出”“错误处理”两种输出流比如“表输出”写目标表失败时错误行会沿错误流走你可以接一个“文本文件输出”把坏行单独落盘。这算转换内部的轻量分支但复杂度马上上来基础阶段不建议一上来就玩多输出流先把单条主链路跑通。连线Hop上还有一个在图形界面里常被忽略的属性在连线上“右击 → 编辑跳”→ 修改“发送”和“接受”状态。默认是单向且启用如果误取消了启用数据不会流动现象是跑完转换后目标表没数据而日志里也没有任何报错。这种“没有报错但没数据”的情况排查顺序里一定要有“看连线是否停用”这一项。2.3 一个最小 .ktr 文件长什么样图形界面拖完保存后Kettle 会生成 XML。很多新人以为只能靠鼠标操作一旦要批量生成或做版本对比就无从下手。其实你完全可以打开一个.ktr文件直接看结构。一个只有“CSV 输入 → 表输出”的转换骨架大概是这样的transformation info nameuser_csv_to_db/name /info step nameread_csv/name typeCsvInput/type encodingUTF-8/encoding filename${INPUT_FILE}/filename delimiter,/delimiter enclosure/enclosure headerY/header bufferSize50000/bufferSize /step step namewrite_db/name typeTableOutput/type connectionlocal_mysql/connection tableods_user/table commitSize1000/commitSize /step hop fromread_csv/from towrite_db/to enabledY/enabled /hop /transformation这个片段里typeCsvInput/type是步骤类型的内部名称connection指向我们在数据库连接里配置的连接名${INPUT_FILE}则是一个变量占位符运行时通过命令行传入真实路径。建议每次保存转换后都顺手打开 XML 看一遍字段名很多界面上的问题其实是配置名写错了比如连接名带空格导致执行时找不到连接。理解了这个结构后面用命令行跑转换时-param传参对到哪里心里就有数了。3. 从零跑通第一个转换CSV 入库的六步操作链纸上概念讲完直接做第一个能跑出结果的东西把一份 CSV 文件读进来简单清洗写进数据库表。整个过程走通之后Kettle 的套路就摸到一半了。3.1 新建转换与输入步骤配置打开 Kettle 图形界面后新建一个转换先把“CSV 文件输入”拖到画布这是基础课里最推荐作为起点的步骤。它比“文本文件输入”配置简单没有繁琐的正则切割规则适合第一次上手。双击进入配置需要定几个核心参数文件路径、分隔符、是否首行作为标题、编码格式。我一般会把文件路径写成变量比如${INPUT_FILE}而不是写死本机路径。原因很简单同一个转换在开发机、测试机、生产机上跑路径一定不一样写死路径等于每换一次环境就改一次文件。编码这个选项容易被无视。手头 CSV 是从 Windows 导出的很可能是 GBK 或 GB18030从线上 Linux 导出的一般是 UTF-8。这里选错不会报错而是导入后字符串字段全变乱码属于 Kettle 新手第一坑后面避坑章节专门展开。参数列表大致如下配置项建议值说明文件/目录${INPUT_FILE}用变量代替硬编码路径分隔符,与 CSV 实际分隔符严格一致头部是首行当列名可省去后续字段映射编码UTF-8 / GBK看文件本身别猜用命令 file 看并行读文件否小文件别开会改变行顺序3.2 字段映射、值映射与输出配置输入步骤读出来的字段不一定直接能写进目标表。常见差异有三类源字段多余目标字段、类型不匹配、值域需要归一化。我通常会在输入之后拖一个“字段选择”步骤把不需要的字段裁掉同时在这里改类型和长度。比如 CSV 里所有字段解析出来默认可能是 String目标表age是整数就在这里把age改为 Integer8长度。如果源数据里性别存的是1/0而目标表要求男/女就在字段选择后面加一个“值映射”步骤源值1映射为男0映射为女目标值是空或异常的保留原值后面再单独处理。最后把“表输出”拖进来配置数据库连接和目标表名。需要注意“表输出”步骤默认行为是追加写入不是清空重建。如果希望同步前清掉旧数据要么在转换最前面加一个“执行 SQL 脚本”步骤先TRUNCATE要么在作业里用作业条目的“SQL 脚本”完成。很多新人直接跑两次转换发现目标表数据翻倍就是这个默认行为没搞清楚。3.3 在命令行用 Pan 跑转换图形界面里点“运行”能直接看到结果但真实场景中转换要被定时任务调用必须学会命令行执行。Kettle 安装目录下有两个执行器pan.sh对应 Windows 的pan.bat跑转换kitchen.sh对应kitchen.bat跑作业。# 切换到 Kettle 安装目录 cd /opt/kettle/data-integration # 执行转换传入输入文件变量日志级别用 Basic ./pan.sh -file:/data/etl/user_csv_to_db.ktr \ -param:INPUT_FILE/data/etl/input/user.csv \ -level:Basic参数说明-file指定转换文件绝对路径-param用来传变量格式是-param:变量名值一个-param只能传一个变量多个变量就写多个-param-level控制日志明细基础运行用Basic排查数据问题时切到Rowlevel但逐行输出日志在数据量大时能把人卡死平时不要用。这里还有个容易踩的位置在 Windows 上跑要写pan.bat而且路径里有空格时最好用引号把-file值包起来。如果嫌命令行输出乱码先执行chcp 65001切换到 UTF-8 代码页再运行。4. 高频步骤的参数取舍表输入、排序合并与增量同步第一个转换跑通之后接下来你接触最多的业务场景大概率的不是 CSV而是库表之间的搬运和比对。这一章讲三组高频步骤表输入与表输出、排序与去重、合并记录并给出参数到底该怎么设。4.1 表输入与表输出SQL 写在哪、分页怎么设如果你面对的数据在数据库里就别绕道 CSV 了直接用“表输入”步骤。“表输入”的本质是一个 SQL 查询执行器查询结果就是数据流。配置时分两步选好数据库连接然后写 SQL。在实际项目里我很少在表输入里写整张表SELECT *而是把过滤条件尽量留在 SQL 里下推给数据库。比如同步updated_at大于上次时间的增量数据就直接写进 SQLSELECT id, user_name, age, updated_at FROM source_user WHERE updated_at ${LAST_RUN}这段 SQL 里的${LAST_RUN}是 Kettle 变量运行时会被替换成上次同步时间戳。原则是“能在 SQL 里过滤的不要等数据全量拉回来再用步骤过滤”Kettle 的过滤步骤虽然好用但数据已经过一次网络传输了性能差距在高并发拉大表时非常明显。表输出的参数是性能核心重点看提交记录大小和批量插入两个配置参数名作用我常用的设置提交记录大小攒够多少行一次性提交事务5002000小表 500大表 2000使用批量插入走 JDBC 批处理大幅减少网络往返开启表名目标表名写完整表名不要带库名前缀忽略插入错误出错时跳过继续跑默认关闭留着错误流接日志提交记录大小的道理和批量插入类似默认值偏保守每次写一行就提交一次事务开销全耗在提交上。调大后目标表的写入表现会明显上一个台阶。但如果你用的是 MySQL 且对端开了 binlog批量插入会产生大量单条 binlog 事件同步期间目标库的从库延迟可能升高这属于要权衡的副作用。4.2 排序去重与合并记录什么时候交给内存什么时候退给数据库Kettle 里做去重有两种常见组合一种是“排序去重”先按主键排序再用“唯一行”步骤去重另一种是“按字段值去重”它不要求排序但只能保留首次出现的行。前者适合大表后者适合小数据量、且不关心顺序的场景。排序步骤有个关键参数排序缓冲区大小也就是内存里最多缓存多少行。默认配置偏保守几十万行以内没事上千万行不做调优就可能触发内存问题。直接用“排序”步骤时我一般先看数据量估算单表超过 500 万行优先在表输入的 SQL 里ORDER BY并用数据库的索引来排而不是拉回来让 Kettle 排。数据库擅长的事别买 单这是 ETL 调优的第一原则。合并记录Merge Rows是增量同步和表对比里最常用的步骤。它要求两个输入一个是参考流一个是对比流两路都先按关键字排序然后逐行比较。配置要点如下配置项含义注意点参考输入Reference一般是目标表已有数据必须与对比流排序规则一致对比输入Comparison一般是源表新数据字段集合要和参考流一致关键字段Keys业务主键如 user_id只做匹配不比较差异比较字段Values需要比对内容的字段如 name空值会被视为不相等先预处理标志字段Flag输出差异标记列值为 identical / new / changed / deleted这个步骤是理解 Kettle 数据流的好样本它不改变数据本身而是给每行打标签。真正的动作在标签之后的“过滤记录”步骤里把 flag 为new的行导到表输出做插入changed的行导到更新步骤deleted的行按需处理。没有这一步合并记录只是看个热闹。4.3 数据校验与空值处理脏数据就地拦截数据清洗里最烦的是空值。Kettle 里空值不是统一的NULL可能是空字符串、空格、字符串NULL三种形态。基础阶段用一个“值映射” 一个“空值替换”步骤组合处理值映射把NULL这类字面量映射成空串然后再把空串统一替换成真正的NULL或业务默认值。这里容易犯的毛病是在转换中间某一步处理了空值却发现下游步骤里的空值又回来了。原因多半是“计算器”或“字段选择”步骤重新生成了字段新字段默认不继承上游的空值处理。字段选择里改名、改类型后建议立即接一个“空值替换”步骤再把关一道别指望流程后面还有机会补救。5. Kettle 避坑手册编码、提交、驱动与合并的四场实战这一章是血泪经验汇总。前四章讲怎么做这一章讲的是做了之后为什么翻车以及翻车时看哪里。5.1 中文乱码CSV 读进来到处都是“?”现象CSV 里的中文通过“CSV 文件输入”读进来预览时已经乱码写进数据库后变成???或者彻底不可读。排查半天最后发现三个地方的编码没对齐CSV 文件本身是 GBK、输入步骤里设的是 UTF-8、数据库连接字符集又是 latin1 之类。原因Kettle 每个步骤、每个数据库连接都有独立的字符集设置任何一个环节断掉就乱码。很多人只改输入步骤忽略了数据库连接 URL 里的字符集参数。解决先把 CSV 文件用文本编辑器或file命令确认真实编码输入步骤选对应编码再把数据库连接的连接参数里加上characterEncodingutf8。实践中我遇到最多的组合是“文件 GBK 数据库 UTF-8”这种场景不要在输入步骤里写死 UTF-8直接把文件另存为 UTF-8 再做省得中间步骤反复转码。5.2 表输出慢得离谱几千行写了几分钟现象一个只有 3000 行的转换前几步秒完到表输出像卡死一样日志里没有任何错误。原因表输出的提交记录大小用了默认值并且“使用批量插入”没开。Kettle 每攒够一次提交就发一次事务逐行提交时数据库端每行都要同步一次落盘几千行就产生几千次事务往返慢是必然的。解决把提交记录大小调到 1000 以上打开批量插入再跑一次基本能快一到两个数量级。这里要提醒批量插入对目标端数据类型隐式转换容忍度低如果源数据类型和目标字段类型不一致会从“慢”变成“报错”。所以先保证字段映射类型正确再开批量。5.3 数据库驱动与连接参数连不上 MySQL 的经典翻车现象新建 MySQL 连接时点测试报Class not found或者提示The server time zone value ...无法识别。原因一是 Kettle 自带的 lib 目录里没有对应版本驱动 jarMySQL 8 的驱动类名和旧版都不一样二是新版 MySQL 驱动要求 URL 带上时区参数。解决先把对应版本的 JDBC 驱动 jar 放进style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
