Hive0.14在left outer join多级连接中，执行计划生成BUG记录

前言：

        这几天遇到一个很诡异的问题，一个三级left outer join的句子，在hive0.9和0.14上的执行结果会不一样。

        而且在0.14上通过转换右表连接的顺序可以达到正确输出的目的，但是其中是为什么却不得而知，情况非常

        诡异，猜测是编译器编译执行计划有问题！（所谓转换右表连接顺序是指把A left outer join B left outer join C

        改成A left outer join C left outer join B,出问题的在B子句中有个聚合出的结果在最终结果中表现不对。）

下面详细介绍下问题：

                      原语句：

select  A.state_date,             A.customer,             A.channel_2,             A.id,             A.pid,             A.type,             A.pv,             A.uv,             A.visits,             if (C.stay_visits is  null , 0 ,C.stay_visits) as stay_visits,             A.stay_time,             if (B.bounce is  null , 0 ,B.bounce) as bounce   from       (select a.state_date,              a.customer,              b.url as channel_2,              b.id,              b.pid,              b.type,              count( 1 ) as pv,              count(distinct a.gid) uv,              count(distinct a.session_id) as visits,              sum(a.stay_time) as stay_time         from                       ( select state_date,                             customer,                             gid,                             session_id,                             ep,                             stay_time                      from bdi_fact.mid_pageview_dt0                      where l_date = '$v_date'                    )a                    join                    (select l_date as state_date ,                            url,                            id,                            pid,                            type,                            cid                     from bdi_fact.frequency_channel                     where l_date = '$v_date'                     and type = '2'                     and dr= '0'                    )b                     on  a.customer=b.cid                      where a.ep  rlike b.url                     group by a.state_date, a.customer, b.url,b.id,b.pid,b.type         )A              left outer join         (   select                     c.state_date ,                     c.customer ,                     d.url as channel_2,                     d.id,                     sum(pagedepth) as bounce              from                    ( select                                t1.state_date ,                                t1.customer ,                                t1.session_id,                                t1.ep,                                t2.pagedepth                      from                                     ( select                                       state_date ,                                       customer ,                                       session_id,                                       exit_url as ep                            from ods.mid_session_enter_exit_dt0                            where l_date = '$v_date'                            )t1                           join                            ( select                                      state_date ,                                      customer ,                                      session_id,                                      pagedepth                              from ods.mid_session_action_dt0                              where l_date = '$v_date'                              and  pagedepth= '1'                            )t2                           on t1.customer=t2.customer                           and t1.session_id=t2.session_id                     )c                     join                     (select *                     from bdi_fact.frequency_channel                     where l_date = '$v_date'                     and type = '2'                     and dr= '0'                     )d                     on c.customer=d.cid                     where c.ep  rlike d.url                     group by  c.state_date,c.customer,d.url,d.id               )B               on           A.customer=B.customer               and A.channel_2=B.channel_2               and A.id=B.id        left outer join       (               select e.state_date,              e.customer,              f.url as channel_2,              f.id,              f.pid,              f.type,              count(distinct e.session_id) as stay_visits         from                       ( select state_date,                             customer,                             gid,                             session_id,                             ep,                             stay_time                      from bdi_fact.mid_pageview_dt0                      where l_date = '$v_date'                    )e                    join                    (select l_date as state_date,                            url,                            id,                            pid,                            type,                            cid                     from bdi_fact.frequency_channel                     where l_date = '$v_date'                     and type = '2'                     and dr= '0'                    )f                     on  e.customer=f.cid                      where e.ep  rlike f.url                     and e.stay_time is not  null                     and e.stay_time <> '0'                     group by e.state_date, e.customer, f.url,f.id,f.pid,f.type             )C      on          A.customer=C.customer          and   A.channel_2=C.channel_2          and   A.id=C.id          and   A.pid=C.pid          and   A.type=C.type   where A.customer= 'Cdianyingwang'  and A.channel_2= 'http://www.1905.com/film/filmnews/jk/'  and A.id= '127' ;"

                  在B子句中算出的结果B.bounce在最终结果中会显示错误（如正确结果是500，但是却显示是100）

                  但是，通过调整连接顺序后就很正常了。

 

                  打印执行计划出来看：

                                  

 

                可以很明显的看见同一个阶段有一个字段没有输出出来，这个阶段就是B子句的任务。而这个字段就是B.bounce。

                这应该就能解释为什么最后结果是不对的

                好了，既然知道问题在哪儿了，就来看源码吧！

                通过查找ExprNodeColumnDesc.java（负责解析并生成输出字段）类，有以下发现：

                

                （图中箭头所指是我修改后的代码：

                                               原代码是：if (tabAlias != null && dest.tabAlias != null && !tabAlias.equals(dest.tabAlias)){

                                                                                                   return false;
                                                                }）

                解析器在判断是否输出字段时，会判断当前字段是否跟最终表的字段相同（在查询中有很多中间表，如多级连接中）：

                                （以下所说的表都是指表别名）

                                 如果中间表和最终表都不为空且当前表不是最终表的话，返回false。即当前字段跟最终字段不同，需要输出。

                                 但是有个漏洞，就是当最终表为null的时候，这个时候如果是原代码的话，会返回true，字段会被直接丢弃

                                 因为返回true的话编译器判断最终结果中已有这个字段不需要输出。

                                 但是想想，如果最终表的别名为null，当前表的字段应该输出才对啊！不然数据的去处没了，源头也会没了。

                                 仔细想想这应该也是一个写代码时粗心犯下的一个错误吧！（在left outer join多级连接中有可能目标表的别名会为空）

 

               通过修改以上代码并编译后在集群上测试，执行计划输出正常了，数据结果也正常了：

                      图为patch前的结果（最后一列为B.bounce）：

                      

                      图为patch后的结果：