一、问题背景
转换和作业是Kettle的两支利剑。其中,转换采用多线程并发运行架构,作业采用递归顺序执行架构。因此,在增加CPU、内存等硬件资源的情况下,Kettle转换只需修改配置,即可充分利用基础设施能力,提高执行效率。转换的这种垂直扩展能力,使其成为实现ETL功能的必备工具,也是性能优化的核心。
当然,性能优化是一个系统工程,不仅涉及工具本身的优化,更涉及到ETL工具之外的诸多因素。比如,ETL要读取数据库,那么目标DMBS的性能、SQL语句、网络等相关因素都影响到执行效率。Kettle的中文意思为水壶,意即通过这把“水壶”,把上游产生的“水”(数据)顺利输送到下游各部门。想要让整个输送过程实现效率最高,取决于三个因素:上游来水渠道、水壶的大小与数量、下游输水渠道。
本文在假设第一、第三个因素已经达到最优的前提下,讨论第二个因素如何优化。即在外部环境因素不变、内部转换不变时,如何定位到性能瓶颈步骤,并通过垂直扩展进行有针对性、实效性的优化。文章最后还简要介绍了自定义优化插件的编程思路。
二、工具局限
Kettle工具本身具备性能监测手段。设计阶段常用的Spoon工具中,转换执行之后,窗口底部执行结果中有一个步骤度量标签页(如下图1所示)。
图1
从步骤度量中,可以看到每个步骤的执行时间以及速度。在生产环境中,通过Pan或者Kitchen的执行日志,也能够看到读、写行数和速度。那么,是不是速度慢的步骤就是性能瓶颈?或者执行时间最长的就是卡的步骤呢?下面通过实例来分析。
图1中的转换,共包括42个步骤。在测试机器上,通过Spoon中调试执行共需3分4秒,各步骤的性能度量结果图2所示。
从图2中可以看出,执行时间长、执行速度慢的步骤都集中在黄色区域,即步骤C01~C15和D00~D07,每个步骤的执行时间大概是3分1秒。那么,性能瓶颈是否就在这些步骤中呢?
答案是非也!
通过目测Spoon调测窗口(详见图1中虚线框步骤)的运行状态,我们可以看到,C01前的步骤几乎都在5秒内完成,而C01后的步骤,由于都在等C01的输出,所以执行时间随之变长,执行速度几乎都在1条记录/秒。因此,本转换的性能瓶颈在步骤C01,跟其他步骤无关(当然这种目测方法不适合用于生产环境)。
图2
三、解决办法
1、原理探究
导致这种误判现象背后的原因究竟是什么呢?
图3
通过JDK工具JavaVirtualVM监测各线程执行状态,也可以证实这一点。图4为转换执行过程中的一个截图。可以看出,Kettle为每一个转换都至少启动了一个线程,线程的命名规则为:
转换名称 – 步骤名称
本例转换名称为KettleSample004,所以步骤C01所在线程名称就为“KettleSample004– C01”。图4中绿色部分代表线程处在工作状态,橙色部分代表等待执行状态。截图时刻(15:51:40至15:52:00),步骤C01一直处在工作状态,而C02~C15基本上都处在等待状态(只有C02存在小段工作时间)。
图4
因此,解决问题的关键在于,需要一个程序来统计步骤的实际工作时间,实际工作时间长的步骤,可以判定为转换性能瓶颈。图5为在另外一台测试机器上,运行同样转换得到的实际工作时间数据(去掉了一些时间非常短的步骤),左侧为各步骤实际工作时间表,右侧为时间数据散点图。由于C01实际工作时间与其他步骤相比悬殊太大,为了更容易分类,右侧下半部分绘制了排除C01时间数据之外的散点图。从图5中的数据可以明显看出转换的性能瓶颈步骤,也可以根据散点图按照各步骤执行时间分为几种不同类别,分类进行优化。
图5
2、手工解决办法
第一步:分组。
根据散点图的分析结果,我们可以按照实际工作时间的长短,将步骤分为5个组(如下表1所示)。实际工作时间在100-400毫秒之间的步骤归入#1组;实际工作时间在2100~6800毫秒之间的步骤归入#2组;实际工作时间在7800~12000毫秒之间的步骤归入#3组;实际工作时间最高的C01单独归入#4组;其他步骤归入#5组。
表1
第二步:定义命名参数。
在Spoon中双击转换,在转换属性对话框中添加4个命名参数,并设置默认值。表1中的其他步骤分组#5无需单独定义参数,因为这些步骤的复制数量可以保持默认值1不变。具体设置如图6所示。
图6
第三步:设置步骤。
根据表1的分组结果,设置每一个步骤的复制数量,以利用Kettle的垂直扩展能力。具体操作是在每一个步骤上点击右键,选择“改变开始复制的数量…”菜单,并按住Ctrl+Alt+空格键,在下拉框中选择对应分组的命名参数即可。注意,某些步骤可能不允许改变复制数量。如果这些步骤对性能调优非常重要,我们可以在步骤前加一个空操作步骤,再进行设置;如果不重要,忽略即可。配置后的结果如下图7所示:
图7
第四步:运行调优。
如果我们单纯把线程数量无限增大,由于创建线程、线程上下文切换等其他资源的消耗,可能带来执行速度不升反降。因此,不能简单地按照实际工作时间比例来调整复制数量。例如#4组的实际工作时间是#3组的40倍以上。按此比例,#3的值如果设置为8,那么#4的值应该设置为320,这显然不是一个合理的设置。所以在环境不变的情况下,如何得到最优的复制数量,是一个有挑战性的问题。本文仅讨论依据经验通过不同设置的实际执行效果,来找到局部最优解的方法。其他方法将在另外的文章中进行讨论。
通过Pan命令,可以设置不同的参数来执行同样的任务,通过整体运行时间,找到一个较好的参数组合。具体命令示例如下(Windows环境):
Pan.bat "/file:D:\KettleSample004.ktr" "/param:#2=1""/param:#3=1" "/param:#4=1"
在测试机器上,不同参数组合的执行结果如下表2所示:
表2
从4次实验的结果看,选择2,3,8,10的参数值组合,执行时间为16秒,得到局部最优解。
3、使用插件
比手工解决更快捷的方法是利用插件,收集各步骤的运行结果,并自动分组、定义各分组相关步骤的命名参数。特别是在步骤相对较多的情况下,可以极大提高工作效率。下面简要介绍插件的用法。
第一步:打开已经定义好的转换,在左侧核心对象树中选择Kettle博士分类下的复制优化步骤,拖动放到转换中的任意位置。
第二步:双击复制优化步骤,在弹出的对话框中选择清空所有复制,并点击确定。这样,转换中所有已经设置复制数量的信息都将清空,以确保获取真实的性能监测数据。如下图8所示。
图8
第三步:双击复制优化步骤,在弹出的对话框中输入分组的数量(默认是7个分组),勾选自动创建参数,并点击确定。如下图9所示。
图9
第四步:运行转换。可以在Spoon中或者生产环境命令行中执行。执行后,可以在日志中看到分组的结果、每一个步骤的实际工作时间等信息,并自动创建相关命名参数,设置到转换每一个相应的步骤中(如果在Spoon中运行,需要重新打开转换文件)。下图10为在Spoon中执行的结果分析信息,图11为自动创建的命名参数以及步骤设置结果。
图10
图11
四、插件编程要点
下面来介绍插件编程的主要代码,插件中基于实际工作时间进行聚类的算法不在本文讨论之列。读者可以参照其他数据挖掘文章,找到关于聚类的算法。
首先需要了解的背景知识是,Java线程包含6种状态(NEW RUNNABLE BLOCKED WAITING TIMED_WAITING TERMINATED),对于优化需求而言,只需统计Kettle转换步骤线程的RUNNABLE状态时间,然后排序输出即可。主要代码解释如下:
1、查找转换的所有步骤
publicList getSteps()
可以得到转换的所有步骤列表。列表中每个元素都是StepMetaDataCombi类的实例。而StepMetaDataCombi类有一个公有属性stepname代表步骤名称。
publicString getName()
可以得到转换名称。
如前所述,得到了转换名称和步骤名称,Kettle步骤执行线程的名称即可确定。
2、查找所有线程
查找所有线程的方法代码如下:
public Thread[] findAllThreads() {
if(topGroup == null) {
ThreadGroupgroup = Thread.currentThread().getThreadGroup();
topGroup= group;
while(group != null) {
topGroup= group;
group= group.getParent();
}
}
intestimatedSize = topGroup.activeCount() * 2;
Thread[]actualContainer = new Thread[estimatedSize];
intactualSize = topGroup.enumerate(actualContainer);
Thread[]threads = new Thread[actualSize];
System.arraycopy(actualContainer,0, threads, 0, actualSize);
returnthreads;
}
3、时间统计
启动一个后台线程,固定间隔时间查看各线程状态,如果为RUNNABLE状态,则累计时间。一直到转换执行完毕或者停止时,时间统计可以停止,排序输出统计结果后,线程运行结束。判断转换是否执行完毕,可以调用上述Trans类的isFinished方法;判断线程是否停止,可以调用其isStopped方法。
4、复制次数设置
添加命名参数,可以调用TransMeta类的addParameterDefinition方法。设置复制数量,可以调用StepMeta类的setCopiesString方法。
五、总结
本文介绍了通过对Kettle垂直扩展参数的优化,提高转换执行性能的方法。同时也把编程相关API要点逐一阐述。所有实际工作中的转换优化问题,均可参考。由于每一个转换步骤优化的方法不尽相同,所以未讨论单个步骤的优化问题。
注意:由于插件只在Kettle6~8版本上进行过验证,其他版本未经严格测试,使用前务必做好备份!
【注意】本公众号所发文章皆为原创,如转载请注明出处及作者。
领取专属 10元无门槛券
私享最新 技术干货