一、簡述

Hadoop的核心能力是parition和sort，因而這也是優(yōu)化的根本。

觀察Hadoop處理數(shù)據(jù)的過程，有幾個顯著的特征：

• 數(shù)據(jù)的大規(guī)模并不是負載重點，造成運行壓力過大是因為運行數(shù)據(jù)的傾斜。
• jobs 數(shù)比較多的作業(yè)運行效率相對比較低，比如即使有幾百行的表，如果多次關聯(lián)對此匯總，產(chǎn)生幾十個jobs，將會需要30分鐘以上的時間且大部分時間被用于作業(yè)分配，初始化和數(shù)據(jù)輸出。M/R作業(yè)初始化的時間是比較耗時間資源的一個部分。
• 在使用SUM，COUNT，MAX，MIN等UDAF函數(shù)時，不怕數(shù)據(jù)傾斜問題，Hadoop在Map端的匯總合并優(yōu)化過，使數(shù)據(jù)傾斜不成問題。
• COUNT(DISTINCT)在數(shù)據(jù)量大的情況下，效率較低，如果多COUNT(DISTINCT)效率更低，因為COUNT(DISTINCT)是按GROUP BY字段分組，按DISTINCT字段排序，一般這種分布式方式是很傾斜的；比如：男UV，女UV，淘寶一天30億的PV，如果按性別分組，分配2個reduce，每個reduce處理15億數(shù)據(jù)。
• 數(shù)據(jù)傾斜是導致效率大幅降低的主要原因，可以采用多一次 Map/Reduce 的方法， 避免傾斜。

二、表設計層面優(yōu)化

2.1、利用分區(qū)表優(yōu)化

分區(qū)表 是在某一個或者幾個維度上對數(shù)據(jù)進行分類存儲，一個分區(qū)對應一個目錄。如果篩選條件里有分區(qū)字段，那么 Hive 只需要遍歷對應分區(qū)目錄下的文件即可，不需要遍歷全局數(shù)據(jù)，使得處理的數(shù)據(jù)量大大減少，從而提高查詢效率。

當一個 Hive 表的查詢大多數(shù)情況下，會根據(jù)某一個字段進行篩選時，那么非常適合創(chuàng)建為分區(qū)表。

2.2、利用桶表優(yōu)化

指定桶的個數(shù)后，存儲數(shù)據(jù)時，根據(jù)某一個字段進行哈希后，確定存儲在哪個桶里，這樣做的目的和分區(qū)表類似，也是使得篩選時不用全局遍歷所有的數(shù)據(jù)，只需要遍歷所在桶就可以了。

2.3、選擇合適的文件存儲格式

Apache Hive 支持 Apache Hadoop 中使用的幾種熟悉的文件格式。

TextFile

默認格式，如果建表時不指定默認為此格式。

存儲方式：行存儲。

每一行都是一條記錄，每行都以換行符\n結尾。數(shù)據(jù)不做壓縮時，磁盤會開銷比較大，數(shù)據(jù)解析開銷也比較大。

可結合 Gzip、Bzip2 等壓縮方式一起使用（系統(tǒng)會自動檢查，查詢時會自動解壓），但對于某些壓縮算法 hive 不會對數(shù)據(jù)進行切分，從而無法對數(shù)據(jù)進行并行操作。

SequenceFile

一種Hadoop API 提供的二進制文件，使用方便、可分割、可壓縮的特點。

支持三種壓縮選擇：NONE、RECORD、BLOCK。RECORD壓縮率低，一般建議使用BLOCK壓縮。

RCFile

存儲方式：數(shù)據(jù)按行分塊，每塊按照列存儲 。

• 首先，將數(shù)據(jù)按行分塊，保證同一個record在一個塊上，避免讀一個記錄需要讀取多個block。
• 其次，塊數(shù)據(jù)列式存儲，有利于數(shù)據(jù)壓縮和快速的列存取。

ORC

存儲方式：數(shù)據(jù)按行分塊，每塊按照列存儲

Hive 提供的新格式，屬于 RCFile 的升級版，性能有大幅度提升，而且數(shù)據(jù)可以壓縮存儲，壓縮快，快速列存取。

Parquet

存儲方式：列式存儲

Parquet 對于大型查詢的類型是高效的。對于掃描特定表格中的特定列查詢，Parquet特別有用。Parquet一般使用 Snappy、Gzip 壓縮。默認 Snappy。

