前言

maptask的並行度決定map階段的任務處理併發度，進而影響到整個job的處理速度
那麼，mapTask並行例項是否越多越好呢？其並行度又是如何決定呢？

1 mapTask並行度的決定機制

一個job的mapTask並行度由客戶端在提交job時決定。

客戶端對map階段並行度的規劃的基本邏輯為：
1. 將待處理資料執行邏輯切片（即按照一個特定切片大小，將待處理資料劃分成邏輯上的多個split）
2. 為每一個split分配一個mapTask並行例項處理

這段邏輯及形成的切片規劃描述檔案，由FileInputFormat實現類的getSplits()方法完成，其過程如下圖：

2 FileInputFormat切片機制

1. 切片定義在InputFormat類中的getSplit()方法

2. FileInputFormat中預設的切片機制：

a)  簡單地按照檔案的內容長度進行切片
b)  切片大小，預設等於block大小
c)  切片時不考慮資料集整體，而是逐個針對每一個檔案單獨切片

比如待處理資料有兩個檔案：

file1.txt    320M
file2.txt    10M

經過FileInputFormat的切片機制運算後，形成的切片資訊如下：

file1.txt.split1--  0~128
file1.txt.split2--  128~256
file1.txt.split3--  256~320
file2.txt.split1--  0~10M
 

3. FileInputFormat中切片的大小的引數配置

通過分析原始碼，在FileInputFormat中，計算切片大小的邏輯：Math.max(minSize, Math.min(maxSize, blockSize)); 切片主要由這幾個值來運算決定

因此，預設情況下，切片大小=blocksize。

maxsize（切片最大值）：
引數如果調得比blocksize小，則會讓切片變小，而且就等於配置的這個引數的值
minsize （切片最小值）：
引數調的比blockSize大，則可以讓切片變得比blocksize還大

選擇併發數的影響因素：
1、運算節點的硬體配置
2、運算任務的型別：CPU密集型還是IO密集型
3、運算任務的資料量

3 map並行度的經驗之談

如果硬體配置為2*12core + 64G，恰當的map並行度是大約每個節點20-100個map，最好每個map的執行時間至少一分鐘。

• 如果job的每個map或者 reduce task的執行時間都只有30-40秒鐘，那麼就減少該job的map或者reduce數，每一個task(map|reduce)的setup和加入到排程器中進行排程，這個中間的過程可能都要花費幾秒鐘，所以如果每個task都非常快就跑完了，就會在task的開始和結束的時候浪費太多的時間。

  配置task的JVM重用可以改善該問題：（mapred.job.reuse.jvm.num.tasks，預設是1，
  表示一個JVM上最多可以順序執行的task數目（屬於同一個Job）是1。也就是說一個task啟一個JVM）

• 如果input的檔案非常的大，比如1TB，可以考慮將hdfs上的每個block size設大，比如設成256MB或者512MB

4 ReduceTask並行度的決定

reducetask的並行度同樣影響整個job的執行併發度和執行效率，但與maptask的併發數由切片數決定不同，Reducetask數量的決定是可以直接手動設定：

//預設值是1，手動設定為4
job.setNumReduceTasks(4);

如果資料分佈不均勻，就有可能在reduce階段產生資料傾斜

注意： reducetask數量並不是任意設定，還要考慮業務邏輯需求，有些情況下，需要計算全域性彙總結果，就只能有1個reducetask
.
儘量不要執行太多的reduce task。對大多數job來說，最好rduce的個數最多和叢集中的reduce持平，或者比叢集的 reduce slots小。這個對於小叢集而言，尤其重要。