在Hadoop中，用于執(zhí)行MapReduce任務(wù)的機(jī)器角色有兩個(gè)：

• JobTracker:用于調(diào)度工作的，初始化作業(yè)，分配作業(yè)，與TaskTracker進(jìn)行通信，協(xié)調(diào)整個(gè)作業(yè)的執(zhí)行
• TaskTracker:用于執(zhí)行工作的；保持與JobTracker的通信，在分配的數(shù)據(jù)片段上執(zhí)行map或reduce任務(wù)
• HDFS：保存作業(yè)的數(shù)據(jù)，配置信息，保存作業(yè)結(jié)果
• 客戶端：編寫(xiě)mapreduce，配置作業(yè)，提交作業(yè)

一個(gè)Hadoop集群只有一個(gè)JobTracker.

MapReduce是一種編程模型，是一種編程方法。

• 輸入一個(gè)大文件，通過(guò)split之后，將其分為多個(gè)分片
• 每個(gè)文件分片由單獨(dú)的機(jī)器去處理，這就是map方法
• 將各個(gè)機(jī)器計(jì)算的結(jié)果進(jìn)行匯總并得到最終的結(jié)果，這就是reduce方法

input->split->map->shuffle->reduce->output

在Hadoop中，每個(gè)MapReduce任務(wù)都被初始化為一個(gè)Job,每個(gè)Job又可以分為兩個(gè)階段：map階段和reduce階段，這兩個(gè)階段分別用兩個(gè)函數(shù)來(lái)表示，即map函數(shù)和reduce函數(shù)，map函數(shù)接受一個(gè)<key,value>形式的輸入，然后同樣產(chǎn)生一個(gè)key-value形式的中間輸出，Hadoop會(huì)負(fù)責(zé)將所有具有相同中間key值的value集合到一起傳遞給reduce函數(shù)，reduce函數(shù)接受一個(gè)如<key,(list of value)>的形式輸入，然后對(duì)這個(gè)value集合進(jìn)行處理，每個(gè)reduce產(chǎn)生0個(gè)或者1個(gè)輸出，reduce的輸出結(jié)果也是key-value

在MR的標(biāo)準(zhǔn)模型中，reduce階段在map階段完成之前無(wú)法啟動(dòng)，而且在下載到reducer之前，所有處理過(guò)程的中間數(shù)據(jù)都保存在磁盤(pán)中，所有這些都顯著增加了處理的延遲

shuffle

shuffle過(guò)程包含在map和reduce兩端，在Map端的shuffle過(guò)程是對(duì)map的結(jié)果進(jìn)行劃分partition,排序sort和分割spill,然后將屬于同一個(gè)劃分的輸出合并在一起merge,并寫(xiě)在磁盤(pán)上，同時(shí)按照不同的劃分將結(jié)果發(fā)送給對(duì)應(yīng)的reduce（map的輸出的劃分和reduce的對(duì)應(yīng)關(guān)系由JobTracker確定）。reduce端又會(huì)將各個(gè)map送來(lái)的屬于同一個(gè)劃分的輸出進(jìn)行合并，然后對(duì)merge的結(jié)果進(jìn)行排序，最后交給reduce處理

map端

map端的shuffle過(guò)程包含在collect函數(shù)對(duì)map輸出結(jié)果的處理過(guò)程中，

reduce端

reduce端shuffle階段可以分為三個(gè)階段：復(fù)制map輸出，排序合并，reduce處理

舊API

map方法

map函數(shù)繼承于MapReduceBase,并且實(shí)現(xiàn)了Mapper接口，此接口是一個(gè)泛型類(lèi)型，有4個(gè)形式的參數(shù)，分別是

1. 輸入key值類(lèi)型
2. 輸入value值類(lèi)型
3. 輸出Key值類(lèi)型
4. 輸出value值類(lèi)型

reduce方法

reduce函數(shù)繼承于MapReduceBase，并且實(shí)現(xiàn)了Reducer接口，reduce函數(shù)是以map函數(shù)的輸出作為輸入

新API

• 在新API中，Mapper與Reducer已經(jīng)不是接口 而是抽象類(lèi)，而且map函數(shù)和reduce函數(shù)已經(jīng)不再實(shí)現(xiàn)Mapper和Reducer接口，而是繼承。
• 廣泛使用context對(duì)象，并使用MapContext進(jìn)行MapReduce之間的通信，MapContext同時(shí)充當(dāng)OutCollector和Reporter
  角色
• Job的配置統(tǒng)一由configuration來(lái)完成，不需要額外使用JobConf對(duì)守護(hù)進(jìn)程進(jìn)行配置
• 由Job類(lèi)來(lái)負(fù)責(zé)Job的控制，而不是JobClient,JobClient在新API中被刪除

