hive性能優化

一、Map階段的優化：

（控制hive任務中的map數，確定合適的map數，以及每個map處理合適的數據量）。

map個數影響因子：

1. input目錄中文件總個數；
2. input目錄中每個文件大小；
3. 集群設置的文件塊大小(默認為128M, 可在hive中通過set dfs.block.size;命令查看，不能在hive中自定義修改)；

舉例：
input目錄中有1個文件（300M），會產生3個塊（2個128M，1個44M）即3個Map數。
input目錄中有3個文件（5M,10M,200M），會產生4個塊（5M,10M,128M,72M）即4個Map數。

適當減少Map數：

當一個任務有很多小文件（遠遠小于塊大小128m）,會產生很多Map，而一個Map任務啟動和初始化的時間遠遠大于邏輯處理的時間，就會造成很大的資源浪費，而且同時可執行的map數是受限的。

set mapred.max.split.size=100000000;//（100M）
set mapred.min.split.size.per.node=100000000;
set mapred.min.split.size.per.rack=100000000;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;//表示執行前進行小文件合并。
//大于128:按照128M分割；100~128按照100分；小于100的進行合并。

適當增加Map數：

當有一個小于128M的文件(其中有上千萬的數據，字段少并且數據單位小)，如果map處理的邏輯比較復雜，用一個map任務去做，耗時比較大。

set mapred.reduce.tasks=10;
create table a_1 as 
select * from a distribute by rand();
//表示通過設置Map任務數來中加Map，把a表中的數據均勻的放到a_1目錄下10個文件中。

Map端聚合：

set  hive.map.aggr=true ;（默認為true)

二、Reduce階段的優化：

2.1 指定reduce數量

 set mapred.reduce.tasks=10

2.2未指定reduce數量

param1:hive.exec.reducers.bytes.per.reducer（默認為1000^3）
param2:hive.exec.reducers.max（默認為999）
reduceNum = min(param2，總輸入數據量/param1(reduceNum = InputFileSize / bytes per reducer))

通常情況下，有必要手動指定reducer個數。考慮到map階段的輸出數據量通常會比輸入有大幅減少，因此即使不設定reducer個數，重設參數2還是必要的。依據Hadoop的經驗，可以將參數2設定為0.95*(集群中TaskTracker個數)。

三、其他優化：

Multi-insert & multi-group by

從一份基礎表中按照不同的維度，一次組合出不同的數據

FROM from_statement
INSERT OVERWRITE TABLE tablename1 [PARTITION (partcol1=val1)] select_statement1 group by key1
INSERT OVERWRITE TABLE tablename2 [PARTITION(partcol2=val2 )] select_statement2 group by key2
#具體實例
FROM pv_users 
INSERT OVERWRITE TABLE pv_gender_sum
SELECT pv_users.gender, count(DISTINCT pv_users.userid) 
GROUP BY pv_users.gender 
INSERT OVERWRITE DIRECTORY '/opt/data/users/pv_age_sum'
SELECT pv_users.age, count(DISTINCT pv_users.userid) 
GROUP BY pv_users.age; 

生成MR Job 個數

生成一個MR Job

多表連接，如果多個表中每個表都使用同一個列進行連接（出現在JOIN子句中），則只會生成一個MR Job。

SELECT a.val, b.val, c.val FROM a 
JOIN b ON (a.key = b.key1) 
JOIN c ON (c.key = b.key1)

三個表a、b、c都分別使用了同一個字段進行連接，亦即同一個字段同時出現在兩個JOIN子句中，從而只生成一個MR Job。

生成多個MR Job

多表連接，如果多表中，其中存在一個表使用了至少2個字段進行連接（同一個表的至少2個列出現在JOIN子句中），則會至少生成2個MR Job。

SELECT a.val, b.val, c.val FROM a 
JOIN b ON (a.key = b.key1) 
JOIN c ON (c.key = b.key2)

三個表基于2個字段進行連接，這兩個字段b.key1和b.key2同時出現在b表中。連接的過程是這樣的：首先a和b表基于a.key和b.key1進行連接，對應著第一個MR Job；表a和b連接的結果，再和c進行連接，對應著第二個MR Job。

數據傾斜：

傾斜原因：

map輸出數據按key Hash的分配到reduce中，由于key分布不均勻、業務數據本身的特性、建表時考慮不周、某些SQL語句本身就有數據傾斜等原因造成的reduce上的數據量差異過大，所以如何將數據均勻的分配到各個reduce中，就是解決數據傾斜的根本所在。

解決方案：

1. 空值數據傾斜

join的key值發生傾斜，key值包含很多空值或是異常值，這種情況可以對異常值賦一個隨機值來分散key。
案例：在日志中，常會有信息丟失的問題，比如日志中的 user_id，如果取其中的 user_id 和 用戶表中的user_id 關聯，會碰到數據傾斜的問題。

select * from log l
left outer join user u on 
case when (l.user_id is null or I.user_id='-' or I.user_id='0') 
then concat(‘sql_hive’,rand() ) else l.user_id end = u.user_id;

2. Join操作產生數據傾斜

2.1 大表和小表Join