Parquet 支持 Impala 查詢引擎。

表的文件存儲格式盡量采用 Parquet 或 ORC，不僅降低存儲量，還優(yōu)化了查詢，壓縮，表關聯(lián)等性能；

2.4、選擇合適的壓縮方式

Hive 語句最終是轉化為 MapReduce 程序來執(zhí)行的，而 MapReduce 的性能瓶頸在與 網(wǎng)絡IO 和 磁盤IO，要解決性能瓶頸，最主要的是 減少數(shù)據(jù)量，對數(shù)據(jù)進行壓縮是個好方式。壓縮雖然是減少了數(shù)據(jù)量，但是壓縮過程要消耗CPU，好在Hadoop中，往往性能瓶頸不在于CPU，CPU壓力并不大，所以壓縮充分利用了比較空閑的CPU。

常用壓縮算法對比

image

如何選擇壓縮方式

1. 壓縮比率
2. 壓縮解壓速度
3. 是否支持split

支持分割的文件可以并行的有多個 mapper 程序處理大數(shù)據(jù)文件，大多數(shù)文件不支持可分割是因為這些文件只能從頭開始讀。

三、分階段優(yōu)化

3.1、map 階段優(yōu)化

確定合適的 map 數(shù)

Map階段的優(yōu)化，主要是確定合適的map數(shù)。

默認的 mapper 個數(shù)計算方式：

# 輸入文件總大?。簍otal_size   
# hdfs 設置的數(shù)據(jù)塊大?。篸fs_block_size
default_mapper_num = total_size/dfs_block_size

MapReduce 中提供了如下參數(shù)來控制 map 任務個數(shù)：

set mapred.map.tasks=10;

從字面上看，貌似是可以直接設置 mapper 個數(shù)的樣子，但是很遺憾不行，這個參數(shù)設置只有在大于default_mapper_num的時候，才會生效。

還有另外的參數(shù)：

mapred.min.split.size: 指的是數(shù)據(jù)的最小分割單元大小，min的默認值是1B，這個大小只有在大于 dfs_block_size 的時候才會生效
mapred.max.split.size: 指的是數(shù)據(jù)的最大分割單元大小，max的默認值是256MB

hive.input.format指定為org.apache.hadoop.hive.ql.io.HiveInputFormat時，map數(shù)與設定的以下三個參數(shù)相關：

（maxSize與blockSize之間的最小值）與minSize之間的最大值
split_size = max(mapred.min.split.size, min(dfs_block_size, mapred.max.split.size)
split_num = total_size/split_size
default_mapper_num = total_size/dfs_block_size
compute_map_num = min(split_num, max(default_mapper_num, mapred.map.tasks))

總結一下控制 mapper 個數(shù)的方法：

• 如果想增加 mapper 個數(shù)，可以設置mapred.map.tasks為一個較大的值
• 如果想減少 mapper 個數(shù)，可以設置maperd.min.split.size為一個較大的值
• 如果輸入是大量小文件，想減少 mapper 個數(shù)，可以通過設置hive.input.format合并小文件

如果想要調整 mapper 個數(shù)，在調整之前，需要確定處理的文件大概大小以及文件的存在形式（是大量小文件，還是單個大文件），然后再設置合適的參數(shù)。

減少map數(shù)量

--假設一個SQL任務：
Select count(1) from popt_tbaccountcopy_meswhere pt = '2012-07-04';
--該任務的inputdir :  /group/p_sdo_data/p_sdo_data_etl/pt/popt_tbaccountcopy_mes/pt=2012-07-04
--共有194個文件，其中很多事遠遠小于128M的小文件，總大小9G，正常執(zhí)行會用194個map任務。
--Map總共消耗的計算資源：SLOTS_MILLIS_MAPS= 623,020

--通過以下方法來在map執(zhí)行前合并小文件，減少map數(shù), 100000000表示100M：
set mapred.max.split.size=100000000;
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;

--再執(zhí)行上面的語句，用了74個map任務，map消耗的計算資源：SLOTS_MILLIS_MAPS= 333,500
--對于這個簡單SQL任務，執(zhí)行時間上可能差不多，但節(jié)省了一半的計算資源。

set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
--這個參數(shù)表示執(zhí)行前進行小文件合并，前面三個參數(shù)確定合并文件塊的大小，文件塊大小128m的，按照128m來分隔，小于128m,大于100m的，按照100m來分隔，把那些小于100m的（包括小文件和分隔大文件剩下的），進行合并,最終生成了74個塊。

增大map數(shù)量

--如何適當?shù)脑黾觤ap數(shù)？
--當input的文件都很大，任務邏輯復雜，map執(zhí)行非常慢的時候，可以考慮增加Map數(shù)，來使得每個map處理的數(shù)據(jù)量減少，從而提高任務的執(zhí)行效率。

