一、概述
用hadoop1.x版本已經有一年多了，在使用的過程中發現hadoop1.X的資源管理機制存在諸多缺陷，甚至在這種資源管理機制下會造成服務器資源的嚴重浪費，負載過高或者過低。本文主要介紹hdaoop1.X的資源管理機制，這種機制的缺點，總結一下自己在這方面遇到的實際問題，最後是自己對改進hadoop資源管理機制的一些想法。
二、hadoop 1.x資源管理機制
hadoop 1.x的資源管理機制分爲兩部分：資源的表示方法和資源的分配。我們都知道計算機的資源是多維度的可以由CPU、內存、磁盤IO、網絡IO等組成，hadoop 1.X將各個節點的這種多維度資源抽象成爲了一種一維度的slot資源，此外考慮到Map Task和Reduce Task這兩種任務使用的資源量不同，hadoop 1.x又將slot分成了Map slot和Reduce slot兩種類型，並規定了Map Task只能用Map slot，Reduce Task只能用Reduce slot。這種設計方法的好處是簡化了資源分配問題，但是也帶來了一系列的問題，包括：導致節點上的資源利用率過低或者過高、對節點的負載不好控制等，下面我會根據自己在實際應用中的各種場景遇到這種問題進行分析和提出假設方案。
三、hadoop 1.x資源管理機制缺點實際場景分析以及假設解決方案
場景：
集羣環境：10臺16核16G內存的PC，集羣配置的map併發數爲110，reduce併發數爲50。
作業1：需要110個Map slot，50個Reduce slot,計算密集型作業。
作業2：需要90個Map slot，40個Reduce slot，磁盤和網絡IO密集型任務。
分析：
一般的PC服務器的瓶頸都在磁盤IO上，對於作業2這種IO密集型作業負載是非常大的，極端情況下如果作業2中的90-90*0.05（約等於85，因爲當有5%的map運行完畢之後纔會啓動reduce任務）個map在運行，40個reduce在運行，那麼集羣的負載是遠遠超過125的，並且很可能超過整個集羣總負載160，因爲IO的等待時間太長。對於作業2這種計算密集型任務來說，負載相對會低，在極端情況下，作業2有110-110*0.05=104個map在運行，有40個reduce在運行，那麼其整個集羣負載會在144左右，不會超過集羣總負載160。
對於這種情況，我們可以進行解決方案的假設:
假設一：如果可以動態的調整map和reduce任務的併發數（換句話說就是動態調整整個集羣的slot數）那麼就不會導致這種節點上的資源利用率過低或者過高情況。
假設二：如果資源表示粒度更細點，不用slot表示而是根據真實的作業資源需求，給作業分配需要CPU、內存、IO等資源，那麼集羣的資源就可以充分利用了。
基於上面2種假設，可以提出下面2種詳細的解決方案：
（1）基於真實需求量的資源管理方案。
整個hadoop 1.X集羣中存在2種slot，分別爲map slot和reduce slot。但是從資源計算機資源的本質來看，這兩種slot其實是同質的,都是代表相同的資源，比如CPU、IO、內存等。在實際環境中，作業隊需求往往是多樣化的，有點需要多些的Cpu、有的需要多寫的內存等等，hadoop 1.X的這種無類別slot的資源劃分粒度過於粗糙，會節點資源利用率的過高或者過低，上面的例子已經描述很清楚了。從真實資源的角度再舉一個反例，例如管理員事先先規劃好一個slot代表2G內存和1個CPU，如果一個應用的任務只需要1G內存，則會產生1G內存資源浪費，從而降低了集羣資源的利用率；同樣，如果一個應用任務需要需要3G的內存資源，則會隱式地搶佔其他任務的資源，從而產生資源搶佔現象，可能導致整個集羣利用率過高。
現在迴歸到資源多維度(CPU、內存、IO等)分配的本質，根據實際的任務資源需求爲其分配系統的各類資源。爲了精確地控制系統資源的分配，不能夠再用slot這種粗粒度的資源表示方式，而是用最直接最本質的方法讓任務直接向調度器申請自己所需要的資源（比如，某個任務需要3G內存、2個CPU），而調度器則按照任務實際的需求爲其精細分配對應的資源量，不再是簡單地將一個slot分配給它。下面是這2種分配方式的示意圖：
這種基於真實資源需求的方案比基於slot的分配方案更加直觀，可以很大程度上提高資源的利用效率。另外，hadoop 2.0已經採用了這種資源管理方案，比如yarn、corona。
（2）基於動態的slot資源管理方案。
根據hadoop 1.X的資源分配策略，一旦每個節點實現配置好可用的slot，即上面場景所說的map和reduce併發數，當集羣啓動後就無法在修改。在我們的實際應用場景中，不同的作業對資源的需求存在着巨大的差異，這種靜態固定的slot分配方案往往會導致節點上的資源利用率過高或者過低。爲了解決這種問題，我們不妨提出這樣的假設在每個節點上安裝一個slot池，它可以根據節點上負載的大小動態的調整節點上map和reduce的併發數，從而是節點上的資源得到充分合理的利用，據我的瞭解這種基於動態的slot資源管理方案已經在阿里的“雲梯”集羣中實現了。看下面示意圖：
（3）基於無類別的slot管理方案。
在MapReduce程序中，Map Task的輸出結果會作爲Reduce Task的輸入，因此Map Task會得到優先調度，當Map Task完成數據達到一定比例（默認5%），Reduce Task纔開始獲得調度機會。對於一個作業來說，剛開始運行時說Map slot資源相對緊缺而Reduce slot卻相當空閒，當Map Task全部運行完畢以後Reduce slot資源就變得相對緊缺而Map slot資源卻很空閒。很明顯，這種按照slot類別的資源管理方案有明顯不足，從一定程度上降低了slot的使用效率。假設我們可以用一種直觀的方案，不再區分Map slot和Reduce slot，而是隻用一種slot，Map Task和Reduce Task共享這些slot，這些slot由任務調度器決定如何分配給Map Task和Reduce Task。這種方案從一定程度上提高了資源的利用效率。示意圖如下：
四、總結
本文主要介紹了hadoop 1.X的資源表示和管理方案，另外根據在實際使用環境中發現這種資源管理方案的問題，提出了一些可以提高集羣資源效率的解決方案。當然，這些方案的實現可行性還有待考證，但是基於真實需求量的資源管理方案已經在Hadoop 2.X中已經得到實現還有基於動態的slot資源管理方案已經在阿里的“雲梯”集羣中實現了。
參考文獻：
[1] http://www.alidata.org/archives
[2]《Hadoop技術內幕：深入解析MapReduce架構設計與實現原理》