Yarn（二） 詳解

原創 安卓学吧 2020-02-21 03:27

一. Yarn架構

1.1 簡介

1.1.1 架構

yarn

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等幾個組件構成。

YARN總體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager爲Master，NodeManager爲Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啓動可以佔用一定資源的任務。由於不同的ApplicationMaster被分佈到不同的節點上，因此它們之間不會相互影響。

1.1.2 Job提交流程

流程

  1. 用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啓動ApplicationMaster的命令、用戶程序等。
  2. ResourceManager爲該應用程序分配第一個Container，並與對應的Node-Manager通信，要求它在這個Container中啓動應用程序的ApplicationMaster。
  3. ApplicationMaster首先向ResourceManager註冊，這樣用戶可以直接通過ResourceManager查看應用程序的運行狀態，然後它將爲各個任務申請資源，並監控它的運行狀態，直到運行結束，即重複步驟4~7。
  4. ApplicationMaster採用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。
  5. 一旦ApplicationMaster申請到資源後，便與對應的NodeManager通信，要求它啓動任務。
  6. NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並通過運行該腳本啓動任務。
  7. 各個任務通過RPC協議向ApplicationMaster彙報自己的狀態和進度，以便讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啓動任務。在應用程序運行過程中，用戶可隨時通過RPC向ApplicationMaster查詢應用程序的當前運行狀態。
  8. 應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉自己。

1.2 組件介紹

1.2.1 ResourceManager（RM）

RM 是一個全局的資源管理器,負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器(Scheduler)和應用程序管理器(Applications Manager)。

調度器（Scheduler）

調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。 
需要注意的是，該調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啓動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器。

在Yarn中有三種調度器可以選擇：FIFO Scheduler ，Capacity Scheduler，Fair Scheduler。

  1. FIFO Scheduler

    FIFO Scheduler把應用按提交的順序排成一個隊列，這是一個先進先出隊列，在進行資源分配的時候，先給隊列中最頭上的應用進行分配資源，待最頭上的應用需求滿足後再給下一個分配，以此類推。

  2. Capacity Scheduler

    Capacity 調度器允許多個組織共享整個集羣，每個組織可以獲得集羣的一部分計算能力。通過爲每個組織分配專門的隊列，然後再爲每個隊列分配一定的集羣資源，這樣整個集羣就可以通過設置多個隊列的方式給多個組織提供服務了。除此之外，隊列內部又可以垂直劃分，這樣一個組織內部的多個成員就可以共享這個隊列資源了，在一個隊列內部，資源的調度是採用的是先進先出(FIFO)策略。

    在正常的操作中，Capacity調度器不會強制釋放Container，當一個隊列資源不夠用時，這個隊列只能獲得其它隊列釋放後的Container資源。當然，我們可以爲隊列設置一個最大資源使用量，以免這個隊列過多的佔用空閒資源，導致其它隊列無法使用這些空閒資源，這就是”彈性隊列”需要權衡的地方。

    配置方法：

    Capacity調度器的配置文件，文件名爲capacity-scheduler.xml

    # 例如以下隊列
root
├── prod 40%
└── dev 60% ~ 75%
  ├── eng 50%
  └── science 50%

    上面隊列配置如下：

    <?xml version="1.0"?>
<configuration>
    <!-- 定義了兩個子隊列prod和dev -->
    <property>
        <name>yarn.scheduler.capacity.root.queues</name>
        <value>prod, dev</value>
    </property>

    <!-- dev隊列又被分成了eng和science -->
    <property>
        <name>yarn.scheduler.capacity.root.dev.queues</name>
        <value>eng, science</value>
    </property>

    <!-- 隊列prod佔40%的容量 -->
    <property>
        <name>yarn.scheduler.capacity.root.prod.capacity</name>
        <value>40</value>
    </property>

    <!-- 隊列dev佔60%的容量 -->
    <property>
        <name>yarn.scheduler.capacity.root.dev.capacity</name>
        <value>60</value>
    </property>

    <!-- 限制dev的最大資源伸縮比重爲75%，所以即使prod隊列完全空閒dev也不會佔用全部集羣資源 -->
    <property>
        <name>yarn.scheduler.capacity.root.dev.maximum-capacity</name>
        <value>75</value>
    </property>

    <!-- 隊列eng佔50%的容量，由於沒有設置最大值，所以可能佔用整個父隊列的資源 -->
    <property>
        <name>yarn.scheduler.capacity.root.dev.eng.capacity</name>
        <value>50</value>
    </property>

    <!-- 隊列science佔50%的容量，由於沒有設置最大值，所以可能佔用整個父隊列的資源 -->
    <property>
        <name>yarn.scheduler.capacity.root.dev.science.capacity</name>
        <value>50</value>
    </property>
