本文目錄：
1、Yarn 的歷史和由來
2、Yarn 相同的領域， 還有哪些產品
3、設計、多租戶APP& 佇列/標籤
4、Real World 中 Yarn 的問題
5、資料驅動的 Yarn 管理， 資源治理
6、分析規律， 反哺線上
一、歷史和由來
當下Hadoop穩定在了2.x.x版本， 3.x版本也基本production stable了， 雖然敢用的公司很少。 在Hadoop 2.x後， 都是用 Yarn （Apache Hadoop Yarn ）來管理集群的計算資源。
隨著互聯網的發展， 互聯網公司的業務越來越複雜。 早在10年前， 一個普通的小網站有個50台機器， 能有20個Web伺服器20個資料庫， 公司內有10來個應用系統， 也就差不多了。 但像Google、BAT這種巨無霸， 很早就面臨了大規模集群的管理問題， 且問題越來越大。 隨著網路的爆炸發展，
於是， 分散式作業系統就產生了。 因此， 現在單台作業系統管理本機的CPU、記憶體， 分散式作業系統就管理整個集群成千上外台機器的CPU、記憶體、甚至網路。
二、相同的領域、產品
資源管理領域：
Google先有了Borg， 後又開源了 Kubernetes
Hadoop系有了Yarn
Twitter開源了Mesos
因為Hadoop的特點和歷史原因， Hadoop集群的資源管控發展到了Yarn這套系統後， 基本就是由Yarn來專門跑Hadoop應用,即 Mapreduce／Spark等等計算作業。
那麼Yarn上面能否跑一些別的項目呢？ 當然可以， 需要自己編寫一個on Yarn的程式， 寫自己的Application-Master (Hadoop: Writing Yarn Applications )和資源申請模組等。
on－Yarn 應用
筆者這裡找了一些開源者嘗試的on－Yarn應用：
Docker on YARN
https://conferences.oreilly.com/strata/strata-ca-2017/public/schedule/detail/55936
Presto YARN Integratio
https://prestodb.io/presto-yarn/
prestoDB/presto-yarn
https://github.com/prestodb/presto-yarn
Introducing Hoya - HBase on YARN - Hortonworks
https://hortonworks.com/blog/introducing-hoya-hbase-on-yarn/
但在實際的應用場景中， 大多數規模以上公司光跑Mapreduce／Spark的Job， 集群資源就都擠破頭了， 所以other on-Yarn Application， 不在本文的討論範疇內。 本文將討論競爭激烈且真正跑滿了Hadoop Application 的 Yarn Cluster。
三、多租戶、並行APP&佇列／標籤
Yarn設計的最大初衷， 是多租戶， 並行APP。
在早版本的 Jobtracker/Tasktracker時期， 整個集群是first-in-first-out的調度策略。 每個APP都在排隊跑， 一個APP占不滿集群的資源， 整個集群的計算資源就浪費了。
到了Yarn時期， 可以允許多個APP同時跑， 按自己的需求共用集群資源。
佇列/標籤
佇列
在當下穩定的Hadoop版本裡， 資源的調度都是基於佇列的。
佇列——標籤的映射關係
在一個公司裡， 不同的Team可以按需求把作業提交到不同的佇列裡。 這就好比銀行的門店， 不同的視窗(Queue)可以辦理不同的業務。
根據業務強度， 銀行會給不同的視窗分配不同的人（機器）， 有的視窗分配能力強的人(多CPU)， 甚至開多個視窗(子佇列)， 有的子佇列只服務“軍人”／“老人” (Sub-queue)。 有的視窗分配普通員工。
Yarn的主流調度器 Hadoop: Fair Scheduler & Hadoop: Capacity Scheduler 都是基於佇列設計的。 對這一塊還不瞭解的朋友， 可以點擊下方Scheduler連結， 讀讀官網的原版wiki：
http://hadoop.apache.org/docs/r2.7.1/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html
CapacityScheduler
FairScheduler
本文的第5部分， 將會重點談談基於Queue History Data 的分析， 筆者這裡提供兩篇關於調度器的文章：
1.Cloudera Community : Cloudera’s Fair Scheduler vs. Capacity Scheduler, which one is the best option to choose?
https://community.cloudera.com/t5/Hadoop-101-Training-Quickstart/Cloudera-s-Fair-Scheduler-vs-Capacity-Scheduler-which-one-is-the/m-p/37645#M2251
2.[StackOverflow]: What is the difference between the fair and capacity schedulers?
https://stackoverflow.com/questions/26546613/what-is-the-difference-between-the-fair-and-capacity-schedulers
標籤
Node label （Yarn Node Labels ）是一個為了給相同特點的集群機器分組的解決方案。 直白地說就是異構機器分組。 這一波機器A， 用來跑 map-reduce；另一波機器B， 用來跑spark；還有一部分機器C， 用來跑AI/Machine-Learning Job。
為什麼會產生這種需求呢？
因為Hadoop這個技術棧已經產生了很多年了。 在公司集群中， 有的機器是3年前、5年前買的，
一般來講， 都會用老的機器跑一些“即時性不是很重要”的Batch Job， 而讓一些新一些的機器， 跑一些需要快速處理的"Spark/Streaming" 甚至OLAP的計算任務。
這裡有幾篇講NodeLabel的很好的文章， 大家也可以參考看看：
slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443
http://link.zhihu.com/?target=https%3A//www.slideshare.net/Hadoop_Summit/node-labels-in-yarn-49792443
YARN Node Labels: Label-based scheduling and resource isolation - Hadoop Dev
https://developer.ibm.com/hadoop/2017/03/10/yarn-node-labels/
Node labels configuration on Yarn
https://community.hortonworks.com/articles/72450/node-labels-configuration-on-yarn.html
總之， Hadoop的Admin可以把一個或多個Label關聯到Queue上， 一個Hadoop Application只能使用一個Queue下面的一種Label。 例子：
提交MR作業到Label X：
提交mr作業到Xlabel： yarn jar /usr/iop/
提交Spark作業到Label Y：
./bin/spark-submit --class org.apache.spark.examples.SparkPi --master yarn --deploy-mode cluster --driver-memory 3g --executor-memory 2g --conf spark.yarn.am.nodeLabelExpression=Y --conf spark.yarn.executor.nodeLabelExpression=Y jars/spark-examples.jar 10
Yarn Queue Label
Tip： YARN Node-labels 功能在Apache Hadoop 2.6被開發出來， 但並沒有被merge到官方版本中， 只能通過打Patch的方式使用， 因此是有很多Bug的。 官方推薦 Hadoop 2.8.x 之後再使用， Fix了很多Bug， 而事實上在Apache Hadoop 2.7.3 版本的官方主業裡， NnodeLabel功能被正式介紹出來。
Cloudera 把Node-label的Feature打入了， 但很多Bug並沒有Fix。 筆者會在下一小節著重講這部分內容。
四、Real World 中 Yarn 使用問題
目前， Yarn已經到了一個相對完備的功能階段， 發展到了多Queue 多租戶以及成熟的Label管理。 下面來講講我個人在運維Yarn的工作時碰到的各種問題。
用戶問題
YARN resources are always complained insufficiently by big-data users.
big data infrastructure team裡有一個內網的聊天Channel。 我總是能聽到一些Hadoop User抱怨， 說他們的job今天跑慢了， Pending太久了， 為什麼還拿不到資源等。
如果仔細分析產生問題的原因， 總結下來大致有以下2種：
資源配置問題
資源配置不均就可能會導致上述問題的產生。 如果給某些佇列劃分了過多的資源， 就會導致某些佇列的Job卡住很久。 當佇列資源使用率達到100%時， 另一個佇列的資源使用還不到50%。 比如下圖， Streaming佇列明顯快滿了， 而OLAP佇列還使用了不到1/4。
應用程式濫用問題
先給大家show幾個圖。 第一個圖是一個APP， 經過分析，它申請了32GB的記憶體，但統計後平均使用的記憶體是514MB 。 what？作為管理員，看到這種用戶，是不是很生氣呢…
第二個是APP申請的資源，這一個APP申請了740個CPU，3000GB的總記憶體，這類APP很多。這種APP我認為調優的空間都很大。一個Mapper／Reducer能優化30%的記憶體占用量，總體看就是一個很客觀的數字。
Yarn的管理員問題
我們怎麼才能知道佇列的資源使用長期情況呢？ 拿什麼資料來作為調整Yarn佇列Queue級別資源的依據呢？
每次新加入了一批機器後，我們當然要給機器打Label，Yarn的Shell Cmd中，打Label:
Yarnrmadmin—replaceLabelsOnNode“node1[:port]=label1node2=label2
如果一次加入100台機器，打Label去輸入這麼多命令，很容易出問題。怎麼能又快速又安全地搞定這個工作呢？
用戶在Channel不停地問Application的問題，有什麼辦法能減少Admin人工回復使用者的工作，讓用戶自助解決問題？
Node-Label問題
Bug1
缺乏 Node-Label 資源顯示如下圖。
cdh-5.7.3-Hadoop-2.6.0的Yarn UI
在穩定版本中，是可以顯示出哪種Label、有多少機器、有多少Memory和CPU資源的。
Node-Label穩定版本Hadoop2.8.x
Bug2
Yarn Shell 功能不全，甚至不能使用list all labels功能。
Bug3
Yarn UI沒有分Label去顯示Queue的資源使用率。
非穩定版
穩定版
五、資料驅動的Yarn管理
為了解決上一節提出來的種種問題，我們做了很多自動化的工具。
我們用搜集“時間序列”的資料，來評估佇列的使用情況
用UI Tool 來加快運維操作的批量性／安全性
用更簡潔明瞭的圖表，來給使用者展示他能得到的資源等。
Yarn資源調配
趨勢圖
為了解決Yarn Queue資源調配的公平，我們製作了Yarn Qqueue Level 的 Capacity 占比History 趨勢圖。
總攬圖：所有子佇列的歷史資源使用都在這裡：大家可以看出哪個佇列長期超負荷運轉，哪些Queue長期用不滿資源。
總攬圖主要用來做對比，發現有問題的Queue。
佇列圖：佇列圖是針對一個Queue進行詳細的分析用的：包括佇列裡使用哪種Label的機器，佇列有多少資源，佇列資源的歷史使用占比、超負荷占比、Running／Pending APP歷史，以及Reserve 的Container歷史等。
這樣，在user提出質疑時，先讓user自己來看是否佇列的使用量已經滿了、是否佇列在Reserve Container，從而滿足user的Job等。
級別資源調配
那麼，一次Yarn的Queue 級別資源調配應該是這樣的：
從“總攬圖”找到長期相對空閒的佇列。
把相對“空閒”佇列的資源，劃歸給“超負荷”的佇列
等一段時間，再觀察“總攬圖”，是否“超負荷”佇列的資源真的變好了。（不是重複1）
Yarn運維
在上一節，我們提到了給新加入集群的機器打Label是個漫長的過程。沒關係，本著 “讓一切人對機器的操作盡可能的自動化”的原則，我們設計給Node批量打Label的UI介面如下。
Yarn Queue 級別資源配置展示的不友好
開源版本的Yarn UI 樣式其實很土，很多資訊都展示得不夠透徹，比如：
Yarn 的Queue資源配置到底占了資源的多少。
缺失不同Queue之間的資源對比
像這種文字類的UI，作為使用Hadoop的其它資料團隊user，是不夠直觀的。
我們重繪了Yarn 的Queue Level 資源配置（哪個Queue分多少資源，一目了然），並著重強調了Node-label在劃分資源裡的重要性。
解決用戶自助排查問題
這一塊我們就使用了Linkedin開源的dr.elephant linkedin/dr-elephant.（https://github.com/linkedin/dr-elephant）。
這個工具提供了很多針對Hadoop Job的診斷/調休資訊，可以説明使用者調優自己的Hadoop Job。我們也基於此做了很多二次開發，比如我們需要這樣的功能：
在某個“Queue”下面，按“浪費”的記憶體數量倒排，分別羅列出所有浪費記憶體絕對數量／相對數量最多的 Application。
這個工具就好比很多公司的“客服系統”。當遇到簡單的問題時，它先讓用戶自行解決包括查閱文檔、語音機器人等；若是遇到用戶很難解決的問題時，它會進行人工介入。畢竟公司內是很少Hadoop Admin 的，而每個人的時間資源更是寶貴，不能陷入“運維陷進”。
六、分析規律，反哺線上
如何調整Yarn Queue級別的資源配置，上一章已做了簡單的介紹。
至於實操，每個公司都不一樣，但有一個通用的原則，即Hadoop 運維團隊可以按月／季度，設定運維日。所有需要調整Yarn資源的需求，都發給管理員，待管理員在運維日統一調整。
另外一個比較有意思的地方是，Yarn 集群資源使用率往往是有高峰期和低谷期。
在高峰期時，可能會讓集群的使用率持續打滿。 而低谷期，使用率往往又可能下降到50%甚至更低。通過之前繪製的集群使用率“總攬圖”，以及佇列的“佇列圖”，大家可以分別觀察集群總體的規律和每個佇列的規律。
比如Yarn的總體使用量走勢，如下圖所示：
分析後得出，Yarn Job最大的來源是來自于作業的調度，即調度系統！
我們可以看到，每一天的淩晨零點左右，資源使用率都會爬上去直到100%，而每一天的早上6點到下午3點，集群資源使用率都會下降，甚至降到50%以下。
很多調度系統都是按天級別來調度作業的，允許使用者配置類似Cron語法的Job。很多調度體系還提供簡單的 Daily選項（Airflow Daily：
https://airflow.apache.org/scheduler.html#dag-runs），而這個選項就預設把作業的調度時間設置為了0點。這樣在0點時，大規模的作業被同時調度出去，互相擠佔資源，所以大家都跑得慢。
我們會建議資料團隊們，更改不那麼重要的Job的Daily運行的小時點，“錯峰”運行。
Airflow的Daily調度默認為0點
總結
1.用資料說話，讓一切人的決策基於資料；
2.開發靈活方便的Tool ，讓一切人對機器的操作盡可能的自動化；
3.謹慎使用開源版本，尤其是非穩定的需要打Patch的功能，做好踩坑填坑的準備。
經過分析，它申請了32GB的記憶體，但統計後平均使用的記憶體是514MB 。 what？作為管理員，看到這種用戶，是不是很生氣呢…第二個是APP申請的資源，這一個APP申請了740個CPU，3000GB的總記憶體，這類APP很多。這種APP我認為調優的空間都很大。一個Mapper／Reducer能優化30%的記憶體占用量，總體看就是一個很客觀的數字。
Yarn的管理員問題
我們怎麼才能知道佇列的資源使用長期情況呢？ 拿什麼資料來作為調整Yarn佇列Queue級別資源的依據呢？
每次新加入了一批機器後，我們當然要給機器打Label，Yarn的Shell Cmd中，打Label:
Yarnrmadmin—replaceLabelsOnNode“node1[:port]=label1node2=label2
如果一次加入100台機器，打Label去輸入這麼多命令，很容易出問題。怎麼能又快速又安全地搞定這個工作呢？
用戶在Channel不停地問Application的問題，有什麼辦法能減少Admin人工回復使用者的工作，讓用戶自助解決問題？
Node-Label問題
Bug1
缺乏 Node-Label 資源顯示如下圖。
cdh-5.7.3-Hadoop-2.6.0的Yarn UI
在穩定版本中，是可以顯示出哪種Label、有多少機器、有多少Memory和CPU資源的。
Node-Label穩定版本Hadoop2.8.x
Bug2
Yarn Shell 功能不全，甚至不能使用list all labels功能。
Bug3
Yarn UI沒有分Label去顯示Queue的資源使用率。
非穩定版
穩定版
五、資料驅動的Yarn管理
為了解決上一節提出來的種種問題，我們做了很多自動化的工具。
我們用搜集“時間序列”的資料，來評估佇列的使用情況
用UI Tool 來加快運維操作的批量性／安全性
用更簡潔明瞭的圖表，來給使用者展示他能得到的資源等。
Yarn資源調配
趨勢圖
為了解決Yarn Queue資源調配的公平，我們製作了Yarn Qqueue Level 的 Capacity 占比History 趨勢圖。
總攬圖：所有子佇列的歷史資源使用都在這裡：大家可以看出哪個佇列長期超負荷運轉，哪些Queue長期用不滿資源。
總攬圖主要用來做對比，發現有問題的Queue。
佇列圖：佇列圖是針對一個Queue進行詳細的分析用的：包括佇列裡使用哪種Label的機器，佇列有多少資源，佇列資源的歷史使用占比、超負荷占比、Running／Pending APP歷史，以及Reserve 的Container歷史等。
這樣，在user提出質疑時，先讓user自己來看是否佇列的使用量已經滿了、是否佇列在Reserve Container，從而滿足user的Job等。
級別資源調配
那麼，一次Yarn的Queue 級別資源調配應該是這樣的：
從“總攬圖”找到長期相對空閒的佇列。
把相對“空閒”佇列的資源，劃歸給“超負荷”的佇列
等一段時間，再觀察“總攬圖”，是否“超負荷”佇列的資源真的變好了。（不是重複1）
Yarn運維
在上一節，我們提到了給新加入集群的機器打Label是個漫長的過程。沒關係，本著 “讓一切人對機器的操作盡可能的自動化”的原則，我們設計給Node批量打Label的UI介面如下。
Yarn Queue 級別資源配置展示的不友好
開源版本的Yarn UI 樣式其實很土，很多資訊都展示得不夠透徹，比如：
Yarn 的Queue資源配置到底占了資源的多少。
缺失不同Queue之間的資源對比
像這種文字類的UI，作為使用Hadoop的其它資料團隊user，是不夠直觀的。
我們重繪了Yarn 的Queue Level 資源配置（哪個Queue分多少資源，一目了然），並著重強調了Node-label在劃分資源裡的重要性。
解決用戶自助排查問題
這一塊我們就使用了Linkedin開源的dr.elephant linkedin/dr-elephant.（https://github.com/linkedin/dr-elephant）。
這個工具提供了很多針對Hadoop Job的診斷/調休資訊，可以説明使用者調優自己的Hadoop Job。我們也基於此做了很多二次開發，比如我們需要這樣的功能：
在某個“Queue”下面，按“浪費”的記憶體數量倒排，分別羅列出所有浪費記憶體絕對數量／相對數量最多的 Application。
這個工具就好比很多公司的“客服系統”。當遇到簡單的問題時，它先讓用戶自行解決包括查閱文檔、語音機器人等；若是遇到用戶很難解決的問題時，它會進行人工介入。畢竟公司內是很少Hadoop Admin 的，而每個人的時間資源更是寶貴，不能陷入“運維陷進”。
六、分析規律，反哺線上
如何調整Yarn Queue級別的資源配置，上一章已做了簡單的介紹。
至於實操，每個公司都不一樣，但有一個通用的原則，即Hadoop 運維團隊可以按月／季度，設定運維日。所有需要調整Yarn資源的需求，都發給管理員，待管理員在運維日統一調整。
另外一個比較有意思的地方是，Yarn 集群資源使用率往往是有高峰期和低谷期。
在高峰期時，可能會讓集群的使用率持續打滿。 而低谷期，使用率往往又可能下降到50%甚至更低。通過之前繪製的集群使用率“總攬圖”，以及佇列的“佇列圖”，大家可以分別觀察集群總體的規律和每個佇列的規律。
比如Yarn的總體使用量走勢，如下圖所示：
分析後得出，Yarn Job最大的來源是來自于作業的調度，即調度系統！
我們可以看到，每一天的淩晨零點左右，資源使用率都會爬上去直到100%，而每一天的早上6點到下午3點，集群資源使用率都會下降，甚至降到50%以下。
很多調度系統都是按天級別來調度作業的，允許使用者配置類似Cron語法的Job。很多調度體系還提供簡單的 Daily選項（Airflow Daily：
https://airflow.apache.org/scheduler.html#dag-runs），而這個選項就預設把作業的調度時間設置為了0點。這樣在0點時，大規模的作業被同時調度出去，互相擠佔資源，所以大家都跑得慢。
我們會建議資料團隊們，更改不那麼重要的Job的Daily運行的小時點，“錯峰”運行。
Airflow的Daily調度默認為0點
總結
1.用資料說話，讓一切人的決策基於資料；
2.開發靈活方便的Tool ，讓一切人對機器的操作盡可能的自動化；
3.謹慎使用開源版本，尤其是非穩定的需要打Patch的功能，做好踩坑填坑的準備。