Hive效能調優之資料傾斜 2

<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數；

當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任務處理合適的資料量；

<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數量

<2>調整reduce個數方法二

在hadoop的mapred-default.xml檔案中修改

設定每個job的reduce個數

set mapreduce.job.reduces = 15;

<3>reduce個數並不是越多越好

a）過多的啟動和初始化reduce也會消耗時間和資源；

b）有多少個reduce，就會有多少個輸出檔案，如果生成了很多個小檔案，那麼如果這些小檔案作為下乙個任務的輸入，則也會出現小檔案過多的問題；

總結:

在設定reduce個數的時候也需要考慮這兩個原則：處理大資料量利用合適的reduce數；使單個reduce任務處理資料量大小要合適；

本次的分享就到這裡了,喜歡的小夥伴們不要忘了點讚加關注哦ヾ(๑╹◡╹)ﾉ"