企业官网建设流程全解析

搞数据的人，估计都逃不过这么一关：教务老师发来一堆学生成绩表，Excel一个班一个格式，缺考的空着、学号带着空格、数字存成文本；领导那边要的排名还特别讲究“同分同名次，下一个名次跳过”。我之前接到这类“学生成绩数据导入与排名”需求时，最开始也试过用Excel函数硬算，后来直接换成了Kettle（Pentaho Data Integration，简称PDI）这种可视化ETL工具。它的核心思想很简单：把数据导入、清洗、拼接、计算、输出这一套重复劳动做成一条可以反复执行的流程，下次数据再来，点一下“运行”就全自动跑完。这篇就用一个完整的学生成绩导入与排名项目，把从Kettle下载安装、Excel读入、字段清洗、总分计算、排名实现、结果导出Excel和数据库，再到Linux环境下定时调度的每一个环节都拆开讲，顺手把那些踩过才知道的坑也列出来。对了，如果你是刚接触ETL的数据处理新手，或者经常和报表打交道的教务、运营、财务同学，这篇实战记录可以直接照着抄。

1. 先想清楚再动手：成绩导入排名项目的需求拆解

1.1 输入和输出到底长什么样

任何Kettle项目开工之前，先别急着拖步骤，把“从哪里拿数据”“到哪里交数据”这两件事描述清楚，后面会省很多事。我这个项目的输入是一个教学楼的典型成绩表，大概长这样：

注意，这只是“理想格式”。实际情况中，学号可能变成2024001（带空格），语文成绩可能是'92.5'（文本格式），缺考同学的成绩栏可能是空字符串。目标输出是一张带“总分”和“排名”的明细表，最好同时支持班级排名和年级排名两个维度。

排名规则要提前和领导确认。我这边采用的是标准的竞赛排名规则：总分相同则名次相同，下一个名次跳过。比如两个人并列第1，那么下一个人就是第3，不是第2。这种规则也叫RANK()，和DENSE_RANK()（并列后下一位仍为2）不一样，后面实现方案时我会分别给出代码。

1.2 为什么选Kettle而不是Excel公式和Navicat

面对这种需求，常见的替代方案有三个：Excel手工操作、Navicat手工导入SQL、编写脚本。先说Excel，几十个班的小表格用公式RANK()确实能搞定，但数据一多、格式一乱，公式出错你根本不知道是哪个单元格的问题，而且每个月重复操作一遍非常痛苦。Navicat更适合做数据库管理和单次导入，它能帮你把Excel数据“塞”进SQL，但缺字段清洗、缺排名计算、缺定时跑批，顶多算半自动。写Python脚本当然强大，但业务同事不一定能接手维护。

Kettle的优势正好卡在这个位置上：流程可视化，每一步都摆在那里，同事打开Spoon就能看懂；天然支持批量处理多个Excel文件，支持排序、分组、表连接、JS计算、多样输出；还可以组成作业（Job），交给Linux定时任务或Windows计划任务去每天自动跑。你可以把Kettle理解成一条流水线：把原料（Excel成绩单）放上传送带，经过清洗、计算、包装，最后变成成品（排名报表和数据库记录），整个过程可重复、可追踪。

1.3 一条清晰的处理链路

这个项目的整体处理链路，我建议按下面这条线走：读取Excel → 字段选择与类型转换 → 清洗空值/去空格 → 计算总分 → 按总分降序排序 → 生成行号 → 计算竞赛排名 → 输出Excel → 输出数据库表 → 组成作业定时运行。前几步是数据导入部分，中间两步是排名计算核心，后面的输出和调度负责把结果变成生产力。

这条链路并不是一次性画完就成功的。我通常先做最小闭环：只用单个班级的小Excel，跑通读取、清洗、算分、排名、导出，确认每个环节数据正确，然后再扩展成通配符批量文件和定时作业。这个习惯帮我避免了很多“全量跑完才发现排名规则错了”的返工。

2. 环境准备：Kettle下载安装与Linux部署经验

2.1 下载哪个版本，JDK怎么配

Kettle的官方名称是Pentaho Data Integration（PDI），社区版是免费的。下载时一定要去官方渠道，老项目一般集中在Pentaho官网和官方GitHub仓库，搜索kettle下载或者kettle pdi下载能找到对应版本。版本选择上，我个人的经验是：PDI 9.x系列是当前最稳的生产组合，配JDK 8或JDK 11都可以；如果你机器上已经装了Java 17，建议优先考虑PDI 10.x版本，避免出现奇怪的启动报错。

