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

10年積累的做網(wǎng)站、網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先做網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有婁底免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

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

?
假設(shè)網(wǎng)站訪問(wèn)日志中會(huì)記錄用戶的user_id，并且對(duì)于注冊(cè)用戶使用其用戶表的user_id，對(duì)于非注冊(cè)用戶使用一個(gè)user_id=0代表。那么鑒于大多數(shù)用戶是非注冊(cè)用戶（只看不寫），所以u(píng)ser_id=0占據(jù)了絕大多數(shù)。而如果進(jìn)行計(jì)算的時(shí)候如果以u(píng)ser_id作為group by的維度或者是join key，那么個(gè)別Reduce會(huì)收到比其他Reduce多得多的數(shù)據(jù)——因?yàn)樗邮账衭ser_id=0的記錄進(jìn)行處理，使得其處理效果會(huì)非常差，其他Reduce都跑完很久了它還在運(yùn)行。

1.group by造成的傾斜

group by造成的傾斜有兩個(gè)參數(shù)可以解決：

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

• reduce 另一個(gè)參數(shù)是Hive.groupby. skewindata。這個(gè)參數(shù)的意思是做Reduce操作的時(shí)候，拿到的key并不是所有相同值給同一個(gè)Reduce，而是隨機(jī)分發(fā)，然后Reduce做聚合，做完之后再做一輪MR，拿前面聚合過(guò)的數(shù)據(jù)再算結(jié)果。

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

?

所以這個(gè)參數(shù)其實(shí)跟Hive.Map.aggr做的是類似的事情，只是拿到Reduce端來(lái)做，而且要額外啟動(dòng)一輪Job，所以其實(shí)不怎么推薦用，效果不明顯。

優(yōu)化思路是： 先替從后統(tǒng)計(jì)

/*改寫前*/
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 ),在數(shù)據(jù)量大的情況下，效率較低，因?yàn)閏ount(distinct)是按group by 字段分組，按distinct字段排序，一般這種分布方式是很傾斜的

2.join造成的傾斜

join造成的傾斜，就比如上面描述的網(wǎng)站訪問(wèn)日志和用戶表兩個(gè)表join：

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

1.傾斜的單獨(dú)處理

另外對(duì)于特殊值的處理往往跟業(yè)務(wù)有關(guān)系，所以也可以從業(yè)務(wù)角度重寫sql解決。比如前面這種傾斜join，可以把特殊值隔離開來(lái)（從業(yè)務(wù)角度說(shuō)，users表應(yīng)該不存在user_id = 0的情況，但是這里還是假設(shè)有這個(gè)值，使得這個(gè)寫法更加具有通用性）：

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.傾斜的隨機(jī)化處理

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傾斜處理

統(tǒng)一hash規(guī)則，int和string的區(qū)別？
本質(zhì)上：
h(1) 和h('1') ，本質(zhì)上分配到partition上沒(méi)有什么區(qū)別，根本就解決不了數(shù)據(jù)傾斜的問(wèn)題。

區(qū)別在于：
h(10)可能與h(1)產(chǎn)生hash碰撞，因?yàn)閔ash值可能一樣，導(dǎo)致進(jìn)一步的數(shù)據(jù)傾斜
而：
h('10') h('1') ，本質(zhì)上hash不一樣；但是如果partition數(shù)量較小，可能導(dǎo)致分配到同一個(gè)partition里面

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

所以下面問(wèn)題二的優(yōu)化思路就是這個(gè)意思：

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

以上是“hive語(yǔ)句如何優(yōu)化”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！