--假設有這樣一個任務：
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 mapred.reduce.tasks=10;
create table a_1 as select * from a distribute by rand(123);

--這樣會將a表的記錄，隨機的分散到包含10個文件的a_1表中，再用a_1代替上面sql中的a表，則會用10個map任務去完成。
--每個map任務處理大于12M（幾百萬記錄）的數(shù)據(jù)，效率肯定會好很多。

3.2、reduce 階段優(yōu)化

如果 reducer 數(shù)量過多，一個 reducer 會產(chǎn)生一個結數(shù)量果文件，這樣就會生成很多小文件，那么如果這些結果文件會作為下一個 job 的輸入，則會出現(xiàn)小文件需要進行合并的問題，而且啟動和初始化 reducer 需要耗費和資源。

如果 reducer 數(shù)量過少，這樣一個 reducer 就需要處理大量的數(shù)據(jù)，并且還有可能會出現(xiàn)數(shù)據(jù)傾斜的問題，使得整個查詢耗時長。

默認情況下，hive 分配的 reducer 個數(shù)由下列參數(shù)決定:

• 參數(shù)1：hive.exec.reducers.bytes.per.reducer(默認1G)
• 參數(shù)2：hive.exec.reducers.max(默認為999)

reducer的計算公式為:

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

可以通過改變上述兩個參數(shù)的值來控制reducer的數(shù)量，也可以通過：

set mapred.reduce.tasks=10;

直接控制reducer個數(shù)，如果設置了該參數(shù)，上面兩個參數(shù)就會忽略。

四、 SQL 語法優(yōu)化

4.1、列裁剪

Hive 在讀數(shù)據(jù)的時候，可以只讀取查詢中所需要用到的列，而忽略其他的列。這樣做可以節(jié)省讀取開銷，中間表存儲開銷和數(shù)據(jù)整合開銷。

set hive.optimize.cp = true; -- 列裁剪，取數(shù)只取查詢中需要用到的列，默認為真

4.2、分區(qū)裁剪

在查詢的過程中只選擇需要的分區(qū)，可以減少讀入的分區(qū)數(shù)目，減少讀入的數(shù)據(jù)量。

set hive.optimize.pruner=true; -- 默認為true

4.3、Join優(yōu)化

4.3.1、使用相同的連接鍵

在 hive 中，當對 3 個或更多張表進行 join 時，如果 on 條件使用相同字段，那么它們會合并為一個 MapReduce Job，利用這種特性，可以將相同的 join on 的放入一個 job 來節(jié)省執(zhí)行時間。

4.3.2、小表 join 大表原則

在使用寫有 Join 操作的查詢語句時有一條原則：應該將條目少的表/子查詢放在Join操作符的左邊。原因是在Join操作的Reduce階段，位于Join操作符左邊的表的內容會被加載進內存，將條目少的表放在左邊，可以有效減少發(fā)生OOM錯誤的幾率；再進一步，可以使用Group讓小的維度表（1000條以下的記錄條數(shù)）先進內存。在map端完成reduce。

實際測試發(fā)現(xiàn)：新版的 hive 已經(jīng)對小表 JOIN 大表和大表 JOIN 小表進行了優(yōu)化。小表放在左邊和右邊已經(jīng)沒有明顯區(qū)別。

4.3.3、啟用 mapjoin

mapjoin 是將 join 雙方比較小的表直接分發(fā)到各個 map 進程的內存中，在 map 進程中進行 join 操作，這樣就不用進行 reduce 步驟，從而提高了速度。只有 join 操作才能啟用 mapjoin。

• 開啟MapJoin參數(shù)設置：

1) 設置自動選擇MapJoin

set hive.auto.convert.join = true（默認為true）

2) 大表小表的閥值設置（默認25M以下認為是小表）：

