歡迎你們前往騰訊雲+社區,獲取更多騰訊海量技術實踐乾貨哦~html
本文由 宋超發表於 雲+社區專欄
本文首先介紹了Hadoop中的ResourceManager中的estimator service的框架與運行流程,而後對其中用到的資源估算算法進行了原理剖析。算法
估計做業運行使用資源是大數據處理集羣的一個重要且具備挑戰性的問題。隨着用戶使用的集羣資源愈來愈多,這一需求被逐漸放大。當前現有的解決方案通常是依賴於用戶的經驗來對做業資源需求進行估計,這樣即繁瑣又低效。根據對集羣工做負載的分析,能夠發現大部分工做(超過60%)是重複工做,這樣咱們便有機會根據做業歷史資源使用狀況來估計做業下一次的資源需求量。同時,在將來,但願能提出一種與框架無關的黑盒解決方案。這樣,即便做業來自不一樣的計算框架,咱們也能對重複性做業進行資源需求估算。apache
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來進行預測(其中用到的算法模型會在後面進行講解)。oop
Resource Estimator Service的URI是http://0.0.0.0,默認服務端口是9998
性能
(在$ ResourceEstimatorServiceHome/conf/resourceestimator-config.xml」 中配置)。 在$ 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}}}
在本部分將重點介紹一下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 送你一份技術課程大禮包!
海量技術實踐經驗,盡在雲加社區!