一、表設計

合理分表

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

二、掃描相關

1、謂詞下推（Predicate Push Down）

2、列裁剪（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

3、分區剪裁（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

三、關聯JOIN相關

1、JOIN操作左邊為小表

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

原因是在Join操作的Reduce階段，位於Join操作符左邊的表的內容會被加載到內存，將條目少的表放在左邊可以有效減少OOM（內存溢出）的幾率

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

如果是mapjoin，可以放在右邊

2、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)

3、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。

4、join不支持不等值連接

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

select ……from ……

join ……

on (a.key!=b.key)

因為如果用不等值號的話，它會查其他節點上的數據，那麽其他查不到的，mapreduce是不支持這樣的機制，所以hive是不支持不等值連接的

四、分組Group By相關

1、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中），最後完成最終的聚合操作

沒法通過部分值推導出最終值的，如中位數和眾數

五、合並小文件

合並功能會增加任務運行時間

合並操作的性能很大程度上取決與“單個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。

六、多作業

共享中間結果集

多作業共用輸入或輸出，如下場景

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

訪問多個表的相同統計存在於很多作業裏面

常用復雜或低效統計統計給出，以避免上層作業過多計算

七、參數調優

有時會起到很好效果

如果，您認為閱讀這篇博客讓您有些收獲，不妨點擊一下右下角的【推薦】。
如果，您希望更容易地發現我的新博客，不妨點擊一下左下角的【關註我】。
如果，您對我的博客所講述的內容有興趣，請繼續關註我的後續博客，我是【劉超★ljc】。

本文版權歸作者，禁止轉載，否則保留追究法律責任的權利。

hive優化總結