Hive会将执行的SQL语句翻译成对应MapReduce任务，当SQL语句比较简单时，性能还是可能处于可接受的范围。但是如果涉及到非常复杂的业务逻辑，特别是通过程序的方式（一些模版语言生成）生成大量判断语句时，出现的问题就会比较多。

 

精简Hive使用的SQL

 

当前项目中如果打包的数量过多，是当前性能的最大瓶颈，在做SQL优化时，至少会存在一个这样的SQL，当打包数量上百甚至到1千后，就会产生大量的 IF/OR 语句：

IF((( true == true  AND caid==2002158 AND rcode IN (12) AND spid IN('6rO6w') AND (dateid >= 20141225 AND dateid <= 20141227)) ),'PACKAGE_0','') PACKAGE_0,IF((( true == true  AND caid==2002158 AND rcode IN (20) AND spid IN('6rO6x') AND (dateid >= 20141225 AND dateid <= 20141227)) ),'PACKAGE_1','') PACKAGE_1,IF((( true == true  AND caid==2002158 AND rcode IN (124) AND spid IN('6rO6y') AND (dateid >= 20141225 AND dateid <= 20141227)) ),'PACKAGE_2','') PACKAGE_2,IF((( true == true  AND caid==2002158 AND rcode IN (33) AND spid IN('6rO6z') AND (dateid >= 20141225 AND dateid <= 20141227)) ),'PACKAGE_3','') PACKAGE_3,IF((( true == true  AND caid==2002158 AND rcode IN (126) AND spid IN('6rO70') AND (dateid >= 20141225 AND dateid <= 20141227)) ),'PACKAGE_4','') PACKAGE_4,

 

此时，执行的效率会非常低，目测在过千万级的日志量时，往往会执行天数据量级的耗时。在当前Reducer阶段中执行时的堆栈：

 

通过定时的取样，发现在Map过程中大部分的时间消耗在这种If/Or调用。

 

最终考虑将其优化成一个UDF，这样SQL就可以不用重写成多个了，经过测试发现优化效果非常好，同时只需指定两个外部文件即可。

 

 

split_package(caid, rcode, spid, dateid, "./524_1_1", "./Region-000000000000000000000008-top100") package_list

 

 

此时，应该在SQL中事先将其通过ADD FILE的方式加入资源，才能正常使用：

 

ADD FILE ./Region-000000000000000000000008-top100;ADD FILE ./524_1_1;

 

我们通过这种方式，成功地将SQL语句缩短，并将执行时间由原来的1天缩减至5小时内，解决了当前发现的最大瓶颈。

 

对于其他可能导致SQL过长的问题，同样都采用该方式统一解决。

 

此外，由于数据中的每一行中都会调用到UDF，因此对于UDF函数中算法的一小步改进，都能够对整体效率起到很大的提升。

 

此外，Hive在提交任务时，会启动一个本地的JVM来对当前执行的SQL进行解析，如果SQL的长度过长时，也是一个非常耗时的过程。比如一个非常极端的例子，在我们的服务器上，有一次执行了2w行的SQL，解析时间居然消耗了50分钟左右！因此，减少SQL行数是必须可少的步骤，同时也需要保证提交任务的服务器有一定的资源，否则在提交任务时过于耗时。

 

上个步骤只不过是优化的第一个步骤，后续会继续针对性能问题进行进一步的优化，因为我们当前的系统距离产品的要求还是有一定的差距的，优化无止境……