一、Mapreduce原理分析

1.1maptask執行機制

（1）首先，讀取資料元件Inputformat（預設為TextInputFormat）會通過getsplit（）方法對對應目錄中的檔案進行邏輯切片，預設128M，一個切片對應一個maptask。

（2）切分為切片之後，由RecordReader物件（預設為LineRecorder）進行讀取，一次讀取一行資料，返回<key，value>key為LongWritable型別，代表資料的偏移量，value為Text型別

代表字串文字。

（3）之後呼叫使用者寫的Mapper類中的map函式，預設每讀取一行呼叫一次。

（4）之後通過context.write(key,value)方法對結果進行map階段的輸出，輸出的資料進入環形緩衝區，環形緩衝區中的資料按分割槽排列。（預設對key進行hash後%reduce的

數量，也可實現partitioner介面，自定義分割槽邏輯）

（5）環形緩衝區預設大小為100M，預設溢寫比例為80%，及當資料達到緩衝區大小的80%後會啟動溢寫執行緒，鎖定這部分空間，並對分割槽內資料進行快速排序。

（6）若配置過Combiner，則會對相同key的value進行聚合，以便減小資料量，減輕網路傳輸開銷。

（7）最後如果有多個溢寫檔案，會進行一個歸併排序，確保一個maptask對應一個磁碟檔案。

1.2MapTask的並行度

　　我們知道，hdfs預設一個block大小為128M，split預設切片大小預設也是128M，這是一種巧合嗎？

　　假設有一個300M的檔案，我們按照1）分片大小100M ，2）分片大小128M進行思考

　　這是第一種情況，由於hdfs預設塊是128M，假如split大小為100M，可以看出，第二個MapTask要想操作第二個分片需要跨機器到datanode1上去拉去資料，資料跨網路傳輸影響效能，

移動計算比移動資料更重要！！

　　再看看第二種情況

　　若split大小保持和block大小一致，則很好的解決了以上的問題。

　　split的數量則為maptask的並行度，那麼並行度越高越好嗎？答案是否定的，這裡有一個比例是1.1，若檔案大小大於128M但是小於128M*1.1，則會被當成一個切片對待。並行度高也會消耗資源。

二、ReduceTask原理分析

2.1ReduceTask執行機制

　　ReduceTask大概分成三個階段：copy、sort,reduce。

　　copy階段會啟用一些資料copy執行緒（fetcher）請求maptask請求屬於自己分割槽的檔案。

　　Merge階段這裡的merge如map端的merge動作，只是陣列中存放的是不同map端copy來的數 值。Copy過來的資料會先放入記憶體緩衝區中，這裡的緩衝區大小要比map端的更為靈活。merge 有三種形式：記憶體到記憶體；記憶體到磁碟；磁碟到磁碟。預設情況下第一種形式不啟用。當記憶體中的 資料量到達一定閾值，就啟動記憶體到磁碟的merge。與map 端類似，這也是溢寫的過程，這個過 程中如果你設定有Combiner，也是會啟用的，然後在磁碟中生成了眾多的溢寫檔案。第二種 merge方式一直在執行，直到沒有map端的資料時才結束，然後啟動第三種磁碟到磁碟的merge 方式生成最終的檔案。

　　合併排序。把分散的資料合併成一個大的資料後，還會再對合並後的資料排序。 對排序後的鍵值對呼叫reduce方法，鍵相等的鍵值對呼叫一次reduce方法，每次呼叫會產生零個 或者多個鍵值對，最後把這些輸出的鍵值對寫入到HDFS檔案中

2.2ReduceTask並行度

　　這裡的並行度實在驅動類中手動設定的。一般要等於分割槽數