</configuration>

    Capacity容器除了可以配置隊列及其容量外，我們還可以配置一個用戶或應用可以分配的最大資源數量、可以同時運行多少應用、隊列的ACL認證等。

    在MapReduce中，我們可以通過mapreduce.job.queuename屬性指定要用的隊列。如果隊列不存在，我們在提交任務時就會收到錯誤。如果我們沒有定義任何隊列，所有的應用將會放在一個default隊列中。

    注意：對於Capacity調度器，我們的隊列名必須是隊列樹中的最後一部分，如果我們使用隊列樹則不會被識別。即不能寫成dev.eng，應該寫爲eng。

  3. Fair Scheduler

    Fair調度器的設計目標是爲所有的應用分配公平的資源（對公平的定義可以通過參數來設置）。舉個例子，假設有兩個用戶A和B，他們分別擁有一個隊列。當A啓動一個job而B沒有任務時，A會獲得全部集羣資源；當B啓動一個job後，A的job會繼續運行，不過一會兒之後兩個任務會各自獲得一半的集羣資源。如果此時B再啓動第二個job並且其它job還在運行，則它將會和B的第一個job共享B這個隊列的資源，也就是B的兩個job會用於四分之一的集羣資源，而A的job仍然用於集羣一半的資源，結果就是資源最終在兩個用戶之間平等的共享。

    # 啓用Fair調度器
# yarn-site.xml中配置
<property>
    <name>yarn.resourcemanager.scheduler.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

# 隊列的配置
# 配置文件爲fair-scheduler.xml
# 可以通過下面配置修改配置文件路徑（yarn-site.xml中）

<property>
    <name>yarn.scheduler.fair.allocation.file</name>
    <value>xxxxx</value>
</property>

# fair-scheduler.xml配置例
<?xml version="1.0"?>
<allocations>
    <!-- 默認調度策略，如果沒有配置這項，默認fair -->
    <defaultQueueSchedulingPolicy>fair</defaultQueueSchedulingPolicy>

    <queue name="prod">
        <!-- 權重，如果沒有配置默認爲1 -->
        <weight>40</weight>
        <schedulingPolicy>fifo</schedulingPolicy>
    </queue>

    <queue name="dev">
        <weight>60</weight>
        <queue name="eng"/>
        <queue name="science"/>
    </queue>

    <!--
    queuePlacementPolicy元素定義規則列表，會逐個嘗試直到匹配成功。
    第一個規則specified，則會把應用放到它指定的隊列中，若這個應用沒有指定隊列或隊列名不存在，則不匹配這個規則；
    primaryGroup規則會嘗試把應用以用戶所在的Unix組名命名的隊列中，如果沒有這個隊列，不創建隊列轉而嘗試下一個；
    當前面所有規則不滿足時，則觸發default規則，把應用放在dev.eng隊列中
    -->
    <queuePlacementPolicy>
        <rule name="specified" create="false"/>
        <rule name="primaryGroup" create="false"/>
        <rule name="default" create="dev.eng"/>
    </queuePlacementPolicy>
</allocations>

    搶佔（Preemption）

    當一個job提交到一個繁忙集羣中的空隊列時，job並不會馬上執行，而是阻塞直到正在運行的job釋放系統資源。爲了使提交job的執行時間更具預測性（可以設置等待的超時時間），Fair調度器支持搶佔。

    yarn.scheduler.fair.preemption=true啓動搶佔，如果隊列在minimum share preemption timeout指定的時間內未獲得最小的資源保障，調度器就會搶佔containers。頂級元素爲所有隊列配置這個超時時間；還可以在元素內配置元素來爲某個隊列指定超時時間。

    與之類似，如果隊列在fair share preemption timeout指定時間內未獲得平等的資源的一半（這個比例可以配置），調度器則會進行搶佔containers。這個超時時間可以通過頂級元素和元素級元素分別配置所有隊列和某個隊列的超時時間。上面提到的比例可以通過(配置所有隊列)和(配置某個隊列)進行配置，默認是0.5。

應用程序管理器（Applications Manager）

應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啓動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啓動它等。

1.2.2 NodeManager（NM）

NodeManager替代了Hadoop v1版本中的TaskTracker，每個節點都會有一個NM，主要功能有：

  1. 爲應用程序啓動容器，同時確保申請的容器使用的資源不會超過節點上的總資源。
  2. 爲task構建容器環境，包括二進制可執行文件，jars等。
  3. 爲所在的節點提供了一個管理本地存儲資源的簡單服務，應用程序可以繼續使用本地存儲資源即使他沒有從RM那申請。比如：MapReduce可以使用該服務程序存儲map task的中間輸出結果。

一個NodeManager上面可以運行多個Container，Container之間的資源互相隔離，類似於虛擬機的多個系統一樣，各自使用自己分配的資源。NodeManager會啓動一個監控進行用來對運行在它上面的Container進行監控，當某個Container佔用的資源超過約定的閾值後，NodeManager就會將其殺死。