set hive.mapjoin.smalltable.filesize=25000000;

• MapJoin 工作機制

image

上圖是 Hive MapJoin 的原理圖，從圖中可以看出 MapJoin 分為兩個階段：

1. 通過 MapReduce Local Task，將小表讀入內存，生成內存HashTableFiles上傳至Distributed Cache中，這里會對HashTableFiles進行壓縮。
2. MapReduce Job在Map階段，每個Mapper從Distributed Cache讀取HashTableFiles到內存中，順序掃描大表，在Map階段直接進行Join，將數(shù)據(jù)傳遞給下一個MapReduce任務。也就是在map端進行join避免了shuffle。

Join操作在Map階段完成，不再需要Reduce，有多少個Map Task，就有多少個結果文件。

4.3.4、桶表 mapjoin

當兩個分桶表 join 時，如果 join on的是分桶字段，小表的分桶數(shù)是大表的倍數(shù)時，可以啟用 mapjoin 來提高效率。

set hive.optimize.bucketmapjoin = true; -- 啟用桶表 map join

4.3.5、大表 JOIN 大表

把空值的 key 變成一個字符串加上隨機數(shù)，就能把傾斜的數(shù)據(jù)分到不同的Reduce上，從而解決數(shù)據(jù)傾斜問題。

4.4、Group By 優(yōu)化

默認情況下，Map階段同一個Key的數(shù)據(jù)會分發(fā)到一個Reduce上，當一個Key的數(shù)據(jù)過大時會產(chǎn)生 數(shù)據(jù)傾斜。進行group by操作時可以從以下兩個方面進行優(yōu)化：

Map端部分聚合

事實上并不是所有的聚合操作都需要在reduce部分進行，很多聚合操作都可以先在Map端進行部分聚合，然后reduce端得出最終結果。

--開啟Map端聚合參數(shù)設置
set hive.map.aggr=true

--用于設定 map 端進行聚合操作的條目數(shù)
set hive.grouby.mapaggr.checkinterval=100000

有數(shù)據(jù)傾斜時進行負載均衡

set hive.groupby.skewindata = true; -- 有數(shù)據(jù)傾斜的時候進行負載均衡（默認是false）

當選項設定為 true 時，生成的查詢計劃有兩個 MapReduce 任務。

在第一個 MapReduce 任務中，map 的輸出結果會隨機分布到 reduce 中，每個 reduce 做部分聚合操作，并輸出結果，這樣處理的結果是相同的group by key有可能分發(fā)到不同的 reduce 中，從而達到負載均衡的目的；

第二個 MapReduce 任務再根據(jù)預處理的數(shù)據(jù)結果按照group by key分布到各個 reduce 中，最后完成最終的聚合操作。

4.5、Order By 優(yōu)化

order by只能是在一個reduce進程中進行，所以如果對一個大數(shù)據(jù)集進行 order by，會導致一個reduce進程中處理的數(shù)據(jù)相當大，造成查詢執(zhí)行緩慢。

• 在最終結果上進行order by，不要在中間的大數(shù)據(jù)集上進行排序。如果最終結果較少，可以在一個reduce上進行排序時，那么就在最后的結果集上進行 order by。
• 如果是取排序后的前N條數(shù)據(jù)，可以使用distribute by和 sort by在各個reduce上進行排序后前N條，然后再對各個reduce的結果集合合并后在一個reduce中全局排序，再取前N條，因為參與全局排序的order by的數(shù)據(jù)量最多是 reduce個數(shù) * N，所以執(zhí)行效率很高。

4.6、in/exists 優(yōu)化

雖然經(jīng)過測驗，hive1.2.1 也支持in/exists操作，但還是推薦使用hive的一個高效替代方案：left semi join

比如說：

select a.id, a.name from a where a.id in (select b.id from b);
select a.id, a.name from a where exists (select id from b where a.id = b.id);

應該轉換成：

select a.id, a.name from a left semi join b on a.id = b.id;

4.7、count(distinct) 優(yōu)化

-- 優(yōu)化前（只有一個reduce，先去重再count負擔比較大）：
select count(distinct id) from tablename;
-- 優(yōu)化后（啟動兩個job，一個job負責子查詢(可以有多個reduce)，另一個job負責count(1))：
select count(1) from (select distinct id from tablename) tmp

4.8、一次讀取多次插入