下载下来是一个压缩包，比如pdi-ce-9.4.0.0-343.zip。解压后，Windows系统直接点Spoon.bat，Mac或者Linux系统运行spoon.sh。启动前先确认Java环境：

java -version

如果提示找不到java，需要先配置JAVA_HOME环境变量。在Linux服务器上：

export JAVA_HOME=/usr/local/jdk8 export PATH=$JAVA_HOME/bin:$PATH

一个常见的坑：解压路径不要放在带空格或中文的目录下，Kettle对这类路径的兼容性有时候很迷，启动时图标一闪而过、日志不输出的情况，多半就是路径问题。

2.2 内存不够就跑不动

Kettle是个Java程序，默认给的堆内存不大，处理几千行成绩没问题，但如果一次性读取多个Excel、中间还有大排序，容易直接OutOfMemoryError。提前把内存调大是性价比最高的操作。

编辑启动脚本，找到下面这些参数：

PENTAHO_DI_JAVA_OPTIONS="-Xms1024m -Xmx2048m"

改成：

PENTAHO_DI_JAVA_OPTIONS="-Xms2048m -Xmx4096m"

这里我建议生产环境直接给4GB，因为排名计算里的排序和分组都是吃内存的活。改完重启Spoon，启动速度会稍微慢一点，但转换跑起来明显不容易崩。如果你跑了几年老机器，分配-Xmx1536m也可以，小项目完全够用。

2.3 Linux环境部署Kettle无图形界面怎么跑

服务器上通常没有桌面环境，没法打开Spoon界面，但Kettle照样能跑，只是把“描画流程”和“执行流程”分开。开发时可以在自己电脑上用Spoon画好转换文件（.ktr）和作业文件（.kjb），然后上传到Linux服务器，用命令行工具执行。

转换用pan.sh，作业用kitchen.sh。命令行执行的示例：

# 执行单个转换 /opt/pdi-ce-9.4.0.0-343/pan.sh -file=/opt/etl/score_to_rank.ktr -level=Basic # 执行整个作业 /opt/pdi-ce-9.4.0.0-343/kitchen.sh -file=/opt/etl/score_rank_job.kjb -level=Detailed

-level参数推荐用Basic或Detailed。Basic只输出关键信息，适合定时任务，日志不会太多；Detailed会把每行的处理情况都打出来，适合调试。配合Linux的定时任务crontab，一个典型的部署配置长这样：

0 2 * * * /opt/pdi-ce-9.4.0.0-343/kitchen.sh -file=/opt/etl/score_rank_job.kjb >> /opt/etl/logs/score_rank_$(date +\%F).log 2>&1

有个细节必须提醒：Linux服务器上推荐使用文件资源库或直接写死.ktr/.kjb文件路径，别去依赖数据库资源库。因为服务器环境跑批要求的是稳定，文件路径是最不容易出幺蛾子的方案；数据库资源库一旦连不上，整个调度就全挂了。

2.4 第一次打开Spoon怎么配置

打开Spoon后，左侧是“转换”和“作业”的树状列表，右侧是工作区，中间下面是核心步骤面板。先到“工具 -> 选项”里把文件资源库目录设置成你能方便访问的路径，然后到“命名参数”里设置项目常用参数。第一次跑转换前，建议先选择菜单栏的“预览”功能查看每一步输出，别直接全量执行。Kettle这个工具有个很友好的特性：每一步都可以单独预览数据，就像SQL里写一个SELECT *看看结果一样，这也是我调试时最依赖的功能。

3. 学生成绩Excel导入Kettle：字段清洗和类型转换

3.1 故意做一张带坑的成绩表

为了演示真实场景，我没有把Excel做得干干净净，反而故意留了一些坑：学号列前面有空格，语文成绩有些单元格是文本格式，数学成绩有的缺考为空，班级名称到底是“高一(1)班”还是“高一（1）班”格式也可能不统一。目的是让读者看到真实的数据导入不是“直接读文件”这么简单，恰恰是Kettle最擅长解决的脏数据问题。

新建一个转换，命名score_rank_transform，第一步从左侧“输入”分类里拖一个Excel输入（Excel Input）步骤。双击进入配置页，选择文件路径，如果多个班就是多个文件，Kettle支持在同一个步骤里配置多行文件名，也支持通配符：

