Impala SQL on Kudu優化（一）

一、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倍，平時工作中需要多看執行計劃。