hive優化總結

1、表設計

    合理分表

    合理設計表分區，靜態分區、動態分區

2、掃描相關

    一、謂詞下推（Predicate Push Down）

    二、列裁剪（Column Pruning）

        在讀數據的時候，只關心感興趣的列，而忽略其餘列

        對於查詢：select a,b from src where e < 10

        其中，src包含5個列(a、b、c、d、e)，列c、d將會被忽略，只會讀取a,b,e列

        選項默認爲真，hive.optimize.cp=true

    三、分區剪裁（Partition Pruning）

        在查詢的過程當中減小沒必要要的分區

        對於下列查詢：select * from t1 join (select * from t2) subq on (t1.c1 = subq.c2) where subq.prtn =100;

        會在子查詢中就考慮subq.prtn =100條件，從而減小讀入的分區數目

        選項默認爲真，hive.optimize.pruner=true

3、關聯JOIN相關

    一、JOIN操做左邊爲小表

        應該將條目少的表/子查詢放在Join操做符的左邊。

        緣由是在Join操做的Reduce階段，位於Join操做符左邊的表的內容會被加載到內存，將條目少的表放在左邊能夠有效減小OOM（內存溢出）的概率

        原理就是關係數據庫中驅動表與被驅動表

        若是是mapjoin，能夠放在右邊

    二、JOIN啓動的job個數

        若是join的key相同，無論有多少個表，都會合併爲一個Map-Reduce

        一個Map-Reduce(Tez)任務，而不是‘n’個

        在作outer join的時候也是同樣

        insert over write table pv_users select pv.pageid,u.age from page_view pv join user u on (pv.userid=u.userid) join newuser x on (u.userid = x.userid)

    三、MapJoin

        join操做在map階段完成，再也不須要reduce，前提條件是須要的數據在map的過程能夠訪問到

        新版本,Hint已經去了，這裏只是演示，應該儘量使用mapjoin

        不會傾斜，默認64M來併發處理數據

        對錶的大小有限制，一般來說大於100M，就作不了了

        insert over write table pv_users select /*+MAPJOIN(pv)*/pv.pageid,u.age from page_view pv join user u on (pv.userid=u.userid);

 

        須要設置的相關數據hive.join.emit.inter-1,hive.mapjoin.size.key,hive.map-join.cache.numrows。

    四、join不支持不等值鏈接

        !=、<>、>、<在join的on條件中不支持

        select ……from ……

        join ……

        on (a.key!=b.key)

        由於若是用不等值號的話，它會查其餘節點上的數據，那麼其餘查不到的，mapreduce是不支持這樣的機制，因此hive是不支持不等值鏈接的

4、分組Group By相關

    一、Skew In Data

        主要關注的是數據傾斜

        hive.groupby.skewindata = true

        當選項設定爲true，生成的查詢計劃會有兩個MR Job。第一個MR Job中，Map的輸出結果集合會隨機分佈到Reduce中，每一個Reduce作部分聚合操做，並輸出結果，這樣處理的結果是相同的Group By Key有可能被分發到不一樣的Reduce中，從而達到負載均衡的目的

        第二個MR Job再根據預處理的數據結果按照Group By Key分佈  到Reduce中（這個過程能夠保證相同的Group By Key被分佈到一個Reduce中），最後完成最終的聚合操做

 

        無法經過部分值推導出最終值的，如中位數和衆數

5、合併小文件

    合併功能會增長任務運行時間

    合併操做的性能很大程度上取決與「單個reduce端輸出文件大小」。Reduce端的輸出越大，耗時越長

    合併操做會對每一個Hive任務增長一次MapRedce任務

    緣由：

        Hive在處理時，Client會從MetaStore中把文件的名字讀到內存中，小文件過多會致使在SQL解析過程當中，可能就根本就解析不出來

 

    經過合併Map和Reduce的結果文件來消除小文件影響。須要設定的參數：

    hive.merge.mapfiles=true,是否合併Map輸入文件默認爲true。

    hive.merge.mapredfiles=false,設定是否合併Reduce輸出文件，默認爲false。

    hive.merge.size.per.task=256*1000*1000，設定合併文件的大小，默認爲256000000。

6、多做業

    共享中間結果集

    多做業共用輸入或輸出，以下場景

        每日幾千個做業訪問大日誌表trackinfo

        訪問多個表的相同統計存在於不少做業裏面

    經常使用複雜或低效統計統計給出，以免上層做業過多計算

7、參數調優

    有時會起到很好效果

 

 

若是，您認爲閱讀這篇博客讓您有些收穫，不妨點擊一下右下角的【推薦】。
若是，您但願更容易地發現個人新博客，不妨點擊一下左下角的【關注我】。
若是，您對個人博客所講述的內容有興趣，請繼續關注個人後續博客，我是【劉超★ljc】。

本文版權歸做者，禁止轉載，不然保留追究法律責任的權利。