1.2.3 ApplicationMaster（AM）

ApplicationMaster 負責管理應用程序的整個生命週期，每個應用程序都對應一個AM，主要功能有：

  1. 與RM的調度器通訊，協商管理資源分配（用Container表示）。
  2. 與NM合作，在合適的容器中運行對應的task，並監控這些task執行。
  3. 如果container出現故障，AM會重新向調度器申請資源。
  4. 計算應用程序所需的資源量，並轉化成調度器可識別的協議。
  5. AM出現故障後，ASM會重啓它，而由AM自己從之前保存的應用程序執行狀態中恢復應用程序。

1.2.4 Container

Container可以說是一個對Application使用資源描述的集合(或容器)，可以看做一個可序列化的java對象，封裝了一些描述信息。

Container的一些基本概念和工作流程如下：

  1. Container是YARN中資源的抽象，它封裝了某個節點上一定量的資源（CPU和內存兩類資源）。它跟Linux Container沒有任何關係，僅僅是YARN提出的一個概念（從實現上看，可看做一個可序列化/反序列化的Java類）。
  2. Container由ApplicationMaster向ResourceManager申請的，由ResouceManager中的資源調度器異步分配給ApplicationMaster；
  3. Container的運行是由ApplicationMaster向資源所在的NodeManager發起的，Container運行時需提供內部執行的任務命令（可以使用任何命令，比如java、Python、C++進程啓動命令均可）以及該命令執行所需的環境變量和外部資源（比如詞典文件、可執行文件、 jar包等）。

另外，一個應用程序所需的Container分爲兩大類，如下：

  1. 運行ApplicationMaster的Container：這是由ResourceManager（向內部的資源調度器）申請和啓動的，用戶提交應用程序時，可指定唯一的ApplicationMaster所需的資源；
  2. 運行各類任務的Container：這是由ApplicationMaster向ResourceManager申請的，並由ApplicationMaster與NodeManager通信以啓動之。

以上兩類Container可能在任意節點上，它們的位置通常而言是隨機的，即ApplicationMaster可能與它管理的任務運行在一個節點上。

1.3 其他服務介紹

1.3.1 YARN Timeline Server

以一種通用的方式向YARN Timeline Server上註冊應用程序的當前和歷史狀態，便於存儲和檢索。它主要有兩大職責：

  1. 持久化應用程序的具體信息

    收集並檢索應用程序或者框架的具體信息。例如，hadoop MR框架裏面的與分片線關係的信息，諸如map tasks、reduce tasks、counters等。應用程序開發者可以在App Master端或者應用程序需的containers中通過TimelineClient將這些信息發送給Timeline Server。

    這些信息都可以通過REST APIs在具體App或者執行框架的UI界面查詢到。

  2. 持久化已完成的應用程序的Generic information

    在Application history server中，顯然只支持MR框架的job。而在Timeline Server中，Application History只是其中的一個功能。

    Generic information包括：

    • queue-name
    • 用戶信息，還有設置在ApplicationSubmissionContext中的信息
    • 運行應用程序的application-attempts列表
    • 關於每個application-attempt的信息
    • 運行在每個application-attempt下的container列表
    • 每個container的信息

1.3.2 Shared Cache

1.3.2.1 介紹

Shared Cache機制的作用在於爲Yarn上的應用(application)提供了一種安全可擴展的上傳和管理的資源的方式。不同應用之間允許複用上傳的資源文件，從而減少集羣網絡開銷以及應用啓動開銷。

在SharedCache機制之前，hadoop在Yarn和Mapreduce的層面已有cache資源的機制：

  1. Yarn層面：NodeManager上有localizationService維護一系列cache資源，在該NodeManager上啓動的Container允許從cache中讀取相關文件。對於cache資源的可見性包括，public（允許被所有用戶的應用訪問）、private（只允許被文件所有者的應用訪問）、application specific（只允許被指定應用訪問）。

  2. Mapreduce層面：MR作業通過DistributedCache接口，上傳cache資源到HDFS上，mr任務啓動時會將cache文件分發到每個任務節點，在mr任務中可以通過DistributedCache接口從節點本地讀取到cache文件。

SharedCache機制

是在現有機制的基礎上實現的更通用的cache資源機制，主要特性有：

  1. 可擴展性: cache資源需要能擴展到所有節點上而不是集中到master節點
  2. 安全性: 需要對cache資源的訪問權限進行控制
  3. 容錯性: SharedCache服務可能會失敗或者起停，但並不能影響服務正常運行
  4. 透明性: SharedCache服務只是服務端的優化，不應該影響現有MR作業或者其他Yarn的應用的代碼。

