Hive數據傾斜的原因及優化方法

這篇文章主要講解了“Hive數據傾斜的原因及優化方法”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Hive數據傾斜的原因及優化方法”吧！

數據傾斜成因：由于數據分布不均勻，造成數據大量的集中到一點，造成數據熱點。具體為某一個reduce接收到的數據是其他reduce的n倍，導致明顯的木桶效應。

癥狀：

1，對表做select count(1) from tb group by key，看表中是否有大量相同的key。

2，查看監控界面，任務進度長時間維持在99%（或100%），只有少量（1個或幾個）reduce子任務未完成或某幾個reduce子任務是平均reduce時長的n倍；

上圖的其中的一個job的reduce時間遠遠超出其他reduce時長，表明該reduce處理的數據遠超出其他的reduce，可見此次統計發生數據傾斜。

解決方案

參數調優：

1，set hive.groupby.skewindata=true：這個參數的意思是做Reduce操作的時候，拿到的key并不是所有相同值給同一個Reduce，而是隨機分發，然后Reduce做聚合，做完之后再做一輪MR，拿前面聚合過的數據再算結果。所以這個參數其實跟Hive.Map.aggr做的是類似的事情，只是拿到Reduce端來做，而且要額外啟動一輪Job，所以其實不怎么推薦用，效果不明顯。

2，set hive.skewjoin.key=100000：這個是join的鍵對應的記錄條數超過這個值則會進行優化。

3，set mapred.reduce.tasks=500：增加Reducer個數，通常數據(KV數值對）Shuffle到某個Reducer是根據Key進行Hash然后對Reducer個數進行取模。

HQL語句優化：

1，小表join大表：

將小表放在join左邊，減少oom的幾率；

使用mapjoin，小表數據最好在1000條以內。select /*+mapjoin(a)*/ count(1) from tb_a a left outer join tb_b b on a.uid=b.uid；

2，大表join大表：

把空值的key變成一個字符串加上隨機數，把傾斜的數據分到不同的reduce上，由于null值關聯不上，處理后并不影響最終結果。

select * from tb_a a left outer join tb_b b on (case when a.userid is null then concact('xxx', rand()) else a.userid end = b.userid);

3，不同數據類型關聯產生數據傾斜，在join之前先轉換數據類型：

select * from users a left outer join logs b on a.usr_id = cast(b.user_id as string);

4，count distinct優化

采用sum() group by的方式來替換count(distinct )進行計算

原語句：select a， count(distinct b) as c from tbl group by a;

改寫后：select a， count(*) as c from (select distinct a， b from tbl) group by a;

另外，count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最后結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union。

感謝各位的閱讀，以上就是“Hive數據傾斜的原因及優化方法”的內容了，經過本文的學習后，相信大家對Hive數據傾斜的原因及優化方法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！