數(shù)據(jù)流

數(shù)據(jù)首先按照TextInputFormat形式被處理成兩個(gè)InputSplit,然后輸入到兩個(gè)map中，map程序會(huì)讀取inputSplit指定位置的數(shù)據(jù)，然后按照設(shè)定的方式處理批數(shù)據(jù)，最后寫(xiě)入本地磁盤(pán)中。注意，這里不是寫(xiě)到hdfs上，因?yàn)閙ap的輸出在job完成之后即可刪除，因此不需要存儲(chǔ)在hdfs上。但是由于網(wǎng)絡(luò)傳輸降低了mapreduce任務(wù)的執(zhí)行效率，因此map的輸出文件是寫(xiě)在磁盤(pán)上的，如果map程序在沒(méi)有來(lái)得及將數(shù)據(jù)傳送到reduce就崩潰了，那么JobTracker只需要另外選取一臺(tái)機(jī)器重新執(zhí)行這個(gè)task就可以了。

Reduce會(huì)讀取map的輸出數(shù)據(jù)，合并Value,然后將他們輸出到hdfs上，reduce的輸出會(huì)占用很多的網(wǎng)絡(luò)帶寬，不過(guò)這與上傳數(shù)據(jù)一樣，是不可避免的。

在這，需要注意：

• MapReduce在執(zhí)行過(guò)程中往往不止一個(gè)reduce task,reduce task的數(shù)量是可以通過(guò)程序指定的，當(dāng)存在多個(gè)reduce task時(shí)，每個(gè)reduce會(huì)收集一個(gè)或者多個(gè)key值，當(dāng)出現(xiàn)多個(gè)reduce task時(shí)，每個(gè)reducetask都會(huì)生成一個(gè)輸出文件
• 在沒(méi)有reduce任務(wù)時(shí)，系統(tǒng)會(huì)直接將map的輸出結(jié)果作為最終的結(jié)果，同時(shí)map task的數(shù)量可以看成是reduce task的數(shù)量，即有多少個(gè)maptask就有多少個(gè)輸出文件

MR任務(wù)優(yōu)化

MapReduce計(jì)算模型的優(yōu)化主要集中在兩個(gè)方面：計(jì)算性能方面的優(yōu)化，IO操作方面的優(yōu)化

1. 任務(wù)的調(diào)度
   計(jì)算方面，hadoop總是優(yōu)先將任務(wù)分配給空閑的機(jī)器，使得所有的任務(wù)能公平分享資源；IO方面，hadoop盡量將Map任務(wù)分配給InputSplit的機(jī)器，減少網(wǎng)絡(luò)IO的消耗
2. 數(shù)據(jù)預(yù)處理與InputSplit的大小
   MR任務(wù)擅長(zhǎng)處理少量的大數(shù)據(jù)，不擅長(zhǎng)大量的小數(shù)據(jù)，因此可以通過(guò)設(shè)置map的輸入數(shù)據(jù)大小來(lái)調(diào)整map運(yùn)行時(shí)間，可以設(shè)置塊block的大小，也可以設(shè)置map任務(wù)的梳理來(lái)調(diào)整map任務(wù)的數(shù)據(jù)輸入
3. maph和reduce任務(wù)的數(shù)量
4. combine函數(shù)
5. 壓縮
6. 自定義comparator

Hadoop流

基本工作原理：

InputSplit->map>stdin>executable->stout->map->key/value

當(dāng)一個(gè)可執(zhí)行文件作為Mapper時(shí)，每一個(gè)map任務(wù)以一個(gè)獨(dú)立的進(jìn)程啟動(dòng)這個(gè)可執(zhí)行文件，然后在map任務(wù)運(yùn)行時(shí)，會(huì)把輸入切分成行提供給可執(zhí)行文件，并作為它的標(biāo)準(zhǔn)輸入stdin內(nèi)容，當(dāng)可執(zhí)行文件運(yùn)行出結(jié)果

幾個(gè)問(wèn)題

• 新舊API之間的差別
• 如何去重
• 如何排序
• reduce卡死
  reduce過(guò)程的百分比與對(duì)應(yīng)的處理如下：
  1. 0~33%是shuffle的過(guò)程，數(shù)據(jù)從mapper已到了reducer
  2. 33~67%是sort的過(guò)程，這個(gè)過(guò)程只會(huì)在mapper完成后才會(huì)執(zhí)行
  3. 67~100%才是reducer程序執(zhí)行的過(guò)程。如果reduce卡在了67%，那么說(shuō)明reducer一個(gè)也沒(méi)有執(zhí)行?？赡苁禽斎霐?shù)據(jù)太大，超過(guò)了限制，也可能是reducer有死循環(huán)的bug