Hive性能調優中數據傾斜的示例分析

這篇文章給大家分享的是有關Hive性能調優中數據傾斜的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

Map數

1. 通常情況下，作業會通過input的目錄產生一個或者多個map任務。主要的決定因素有：input的文件總個數，input的文件大小，集群設置的文件塊大小(目前為128M，可在hive中通過set dfs.block.size;命令查看到，該參數不能自定義修改)；

2. 舉例：a)一個大文件：假設input目錄下有1個文件a，大小為780M，那么hadoop會將該文件a分隔成7個塊（6個128m的塊和1個12m的塊），從而產生7個map數。b) 多個小文件：假設input目錄下有3個文件a，b，c大小分別為10m，20m，150m，那么hadoop會分隔成4個塊（10m，20m，128m，22m），從而產生4個map數。即，如果文件大于塊大小(128m)，那么會拆分，如果小于塊大小，則把該文件當成一個塊。

3. 是不是map數越多越好? 答案是否定的。如果一個任務有很多小文件（遠遠小于塊大小128m），則每個小文件也會被當做一個塊，用一個map任務來完成，而一個map任務啟動和初始化的時間遠遠大于邏輯處理的時間，就會造成很大的資源浪費。而且，同時可執行的map數是受限的。

4. 是不是保證每個map處理接近128m的文件塊，就高枕無憂了？答案也是不一定。比如有一個127m的文件，正常會用一個map去完成，但這個文件只有一個或者兩個字段，卻有幾千萬的記錄，如果map處理的邏輯比較復雜，用一個map任務去做，肯定也比較耗時。

針對上面的問題3和4，我們需要采取兩種方式來解決：即減少map數和增加map數。

如何適當的增加map數

當input的文件都很大，任務邏輯復雜，map執行非常慢的時候，可以考慮增加Map數，來使得每個map處理的數據量減少，從而提高任務的執行效率。針對上面的第4條 假設有這樣一個任務：

Select data_desc,
count(1),
count(distinct id),
sum(case when …),
sum(case when …),
sum(…)
from a group by data_desc

如果表a只有一個文件，大小為120M，但包含幾千萬的記錄，如果用1個map去完成這個任務，肯定是比較耗時的，這種情況下，我們要考慮將這一個文件合理的拆分成多個，這樣就可以用多個map任務去完成。

set mapreduce.job.reduces =10;
create table a_1 as
select * from a
distribute by rand();

這樣會將a表的記錄，隨機的分散到包含10個文件的a_1表中，再用a_1代替上面sql中的a表，則會用10個map任務去完成。

每個map任務處理大于12M（幾百萬記錄）的數據，效率肯定會好很多。

看上去，貌似這兩種有些矛盾，一個是要合并小文件，一個是要把大文件拆成小文件，這點正是重點需要關注的地方，根據實際情況，控制map數量需要遵循兩個原則：使大數據量利用合適的map數；使單個map任務處理合適的數據量；

調整reduce數

1. 
   

1. 調整reduce個數方法一

a） 每個Reduce 處理的數據量默認是256MB

hive.exec.reducers.bytes.per.reducer=256123456

b） 每個任務最大的reduce數，默認為1009

hive.exec.reducers.max=1009

c）計算reducer數的公式

N=min(參數2，總輸入數據量/參數1)

參數1：每個Reduce處理的最大數據量 參數2：每個任務最大Reduce數量

1. 調整reduce個數方法二

在hadoop的mapred-default.xml文件中修改 設置每個job的Reduce個數

set mapreduce.job.reduces = 15;

1. reduce個數并不是越多越好

a）過多的啟動和初始化reduce也會消耗時間和資源；b） 有多少個reduce，就會有多少個輸出文件，如果生成了很多個小文件，那么如果這些小文件作為下一個任務的輸入，則也會出現小文件過多的問題；

感謝各位的閱讀！關于“Hive性能調優中數據傾斜的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！