前言
雖然mapreduce幾乎已經被淘汰，但是他的原理機制還是需要去了解深挖的，他的分而治之的理念差不多是貫通整個大資料的架構的，spark，flink都借鑒了其分而治之的理念，下面是我總結的mapReduce的模型，結構，以及原理。寫的不好，請見諒！！！雖然mapreduce幾乎已經被淘汰，但是他的原理機制還是需要去了解深挖的，他的分而治之的理念差不多是貫通整個大資料的架構的，spark，flink都借鑒了其分而治之的理念，下面是我總結的mapReduce的模型，結構，以及原理。寫的不好，請見諒！！！
Mapreduce1.0
Client：編寫mapreduce程式，配置作業，送出作業，這就是程式員完成的工作；
JobTracker：JobTracker隻有一個，一般情況應該把JobTracker部署在單獨的機器上,類似于namenode，每個應用程式被表示成一個作業，每個作業又被分成多個任務，JobTracker的作業控制子產品則負責作業的分解和狀态監控,簡單來說：jobTracker管理折map，reduce搜友任務的啟動，以及所有資源的調配。
TaskTracker：TaskTracker是運作在多個節點上的slaver服務。TaskTracker主動與JobTracker通信，接收作業，并負責直接執行每一個任務。本地節點上各個任務的狀态通過心跳周期性彙報給JobTracker，節點健康情況、資源使用情況，任務執行進度、任務運作狀态等，比如說map task我做完啦，你什麼時候讓reduce task過來拉資料啊。從JobTracker接收并執行各種指令：運作任務、送出任務、殺死任務等
總體步驟
- input：也就是資料存儲位置，這裡當然是類似于hdfs這樣的分布式存儲啦，
- split：因為maptask隻讀split，而split基本上和hdfs的基本存儲塊block同樣大小，一個split對應一個map，你可以把它當做map的機關塊來了解，投喂進map的時候必須要這樣的格式。
- List itemmap：這裡做的是wordcount，而map程式是由程式原來編寫的。
- shuffle：這是一個比較核心的過程，shuffle有洗牌的意思。
-
List itemreduce：既然都說了似wordcount了。
細化過程
mapTask讀取inputSplit的資料，通過map接口，讀入的資料為key為在行在這個檔案中的offset，value為行資料，通過map接口轉換為key為資料，value為你的需求格式的資料，此時資料寫入記憶體區，當記憶體區資料量過大，此時通過溢寫，資料寫入磁盤，此時會通過key mod/reduce個數，分出不同的partition，每個分片還會進行排序以combiner（小規模的歸并資料），當map執行完成，這時候進行一個大規模的歸并，相同位置的partition進行歸并，送出reduce作業，最後輸出作業
Map階段：
輸入資料的解析：InputFormat
輸入資料處理：Mapper
輸入分組：Partitioner
本節點的規約：Combiner
Reduce階段：
Shuffling階段拉取資料
桶排序，是一個hash過程，使得相同的Key可以排在一堆
資料規約：Reducer
資料輸出格式： OutputFormat
資料本地化
map操作都是本地化操作也就是在資料存儲節點上進行，将map任務配置設定給含有該map處理的資料塊的TaskTracker，其實就是任務運作在他将處理資料所在的節點上。其實發展到現在，記憶體已經足夠大，cpu計算能力也很強，真正的瓶頸是磁盤io，網絡io。同節點>同機架>其他 ，資料本地化可避免跨界點以及跨機架的資料傳輸，送出運作效率。
memory Buffer ：這是一個環形的緩沖區。map task輸出結果首先會進入一個緩沖區内，這個緩沖區的大小是100MB，如果map task内容太大，是很容易撐爆記憶體的，是以會有一個守護程序，每當緩沖區到達上限80%的時候，就會啟動一個Spill(溢寫)程序，它的作用是把記憶體裡的map task的結果寫入到磁盤。這裡值得注意的是，溢寫程式是單獨的一個程序，不會影響map task的繼續輸出。當溢寫線程啟動後，需要對這80MB空間内的key做排序(Sort)。排序是MapReduce模型預設的行為，這裡的排序也是對序列化的位元組做的排序。
**partition：**partition是分割map每個節點的結果，按照key分别映射給不同的reduce，也是可以自定義的。這裡其實可以了解歸類。隻不過在寫程式的時候，mapreduce使用哈希HashPartitioner幫我們歸類了。預設是hash(key)%R哈希函數分散到各個reducer去
Combiner：如果client設定過Combiner，那麼現在就是使用Combiner的時候了。将有相同key的key/value對的value加起來，減少溢寫到磁盤的資料量，combiner簡單說就是map端的reduce！。Combiner的輸出是Reducer的輸入，Combiner絕不能改變最終的計算結果。Combiner的使用一定得慎重，如果用好，它對job執行效率有幫助，反之會影響reduce的最終結果。
Merge：每次溢寫會在磁盤上生成一個溢寫檔案，如果map的輸出結果真的很大，有多次這樣的溢寫發生，磁盤上相應的就會有多個溢寫檔案存在。當map task真正完成時，記憶體緩沖區中的資料也全部溢寫到磁盤中形成一個溢寫檔案。最終磁盤中會至少有一個這樣的溢寫檔案存在(如果map的輸出結果很少，當map執行完成時，隻會産生一個溢寫檔案)，因為最終的檔案隻有一個，是以需要将這些溢寫檔案歸并到一起。
Copy過程: Reduce會接收到不同map任務傳來的資料，并且每個map傳來的資料都是有序的。Reduce程序啟動一些資料copy線程(Fetcher)，通過HTTP方式請求map task所在的TaskTracker擷取map task的輸出檔案。因為map task早已結束，這些檔案就歸TaskTracker管理在本地磁盤中。
Merge: 這裡的merge如map端的merge動作，隻是數組中存放的是不同map端copy來的數值。Copy過來的資料會先放入記憶體緩沖區中，這裡的緩沖區大小要比map端的更為靈活，它基于JVM的heap size設定，因為Shuffle階段Reducer不運作，是以應該把絕大部分的記憶體都給Shuffle用。這裡需要強調的是，merge有三種形式：1)記憶體到記憶體 2)記憶體到磁盤 3)磁盤到磁盤。預設情況下第一種形式不啟用，讓人比較困惑，是吧。當記憶體中的資料量到達一定門檻值，就啟動記憶體到磁盤的merge。與map 端類似，這也是溢寫的過程，這個過程中如果你設定有Combiner，也是會啟用的，然後在磁盤中生成了衆多的溢寫檔案。第二種merge方式一直在運作，直到沒有map端的資料時才結束，然後啟動第三種磁盤到磁盤的merge方式生成最終的那個檔案。
Reducer的輸入檔案：不斷地merge後，最後會生成一個“最終檔案”。為什麼加引号？因為這個檔案可能存在于磁盤上，也可能存在于記憶體中。對我們來說，當然希望它存放于記憶體中，直接作為Reducer的輸入，但預設情況下，這個檔案是存放于磁盤中的。當Reducer的輸入檔案已定，整個Shuffle才最終結束。
MapReduce2.0運作在YARN之上。YARN
Client ：使用者通過Client與YARN互動，送出MapReduce作業，查詢作業運作狀态，管理作業等
MRAppMaster ：功能類似于 1.0中的JobTracker，但不負責資源管理，任務劃分、資源申請并将之二次配置設定給Map Task和Reduce Task、任務狀态監控和容錯，注意這裡涉及對RM的兩次資源申請，第一次申請是用于啟動一個MRAppMaster，來管理這次MR Task, 第二次申請用于申請Map Task和Reduce Task需要的資源（每申請成功一個都會啟動一個）
執行流程：Client向ResourceManager送出一個mr作業，ResourceManager會找一個空閑的機器（NodeManager）用來啟動MRAppMaster，MRAppMaster會ResourceManager請求資源，擷取到資源，聯系NodeManager啟動mapTask任務。
反向索引：在搜尋引擎中每個檔案都對應一個檔案ID，檔案内容被表示為一系列關鍵詞的集合（實際上在搜尋引擎索引庫中，關鍵詞也已經轉換為關鍵詞ID）。例如“文檔1”經過分詞，提取了20個關鍵詞，每個關鍵詞都會記錄它在文檔中的出現次數和出現位置。
當使用者在首頁上搜尋關鍵詞“華為手機”時，假設隻存在正向索引（forward index），那麼就需要掃描索引庫中的所有文檔，找出所有包含關鍵詞“華為手機”的文檔，再根據打分模型進行打分，排出名次後呈現給使用者。因為網際網路上收錄在搜尋引擎中的文檔的數目是個天文數字，這樣的索引結構根本無法滿足實時傳回排名結果的要求。
是以，搜尋引擎會将正向索引重新建構為反向索引，即把檔案ID對應到關鍵詞的映射轉換為關鍵詞到檔案ID的映射，每個關鍵詞都對應着一系列的檔案，這些檔案中都出現這個關鍵詞。
https://blog.csdn.net/zsd_31/article/details/79979818
面試問題收集
https://blog.csdn.net/WYpersist/article/details/80102778