[hadoop] hadoop之yarm資源調度

YARN

YARN(Yet Another Resource Negotiator)是Hadoop2.0集羣中負責資源管理和調度以及監控運行在它上面的各種應用,是hadoop2.0中的核心,它類似於一個分佈式操作系統,通過它的api編寫的應用可以跑在它上面,支持臨時和常駐的應用,集羣的資源可以得到最大限度的共享。資源是指CPU,內存,硬盤,帶寬等可以量化的東西。

 

YARN 概述 

YARN 是一個資源調度平臺,負責爲運算程序提供服務器運算資源,相當於一個分佈式的操 作系統平臺,而 MapReduce 等運算程序則相當於運行於操作系統之上的應用程序

YARN 是 Hadoop2.x 版本中的一個新特性。它的出現其實是爲了解決第一代 MapReduce 編程 框架的不足,提高集羣環境下的資源利用率,這些資源包括內存,磁盤,網絡,IO等。Hadoop2.X 版本中重新設計的這個 YARN 集羣,具有更好的擴展性,可用性,可靠性,向後兼容性,以 及能支持除 MapReduce 以外的更多分佈式計算程序

  1、YARN 並不清楚用戶提交的程序的運行機制

  2、YARN 只提供運算資源的調度(用戶程序向 YARN 申請資源,YARN 就負責分配資源)

  3、YARN 中的主管角色叫 ResourceManager

  4、YARN 中具體提供運算資源的角色叫 NodeManager

  5、這樣一來,YARN 其實就與運行的用戶程序完全解耦,就意味着 YARN 上可以運行各種類 型的分佈式運算程序(MapReduce 只是其中的一種),比如 MapReduce、Storm 程序,Spark 程序,Tez ……

  6、所以,Spark、Storm 等運算框架都可以整合在 YARN 上運行,只要他們各自的框架中有 符合 YARN 規範的資源請求機制即可

  7、yarn 就成爲一個通用的資源調度平臺,從此,企業中以前存在的各種運算集羣都可以整 合在一個物理集羣上,提高資源利用率,方便數據共享

 

Hadoop1.0和2.0架構對比

  • 1.0的絕對核心是mapreduce,只能跑mapreduce的任務;2.0的絕對核心是YARN,除了可以跑mapreduce,還可以跑其它各種各樣的任務,每個應用向YARN申請資源
  • 1.0的JobTracker和NameNode是單點,一旦掛掉,整個集羣會癱瘓;2.0核心組件不再是單點,基於ZooKeeper實現了HA(RM Hadoop2.4版本及後才支持)
  • 2.0沒有了JobTracker和TaskTracker,增加了ResourceManager,NodeManager,Application Master,Container
  • 2.0資源使用效率更高,資源使用更加彈性靈活
  • 2.0把資源管理以及調度和任務管理以及調度拆開,使得組件功能變得更簡單,程序更加穩定健壯,1.0時都由JobTracker負責
  • 2.0比1.0架構更加複雜了
  • YARN的出現解決了1.0時代設計的缺陷,讓Hadoop集羣功能越來越完善,讓Hadoop集羣越來越穩定

YARN架構設計

YARN 作業執行流程:

    1、用戶向 YARN 中提交應用程序,其中包括 MRAppMaster 程序,啓動 MRAppMaster 的命令, 用戶程序等。

    2、ResourceManager 爲該程序分配第一個 Container,並與對應的 NodeManager 通訊,要求 它在這個 Container 中啓動應用程序 MRAppMaster。

    3、MRAppMaster 首先向 ResourceManager 註冊,這樣用戶可以直接通過 ResourceManager 查看應用程序的運行狀態,然後將爲各個任務申請資源,並監控它的運行狀態,直到運行結束,重複 4 到 7 的步驟。

    4、MRAppMaster 採用輪詢的方式通過 RPC 協議向 ResourceManager 申請和領取資源。

    5、一旦 MRAppMaster 申請到資源後,便與對應的 NodeManager 通訊,要求它啓動任務。

    6、NodeManager 爲任務設置好運行環境(包括環境變量、JAR 包、二進制程序等)後,將 任務啓動命令寫到一個腳本中,並通過運行該腳本啓動任務。

    7、各個任務通過某個 RPC 協議向 MRAppMaster 彙報自己的狀態和進度,以讓 MRAppMaster 隨時掌握各個任務的運行狀態,從而可以在任務敗的時候重新啓動任務。

    8、應用程序運行完成後,MRAppMaster 向 ResourceManager 註銷並關閉自己。

 

RM實現HA


(圖片來源:hadoop官方文檔)

  • 大於等於2.4版本才支持HA
  • RM有2種狀態,提供服務的處於Active狀態,備份的是Standby狀態
  • 通過ZooKeeper協調,實現故障轉移
  • RM有內置ZKFC,只需開啓配置,不需要單獨啓動額外的監控進程
  • RM狀態信息存儲方式:
    1 ZooKeeper
    2 HDFS
    3 本地文件系統,故障轉移需要考慮信息如何同步,人工實現故障轉移

調度策略

  • FIFO Scheduler(先進先出)
    先來的先執行,如果有任務執行時間長,佔用資源多,後面的任務只能等待,即使是執行快,佔用資源少的應用,也必須等待那個耗時耗資源的任務執行完
  • Capacity Scheduler(預先分配資源模式)
    N個任務隊列,每個隊列分配一定資源,每個隊列資源互不共享,每個隊列只有有權限的人或者組織才能使用。
    如果某些任務隊列沒有任務,會造成資源的浪費。相比FIFO模式,任務執行時間會變的更長,因爲耗時耗資源的應用可用
  • 資源更少了。
  • Fair Scheduler(公平調度模式)
    先來的任務先執行,當有新的任務到來時,雖然上一個任務沒有執行完,上一個任務釋放的Container優先分配給這個新任務,當新任務執行完成時,釋放的資源再給上一個任務使用。
    這樣就能達到即不影響耗時的任務又能執行執行新任務的目的。在兼顧公平使用的基礎上,最大化利用集羣的資源。

 

pdf文檔:https://download.csdn.net/download/weixin_40902527/11377551

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章