Impala SQL on Kudu优化(一)

  • Post author:
  • Post category:其他



一、Impala sql 的计算方式是啥?


在使用Impala进行SQL查询的时候,我们经常会使用join来关联多个表进行查询,获取想要的结果。对于表的数量达到千万甚至上亿的时候,不同的join方式所造成的执行速度,可能差距非常大。Impala提供了两种Join算法-shuffle和broadcast。




二、

主要Join方式




1.

broadcast join


适合大表与小表的join,将大表划分成多块,小表广播与这些块进行hash join。




2.

shuffler hash join


适合大表与大表的join,将两个大表都划分成多块,然后分别进行hash join,有点类似于mapreduce中的shuffle。

三、

实战案例


已知:ods_xxxxxxx 大表(一天几个亿),即a1表数据量大;dim_t_config 小表(几百条)即a2表数据量少。


预期:对a2进行broadcast ,防止对a1进行broadcast


代码:

SELECT  concat('20201111',a2.colv3) ds
        ,col1
        ,col2
        ,sum(col3) col3
        ,col4
FROM    (
            SELECT  substr(col_update_time, 12, 8) col_update_time
                    ,TYPE
                    ,col1
                    ,(
                        unix_timestamp(col_update_time)-unix_timestamp(lag((col1_update_time), 1) OVER(PARTITION BY col1 ORDER BY col_update_time ASC))
                    )/60 col3
                    ,CASE    WHEN col10 = 0 THEN 'kudu'
                             WHEN col10 = 1 THEN 'hive'
                             WHEN col10 = 2 THEN 'impala'
                             WHEN col10 = 3 THEN 'spark' 
                     END col3
                    ,col4
            FROM    ods_xxxxxxx
            WHERE   ds = '20201111'
        ) a1
JOIN    (
            SELECT  TYPE
                    ,colv1
                    ,colv2
                    ,colv3
            FROM    dim_t_config
            WHERE   ds = '20201112'
        ) a2
ON      a1.col_update_time >= a2.colv1
AND     a1.col_update_time <= a2.colv2
AND     a1.TYPE = a2.TYPE
GROUP BY a2.colv3
         ,col1
         ,col2
         ,col4;



实际运行时间:122秒

如下图所示:



实际运行执行计划如下: 对 a1表 进行了broadcast



如何使用Hint进行join控制?



代码:添加了如下所示两点 (




STRAIGHT_JOIN




)




和(




[broadcast]




)

SELECT  STRAIGHT_JOIN concat('20201111',a2.colv3) ds
        ,col1
        ,col2
        ,sum(col3) col3
        ,col4
FROM    (
            SELECT  substr(col_update_time, 12, 8) col_update_time
                    ,TYPE
                    ,col1
                    ,(
                        unix_timestamp(col_update_time)-unix_timestamp(lag((col1_update_time), 1) OVER(PARTITION BY col1 ORDER BY col_update_time ASC))
                    )/60 col3
                    ,CASE    WHEN col10 = 0 THEN 'kudu'
                             WHEN col10 = 1 THEN 'hive'
                             WHEN col10 = 2 THEN 'impala'
                             WHEN col10 = 3 THEN 'spark' 
                     END col3
                    ,col4
            FROM    ods_xxxxxxx
            WHERE   ds = '20201111'
        ) a1
JOIN  [broadcast]  (
            SELECT  TYPE
                    ,colv1
                    ,colv2
                    ,colv3
            FROM    dim_t_config
            WHERE   ds = '20201112'
        ) a2
ON      a1.col_update_time >= a2.colv1
AND     a1.col_update_time <= a2.colv2
AND     a1.TYPE = a2.TYPE
GROUP BY a2.colv3
         ,col1
         ,col2
         ,col4;



实际运行时间:24.9秒



执行计划:对小表a2进行了broadcast,大表a1避免了broadcast





总结




通过以上测试,看出,选择合适的join方式,性能提升了5倍,平时工作中需要多看执行计划。





下一篇,将针对Kudu分区表进行讲解。欢迎关注




Impala SQL on Kudu优化(二)_一个数据小开发的博客-CSDN博客









版权声明:本文为Aaron_ch原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。