背景介紹

在YARN中，用戶提交應(yīng)用程序后，對應(yīng)的ApplicationMaster負(fù)責(zé)將應(yīng)用程序的資源需求轉(zhuǎn)化成符合特定格式的資源請求，并發(fā)送給ResourceManager。一旦某個節(jié)點出現(xiàn)空閑資源，ResourceManager中的調(diào)度器將決定把這些空閑資源分配給哪個應(yīng)用程序，并封裝成Container返回給對應(yīng)的ApplicationMaster。ApplicationMaster發(fā)送的資源請求（ResourceRequest）形式如下（具體可閱讀我的這篇文章：YARN/MRv2 ResourceManager深入解析–ContainerAllocator解析）：

其中，Priority為資源的優(yōu)先級、HostName是期望資源所在的節(jié)點，可以為節(jié)點host名、節(jié)點所在rack名或者*（任何節(jié)點均可以），Resource為資源量，#Container為滿足上述三個屬性的資源個數(shù)。

在2.1.0-beta版本之前，通過以上描述無法申請到這樣的資源，比如“只給我節(jié)點Node1上的資源，其他節(jié)點上的不要”或者“只給我機(jī)架rack1上的資源，其他機(jī)架上的不要”，這是因為ResourceScheduler（參考我的這篇文章：YARN/MRv2 ResourceManager深入解析–ResourceScheduler解析）自帶的delay Scheduling機(jī)制導(dǎo)致的，這個機(jī)制來自于MapReduce架構(gòu)，這個機(jī)制進(jìn)一步表現(xiàn)了YARN是直接從MapReduce演化而來的，它對MapReduce天生的支持，而對其他框架不友好。Delay scheduling機(jī)制是為了提高數(shù)據(jù)本地性提出的，它的基本思想是，當(dāng)一個節(jié)點出現(xiàn)空閑資源時，調(diào)度器按照調(diào)度策略應(yīng)將該資源分配給job1，但是job1沒有滿足locality的任務(wù)，考慮到性能問題，調(diào)度器暫時跳過該作業(yè)，而將空閑資源分配給其他有l(wèi)ocality任務(wù)的作業(yè)，今后集群出現(xiàn)空閑資源時，job1將一直被跳過，知道它有一個滿足locality的任務(wù)，或者達(dá)到了管理員事先配置的最長跳過時間，這時候不得不將資源分配給job1（不能讓人家再等了啊，親）。從上面描述可知道，ApplicationMaster申請的node1上的資源，最終可能得到的是node2上的資源，這在某些應(yīng)用場景下，是不允許如此操作的。

解決方案

在這個Jira鏈接中，經(jīng)過討論后，產(chǎn)生了兩種可行方案，分別是：

【方案1】：為每個ResourceRequest添加一個bool類型變量relaxLocality以表明是否為該資源請求啟動delay scheduling機(jī)制，默認(rèn)是true，表示啟用。舉例說明：當(dāng)應(yīng)用程序申請rack1上node1節(jié)點上的資源時，需將rack1和ANY資源的relaxLocality值置為false，同樣，當(dāng)申請rack1上的資源時，需將ANY資源的relaxLocality值置為false。換句話說，某個應(yīng)用程序的rack1資源請求的relaxLocality設(shè)為false的含義是YARN不會為該應(yīng)用程序的分配rack1上的任何資源，直到它接下來請求rack1上的某個節(jié)點或者某些節(jié)點上的資源。

【方案2】：該方案提出將delay scheduling的延遲時間（指上面的最長跳過時間）配置下放給各個Application，而不是由管理員配置一個全局的值。這樣，當(dāng)需要某個節(jié)點或者機(jī)架上的資源時，只需將對應(yīng)的延遲時間設(shè)置為無限大即可，同樣可以巧妙的完成所需功能。

對比兩種方案，感覺實現(xiàn)上難度和復(fù)雜度差不多，但實際上，第2種方案更加復(fù)雜：ResourceManager需要為每個ResourcRequest中的node和rack增加一個超時監(jiān)控器（之前每個application有一個就行），且每次發(fā)送新的ResourceRequest后，ResourceManager需要進(jìn)行較為復(fù)雜的邏輯進(jìn)行資源合并和存放。相比之下，方案1則簡單得多，不需要修改太多代碼，不會引入過多的復(fù)雜邏輯，考慮到2.1.0-beta版本發(fā)布在即，采用方案1是明智之選。但需要注意的是，該jira并沒有解決所有的資源請求語義表達(dá)方面的需求，很多語義仍不能表達(dá)出來，比如，“應(yīng)用程序需要同時申請一組資源，這些資源必須同時滿足應(yīng)用程序才能運行”；“應(yīng)用程序需要一個集合中的任何一個資源，只要獲得了任何一個資源，則其他資源就不需要了”等等。

這個jira可看做實現(xiàn)了一個應(yīng)用程序為自己添加資源白名單的需求，也就是說，只有滿足某些條件的資源才分配給自己；而YARN-750則是應(yīng)用程序申請將某些節(jié)點加入自己的黑名單中，此后不要為自己分配這幾個節(jié)點上的資源，該功能有很多應(yīng)用場景，比如在MapReduce中，當(dāng)一個作業(yè)在某個節(jié)點失敗的任務(wù)數(shù)據(jù)過多時，作業(yè)會將該節(jié)點加入到自己的黑名單中，此后不會再在這個節(jié)點上運行任務(wù)。

我們學(xué)到了什么？

（1） 實現(xiàn)一個龐大無邊的功能時，在未搞清全局問題前，最好先易后難的解決問題。該jira只是YARN-397中的一個子問題，YARN-397的主題是為ResourceManager Scheduler增加新的API，以支持各種語義的資源調(diào)度，比如gang-scheduling（同時申請一組資源,參考：YARN-624）、deadline-scheduling（在規(guī)定時間內(nèi)分配資源）等，這方面的需求伴隨著各種應(yīng)用而生，需要從各種應(yīng)用程序需求中抽取出更全面的調(diào)度模型和語義表達(dá)模型。

（2）YARN調(diào)度器是一個resource-centric調(diào)度器，調(diào)度時間復(fù)雜度是O（number of nodes），而JobTracker調(diào)度器是一個task-centric調(diào)度器，調(diào)度時間復(fù)雜度是O（number of tasks），在設(shè)計YARN調(diào)度策略時，一定要牢記這一點，這是保證YARN高擴(kuò)展性的前提，切莫混淆了這兩種調(diào)度。

（3）YARN的調(diào)度語義在不斷的演化，沒有盡頭。應(yīng)用程序可能有各種各樣的資源需求，比如需要同時獲得一組資源（少一個都不行）、需要獲取來自同一個rack上的資源等，這些通常是從無數(shù)類型的應(yīng)用程序需求中抽象出來的，需要在不斷歸納和抽象中提取，是一個漫長的路。

原創(chuàng)文章，轉(zhuǎn)載請注明： 轉(zhuǎn)載自董的博客

本文鏈接地址: http://dongxicheng.org/mapreduce-nextgen/hadoop-jira-yarn-392/

作者：Dong，作者介紹：http://dongxicheng.org/about/

本博客的文章集合:http://dongxicheng.org/recommend/

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com