Hadoop新特性、改進、優化和Bug分析系列3：YARN-392

背景介紹

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

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

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

解決方案

在這個Jira鏈接中，經過討論后，產生了兩種可行方案，分別是：

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

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

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

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

我們學到了什么？

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

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

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

原創文章，轉載請注明： 轉載自董的博客

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

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

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

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