數(shù)據(jù)傾斜的解決方案

數(shù)據(jù)傾斜的解決方案2學(xué)習(xí)任務(wù)了解設(shè)置參數(shù)解決數(shù)據(jù)傾斜了解sql語句優(yōu)化解決數(shù)據(jù)傾斜3知識目標(biāo)設(shè)置參數(shù)解決數(shù)據(jù)傾斜sql語句優(yōu)化解決數(shù)據(jù)傾斜01能力目標(biāo)掌握設(shè)置參數(shù)解決數(shù)據(jù)傾斜理解sql語句優(yōu)化解決數(shù)據(jù)傾斜02學(xué)習(xí)目標(biāo)4目錄01Groupby傾斜解決方案02Join傾斜解決方案5Groupby傾斜解決方案開啟map端部分聚合功能，就是將key相同的歸到一起，減少數(shù)據(jù)量，這樣就可以相對地減少進(jìn)入reduce的數(shù)據(jù)量，在一定程度上可以提高性能。設(shè)置hive.map.aggr=true6Groupby傾斜解決方案如果發(fā)生了數(shù)據(jù)傾斜就可以通過它來進(jìn)行負(fù)載均衡。當(dāng)選項設(shè)定為true，生成的查詢計劃會有兩個MRJob。第一個MRJob中，Map的輸出結(jié)果集合會隨機(jī)分布到Reduce中，每個Reduce做部分聚合操作，并輸出結(jié)果，這樣處理的結(jié)果是相同的Key有可能被分發(fā)到不同的Reduce中，從而達(dá)到負(fù)載均衡的目的；第二個MRJob再根據(jù)預(yù)處理的數(shù)據(jù)結(jié)果按照Key分布到Reduce中最后完成最終的聚合操作。設(shè)置hive.groupby.skewindata=true7Groupby傾斜解決方案countdistinct操作往往需要改寫SQL，改寫SQL語句前后差別很大，如下是修改前的SQL語句groupby查詢：countdistinct改寫修改過后，取出distinct關(guān)鍵字，采用子查詢的方式提高查詢速度，修改過的SQL語句如下：selecta,count(distinctb)ascfromtblgroupbya;selecta,count(*)ascfrom(selecta,bfromtblgroupbya,b)groupbya;8Join傾斜解決方案join造成的傾斜，常見情況是不能做map。join的兩個表，其中一個是行為表，另一個是屬性表。比如我們有三個表，一個用戶屬性表users，一個商品屬性表items，還有一個用戶對商品的操作行為表日志表logs。假設(shè)現(xiàn)在需要將行為表關(guān)聯(lián)用戶表。命令如下所示：設(shè)置skewjoin參數(shù)select*fromlogsajoinusersbona.user_id=b.user_id;其中l(wèi)ogs表里面會有一個特殊用戶user_id=0，代表未登錄用戶，假如這種用戶占了相當(dāng)?shù)谋壤?，那么個別reduce會收到比其他reduce多得多的數(shù)據(jù)。9Join傾斜解決方案因為要接收所有user_id=0的記錄進(jìn)行處理，使得其處理效果會非常差。hive給出的解決方案叫skewjoin，其原理把這種user_id=0的特殊值先不在reduce端計算掉，而是先寫入hdfs，然后啟動一輪mapjoin專門做這個特殊值的計算，期望能提高計算這部分值的處理速度。當(dāng)然你要告訴hive這個join是個skewjoin，即：設(shè)置skewjoin參數(shù)hive.optimize.skewjoin=true;10Join傾斜解決方案針對join傾斜的問題，一般都是通過改寫sql解決。對于上面這個問題，我們已經(jīng)知道user_id=0是一個特殊key，那么可以把特殊值隔離開來單獨做join，這樣特殊值肯定會轉(zhuǎn)化成mapjoin，非特殊值就是沒有傾斜的普通join了，命令如下：特殊值分開處理法select*from(select*fromlogswhereuser_id=0)ajoin(select*fromuserswhereuser_id=0)bona.user_id=b.user_idunionallselect*fromlogsajoinusersbona.user_id<>0anda.user_id=b.user_id;11Join傾斜解決方案上面這種個別key傾斜的情況只是一種傾斜情況。最常見的傾斜是因為數(shù)據(jù)分布本身就具有長尾性質(zhì)，比如我們將日志表和商品表關(guān)聯(lián)：隨機(jī)數(shù)分配法select*fromlogsajoinitemsbona.item_id=b.item_id;這個時候分配到熱門商品的reducer就會很慢，因為熱門商品的行為日志肯定是最多的，而且我們也很難像上面處理特殊user那樣去處理item。為了解決這個問題會用到加隨機(jī)數(shù)方法，就是在join的時候增加一個隨機(jī)數(shù)，隨機(jī)數(shù)的取值范圍n相當(dāng)于將item給分散到n個reducer，命令如下所示：12Join傾斜解決方案上面的寫法里，對行為表的每條記錄生成一個1-10的隨機(jī)整數(shù)，對于item屬性表，每個item生成10條記錄，隨機(jī)key分別也是1-10，這樣就能保證行為表關(guān)聯(lián)上屬性表。這個做法是一個解決join傾斜比較根本性的通用思路，就是如何用隨機(jī)數(shù)將key進(jìn)行分散。隨機(jī)數(shù)分配法selecta.*,b.*from(select*,cast(rand()*10asint)asr_idfromlogs)ajoin(select*,r_idfromitemslateralviewexplode(range_list(1,10))rlasr_id)bona.item_id=b.item_idanda.r_id=b.r_id查詢命令如下：13Join傾斜解決方案最后一種是因為業(yè)務(wù)設(shè)計導(dǎo)致的問題，也就是說即使行為日志里面joinkey的數(shù)據(jù)分布本身并不明顯傾斜，但是業(yè)務(wù)設(shè)計導(dǎo)致其傾斜。比如對于商品item_id的編碼，除了本身的id序列，還人為的把item的類型也作為編碼放在最后兩位，這樣如果類型1（電子產(chǎn)品）的編碼是00，類型2（家居產(chǎn)品）的編碼是01，并且類型1是主要商品類，將會造成以00為結(jié)尾的商品整體傾斜。這時，如果reduce的數(shù)量恰好是100的整數(shù)倍，