1.3.2.2 設計原理

主要有兩部分組成：SharedCacheManager（SCM），本地化服務

  1. Shared Cache Manager

    SCM是ShareCache服務的核心節點。他負責維護所有cache資源信息以及與客戶端之間的通信。SCM本身是一個獨立的進程，可以運行在任意節點上。管理員可以起停SCM服務，並且不會對現有服務產生影響。客戶端與SCM的通信只需要通過兩個接口

    Path use(String checksum, String appId)：客戶端向SCM註冊應用對某個cache資源的使用。其中checksum是cache資源生成的唯一標識。如果該cache資源已經存在則返回其路徑，否則返回null。

    boolean release(String checksum, String appId)：客戶端向SCM釋放應用對某個cache資源的使用。成功則返回true，否則返回false。

    客戶端與SCM交互流程如下：

    1. 客戶端計算cache資源的checksum

    2. 客戶端向SCM調用use(checksum, appId)接口

      • 如果資源已經存在，SCM返回其路徑。客戶端使用cache資源的路徑，並做任務提交。隨後進入步驟5
      • 如果資源尚未存在，SCM返回null。繼續步驟3。

    3. 上傳cache文件到HDFS上的某個路徑（路徑由應用自身決定）。

    4. Cache資源本地化到各個節點。
    5. 提交應用並使用之前獲取到的cache資源路徑。
    6. 應用結束後，調用release(checksum, appId)接口註銷應用對cache資源的使用。

    SCM Store

    SCM Store在SCM中負責維護cache資源的元數據信息。對於每個cache資源，元數據包括：HDFS文件路徑、Checksum值、對該cache資源的引用列表（application列表，每個app包括其id和user名）、該cache資源最近訪問時間。

    目前情況下，SCM store中的信息只維護在內存中，後續會持久化到本地磁盤以及zookeeper上。

    SCM Cleaner service

    這個服務負責掃描並清理cache資源數據。這是個後臺線程定期掃描，一段時間未被使用的cache資源，會被這個線程清理掉。

  2. 本地化服務

    這裏SharedCache本地化服務基於先前的NodeManager的本地化服務。一旦cache資源被本地化，NodeManager會將其添加到shared cache中。默認情況下，appMaster會提交這個資源。

    本地化服務的流程

    1. 資源在NodeManager上進行本地化
    2. 如果該資源需要加入到sharedCache，執行3，否則退出
    3. 計算資源文件的checksum
    4. 上傳資源文件到HDFS的某個目錄，文件作爲一個臨時文件
    5. 臨時文件重命名爲一個特定文件。
    6. 通知SCM該資源文件已經加入到了SharedCache，如果SCM該文件先前已經被上傳過（通過checksum），則刪除該文件。

二. 配置詳解

默認配置文件是yarn-default.xml，需要修改的話，在yarn-site.xml添加對應的屬性。

本節的縮寫：

RM: ResourceManager
AM: ApplicationMaster
NM: NodeManager 

2.1 ResourceManager

選項默認值說明
yarn.resourcemanager.address${yarn.resourcemanager.hostname}:8032RM 對客戶端暴露的地址。客戶端通過該地址向 RM 提交應用程序，殺死應用程序等。
yarn.resourcemanager.scheduler.address${yarn.resourcemanager.hostname}:8030RM 對 AM 暴露的訪問地址。AM 通過該地址向RM申請資源、釋放資源等。
yarn.resourcemanager.resource-tracker.address${yarn.resourcemanager.hostname}:8031RM 對 NM 暴露的地址。NM 通過該地址向 RM 彙報心跳，領取任務等
yarn.resourcemanager.admin.address${yarn.resourcemanager.hostname}:8033RM 對管理員暴露的訪問地址。管理員通過該地址向 RM 發送管理命令等。
yarn.resourcemanager.webapp.address默認值：${yarn.resourcemanager.hostname}:8088RM 對外web ui地址。用戶可通過該地址在瀏覽器中查看集羣各類信息。
yarn.resourcemanager.webapp.https.address${yarn.resourcemanager.hostname}:8090同上的https地址
yarn.resourcemanager.scheduler.classorg.apache.hadoop.yarn.server.resourcemanager
.scheduler.capacity.CapacityScheduler		啓用的資源調度器主類。目前可用的有FIFO、Capacity Scheduler和Fair Scheduler。
yarn.resourcemanager.resource-tracker.client.thread-count50處理來自NodeManager的RPC請求的Handler數目。
yarn.resourcemanager.scheduler.client.thread-count50處理來自ApplicationMaster的RPC請求的Handler數目。
yarn.scheduler.minimum-allocation-mb1024單個容器可申請的最小內存資源量（MB）
yarn.scheduler.maximum-allocation-mb8192單個容器可申請的最大內存資源量（MB）
yarn.scheduler.minimum-allocation-vcores1單個容器可申請的最小虛擬CPU個數
yarn.scheduler.maximum-allocation-vcores32單個容器可申請的最大虛擬CPU個數
yarn.resourcemanager.nodes.include-path（空）NodeManager黑白名單。如果發現若干個NodeManager存在問題，比如故障率很高，任務運行失敗率高，則可以將之加入黑名單中。注意，這兩個配置參數可以動態生效。（調用一個refresh命令即可）
yarn.resourcemanager.nodes.exclude-path（空）見上
yarn.resourcemanager.nodemanagers.heartbeat-interval-ms1000（毫秒）NodeManager心跳間隔