有些場景是從一張表讀取數(shù)據(jù)后，要多次利用，這時可以使用multi insert語法：

from sale_detail  
insert overwrite table sale_detail_multi 
partition (sale_date='2010', region='china' )  
select shop_name, customer_id, total_price where .....  
insert overwrite table sale_detail_multi partition (sale_date='2011', region='china' )  
select shop_name, customer_id, total_price where .....;

五、小文件優(yōu)化

小文件是如何產(chǎn)生的：

• 動態(tài)分區(qū)插入數(shù)據(jù)，產(chǎn)生大量的小文件，從而導致map數(shù)量劇增；
• reduce數(shù)量越多，小文件也越多（reduce的個數(shù)和輸出文件是對應的）
• 數(shù)據(jù)源本身就包含大量的小文件。

小文件問題的影響：

• 從Hive的角度看，小文件會開很多map，一個map開一個JVM去執(zhí)行，所以這些任務的初始化，啟動，執(zhí)行會浪費大量的資源，嚴重影響性能。
• 在HDFS中，每個小文件對象約占150byte，如果小文件過多會占用大量內存。這樣NameNode內存容量嚴重制約了集群的擴展。

小文件問題的解決方案：

• 從小文件產(chǎn)生的途徑就可以從源頭上控制小文件數(shù)量，方法如下：

  • 使用Sequencefile作為表存儲格式，不要用textfile，在一定程度上可以減少小文件
  • 減少reduce的數(shù)量（可以使用參數(shù)進行控制）
  • 少用動態(tài)分區(qū)，用時記得按 distribute by 分區(qū)

• 對于已有的小文件，我們可以通過以下幾種方案解決：

  • 使用hadoop archive命令把小文件進行歸檔；
  • 重建表，建表時減少 reduce 數(shù)量；
  • 通過參數(shù)進行調節(jié)，設置map/reduce端的相關參數(shù)

5.1、Map 輸入合并

可以通過在輸入 mapper 的之前將是輸入合并，以減少 map 的個數(shù)：

-- 每個Map最大輸入大小，決定合并后的文件數(shù)
set mapred.max.split.size=256000000;
-- 一個節(jié)點上split的至少的大小 ，決定了多個data node上的文件是否需要合并
set mapred.min.split.size.per.node=100000000;
-- 一個交換機下split的至少的大小，決定了多個交換機上的文件是否需要合并
set mapred.min.split.size.per.rack=100000000;
-- 執(zhí)行Map前進行小文件合并
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

5.2、Map/Reduce 輸出合并

-- 在map-only job后合并文件，默認true
set hive.merge.mapfiles=true;
-- 在map-reduce job后合并文件，默認false
set hive.merge.mapredfiles=true;
-- 設置合并后文件大大小，默認256000000
set hive.merge.size.per.task=256000000;
-- 當輸出文件的平均值大小小于該值時，啟動一個獨立的MR任務進行文件merge，是決定是否執(zhí)行合并操作的閾值，默認16000000
set hive.merge.smallfiles.avgsize=16000000;

六、其他參數(shù)層面優(yōu)化

6.1、啟用壓縮

6.1.1、map 輸出壓縮

set mapreduce.map.output.compress=true;
set mapreduce.map.output.compress.codec=org.apache.hadoop.io.compress.SnappyCodec;

6.1.2、中間數(shù)據(jù)壓縮

中間數(shù)據(jù)壓縮就是對 hive 查詢的多個 job 之間的數(shù)據(jù)進行壓縮。最好是選擇一個節(jié)省CPU耗時的壓縮方式?？梢圆捎?code>snappy壓縮算法，該算法的壓縮和解壓效率都非常高。

set hive.exec.compress.intermediate=true;
set hive.intermediate.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;
set hive.intermediate.compression.type=BLOCK;

6.1.3、結果數(shù)據(jù)壓縮

最終的結果數(shù)據(jù)（Reducer輸出數(shù)據(jù)）也是可以進行壓縮的，可以選擇一個壓縮效果比較好的，可以減少數(shù)據(jù)的大小和數(shù)據(jù)的磁盤讀寫時間。

常用的gzip，snappy壓縮算法是不支持并行處理的，如果數(shù)據(jù)源是gzip/snappy壓縮文件大文件，這樣只會有有個mapper來處理這個文件，會嚴重影響查詢效率。

