ResourceManager中的Resource Estimator框架介绍与算法剖析
歡迎大家前往騰訊云+社區，獲取更多騰訊海量技術實踐干貨哦~
本文由宋超發表于云+社區專欄
本文首先介紹了Hadoop中的ResourceManager中的estimator service的框架與運行流程，然后對其中用到的資源估算算法進行了原理剖析。
一. Resource Estimator Service的出發點與目標
估計作業運行使用資源是大數據處理集群的一個重要且具有挑戰性的問題。隨著用戶使用的集群資源越來越多，這一需求被逐漸放大。當前現有的解決方案一般是依賴于用戶的經驗來對作業資源需求進行估計，這樣即繁瑣又低效。根據對集群工作負載的分析，可以發現大部分工作(超過60%)是重復工作，這樣我們便有機會根據作業歷史資源使用情況來估計作業下一次的資源需求量。同時，在未來，希望能提出一種與框架無關的黑盒解決方案。這樣，即使作業來自不同的計算框架，我們也能對重復性作業進行資源需求估算。
二. Resource Estimator Service的框架結構
Hadoop-resource estimator主要由三個模塊組成：Translator，SkylineStore和Estimator。下面分別介紹這三部分。
1.ResourceSkyline用來表征作業在其生命周期中的資源利用率。它使用RLESparseResourceAllocation記錄容器分配的信息。RecurrenceId用于標識重復pipeline的特定運行。pipeline可以包含多個作業，每個作業都有一個ResourceSkyline來表征其資源利用率。
2.Translator用來解析作業日志，提取他們的ResourceSkylines并將它們存儲到SkylineStore。SingleLineParser解析日志流中的一行并提取ResourceSkyline。
3.SkylineStore充當Hadoop-resource estimator的存儲層，由2部分組成。HistorySkylineStore存儲由轉換程序提取的ResourceSkylines。它支持四種操作：addHistory，deleteHistory，updateHistory和getHistory。addHistory將新的ResourceSkylines附加到定期pipeline，而updateHistory刪除特定定期pipeline的所有ResourceSkyline，并重新插入新的ResourceSkylines。PredictionSkylineStore存儲由Estimator生成的預測RLESparseResourceAllocation。它支持兩個操作：addEstimation和getEstimation。
4.Estimator根據歷史記錄運行預測重復出現的pipeline資源需求，將預測存儲到SkylineStore并在YARN上進行資源預留。Solver讀取特定定期pipeline的所有歷史ResourceSkylines，并預測其包含在RLESparseResourceAllocation中的新資源需求。目前，Hadoop-resource estimator提供了一個LPSOLVER來進行預測（其中用到的算法模型會在后面進行講解）。
三.以示例demo演示其運行流程
Resource Estimator Service的URI是http://0.0.0.0，默認服務端口是9998
(在 ResourceEstimatorServiceHome/data中，有一個示例日志文件resourceEstimatorService.txt，其中包含2次運行的tpch_q12查詢作業的日志。進行資源預測主要有以下幾個步驟：
1.解析作業日志：
POST http://URI:port/resourceestimator/translator/LOG_FILE_DIRECTORY 復制代碼發送
POST http://0.0.0.0:9998/resourceestimator/translator/data/resourceEstimatorService.txt 復制代碼underlying estimator將從日志文件中提取ResourceSkylines并將它們存儲在jobHistory SkylineStore中。
2.查詢作業的歷史ResourceSkylines：
GET http://URI:port/resourceestimator/skylinestore/history/{pipelineId}/{runId} 復制代碼發送
GET http://0.0.0.0:9998/resourceestimator/skylinestore/history/*/* 復制代碼underlying estimator將返回歷史SkylineStore中的所有記錄。在示例文件中能夠看到兩次運行tpch_q12的ResourceSkylines：tpch_q12_0和tpch_q12_1。
3.預測作業的資源使用情況：
GET http://URI:port/resourceestimator/estimator/{pipelineId} 復制代碼發送
http://0.0.0.0:9998/resourceestimator/estimator/tpch_q12 復制代碼estimator將根據其歷史ResourceSkylines預測新運行的作業資源需求，并將預測的資源需求存儲到jobEstimation SkylineStore。
4.查詢作業的預測資源情況：
GET http://URI:port/resourceestimator/skylinestore/estimate/{pipelineId} 復制代碼發送
http://0.0.0.0:9998/resourceestimator/skylinestore/estimation/tpch_q12 復制代碼估算器將返回tpch_q12作業資源預測情況。
5.刪除作業的歷史資源情況數據：
DELETE http://URI:port/resourceestimator/skylinestore/history/{pipelineId}/{runId} 復制代碼發送
http://0.0.0.0:9998/resourceestimator/skylinestore/history/tpch_q12/tpch_q12_0 復制代碼underlying estimator將刪除tpch_q12_0的ResourceSkyline記錄。重新發送
GET http://0.0.0.0:9998/resourceestimator/skylinestore/history/*/* 復制代碼underlying estimator只返回tpch_q12_1的ResourceSkyline。
四.資源預測算法中用到的數據介紹
Hadoop-resource estimator的Translator組件會解析日志并將其按照一定規范的格式進行拼接，下面給出了示例中的資源歷史使用數據和預測資源數據，可以看到作業的歷史資源使用數據是同一個job的兩次run，分別為tpch_q12_0和tpch_q12_1,其主要給出了隨時間變化的memory和cpu的使用情況。其中第0時間單位表示的是container規格，為memory:1024,vcores:1，第25時間單位為作業結束時刻，memory和cpu皆為0。可以看到預測數據根據歷史數據給出了10~25時間單位的資源預測數據。
歷史資源使用數據:
[[{"pipelineId":"tpch\_q12","runId":"tpch\_q12\_0"},[{"jobId":"tpch\_q12\_0","jobInputDataSize":0.0,"jobSubmissionTime":0,"jobFinishTime":25,"containerSpec":{"memory":1024,"vcores":1},"skylineList":{"resourceAllocation":{"0":{"memory":1024,"vcores":1},"10":{"memory":1099776,"vcores":1074},"15":{"memory":2598912,"vcores":2538},"20":{"memory":2527232,"vcores":2468},"25":{"memory":0,"vcores":0}}}}]],[{"pipelineId":"tpch\_q12","runId":"tpch\_q12\_1"},[{"jobId":"tpch\_q12\_1","jobInputDataSize":0.0,"jobSubmissionTime":0,"jobFinishTime":25,"containerSpec":{"memory":1024,"vcores":1},"skylineList":{"resourceAllocation":{"0":{"memory":1024,"vcores":1},"10":{"memory":813056,"vcores":794},"15":{"memory":2577408,"vcores":2517},"20":{"memory":2543616,"vcores":2484},"25":{"memory":0,"vcores":0}}}}]]] 復制代碼預測數據:
{"resourceAllocation":"10":{"memory":1083392,"vcores":1058},"15":{"memory":2598912,"vcores":2538},"20":{"memory":2543616,"vcores":2484},"25":{"memory":0,"vcores":0}}} 復制代碼五.Resource Estimator Service算法框架與原理
在本部分將重點介紹一下estimator中用到的資源預測算法原理。此算法由微軟提出，其鏈接在文末參考資料中給出。下圖是estimator的運行框架，可以看到其主要由三部分組成，下面分別介紹這三部分。
image六.算法原理剖析
微軟提出的此資源分配算法本質上是一種最優化算法，其優化的目標函數是由兩部分組成的線性組合，下文中stage的概念是指每個job的運行期間按照一定規則劃分成多個時間片，每個時間片稱之為一個stage，下面分步驟闡述其算法原理。
1.首先定義一個目標函數，也可以稱之為損失函數，即我們優化的目標。在此算法中由過分配和欠分配組成的線性組合組成損失函數costfunction。目標就是minimize(cost=αA0(s)+(1?α)Au(s))。其中A0(s)表示在當前stage的資源過分配值，其是由當前stage的分配值減去此stage的歷史資源使用均值然后取平均得到，其公式表示為A0(s)=1N∑Ni=1∑k(sk?si,k)+,sk即為當前的資源分配值，si,k即為第i次run的歷史資源使用值;Au(s)表示當前stage的欠分配值，其是由上一stage的欠分配值加上當前stage的欠分配值得到，公式表示如下：Di,k(s1,...,sk)=(Di,k+si,k?sk)+,Au(s)=1N∑Ni=1Di,k(s),下圖比較直觀的顯示了estimator在預測資源時的一種過分配與欠分配的情況。
2.針對每個stage,此算法的策略就是選擇可以使得costfunction最小的資源分配方式，即選擇一個值使得costfunction最小，即得到Sk,即每一個stage上的資源分配值。 因為分配值是固定規格的倍數，所以在實現時可以通過簡單的for循環或者一些最優化算法比如爬山法或者蟻群算法就可以快速得到最小值。
3.總結：算法中的做法是針對一個job，根據其歷史運行時間拿到其作業開始和結束時間，在這時間段內按照一定規則劃分時間片，每一個時間片為一個stage，根據同一job多次run的歷史資源使用情況來預測下一run的資源使用情況。其每次配置的策略是使得costfunction最小。costfunction是過分配與欠分配的一個線性組合。
七.算法的測試效果
在本次測試中運行tpch_q12作業9次，并在每次運行中收集作業的資源skylines。然后，在Resource Estimator Service中運行日志解析器，從日志中提取ResourceSkylines并將它們存儲在SkylineStore中。下面繪制了作業的ResourceSkylines以進行演示。
在Resource Estimator Service中運行估算器來預測新運行的資源需求,下面繪制了預測的資源需求數據。可以看到預測數據根據歷史資源使用情況較好地表征了下一次運行的資源使用數據，有一定的參考意義。另外在實際場景業務上的測試效果還有待考證。
八.參考
1.Resourcemanager Estimator Service
2.微軟算法文章
相關閱讀
簡單聊聊py的高性能編程
Prometheus 初體驗
IF函數——放松工作，享受生活！
【每日課程推薦】機器學習實戰！快速入門在線廣告業務及CTR相應知識
此文已由作者授權騰訊云+社區發布，更多原文請點擊
搜索關注公眾號「云加社區」，第一時間獲取技術干貨，關注后回復1024 送你一份技術課程大禮包！
海量技術實踐經驗，盡在云加社區！
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的ResourceManager中的Resource Estimator框架介绍与算法剖析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Optaplanner终于支持多线程并行
- 下一篇： 20165232 缓冲区溢出漏洞实验