2.2 NodeManager

選項默認值說明
yarn.nodemanager.resource.memory-mb8192NodeManager總的可用物理內存
yarn.nodemanager.vmem-pmem-ratio2.1每使用1MB物理內存，最多可用的虛擬內存數
yarn.nodemanager.resource.cpu-vcores8NodeManager總的可用虛擬CPU個數
yarn.nodemanager.local-dirs${hadoop.tmp.dir}/nm-local-dir中間結果存放位置，注意，這個參數通常會配置多個目錄，已分攤磁盤IO負載
yarn.nodemanager.log-dirs${yarn.log.dir}/userlogs日誌存放地址（可配置多個目錄）
yarn.nodemanager.log.retain-seconds10800（3小時）NodeManager上日誌最多存放時間（不啓用日誌聚集功能時有效）
yarn.nodemanager.aux-services（空）NodeManager上運行的附屬服務。需配置成mapreduce_shuffle，纔可運行MapReduce程序
yarn.nodemanager.webapp.address${yarn.nodemanager.hostname}:8042 
yarn.nodemanager.localizer.address${yarn.nodemanager.hostname}:8040 

2.3 ResourceManager HA

選項默認值說明
yarn.resourcemanager.ha.enabledfalse是否開啓HA模式
yarn.resourcemanager.cluster-id（空）集羣的Id，elector使用該值確保RM不會作爲其它集羣的active。
yarn.resourcemanager.ha.id（空）節點邏輯id
yarn.resourcemanager.ha.rm-ids（空）RM邏輯id列表，用逗號分隔
yarn.resourcemanager.ha.automatic-failover.enabledtrue是否啓用自動故障轉移。默認情況下,在啓用HA時,啓用自動故障轉移。
yarn.resourcemanager.ha.automatic-failover.embeddedtrue啓用內置的自動故障轉移。默認情況下，在啓用HA時，啓用內置的自動故障轉移
yarn.resourcemanager.hostname.xxx（空）各節點hostname（xxx爲邏輯id，需分別配置，見rm-ids）
yarn.resourcemanager.recovery.enabledfalse是否開啓自動恢復
yarn.resourcemanager.zk-address（空）HA時，ZooKeeper節點列表
yarn.resourcemanager.store.classorg.apache.hadoop.yarn.server
.resourcemanager.recovery.ZKRMStateStore		配置RM狀態信息存儲方式，有MemStore和ZKStore
yarn.resourcemanager.ha.automatic-failover.zk-base-path/yarn-leader-electionZooKeeper中的路徑
yarn.client.failover-proxy-providerorg.apache.hadoop.yarn.client
.ConfiguredRMFailoverProxyProvider		Clients, AMs和NMs使用該類故障轉移到active RM
yarn.client.failover-max-attempts（yarn.resourcemanager
.connect.max-wait.ms）		FailoverProxyProvider嘗試故障轉移的最大次數
yarn.client.failover-sleep-max-ms（yarn.resourcemanager
.connect.retry-interval.ms）		故障轉移間的最大休眠時間（單位：毫秒）
yarn.client.failover-retries0每個嘗試連接到RM的重試次數。
yarn.client.failover-retries-on-socket-timeouts0在socket超時時，每個嘗試連接到RM的重試次數。

2.4 Timeline Server

選項默認值說明
yarn.timeline-service.enabledfalse是否啓用timeline service
yarn.resourcemanager.system-metrics-publisher.enabledfalse控制YARN的系統指標是否發佈到Timeline Server
yarn.timeline-service.generic-application-history.enabledfalse客戶端是否能從timeline history-service檢索generic application data。如果爲false，則只能通過RM檢索
yarn.timeline-service.hostname0.0.0.0timeline service的hostname
yarn.timeline-service.address${yarn.timeline-service.hostname}:10200RPC地址
yarn.timeline-service.webapp.address${yarn.timeline-service.hostname}:8188web地址
yarn.timeline-service.webapp.https.address${yarn.timeline-service.hostname}:8190https web地址
yarn.timeline-service.leveldb-timeline-store.path${hadoop.tmp.dir}/yarn/timelineleveldb timeline store存儲路徑