/data/excel/score_2024_*.xlsx

这样每次新文件放进去，文件名符合规则就会被自动读取，非常省心。

3.2 Excel输入步骤怎么配

在Excel输入里重点设置三处：工作表、表头、字段。通常Excel成绩表的第一个Sheet就是数据，所以“Sheet名称”可以留空代表第一个Sheet。第一行是标题的话，“标题行”选项填1，Kettle会自动把表头当字段名。然后点“获取字段”，Kettle会扫描文件把每个列名带出来，接下来需要检查字段类型。

这类成绩表的字段类型，我建议统一这样设置：学号设为String，姓名String，班级String，语文、数学、英语都设为Number，精度设成2位小数。为什么学号要设String？因为学号是唯一标识，不是用来计算的，一旦设成数字类型，超过15位的长数字学号或者带前导零的学号会被截断，后面想按学号关联就全对不上了。

设置完点“预览”，看看前100行数据是否符合预期。这里有个隐藏的坑：Excel文件编码如果不对，中文会变成乱码。Excel输入步骤一般能自动识别，但如果是CSV文件，就一定要手动选对编码，比如UTF-8或GBK。

3.3 清洗三件套：去空格、空值替换、类型转换

读取进来之后，原始数据依然带“脏”东西。我发现最常遇到的三个问题：空格、空值、错误类型。处理这三个问题，我一般加两到三个步骤搞定。

去空格用字符串操作（String Operations）步骤，把学号、姓名这类字段的“移除字符串空格”选项打开，Kettle内部会把首尾空格清掉。对班级名称，建议统一做一次值映射（Value Mapper），把“高一（1）班”这种全角括号写法映射成标准写法“高一(1)班”，虽然这步不是必须的，但可以让最终报表一致性更好。

空值和类型转换是关联在一起的，尤其是计算总分之前，必须保证三科成绩是数值类型。我的推荐组合是：先拖一个字段选择（Select Values）步骤，在“元数据”标签里把语文、数学、英语的“类型”改成Number、“格式”改成#.##，再把“空值替换”设置一下。但老实说，某些版本里字段选择对空值替换的支持不够直观，所以更稳妥的做法是下一个JavaScript代码步骤，用一段简单逻辑把空值统一补成0：

// 在JavaScript代码步骤的“字段”里定义输出字段 totalScore，类型Number function processRow() { var chinese = Number(chinese); var math = Number(math); var english = Number(english); if (isNaN(chinese)) chinese = 0; if (isNaN(math)) math = 0; if (isNaN(english)) english = 0; totalScore = chinese + math + english; return true; }

有人可能有疑问：缺考到底是算0，还是算NULL？这个先定义好。真实业务里“缺考”和“考了零分”含义不同，如果后续要统计及格率、优秀率，缺考和0分会被算进分母导致数据失真。所以正式项目里我习惯单独留一个“是否缺考”标记列，而不是简单把空值补0。但如果我们只需要总分排名，补0是一种快速处理方式，教务也能接受。

3.4 一个实用的清洗组合流程

综合上面的操作，开发时我的清洗流是这么串的：

Excel输入 -> 字符串操作（去空格） -> 值映射（班级名称标准化） -> 字段选择（设置字段类型） -> JavaScript代码（空值补0并计算总分） -> 后续排名逻辑

每一个步骤之间我都会点预览看数据，特别是做完类型转换之后，要确认语文成绩92.5不再是文本而是数值。你可以这样判断：预览时如果数字右上角没有文本格式标记，说明类型对了；如果排序时出现“10比9小”这种结果，八成就是按文本排序了，一定要回来看字段类型。这个检查点，几乎是我帮别人排查“排名结果不对”时第一个会问的问题。

4. 成绩排名怎么算：三种排名实现方案从简到繁

4.1 先算总分：计算器和公式二选一

总分是排名的基础，计算方式主要有两种：计算器（Calculator）步骤和公式（Formula）步骤。两者的差别在于，计算器更直观，适合三五个字段的加减乘除；公式支持复杂表达式，适合条件判断。我们这个场景用计算器就够了。

计算器步骤配置很简单：选择运算为A+B+C，分别指定A、B、C为语文、数学、英语，输出字段名totalScore，输出类型设为Number。这里有个细节：如果前面步骤还没把文本转成数值，计算器可能会把数字当字符串做拼接，得到92.58895这种明显不对的结果。所以再次强调，顺序一定是“先类型转换，再计算总分”。

