客戶端即jar 提交到叢集上面，執行jar包main方法，job.submit() 就會生成一個代理物件，yarnrunner 會和resourceManager進行通訊，實則rpc呼叫，申請提交一個application對叢集來說jar程式就相當與application，RM則會返回給其資源提交路徑，hdfs://XXX/staging 資源其實就是job執行所需要的一些配置檔案如job.split通過inputformat.etSplit()獲得切片規劃，job.xml jar 包

RM返回給其資源提交的路徑以及job的ID號,staging+jobId構成一個job的唯一資源提交路徑，將job.split job.xml jar包提交到此路徑上面去，

job資源提交完畢，RM將其分裝為一個task，

RM可能會處理多個task，所以需要資源排程，其主要有三種方式

fair 公平每個資源分配資源想等

FIFO佇列先進先出，RM可以接收，但其後執行的task需等待

capacity  第一關task資源全部都給它，隨著task的執行，慢慢的回收

nodemanager 和ResourceManager保持著心跳，隨機拿到resourceManager封裝的task去執行

NM接收到task任務後根據task描述建立container容器來執行mr程式，container包含虛擬cpu 記憶體等

然後把task所需要的資原始檔即前面放到資源路徑中的檔案 cp 到container中

然後container開始正式執行，首先第一個container會執行mrappmaster  每個請求對應一個不同的mrappmaster

為了協調map和reduce

mrappmaster會讀取job.split等資源路徑，會知道多少個map reduce 輸入出路徑等

現在mrappmaster又相當與一個客戶端去請求RM執行任務，分配資源容器，其實容器就是程序mrappmaster又重新申請的叫做yarnchild

mrappmaster向yarnchild傳送程式啟動命令，實際是java -cp xxxx,

yarnchild 然後執行maptask 由mrappmaster監管，是否成功，執行進度等，若失敗或執行很慢，則會重新申請一個yarnchild來執行，看哪個先進行完，就用哪個結果

等maptask執行結束 mrappmaster 就會向RM申請container  yarnchild來執行reducetask

等maptask執行結束其所佔資源會被mrappmaster回收，等reducetask等都執行結束，mrappmaster會想RM申請回收登出自己

yarn：只負責程式執行所需資源回收排程等排程任務，與應用程式的執行機制完全無關，成為一個通用資源排程平臺，mr/spark/storm/flink

而hadoop1.0中

jobtracker tasktracker

客戶端 向jobtracker 請求 jobtrasker將map reduce任務資源排程耦合在一起，而1.0中提交的任務都歸jobtracker，1資源排程  2應用的運算流程管理監控，壓力大，