hadoop之yarn（優化篇）

最近一直在學習hadoop的一些原理和優化，而後也作了一些實踐，也有沒有去作實踐的，反正我的觀點都記錄下來

1、yarn的介紹

　　YARN的基本結構由一個ResourceManager與多個NodeManager組成。ResourceManager負責對NodeManager所持有的資源進行統一管理和調度。當在處理一個做業時ResourceManager會在NodeManager所在節點建立一全權負責單個做業運行和監控的程序ApplicationMaster。

一、ResouceManager（簡稱RM）

　　資源管理器負責整個集羣資源的調度，該組件由兩部分構成：調度器（Scheduler）和ApplicationsManager。調度器會根據特定調度器實現調度算法，結合做業所在的隊列資源容量，將資源按調度算法分配給每一個任務。分配的資源將用容器（container）形式提供，容器是一個相對封閉獨立的環境，已經將CPU、內存及任務運行所需環境條件封裝在一塊兒。經過容器能夠很好地限定每一個任務使用的資源量。YARN調度器目前在生產環境中被用得較多的有兩種：能力調度器（Capacity Scheduler）和公平調度器（Fair Scheduler）（FIFO通常都不使用）。

二、ApplicationMaster（簡稱AM）

　　每一個提交到集羣的做業（job）都會有一個與之對應的AM 來管理。它負責進行數據切分，併爲當前應用程序向RM 去申請資源，當申請到資源時會和NodeManager 通訊，啓動容器並運行相應的任務。此外，AM還負責監控任務（task）的狀態和執行的進度。

三、NodeManage（簡稱NM）

　　NodeManager負責管理集羣中單個節點的資源和任務，每一個節點對應一個NodeManager, NodeManager負責接收ApplicationMaster的請求啓動容器，監控容器的運行狀態，並監控當前節點狀態及當前節點的資源使用狀況和容器的運行狀況，並定時回報給ResourceManager

更具體點的知識能夠參考hadoop之yarn詳解（基礎架構篇）、hadoop之yarn詳解（框架進階篇）和hadoop之yarn詳解（命令篇）這幾篇文章

2、yarn的優化

丟個官網：https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/yarn-default.xml

　　這裏不說調度器的配置，通常都是選用能力調度器（Capacity Scheduler）和公平調度器（Fair Scheduler），這些通常都是根據公司的具體狀況進行配置，好比根據用戶配置資源比例，或者更具時間點的不一樣配置，畢竟有時候離線計算在某些時候壓力會比較大，能夠根據公司的具體狀況，對具體的一些時間段進行相應的調整，防止集羣壓力過大，形成集羣不健康。

2.一、資源配置

　　在YARN中可供分配和管理的資源有內存和CPU資源，在Hadoop 3.0中將GPU、FPGA資源也歸入可管理的資源中。

　　既然yarn是用來管理資源的，因此資源的來源仍是來源於服務器的cpu和內存。因此也就是咱們配置服務器的多少資源做爲yarn的資源。這裏有兩種配置，一種是本身更具服務器的資源，本身判斷預留給服務器多少資源提供給其餘服務，其餘配置給yarn做爲資源，還有一種就是讓yarn去掃描服務器的資源，按照比例進行配置（這個理論上可行，沒有實踐）

　　這裏再說一句，優化這個東西呢其餘在集羣沒有出現瓶頸的時候就不要去優化，一個是看不出效果，還有就是浪費時間，反正資源夠用，沒啥好優化的，優化的目的就是在有限的資源下，保證集羣的穩定，又能挺高資源的利用率和提升集羣的併發能力。

首先咱們說第一種：手動配置固定的資源給yarn

yarn.nodemanager.resource.cpu-vcores，默認值爲-1。默認表示集羣中每一個節點可被分配的虛擬CPU個數爲8。爲何這裏不是物理CPU個數？由於考慮一個集羣中全部的機器配置不可能同樣，即便一樣是16核心的CPU性能也會有所差別，因此YARN在物理CPU和用戶之間加了一層虛擬CPU，一個物理CPU能夠被劃分紅多個虛擬的CPU。這裏確實能夠配置超過物理cpu的個數，確實可以提升併發，可是嘗試了一把，這樣子服務器的負載就很大了，基本上是處理不過來，並且這樣配置沒有個服務器留有空餘的cpu去執行其餘的任務或者其餘的集羣。由於是生產環境，也沒敢去作壓測，檢測到服務器的負載都是cpu核數的十倍了，因此負載太大，不太敢太激進，因此最終配置是比物理cup核數少那麼幾個，預留幾個cpu給服務器或者其餘服務使用。

 yarn.nodemanager.resource.memory-mb，默認值爲-1。當該值爲-1時，默認表示集羣中每一個節點可被分配的物理內存是8GB。這個通常配置是給服務器預留20%的內存便可。

 

接下來講說第二種：讓yarn自動探測服務器的資源，而後預留必定比例給服務器，而後就能夠把vcore調的大一些，這樣既能提升cpu的使用率，有能保證給服務器留有必定的cpu

首先yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb都要採用默認值-1，這樣以下的配置纔會生效：

yarn.nodemanager.resource.detect-hardware-capabilities 配置爲true，表示可讓yarn自動探測服務器的資源，好比cpu和內存等

而後咱們就配置能夠留給服務器的內存和可使用物理cpu的比例：

yarn.nodemanager.resource.system-reserved-memory-mb：YARN保留的物理內存，給非YARN任務使用，該值通常不生效，只有當yarn.nodemanager.resource.detect-hardware-capabilities爲true的狀態纔會啓用，會根據系統的狀況自動計算

