hive語句如何優化

小編給大家分享一下hive語句如何優化，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

傾斜分成group by造成的傾斜和join造成的傾斜

?
假設網站訪問日志中會記錄用戶的user_id，并且對于注冊用戶使用其用戶表的user_id，對于非注冊用戶使用一個user_id=0代表。那么鑒于大多數用戶是非注冊用戶（只看不寫），所以user_id=0占據了絕大多數。而如果進行計算的時候如果以user_id作為group by的維度或者是join key，那么個別Reduce會收到比其他Reduce多得多的數據——因為它要接收所有user_id=0的記錄進行處理，使得其處理效果會非常差，其他Reduce都跑完很久了它還在運行。

1.group by造成的傾斜

group by造成的傾斜有兩個參數可以解決：

• map 一個是Hive.Map.aggr，默認值已經為true，意思是會做Map端的combiner。所以如果你的group by查詢只是做count(*)的話，其實是看不出傾斜效果的，但是如果你做的是count(distinct)，那么還是會看出一點傾斜效果。

• reduce 另一個參數是Hive.groupby. skewindata。這個參數的意思是做Reduce操作的時候，拿到的key并不是所有相同值給同一個Reduce，而是隨機分發，然后Reduce做聚合，做完之后再做一輪MR，拿前面聚合過的數據再算結果。

set Hive.optimize.skewjoin = true; 
還有要告訴Hive如何判斷特殊值，根據Hive.skewjoin.key設置的數量Hive可以知道，比如默認值是100000，那么超過100000條記錄的值就是特殊值。

?

所以這個參數其實跟Hive.Map.aggr做的是類似的事情，只是拿到Reduce端來做，而且要額外啟動一輪Job，所以其實不怎么推薦用，效果不明顯。

優化思路是： 先替從后統計

/*改寫前*/
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)是按group by 字段分組，按distinct字段排序，一般這種分布方式是很傾斜的

2.join造成的傾斜

join造成的傾斜，就比如上面描述的網站訪問日志和用戶表兩個表join：

select a.* from logs a join users b on a.user_id = b.user_id;

1.傾斜的單獨處理

另外對于特殊值的處理往往跟業務有關系，所以也可以從業務角度重寫sql解決。比如前面這種傾斜join，可以把特殊值隔離開來（從業務角度說，users表應該不存在user_id = 0的情況，但是這里還是假設有這個值，使得這個寫法更加具有通用性）：

select a.* from 
(
select a.*
from (select * from logs where user_id = 0)  a 
join (select * from users where user_id = 0) b 
on a.user_id =  b.user_id
union all
select a.* 
from logs a join users b
on a。user_id <> 0 and a。user_id = b.user_id
)t;

2.傾斜的隨機化處理

Select *
from log a
left outer join bmw_users b
on case when a.user_id is null then concat(‘dp_hive’,rand() ) else a.user_id end = b.user_id;

3.字符類型的hash傾斜處理

統一hash規則，int和string的區別？
本質上：
h(1) 和h('1') ，本質上分配到partition上沒有什么區別，根本就解決不了數據傾斜的問題。

區別在于：
h(10)可能與h(1)產生hash碰撞，因為hash值可能一樣，導致進一步的數據傾斜
而：
h('10') h('1') ，本質上hash不一樣；但是如果partition數量較小，可能導致分配到同一個partition里面

HashPartitioner是mapreduce的默認partitioner。
計算方法是
which reducer=(key.hashCode() & Integer.MAX_VALUE) % numReduceTasks

所以下面問題二的優化思路就是這個意思：

問題2：不同數據類型id的關聯會產生數據傾斜問題。
一張表s8的日志，每個商品一條記錄，要和商品表關聯。但關聯卻碰到傾斜的問題。s8的日志中有字符串商品id,也有數字的商品id,類型是string的，但商品中的數字id是bigint的。猜測問題的原因是把s8的商品id轉成數字id做hash來分配reduce，所以字符串id的s8日志，都到一個reduce上了，解決的方法驗證了這個猜測。
方法：把數字類型轉換成字符串類型
Select * from s8_log a
Left outer join r_auction_auctions b
On a.auction_id = cast(b.auction_id as string);
 

以上是“hive語句如何優化”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！