產生原因：Hive在進行join時，按照join的key進行分發，而在join左邊的表的數據會首先讀入內存，如果左邊表的key相對分散，讀入內存的數據會比較小，join任務執行會比較快；而如果左邊的表key比較集中，而這張表的數據量很大，那么數據傾斜就會比較嚴重，而如果這張表是小表，則還是應該把這張表放在join左邊。
解決方式：使用map join讓小的維度表先進內存。在map端完成reduce。
在0.7.0版本之前：需要在sql中使用 /*+ MAPJOIN(smallTable) */ ；

SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a
JOIN b ON a.key = b.key;

在0.7.0版本之后：可以配置hive.auto.convert.join。

注意：使用默認啟動該優化的方式如果出現默名奇妙的BUG(比如MAPJOIN并不起作用),就將以下兩個屬性置為fase手動使用MAPJOIN標記來啟動該優化

hive.auto.convert.join=false(關閉自動MAPJOIN轉換操作)
hive.ignore.mapjoin.hint=false(不忽略MAPJOIN標記)

對于以下查詢是不支持使用方法二(MAPJOIN標記)來啟動該優化的

select /*+MAPJOIN(smallTableTwo)*/ idOne, idTwo, value FROM
  ( select /*+MAPJOIN(smallTableOne)*/ idOne, idTwo, value FROM
    bigTable JOIN smallTableOne on (bigTable.idOne = smallTableOne.idOne)                                                  
  ) firstjoin                                                            
  JOIN                                                                 
  smallTableTwo ON (firstjoin.idTwo = smallTableTwo.idTwo)  

但是，如果使用的是方法一即沒有MAPJOIN標記則以上查詢語句將會被作為兩個MJ執行，進一步的，如果預先知道表大小是能夠被加載進內存的，則可以通過以下屬性來將兩個MJ合并成一個MJ

hive.auto.convert.join.noconditionaltask：Hive在基于輸入文件大小的前提下將普通JOIN轉換成MapJoin，
并是否將多個MJ合并成一個
hive.auto.convert.join.noconditionaltask.size：
多個MJ合并成一個MJ時，其表的總的大小須小于該值，同時hive.auto.convert.join.noconditionaltask必須為true

2.2 大表和大表Join

產生原因：業務數據本身的特性，導致兩個表都是大表。
解決方式：業務削減。
案例：user 表有 500w+ 的記錄，把 user 分發到所有的 map 上也是個不小的開銷，而且 map join 不支持這么大的小表。如果用普通的 join，又會碰到數據傾斜的問題。

select * from log l left outer join user u
 on l.user_id = u.user_id;

解決方法：當天登陸的用戶其實很少,先只查詢當天登錄的用戶，log里user_id有上百萬個，這就又回到原來map join問題。所幸，每日的會員uv不會太多，有交易的會員不會太多，有點擊的會員不會太多，有傭金的會員不會太多等等。所以這個方法能解決很多場景下的數據傾斜問題。

select /*+mapjoin(u2)*/* from log l2
left outer join
 (
select  /*+mapjoin(l1)*/u1.*
from ( select distinct user_id from log ) l1
join user u1 on l1.user_id = u1.user_id
) u2
on l2.user_id = u2.user_id;

3. count distinct 聚 合 時 存 在 大 量 特 殊 值

產生原因： 做count distinct時，該字段存在大量值為NULL或空的記錄。
解決方式： 做count distinct時，將值為空的情況單獨處理，如果是計算count distinct，可以不用處理，直接過濾，在最后結果中加1。如果還有其他計算，需要進行group by，可以先將值為空的記錄單獨處理，再和其他計算結果進行union。
案例：
1.只計算count distinct

select cast(count(distinct user_id)+1 as bigint) as user_cnt
from user
where user_id is not null and user_id <> '';

2.計算完count distinct 后面還有 group by。同一個reduce上進行distinct操作時壓力很大,先將值為空的記錄單獨處理，再和其他計算結果進行union。
在Hive中，經常遇到count（distinct）操作，這樣會導致最終只有一個reduce，我們可以先group 再在外面包一層count，就可以了。

select day,
count(case when type='session' then 1 else null end) as session_cnt,
count(case when type='user' then 1 else null end) as user_cnt
from (
  select day,type
  from (
    select day,session_id,'session' as type from log
    union all
    select day user_id,'user' as type from log
  )
  group by day,type
)t1 
group by day;

4. group by 產生傾斜的問題

set hive.map.aggr=true

開啟map端combiner:在Map端做combine,若map各條數據基本上不一樣, 聚合無意義，通過如下參數設置。

hive.groupby.mapaggr.checkinterval = 100000 (默認)
hive.map.aggr.hash.min.reduction=0.5(默認)

解釋：預先取100000條數據聚合,如果聚合后的條數小于100000*0.5，則不再聚合。

set hive.groupby.skewindata=true；//決定  group by 操作是否支持傾斜數據。

注意：只能對單個字段聚合。
控制生成兩個MR Job,第一個MR Job Map的輸出結果隨機分配到reduce中減少某些key值條數過多某些key條數過小造成的數據傾斜問題。
在第一個 MapReduce 中，map 的輸出結果集合會隨機分布到 reduce 中， 每個reduce 做部分聚合操作，并輸出結果。這樣處理的結果是，相同的 Group By Key 有可能分發到不同的reduce中，從而達到負載均衡的目的；
第二個 MapReduce 任務再根據預處理的數據結果按照 Group By Key 分布到 reduce 中（這個過程可以保證相同的 Group By Key 分布到同一個 reduce 中），最后完成最終的聚合操作。