yarn.nodemanager.resource.percentage-physical-cpu-limit：默認是100，表示100%使用，這裏咱們好比能夠配置80%，表示預留給服務器或者其餘應用20%的cpu

yarn.nodemanager.resource.pcores-vcores-multiplier：默認爲1，表示一個物理cpu當作一個vcore使用，若是咱們已經預留給了服務器cpu的話，那咱們這裏能夠調整問題2或者3，這樣一個物理cpu能夠當作2個或者3個vcore使用，畢竟每一個map和reduce做業都要配置cpu，可是有些map和reduce做業又不是計算型做業，因此這樣就能夠更合理的利用資源。相似把蛋糕切小塊，少需的拿一塊，多需求的多拿幾塊，這樣提升了cpu的利用率和提升了集羣的併發能力。（這麼配置的前提是集羣的瓶頸在於cpu不夠使用）

yarn.nodemanager.vmem-pmem-ratio，默認值爲2.1。該值爲可以使用的虛擬內存除以物理內存，即YARN 中任務的單位物理內存相對應可以使用的虛擬內存。例如，任務每分配1MB的物理內存，虛擬內存最大可以使用2.1MB，若是集羣缺內存，能夠增大該值。

注意：若是集羣的資源很充足，就不要把一個物理cpu當2個或者3個使用，也不要吧虛擬內存比例調大，資源夠用就是不用優化，優化只是在資源不夠的狀況進行的。

如上咱們配置yarn集羣的資源，cpu和內存，可是在做業的執行的過中是以container爲單位的，如今咱們來配置container的資源。

yarn.scheduler.minimum-allocation-mb：默認值1024MB，是每一個容器請求被分配的最小內存。若是容器請求的內存資源小於該值，會以1024MB 進行分配；若是NodeManager可被分配的內存小於該值，則該NodeManager將會被ResouceManager給關閉。

yarn.scheduler.maximum-allocation-mb：默認值8096MB，是每一個容器請求被分配的最大內存。若是容器請求的資源超過該值，程序會拋出InvalidResourceRequest Exception的異常。

yarn.scheduler.minimum-allocation-vcores：默認值1，是每一個容器請求被分配的最少虛擬CPU 個數，低於此值的請求將被設置爲此屬性的值。此外，配置爲虛擬內核少於此值的NodeManager將被ResouceManager關閉。

yarn.scheduler.maximum-allocation-vcores：默認值4，是每一個容器請求被分配的最少虛擬CPU個數，高於此值的請求將拋出InvalidResourceRequestException的異常。若是開發者所提交的做業須要處理的數據量較大，須要關注上面配置項的配置

2.二、線程配置

資源配置當然重要，可是影響yarn性能的不僅僅只是資源，還有各個組件之間的配合，線程的數量直接影響到併發的能力，固然也不能配置的過高，這樣會給集羣形成不小的壓力，因此要根據本身集羣的狀態進行合理的配置。

yarn.resourcemanager.client.thread-count：默認50，用於處理應用程序管理器請求的線程數

yarn.resourcemanager.amlauncher.thread-count：默認50，用於啓動/清理AM的線程數

yarn.resourcemanager.scheduler.client.thread-count：默認50，處理來自ApplicationMaster的RPC請求的Handler數目，比較重要

yarn.resourcemanager.resource-tracker.client.thread-count：默認50，處理來自NodeManager的RPC請求的Handler數目，比較重要

yarn.resourcemanager.admin.client.thread-count：默認1，用於處理RM管理接口的線程數。

yarn.nodemanager.container-manager.thread-count：默認20，container 管理器使用的線程數。

yarn.nodemanager.collector-service.thread-count：默認5，收集器服務使用的線程數

yarn.nodemanager.delete.thread-count：默認4，清理使用的線程數。

yarn.nodemanager.localizer.client.thread-count：默認5，處理本地化請求的線程數。

yarn.nodemanager.localizer.fetch.thread-count：默認4，用於本地化獲取的線程數

yarn.nodemanager.log.deletion-threads-count：默認4，在NM日誌清理中使用的線程數。在禁用日誌聚合時使用

yarn.timeline-service.handler-thread-count：用於服務客戶端RPC請求的處理程序線程計數。

2.三、log日誌和文件目錄配置

yarn.nodemanager.log-dirs：日誌存放地址（建議配置多個目錄），默認值：${yarn.log.dir}/userlogs

yarn.nodemanager.local-dirs：中間結果存放位置，建議配置多個目錄，分攤磁盤IO負載，默認值：${hadoop.tmp.dir}/nm-local-dir

yarn.log-aggregation-enable：默認false，是否啓用日誌聚合

yarn.log-aggregation.retain-seconds：聚合日誌的保留時長，設置到3-7天便可，默認-1

yarn.nodemanager.remote-app-log-dir：默認/tmp/logs，本地聚合在hdfs上的日誌目錄

yarn.nodemanager.remote-app-log-dir-suffix：{yarn.nodemanager.remote-app-log-dir}/${user}/{thisParam}用於存放聚合後的日誌

yarn.nodemanager.recovery.dir：默認${hadoop.tmp.dir}/yarn-nm-recovery，本地文件系統目錄，當啓用恢復時，nodemanager將在其中存儲狀態。只有當yarn.nodemanager.recovery.enabled爲true的狀況下才有用，該值默認false

yarn.resourcemanager.recovery.enabled：默認fasle，當RM啓用高可用的時候默認啓用，可是必須配置yarn.resourcemanager.store.class，該值默認爲org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore，最好配置配org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore