HADOOP 1.0存在的問題
HDFS1.0存在的問題：
Namenode單點故障：集群的文件都是以“塊(block)”的形式存儲，並且為了容錯，每個block有多個副本。namenode需要記錄整個集群所有block及其副本的元數據信息（fsimage：文件目錄結構，block和文件的映射關系等）和操作日志（edits），因此，在hadoop1.0框架中，namenode設計為單個節點，通常部署在一台性能強勁的計算機上，客戶端上傳的所有文件，都要先與namenode進行交互，由namenode管理。這樣，namenode的可用性決定整個集群的存儲系統的可用性。
Namenode壓力過大，內存受限： 在集群啟動時，namenode需要將集群所有block的元數據信息加載到內存，這樣，當文件越來越多時，namenode的內存壓力也會遇到瓶頸。
MapReduce1.0存在的問題：
JobTracker單點故障：MapReduce作為hadoop的計算框架，其作業的調度和資源分配是通過JobTracker完成。但是，因為資源管理是全局性的，因此，JobTracker仍然是單個節點，通常部署在一台性能強勁的計算機上。一旦該節點失敗，整個集群的作業就全部失敗。
不支持MapReduce之外的其它計算框架：hadoop1.0僅能支持MapReduce計算框架，隨着人們對實時性的要求，spark、storm等計算框架也應運而出，但是hadoop1.0並不能良好地支持。
JobTracker訪問壓力大，影響系統擴展性：在hadoop1.0中，JobTracker負責所有作業的調度、各個作業的生命周期、各個作業中所有task的跟蹤和失敗重啟等。因此，當集群中作業很多時，所有作業的map task和reduce task都要與JobTracker進行交互
為解決hadoop1.0中JobTracker單點故障問題，hadoop2.0開始將Hadoop 1.0中的JobTracker的集群資源分配和作業調度分為兩個守護進程來控制，分別是Global Resource Manager(以下簡稱RM)和每個Application的ApplicationMaster(以下簡稱AM)，這也是YARN最重要的兩個組件。
HADOOP 2.X YARN實現
流程圖
步驟：
1、Client向RM發出請求
2、RM返回一個ApplicationID作為回應
3、Client向RM回應Application Submission Context（ASC）。ASC包括ApplicationID、user、queue，以及其他一些啟動AM相關的信息，除此之外，還有一個Container Launch Context（CLC），CLC包含了資源請求數（內存與CPU），job files，安全token，以及其他一些用以在一個node上啟動AM的信息。任務一旦提交以后，client可以請求RM去殺死應用或查詢應用的運行狀態
4、當RM接受到ASC后，它會調度一個合適的container來啟動AM，這個container經常被稱作為container 0。AM需要請求其他的container來運行任務，如果沒有合適的container，AM就不能啟動。當有合適的container時，RM發請求到合適的NM上，來啟動AM。這時候，AM的PRC與監控的URL就已經建立了。
5、當AM啟動起來后，RM回應給AM集群的最小與最大資源等信息。這時AM必須決定如何使用那么當前可用的資源。YARN不像那些請求固定資源的scheduler，它能夠根據集群的當前狀態動態調整。
6、AM根據從RM那里得知的可使用的資源，它會請求一些一定數目的container。
7、RM將會根據調度策略，盡可能的滿足AM申請的container。然后AM會將任務跑在container上，並監控和管理作業狀態。當任務完成之后，AM會通知RM釋放container資源。
功能
Resource Manager
處理客戶端請求
啟動/監控ApplicationMaster
監控NodeManager
資源分配與調度
Node Manager
單個節點上的資源管理和任務管理
處理來自ResourceManager的命令
處理來自ApplicationMaster的命令
ApplicationMaster
數據切分
為應用程序申請資源，進一步分配給內部任務
任務監控和容錯
Container
任務運行資源(節點，cpu，內存)
任務啟動命令
任務運行環境
Spark on yarn
原理圖
步驟
1、Spark Yarn Client 向 Yarn 中提交應用程序。
2、ResourceManager 收到請求后，在集群中選擇一個 NodeManager，並為該應用程序分配一個 Container，在這個 Container 中啟動應用程序的 ApplicationMaster， ApplicationMaster 進行 SparkContext 等的初始化。
3、ApplicationMaster 向 ResourceManager 注冊，這樣用戶可以直接通過 ResourceManager 查看應用程序的運行狀態，然后它將采用輪詢的方式通過RPC協議為各個任務申請資源，並監控它們的運行狀態直到運行結束。
4、ApplicationMaster 申請到資源（也就是Container）后，便與對應的 NodeManager 通信，並在獲得的 Container 中啟動 CoarseGrainedExecutorBackend，啟動后會向 ApplicationMaster 中的 SparkContext 注冊並申請 Task。
5、ApplicationMaster 中的 SparkContext 分配 Task 給 CoarseGrainedExecutorBackend 執行，CoarseGrainedExecutorBackend 運行 Task 並向ApplicationMaster 匯報運行的狀態和進度，以讓 ApplicationMaster 隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啟動任務。
6、應用程序運行完成后，ApplicationMaster 向 ResourceManager申請注銷並關閉自己。
————————————————
版權聲明：本文為CSDN博主「spark大數據玩家」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_23160237/article/details/86416185