1.回顧YARN的三大組件
1.1ResourceManager全局資源管理器
每個集群有一個RM守護進程（可HA），RM負責整個系統的資源分配與管理；它主要有調度器ResourceScheduler和應用程式管理器（APPlications Manager）構成；
1.2 NodeManger，節點資源管理器
每個節點有一個NM守護進程，負責本節點的資源管理。其資源分配主要體現在Container模式上，根據RM分配資源。其次NM負責本地可用資源的監控，故障報告，以及Container的生命周期管理等。
1.3Application Master應用程式主管理器
每個提交的應用程式都有一個AM的守護進程，客戶端每使用YARN客戶端啟動提交執行一個應用程式之前，先啟動一個AM（其實本質就是一個運行的Container，一個程序最早啟動的container實例），AM負責與RM進行資源協商，並協同NM工作以完成應用的功能。
AM的作用就是負責向RM協商資源，並且同時和NM協同配合來運行Container，以及監控他們的資源消耗。
2.NodeManager的功能與服務架構
2.1NodeManager主要職責
NodeManager的概述與核心功能，Hadoop官網一言以蔽之：NodeManager 負責啟動和管理節點上的容器。這些容器用來執行 AppMaster 指定的任務。實際使用中,NM的主要功能如下：
- 啟動後向RM註冊，然後與之保持通信，通過心跳匯報自己的狀態以及接受來自RM的指令。
- 監控節點的健康狀態，並與RM同步
- 管理節點上所有的Container的生命周期，監控Container的資源使用情況，以及Container運行產生的日誌（核心）,NM會向RM匯報Container的狀態信息。
- 管理分布式緩存（對Container運行需要的依賴，依賴庫如jar,配置文件等進行本地緩存），以及不同應用程式的其他附屬要求
2.2 NodeManager服務架構組成
NodeManager內部也有很多組件構成，核心的組件主要NodeStatusUpdater,ContainerManager,NodeHealthCheckService這三大塊構成。
2.2.1NodeStatusUpdater解析
這個組件是NM和RM通信的唯一渠道，主要是用來NM剛啟動或者重啟後向RM進行註冊使用的，NM剛啟動時會向RM註冊，然後匯報本節點的資源情況。後面面周期性地匯報節點的健康狀態，Containers運行情況，正在運行的，已完成，待清理的等等。RM會在NM註冊時給其發送一個令牌KEY，NM保存這個KEY,用這個令牌KEY為AM請求的Container做認證。
其次當一個節點退役或者程序完成時，RM會通過NodeStatusUpdater通知NM殺死正在運行的Container或者清理已經完成應用程式的資源，然後將應用程式的運行日誌進行聚合。
2.2.2 ContainerManager解析
NM的核心是Container的分配與管理，而ContainerManager就是這個核心。一個Container從拉起運行，到最終結束需要很多服務配合，比如通信，資源管理，運行策略等等。而這些服務都有ContainerManager提供管理，具體則由內部的組件完成。
其中的ContainerLauncher類似RM中的ApplicationMaster launcher，區別是前者只拉起AM。而這裡的ContainerLauncher同樣也是維護一個線程池，主要用來殺死或者啟動Container。殺死的請求主要來自RM通過NodeStatusUpdater或者AM通過RPC服務要求清理某個Container時，來殺死Container。而通過ContainerLauncher啟動Container則只有AM通過RPC Server通信發送的請求。
ContainerMonitor就是管理NM上運行中的Container的資源使用情況，如果有Container資源使用情況超過申請的值，就會被殺死.
ResourceLocaliazationService資源本地化服務其實就是，在啟動Container前將其需要的所有的資源安全地下載到本地磁碟，比如從HDFS上下載的文件（程序提交YARN時，YARN會返回一個路徑，一個應用所需資源的HDFS提交路徑）
2.2.3NodeHealthCheckService節點健康檢查
節點的健康檢查通過YARN提供的腳本，定期運行，將檢查結果通過NodeStatusUpdater匯報給RM,以方便RM做節點的監控管理，進一步操作,比如拉黑這個NM，不在給它分配計算任務，直到恢復為止。
3.要了解Container的這些
3.1Container是什麼？
Container是什麼？一般會說Container是NM中抽象的資源集合（包含cpu，內存等）。但實際AM向RM請求的Container是什麼呢？NM上啟動一個Container需要哪些信息？
其實YARN中的Container實例實際是Container Launch Context，包含依賴庫，運行資源（文件，配置信息，運行資源大小），創建進程的必要命令以及安全令牌TOKEN等。具體可參考Container的生命周期。
某種程度上說 Containers其實是一種資源分配形式，它授權應用程式可以在分布式集群中使用某台機器的某些資源。但目前YARN僅支持內存和CPU兩種資源，而且CPU的資源隔離還是使用的Linux的輕量級資源隔離機制CGroup，進行資源隔離的
3.2Container的生命周期
一個Container的生命周期大致可以分成三個過程：
- 資源本地化：主要是Container在啟動前，先將Container運行應用程式需要的各種"資源"下載緩存到本地,供後續Container啟動使用。
- Container拉起/啟動：身份驗證後，服務由ContainerLauncher拉起，啟動Container，執行應用程式的代碼。
- 資源清理：對已經運行完成後者不需要的資源進行清理，防止「爆盤」，跟資源本地化是逆過程。同時NM對Container資源進行回收。
其實內部一個Container生命周期內的狀態遠比這複雜的多，分成很多狀態階段,，從new...Localizing.....Done還有很多細化到狀態，由Container的專門狀態機制維護。
4. NodeManager生產主要參數解析與優化
4.1數據/日誌目錄
4.1.1數據目錄
NodeManager上的存儲目錄主要兩種，一是數據存儲目錄，用於存儲Container運行前需要依賴的文件（jar，配置文件等等），Container運行中產生的臨時數據，比如MR任務運行中落盤的數據。二則是日誌數據目錄，存儲該節點所有Container運行中產生的日誌。
yarn.nodemanager.local-dirs
--NodeManager 存儲中間數據文件的本地文件系統中的目錄列表
<property>
<name>yarn.nodemanager.local-dirs</name>
<value>
/hadoop/data/tmp/nodemanager,/hadoop1/data/tmp/nodemanager,/hadoop2/data/tmp/nodemanager,/hadoop3/data/tmp/nodemanager,/hadoop4/data/tmp/nodemanager,/hadoop5/data/tmp/nodemanager,/hadoop6/data/tmp/nodemanager,/hadoop7/data/tmp/nodemanager,/hadoop8/data/tmp/nodemanager,/hadoop9/data/tmp/nodemanager,/hadoop10/data/tmp/nodemanager,/hadoop11/data/tmp/nodemanager
</value>
</property>注意：一般會將該節點的所有掛載盤（除/根目錄外）都會配置成數據目錄，用逗號分隔即可，一般所有的數據目錄結構都一致，如上所示，掛載了12塊盤的集群數據目錄，具體目錄的名稱可以自定義；這樣配置是為了提高讀寫和負載均衡性能。
這樣配置後實際使用時會採用輪詢的方式將不同的磁碟分配給不同的Container寫入數據。而且為了防止Container的數據被刪除，YARN統一規定必須等Application完成以後，才會清理掉臨時文件。
4.1.2 日誌目錄
yarn.nodemanager.log-dirs
--日誌目錄，也可以配置多個，提高負載，但會限制大小，防止爆盤。
--注意，一般也可以直接配置一個目錄
<property>
<name>yarn.nodemanager.log-dirs</name>
<value>
/var/log/hadoop-yarn/container
</value>
</property>
注意：和數據目錄一樣，YARN也支持將日誌目錄配置成多個目錄，提高讀寫負載均衡。注意這個日誌是Container運行日誌，不止NodeManager運行日誌。一般一個節點一天都會有大量的Container分配，運行，所以也會聚集大量的Container運行日誌，所以本地日誌必須定期清理，否則遲早會爆盤，當然也可以啟動聚合日誌，將日誌上傳的HDFS進行分布式存儲，方便後面進行查看分析。Yarn提供了如下參數，對日誌進行處理：
1.yarn.nodemanager.log.retain-seconds=10800
保留用戶日誌的時間（以秒為單位）。僅適用在日誌聚合已禁用的情況下。
一旦超出時間，NodeManager會將該應用程式的所有日誌進行刪除。
2.yarn.log-aggregation-enable
默認false，不啟用聚合日誌，生產一般啟動true
yarn.log-aggregation.retain-seconds
啟用聚合日誌後，聚合日誌保留多久，建議7天，根據實際制定
3.yarn.nodemanager.remote-app-log-dir
默認值hdfs上：/tmp/logs，
4.yarn.nodemanager.remote-app-log-dir-suffix
默認值是logs
最後聚合日誌的目錄就是由這個目錄由參數3值++用戶名+參數4的值等合成而來
如下圖HDFS上聚合日誌目錄：關於聚合日誌的設置使用還有很多參數，具體可以參考hadoop官網yarn-site.xml文件：
4.2資源參數優化
4.2.1計算節點NM可使用資源配置，節點級別
1.yarn.nodemanager.resource.memory-mb
這個值是NM節點可以使用當前伺服器的最大內存，一般可以設置伺服器內存的70%-85%之間，比如伺服器內存256G,只有NM服務可以設置成200G。
2.yarn.nodemanager.resource.cpu-vcores
這個值是NM節點可以使用當前伺服器的最大CPU核數，一般可以設置伺服器核數的70%-85%之間，比如伺服器64核,可以設置50
下面是HDP官網給的推薦預留內存設置，如果節點不單存是NM,則需要預留更多
編輯
4.2.1節點NM上Container的大小設置
如上，我們知道Container是NM上資源分配的形式，一個NM可以看成很多個不同的Container構成，下面是控制AM申請的Container大小的控制。
1.yarn.scheduler.minimum-allocation-mb
單個容器的最小物理內存量（以 MiB 為單位），一般看公司數據量，我們公司設置3g,一般公司2g也可，且居多都是2g。注意如果申請的資源小於這個值，也按這個值去分配。
2.yarn.scheduler.maximum-allocation-mb
可為容器請求的最大物理內存數量（以 MiB 為單位）。這個值建議可以為單節點NM的可使用的最大內存值。即等於yarn.nodemanager.resource.memory-mb這個值，尤其對於數據量大，計算複雜的公司而言,防止因為內存不足任務報錯。因為使用FAIR公平調度器，如果容器內存不足重試後還不足，直接任務報錯，而使用Capcity調度器可以根據實際Container需要的大小動態調整。具體可參考我的博客。一般公司數據朗不大的話，可以配置NM值的一半也可，即一個NM最小時可以啟動兩個Container。比如以MR任務為例，這個值會限制單個MAP可以使用的最大內存
3.yarn.scheduler.maximum-allocation-vcores
yarn.scheduler.minimum-allocation-vcores
一般伺服器64核，最小可配置1，最大可配置48，同樣，上面兩個參數是確認一個Container可使用的NM上CPU的大小，一般可參考和cpu：內存=1:3配置，比如Container內存最小值是3g，可以配置1核，當然不能超過NM最大的CPU使用核數限制。
4.yarn.scheduler.increment-allocation-mb=512Mb
yarn.scheduler.increment-allocation-vcores=1
這兩個參數是請求資源超出Container最小值後，如何進行動態增加，這兩個參數只對Fairl公平調度器有用，比如YARN的container最小資源內存量為3G，上面的規整化因子是512Mb，如果一個應用程式申請3.2G內存，則會得到3.5內存。但對Capcity調度沒用作用，容量調度器直接增加最小資源的整數倍，同樣申請3.5，後者直接分配7G。具體參考:大數據架構師一定要弄清楚Fair Scheduler和Capacity Scheduler調度器
如下是HDP官網給的配置推薦