2.5 sharedcache

選項默認值說明
yarn.sharedcache.enabledfalse是否啓動sharedcache
yarn.sharedcache.root-dir/sharedcachesharedcache的根目錄
yarn.sharedcache.admin.address0.0.0.0:8047管理接口地址
yarn.sharedcache.webapp.address0.0.0.0:8788web ui地址
yarn.sharedcache.uploader.server.address0.0.0.0:8046NM接口地址
yarn.sharedcache.client-server.address0.0.0.0:8045客戶端接口地址

2.6 動態設置

可以使用如下命令在提交任務時動態設置：

hadoop jar <jarName> -D mapreduce.map.memory.mb=5120
或者
hadoop jar <jarName> -D mapreduce.reduce.memory.mb=5120

三. 應用示例

3.1 MapReduce On Yarn

vim mapred-site.xml

<configuration>
  <property>
    <name>mapreduce.framework.name</name>
    <value>yarn</value>
  </property>
</configuration>

vim yarn-site.xml
<property>
    <name>yarn.nodemanager.aux-services</name>
    <value>mapreduce_shuffle</value>
</property>

<property>
    <name>yarn.nodemanager.aux-services.mapreduce.shuffle.class</name>
    <value>org.apache.hadoop.mapred.ShuffleHandler</value>
</property>

3.2 Spark On Yarn

在YARN上啓動Spark應用有兩種模式。在cluster模式下，Spark驅動器（driver）在YARN Application Master中運行（運行於集羣中），因此客戶端可以在Spark應用啓動之後關閉退出。而client模式下，Spark驅動器在客戶端進程中，這時的YARN Application Master只用於向YARN申請資源。

3.2.1 cluster運行

運行命令

$ ./bin/spark-submit --class path.to.your.Class --master yarn --deploy-mode cluster [options] <app jar> [app options]

# 示例
$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
    --master yarn \
    --deploy-mode cluster \
    --driver-memory 4g \
    --executor-memory 2g \
    --executor-cores 1 \
    --queue thequeue \
    --jars my-other-jar.jar,my-other-other-jar.jar \
    lib/spark-examples*.jar \
    app_arg1 app_arg2


執行步驟

Spark On Yarn

3.2.2 client運行

執行命令

$ ./bin/spark-shell --master yarn --deploy-mode client

四. 優化

基於兩方面優化：調度器和內存配置。

調度器

根據業務需要選擇fair或capacity調度器。同時根據節點物理資源（性能）的高低，可以打標籤，例如高配置節點、低配置節點和一般節點。

內存優化

依照以下屬性計算推薦的配置

  • RAM（Amount of memory）總內存數
  • CORES（Number of CPU cores）CPU內核數
  • DISKS（Number of disks）硬盤數
每個節點的總內存系統內存HBase內存
4G1G1G
8G2G1G
16G2G2G
24G4G4G
48G6G8G
64G8G8G
72G8G8G
96G12G16G
128G24G24G
256G32G32G
512G64G64G

Container的最大數計算方式：

min (2*CORES, 1.8*DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)

其中MIN_CONTAINER_SIZE是容器的最小內存，可以根據下表獲得

每個節點的總內存容器最小內存的推薦值
小於4G256M
4~8G512M
8~24G1024M
大於24G2048M

最終容器的內存由下式計算獲得：

RAM-per-Container = max (MIN_CONTAINER_SIZE, (Total Available RAM) / Containers))

最後YARN和MR的配置爲：

配置文件屬性值
yarn-site.xmlyarn.nodemanager.resource.memory-mbContainers * RAM-per-Container
yarn-site.xmlyarn.scheduler.minimum-allocation-mbRAM-per-Container
yarn-site.xmlyarn.scheduler.maximum-allocation-mbcontainers * RAM-per-Container
mapred-site.xmlmapreduce.map.memory.mbRAM-per-Container
mapred-site.xmlmapreduce.reduce.memory.mb2 * RAM-per-Container
mapred-site.xmlmapreduce.map.java.opts0.8 * RAM-per-Container
mapred-site.xmlmapreduce.reduce.java.opts0.8 * 2 * RAM-per-Container
yarn-site.xml (check)yarn.app.mapreduce.am.resource.mb2 * RAM-per-Container
yarn-site.xml (check)yarn.app.mapreduce.am.command-opts0.8 * 2 * RAM-per-Container

例如：

集羣節點是12核CPU、48G和12塊硬盤

保留內存 = 6 GB 系統使用 + (如果有HBase) 8 GB HBase使用 
容器最小內存 = 2 GB

無HBase

容器數 = min (2 * 12, 1.8 * 12, (48-6)/2) = min (24, 21.6, 21) = 21 
每個容器的內存 = max (2, (48-6)/21) = max (2, 2) = 2