如果你要额外处理“缺考按0分计算”，可以走前面的JavaScript代码步骤，直接在清洗阶段把总分算好。我习惯在JavaScript代码步骤里同步输出清洗后的三科成绩和总分，这样后面的排序、排名、输出都不用再关心外部的空值问题。

4.2 方案一：排序记录加增加序列，五分钟拿到流水号

最简单的“排名”，其实是拿到一个按总分从高到低排列的行号。实现方式就两个步骤：排序记录（Sort rows）和增加序列（Add sequence）。

排序记录里添加两个排序条件：第一是总分，方向选“降序”，这样最高分排在最前面；第二是学号，方向“升序”，作用是给同分考生一个稳定的先后顺序，避免数据库每次跑批结果顺序不一致。这里注意：排序字段如果是字符串类型，排序会按字典序走，结果可能不是你想要的数字大小顺序。所以排序之前再检查一次总分字段的类型。

增加序列步骤就简单了：起始值填1，增量填1，输出字段名row_no。跑到这里，流中的每一行都有了行号，最高分是1，第二高分是2。这不就是“按分数排名”吗？对，但还差一步：如果有两个98分，按这种方案他们会被排成1和2，而标准竞赛规则要求并列第1，让下一个97分的人排第3。所以方案一本质是ROW_NUMBER()，只适合不需要处理并列的榜单，比如学号清单、抽取名单、内部流水编号等。

4.3 方案二：分组取最小行号，不写一行代码

如果你不想写JavaScript，而且想实现“同分同名次、下一名次跳过”的标准竞赛排名，可以用分组（Group by）步骤完成，原理是：既然已经排好序了，同一个分数的人在排序流里是连续的一小段，那么这一小段的最小行号，就是他们共同的排名序号。

做法是：在排序记录和增加序列之后，拖一个分组步骤，分组字段选totalScore，聚合项目中添加一项，对row_no取最小值，输出字段命名为rank_no。运行之后，分组步骤会输出若干行，每行对应一个分数和它的rank_no。比如98分对应的最小行号是1，那么98分的所有人排名就是1；97分的最小行号是3，那么97分的人排名就是3。

但是这个方案有个麻烦点：分组之后会把明细字段全部丢掉，只剩总分和排名。所以如果想输出每个学生的姓名和排名，需要把分组结果再和原明细连接一次。具体做法是在分组步骤后面挂一个数据流查询（Stream Lookup）或者数据库查询，连接条件就是totalScore相等，把rank_no关联回来。

这个方案最大的好处是全程可视化、不写代码，适合Kettle新手理解“分组聚合”的概念。缺点是流程变长了，中间多了一步查询，当数据量大时内存占用也会增加。我的建议是：如果只做简单验证，方案二很好用；正式报表想看四个小时跑完不出错，我反而推荐下面的方案三。

4.4 方案三：JavaScript实现标准竞赛排名

这是我个人在生产环境里用得最多的方案。原理就是利用之前生成的明细顺序和行号row_no，再用JavaScript步骤保留“上一行总分”和“当前已发放的名次”，逐行扫描一遍就把前置排名算出来。

先看标准竞赛排名RANK()的实现：

// 在JavaScript代码步骤的“字段”页签里添加输出字段 rank，类型Integer var prevScore = null; var count = 0; var rank = 0; function processRow() { var currentScore = Number(totalScore); count++; // 当前行进过的总数，相当于全局行号 if (prevScore === null || currentScore !== prevScore) { rank = count; // 遇到新分数，名次等于当前已扫描的行数 prevScore = currentScore; } return true; }

仔细看逻辑：进入第一行时prevScore是null，触发条件，rank被赋值为count，也就是1；第二行如果分数相同，currentScore和prevScore相等，不进入if，rank仍是1；第三行分数变了，count已经是3，于是rank直接跳到3。这就是标准竞赛排名。

如果你要的是DENSE_RANK()，也就是并列后下一名不跳号，用下面这个版本：

// 输出字段 denseRank，类型Integer var prevScore = null; var denseRank = 0; function processRow() { var currentScore = Number(totalScore); if (prevScore === null || currentScore !== prevScore) { denseRank++; prevScore = currentScore; } return true; }