所以如果結果數(shù)據(jù)需要作為其他查詢任務的數(shù)據(jù)源，可以選擇支持splitable的 LZO算法，這樣既能對結果文件進行壓縮，還可以并行的處理，這樣就可以大大的提高job執(zhí)行的速度了。

關于如何給Hadoop集群安裝LZO壓縮庫可以查看 這篇文章。

set hive.exec.compress.output=true;
set mapreduce.output.fileoutputformat.compress=true;
set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.compress.GzipCodec;
set mapreduce.output.fileoutputformat.compress.type=BLOCK;

七、Hive架構層面優(yōu)化

7.1、模式選擇

7.1.1、本地模式

對于大多數(shù)情況，Hive可以通過本地模式在單臺機器上處理所有任務。對于小數(shù)據(jù)，執(zhí)行時間可以明顯被縮短。通過set hive.exec.mode.local.auto = true（默認為false）設置為本地模式，本地模式涉及到三個參數(shù)：

set hive.exec.mode.local.auto=true；是打開hive自動判斷是否啟動本地模式的開關，但是只是打開這個參數(shù)不能保證啟動本地模式，要當map任務數(shù)不超過hive.exec.mode.local.auto.input.files.max 的個數(shù)并且 map 輸入文件大小不超過hive.exec.mode.local.auto.inputbytes.max 所指定的大小時，才能啟動本地模式。

如下：用戶可以通過設置hive.exec.mode.local.auto的值為true，來讓Hive在適當?shù)臅r候自動啟動這個優(yōu)化。

--開啟本地mr，默認 false
set hive.exec.mode.local.auto=true;  
--設置local mr的最大輸入數(shù)據(jù)量，當輸入數(shù)據(jù)量小于這個值時采用local mr的方式，默認為134217728，即128M
set hive.exec.mode.local.auto.inputbytes.max=50000000;
--設置local mr的最大輸入文件個數(shù)，當輸入文件個數(shù)小于這個值時采用local mr的方式，默認為4
set hive.exec.mode.local.auto.input.files.max=10;

7.1.2、并行模式

Hive會將一個查詢轉化成一個或多個階段。這樣的階段可以是MapReduce階段、抽樣階段、合并階段、limit階段。默認情況下，Hive一次只會執(zhí)行一個階段，由于job包含多個階段，而這些階段并非完全相互依賴，即：這些階段可以并行執(zhí)行，可以縮短整個job的執(zhí)行時間。設置參數(shù)，set hive.exec.parallel=true，或者通過配置文件來完成：

 set hive.exec.parallel;

7.1.3、嚴格模式

Hive提供一個嚴格模式，可以防止用戶執(zhí)行那些可能產(chǎn)生意想不到的影響查詢，通過設置Hive.mapred.modestrict來完成。

set Hive.mapred.modestrict;

7.2 JVM重用

Hadoop通常是使用派生JVM來執(zhí)行map和reduce任務的。這時JVM的啟動過程可能會造成相當大的開銷，尤其是執(zhí)行的job包含成百上千的task任務的情況。JVM重用可以使得JVM示例在同一個job中時候，通過參數(shù)mapred.job.reuse.jvm.num.tasks來設置。

set mapred.job.reuse.jvm.num.tasks=5;

JVM 重用也是有缺點的，開啟JVM重用會一直占用使用到的 task 的插槽，以便進行重用，直到任務完成后才會釋放。如果某個不平衡的job中有幾個 reduce task 執(zhí)行的時間要比其他的 reduce task 消耗的時間要多得多的話，那么保留的插槽就會一直空閑卻無法被其他的 job 使用，直到所有的 task 都結束了才會釋放。

7.3、推測執(zhí)行

Hadoop推測執(zhí)行可以觸發(fā)執(zhí)行一些重復的任務，盡管因對重復的數(shù)據(jù)進行計算而導致消耗更多的計算資源，不過這個功能的目標是通過加快獲取單個task的結果以偵測執(zhí)行慢的TaskTracker加入到?jīng)]名單的方式來提高整體的任務執(zhí)行效率。Hadoop的推測執(zhí)行功能由2個配置控制著：

set mapreduce.map.speculative=true;
set mapreduce.reduce.speculative=true;

八、來源

1.https://www.cnblogs.com/swordfall/p/11037539.html#auto_id_27
2.https://juejin.im/entry/5afb63e051882542af040dd2