屬性值
yarn.nodemanager.resource.memory-mb= 21 * 2 = 42 * 1024 MB
yarn.scheduler.minimum-allocation-mb= 2 * 1024 MB
yarn.scheduler.maximum-allocation-mb= 21 * 2 = 42 * 1024 MB
mapreduce.map.memory.mb= 2 * 1024 MB
mapreduce.reduce.memory.mb= 2 * 2 = 4 * 1024 MB
mapreduce.map.java.opts= 0.8 * 2 = 1.6 * 1024 MB
mapreduce.reduce.java.opts= 0.8 * 2 * 2 = 3.2 * 1024 MB
yarn.app.mapreduce.am.resource.mb= 2 * 2 = 4 * 1024 MB
yarn.app.mapreduce.am.command-opts= 0.8 * 2 * 2 = 3.2 * 1024 MB

有HBase

容器數 = min (2 * 12, 1.8 * 12, (48-6-8)/2) = min (24, 21.6, 17) = 17 
每個容器的內存 = max (2, (48-6-8)/17) = max (2, 2) = 2

屬性值
yarn.nodemanager.resource.memory-mb= 17 * 2 = 34 * 1024 MB
yarn.scheduler.minimum-allocation-mb= 2 * 1024 MB
yarn.scheduler.maximum-allocation-mb= 17 * 2 = 34 * 1024 MB
mapreduce.map.memory.mb= 2 * 1024 MB
mapreduce.reduce.memory.mb= 2 * 2 = 4 * 1024 MB
mapreduce.map.java.opts= 0.8 * 2 = 1.6 * 1024 MB
mapreduce.reduce.java.opts= 0.8 * 2 * 2 = 3.2 * 1024 MB
yarn.app.mapreduce.am.resource.mb= 2 * 2 = 4 * 1024 MB
yarn.app.mapreduce.am.command-opts= 0.8 * 2 * 2 = 3.2 * 1024 MB

五. Memsos

5.1 簡介

Mesos是Apache下的開源分佈式資源管理框架，它被稱爲是分佈式系統的內核。Mesos最初是由加州大學伯克利分校的AMPLab開發的，後在Twitter得到廣泛使用。

5.1.1 架構

Mesos Architecture

Mesos實現了兩級調度架構，它可以管理多種類型的應用程序。第一級調度是Master的守護進程，管理Mesos集羣中所有節點上運行的Slave守護進程。集羣由物理服務器或虛擬服務器組成，用於運行應用程序的任務，比如Hadoop和MPI作業。第二級調度由被稱作Framework的“組件”組成。Framework包括調度器（Scheduler）和執行器（Executor）進程，其中每個節點上都會運行執行器。Mesos能和不同類型的Framework通信，每種Framework由相應的應用集羣管理。上圖中只展示了Hadoop和MPI兩種類型，其它類型的應用程序也有相應的Framework。

主要組件以及概念：

  • Zookeeper 主要用來實現Master的選舉，支持Master的高可用。
  • Master Mesos的主節點，接收Slave和Framework scheduler的註冊，分配資源。
  • Slave 從節點，接收master發來的task，調度executor去執行。
  • Framework 比如上圖中的Hadoop，MPI就是Framework，包括scheduler，executor兩部分。scheduler獨立運行，啓動後註冊到master，接收master發送的Resource Offer消息，來決定是否接受。Executor是給slave調用的，執行framework的task。Mesos內置了CommandExecutor（直接調用shell）和DockerExecutor兩種executor，其他的自定義Executor需要提供uri，供slave下載。
  • Task Mesos最主要的工作其實就是分配資源，然後詢問scheduler是否可以利用該資源執行Task，scheduler將資源和Task綁定後交由Master發送給指定的Slave執行。Task可以是長生命週期的，也可以使用批量的短生命週期的。

5.1.2 Mesos流程

Mesos流程

  1. Slave1 向 Master 報告，有4個CPU和4 GB內存可用
  2. Master 發送一個 Resource Offer 給 Framework1 來描述 Slave1 有多少可用資源
  3. FrameWork1 中的 FW Scheduler會答覆 Master，我有兩個 Task 需要運行在 Slave1，一個 Task 需要<2個CPU，1 GB內存=””>，另外一個Task需要<1個CPU，2 GB內存=””>
  4. 最後，Master 發送這些 Tasks 給 Slave1。然後，Slave1還有1個CPU和1 GB內存沒有使用，所以分配模塊可以把這些資源提供給 Framework2

