Kettle Table Exists控件优化

一、背景

本文是kettle优化的系列文章中的其中一篇。最近在分析一些跑的比较慢的Job，发现一个很诡异的现象：同一个Table Exists控件，有的跑的很快、有的很慢，最慢的甚至30分钟左右。经过进一步分析，了解到在判断hive数据库时，当表的数据量很大或视图的查询逻辑非常复杂，控件调用就会变得非常耗时。初步想法是控件在运行时，可能是数据库连接或查询数据的TEST SQL有问题，导致对大量数据表的判断没有进行优化。为了验证这一想法并进行彻底的优化，只能通过看源代码实现方式。

二、准备工作

1、下载Kettle源码
从githup上下载kettle代码并checkout到和自己kettle版本对应的分支上：

git clone [email protected]:pentaho/pentaho-kettle.git 
git checkout 6.1.0.1-R

2、下载big-data-plugin源码，big-data-plugin是kettle大数据相关的组件

git clone [email protected]:pentaho/big-data-plugin.git
git checkout 6.1.0.1-R

3、前两步下载的项目导入到Eclipse

三、代码分析

Table Exists控件的实现类是 pentaho-kettle项目中的JobEntryTableExists，运行时执行execute方法，该方法首先获得Database对象、数据库连接，然后调用Database的checkTableExists方法，该方法就是用来判断数据库中是否存在指定的表。
checkTableExists根据实际的数据库实例，设置特定数据库的SQL，然后执行该sql，基于执行结果判断表是否存在，如果表不存在会异常。
Mysql执行的sql：
Oracle执行的sql：
可以看到不同的数据库，查询sql是不一样的，这就可以根据数据库的特点，以最快的效率返回查询结果。
Hive使用的是默认的Sql：
hive中执行上面的查询sql时，如果表或视图的数据量比较大，就会起MR任务，启动和销毁MR任务都会浪费时间，这就导致了查询比较慢。

四、代码优化

经过上面的分析，已经能定位到问题，解决方案也很简单，针对hive数据库实现特定的getSQLTableExists方法，最大化利用hive特性、以最优方式查询数据。
在pentaho-big-data-legacy项目的Hive2DatabaseMeta类增加以下代码：
编译big-data-plugin项目下的legacy模块，编译后的jar包放到$KETTLE_HOME/plugins/pentaho-big-data-plugin目录下

五、总结

遇到问题首先要分析详细的Log，找到问题，根据以往经验了解大致原因，然后为了进一步找到问题根源，最好仔细看源代码、然后优化