在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é)果
- 客戶端：編寫mapreduce，配置作業(yè)揖庄，提交作業(yè)
一個(gè)Hadoop集群只有一個(gè)JobTracker.
MapReduce是一種編程模型栗菜，是一種編程方法。
- 輸入一個(gè)大文件蹄梢，通過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ù)來表示幕袱，即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階段完成之前無法啟動(dòng)擂煞，而且在下載到reducer之前混弥，所有處理過程的中間數(shù)據(jù)都保存在磁盤中，所有這些都顯著增加了處理的延遲
shuffle
shuffle過程包含在map和reduce兩端对省，在Map端的shuffle過程是對(duì)map的結(jié)果進(jìn)行劃分partition,排序sort和分割spill,然后將屬于同一個(gè)劃分的輸出合并在一起merge,并寫在磁盤上蝗拿，同時(shí)按照不同的劃分將結(jié)果發(fā)送給對(duì)應(yīng)的reduce（map的輸出的劃分和reduce的對(duì)應(yīng)關(guān)系由JobTracker確定）。reduce端又會(huì)將各個(gè)map送來的屬于同一個(gè)劃分的輸出進(jìn)行合并蒿涎，然后對(duì)merge的結(jié)果進(jìn)行排序哀托，最后交給reduce處理
map端
map端的shuffle過程包含在collect函數(shù)對(duì)map輸出結(jié)果的處理過程中，
reduce端
reduce端shuffle階段可以分為三個(gè)階段：復(fù)制map輸出劳秋，排序合并仓手，reduce處理
舊API
map方法
map函數(shù)繼承于MapReduceBase,并且實(shí)現(xiàn)了Mapper接口，此接口是一個(gè)泛型類型玻淑，有4個(gè)形式的參數(shù)嗽冒，分別是
- 輸入key值類型
- 輸入value值類型
- 輸出Key值類型
- 輸出value值類型
reduce方法
reduce函數(shù)繼承于MapReduceBase，并且實(shí)現(xiàn)了Reducer接口补履，reduce函數(shù)是以map函數(shù)的輸出作為輸入
新API
- 在新API中添坊，Mapper與Reducer已經(jīng)不是接口 而是抽象類，而且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來完成阳准，不需要額外使用JobConf對(duì)守護(hù)進(jìn)程進(jìn)行配置
- 由Job類來負(fù)責(zé)Job的控制氛堕，而不是JobClient,JobClient在新API中被刪除
數(shù)據(jù)流
數(shù)據(jù)首先按照TextInputFormat形式被處理成兩個(gè)InputSplit,然后輸入到兩個(gè)map中，map程序會(huì)讀取inputSplit指定位置的數(shù)據(jù)野蝇，然后按照設(shè)定的方式處理批數(shù)據(jù)岔擂，最后寫入本地磁盤中。注意浪耘，這里不是寫到hdfs上乱灵，因?yàn)閙ap的輸出在job完成之后即可刪除，因此不需要存儲(chǔ)在hdfs上七冲。但是由于網(wǎng)絡(luò)傳輸降低了mapreduce任務(wù)的執(zhí)行效率痛倚，因此map的輸出文件是寫在磁盤上的，如果map程序在沒有來得及將數(shù)據(jù)傳送到reduce就崩潰了澜躺，那么JobTracker只需要另外選取一臺(tái)機(jī)器重新執(zhí)行這個(gè)task就可以了蝉稳。
Reduce會(huì)讀取map的輸出數(shù)據(jù)，合并Value,然后將他們輸出到hdfs上掘鄙，reduce的輸出會(huì)占用很多的網(wǎng)絡(luò)帶寬耘戚，不過這與上傳數(shù)據(jù)一樣，是不可避免的操漠。
在這收津，需要注意：
- MapReduce在執(zhí)行過程中往往不止一個(gè)reduce task,reduce task的數(shù)量是可以通過程序指定的，當(dāng)存在多個(gè)reduce task時(shí)浊伙，每個(gè)reduce會(huì)收集一個(gè)或者多個(gè)key值撞秋，當(dāng)出現(xiàn)多個(gè)reduce task時(shí)，每個(gè)reducetask都會(huì)生成一個(gè)輸出文件
- 在沒有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)化
- 任務(wù)的調(diào)度
計(jì)算方面舅列，hadoop總是優(yōu)先將任務(wù)分配給空閑的機(jī)器，使得所有的任務(wù)能公平分享資源卧蜓；IO方面帐要，hadoop盡量將Map任務(wù)分配給InputSplit的機(jī)器，減少網(wǎng)絡(luò)IO的消耗 - 數(shù)據(jù)預(yù)處理與InputSplit的大小
MR任務(wù)擅長(zhǎng)處理少量的大數(shù)據(jù)烦却，不擅長(zhǎng)大量的小數(shù)據(jù)宠叼，因此可以通過設(shè)置map的輸入數(shù)據(jù)大小來調(diào)整map運(yùn)行時(shí)間先巴，可以設(shè)置塊block的大小其爵，也可以設(shè)置map任務(wù)的梳理來調(diào)整map任務(wù)的數(shù)據(jù)輸入 - maph和reduce任務(wù)的數(shù)量
- combine函數(shù)
- 壓縮
- 自定義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è)問題
- 新舊API之間的差別
- 如何去重
- 如何排序
- reduce卡死
reduce過程的百分比與對(duì)應(yīng)的處理如下：- 0~33%是shuffle的過程摇幻，數(shù)據(jù)從mapper已到了reducer
- 33~67%是sort的過程横侦，這個(gè)過程只會(huì)在mapper完成后才會(huì)執(zhí)行
- 67~100%才是reducer程序執(zhí)行的過程。如果reduce卡在了67%绰姻，那么說明reducer一個(gè)也沒有執(zhí)行枉侧。可能是輸入數(shù)據(jù)太大狂芋，超過了限制榨馁，也可能是reducer有死循環(huán)的bug