两个版本的核心差别就一句话：RANK用“已扫描行数”充当名次，DENSE_RANK用“已遇到的不同分数个数”充当名次。项目里要哪个，直接换函数体即可。

JavaScript步骤需要注意一个特别恶心的问题：一定要保证这个步骤是单线程执行。Kettle默认转换可以并行，如果上游步骤把数据分成了多个线程，这个“全局变量跨行累计”的逻辑就会乱，排名结果会随机飘。保险起见，我在JavaScript步骤前的排序记录阶段保持默认单线程，并且不在JavaScript步骤上勾选任何“改变执行方式”之类的并行选项。也就是说，这条链路让它老老实实一行一行过，最稳。

4.5 三个方案到底怎么选

我把三个方案放在一起对比，方便你按场景选择：

我自己的判断标准很简单：临时看看数据，用方案一；团队里有Kettle新手，方案二好理解；要交付长期运行的报表或者排名规则还要继续加码（比如先班级后年级排名），直接上方案三。实际跑下来，几万行成绩数据用方案三基本是秒级完成，不会有性能压力。

5. 结果输出与任务调度：Excel报表和入库自动化

5.1 输出到Excel：结果需要给教务老师看

排名算好了，输出环节不能拖后腿。教务老师根本不会去数据库看数据，他们要的就是一张能直接打印的Excel。这时用Excel输出（Microsoft Excel Output）步骤。

配置重点有几个：文件路径一定要提前规划好，比如/data/output/成绩排名_2024下半年.xlsx；输出字段在“字段”页签里添加，把需要的列按顺序排好：学号、姓名、班级、语文、数学、英语、总分、排名；然后勾选“启用Sheet页头”，这样第一行会生成表头。如果想把班级排名和年级排名分到两个Sheet，我一般是直接在转换里复制一套输出逻辑，用不同的Sheet名称。

这里有个小经验：Excel输出步骤默认输出的文件如果已经存在，会直接覆盖，但这个行为在某些版本里会弹提示，定时跑批时千万不能弹窗卡住。建议在作业里加一个删除文件步骤，每次跑之前先把旧的输出文件删掉，再执行Excel输出，避免版本差异导致的问题。

5.2 输出到数据库：表输出与驱动配置

数据最终要入库，方便教务系统或者大屏应用读取。输出到数据库用表输出（Table Output）步骤。连接数据库之前，先新建数据库连接，填写URL、用户名、密码，测试连接。常见的坑是MySQL驱动依赖：Kettle不内置JDBC驱动，你需要手动把mysql-connector-java-x.x.x.jar复制到Kettle的lib目录，然后重启Spoon，否则报ClassNotFoundException。如果你用的数据库是Oracle或者国产数据库，同样要找到对应版本驱动，这是老生常谈又永远有人踩的坑。

数据库表建议提前建好，推荐结构：

CREATE TABLE student_score_rank ( id INT AUTO_INCREMENT PRIMARY KEY, student_id VARCHAR(20), student_name VARCHAR(50), class_name VARCHAR(50), chinese DECIMAL(5,1), math DECIMAL(5,1), english DECIMAL(5,1), total_score DECIMAL(6,1), rank_no INT, rank_type VARCHAR(20), stat_date DATE, KEY idx_total (total_score) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

表输出步骤里，点击“获取字段”可以把输入流字段和表字段一一映射起来。提交大小建议设成1000左右，也就是每1000行批量提交一次，避免连接占用时间过长。关于“慌”这一点我要多说一句：很多人习惯先把结果导出成SQL文件，再手动打开Navicat导入SQL，其实Kettle这里已经一步到位了，转换直接往目标库写数据，根本不需要来回倒文件。就算同事坚持用Navicat查看最终表，你只要把stat_date字段传到报表查询条件里，他们打开看到的也是增量刷新后的干净数据。

5.3 作业调度：Job串联与定时运行

单个转换只能手动跑一次，要做到“每天自动算排名”，必须把转换装进作业（Job）。新建一个作业，从左边的“通用”分类里拖入Start，然后拖入转换（Transformation）步骤，选择已经保存好的.ktr文件，接着可以拖入删除文件步骤清理历史Excel，再拖入Shell步骤发通知或者执行额外命令。

为什么要用作业而不是直接在转换里加定时？因为转换更关注“一条数据链路怎么处理”，作业才承担“什么时候跑、跑完做什么、失败了怎么处理”的调度编排。一个典型的生产作业链路是：

Start -> 转换：成绩排名计算并输出Excel -> 转换：成绩排名写入数据库 -> 删除旧的备份文件并归档 -> 复制新的Excel到共享目录

定时执行就交给操作系统。Windows用计划任务，Linux用cron。如果你们已经有了调度平台，也可以让平台直接调pan.sh或kitchen.sh，把执行命令配进去即可。我见过不少团队把Kettle作业挂在定时任务里后就不管了，直到领导要看报表才发现前天就失败了。所以无论如何，作业里至少加一个失败日志输出，或者让Shell发一条告警消息，别默认“跑了就成功”。

6. 实战中躲不开的坑：Kettle常见问题与排查技巧实录

6.1 常见问题速查表

把我在这个项目里和以往项目中遇到的典型问题整理成一张速查表，建议截图留档：

6.2 排名结果总是不对的三个检查点

如果排名结果和手工算的对不上，我一般只查三个地方。

第一个是排序是否正确。排名是基于排序流的，排序本身错了，后面所有名次都是错。检查方法：临时在排序记录后面加一个字段选择输出，预览前20行，看最高分是否真的在第一行，并且看看是否是“数字大小”顺序而不是“字符串字典序”。

第二个是JavaScript步骤的全局变量是否被并行污染。如果你发现同分的学生名次每次跑都不一样，九成是并行问题。解决办法可以强制这个步骤用单线程，或者在前一步放一个阻塞直到步骤完成（Blocking Step）让流串行化。尽管会牺牲一点速度，但几百条成绩数据完全无所谓。

第三个是分组方案中关联字段是否正确。方案二用总分关联分组结果时，如果总分是浮点数，两个98分可能在字面上一样，但在内部存储里一个是98.0000001另一个是98，连接就会失败或者漏行。解决办法：把总分字段在类型转换时统一精度，或者直接保留到1位小数，别用长浮点。

6.3 数据量变大以后怎么办

上百个班、几千上万条成绩数据，在这个项目里其实不算大，但Kettle跑得慢的常见瓶颈仍然是“全放在内存里排序、全量写库”。我给的思路是：第一，合并同类数据，比如一个Excel输入步骤配置多个文件，而不是拖20个Excel输入步骤；第二，写库时拉大提交大小，1000到2000条一次；第三，如果中间清洗逻辑复杂，尽量用Kettle原生步骤，少用JavaScript逐行处理大字段；第四，排名计算前先过滤掉无效数据，比如学号为空的脏行，这样排序和JS步骤的行数会少很多。

6.4 让流程更稳的几个习惯

最后分享几个我养成的习惯，这些小习惯曾经帮我省掉很多麻烦。第一，所有转换和作业文件统一放在/data/etl/这样的固定目录，文件名带日期或版本号，避免覆盖；第二，日志输出目录固定下来，cron里定时清三个月前的日志；第三，改动流程之前，先复制一份.ktr出来，跑完对比结果，确认没破坏了再删旧版；第四，每次启用新流程时，先用一小部分数据预览验证，再切换到全量文件通配符，绝不拿几万条数据陪新人练手。

另外，资源库里建议把命名参数用起来。比如文件目录、目标表名、统计日期这些经常变的变量，定义成参数后，定时任务就可以通过命令行传参，不用为了改一个路径重新打开Spoon做调整。

最后再说两句实在话

做过几个类似的ETL项目之后，我的体会是：成绩排名这件事看起来很“小”，但它把数据导入、清洗、计算、输出、调度这一整套ETL的核心动作全包括了。能把这一条链路跑通，你换成订单数据、销量数据、评分数据，本质上都是同一套方法论。你甚至可以把排名规则原封不动迁移到“单机游戏销量榜”“软件评分榜”这些完全不同的业务场景里，代码和步骤都一样，换成各自的字段名而已。

还有一个很务实的小建议：别一上来就追求做一条无所不能的超级转换。你只需要先把一个班级的Excel跑通，确定清洗、排名、输出每一步数据都没毛病，再把文件名换成通配符，再套上定时Job。之前很多人折腾一整天最后连文件都没读出来，就是因为第一步就想解决所有问题，结果卡在某个乱码上无法推进。Kettle最舒服的用法，就是小步快跑，每一步都能看到预览，出了问题也知道去哪一步查。希望这套实战流程能帮你把手动排名的日子彻底结束。