一、hadoop概念
Hadoop由兩部分組成，一是負責存儲與管理文件的分佈式文件系統HDFS、二是負責處理與計算的MapReduce的計算框架。
二、HDFS
1.namenode
負責管理工作(管理文件系統的目錄結構,元數據信息,響應用戶請求)
包含了兩個核心的數據結構，FsImage和EditLog。
FsImage:用於維護整個文件系統數以及文件樹中所有的文件和文件夾的元數據
EditLog:記錄了所有針對文件的創建,刪除,重命名等操作
2.Seconday NameNode
爲主namenode內存中的文件系統元數據,創建檢查點,在文件系統中設置一個檢查點來幫助NameNode更好的工作,不是取代掉NameNode,也不是備份SecondayName有兩個作用
一是鏡像備份,二是日誌與鏡像的定期合併。兩個同時進行稱爲checkpoint。
鏡像備份的作用：備份fsImage
合併作用:防止如果NameNode節點故障,namenode下次啓動時,會把fsImage加載到內存中,應用editLog,EditLog往往很大,可以減少重啓時間,同時保證HDFS系統的完整性。
3.dataname
以塊的形式進行存儲數據
在HDFS中,我們真實的數據是由DataNode來負責來存儲的，但是數據具體被存儲到了哪個DataNode節點等元數據信息則是由我們的NameNode來存儲的。
image.png
三、mapreduce
- mapreduce概念
*將複雜運行與大規模集羣上的並行運算的過程高度抽象到兩個函數：map和reduce
*採用"分而治之"策略,一個存儲在分佈式文件系統中的大規模數據集,會被切分成許多獨立分片,這些可以被多個map任務執行。
map(映射):將小數據集解析成一批<key,value>
reduce(遞歸):將所有相同Key的value合併起來
2.mapreduced的結構體系
主從式的結構,JobTrack只有一個,TaskTracker有很多個
image.png
JobTracker的職責
1.負責接受用戶提交給的任務
2.將計算任務分配給TaskTracker
3.跟蹤監控TaskTracker的任務和task的執行狀況
TaskTracker的職責
執行JobTracker分配給的計算任務task。
3.mapreduce的 input split
image.png
hdfs以固定大小的block爲基本單位存儲數據,而對於MR而言,集中處理單位split,輸入分片（input split）存儲的並非數據本身，而是一個分片長度和一個記錄數據的位置的數組。大多數情況下,理想的分片大小是一個hdfs塊。
4.shuffle過程
shuffle過程
image.png
image.png
1.map端shuffle
map端shuffle
①寫入環形內存緩衝區
因爲頻繁的磁盤I/O操作會嚴重的降低效率，因此“中間結果”不會立馬寫入磁盤，而是優先存儲到map節點的“環形內存緩衝區”，並做一些預排序以提高效率，當寫入的數據量達到預先設置的闕值後便會執行一次I/O操作將數據寫入到磁盤。每個map任務都會分配一個環形內存緩衝區，用於存儲map任務輸出的鍵值對（默認大小100MB，mapreduce.task.io.sort.mb調整）以及對應的partition，被緩衝的（key,value）對已經被序列化（爲了寫入磁盤）。
②緩存達到閾值，溢寫到磁盤文件 溢寫前會進行分區，分區內排序和合並（可選）
2.1分區partition
在將map()函數後得到的(key,value)對寫入到緩衝區之間,需要進行分區,這樣能把map任務處理結果發送給指定的reducer去執行,從而達到負載均衡,避免數據傾斜MapReduce提供默認的分區類（HashPartitioner）
public class HashPartitioner<K, V> extends Partitioner<K, V> {
/** Use {@link Object#hashCode()} to partition. */
public int getPartition(K key, V value,
int numReduceTasks) {
return (key.hashCode() & Integer.MAX_VALUE) % numReduceTasks;
}
}
getPartition()方法有三個參數，前兩個指的是mapper任務輸出的鍵值對，而第三個參數指的是設置的reduce任務的數量，默認值爲1。因爲任何整數與1相除的餘數肯定是0。也就是說默認的getPartition()方法的返回值總是0，也就是Mapper任務的輸出默認總是送給同一個Reducer任務，最終只能輸出到一個文件中。如果想要讓mapper輸出的結果給多個reducer處理，那麼只需要寫一個類，讓其繼承Partitioner類，並重寫getPartition()方法，讓其針對不同情況返回不同數值即可。並在最後通過job設置指定分區類和reducer任務數量即可。
2.2分區內排序
旦緩衝區內容達到閾值（mapreduce.map.io.sort.spill.percent,默認0.80，或者80%），就會會鎖定這80%的內存，並在每個分區中對其中的鍵值對按鍵進行sort排序，具體是將數據按照partition和key兩個關鍵字進行排序，排序結果爲緩衝區內的數據按照partition爲單位聚集在一起，同一個partition內的數據按照key有序。排序完成後會創建一個溢出寫文件（臨時文件），然後開啓一個後臺線程把這部分數據以一個臨時文件的方式溢出寫（spill）到本地磁盤中
2.3合併（可選）
如果客戶端自定義了Combiner（相當於map階段的reduce），則會在分區排序後到溢寫出前自動調用combiner，將相同的key的value相加，這樣的好處就是減少溢寫到磁盤的數據量。這個過程叫“合併”
④歸併merge
當一個map task處理的數據很大，以至於超過緩衝區內存時，就會生成多個spill文件。此時就需要對同一個map任務產生的多個spill文件進行歸併生成最終的一個已分區且已排序的大文件。配置屬性mapreduce.task.io.sort.factor控制着一次最多能合併多少流，默認值是10。這個過程包括排序和合並（可選），歸併得到的文件內鍵值對有可能擁有相同的key，這個過程如果client設置過Combiner，也會合並相同的key值的鍵值對（根據上面提到的combine的調用時機可知）。
溢出寫文件歸併完畢後，Map將刪除所有的臨時溢出寫文件，並告知NodeManager任務已完成，只要其中一個MapTask完成，ReduceTask就開始複製它的輸出（Copy階段分區輸出文件通過http的方式提供給reducer）
map shuffle一些特點
1.每個Map任務分配一個緩存
2.MapReduce默認100MB緩存
3.設置溢寫比例0.8
4.分區默認採用哈希函數
5.排序是默認的操作
6.排序後可以合併（Combine）
7.合併不能改變最終結果
8.在Map任務全部結束之前進行歸併
9.歸併得到一個大的文件，放在本地磁盤
10.文件歸併時，如果溢寫文件數量大於預定值（默認是3）則可以再次啓動Combiner，少於3不需要
合併（Combine）和歸併（Merge）的區別：
兩個鍵值對<“a”,1>和<“a”,1>，如果合併，會得到<“a”,2>，如果歸併，會得到<“a”,<1,1>>
3.Reduce端的Shuffle過程
image.png
①領取數據
Map端的shuffle過程結束後，結果會保存在本地磁盤中，Reduce任務只需要把這些數據領取（Fetch）回來首先存放到緩存當中
②歸併數據
如果緩存到一定閾值，就會像發生溢寫操作,當溢寫程序啓動時，具有相同key的鍵值對會被歸併，如果用戶定義了combiner，則歸併後還可以執行combiner，減少寫入磁盤的數據量，每個溢寫過程結束後，都會在磁盤生成一個溢寫文件，當溢寫文件過多時也會像Map一樣被歸併成一個大文件，歸併是也會進行排序，當數據很少時，寫入緩存就行，不需要溢寫到磁盤，而是直接在內存中執行歸併操作，直接輸出給Reduce任務
面試寶典之mapreduce的shuffle過程
首先shuffle是貫徹整個mapreduce過程,可以分爲2部分,map端的shuffle和reduce端的shuffle。map端shuffle,map任務執行後的中間結果”不會立馬寫入磁盤，而是優先存儲到map節點的“環形內存緩衝區”(默認100MB)，當內存緩存區達到一定閾值(默認0.8)就會進行溢寫到磁盤文件,溢寫之前會先進行分區,然後分區內的排序,如果客戶端自定義了Combiner，還會進行合併操作。最後如果有多個溢寫文件。會對這個多個溢寫文件進行歸併生成最終的一個已分區且已排序的大文件。reduce端shuffle先領取不同節點map任務執行結束數據存儲到緩存區,當緩存區到達一定閾值,就是發生溢寫操作,溢寫之前具有相同key的鍵值對會被歸併,如果客戶端定義combiner，歸併後還可以執行combiner(合併),但溢寫文件過多,也會歸併成一個大文件。輸出給Reduce任務，整個shuffle才最終結束。
四、hadoop 2.0新特性
1.針對1.0中NameNode的單點故障問題，在2.0中引入了新的HA機制：即如果Active的NameNode節點掛掉，處於Standby的NameNode節點將替換掉它繼續工作
2.引入yarn資源管理
yarn資源管理
Yarn是Hadoop2.0中的資源管理系統，它的基本設計思想是將MR1.0中的JobTracker拆分成兩個獨立的服務：一個是全局的資源管理器ResouceManager和每個應用程序特有的AppMaster。
在Yarn平臺中，各個組件的詳細功能如下：
1.ResouceManager
是一個全局的資源管理器，負責整個系統的資源管理和分配，ResouceManager相當於Hadoop1.0中的JobTracker的部分職能：資源分配。
2.AppMaster
負責管理單個應用程序，即負責一個Job生命週期內的所有工作，監控整個任務的執行，跟蹤整個任務的狀態，處理任務失敗以異常情況。AppMaster類似老的框架中的JobTracker的部分職能：任務分配與任務監控。特別注意：每一個Job（而不是每一種）都有一個相應的APPMaster，APPMaster可以運行在除主節點ResouceManager節點以外的其它機器上，但是在Hadoop1.0中，JobTracker的位置是固定的。
3.NodeManager
NodeManager 是 YARN 集羣當中真正資源的提供者，是真正執行應用程序的容器的提供者， 監控應用程序的資源使用情況（CPU，內存，硬盤，網絡），並通過心跳向集羣資源調度器 ResourceManager 進行彙報以更新自己的健康狀態。同時其也會監督 Container 的生命週期 管理，監控每個 Container 的資源使用（內存、CPU 等）情況，追蹤節點健康狀況，管理日誌和不同應用程序用到的附屬服務（auxiliary service）。
YARN 作業執行流程
YARN 作業執行流程
1>首先，用戶的應用程序通過Yarn平臺的客戶端程序將我們的應用程序提交給我們的YARN平臺
2>YARN平臺的ResouceManager接受到我們客戶端提交給的應用程序後，將應用程序交給某個NodeManager，並在其上面啓動一個新的進程AppMaster
3>AppMaster首先爲應用程序在ResouceManager中進行註冊，這樣用戶可以通過ResouceManager查看應用程序的執行進度
4>註冊完之後，APPMaster將通過Rpc協議向ResouceManager申請資源並領取相應的資源
5>獲取到資源後，APPMaster便於對應的NodeManager節點進行通信，要求其啓動相應的任務
6>各個任務在執行的過程中將通過RPC協議向APPMaster彙報自己的執行進度和執行狀況，以便讓APPMaster可以隨時掌握各個任務的執行狀況，進而在任務運行失敗時可以重新啓動相應的任務。
7>mapper任務和reducer任務執行完之後，AppMaster向ResouceManager節點註銷並關閉自己，此時資源得到回收，應用程序執行完畢。
作者：有一束陽光叫溫暖
鏈接：https://www.jianshu.com/p/ad9b9e2ecd25
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。