5.2 Yarn與Memsos對比

  1. 最大的不同點在於他們所採用的scheduler：mesos讓framework決定mesos提供的這個資源是否適合該job，從而接受或者拒絕這個資源。而對於yarn來說，決定權在於yarn，是yarn本身（自行替應用程序作主）決定這個資源是否適合該job，對於各種各樣的應用程序來說或許這就是個錯誤的決定（這就是現代人爲什麼拒絕父母之命媒妁之言而選擇自由婚姻的緣故吧）。所以從scaling的角度來說，mesos更scalable。

  2. 其次，yarn是MapReduce進化的產物，yarn就是爲hadoop jobs資源管理而生，yarn只爲hadoop jobs提供了一個static partitioning。而mesos的設計目標是爲各個框架（hadoop、spark、web services等）提供dynamical partitioning，讓各個集羣框架共用數據中心機器。

  3. myriad項目將讓yarn運行在mesos上面。

六. 參考

初步掌握Yarn的架構及原理

Hadoop YARN架構設計要點

Hadoop Yarn架構解析

Hadoop Yarn 框架原理及運作機制

Hadoop On Yarn Mapreduce運行原理與常用數據壓縮格式

yarn-site.xml相關配置參數

Yarn 調度器Scheduler詳解

Hadoop Yarn內存使用優化配置

Yarn資源分配性能調優

Hadoop YARN

YARN Timeline Server(hadoop2.7.1)——科普篇

Hadoop中的Shared Cache機制

Yarn、MR、HBase推薦內存配置

Mesos 架構以及源碼淺析

深入淺出Mesos（二）：Mesos的體系結構和工作流

Mesos高可用解決方案剖析

站內首發文章
安卓學吧
發佈了110 篇原創文章 · 獲贊 95 · 訪問量 7萬+
私信 關注
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

Redis教程（二）詳解

Redis是一個開源，高級的鍵值存儲和一個適用的解決方案，用於構建高性能，可擴展的Web應用程序。Redis有三個主要特點，使它優越於其它鍵值數據存儲系統 -Redis將其數據庫完全保存在內存中，僅使用磁盤進行持久化。與其它鍵值數據存儲相

安卓学吧 2020-06-21 15:36:31

Redis教程（一）簡介及安裝

一、簡介1.1  特點    redis是一個開源的key-value存儲系統，支持多種數據結構，包括：String，hashes，lists，sets和sorted sets。redis將數據存儲於內存中，在內存不足的時候使用虛擬內存來

安卓学吧 2020-06-21 15:36:31

Redis - Memcached 比較

Memcached和Redis作爲兩種Inmemory的key-value數據庫，在設計和思想方面有着很多共通的地方，作爲分佈式緩存服務器使用等也很相似，在這裏把兩者放在一起做一下對比的介紹  基本架構和思想首先簡單介紹一下兩者的架構和設

安卓学吧 2020-06-21 15:36:31

Hadoop 2.x 四層架構

一、存儲層：文件系統HDFS，NoSQL Hbase二、資源及數據管理層：YARN以及Sentry等三、計算引擎：MapReduce、Impala、Spark等四、基於MapReduce、Spark等計算引擎的高級封裝及工具：Hive、P

安卓学吧 2020-06-21 15:36:31

大數據都學什麼？（初學者）

一、學習大數據需要的基礎    java SE，EE(SSM)        90%的大數據框架都是java寫的    MySQL        SQL on Hadoop    Linux        大數據的框架安裝在Linux操作

IT_laobai 2020-06-19 16:12:52

Java大數據學習11--資源調度平臺Yarn的執行流程和三種調度器介紹

一、概述 Yarn是一個資源調度平臺，負責爲運算程序提供服務器運算資源，相當於一個分佈式的操作系統平臺，而mapreduce等運算程序則相當於運行於操作系統之上的應用程序。 二、重要概念 1、yarn並不清楚用戶提交的程序的運行機制 2、

stalin_ 2020-06-07 22:16:59

Java大數據學習09--Mapreduce數據壓縮介紹和配置方法

一、概述： 數據壓縮是mapreduce的一種優化策略：通過壓縮編碼對mapper或者reducer的輸出進行壓縮，以減少磁盤IO，提高MR程序運行速度（但相應增加了cpu運算負擔） 二、基本原則： 運算密集型的job，少用壓縮 IO密集

stalin_ 2020-06-07 22:16:48

MongoDB教程（二） 詳解

安卓学吧 2020-05-13 19:20:37

大數據是什麼？學大數據要掌握的基礎是？（簡單的介紹）

IT_laobai 2020-02-23 06:57:45

Linux定時

IT_laobai 2020-02-23 06:57:45

Hadoop（一） Windows安裝

安卓学吧 2020-02-21 03:27:40

Hadoop（二） HDFS原理

安卓学吧 2020-02-21 03:27:40

Hadoop - Spark 關係

安卓学吧 2020-02-21 03:27:40

Memcached教程（一） 簡介及安裝

安卓学吧 2020-02-21 03:27:40

MongoDB教程（三） Linux下安裝

安卓学吧 2020-02-21 03:27:40