简介KettlePentaho Data Integration是一款由Java开发、跨平台运行的开源ETL工具面向数据工程师与数据分析人员用于解决多源数据抽取、转换与加载问题。其图形化界面Spoon支持拖拽式无编码开发可对接传统数据库、文件、大数据平台、接口及流数据并能融入机器学习算法。压缩包内为Kettle 7.1发行版整体资源共1928个文件以1302个jar程序库为核心包含200个ktr转换文件、99个xml配置、71个cfg参数文件以及启动脚本、界面图标、示例表格等压缩包约827MB目录结构完整便于本地部署与二次开发。已有1491人学习下载适合需要快速搭建ETL环境、研究Kettle内部结构或基于该版本定制数据管道的开发者参考。1. Kettle 7.1开源的ETL工具为什么到现在还有人翻出来用把一张订单 CSV 灌进业务库或者每天凌晨同步一次用户表本不需要搭实时数据平台。很多团队绕了一圈又翻出 Kettle 7.1 这个开源的 ETL 工具因为它把抽取、清洗、加载做成了能在 Spoon 界面里拖拽完成的任务不用写调度框架不用维护一堆脚本不同数据源也能接。7.1 是社区存量最大、被生产验证最久的版本对应安装包通常是 pdi-ce-7.1.0.0-12。这篇笔记写给两类人一类要快速交付批量同步任务的实施人员另一类在评估 Kettle 值不值得用于下一套离线任务的开发。结论先放这里数据量千万级以下、以定时批处理为主、团队不想为 ETL 专门维护代码时Kettle 7.1 依然是一个务实选择。2. Kettle 7.1 的两种任务模型与本地部署转换和作业先分清2.1 任务模型转换是数据管道作业是控制流程上手第一周最容易搞混的是转换和作业。转换Transformation解决“数据怎么流”从一个输入步骤读数据经过清洗步骤再写到输出步骤步骤之间通过行集交换数据每行数据长度有限步骤天然并行。作业Job解决“任务怎么排”把转换、SQL 脚本、文件检查、发送邮件串成一条有先后顺序的控制流作业内部还可以做定时触发。判断用哪个模型我一般问三个问题是不是只处理一批输入并产生一批输出用转换。是不是要按顺序执行多个步骤失败就停止用作业。是不是要定时启动在作业里放 Start或者交给系统调度器调 Kitchen。两者落到磁盘是 .ktr 和 .kjb 两种文件Kettle 7.1 默认用文件仓库把任务保存为 XML 文件方便纳入版本管理。很多人把多个转换的步骤连成一个大转换结果并行层级变深、内存涨、排错困难常见做法是一个转换只干一件事抽取、清洗、加载各自独立成转换再用作业串起来。版本选择上别盲目追新。7.1 是社区里被大量生产项目验证过的版本插件生态旧但稳定很多历史任务还是 .ktr/.kjb 格式直接拿新版本打开反而有兼容性变更。我的原则是老项目不动新项目如果团队没有特殊诉求也可以继续用 7.1数据量不大时它足够用。2.2 解压到启动Java 环境与 Spoon 的第一次启动拿到压缩包后我一般解压到固定目录比如 /opt/data-integration。这一步唯一要注意的是目录路径里不要有空格Spoon 对带空格的路径支持不好启动时容易报找不到资源。先确认 Java 环境Kettle 7.1 官方对应 JDK 8用高版本 JDK 可能遇到反射或类加载问题。命令行检查java -version echo $JAVA_HOME如果 JAVA_HOME 为空先设置再启动export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cd /opt/data-integration ./spoon.shspoon.sh 是 Linux 下的启动脚本Windows 用 Spoon.bat。第一次启动会停留在欢迎页并初始化插件耗时几十秒属正常。如果启动后界面空白或者工具栏没反应多半是显卡或字体问题可以改用软件渲染启动./spoon.sh -swt参数说明-swt 让 Spoon 使用 SWT 软件渲染模式适合无桌面环境或远程窗口转发的场景。如果 Spoon 启动后主窗口只有菜单没有画布检查显示器变量是否设置远程服务器上用窗口转发时加上 -swt 基本能解决。这些都属于环境问题先排除再谈任务开发。2.3 内存参数与数据库驱动连上 MySQL 前的两个必要动作7.1 默认堆内存并不宽裕批量导入几百万行时很可能内存溢出。打开 spoon.sh 找到这一行PENTAHO_DI_JAVA_OPTIONS-Xmx2048m -Xms256m -XX:MaxPermSize256m改成适合本机内存的值比如 4G 堆PENTAHO_DI_JAVA_OPTIONS-Xmx4096m -Xms512m -XX:MaxPermSize512m -Dfile.encodingUTF-8这个变量同时作用于 Spoon 和 Kitchen改一处即可。-Xmx 是最大堆-Xms 是初始堆MaxPermSize 是早期 JDK8 的永久代上限。如果机器内存有限Xmx 宁可设小也不要让系统频繁交换。数据库驱动方面7.1 自带的 lib 目录里没有 MySQL 驱动需要把对应版本的 JDBC 驱动 jar 放进 lib 并重启 Spoon。驱动与数据库版本不匹配时典型表现是能建连接但跑任务时 SQL 报错或时间类型读写异常。连接配置里我一般会在“选项”页追加 URL 参数useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8这样做的原因新版 MySQL 驱动默认开启 SSL本地测试时经常握手失败serverTimezone 解决日期时间字段写入报“无法转换”的问题。驱动版本有个经验MySQL 5.6/5.7 用 5.1.4x 系列最省事MySQL 8.0 用 8.0.x 驱动。不要把 lib 目录下的驱动一股脑全丢进去多个驱动相互竞争时测试连接可能直接失败。连接配置里密码带特殊字符时建议用命名参数传入避免写死在转换文件里。3. 用 Spoon 做一个 CSV 入库转换组件、参数与运行细节3.1 新建转换并配置 CSV 文件输入从文件到字段映射启动 Spoon 后文件 → 新建 → 转换。左侧“核心对象”的“输入”分类下找到“CSV 文件输入”拖到画布双击打开配置。文件相关配置项文件名填绝对路径避免相对路径在不同工作目录下出错编码默认 UTF-8如果源文件是其他编码按实际修改分隔符填逗号“是否包含标题行”选是“限制”默认空表示不限制读取行数。字段映射点“获取字段”按钮让 Kettle 读文件头自动生成字段列表。这一步有两个容易踩的点一是日期字段读进来类型可能是 String需要手动改成 Date并输入格式 yyyy-MM-dd 或 yyyy-MM-dd HH:mm:ss二是某些 CSV 的列头带 BOMKettle 会把它显示成特殊字符开头导致后续字段名对不上解决办法是把第一个字段名手动改掉。字段名匹配问题如果发生在输出步骤运行时会报“无法找到字段 xxx”这时回到输入步骤看字段列表即可定位。Kettle 7.1 里还有“文本文件输入”组件很多人会误选。CSV 文件输入速度快适合分隔符规整的简单文件文本文件输入支持正则、多行记录、复杂分隔但配置繁琐。绝大多数日常文件处理用 CSV 文件输入就够了别一上来用文本文件输入给自己加难度。一个最小转换只要三步CSV 输入 → 字段选择 → 表输出。步骤之间用 Shift 拖出连线箭头方向决定数据流向如果反向连线数据会原地打转运行时报“没有可执行的步骤”或输出行数为零。保存成 user_load.ktr建议路径 /opt/etl/transformations/文件名不要用中文作业调用时中文路径在部分系统上会出问题。3.2 用“字段选择”清理列用“表输出”写数据库从“转换”分类拖一个“字段选择”到画布把 CSV 输入到字段选择之间拉一条连线。字段选择的作用是裁剪列、改名、改类型在“选择和修改”标签页里逐列配置元数据。清理过脏列后从“输出”分类拖“表输出”进来。表输出是写数据库最直接的步骤关键配置有三个数据库连接选刚才建好的连接目标表直接填表名或者用 ${table_name}提交记录数指每累积多少行提交一次事务。默认情况下表输出按“流字段名等于表字段名”自动映射真实环境命名经常不一致这时进入“数据库字段”标签页把表的字段和流里的字段手动拉平。一个新手经常翻车的操作流里是 user_id表里是 uid不映射直接运行第一条插入就会报“列不存在”。提交批次和事务有关不是行数越多越快。批次太大会让单次事务过长中途失败回滚也慢批次太小又频繁提交网络往返多。针对千万级以下数据我习惯设 5000如果目标表有索引且并发量不大10000 也无妨。这里还要澄清表输出默认生成 INSERT如果没有处理已存在记录的逻辑主键冲突就会中断任务这个留到第 5 章展开。3.3 运行预览与日志查看看懂行数和“Caused by”配置完点击运行按钮弹出运行配置窗口。日志级别选“基本”即可它能显示每个步骤读入多少行、写出多少行、出错多少行也能看到事务提交的批次信息如果问题出在数据内容本身再把级别调到“详细”重跑一次。级别越高写日志越频繁全量数据任务慎用“调试”。运行后主界面下方有“执行结果”面板里面的“步骤度量”表格会把每个步骤的输入、输出、错误行数列出来。我排查问题的顺序先看哪个步骤有错误行再看该步骤配置最后看日志里第一处红色堆栈。很多人看到长堆栈就慌其实关键就在结尾的 Caused by 一行比如 Caused by: java.sql.SQLException: Unknown column uid in field list这已经直接告诉你是字段映射问题不用往下读了。日常维护里我一般会在转换文件头部配置命名参数把文件名和目录做成变量后面接作业调度时不用改转换文件本身。命名参数在第 4 章展开。4. 用作业把转换管起来定时、依赖与命令行运行4.1 作业设计思路与三个基础步骤转换负责数据管道作业负责执行顺序。新建作业后左侧“作业”分类里能看到 Start、成功、失败、转换、SQL、Shell 等步骤。一个最简单但有意义的作业包含Start 开始、转换调用第 3 章保存的 user_load.ktr、成功结束。双击“转换”步骤选择 .ktr 文件作业执行时从上往下沿着跳走。作业的跳分两种无条件跳和条件跳。默认连线是无条件执行完上游继续跑下游从步骤右侧拉出的连线可以选择“失败”或“成功”作为条件。我的做法Start 到转换用无条件转换到成功用无条件转换到失败步骤用失败条件。这样失败时日志会明确指示从哪个组件走到了失败分支。为什么要用作业而不是大转换因为作业天然支持有条件的执行比如判断文件存在再执行转换、转换失败就发告警邮件。这些控制逻辑放在转换里要靠复杂步骤组合放在作业里只是加一个步骤的事。7.1 的作业还支持定时触发双击 Start 选“定时”配置运行时间不过内置调度跨系统迁移不跟手生产调度交给 crontab 或第三方调度平台更靠谱。4.2 变量与命名参数让一个转换适配多张表把数据库表名、CSV 路径、日期这些经常变化的值抽出来是让 ETL 任务可维护的关键一步。Kettle 7.1 可以在转换或作业的设置里定义命名参数引用时写成 ${参数名}。作业执行时会从调用方接收参数再传递给内部转换。例如 user_load.ktr 里表输出步骤的目标表写 ${table_name}CSV 输入步骤的文件名写 ${src_file}。调用时传参./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic \ -param:table_nameods_user -param:src_file/data/input/user.csv参数说明-param 键值对覆盖作业内同名参数作业里继续传给转换需要在作业的“转换”步骤里手动勾选“传递命名参数”。命名参数的默认值设置很重要同一个转换被两个作业调用时一个传了 src_file另一个没传没传的会直接跑挂。我给每个命名参数都填默认值即使只是占位Spoon 的运行配置窗口里也能临时覆盖参数值方便调试。这里有个新手普遍搞混的点变量和命名参数不是一回事。变量是运行时环境里全局可读的键值命名参数是定义在任务入口、可以随调用传入的显式参数。我建议一律用命名参数因为它在 Spoon 运行配置里能看到默认值排错比变量直观得多。4.3 用 Kitchen 脱离界面跑作业命令行、返回码与 crontabSpoon 是开发环境生产上跑任务必须用命令行引擎。作业用 kitchen.sh单个转换用 pan.sh两者都在>cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic \ -param:table_nameods_user -param:src_file/data/input/user.csv执行结束后用 echo $? 看返回码0 表示成功非 0 表示失败。如果任务有多个转换我一般把它们串进同一个作业而不是在 crontab 里写多行 kitchen 命令作业内部失败时能立刻中断后续步骤多行命令则可能在本该失败时继续往下跑。crontab 的标准模板0 2 * * * cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic /var/log/etl/kitchen.log 21这段命令的含义每天凌晨 2 点进到>#!/bin/bash export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic /var/log/etl/kitchen.log 21然后把 crontab 改成0 2 * * * /opt/etl/run_job.sh。另一点crontab 里用相对路径时工作目录是用户主目录脚本里必须 cd 到 style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
简介KettlePentaho Data Integration是一款由Java开发、跨平台运行的开源ETL工具面向数据工程师与数据分析人员用于解决多源数据抽取、转换与加载问题。其图形化界面Spoon支持拖拽式无编码开发可对接传统数据库、文件、大数据平台、接口及流数据并能融入机器学习算法。压缩包内为Kettle 7.1发行版整体资源共1928个文件以1302个jar程序库为核心包含200个ktr转换文件、99个xml配置、71个cfg参数文件以及启动脚本、界面图标、示例表格等压缩包约827MB目录结构完整便于本地部署与二次开发。已有1491人学习下载适合需要快速搭建ETL环境、研究Kettle内部结构或基于该版本定制数据管道的开发者参考。1. Kettle 7.1开源的ETL工具为什么到现在还有人翻出来用把一张订单 CSV 灌进业务库或者每天凌晨同步一次用户表本不需要搭实时数据平台。很多团队绕了一圈又翻出 Kettle 7.1 这个开源的 ETL 工具因为它把抽取、清洗、加载做成了能在 Spoon 界面里拖拽完成的任务不用写调度框架不用维护一堆脚本不同数据源也能接。7.1 是社区存量最大、被生产验证最久的版本对应安装包通常是 pdi-ce-7.1.0.0-12。这篇笔记写给两类人一类要快速交付批量同步任务的实施人员另一类在评估 Kettle 值不值得用于下一套离线任务的开发。结论先放这里数据量千万级以下、以定时批处理为主、团队不想为 ETL 专门维护代码时Kettle 7.1 依然是一个务实选择。2. Kettle 7.1 的两种任务模型与本地部署转换和作业先分清2.1 任务模型转换是数据管道作业是控制流程上手第一周最容易搞混的是转换和作业。转换Transformation解决“数据怎么流”从一个输入步骤读数据经过清洗步骤再写到输出步骤步骤之间通过行集交换数据每行数据长度有限步骤天然并行。作业Job解决“任务怎么排”把转换、SQL 脚本、文件检查、发送邮件串成一条有先后顺序的控制流作业内部还可以做定时触发。判断用哪个模型我一般问三个问题是不是只处理一批输入并产生一批输出用转换。是不是要按顺序执行多个步骤失败就停止用作业。是不是要定时启动在作业里放 Start或者交给系统调度器调 Kitchen。两者落到磁盘是 .ktr 和 .kjb 两种文件Kettle 7.1 默认用文件仓库把任务保存为 XML 文件方便纳入版本管理。很多人把多个转换的步骤连成一个大转换结果并行层级变深、内存涨、排错困难常见做法是一个转换只干一件事抽取、清洗、加载各自独立成转换再用作业串起来。版本选择上别盲目追新。7.1 是社区里被大量生产项目验证过的版本插件生态旧但稳定很多历史任务还是 .ktr/.kjb 格式直接拿新版本打开反而有兼容性变更。我的原则是老项目不动新项目如果团队没有特殊诉求也可以继续用 7.1数据量不大时它足够用。2.2 解压到启动Java 环境与 Spoon 的第一次启动拿到压缩包后我一般解压到固定目录比如 /opt/data-integration。这一步唯一要注意的是目录路径里不要有空格Spoon 对带空格的路径支持不好启动时容易报找不到资源。先确认 Java 环境Kettle 7.1 官方对应 JDK 8用高版本 JDK 可能遇到反射或类加载问题。命令行检查java -version echo $JAVA_HOME如果 JAVA_HOME 为空先设置再启动export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cd /opt/data-integration ./spoon.shspoon.sh 是 Linux 下的启动脚本Windows 用 Spoon.bat。第一次启动会停留在欢迎页并初始化插件耗时几十秒属正常。如果启动后界面空白或者工具栏没反应多半是显卡或字体问题可以改用软件渲染启动./spoon.sh -swt参数说明-swt 让 Spoon 使用 SWT 软件渲染模式适合无桌面环境或远程窗口转发的场景。如果 Spoon 启动后主窗口只有菜单没有画布检查显示器变量是否设置远程服务器上用窗口转发时加上 -swt 基本能解决。这些都属于环境问题先排除再谈任务开发。2.3 内存参数与数据库驱动连上 MySQL 前的两个必要动作7.1 默认堆内存并不宽裕批量导入几百万行时很可能内存溢出。打开 spoon.sh 找到这一行PENTAHO_DI_JAVA_OPTIONS-Xmx2048m -Xms256m -XX:MaxPermSize256m改成适合本机内存的值比如 4G 堆PENTAHO_DI_JAVA_OPTIONS-Xmx4096m -Xms512m -XX:MaxPermSize512m -Dfile.encodingUTF-8这个变量同时作用于 Spoon 和 Kitchen改一处即可。-Xmx 是最大堆-Xms 是初始堆MaxPermSize 是早期 JDK8 的永久代上限。如果机器内存有限Xmx 宁可设小也不要让系统频繁交换。数据库驱动方面7.1 自带的 lib 目录里没有 MySQL 驱动需要把对应版本的 JDBC 驱动 jar 放进 lib 并重启 Spoon。驱动与数据库版本不匹配时典型表现是能建连接但跑任务时 SQL 报错或时间类型读写异常。连接配置里我一般会在“选项”页追加 URL 参数useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8这样做的原因新版 MySQL 驱动默认开启 SSL本地测试时经常握手失败serverTimezone 解决日期时间字段写入报“无法转换”的问题。驱动版本有个经验MySQL 5.6/5.7 用 5.1.4x 系列最省事MySQL 8.0 用 8.0.x 驱动。不要把 lib 目录下的驱动一股脑全丢进去多个驱动相互竞争时测试连接可能直接失败。连接配置里密码带特殊字符时建议用命名参数传入避免写死在转换文件里。3. 用 Spoon 做一个 CSV 入库转换组件、参数与运行细节3.1 新建转换并配置 CSV 文件输入从文件到字段映射启动 Spoon 后文件 → 新建 → 转换。左侧“核心对象”的“输入”分类下找到“CSV 文件输入”拖到画布双击打开配置。文件相关配置项文件名填绝对路径避免相对路径在不同工作目录下出错编码默认 UTF-8如果源文件是其他编码按实际修改分隔符填逗号“是否包含标题行”选是“限制”默认空表示不限制读取行数。字段映射点“获取字段”按钮让 Kettle 读文件头自动生成字段列表。这一步有两个容易踩的点一是日期字段读进来类型可能是 String需要手动改成 Date并输入格式 yyyy-MM-dd 或 yyyy-MM-dd HH:mm:ss二是某些 CSV 的列头带 BOMKettle 会把它显示成特殊字符开头导致后续字段名对不上解决办法是把第一个字段名手动改掉。字段名匹配问题如果发生在输出步骤运行时会报“无法找到字段 xxx”这时回到输入步骤看字段列表即可定位。Kettle 7.1 里还有“文本文件输入”组件很多人会误选。CSV 文件输入速度快适合分隔符规整的简单文件文本文件输入支持正则、多行记录、复杂分隔但配置繁琐。绝大多数日常文件处理用 CSV 文件输入就够了别一上来用文本文件输入给自己加难度。一个最小转换只要三步CSV 输入 → 字段选择 → 表输出。步骤之间用 Shift 拖出连线箭头方向决定数据流向如果反向连线数据会原地打转运行时报“没有可执行的步骤”或输出行数为零。保存成 user_load.ktr建议路径 /opt/etl/transformations/文件名不要用中文作业调用时中文路径在部分系统上会出问题。3.2 用“字段选择”清理列用“表输出”写数据库从“转换”分类拖一个“字段选择”到画布把 CSV 输入到字段选择之间拉一条连线。字段选择的作用是裁剪列、改名、改类型在“选择和修改”标签页里逐列配置元数据。清理过脏列后从“输出”分类拖“表输出”进来。表输出是写数据库最直接的步骤关键配置有三个数据库连接选刚才建好的连接目标表直接填表名或者用 ${table_name}提交记录数指每累积多少行提交一次事务。默认情况下表输出按“流字段名等于表字段名”自动映射真实环境命名经常不一致这时进入“数据库字段”标签页把表的字段和流里的字段手动拉平。一个新手经常翻车的操作流里是 user_id表里是 uid不映射直接运行第一条插入就会报“列不存在”。提交批次和事务有关不是行数越多越快。批次太大会让单次事务过长中途失败回滚也慢批次太小又频繁提交网络往返多。针对千万级以下数据我习惯设 5000如果目标表有索引且并发量不大10000 也无妨。这里还要澄清表输出默认生成 INSERT如果没有处理已存在记录的逻辑主键冲突就会中断任务这个留到第 5 章展开。3.3 运行预览与日志查看看懂行数和“Caused by”配置完点击运行按钮弹出运行配置窗口。日志级别选“基本”即可它能显示每个步骤读入多少行、写出多少行、出错多少行也能看到事务提交的批次信息如果问题出在数据内容本身再把级别调到“详细”重跑一次。级别越高写日志越频繁全量数据任务慎用“调试”。运行后主界面下方有“执行结果”面板里面的“步骤度量”表格会把每个步骤的输入、输出、错误行数列出来。我排查问题的顺序先看哪个步骤有错误行再看该步骤配置最后看日志里第一处红色堆栈。很多人看到长堆栈就慌其实关键就在结尾的 Caused by 一行比如 Caused by: java.sql.SQLException: Unknown column uid in field list这已经直接告诉你是字段映射问题不用往下读了。日常维护里我一般会在转换文件头部配置命名参数把文件名和目录做成变量后面接作业调度时不用改转换文件本身。命名参数在第 4 章展开。4. 用作业把转换管起来定时、依赖与命令行运行4.1 作业设计思路与三个基础步骤转换负责数据管道作业负责执行顺序。新建作业后左侧“作业”分类里能看到 Start、成功、失败、转换、SQL、Shell 等步骤。一个最简单但有意义的作业包含Start 开始、转换调用第 3 章保存的 user_load.ktr、成功结束。双击“转换”步骤选择 .ktr 文件作业执行时从上往下沿着跳走。作业的跳分两种无条件跳和条件跳。默认连线是无条件执行完上游继续跑下游从步骤右侧拉出的连线可以选择“失败”或“成功”作为条件。我的做法Start 到转换用无条件转换到成功用无条件转换到失败步骤用失败条件。这样失败时日志会明确指示从哪个组件走到了失败分支。为什么要用作业而不是大转换因为作业天然支持有条件的执行比如判断文件存在再执行转换、转换失败就发告警邮件。这些控制逻辑放在转换里要靠复杂步骤组合放在作业里只是加一个步骤的事。7.1 的作业还支持定时触发双击 Start 选“定时”配置运行时间不过内置调度跨系统迁移不跟手生产调度交给 crontab 或第三方调度平台更靠谱。4.2 变量与命名参数让一个转换适配多张表把数据库表名、CSV 路径、日期这些经常变化的值抽出来是让 ETL 任务可维护的关键一步。Kettle 7.1 可以在转换或作业的设置里定义命名参数引用时写成 ${参数名}。作业执行时会从调用方接收参数再传递给内部转换。例如 user_load.ktr 里表输出步骤的目标表写 ${table_name}CSV 输入步骤的文件名写 ${src_file}。调用时传参./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic \ -param:table_nameods_user -param:src_file/data/input/user.csv参数说明-param 键值对覆盖作业内同名参数作业里继续传给转换需要在作业的“转换”步骤里手动勾选“传递命名参数”。命名参数的默认值设置很重要同一个转换被两个作业调用时一个传了 src_file另一个没传没传的会直接跑挂。我给每个命名参数都填默认值即使只是占位Spoon 的运行配置窗口里也能临时覆盖参数值方便调试。这里有个新手普遍搞混的点变量和命名参数不是一回事。变量是运行时环境里全局可读的键值命名参数是定义在任务入口、可以随调用传入的显式参数。我建议一律用命名参数因为它在 Spoon 运行配置里能看到默认值排错比变量直观得多。4.3 用 Kitchen 脱离界面跑作业命令行、返回码与 crontabSpoon 是开发环境生产上跑任务必须用命令行引擎。作业用 kitchen.sh单个转换用 pan.sh两者都在>cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic \ -param:table_nameods_user -param:src_file/data/input/user.csv执行结束后用 echo $? 看返回码0 表示成功非 0 表示失败。如果任务有多个转换我一般把它们串进同一个作业而不是在 crontab 里写多行 kitchen 命令作业内部失败时能立刻中断后续步骤多行命令则可能在本该失败时继续往下跑。crontab 的标准模板0 2 * * * cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic /var/log/etl/kitchen.log 21这段命令的含义每天凌晨 2 点进到>#!/bin/bash export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cd /opt/data-integration ./kitchen.sh -file/opt/etl/jobs/daily_load.kjb -levelBasic /var/log/etl/kitchen.log 21然后把 crontab 改成0 2 * * * /opt/etl/run_job.sh。另一点crontab 里用相对路径时工作目录是用户主目录脚本里必须 cd 到 style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />
