Hadoop 跑滿狀態下的 Yarn 資源管理談

1、歷史和由來

當下Hadoop穩定在了2.x.x版本，3.x版本也基本production stable了，雖然敢用的公司不多。在Hadoop 2.x後，都是用 Yarn （Apache Hadoop Yarn ）來管理集羣的計算資源。

隨着互聯網的發展，互聯網公司的業務愈來愈複雜。早在10年前，一個普通的小網站有個50臺機器，能有20個Web服務器20個數據庫，公司內有10來個應用系統，也就差很少了。但像Google、BAT這種巨無霸，很早就面臨了大規模集羣的管理問題，且問題愈來愈大。隨着網絡的爆炸發展，網絡巨頭公司的業務線愈來愈多，愈來愈複雜。看看如今的BAT，有多少業務線，內部有多少IT系統在不停歇的運轉。假若應用的維護者，都本身維護本身的物理機，那這些機器出問題後，維護成本簡直沒法估量。

因而，分佈式操做系統就產生了。所以，如今單臺操做系統管理本機的CPU、內存，分佈式操做系統就管理整個集羣成千上外臺機器的CPU、內存、甚至網絡。

2、相同的領域、產品

2.1 資源管理領域：

• Google先有了Borg，後又開源了 Kubernetes

• Hadoop繫有了Yarn

• Twitter開源了Mesos

由於Hadoop的特色和歷史緣由，Hadoop集羣的資源管控發展到了Yarn這套系統後，基本就是由Yarn來專門跑Hadoop應用,即 Mapreduce／Spark等等計算做業。

那麼Yarn上面可否跑一些別的項目呢？ 固然能夠，須要本身編寫一個on Yarn的程序，寫本身的Application-Master (Hadoop: Writing Yarn Applications )和資源申請模塊等。

2.2 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。

3、多租戶、並行APP&隊列／標籤

3.1 Yarn設計的最大初衷，是多租戶，並行APP

在早版本的 Jobtracker/Tasktracker時期，整個集羣是first-in-first-out的調度策略。每一個APP都在排隊跑，一個APP佔不滿集羣的資源，整個集羣的計算資源就浪費了。

到了Yarn時期，能夠容許多個APP同時跑，按本身的需求共享集羣資源。

3.2 隊列/標籤

• 隊列

在當下穩定的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年前買的，有的是近1年買的。那麼隨着時間的推移，集羣中的機器配置必然會是異構性。

通常來說，都會用老的機器跑一些「實時性不是很重要」的Batch Job，而讓一些新一些的機器，跑一些須要快速處理的"Spark/Streaming" 甚至OLAP的計算任務。

這裏有幾篇講NodeLabel的很好的文章，你們也能夠參考看看：

1. 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

2. YARN Node Labels: Label-based scheduling and resource isolation - Hadoop Dev

   https://developer.ibm.com/hadoop/2017/03/10/yarn-node-labels/

3. 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：

yarn jar /usr/iop//hadoop-mapreduce/hadoop-mapreduce-examples.jar  wordcount -D mapreduce.map.node-label-expression="X" /tmp/source /tmp/result

提交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。筆者會在下一小節着重講這部份內容。

4、Real World 中 Yarn 使用問題

目前，Yarn已經到了一個相對完備的功能階段，發展到了多Queue 多租戶以及成熟的Label管理。下面來說講我我的在運維Yarn的工做時碰到的各類問題。

4.1 用戶問題

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%的內存佔用量，整體看就是一個很客觀的數字。

4.2 Yarn的管理員問題

• 咱們怎麼才能知道隊列的資源使用長期狀況呢？ 拿什麼數據來做爲調整Yarn隊列Queue級別資源的依據呢？

• 每次新加入了一批機器後，咱們固然要給機器打Label，Yarn的Shell Cmd中，打Label:

  Yarnrmadmin—replaceLabelsOnNode「node1[:port]=label1node2=label2

• 若是一次加入100臺機器，打Label去輸入這麼多命令，很容易出問題。怎麼能又快速又安全地搞定這個工做呢？

• 用戶在Channel不停地問Application的問題，有什麼辦法能減小Admin人工回覆用戶的工做，讓用戶自助解決問題？

4.3 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的資源使用率。

非穩定版

穩定版

5、數據驅動的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. 從「總攬圖」找到長期相對空閒的隊列。

2. 把相對「空閒」隊列的資源，劃歸給「超負荷」的隊列

3. 等一段時間，再觀察「總攬圖」，是否「超負荷」隊列的資源真的變好了。（不是重複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 的，而每一個人的時間資源更是寶貴，不能陷入「運維陷進」。

6、分析規律，反哺線上

如何調整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的功能，作好踩坑填坑的準備。

Refer：

[1] Hadoop跑滿狀態下的Yarn資源管理談

http://chuansong.me/n/2145122152021

[2] 大數據sre的思考

https://zhuanlan.zhihu.com/hadoopsre

[3] 大數據平臺下多租戶架構研究

http://blog.csdn.net/u013407595/article/details/37677985

[4] YARN 資源調度那些事兒

http://bit.ly/2n9E478